徐波 | 百科知识图谱构建

2017 年 9 月 11 日 开放知识图谱 徐波

本文转发自公众号知识工场，整理自复旦大学知识工场实验室徐波博士在2017年8月26日参加CCKS 2017讲习班所做的报告。

徐波：各位老师，同学，以及企业界的各位朋友，大家下午好。很高兴今天能有机会来这里和大家分享知识图谱的相关技术，我要分享的主题是百科知识图谱构建。

在正式介绍之前，我先简单介绍一下我们知识工场实验室目前在百科知识图谱构建方面的工作。我们构建的知识图谱叫做CN-DBpedia，从这名字大家也能看得出来，是一个类似于DBpedia的工作，主要以百度百科作为单数据源进行知识图谱构建。目前，CN-DBpedia已经成为最大的中文开放通用百科知识图谱之一，涵盖数千万实体和数亿的关系。API累计调用量已经超过了3.5亿次。

CN-DBpedia是一个开放的知识图谱。我们直接开放了Dump数据，大家可以从中文开放知识图谱的网站上进行下载。当前版本包含900多万的实体以及6700万的关系。

当然，大家如果想要CN-DBpedia最新的数据，也可以通过API接口的形式来访问。目前提供了两个API，一个是mention2entity，实现输入一个字符串，返回CN-Dbpedia中对应的实体名。另一个是entityAVP，实现输入一个实体，返回这个实体的所有知识。

围绕着CN-DBpedia，我们组也做了许多应用。

第一个是语义搜索。

这是每个做知识图谱的团队都会做的功能，输入关键字，语义搜索引擎找到它在知识图谱中对应的实体名，然后返回实体所有的结构化信息。包括实体的摘要、infobox、标签和分类等信息。

第二个应用是基于CN-DBpedia构建了一个基于百科知识图谱的问答系统--小Cui问答。

这个问答系统可以回答一些百科知识图谱中存在的知识。大家可以扫描二维码关注我们的公众号，也可以上我们的网站来看。

同时，我们也增加了错误反馈机制，如果小Cui回答错了，大家可以输入数字1告诉我们。

第三个应用是提出了一个基于知识图谱的超级验证码。

验证码提出的初衷就是为了区分人和机器，一个好的验证码应该是人很容易识别出来而机器却很难识别。但是，随着深度学习在图像领域的快速发展，传统主流图像验证码已经不再安全。所以图片验证码只能越做越复杂，慢慢地，验证码变成了机器能识别出来，但人脑反而识别不出来了。

为此，我们仔细的研究了一下，与机器相比，人脑的优势到底在哪？我们认为目前人脑的优势在于阅读理解，因为当前机器的语言认知能力还比较弱。因此，我们提出了基于知识图谱的验证码系统，也就是根据知识图谱中的三元组自动生成了一些题库，让用户来做阅读理解题。也就是给出一个问题和一段文本，让用户通过阅读这段文本来找到问题的答案。

接下来我们进入正题，介绍一下像CN-DBpedia这样的一个百科知识图谱是怎样构建出来的。

首先要回答的一个问题就是，什么是百科知识图谱？我们认为百科知识图谱是一类专门从百科类网站中抽取知识构建而成的知识图谱。

那么，什么是百科类网站呢？典型的百科类网站包括百科网站，例如维基百科和百度百科。

我们分析这两个网站，不难发现，百科类网站具有三个特点：第一个特点是一个实体一个页面，每个页面都是围绕一个实体进行全方面介绍的。从它们网页的命名方式也能看出来，都是以网站的前缀+实体名构成的。

第二个特点是这类网站包含了格式统一的半结构化文本。这样的半结构化文本让我们能够写统一的抽取模板来对网页进行抽取。

第三个特点是内容质量高，百科类网站都是通过众包或者专业人员编辑的，错误相对要少一些。

百科类网站的这三个特点刚好对应了百科知识图谱的三大特点：获取容易、抽取简单、质量高。因此百科知识图谱成为了许多知识图谱构建人士的入门首选。

按照以上我所描述的百科类网站的特点，有很多网站都可以称为“百科类网站”。比如电影网站、购物网站、工商信息网站、法律网站等，都是一个页面介绍一个实体，每个实体都有很多结构化的内容。可以通过这些网站来构建领域知识图谱。

