知识图谱基础

（一）什么是知识图谱

知识图谱的定义

 

知识图谱在国内属于一个比较新兴的概念，国内目前paper都比较少，应用方主要集中在BAT这类手握海量数据的企业，这个概念是google在2012年提出的，当时主要是为了将传统的keyword-base搜索模型向基于语义的搜索升级。知识图谱可以用来更好的查询复杂的关联信息，从语义层面理解用户意图，改进搜索质量。

 

个人认为，知识图谱最大的优势是在于对数据的描述能力非常强大，各种机器学习算法虽然在预测能力上很不错，但是在描述能力上非常弱，知识图谱刚好填补了这部分空缺。

 

知识图谱的定义非常多，我这里提供一部分我自己的理解：

 

1.知识图谱主要目标是用来描述真实世界中存在的各种实体和概念，以及他们之间的强关系，我们用关系去描述两个实体之间的关联，例如姚明和火箭队之间的关系，他们的属性，我们就用“属性--值对“来刻画它的内在特性，比如说我们的人物，他有年龄、身高、体重属性。

 

2.知识图谱可以通过人为构建与定义，去描述各种概念之间的弱关系，例如：“忘了订单号”和“找回订单号”之间的关系

 

知识库的概念

知识库的种类

知识库目前可以分为两种类型：Curated KBs 和 Extracted KBs

 

Curated KBs：以yago2和freebase为代表，他们从维基百科和WordNet等知识库抽取了大量的实体及实体关系，可以把它理解城一种结构化的维基百科。

 

Extracted KBs：主要是以Open Information Extraction (Open IE),  Never-Ending Language Learning (NELL)为代表，他们直接从上亿个网页中抽取实体关系三元组。与freebase相比，这样得到的实体知识更具有多样性，而它们的实体关系和实体更多的则是自然语言的形式，如“姚明出生于上海。” 可以被表示为(“Yao Ming”, “was also born in”, “Shanghai”)。直接从网页中抽取出来的知识，也会存在一定的噪声，其精确度低于Curated KBs。

 

目前行业内使用的比较多的还是Curated KBs,主要是因为Curated KBs比较简单，容易构建，噪音少。

 

什么是知识库

a)“姚明出生于上海”

b)“姚明是篮球运动员”

c)“姚明是现任中国篮协主席”

 

以上就是一条条知识，把大量的知识汇聚起来就成为了知识库（Knowledge Base）。我们可以从wikipedia，百度百科等百科全书获取到大量的知识。但是，这些百科全书的知识是由非结构化的自然语言组建而成的，这样的组织方式很适合人们阅读但并不适合计算机处理。

知识库的表示形式

为了方便计算机的处理和理解，我们需要更加形式化、简洁化的方式去表示知识，那就是三元组（triple）。

 

“姚明出生于中国上海” 可以用三元组表示为(Yao Ming, PlaceOfBirth, Shanghai)[1]。这里我们可以简单的把三元组理解为(实体entity,实体关系relation,实体entity)。如果我们把实体看作是结点，把实体关系（包括属性，类别等等）看作是一条边，那么包含了大量三元组的知识库就成为了一个庞大的知识图。

 

有些时候会将实体称为topic，如Justin Bieber。实体关系也可分为两种，一种是属性property，一种是关系relation。如下图所示，属性和关系的最大区别在于，属性所在的三元组对应的两个实体，常常是一个topic和一个字符串，如属性Type/Gender，对应的三元组（Justin Bieber, Type, Person），而关系所在的三元组所对应的两个实体，常常是两个topic。如关系PlaceOfBrith，对应的三元组（Justin Bieber, PlaceOfBrith, London）。

 

 

 

 

（图中蓝色方块表示topic，橙色椭圆包括属性值，它们都属于知识库的实体；蓝色直线表示关系，橙色直线表示属性，它们都统称为知识库的实体关系，都可以用三元组刻画实体和实体关系）

 

知识库的数据结构

这里只是简单介绍一下数据结构，知识表达这一块会在《知识图谱基础（二）-知识图谱的知识表达系统》中详细讲解。

 

读者只要记住，freebase的基础知识表达形式：(实体)-[关系]-(实体)，(实体)-[关系]-(值)即可，参考图3，姚明和叶莉的关系。

 

 

知识图谱的应用

