浅谈知识图谱“数据生态”建设

浅谈知识图谱“数据生态”建设

前一阵，企业与一家科研机构合作，研发一款所谓“XX人物知识图谱”的产品。领导声明要把它打造成未来公司的“拳头”产品，要以合作打响名气，并对合作中的一个细节进行了约束——“不要应用”部分，因为“没有人需要那些数据的展现，就连BAT的大厂都不卖这个东西”，“厂家需要的是一个数据产品”。因为前一阶段为了想要自研知识图谱产品，所以进行了一些自认为比较“深入”的研究，实践并踩了一些坑，发现“领导”和大部分技术人员对知识图谱及其应用有一些误解，特别是其中我自称其为“数据生态”的部分，基本没有概念。下文要阐明的观点自是一家之言，但鉴于知识图谱在业内还没有特别成熟的产业框架，姑且作为一点思路来警醒那些以为知识图谱是另一种东西的“那些人”吧。

[if !supportLists]一、[endif]当前知识图谱建设的现象（现状）

正如我们的“领导”们的概念中知识图谱的丑恶面貌一样，我们来说说这些自以为是的奇怪想法：

[if !supportLists](一)[endif]知识图谱本身是一个应用

知识图谱是知识存储的空间，有一点像数据库，用它来做什么样的应用，要看里面放了什么数据，而不是有了数据库就可以做应用了。同样，用知识图谱做什么样的应用，要看里面放了什么知识。

在各类人工智能文章的“轰炸”之下，我们有时会把一些开放域知识图谱当成是万能的应用，一说就是里面保存了n亿个事实，像是一个问什么都知道的百科全书。对，像是百度百科。这是一个白马非马的悖论，百度百科固然是一个很大的知识图谱应用产品，但并不是知识图谱就是百度百科那一种样子。但从有限的眼见为实的认知里，知识图谱常被等同于一个百科全书。

当然，我们本来为了迎合这种想法，作为应用也想先搞一个所谓“背景知识”展示，仿照百度百科来提供一个简单的“SQL查询”。领导仿佛也看穿了这个思路，否定这种做法，进而直接把“应用”取消。这让我们很困扰，一个保存了数据的数据库，设计了数据结构，但没有应用，可不可以用来直接支持未来不可知的“应用”。试想，一个自认为满腹经纶的才子，让他去带兵打仗，能干好么？所以，我认为很先有业务需求，才有可能来造知识图谱，那些开放域的图谱，一定不适用于垂直领域下的业务需求。

[if !supportLists](二)[endif]知识图谱是一个可以移动的黑盒子

知识图谱是一种一次性产品么？像铁锅，一但造好就可以使用了，直到用坏了，中间没有什么变化了。像是在说，我们做了一个“红楼人物知识图谱”，《红楼梦》是成型著作，不会再变化了，那么我们的知识图谱就可一直应用下去。这是被网上的程序员的知识图谱“实践”给骗了，看起来十分合理，但细想一下，业务环境下的知识图谱，绝不是一本书这么小，这种实践充其量是我所理解的知识图谱的一个环节。真正的业务环境下的知识图谱是不断更新积累的，可以适应数据流转，是具备“数据生态”的动态服务，所以它不是一个可以移动的黑盒子，而是一系列生产体系，像是人类的头脑，一边学习，一边工作，如果不学习了，那一时间还可以应付，但时间一长就下岗了。

回头说这家科研机构，绝口不提什么更新过程，只说帮着训练抽取模型，圈定一个小范围，灌到图谱中就完事。从出钱的情况、卖东西的角度和领导想要看的效果来说，确是就行了。像是学生上了那么长时间学，毕业之后就上班，还要充什么电，按部就班地干就好了，如果未来业务变化了，就让他下岗，再招人就好了。甚至，领导提出不要让他们学那些“高档的东西”，要不学会了就跑了。这个奇葩思路，让我想起了《资本论》，这些我就不多讨论了，毕竟我自己的“高度”不够，“做企业就得这样才行”，“你不怎么怎么样怎么能怎么怎么样呢？”