百科知识图谱构建的方法从数据源来说，可以分为两类。一类是对单百科数据源进行深度抽取，典型代表有Dbpedia,Yago和CN-DBpedia。Dbpedia和Yago是以维基百科作为数据源，而CN-Dbpedia是以百度百科作为数据源。另一类是对多百科数据源进行融合。典型代表有BabelNet，zhishi.me和XLORE。BabelNet是融合了非常多的知识图谱。Zhishi.me融合了百度百科、互动百科以及中文维基百科。XLORE融合了百度百科、互动百科以及英文维基百科。这两类构建方法的重点有所不同，前者侧重于抽取，后者侧重于融合。

在前几天刚刚结束的IJCAI 2017会议上，评出了两篇卓越论文奖，分别给了YAGO2和BabelNet，这是一件令广大知识图谱构建者兴奋的事情，这代表着国际人工智能组织对于我们知识图谱构建工作的认可。同时，两类构建方法并列获奖，也说明了这两类构建方法都是非常重要的。

接下来，我将以CN-DBpedia为例，介绍如何对单百科数据源进行深度抽取。后面我们讲的百科知识图谱构建均表示对单百科数据源进行深度抽取的构建方法。总的来说，百科知识图谱构建分为三个部分，第一个是知识获取，就是通过自动的方法将网页数据转化为高质量的结构化数据。第二个是知识填充，即在现有数据的基础上加以完善，得到更多结构化的知识。第三个是知识更新，就是保证你所获得的知识永远是最新的。

我们首先介绍第一部分，知识获取。

知识获取主要分为两个部分，一个是抽取知识，另一个是对抽取来的知识进行清洗。

知识抽取大致能分为三类，一类是结构化数据知识抽取，比如说从数据库里面抽取知识。另一类是半结构化知识数据抽取，比如说从表格里面抽取知识。第三类是非结构化知识数据抽取，比如说从文本里面抽取知识。

此次讲习班的安排，很巧妙的刚好把这三个分类全都覆盖了。

比如T5的知识图谱虚拟化，就是对数据库进行处理的。不过他们并不要对数据进行抽取。具体怎么做的大家晚上听报告就知道了。半结构化数据的知识抽取就是我们百科知识图谱构建要干的事情，主要从百科网站的半结构化数据中抽取知识。然后T3报告的话，就是对文本数据进行开放领域抽取或者限定领域抽取等。

言归正传，下面我们一起来看看百科知识从哪来。

由于百科网站一个实体只占据一个页面，所以实体的所有关系也只能从这么一个网页上获得。有句话叫所见即所得，我们把一个页面从上翻到下，看到什么，就拿什么。一般来说，百科知识可以分为这么几大类，首先是标题，用来表示实体名称。然后是它的同义词和多义词以及摘要关系。

接下来就是infobox信息，又叫基本信息框，是一组（属性，属性值）对，是对实体的结构化总结。很多情况下，你可以不看内容，只看infobox信息就能了解这个实体了。Infobox是百科知识图谱最重要的知识来源之一，从关系数量来说，它也能提供最多知识的一类关系。

还有就是相关实体关系，如下图中蓝色字体部分，代表着一个与当前实体有联系的其他实体。另外就是标签了。根据“知识图谱导论”课程上说的，知识体系分为三类。第一类是ontology，不同层节点之间是严格的IsA关系，可以适用于知识的推理。第二类是Taxonomy，上下位节点之间是非严格的IsA关系，可以表示概念的二义性。第三类是Folksonomy，能够涵盖更多的概念，但难以进行标签管理。

百度百科中的标签就属于第三类，开放分类。概念与概念之间无直接联系。

当然，不同百科网站能得到的知识也不尽相同。Wikipedia中就有一些百度百科中没有的知识，比如说概念的层次结构、实体的地理信息以及实体的多语言版本等。

统一的自动抽取框架就是为每类关系建立一个单独的抽取器。如下图所示，这个是DBpedia的抽取框架，输入可以是Dump文件，也可以是API形式。一个网页进来后，首先通过解析器对其进行解析，然后通过不同的抽取器获得不同的知识，再存储到数据库中，供外部应用使用。

