北京大学在图数据库和知识图谱上的探索与实践

知识图谱是一种新的数据组织管理的模式，以前大家见得比较多的就是Excel或者关系数据库，用行和列的方式存储、管理、组织数据，知识图谱是一种图的方式把数据划为点，数据和数据之间的关系以边的方式描述，更多表示的是实体和实体之间的关系。

为什么说这几年知识图谱很火热？大数据时代很多人都会说有多少特性，其中有一个Value就是价值是不可忽视的。大数据的价值很重要的一个方面就是体现在数据和数据之间隐含的价值，需要去挖掘、去分析，所以在大数据时代知识图谱是一个很热的研究领域。

上图中左边是用文本的方式描述詹姆斯瓦特的相关信息，除了以这种文本的方式以外，我们还可以以右边图的方式描述。这样的好处是我们能够做知识的推理，包括归因分析、关联度分析、路径检索、重要性分析等等，可以做很多的工作，以知识图谱组织管理数据有它的优势。

知识图谱在Google的智能搜索出现得比较早，现在大家搜索北京大学的词条，不再像以前基于文本关键字的匹配方式。

除了在搜索领域，社交网络也应用得比较多，比如Facebook的社交网络，不仅能根据文章标题搜索一篇文章，现在还能够搜索在加拿大的朋友有哪些，不光是把这个问题作为一个关键字到Facebook的数据库去搜，而是把内容解析为搜索树，从而实现基于知识图谱的检索。可以把图像识别和知识图谱的检索融合在一起，从而做更加智能的检索，在图片里就可以看到哪些是住在加拿大的朋友。

“知识图谱”这个词出现得不是特别久，大概是十年左右，但“知识”这个词出现得很早，比如专家知识库、知识工程或者专家系统，其实是一个传统的知识工程。以前做专家系统更多是通过关系型数据库，以二维表的方式存储数据和数据之间的关系。目前做知识库或者知识图谱系统更多是以图的方式来做。

简单来说知识图谱就是以图的方式描述数据和数据之间的关系，整个生命周期划分为三个阶段：

第一阶段是知识图谱的构建。如何把一个传统的数据，比如关系型数据库的数据或者Excel表格的数据，甚至是文本数据转化为点和边的数据。

第二阶段是知识图谱存储与管理。数据其实会膨胀很多，假设一张表有10万行，每行10个字段，初步估计形成三元组（以三元组为例）将会是10万乘以10的量，所以数据的膨胀是非常快的，意味着构建的知识图谱数据的量，很容易突破百亿千亿规模，面对如此海量的知识图谱数据，如何存储和管理是需要重点解决的问题，涉及到图数据库。

第三阶段是知识图谱应用。花了很大功夫把知识图谱构建出来，又花了很大资源存储和管理，要是不去用的话这个东西就没有意义，所以知识图谱的应用环节是整个知识图谱生命周期价值点的体现。各行各业应用场景很多，一般情况下都是可视化的知识图谱的检索或者溯源，包括路径分析、聚类分析等等，其中有一个比较通用的应用就是知识图谱的智能问答。

知识图谱全生命周期三个阶段都有一些挑战，其中难度比较大的是最开始的知识图谱构建。比如，现在有一本《红楼梦》，要从里面把所有人物的关系查询出来，其实这是很困难的事情，在这本书里面出现了很多名词，有些可能是人，有些可能是动物，有些可能是建筑物，如何把实体类型识别出来是很关键的，第二个，实体和实体之间的关系也很重要，这是非常难的一个事情。

详细介绍一下我们知识图谱构建的方案和探索。

知识图谱在RDF的数据模型基础上，RDF本身是一个Free Model，就是主谓宾三元组数据，本身是无模式的，不像关系数据库需要先设计表结构，都有表和字段。

传统的RDF数据只要满足主谓宾的形式都可以往里面塞，但是在实际应用过程中往往还是会先设计一个本体，就是对知识图谱Schema进行设计。虽然从技术和RDF的要求来说不是必需的，但我们认为在整个项目里是贯穿始终的，能够很容易给别人展示里面到底有什么类型的实体，实体和实体之间的关系、什么属性等等，所以知识图谱Schema是贯穿整个知识图谱的生命周期，后续的应用过程中也需要基于知识图谱的Schema进行查询、分析等等。不管是用哪种语言查询都需要知道谓词，所以对知识图谱Schema的设计是很重要的。

国外有一个工具Protégé，功能还是非常强大的，当然也有一些不足的地方，比如描述数据和数据之间、本体和本体之间的关系主要以树形结构描述，更适合上下级或者父子关系，但是平行关系这种非隶属关系相对比较难描述，比较难直观地表达出来。