[if !supportLists]二、[endif]为什么要建设知识图谱的“数据生态”（必要性）

建设知识图谱的“数据生态”是生产环境下使用知识图谱的需求。根据《知识图谱标准化白皮书（2019）》中所描述，至少会有：基于增量数据的知识运维、图谱内容统计监控、知识审核与修正、知识版本管理、知识安全管理的内在需求。大致思路说来，就是说一个工厂并不是只要有机器就可以了，要有一套动作体系，怎么保证安全，怎么控制成本，怎么运行维护，怎么安排人力等等，完全符合常识。

建设知识图谱的“数据生态”是产业化的要求（方法论）。一个企业是不是想发展，是不是想从一个厂房变成多个厂房？那就需要有迁移能力，特别是管理体系的迁移。那么知识图谱的“数据生态”，不光是一个项目的生态，更是一套概念模式，需要抽象总结再演绎细化的过程。

建设知识图谱的“数据生态”是结合前沿技术发展的必要条件。未来技术的发展会越来越快，新技术的加入必然会对原有架构有所冲击。“数据生态”的概念通过架构级模块自治来应对这种变化，原料供给、各环节机器生产、成品销售等等之间都以接口衔接，更新更换其中的一部分，只要仍符合接口规范就可以使用。这样，未来就能不断结合新技术替换原有技术，甚至混合使用新技术。

[if !supportLists]三、[endif]“数据生态”概念架构（需求、概念）

[if !supportLists](一)[endif]对“数据生态”的需求

引用《知识图谱标准化白皮书（2019）》的描述：

1.知识图谱的全生命周期质量保障

具备知识运维能力的知识图谱平台主要功能宜包括：本体的构建，针对多种数据来源的结构化、半结构化、非结构化的数据类型在不同的技术下的知识获取，实体识别、关系识别、实体链接、实体属性抽取的实现，基于本体概念和实体知识图谱间的验证，构建流程与运维过程的监控，对知识图谱构建过程中的各种异常情况的记录和反馈，对入库知识图谱的人工审核。此外，通过在知识图谱平台的知识库以版本的形式进行管理，避免知识运维中因为新知识的错误发布对现有业务的影响，提供给运维人员上线发布前的质量检测方法，并将经过严格测试验证的知识图谱版本正式生效上线，最终保证知识图谱全生命周期各环节的数据质量。

2、多知识图谱的运维管控

此外，面向按照不同领域和范围下多个知识图谱的构建和运维，有待开发一套完备的平台对多个不同知识应用提供支撑。该平台本身需具备完整的安全管控及权限管理，并可满足动态本体的多人协同构建、冲突检测及讨论确定统一的版本的机制及功能，最终可对外开放给上层应用，提高应用的智能化。同时，通过应用的使用记录及问题反馈带动知识图谱的运维优化，形成闭环全周期的多知识图谱间的运维管控。

[if !supportLists](二)[endif]概念架构

根据上面的需求，结合我们已有实践，暂时不包含图谱的设计和监控部分，未考虑多图谱管控的情况，粗略设计如下：

[if !vml]

[endif]

[if !vml]

[endif]

图  1数据生态概念架构

运行流程如上图：（1）数据服务平台接入采集和采购数据，调用人工智能标引服务进行数据标引，并根据指标计算得出未识别的实体基础数据；（2）利用人工智能抽取引擎进行实体抽取，利用远程监督服务辅助实体对齐消歧，再用实体对齐消歧服务进行实体识别，初步得到实体基础数据；（3）可由人工录入、远程监督发现和实体识别得到实体基础数据，再将这些基础数据关交人工监督平台验证；（4）人工监督平台对数据进行人工监督和标注，一方面将验证过的实体基础数据保存到知识库，一方面将标注（特别是修改过的）的原始数据生成训练标注语料送训练平台；（5）训练平台利用训练标注语料重新训练机器学习模型，并更新当前线上的抽取引擎以提高精度（反馈）；（6）知识库将实体基础数据进行知识融合，保存知识到知识图谱（特指图数据库）中，并形成实体链指；（7）知识图谱对外提供知识计算服务，支撑类似搜索推荐和基于图谱的问答等应用。