然而，抽取完的数据并不是那么完整，还是会有许多的质量问题，这是不可避免的，因为百科网站是由很多人众包编写的，并没有一个非常统一的编写标准，每个人的想法不一样，写出来的内容也不尽相同。

这种不完整具体表现为：在基本信息框中，属性可能不一致，比如说，有的喜欢叫英文名，有的喜欢叫英文名称。属性值的写法也不一样，同样一个日期，有的人喜欢用年、月、日，有的喜欢用纯数字。还有一个需要特意强调的地方就是，大家喜欢把多个值写在一起，这样做其实对于转化为结构化数据是非常不利的。本来知识图谱想构建的是实体和实体的关系，结果抽取出来变成了实体和字符串的关系，因此，需要将多个属性值分开处理。

所以，数据清洗模块我们分为了三个部分，首先属性融合，将所有等价属性合并，比如英文名和英文名称。接下来对日期属性值进行归一化，转化为统一的日期格式。最后，再通过一个值分割算法，将所有多值的情况分开。

一、单数据源的属性融合

一般来讲，分为两步，第一步是找到候选属性对。可以通过属性相似性来找候选属性对，这样英文名和英文名称就能找到了。但是有一些属性对还是找不到，比如妻子和老婆。这个就需要利用外部的同义词知识库来做了。大家可以从同义词字典、百度汉语等地方来找同义词。如果还有些找不到的话，就要通过人工的方式录入进去。第二步是删除错误的候选属性对。那么如何删除错误属性对呢？一般来说，是基于启发式规则来做的，包括等价属性不能同时出现在一个实体中。例如复旦大学这个实体中不可能同时出现“英文名”和“英文名称”这两个属性。以及等价属性的domain和range要相同等等。最后，再通过人工的方式删掉一些。

二、数值属性值归一化

之所以要对数值属性归一化，是因为数值属性的属性值往往是由数字+ 单位构成。所以可以分为数值抽取和单位统一两个步骤，比如通过正则表达式抽取出年、月、日等数值信息，通过转化公式来统一单位。

针对对象属性值，我们首先判断这个字符串是否存在分隔符。如果不存在任何一种分隔符，那就不需要分割。如果存在，计算字符串按照出现的每一种分隔符进行分割后的得分，得分如图所示。再判断该得分是否大于未分割的得分，最终，取得分最大的方案作为最终的分割方案。

三类数据清洗的例子如图所示。根据属性融合方法，我们将“英文名”改成了“英文名称”。根据数值属性归一化方法，我们将“1905年（乙巳年）9月14日”统一成“1905年09月14日”。根据对象属性值分割方法，我们将复旦大学的知名校友给分割开来。

通过知识抽取和数据清洗两个步骤，我们就能将网页数据转换为高质量的结构化数据了。

接下来，我们再介绍一下知识填充，即如何获得更多的知识。

所有百科知识图谱都会面临的一个不可避免的问题就是知识缺失。因为我们的数据源是百科类网站，而它们很难做到完整。总体来说，包括三类知识缺失：

第一类为单个实体的知识缺失

第二类为所有实体都缺少的分类知识

第三类为概念缺失表示知识

第一类是单个实体的知识缺失。比如缺失infobox，标签，摘要等信息。下图左边是周杰伦的信息，右边的刘德华的信息，刘德华的infobox信息就要比周杰伦多5个。这两个实体还都是最popular的实体，都有这么明显的差距。其他实体就更不用说了。

第二个是实体的分类信息缺失。我们知道，百度百科中的标签属于folksonomy开放标签，无法进行推理，因此，我们需要把实体分类到能进行推理的ontology上去。

第三个是概念表示知识缺失。相对于实体而言，我们对概念的认识还不够，目前只知道一个概念的父概念是哪个，子概念是哪个，以及它包含哪些实体，但我们无法直接从知识图谱中获知这个概念是怎么形成的？

针对这三类知识的缺失，我们将其归类到三个具体的研究任务上。

针对单个实体的知识缺失问题，我们把它看做是实体的属性-值，也叫infobox关系填充问题来解决。

