关于知识图谱标准化构建平台的思考：知识图谱只能做项目，不能做平台？

从知识图谱被大家所熟知之后，知识图谱自身已经成为”知识图谱+”的一个潮流，许多领域、许多行业在各个层级，都在大规模地进行知识图谱方面的结合尝试。而这种尝试，本质上包括两种，一种是以项目的方式做知识图谱，即解决方案，另一种是以产品的方式做知识图谱，即做标准化的知识平台。不同的做法会带来不同的问题，最近自己也正经历着这两种方式的转变，发现了一些问题，有些思考，写出来与大家一同分享。

一、知识图谱标准化平台的六个问题

1、知识图谱当前的应用场景是什么？
关于知识图谱的应用场景，目前畅想的已经足够多。但本质上，应用场景还是要从知识图谱自身的技术特性出发。知识图谱最大的意义其实在于其schema，即标准化的知识约束，这种约束能够将不同来源的数据、不同格式的数据进行融合，形成一个互联的数据。而这种互联，也自然而然地衍生出来了许多场景，比如关联分析、推荐、关联推理等等。但成也schema，败也schema，这种schema自身是存在很多问题的，体现在schema的颗粒度、schema的覆盖度，schema的准确度。这三个角度，直接决定了后期知识图谱的构建难度和使用体验。

2、知识图谱目前是做方案还是做标准化产品？
任何一项技术，都会经历从方案到标准化产品的过渡。解决方案的好处在于能够紧贴业务，具体问题具体分析，能够在某个垂直的领域或者数据上做到比较好的交付效果。但这种方式对于一个公司或者企业而言不是长久之计，因此这种方案不具备复制性，从一个客户到另一个客户可能就需要全部或者大部分从头开始，并为此花费大量的人力，无法迅速扩展。所以，产品的设计者以及上层的管理者，都更希望能够从这种业务中抽离出来形成一个标准化的产品，形成一个具有标准化生产流程的流水线，将整个知识图谱构建进行平台化，用户只需要根据平台的要求结合自己的业务进行适配、执行，既可以得到具体的应用效果。这种方法的好处在于具有业务的抽象性和可复制性，能够在不同的业务之间进行快速复制，可以提高生产力，但这种方式无疑是理想化或者过于理想化的。因为，业务的抽象本质上就是一个抽象概括的过程， 是忽视个体差异性的一个过程，而这种差异性也就导致这个平台在设计之初就会必然地涉及到主观性、抽象的粒度、平台运行效果的不可控等诸多因素的困扰，使得整个平台的交付能力较差。事实上，从2020年的下半年开始，就陆续出现了不少知识图谱构建平台，如华为的知识图谱构建平台，诸多公司也在建立类似的平台。这是一个趋势，但这种趋势不见的是一个正确的短期可行的的方式。至少在未来几年，我们可以发现，在简单场景（业务简单、数据准确性不敏感）中或许会有直接的应用，但相对来说比定是少数，简单场景所带来的付费能力也必然是少的。在复杂场景下得到大规模的应用，还需要很长的时间。因此，综合来看，在未来几年里，知识图谱还是以项目为绝对主导，标准化产品还需要经历业务毒打和用户验证，会是一个处于长期验证和迭代的状态。

3、作为标准化知识图谱平台是什么？
标准化的知识图谱平台，其核心价值在于代替在进行知识图谱项目解决方案中的整个流程，通过标准化组件的方式进行组装，使得流程自动化，最大程度上的发挥机器的优势，以减少人力。因此这种平台，在构建上就必然会包括知识图谱构建的标准化构建环节。从构成上看，一个标准化的知识图谱平台，大体包括知识图谱的知识定义模块、知识图谱的知识获取模块、知识图谱的知识治理模块、知识图谱的知识应用四个模块。知识定义是知识获取的指南，知识获取后进行知识治理，才有实际价值，因为知识不治理，其中的知识陈旧、知识不准确，回直接影响到后续的知识应用模块，所以，各个环节都是十分重要的。

