技术思考：一片繁荣与满地鸡毛的知识图谱技术落地冷辨析

以下文章来源于老刘说NLP

一、前言

无知识图谱，不AI。

一片繁荣下，满地鸡毛。

当前，知识图谱无疑是处于一个理想却很难落地的一个现状，大公司、小公司都在寻找知识图谱的落地场景。

无论是2C还是2B，还是2G，产品经理们都在知识图谱与具体业务的结合点。

“对内唱衰务实，对外吹PPT务虚”，这一模式在知识图谱实际从业者们的认知里，应该占据了大多数比例。

“知识图谱是上级意志，是优先战略，抢战略高地，挣行业影响力”，也真实体现了当前知识图谱在公司【尤其是大公司】的战略定位。

与职场中的”面试造火箭，工作拧螺丝”类比，”汇报标准化解决方案，开发洗数据造词典写规则”的项目制知识图谱开发模式， Demo级演示工具也覆盖了太多数从业者的实际现状

然而，当我们搜索知识图谱这一关键词时，我们总会看到一片繁荣的景象，不断有新的深度学习模型出现、更多门类的知识图谱技术突破，不断刷新记录的评测榜单。

但在这个繁荣景象的背后，在我们看到其真正落地情况，看到实际工作者的日常工作之后，我们需要静下心来想一想，知识图谱这种过火状态，是否真的配得上？这种技术是否也真的像报道写的那样“通往认知智能的语义基石，下一代人工智能的大脑”。

本文顺着这一问题展开论述，从知识图谱本身的技术特性进行冷思考，从知识图谱系列技术的不成熟、对数据的贪婪与敏感性，并对选型落地进行论述。

本文只谈清醒认识，人间清醒，辩证的看。

二、知识图谱系列技术的不成熟与解释性

1、知识图谱对知识的抽象下的技术不成熟

知识的准确性、实时性、全面性是实现知识图谱应用的几个根本前提，如果忽视知识图谱数据准确性的情况下冒然进行应用，会给某些敏感领域（医疗领域、金融领域、公安政务领域）带来巨大的灾难。但究其根本，还是以“二元一阶谓词逻辑”作为知识表示的本身缺陷带来的。

一方面， 完全依靠（头实体、关系、尾实体）这样的命题，尽管能表示大部分简单事件或实体属性，对于复杂知识却束手无策。

另一方面，知识图谱对实体太过于抽象带来了自然语言处理许多麻烦，得到准确的知识图谱数据，并非易事，因为当前自然语言处理技术在无人干预的信息抽取上还无法达到100%的准确率，实体识别和实体关系抽取算法性能较差，尤其是对复杂异构文本等处理上带来的困难。此外，知识图谱这种三元组表示方法丢失了大量的上下文信息，这也给实体链接、实体对齐等任务和应用上带来了一定的困难。

因此，综合知识图谱自身的局限，直接造成了真正应用落地下知识图谱的尴尬境地，纵观现有的知识图谱应用，受限于知识图谱所耗费的代价、现有知识图谱技术瓶颈、国内数据生态发展不平衡等多个问题，虽然从提出到现在知识图谱已经得到了快速的发展，但目前知识图谱可视化占据了知识图谱应用的现象。

一方面，知识问答需要依靠大规模高质量的知识三元组数据，以及大量的规则模板进行约束引导，大规模成熟、成本适中的知识图谱问答产品还并未出现；

另一方面，由于知识图谱对知识的要求较高，而技术发展和数据基础设施并不完善，领域性的知识图谱抽取大规模运用还存在诸多问题， 标准化的知识图谱生产平台还难以推广，人机交互+大规模人工干预方法的领域不可复制的知识图谱建设思路仍占据绝对优势。

2、知识图谱的可解释争论

知识图谱作为一种可解释的标签出现在近年来也是呼声较高，但细究起来，我们可以发现，知识图谱是可解释是相较而言的，站在对立面的深度学习模型常常成为被吐槽的对象，由于内部是复杂的神经网络数值运算，从中学习到的系数或值缺少实际的物理意义，从而被认为是不可解释的，因为缺乏形式化（这也催生了关于深度学习模型可解释的相关研究工作）。

从概念上来说，“可解释”本身就是存在主观性的，如果以“眼见为实”的观点来论述，那么知识图谱确实可以站得住脚。 对于人类而言，人类只认识符号，可解释性不能回避符号知识，而人类进行解释的过程，是运用概念、属性以及关系进行推断的过程。