针对实体分类知识缺失问题，我们就把它当做实体分类问题来解决。

针对概念表示知识缺失问题，我们把它当做概念的符号表示问题来解决。

接下来，我们先介绍infobox completion。

Infobox completion方法很多，主要包括：

一、利用其它知识图谱进行填充。

二、利用百科网站实体标签进行填充。

三、利用百科网站文本进行填充。

第一类方法是利用其它知识图谱进行填充。主要使用的是知识图谱融合的思想，不同知识图谱的实体之间可以通过等价关系“SameAS”链接在一起，不同知识图谱由于构建方式不同，知识也不尽相同，因此，可利用其它知识图谱来对自身知识图谱Infobox进行填充。此类方法需要解决的难点包括：实体匹配、属性匹配、属性值融合等。如果要做跨语言的融合，还需要解决跨语言的问题。

第二类方法是利用百科网站实体的标签进行填充。例如已知“刘德华”的一个标签信息为“香港男演员”，那么就可以推出（刘德华，出生地，香港），（刘德华，性别，男）和（刘德华，职业，演员）这三组infobox。目前主流的方法倾向于使用人工建立规则的方法来进行抽取，主要包括YAGO和Catriple。我们也提出了一种基于统计的方法，具体将在概念表示部分来进行说明。

具体来说，YAGO是使用了一种基于正则表达式的方法来从标签信息中抽取关系。例如，通过正则表达式([0-9]{3,4}) births 来抽取BornOnDate关系，或者通过Mountains|Rivers in (.*)来获取LocatedIn关系。这种方法的优点是准确率高，每类关系的准确率都超过90%。但缺点是代价太大了，需要为每个关系定制一套正则表达式。

Catriple利用了Wikipedia的上下位概念来获取实体的infobox信息。如下图所示，根据（Songs by artist, The Beatles songs）能推断出任何属于概念TheBeatles songs的实体都包含（artist,The Beatles）这一对属性-值对。根据（Rock songs ，British rock songs ）能推断出任何属于概念Britishrock songs的实体都包含（Country,British）这一对属性-值对。因此，实体Hey Jude能得到两组infobox，分别是（Hey Jude, artist, The Beatles）和（ HeyJude, Country, British）。

具体方法为构建了四种有效的上下位概念模式：

第一种为by-prep的上下位概念组合。其中上位概念需要满足“by +属性”这一条件，例如songs by theme。下位概念需要满足“是介词从句且包含属性值”这一条件，例如Songs about divorce。如果满足这两个条件，那么就可以从上位概念中抽取属性，从下位概念中抽取属性值。这一属性-值对将传递给下位概念的所有实体。

第二种为by-noun的上下位概念。和第一种的区别就是下位概念需要满足“是名词从句且包含属性值”这一条件。抽取方式和第一种相似。

第三种为非by-prep形式的*-prep上下位概念组合。其中上位概念不包含属性，如“songs”。下位概念满足 “是介词从句且包含属性值”这一条件，如“songs from films”。这种情况下，可以从下位概念中抽取属性值，再根据投票的方法确认属性值对应的属性。投票的方法包括全局投票和局部投票两种。全局投票是统计整个数据集中，当属性值为某一个具体值（如films）的时候，最常出现的属性是哪个。局部投票是统计在某个下位概念包含的实体infobox数据集中，当属性值为某一个具体值（如films）的时候，最常出现的属性是哪个。

第四种模式和第三种类似，只是把介词从句改成了名词从句。

第三类进行infobox completion的方法是利用实体的文本内容进行填充。对实体正文进行属性值抽取和之前的网页抽取器类似，可以看作是为每个属性分别构建一个抽取器，例如“刘德华（AndyLau），1961年9月27日出生于中国香港。”这个句子，通过“英文名称”抽取器可以得到AndyLau这个属性值，出生日期抽取器可以得到1961年9月27日，而出生地抽取器可以得到中国香港这个属性值。

文本属性值抽取被认为是一个序列数据标记问题。它是把整个句子当做是一个序列数据，每个属性值抽取器的抽取过程当做是序列数据的标记过程。1表示是属性的值，0表示不是属性的值。