通过知识图谱，不仅可以将互联网的信息表达成更接近人类认知世界的形式，而且提供了一种更好的组织、管理和利用海量信息的方式。下图是笔者整理的知识图谱有关的应用，接下来的一些文章笔者会对下面的应用进行剖析。

 

从图4上看，知识图谱的应用主要集中在搜索与推荐领域，robot（客服机器人，私人助理）是问答系统，本质上也是搜索与推荐的延伸。可能是因为知识图谱这项技术（特指freebase）诞生之初就是为了解决搜索问题的。知识存储这一块可能是企查查和启信宝这些企业发现使用图结构的数据比较好清洗加工。

 

在语义搜索这一块，知识图谱的搜索不同于常规的搜索，常规的搜索是根据keyword找到对应的网页集合，然后通过page rank等算法去给网页集合内的网页进行排名，然后展示给用户；基于知识图谱的搜索是在已有的图谱知识库中遍历知识，然后将查询到的知识返回给用户，通常如果路径正确，查询出来的知识只有1个或几个，相当精准。

 

问答系统这一块，系统同样会首先在知识图谱的帮助下对用户使用自然语言提出的问题进行语义分析和语法分析，进而将其转化成结构化形式的查询语句，然后在知识图谱中查询答案。

 

（二）知识图谱的知识表达系统

前面一篇文章主要简单介绍了一下什么是知识图谱，什么是知识库，以及知识图谱的基本应用。知识表达系统可以说是整个知识图谱应用化的灵魂，本文主要从产品角度去讲解知识图谱的知识表达系统。

 

三元组的定义

《知识图谱基础（一）-什么是知识图谱》中讲到了以freebase为代表的curated KBs的本质上是三元组，下面会来讲解三元组的基本组成部分。

 

 

 

实体（Entity）

 

实体是对客观个体的抽象，一个人、一部电影、一句话都可以看作是一个实体。例如：姚明，李安，我不是潘金莲

 

 

 

类型（type）

 

类型是对具有相同特点或属性的实体集合的抽象。

 

举例：中国是一个实体，美国是一个实体，法国是一个实体。这些实体都有首都、人口、面积等共同特征，因此例如像中国、美国、法国等都有首都、人口、面积等特征的实体可以抽象为“国家”类型

 

 

 

属性（property）

 

属性是对实体与实体之间关系的抽象，例如李安是一个实体，李安是一个人物（type），少年派的奇幻漂流是一个实体，少年派的奇幻漂流是一个电影（type），很明显两个实体之间存在着关系即为：李安→导演→少年派的奇幻漂流因此李安与少年派的奇幻漂流之间的关系可以用属性“导演”刻画。那么可以根据属性构建一层关系，人物（type）→导演（property）→电影（type）。

 

 

 

关系（relation）

 

关系是实体与实体之间关系的抽象，李安（entity）→导演（relation）→少年派的奇幻漂流（entity），导演这个relation则是描述李安和少年派的奇幻漂流的关系。

 

 

 

域（domain）

 

域是类型的集合，凌驾于类型之上，是对某一领域所有类型的抽象，例如：国家是对中国、美国这样实体的一种抽象，是一种类型，而一个地理位置除了国家类型之外，还包括其他类型：城市、区域、洲等等，而把这些所有类型：洲、国家、城市、区域等类型抽象起来，就形成了地理位置域。

 

 

 

值（value）

 

值是用来描述实体的，可以分为文本型和数值型，EG：姚明（entity）→身高（relation）→226cm（value）。

 

根据上面的概念，构建一个基础的图谱

 

从三元组构建图谱

从图1中可以得出

 

 

 

阿里巴巴是一家公司，一个股票

 

张勇是一个人物

 

支付宝是一个产品。

 

阿里巴巴的CEO是张勇

 

阿里巴巴的主营产品是支付宝

 

阿里巴巴员工人数是60000

 

 

 

以上就是最基础的知识表达系统，各家公司会针对公司的业务去构建知识库，一般来说，基础的知识表达概念不会改变，比较复杂的情况会针对以上知识表达系统进行一定的修改，后面的文章会讲到。比较复杂的业务可能会涉及到“状态”，“动作”，“状态转移”等过程，freebase就不太适用了，有兴趣的同学可以去看看"超图"。在freebase的二维图谱基础上添加了“状态”的第三维，“动作”的第四维，不过构建会比freebase复杂的多。

 

 