例如，在对未知实体的结果推理过程中，总可以通过形式化的实体关联信息作为一种路径来解释，这种路径与人类大脑进行认知推断十分相似。

例如鸟能飞，是因为它有翅膀的属性， 鹿晗出事时关晓彤的名字总会出现在新闻报道当中，这是因为两人之间存在着恋人关系，在搜索香蕉时，搜索系统总能推荐出苹果、西瓜，因为他们都属于水果；图像识别分类问题时，也可以通过知识图谱的方式，对图像中的部件进行拆解作为可解释基，例如判断出一个人的照片时，能够将人头、四肢、眼镜等部件进行解释。

不过，当前将知识图谱与深度学习相结合，在进行知识推理任务上，大量不同的关系上很难定义逻辑规则，在知识图谱上“推理” 也转入黑盒模型预测的范式，这种方式也无疑要受到重视。

3、知识图谱作为知识表示没有解决的问题

知识图谱只是知识表示的一种，单单知识图谱不足以表达现实世界的丰富语义，不足以解决所有问题。比如很多领域有着丰富的if-then规则（比如故障维修、计算机系统配置），这些规则利用知识图谱表达就很牵强，特别是对于if A and B then C这样的复合规则。条件部分的原子表达式之间的关系可以很复杂，利用知识图谱难以表达。

三、知识图谱本体的主观性与数据贪婪性

1、知识图谱Schema定义的主观性

知识图谱的抽象性催生了知识本体构建、实体识别、实体关系抽取、实体属性抽取等技术，并且对这些技术提出了很高的要求。而知识图谱schema这个东西表现的最为关键，在实际的知识图谱构建过程当中，知识建模都是第一步也是最重要的工作。

对于一个从无到有进行知识图谱构建的人来说，是个十分头疼的事情，无论是业务人员，还是技术人员，都存在诸多困惑， schema是对领域或者行业知识的一个高度抽象化建模，是个十分耗时的过程。也正是因为这个原因，知识架构师，知识产品经理会成为未来知识图谱的一个十分必要的工种，技术人员用技术的方式去学习生成图谱的schema，难度比较大，并且也不一定会为业务人员买账。

一方面，知识图谱要求对领域内的数据进行抽象建模，这一步相当难，尤其是刚入行不久的业务小白，构造一个标准的知识本体都很难。 业务人员需要需要了解什么是主体、客体、有哪些实体类型，什么是属性，属性关系和实体关系怎么去区分等等，这个既需要了解细节的业务，也需要将业务进行抽离、抽象，这个对于业务人员来讲是很难的。

构建一个尽可能可用和完善的知识图谱本体，存在两个基本难点，一个是对业务的梳理或者说理解，既需要有跳出来的宏观把控，只有跳出来才能尽可能地建模场景元素，也需要对细节的把控，针对不同的需求，如问答、检索等，制定不同的本体，这个要求比较高。

另外一个就是动态的schema的问题，schema的版本都会一直变化，根据业务变化，也会根据自己对业务的认识而变化，如何尽可能地减少这种变化，也是一个难点。

2、知识图谱的数据贪婪性

知识图谱的强大不在于信息的详尽，而在于信息的穿透（或者关联）。知识图谱作为一种“大而全”的数据，数据的增量部分是很少的，大部分数据是对已有数据的再组织，成果就是由“多源异构数据”转化为统一的schema，不过，数据的质量以及数据的缺失，会直接影响知识图谱应用的效果，这就是经典的“知识图谱完备性”问题。

冯诺依曼曾估计单个个体的大脑中的全量知识需要2.4*1020个bits来存储。客观世界拥有不计其数的实体，人的主观世界更加包含有无法统计的概念，这些实体和概念之间又具有更多数量的复杂关系，导致大多数知识图谱都面临知识不完全的困境。 在实际的领域应用场景中，知识不完全也是困扰大多数语义搜索、智能问答、知识辅助的决策分析系统的首要难题。

以金融领域股权知识图谱为例，在构建其schema时，可以清晰描述出了企业核心信息，如覆盖公司、产品、行业、概念、地域，甚至资讯、研报、事件、指标等实体，股权关系为、产业链上下游等。但如果实际获取到的数据，并不能够有效地填充这个定义好的Schema，如形成的实际实体关系只有1、2度的深度，那么这个图谱跟上市公司的三方数据没什么区别。