4、作为标准化知识图谱平台中知识定义的坑？
知识定义是标准化知识图谱平台的首要成分，也是遇到的第一个难题，我之前有篇文章中对这种schema的定义展开了一些论述，认为这种schema实际上是很难去定义出来了。其颗粒度、覆盖度、准确度的设置，会直接影响后续知识获取和知识治理的难度。以最近做的一些知识图谱项目为例，对于一个垂域的知识图谱，一个实体定义了近50种的属性，这固然想的很全面，但是后面在进行知识标注（构建实体、实体关系的训练数据）的时候，发现标注的结果是相当糟糕的，主要体现在错标、漏标十分严重，而为什么会出现这种问题，主要有两个方面的原因。一个是标注的难度，二是标注的方式。因为标注的人，首先很有可能不是专业的业务专家，而是一些实习生或者一些业务专员（毕竟算法工程师比较贵），他们大多都是经历过很短的时间培训后就展开大量的标注。其次，由于标注是篇章级的，一个人要从一篇文档中标注出四十多类知识点，其标注的空间解是很大的，一条条捋下来，漏标自然会很严重。另外，由于文本标注本身就存在主观性，因此，对于同一个名称的标注，很多人的理解是不一样的，例如一个实体有名称、代号、型号等，很有可能很多人压根就分辨不出来，这样很有可能就变成了错标，而由于标注工具分包的问题，就直接导致了不同的人标注不同的文档，这么一重叠，就直接导致了标注数据的低质量。这种低质量后续交给模型去拟合，自然就会得到”garbage in, garbage out”的恶性循环当中。因此，为了尽可能减少这种原则上不可避免的东西，不仅需要在标注数据平台的设计上进行好好设计，将标注数据平台的易用性以及支持不同模式下的标注分包考虑进去。例如，设计的时候要以标注的易选性放在首位，一个实体会有名称标记、代号标记，有的平台只提示代号，如M1-M45代表不同的实体或属性，这种代号在标注人员开来很陌生，根本对不起来哪个是哪个；标注的方式可以根据按文档数量分包，也可以按照任务分发，如某些人负责某类知识的标注，一个文档像一个流水线一样进行标注（当然要考虑任务之间的依赖关系，比如任务3需要任务2执行完成后才能执行），这样的好处在于能够减少标注人员在进行标注时的压力，也能保证一类实体或属性标准的唯一性。最后一个方面，一定要控制知识在定义时候的范围，因为实践表明，在预先定义好的知识本体中，实际上得到标注的，可能不到50%。因此，需要加以控制，不然的话，会给后续的知识获取直接带来小样本学习的难度。

5、作为标准化知识图谱平台中知识获取的坑？
知识获取环节在整个平台过程当中是一个承上启下的功能，其需要依据上一环节中定义好的知识，将结构化、半结构化的、非结构化的知识都融合进来。当然，在这里需要具体任务具体分析，对于结构化的，由于知识单元都已经是结构化形成的一个个固定单元，因此只需要进行数据映射进行完成；半结构化的，也可以根据解析的方式进行映射；非结构化的则需要经历知识标注、模型训练、模型测试、模型发布与运行几个阶段。其中，知识标注环节，目前开放的知识标注平台已经有一些，例如docano、brat等，各个公司也在逐步地进行本土化或者自行设计开发，以解决不同的标注任务。通在模型训练中，知识获取这个平台更多的是将一系列的经典抽取模型列表进行内嵌化和黑盒化（如实体识别模型、实体关系抽取模型、事件抽取模型），只暴露出模型的名称、模型的输入样式以及输入的参数，用户在操作的过程中只需要加载经过标注的数据地址，选择相应的模型进行训练即可。其中的各个模型其实就是一个模型抽象的过程，可以从各个评测任务中抽离出来，将其sota的解决方案进行标准化封装即可。模型的测试，则是对模型训练后进行的评估检验，用户需要根据模型的反馈结果自行地进行参数调节以达到上线条件，最后到模型的发布。但其中涉及到一个问题，即模型的管理问题，以及模型的参数调节问题，因为模型的调参本质上是一个技术问题，不懂技术的业务人员是不理解的，他们根本就不清楚一个lr学习率对一个模型的影响，因此，在这个地方，这个功能的设置本身就是伪命题，除非这个平台能够自动地去自学习。事实上，这个环节是最吃力不讨好的，因为一个通用模型性能的好坏受制于多个方面，比如标注数据的质量、训练样本的多样性、模型自身的鲁棒性等。而在标注数据这一端，还是”garbage in , garbage out”的思想，”garbage”的判定，实际上是业务或者算法人员通过观察对比语料，显式的发现的，是一个在明处的有监督的过程。而这一过程一旦不透明或者缺少，或者没有审核的过程，是无法得到一个很好的支撑的。而一个模型的效果不好，需要准确地归类出来到底是哪个问题，并且将这个问题反馈出来，这种机制本身就存在挑战。相较与解决方案模式下的算法人员反复查看数据，定位问题，并且挖掘bad case的密切分析方式，如何将这种方式标准化成机器自动反馈的流程，本质上还是存在问题的。 总结的来说，就是，知识获取环节，需要自动地发现问题、反馈问题，并自动地根据问题进行调整，使得整个过程可控，用户的学习、使用成本降至最低。