（三）Schema的构建

在前面一篇文章《知识图谱基础（二）-知识表达系统》中介绍了知识图谱的基础知识表达系统，什么是entity，什么是relation，什么是domain，什么是type等等。本篇文章主要从应用角度来聊一聊如何构建schema以及shcema构建中需要考虑的问题。以下所讲的schema构建主要是基于common sense进行构建的，弱关系图谱构建会在应用中讲到。

 

schema的定义

简单来说，一个知识图谱的schema就是相当于一个领域内的数据模型，包含了这个领域里面有意义的概念类型以及这些类型的属性。任何一个域的schema主要由类型（type）和属性（property）来表达。图1是plantdata内的创投schema，主要是为了发掘一级市场的投资和融资构建的schema。该schema主要是去定义需求，哪些数据对创投有用，才往上构建，例如：人物都有身高 体重，但是这些数据对创投来说意义不大，在schema中就不用构建了。关注创投的人会关注这些基金与人物投资了哪些公司，投资的公司所属行业，投资的公司属于哪一类企业，在该schema中就需要详细构建。

 

 

如何构建schema

1.如何构建域（domain）

 

域（domain）的概念是凌驾于所有类型之上，对于域的定义应该尽量的抽象，不应该具体，同时域与域之间应尽量做到相互独立，不交叉。例如，省份就不应该是一个域的概念，在思考是否应该把一个概念当做域时，需要考虑到该概念是否能够继续向上抽象，例如：省份；城市；国家；县等等，他们同属于地理位置域。在明确域的概念时，应该定义好域的边界，这样比较容易区分不同域之间的区域划分。

 

2.如何确定一个域的类型（type）

 

这里需要产品经理去思考，构建这个schema的核心需求是什么，到底需要解决用户什么问题。为了满足这些核心需求，我们需要创造出哪些概念？

 

举个例子，在汽车领域，用户主要关心什么问题，例如：汽车的品牌、车系、发动机。

 

在NBA领域，用户主要关心球队、所属联盟、教练、球员等等。

 

针对不同的需求，需要在域下面构建不同的类型来满足用户的需求。

 

3.如何确定属性（property）

 

思考的角度如下：

 

1.以用户需求为出发点

 

2.以数据统计为证据

 

比如在构建完足球领域中的球队类型后，该类型集合了所有的球队实体，站在用户角度触发，用户会关注球队的哪些关系？

 

 

 

图2是我简单的针对足球领域构建的一个图谱，上面包含了梅西（球队的球员），埃内斯托·巴尔韦德（球队的教练），西甲（球队的所属联赛），其中梅西、西甲、埃内斯托.巴尔韦德又分属于不同的类型：足球球员，足球联赛，足球教练，这些所有的类型构成了足球域。

 

 

 

从上图的common sense配合图查询和自然语言处理技术已经可以支持基础的问答了，例如，梅西是哪个球队的？埃内斯托巴尔韦德是哪些球员的教练？西甲有哪些球队在踢球？等等

 

schema的应用

schema的应用是产品经理需要重点考虑的内容，因为产品需求决定了schema应该怎么构建，构建的是否完备。而产品的具体应用则主导了schema的整体构建方式，如果不仔细考虑产品应用的话，最惨的情况可能构建了很久的schema会因为一个逻辑坑而彻底报废掉，由于知识图谱又是一个牵一发而动全身的工程，根据实际经验来说，如果图谱构建和应用有部分脱节，可能修改图谱schema比重新构建图谱schema的成本还要高。所以，首先确认好具体的应用场景对于一个schema构建的成功与否是至关重要的。

 

笔者写一套曾经用过的确认schema的流程

 

1.需求划分

先将应用根据需求的强弱划分，分为基础核心需求，schema特色需求，锦上添花需求，未来扩展性需求。

 

基础核心需求：是经过需求分析后，构建这个schema需要完成最核心的需求，该需求优先级最高

 

schema特色需求：构建图谱时可能会经常遇到图谱可以实现而其他方法实现比较困难的特色需求，这类需求可能需求强度不是很高，但是由于能够实现一定的差异性，经常会有意想不到的效果。

 

锦上添花需求：非基础核心需求，做了更好，不做也可以接受

 

未来扩展性的需求：确认schema的时候要充分考虑到未来的扩展性，因为这类需求有可能会大改图谱的schema结构

 