我们北大团队从2020年就开始构建gBuilder平台，gBuilder是北京大学王选计算机研究所数据管理实验室历经两年研发的知识图谱自动化构建平台。通过结合NLP技术、机器学习、人工智能、知识图谱、图数据库等众多技术，打造的一个针对结构化数据和非结构化数据的知识图谱自动化构建平台，实现数据向知识的转化。

gBuilder平台其中有几个关键功能和模块：

1、Schema设计

其中一个是可视化Schema设计，gBuilder提供了可视化的、轻量级的知识图谱Schema设计功能，用户只需要简单的拖拽就可以完成知识图谱Schema设计（本体设计），同时还支持Schema的导入和导出。其中还有一些限制条件，比如数据类型、最大值、最小值等等。

通过一些项目的实战，我们也发现Schema设计跟关系型数据库设计、ER模型设计非常类似，没有绝对的正确和错误，但一般要考虑如下几个方面：

2、知识抽取

二是知识的抽取。其实知识的抽取主要目标就是把已有的数据转化为属性图数据、点边数据或者RDF三元组数据，重点和难点在于文本信息抽取，需要解决刚才说的实体识别、实体消歧、关系抽取和事件抽取等一系列问题。国外的机构基于开放的数据集其实也做了大量的工作，形成了一些大规模的数据集，比如Yago、DBPedia和FreeBase。

知识图谱的知识抽取流程在gBuilder平台如上图，面向结构化知识抽取采用的是左边的流程，非结构化知识抽取采用的是右边的流程。当然，不管是结构化数据还是非结构化数据都需要经过知识图谱Schema的设计，后面还会进行知识融合，包括实体消歧、数据消歧等等。

结构化数据的知识图谱构建相对来说比较简单，核心问题就是把关系型数据库的二维表数据和Schema进行映射。可以用开源工具D2RQ，将关系型数据库数据转化为RDF三元组数据。

整个转化非常简单：通过Generate-Mapping命令可以生成一个Mapping文件，描述数据的源头，字段和Schema的映射关系。然后把Mapping文件从数据库中抽取出来形成RDF三元组数据，使用起来非常简单，三条命令就可以解决问题。当然也有缺点，使用这三条命令只能实现一些基本操作，更高级的操作需要修改Mapping文件，需要用户具有比较专业的知识，比如对Mapping文件的语法比较了解。

gBuilder平台在结构化数据抽取方面其实是基于D2RQ，我们主要解决的问题就是可以全程可视化的方式将Mapping文件编辑的过程进行映射，包括数据库的连接、关系表和实体的映射、关系表和谓词映射都可以通过可视化的方式实现。

目前gBuilder 2.0支持MySQL、Oracle、SQL Server、PostgreSQL等主流数据库，以及一些国产数据库。

真正的难点在于非结构化数据的信息抽取，属于信息抽取领域的核心问题。

举个例子，布朗出生在美国首都华盛顿，这句话其实蕴含着很多信息，比如布朗这样一个人的出生地，包括出生的城市，城市和国家都存在什么关系。这里涉及很多技术，命名实体识别，比如这是一个人、城市或者国家。关系抽取，人和城市之间是关系，人和国家是关系，城市和国家是关系。

命名实体识别的方法有很多，比如基于规则的实体识别方法，中文人名的识别比较简单，不考虑少数民族名字的情况下，汉族基本都是姓氏+名字，中文的地名如北京市、重庆市等比较规整，有些规律可循的方式。当然也可以基于机器学习的方式识别，比如最大熵模型(Maximum Entropy Model) 和条件随机场模型(Conditional Markov Random Field)。目前，命名实体识别当然还有提升的空间，但整体上准确度还可以，基本达到90%以上。

难点在于关系抽取，刚才我们识别出布朗、华盛顿和美国三个实体以后要对实体之间的关系进行判定，所以这是一个困难的事情。我们有不同词汇的表示方式，比如你、我、他这种指代消解，上文指的是“刘德华”，下文可以讲“他”，所以如何结合上下文实现指代消解是非常困难的。

刚才分析的是非结构化数据本身的构建存在众多技术挑战，本身就有很多技术难题没有解决，也不可能以一个通用的系统覆盖所有的非结构化数据抽取的功能。

我们希望有这样的一个系统，能够有效地从非结构化文本中抽取信息，自动构建知识图谱；可以引入最新、最好的学界或业界的工作，提升图谱构建的准确度；可以在多个领域中进行迁移；无论是从事知识图谱的专业人士还是小白，都能轻松使用；提供可视化的低代码/无代码的知识图谱构建流水线设计工具。