“数据生态”的参与者可以分成五个角色：知识运维管理员、数据审核标注员、服务管理员、人工智能调试员和数据运维管理员。

[if !vml]

[endif]

图  2“数据生态”参与者角色

[if !supportLists]四、[endif]“数据生态”建设面临的挑战（重点技术）

这里不提知识图谱（特指库数据库）问题，因为它由定型产品来完成，不需要也没什么能力去改变它。在此之外，需要重点关注的部分应该有以下几方面：

[if !supportLists](一)[endif]信息抽取

信息抽取是知识抽取的关键步骤，可以分为实体抽取、实体关系抽取和属性抽取。在技术上，传统的机器学习、基于规则抽取和深度学习抽取都有相应的开源工程。理论上基于规则的抽取准确率高但召回率低，但需要大量人工配置规则；深度学习基本替代了传统机器学习，召回率高但准确率低，且与是否有足够的训练语料保证、分词质量、训练调参等有关，不确定性高。所以，应当考虑两种方式相结合的模式，还要考虑随着时间变化更新训练模型的问题。这里将语料、训练等深度学习的部分统一归到一个训练平台的工程上来。训练平台相对功能自治，主要形成语料管理、数据预处理、训练管理、模型管理为一体的自动化/半自动化训练平台，可以以业务需求和时间演进训练和应用模型，以达到随时、随需的人工智能数据加工功能。

[if !supportLists](二)[endif]实体识别

命名实体识别(Named EntitiesRecognition，NER)，就是识别这些实体指称的边界和类别。在开源项目中常能看到NER的身影，无论是基于规则的还是基于深度学习的，甚至直接用一些现成库来实现实现。但这里所指的实体识别更多是指实体对齐和实体消歧两个功能，不但要指出哪个词是实体，还要确实地得到准确的实体（例如实体链指）。实体对齐是指一个实体有多个表述词，例如：特朗普和川普其实就是一个实体的不同表述词。实体消歧是指同一表述词根据上下文可以指向不同的实体，例如：王东明到水利部视察，这里的王东明是指人大副委员长王东明，而不是指辽宁第二巡视员王东明。由于并不是每个文本中的实体都需要用到实体对齐和实体消歧进行判断，从而确认实体，例如基于关键词的搜索，所以之前的自然语言处理工程中往往忽略这一模块，但知识图谱是以实体为基础的，也就是说知识的基本单元是基于实体的（我把事件也看成一种实体），所以实体识别就变得至关重要。如果缺少这一步骤，后面的知识计算就可能在一个错误的基于上演绎出更错误的结论。也有一种思路，是由人工来确认所有实体，这一方式成本很高，我们在后面人工监督部分再讨论。

[if !supportLists](三)[endif]人工监督

在人工智能的基础数据或是模型训练方面，人工监督是不可或缺的一部分，后期无论采用众包的模式还是单纯的人工审核，都需要一个平台来进行支持。传统的人工审核没有智能化的辅助，只是单纯的人员操作，效率比较低。而现在的人工监督平台，不但要能以众包的模式进行灵活的上线下线、投票机制、模板机制，还要能进行人工智能的辅助，让大部分监督从填写变成判断，大大提高效率。人工监督（或者数据标注）是一个新兴的市场，功能上也可以完成自治，甚至以外部第三方模式引进。

[if !supportLists](四)[endif]远程监督

远程监督实际就是利用一些开放成型的数据资源来丰富自己的数据。一方面，我们可以像“拿来主义”一样，直接引用别人的结构化数据对自己的数据进行判断；另一方面，我们的知识图谱从某种意义上也可以提供这种远程监督，反过来作用于信息抽取、人工监督等模块。此外，它也可以是数据更新的一个来源。但是不是所有“拿来”的数据都可用呢？这其中就有远程监督源自身的可信性、数据及时性、数据结构差异以及错误传播等因素，在后面的初步尝试部分详述。

[if !supportLists](五)[endif]数据更新