2.列出功能点

在构建schema的时候，根据上述分类，需要去考虑该schema一期需要满足哪些具体的功能，将功能一一列下来，哪些功能是需要放在第二期、第三期完成的，未来的扩展性需求需要在构建的哪一块区域留下可扩展的内容。

 

常用的方法可以使用excel去列出一、二、三期所需要的功能点。

 

3.转化成查询结构

列出上述的功能点后，针对每一个功能点在后面备注好该功能的构建要点（注：这个非常重要），通常需求只需要将产品需求转化成一定的查询结构即可，笔者原来用的是cypher查询语法。以图2为例，我要支持某个教练教了哪些球员？转化成查询语言就是（a:足球教练）<-{b:教练}-（c:球队）-{d:球员}-（e:足球球员） return e。将a变成参数，输入a即可返回所有的e，即输入埃内斯托巴尔韦德，返回就是梅西。

 

流程如下：query:埃内斯托巴尔韦德带了哪些球员？→语义解析→转化成上述查询，将埃内斯托巴尔韦德作为参数a代入查询→返回结果→前端包装展示

 

注：上面在每个功能点后面备注了构建要点，当大部分功能点的构建要点都写完的时候，需要集中查看构建要点，因为如果需求本身比较大的话，不同的需求很容易造成schema的构建冲突，正如前面所讲，schema尽量要保证少出错。这个时候由于备注了构建要点，可以全局的来审视这个schema中间有没有逻辑黑洞。常出现的问题主要是在属性的设计，以及知识融合上。

 

4.转化开发需求

拿着上述文件去找开发，确认一下哪些是比较好实现的，一般来说做到这种程度大多数需求开发都是会接的。如果开发同学足够专业的话，他会从他的视角去给你提出他的宝贵意见。通常产品经理在思考schema这一块更倾向于思考这个schema的作用，而开发同学会思考工程实现、实现效率、运行效率、计算量等问题。

 

大规模构建schema

大规模构建schema的时候需要认真考虑数据源的情况，由于不同公司掌握的数据不同，所应用的对策也不同。

 

通常笔者会将数据源分为如下几种：

 

1.已经清洗好的结构化数据：这部分数据一般是公司的核心数据，或者其他公司的核心数据，构建的时候应该优先考虑这类数据。这部分数据通常只需要改变数据格式即可入图谱。

 

2.清洗好的结构化数据，但数据残缺：这部分数据通常需要数据挖掘，知识融合。清洗难度是由残缺比例决定的。

 

3.无数据：没有这部分数据，但是又需要这部分数据，通常只能去选择让BD去购买数据，或者让爬虫组去专业网站爬取，例如：企业数据可以去企查查，电影的数据可以去猫眼，产业的数据可以去产业信息网等等。

 

假设需要构建的图谱entity数量在千万级别，开发力量不够强大的时候，慎用纯数据挖掘方案，有条件的话笔者建议直接去买结构化数据，因为可能挖掘和知识融合在经济上的成本比直接买数据要高，而且时间周期也会很长。

 

 

 

个人认为，大规模构建schema最难的地方就在于挖掘数据的知识融合上，举个例子：全国有10000个叫王刚的人，爬虫从A网站挖下来5000个“王刚”，从B网站挖下来7000个“王刚”，那么这5000个王刚和那7000个王刚到底是不是一个人？在没有身份证号码的情况下如何确定哪些王刚是一个人呢？常规的做法是去挖掘出“王刚”的其他信息，例如出生年月，任职信息，籍贯等等，然后通过一定的算法进行知识融合。通常，网站的数据不一定全面，即使经过知识融合后，挖掘的数据中一定会有大量的噪音，不同的需求对噪音的承受能力是不同的，构建schema的时候需要充分考虑数据出现噪音的可能性，去评价这部分需求对噪音的承受能力。

 

如果知识融合完成了话，大规模构建其实就是一个导数据的过程，由于图谱数据结构的关系，一般存2张表（点、边）或者使用RDFs存储，在entity数量上千万以后，图谱的查询压力会比较大，单机查询可能会直接跪掉，开发一般会采用graphX的分布式的存储，不过由于点和边的切割方式的问题，会有一定的副作用。

 

 

作者：画一个逗逗陪着我

链接：https://www.jianshu.com/p/704e935c98a9

来源：简书