以“股权穿透：为例，因为信息批露的原因，上市公司的一层股东关系（如10大股东、10大流通股东、联营公司、母公司、子公司）很容易获得，而在二层股东关系里，可能会有一些非上市公司，非上市公司没有信息批露的义务，所以有可能只能获取有限的工商股权数据，这样一来，就使得定义如此强大的schema变得非常尴尬，当知识图谱schema定义的很多槽无法得到有效填充的情况下，知识图谱的信息穿透和关联等分析能力就会大为减弱。

通常，对于知识图谱的应用而言，最难的并不是基于知识图谱的计算，而是知识图谱数据本身的构造上，例如，在金融领域，最难的不是连通子图的计算，也不是上下穿透的图分析，而是找到并清洗出一份合格的股权数据。实际上，低资源问题也是知识图谱在数据构建上的一大难点。例如，在金融知识图谱构建高管关系，CEO的相关资源比较丰富，可以有比较多的训练样本，但是CFO、CDO等处于长尾部分的高管关系可能相关资源比较缺乏，学术界特别关注如何在低资源条件下构建知识图谱，相关论文的产出也比较多。

因为在实际的领域实践中，不论是关系抽取还是实体识别等，很多时候都会面临低资源问题。例如在金融领域做关系抽取任务，并不是所有关系都有丰富的训练语料，而且新的关系、新的属性、新的实体类型总会不断出现，甚至会面临完全没有样本的情况，也即零样本问题。

四、知识图谱的工业落地

对于通用的知识图谱（以百科知识图谱为例）来讲，结构化的知识已经相对来说比较稳定了，一般几千万或是一亿多实体基本可以涵盖现有应用形式下对知识的多数需求，但目前知识图谱的查询应用， 依是是处于偏浅层，推理技术在这方面的应用较少。当前，领域性的知识图谱将会受到越来越多的关注，这就必然会涉及到工业选型的问题以及衍生出一系列的未来落地趋势。

1、知识图谱的工业选型

在很多情况下，不乏有些公司会一脑热地上设立知识图谱项目，而没有做好相应的准备。一个项目的成败在于正确定义问题，这远比使用什么技术重要，一切从业务痛点出发，切记不要通过技术去寻找相应的问题。在有想从零开始进行知识图谱构建这一念头开始，需要回答几个关键性的问题：

1）使用知识图谱是想解决什么业务问题，这种业务功能是否非知识图谱不可？

在知识图谱的应用部分中，讲到了知识图谱自身的技术特征和包括知识可视化、知识搜索与知识问答、知识管理等在内的知识图谱场景，这几个场景在实现技术的难度上呈现出依次递增的特点，如果业务需求中并不属于这几类，那么可以不采用知识图谱来做。

2）为了实现这些业务功能，需要采用哪些知识图谱数据作为支撑。

为了实现业务功能，后台必须要相匹配的数据作为支撑，而这些数据的类型、数据的样式、数据的规模等信息，则需要进行业务建模，由专业的技术专家或者产品经理进行业务抽离和总结归纳。

3）当前公司都有哪些数据，数据的规模有多大，数据的样式、类型、加工程度都处于什么状态。

在完成业务建模之后，会产出一个明确的数据需求清单。研发人员需要拿着需求清单与公司现有的数据进行比对，进一步明确需要加工什么数据，什么数据可以直接拿来用（比如结构化数据），什么数据需要从非结构化文本中实施抽取，是否需要用到OCR等组件从文本影像中进行提取，是否需要解析PDF文档等，将这些技术梳理清楚之后，则可以分派给不同的专业技术人员进行处理。

4）当前公司是否能够支撑起知识图谱研发中的成本支出。

不同的业务需求、不同的数据情况，所需要采取的技术解决方案以及对应产生的成本是不同的。

如果所需的数据都是高度结构化（如存储在关系型数据库）或者稍加整理即可完成的状态，那么可以不需要自然语言处理工程师参与，直接进行结构化知识的导入和转换处理（如使用脚本处理转换）即可。

如果所需的数据是半结构化的，如发布在网页中的百科infobox数据，规范表格中的数据，则让爬虫工程师和算法工程师进行提取即可。

如果所需的数据是非结构化的，即知识是隐藏在文本段落中，需要通过实体识别、实体关系抽取等方式进行的，则需要让专业的算法工程师加以实施。

五、知识图谱的未来落地趋势