传统最好的方法是使用条件随机场来进行序列数据标记。它同时考虑了每个单词的特征以及句子的顺序性，但缺点是需要专家人为设计一套特征，如下图右边所示，特征选择的好坏直接影响分类的结果。同时，也不具有通用性，英文的需要设计一套特征，换成中文的话，又要设计另外一套特征了。

为此，我们提出了基于深度学习的方法，不需要人工设计特征进行自动进行分类。典型方法为基于LSTM的方法，输入为一个句子，输出为句子中每个单词的标记，其中，句子中的每个单词用两类向量来表示，一个是word embedding，另一个是character embedding。同时，整个句子再通过一个双向的lstm模型来自动抽取出特征，最后对每个单词进行分类，0表示不是属性值，1表示是属性值。

目前更好的深度学习方法，是使用lstm自动抽取特征，再通过条件随机场来进行序列数据标记，也就是在lstm的输出层中在加一个crf层。目前TensorFlow和keras等都支持这一操作。

接下来，我们来介绍如何对实体进行分类。

我们这里研究的实体分类是指将知识图谱中的实体分类到一组预定义的概念集合中。这与传统的命名实体识别问题有一些区别，传统命名实体识别问题研究的是一个句子中的实体指称项（也称mention），考虑的也仅仅是上下文的文本特征，实体指称项的分类结果可能只是现实世界中实体分类结果的一部分。例如从句子“刘德华出生于1961年9月”中，只能推断出“刘德华”属于“人物”这个概念，其他的“演员”、“歌手”等概念都无法得到。知识图谱中的实体分类研究的对象是实体本身，考虑的是实体在知识图谱中的全部知识，包括文本特征和语义关系特征等，与真实世界中实体的分类结果理论上一致。

实体分类本质上就是一个经典的分类问题，总结下来，可以包括人工方法、自动规则、有监督方法和远程监督方法。

人工方法的典型代表就是DBpedia，它通过众包的方式构建了一个本体ontology，然后又通过众包的方式建立起了Wikipedia infobox模板名称和ontology中概念的等价关系。这样的话，一个实体就能根据它的模板名称来判断它属于哪些概念了。

自动规则很简单，就是基于等价概念、等价实体以及继承关系来进行推理。

接下来一种是YAGO的做法。它认为实体的标签中蕴含着实体的概念信息，它将wikipedia的标签分为了四类。第一类是我们需要的概念型标签；第二个是基于管理目的的标签，如“缺少引用文献的词条”等；第三类是关系型标签；第四类为主题型标签。只有第一类是我们需要的。它的识别方法也很简单，使用了浅层语义解析方法来做。对于任意一个标签，首先从中识别出它的中心词，如果这个中心词是复数名词的话，那么这个概念就有很大可能性是一个概念型标签。当然，这个方法比较适合于英文，中文的话就很难这样做了。

另外一种是有监督的实体分类。这种最为简单，如果你有充足的训练集的话，那么不管你用哪个模型，比如支持向量机、逻辑回归、决策树等等，都能取得非常好的效果。

更多情况下，我们遇到的问题是没有训练集，例如，我们要将百度百科的实体分类到英文DBpedia的本体上去。所以我们可以通过一种被称为弱监督或者远程监督的方法来构建训练集，即首先建立起中文百度百科实体和英文DBpedia实体的等价关系，再把英文实体的分类关系传递给等价的中文实体，通过这种方式就能为一些中文百度百科实体获得标记数据了。

当然，与有监督方法的训练集相比，远程监督方法构建的训练集会存在更多的噪声问题。主要是由三方面原因构成：1，目标知识图谱本身存在噪声，这点无法避免；2，实体链接错误，这也很难避免，因为实体链接本身就是一个很难的问题，准确率不能达到100%；3，实体特征缺失，导致很多正确的分类错误变成了错误标记。举个极端点的例子就是，一个实体，它的所有特征都缺失了，但是根据等价关系知道它有很多分类结果，这就意味着，如果你不包含任何特征，你就能属于这些分类。这显然是错误的。