基于这些目标，我们在gBuilder中朝着这些方向努力发展，比如gBuilder 2.0系统提供一个可视化的、非结构化流程构建的模块，系统内置了很多工具箱，包括模型库，比如实体抽取、关系抽取、粘合抽取，用户可以根据自己数据的特点选择合适的模型或者工具进行信息抽取，可以理解为这是一个生产平台，特别是模型库有一个模型中心，其他用户可以把好的模型通过模型中心注册进来，这是一个不断成长、不断完善的系统。

我们会把这样一些模型不断地向公众开放，比如做命名实体识别的，可以把模型注册进来，跟其它关系抽取的模型进行匹配，看一看是不是二者组合能够很好地把信息完整地抽取出来。除了解决实际的问题之外，gBuilder更重要的目标是希望能够打造在信息抽取方面的实验平台或者研究平台。

知识图谱的数据会膨胀得非常大，如何存储和管理数据？其实有两种方式：一种是关系型数据库，把数据以行和列的方式存储，以前做的专家知识库都是按照这种方式。另一种是采用图数据库的方式存储知识图谱的数据。其实优缺点非常明显，以表的方式来存数据，最重要的问题就是数据之间的关系是以外键的方式描述，肯定需要大量的连接操作。

之前我们做过一个对比，同样100万的数据，假设每个人用10个社交关系，1个人5跳的社交关系，关系型数据库直接就崩溃了，但用图数据库仍然可以保持在秒级甚至毫秒级，对性能影响非常明显。

知识图谱的数据模型有很多种，目前主流的是RDF三元组数据，此外还有RDFs、OWL等等。RDF是我们重点介绍的，因为我们的系统就是基于RDF的数据模型，属性图模型也可以用来存储知识图谱的数据。知识图谱和图数据库是不能划等号，但图数据库是知识图谱的一个很好的存储介质，这是毋庸置疑的。

gStore是由北京大学王选所数据管理实验室研发的，面向RDF知识图谱的开源原生图数据库系统（通常称为Triple Store）。不同于传统基于关系数据库的知识图谱数据管理方法，gStore原生基于图数据模型(Native Graph Model)，维持了原始RDF知识图谱的图结构；其数据模型是有标签、有向的多边图，每个顶点对应着一个主体或客体。我们将面向RDF的SPARQL查询，转换为面向RDF图的子图匹配查询，利用我们所提出的基于图结构的索引(VS-tree)来加速查询的性能。具备源头创新、自主可控、实战部署、性能卓越等优势。

我们团队提供gStore图数据库、gBuilder知识图谱构建、gAnswer智能问答引擎、gStore Workbench可视化管理查询平台、gMaster分布式gStore管理系统和gCloud开箱即用的gStore云服务平台一系列生命周期的产品栈，打造了知识图谱一体化解决方案。

知识图谱很重要的应用场景就是知识关联分析，目前重点是在政府和金融领域。我们主要是构建以股权关系为主的企业股权知识图谱，通过这种方式可以对企业股权关系进行穿透式查询，就是一查到底，一次性获得企业完整的股权架构，我们压力测试可以做到43层以后。通过穿透式分析查看有没有交叉持股、循环持股等特殊关系。

介绍一下几个心得体会：因为我个人最开始是做图数据库的，参与了gStore核心代码开发，我觉得图数据库至少在国内跟关系型数据库有相同的地方，机遇和挑战并存。目前跟国外的图数据库差距不是特别大，更多的可能是在产品化方面。

目前仍然存在很大挑战，一个是标准不统一，比如RDF数据和属性图数据是两大阵营，属于百花齐放，关系型数据库基本都是基于SQL标准。目前我们有些商业化的部署，更多的是跟企业合作，如果直接进行知识图谱或者图数据库的商业化合作，其实在很多领域是很困难的。举个例子，把一个图数据库卖给别人，别人不知道用来干嘛，我见过一些企业买了国外的图数据库好几年都没有安装。目前客户更希望用图数据库解决实际问题，金融领域的风控、保险行业骗保问题，需要一个解决方案，数据如何转变为图数据存储，以及如何做图计算、图分析、图查询。

我们在这个过程中需要经常跟客户碰撞应用场景是什么，知识图谱或者图数据库很大层面是属于数据分析或者数据挖掘、数据增值服务，按照一个传统流行的广告语，不是数据的生产工，而是数据的搬运工，我们更多关心的是明细数据或者规则数据。应用图数据库要找到合适的场景，发挥图数据库的独特优势，尤其凸显关联关系分析的优势。比如要在社交网络中找1个人的5跳关系，关系型数据库做不了，如果所有查询都只是1跳查询使用图数据库的意义也不是特别大，因为可以根据关系型数据库的索引直接得到结果。场景很重要，知识图谱或者图数据库更多的是监管职能的关联分析，包括溯源情报和规律分析等等。