知识图谱从2012年正式从工业界提出（谷歌发布基于知识图谱的搜索）一来，从构建技术以及领域知识库的构建上已经初见成效（虽然离大规模可用状态还有很大距离），并且在这8年里，落地范式在悄然发生改变。

1）从知识可视化到领域知识图谱辅助构建工具

知识可视化与知识问答是知识图谱提出后，工业界落地最为常见的两个场景，前者由于偏前端工程，与底层知识图谱数据无关，实现难度不大，因此迅速占领了知识图谱的市场。知识问答落地也可以剥离出数据层，而以问答解析、实体链接、知识查询等技术为核心点，在针对实体属性、实体关系的单跳问题上也取得了一定的成效。

也就是说，这两个场景的成功，是避开了知识图谱数据的问题，两者都可以利用已经结构化好的数据（如mysql中的结构化数据转换以及百科类半结构化数据的解析）迅速搭建起来。但接下来，领域知识图谱自身数据的问题将会被放大，结构化数据带来的红利将会逐步消失，百科类知识图谱构建和应用已经到了深水区，三元组类的知识本身相对来说已经收敛，从而从单纯的知识服务，过渡到决策和预测服务。

因此，自进入2020年以来，由于知识抽取的领域性问题（不同的领域，需要进行定制化开发）和数据私有性问题（特别是军工、公安等内网环境），以构建领域知识图谱数据的知识图谱平台逐步浮出水面。

目前，已经出现了多款模块化知识图谱构建工具，大体上提供一站式知识图谱构建平台，提供本体设计、信息抽取、知识映射、多源融合以及增量更新等功能。其中，提供本体设计界面，针对结构化、半结构化输入数据，提供插件化、配置化、可扩展的信息抽取模块，结合相应的配置及源数据，自动完成信息抽取过程。

对于非结构化数据，提供实体关系标注、模型训练发布功能，可通过算法模型自动抽取相应的三元组信息。在知识映射部分，通过配置化、自定义接口方式，完成信息抽取结果与定义本体之间的知识映射，实现知识的内部统一表示。提供知识图谱查询服务接口，方便知识图谱应用直接调用。提供可视化服务，通过人机交互方式，可以快速的查询拓展实体及关系信息。

2）从数据图谱到知识推理专家系统的决策工具

目前，知识图谱还是处在数据的建设上，而离真正可用的业务系统还有很大距离，当前工业界的许多业务都有决策推理的场景，单单地使用知识图谱数据是不够的。因此，到后续，基于知识图谱的专家系统会逐步浮出水面。专家系统是模拟人类专家解决某一类具体问题的人工智能系统，如疾病诊疗、机械设计等，实现一个专家系统需要解决如何表示知识以及如何利用知识解决问题两个问题。

最开始的产生式表示方法， “IF <前提> THEN <结论>”本质上与知识图谱很类似，前提和结论可以表示成(前件，结果，结论)的表示形式，如（吃坏东西，结果，拉肚子）,专家掌握的所有知识按这种格式总结出来，就构造出了一个领域知识库。

一个典型专家系统包括知识库、推理机和解释器三个组成部分，知识工程师将专家知识提取出来并保存到知识库中，推理机基于这些知识进行推理，以处理用户的输入请求，解释器对推理结果给出解释（包括Why解释和How解释两种，Why解释回答“为什么有这样的答案”，How解释回答“如何得到这样的答案”）。

知识图谱作为数据，可以解决知识库的问题，但要真正发挥知识的作用，还需要进一步完成推理机和解释器两个部分的工作。例如，在一次诊疗过程中，系统给出让病人验血的建议，如果病人想知道为什么让自己去验血，可以通过交互接口输入Why，系统会根据推理过程给出让病人验血的原因，让用户明白验血的意义。

又如，如果系统诊断病人患有肺炎，而病人想了解这个结论是如何得到的，他可以通过交互接口输入How，系统就会解释做出肺炎诊断所依据的临床证据。解释器给出的原因和依据不仅使用户更加信服，也极大提高了系统在实际应用中的安全性。构建出这样的工具，也是知识图谱未来发展的一个重要方向。

六、总结

对于知识图谱，无论是产品经理，还是研发工程师。还是上层决策者，都需要对它有清醒的认识，虽然有时候也不得已而为之。

我们批判它，不是为了否定它，而是为了更好的认识它，接受它，并且改善它，让它找到更好的位置，创造更好的落地条件。