因此，我们采用了一个通用的噪声过滤算法，这种方法叫做多分类器投票过滤算法。具体而言，它是将训练集分成了N份，其中每N-1份作为新的训练集，用来过滤剩下的那一份训练集中的噪声数据。每个分类器根据新训练集进行重新训练，再对剩下的那份训练集中的每个实体进行重新预测，将预测结果和原始结果进行比较，原始结果中未被预测出的结果就视为分类器发现的该实体的噪声分类。每个分类器都能找到一些噪声数据。最后，综合多个分类器发现的噪声数据，再通过合理的过滤策略就能对训练集进行噪声过滤了。

过滤策略分为大多数投票过滤和一致性过滤两种。其中，大多数投票过滤认为只要大多数分类器认为它是一个噪声数据，那么就可以把它给过滤掉了。一致性过滤认为必须要所有分类器都认为它是噪声数据才能把它给过滤掉。PPT上的两个图也说明了这两种过滤策略的区别。

最后，并不是随便选一些分类器就能做多分类器投票的。它必须满足两个条件，一个是每个分类器的准确率要高于50%，另外一个是每个分类器产生的错误要是独立的。

接下来我们来具体讲讲在CN-DBpedia中是如何进行实体分类的。

因为中文并没有一个很好的本体ontology，但英文有一些很好的本体，比如DBpedia,所以我们将百度百科中的实体分类到英文DBpedia的本体中去。具体用到的特征包括语义关系特征(属性，属性-值以及标签等)以及文本特征(主要来自于摘要以及正文信息)。处理这两种特征的方法不同，我们针对每类特征分别提出了一种分类方法。

第一种是利用语义关系特征来进行分类。

一个实体通过一组语义关系特征来表示,根据这一组语义关系特征来判断实体的分类。核心点之前已经说过了，就是构建一个高质量的训练集，也就是我们框架图的中间层部分。

我们首先通过远程监督的方式构建了一个训练集，包括使用了跨语言实体链接技术构建了中文实体和英文实体的等价关系，然后通过跨语言分类传递方法，将英文实体的分类信息传递给等价的中文实体,接着，通过之前提到的训练集过滤算法，得到一个去噪后的训练集。当然，为了使这个结果更好，我们进行了额外的两步优化:第一步，针对DBpedia实体不完整的情况，对DBpedia的分类关系进行了填充，利用到了DBpedia实体的标签信息；第二步针对Dbpedia本体的树状结构，提出了一个层次化的分类算法。具体实现大家可以看我们发表的这篇论文。

第二种是利用文本特征来对实体进行分类。

从文本中得到实体的分类结果和利用语义关系特征得到分类结果是不一样的。因为，实体在句子中可能只能表现出实体的部分分类结果，你不能只通过实体在一个句子中的信息来判断它的分类结果，这样是不全面的。比如第一句“刘德华出生于1961年9月”，这里mention刘德华只能推断出它是一个人物。类似的，第二个句子“刘德华出演《长城》”，只能推断出刘德华不仅是一个人物，还是一个演员，但歌手这个身份是无法推断出来的。因此，我们的基本思路是分别对每个mention进行分类，然后合并所有的分类结果。

第一个难点在于人工标记代价大。

针对这个难点我们都采用远程监督的方法，把知识图谱中实体的分类结果赋给句子中的mention，这里需要注意的是，远程监督方法能够实现的原因是我们通过上一步基于语义关系特征已经得到了大量实体的分类。没有上一步的话，这一步也做不出来。同样的，基于远程监督的方法会产生很多的噪声，因此我们又需要通过多分类器过滤的方法对训练集进行过滤。

第二个难点也是之前提过的，人工设计代价大。

针对这个难点，我们采用了神经网络模型。这里需要注意的是，我们是要对mention进行typing，而不是对句子进行typing，这就需要在神经网络模型里面明确的告知mention在哪里。因此，我们将句子拆分为了三部分，mention部分，和它的左右context部分，这三部分都是固定长度的，缺了就补0，多了就删掉。最后，将这三个模型分别通过lstm来抽取特征再合并起来。

第三个难点在于简单的融合效果不好。