6、作为标准化知识图谱平台中知识治理的坑？
通过知识获取得到的结构化知识，大概率是不敢用的，因为其得到的结果还是处于一种较为粗糙的结果，需要进行进一步的加工，加入版本信息、时间信息、知识实证信息等多种标识。其中最大的工作就是对知识进行标准化、知识融合以及知识控制。知识标准化是其中最为关键的事情，也是直接决定知识可用性的前提。例如速度这个属性值，有的抽取结果是功力每小时，有的米每秒。有的实体名称写的是全称，有的写的是简称，有的写的是英文名称，有的只是写的其中的一个型号，而如何进行实体对齐、属性归一，也在具体实施过程中，同样又会出现与知识定义、知识获取中一样的问题，比如归一目标的标准设计、归一模型（实体对齐模型、实体融合模型）训练数据的标注、训练模型的反馈等。知识治理的目的是最大程度上地对知识标注、知识获取这两个环节中所累积的错误进行排除和最小化，以保证整个知识的准确性和可用性，而从用户的角度上来说，他需要利用这些知识来进一步产生价值，因此就必须有证据或者有理由让用户觉得这个知识是可信的，是可以为人所接受的。而如何将这种接受进行量化的标签化，则需要对知识给出置信度以及丰富的上下文信息（如版本信息、时间信息、知识实证信息）加以佐证，以赢得用户的信赖。因此，在这个环节的设计中，需要充分考虑这些因素，将用户反馈、模型反馈、模型的结果等信息考虑进去。

6、作为标准化知识图谱平台中知识应用的坑？
知识治理的直接结果，就是向知识应用提供可信、可用的知识图谱数据。制约知识应用的最大问题，往往不是知识的规模，而是知识的可信性和可用性。小知识，能够发挥出作为小数据的最大价值，至少其是准确的。大知识，如果其中很多知识是错误的，那么得到数据也必然是站不住脚的，这样就丧失了其作为大数据的价值。当然，对接知识图谱结构化数据，进行知识应用的场景很多，例如基于知识图谱的问答，基于知识图谱的可视化检索，基于知识图谱的推荐等等，这个相对知识图谱的构建本身来说，反而技术没那么苛刻，敏感性也相对弱一些。其在具体应用的过程中，往往会处于一个迭代的状态，如考虑到应用的QPS时延性、数据查询的效率问题等等（toC场景往往对于时延性是很高的，toB则没那么苛刻），这些问题当然也可以作为反馈信息上传至知识治理当中，以决定使用什么样的数据库类型、存储架构等等。

二、知识图谱标准化平台的总结
上述以六个问题自问自答的方式，对知识图谱标准化构建平台的思考进行了几点介绍。归结起来，就以下几个点。
1、由于不同业务的壁垒以及算法模型的迁移能力较差，整个知识图谱的构建过程流程长、人为参与力度较大。在未来很长一段时间内， 知识图谱还是只能做项目式解决方案，知识图谱构建平台很长一段时间内，会由于整个流程的不可控性，在中度及以上复杂度场景下处于实验室级别，不会出现大规模具有实际交付效果的平台。

2、知识图谱构建平台的搭建，是一个结构十分复杂的工程，其最终的形态，是要形成一个具有 高质量交付能力的、质量可信、质量可用的知识图谱生产标准化车间。在这种指引下，很难将原先算法工程师、业务人员在对具体业务场景、业务数据中所作出的差异化工作用模块化的组件进行代替，这需要在产品设计上反复磋商、设计，在目前开来，除非模型本身、整个平台本身，能够自反馈、自生长、自优化，尽量让用户当傻瓜地一键式使用，很显而易见的是，这个目标是目前AI技术的终极挑战。因此，在未来很长一段时间，不会出现阵阵具有高可用的平台出现，会长期处于“低能”的初级阶段。

3、标准化的知识图谱构建平台，包括知识定义、知识获取、知识治理、知识应用等多个环节。每个环节都存在诸多不可控的因素，这些因素也是制约知识图谱最终落地的拦路虎。因此，每个环节都需要作为一个单独的模块进行 人性化、可控性的设计。例如，设计支持多种标注模式、能够减少标注人员思考复杂度的标注工具。在知识获取的过程中，设计出能够将业务人员和算法人员都能看懂且能够介入的训练方式，以保证整个训练的过程可控、可反馈和迭代优化。在知识治理阶段，设计出能够查看结构化知识，非结构化知识来源、定位、知识点置信度以及丰富的上下文信息等组件，并为最后的知识图谱应用提供最优的图谱数据库选型以及架构选型。
三、写在最后
知识图谱标准化构建平台，是一个阶段性的理想型（有条件实现）产物，是一个融合工程、业务、算法三者为一体的复杂系统。就如知识图谱自身一样，学界、业界都需要进一步的更务实，而少务虚地围绕一些具体的问题去探索，去建模，才能进一步地将这种”有条件实现”中的条件列表不断压缩，最终逼近那个目标。

刘焕勇，liuhuanyong，主页：https://liuhuanyong.github.io，360人工智能研究院算法专家，主要研究方向为知识图谱与事件图谱的应用落地。

Original: https://blog.csdn.net/lhy2014/article/details/119857488
Author: 「已注销」
Title: 关于知识图谱标准化构建平台的思考：知识图谱只能做项目，不能做平台？