“数据生态”的核心就是数据的动态性，所以数据更新是要解决的关键问题。这其中，基于不断流入的数据进行分析从而得到的类似事件实体的动态数据，像是工厂不断生产的产品，是比较容易做到的部分。另一类，实体基础数据的更新，像是工厂的机器的更新，是比较困难的部分。更新触发源可能包括：手工录入模式的更新仍是一种选择；此外可以考虑由大数据计算“热词”，再与已有实体比较，补充新实体；利用远程监督，当监视远程数据资源发生变化时，监督自身数据是否也要随之变化。当然，如果有固定更新源就更好了，例如：违纪官员由中纪委网站发布，用爬虫爬取最新文章并分析，会比较准确，也就是垂直领域最好的更新方式。

[if !supportLists]五、[endif]初步尝试和未来想法（实施和展望）

[if !supportLists](一)[endif]数据服务平台建设（数据流程控制）

早在一年半之前，先入手的大数据平台建设，在这之中，有关数据流程控制的部分显得十分重要。相关的主要包括：kafuka的数据接入和流转消息队列，实时和离线计算部分，数据流程配置管理等部分。这样就具备了一个数据流转的底层，后面再搞什么计算还是推送都不需要太考虑数据流转问题了。

当然，这部分的可视化配置，还需要再慢慢开发。所谓监控，一部分是监视状态，一部分是控制。所有数据任务的统筹管理可以与具体的业务能力解耦，这也有助于未来实施多个图谱任务，以及多个图谱任务之间相互数据交换的更复杂的业务构建。

[if !supportLists](二)[endif]基于BERT的信息抽取

由于预训练的深度学习模型已成为当前人工智能的一大主流，且经过一些实验确实比普通的机器学习和自己训练的模型要好很多。特别是网上一些开源项目，已经规模化应用类似BERT这样的模型框架来形成服务，我们在这里也做了一定的尝试，后面将加大这部分的比例，结合规则引擎，综合提高实体抽取、事件抽取、实体关系抽取、事件关系抽取等信息抽取的准确率和自动化程度。

[if !supportLists](三)[endif]对齐消歧算法

现有的对齐算法以流行的同义词模式为主，辅助以知识图谱中的别名。消歧算法以关键词向量组之间计算相似度为主，辅助以对一些实体词的加权。这里可尝试的地方还有很多，例如结合知识图谱，利用实体属性和实体关系进行消歧，可以进一步调优。

另外，现在把候选的消歧实体放到了图谱之外，也就是计算消歧时并不同图谱中进行计算，这种模式从某种意义上处理了消歧与知识图谱之间的耦合，但也使得知识图谱的计算不能直接地一次性完成，而要分阶段进行，暂时没有应用实例来证明那种方式更合适。

[if !supportLists](四)[endif]远程监督平台

远程监督是平台化模式接入，完成缓存、验证更新、多源监督等工作。当前，只用了百度百科的数据，也试验过其它百科类API或引擎，效果明显不如百度百科的好，一方面是不准确，一方面是更新不及时。当然，面对垂直领域如果有更准确和实时的结构化数据或API的话，就更好了。所以，这里把远程监督平台独立出来，抽象化它的功能，以应对未来在这个地方的改进和更新。

[if !supportLists](五)[endif]人工监督平台搭建

人工监督平台其实是一个任务处理的众包平台，真正监督或审核的界面采用模板化架构，应需求配置不同的模板，这里主要参考pybossa和doccano两个项目。将人工监督做成一个单独的业务（甚至数据标注公司），其中结合越多的人工智能技术（图像标注中的人脸识别、语义划分等），效率越高，成本越低。

[if !supportLists](六)[endif]图数据库及数据展示

在知识图谱的探索过程中，也没有什么经验，先使用了neo4j这种大众化工具，由于应用部分的实践还不多，暂时体现不出哪种图数据的效果更好。有点像ORACLE和MySql的使用，只是SQL语句查询，也看不出两个数据库有什么差异，只有用到深处才能有所区别。而当前的需求来看，一个是存储数据总量，一个是查询效率（特别是复杂查询），这就要求分布式和图数据库自身的性能，暂时还没有考虑过多的图数据的功能问题。