例如表中的前三种融合策略，分别是取并集、取交集、多数投票，效果都不尽如人意。所以我们提出了一个整数线性规划的问题，在合并的同时，考虑概念与概念之间的关系才进行约束，包括互斥概念不能同时存在，比如人物和建筑，以及概念层次化约束，父概念不为1的情况下，所有子概念均不能为1。

解决了这三个问题，基于文本的实体分类问题也就结束了。

接下来，我们来介绍一下如何对概念进行表示。

概念是怎么形成的这一问题，很早就有人研究了。最早可以追溯到亚里士多德时代，他认为，概念是由一组包含相同特征集合的实体构成的。这组特征后来在Allan Collins的论文中被称为概念的固有特征集合，英文叫Defining Features.

概念的固有特征集合满足两个性质。

1、如果一个实体包括某个概念的固有特征集合，那么它一定属于这个概念。这个性质可以帮助我们做实体分类。

2、如果一个实体属于某个概念，那么它也一定包含这个概念的固有特征集合。这个性质可以用来帮助我们做infobox completion.

在很早之前，心理学家就通过人工的方法为少量的粗粒度的概念定义了它们的固有特征集合，如鸟类、动物、汽车等。然而，这种方法仅适用于概念数量较少的分类，当概念数量上万时，人工方法已经不再适用。因此，我们研究的是，在有了知识图谱之后，如何通过自动的方法，利用知识图谱中的已有知识来表示概念的固有特征集合。

在这之前，我们需要回答两个问题。第一个是哪些概念适合用知识图谱中的关系来表示？概念包括粗粒度概念和细粒度概念。粗粒度概念有“花”，“鸟”，“鱼”，“虫”等，细粒度概念有“周杰伦歌曲”，“香港男演员”等。

很明显我们能发现，知识图谱只能对细粒度概念进行表示，粗粒度概念的特征很难出现在知识图谱中。比如说鸟的固有特征集合包括有羽毛、能飞、有翅膀等。这些在百科知识图谱中都很难出现。

第二个问题是知识图谱中的哪些知识能够用来表示概念？我们根据Allan Collins人工定义的概念的固有特征集合可以发现，可以通过实体的infobox和type信息来表示。

这样的话，我们就能利用知识图谱中实体的infobox和Type信息来表示实体的细粒度概念（标签），上图表中给出了四个例子。当然，需要注意的是，概念的固有特征集合是唯一的，集合中的特征不能多一个，也不能少一个。

由于知识图谱是不完整的，我们无法一次性获得所有概念的固有特征集合。因此，我们提出了一种迭代的方法：先基于统计方法来得到一些概念的固有特征集合作为种子结点，根据这些种子结点生成规则，再利用这些规则来扩展得到更多概念的固有特征集合，有了很多概念的固有特征集合之后，反过来对知识图谱进行填充，新增的知识又能发现更多概念的固有特征集合。依此迭代，直至没有新的知识产生为止。

首先，我们介绍基于统计的方法。每个概念都会包含许多实体，而这些实体的特征集合中肯定都包含了这个概念的固有特征集合，然而，一个实体不仅包含概念的固有特征集合，也包含更多的非固有特征集合的特征。比如实体《Inception》，也就是《盗梦空间》，是概念Films directed by Christopher Nolan的一个实例，它包含了很多特征，其中只有红色标记的才是概念的固有特征集合。

那么，如何从这么多特征中找到概念的固有特征集合呢？一个naïve的方法就是穷举概念的所有可能的特征集合，并计算每个特征集合的得分。打分函数如图所示，主要是两个概率的乘积。第一个概率表示，如果一个实体属于某个概念，那么它将包含这个概念的固有特征集合的概率。第二个概念表示，如果一个实体包含了某个概念的固有特征集合，那么这个实体属于这个概念的概率。当两边概率都为1时，表示特征集合为这个概念的固有特征集合。

当然，这种方法是有缺陷的。首先，由于知识图谱的不完整性，很多概念的固有特征集合的得分都小于1，这些就会漏掉很多概念的固有特征集合。其次，穷举所有特征集合的代价太大了。

针对这两个缺陷，我们分别提出了两种解决方案。

针对缺陷一，我们降低了打分函数的取值。不变要求它的值必须为1，只要是得分最大的那个特征集合就好了。当然，并不是每个概念都能按照这种方法找到它的固有特征集合的，所以我们对得分设置了一个阈值，必须大于这个阈值才行。

针对缺陷二，我们利用了频繁项集发掘的方法来进行剪枝。只计算哪些频繁的特征集合。我们在论文中证明了，只要频繁项集的支持度阈值和打分函数的阈值相同，就能保证非频繁特征集合一定不是概念的固有特征集合。

由于知识图谱的不完整性，很多概念的固有特征集合可能是不频繁的，导致其无法通过基于统计的方法得到结果，因此，我们又提出了基于规则的方法。

基于规则的方法首先是要找规律。我们先来看看这个例子，表中我们已经找到了5个概念的固有特征集合，我们发现，它的规律非常明显，只有红色标记的位置发生了变化，其他部分都是一样的，所以我们第一个猜测就是能不能利用正则表达式来表示一个规则，比如第二张表这样的形式。

但我们后来通过更多的例子发现，这种方法是行不通的。比如我们第一张表的例子，前三个例子能匹配第一个正则表达式，后三个例子却匹配了第二个正则表达式。为什么会出现这种情况呢？主要原因是我们没有对这个任意字符串（.*）进行限定。

当我们将这个任意字符串（.*）限定为特定类型的实体<Agent>,<RecordLabel>时，我们发现，这样总结出来的规则就能很好的匹配上诉的例子了。具体如何对任意字符串进行限定了，我们可以根据属性的值域range来进行限定。

当然，每个生成的规则我们都需要进行评估，评估指标包括支持度和置信度。

有了这些好的规则，我们就可以扩展得到更多概念的固有特征集合了，例如概念Taylor Swift albums匹配了图上的规则，就能推断出它的固有特征集合了。

有了一些固有特征集合，我们就能对知识图谱进行填充了。例如，根据固有特征集合的第二个性质，我们能做实体的infobox填充和type填充。

根据固有特征集合的第一个性质，我们能做实体的细粒度概念填充。

接下来，我们介绍如何将我们知识图谱中的知识与数据源中的知识保持同步。

传统的更新方法有两种：

第一种是基于更新日志的更新，这也是DBpedia的更新策略，因为wikipedia会把每天更新的内容以文件的形式发布出来的，那么知识图谱只要更新这些文件就好了。这是最好的更新方式，但是百度百科没有，你只能去猜到底哪些实体更新过了。

第二种方法是周期性更新，即每隔一段时间，比如说半年重新爬取一遍数据，并进行解析。且不说这种方法代价巨大，时效性同样不能保证。有些知识可能在刚爬取完就更新了，那么它也只能等待下一个更新周期了再更新了。

另外两种是我们提出来的，基于语义搜索引擎的更新。

第一种是之前提到的我们构建了一个语义搜索平台，用户可以通过输入关键字来得到结构化的结果。如果用户觉得这条知识过时了，百度百科上有新的，那么点击更新按钮，我们就会从百度百科上去拿新的内容过来。

第二种是基于搜索日志的新词发现，如果用户搜索一个词时，没有在我们的知识图谱中找到，那么就认为它是一个新词，我们也会去百度百科上看看有没有这个词条。

当然，这两种是在有了一定的流量之后才能做的事情，并且需要用户乐意帮忙才行。

所以我们又提出了一个主动的自动更新方法。基本思路是监控互联网上的热词。热词分为两种情况，一种是新词，另一种是旧词，但信息发生了变化，这刚好满足我们的更新旧词以及增加新词的更新策略，然后，更新热词以及与之相关的词条。

之所以要做实体扩展是因为牵一发而动全身。一个关系发生了变化，会牵扯到很多实体，它们的关系都会发生变化。比如王宝强离婚，不仅王宝强的婚姻关系变了，马蓉的婚姻关系同样也变了。

所以，整个更新框架就是这样，先发现热词作为种子结点，更新这个热词，再从热词的页面中，扩展得到更新的实体。重点是，到了这一步并不是马上更新这些实体，因为一扩展实体的量就上来了，我们根本更新不了这么多的实体，并且并不是每个实体都发生了变化，所以我们对每个扩展实体设置了一个更新优先级，然后根据这个优先级来进行更新。