工业知识图谱进阶实战

要说知识图谱在工业界到底有多重要，以及目前主流的图谱产品长什么样，用几个真实案例来聊一聊。下面这篇文章主要围绕这样几个话题展开：首先聊聊背景，然后看看图谱产品有哪些形态，最后进阶到工业场景的落地实践。

01 背景简介

先聊聊云问科技是怎么走到今天的。公司是从Chatbot起家的，2013年到2019年这几年，一直深耕在人机对话领域，做了不少客服类的产品。后来之所以转向知识方向，原因其实挺直接的——在Bert大规模应用之前，机器问答的效果一直不太理想。光靠单个NLP算法，很难实现质的突破。于是我们开始想，既然算法上暂时找不到突破口，能不能换个思路，从提升问答系统质量的角度入手？答案很明确：构建高质量的企业级知识，是一条值得走的路。所以从2020年到2023年，团队把精力放在了知识领域，也慢慢发现知识图谱的应用空间远比想象中广阔。 到了2023年，大模型成了绝对的主角。不少企业觉得，有了大模型，图谱的重要性就下降了，之前那些预置的信息化系统好像也不重要了。但实际走下来才发现，随着RAG的推广和数据治理的普及，一个事实越来越清晰——更高效的数据治理和更高质量的数据，才是提升私有化大模型效果的关键前提。于是越来越多的企业开始重新审视知识构建这件事。知识的构建和加工也因此被推向了更高的水平，里面可以挖掘的技巧和方向其实非常丰富。一个新技术的出现，并不是要把旧技术全盘干掉，相反，很多情况下新旧技术结合反而能碰撞出更好的结果。站在巨人的肩膀上，才能走得更远。

那为什么云问科技会聚焦在企业知识中心这件事上？从过往的案例来看，很多复杂场景——比如风控、药物检测之类的——如果直接交给大模型去处理，短期内很难达到理想效果，也很难打磨出一个标准化产品去交付。但在企业知识管理或者办公相关的业务管理场景里，情况就不太一样了，往往能很快进入试运行，并且拿到不错的效果。所以今年在跟企业合作做私有化大模型的时候，都会把企业的知识管理、包括基于知识管理的问答或搜索作为一个重点课题来推进。对企业来说，自身的私有化知识和知识中心的建设，真的非常重要。 基于这些观察，如果对知识图谱方向感兴趣，建议从知识的全生命周期去思考，想清楚要解决什么问题、具体的落地点在哪里。比如有的企业会用现有的文档来生成考试、培训、面试相关的内容，这个场景看起来可能不像多模态、Agent这些技术热词那么耀眼，但实际效果——搭出来的私有化模型，比GPT3.5甚至GPT4都更管用。原因很简单，在这个场景里已经做了很多场景预制。所以一个判断是：更专、更精的模型，会是未来一个很大的趋势。

02 图谱产品形态

基于上面这些背景，图谱产品到底会是什么样子？接下来就以云问科技的“AI+知识”产品体系为例，把框架捋一遍。 首先，得有一个统一的AI底座。这个东西，靠一个团队、甚至一家公司是很难独立搞定的。完全可以利用大模型引擎的第三方API或者SDK，很多时候不一定要从零到一去造轮子，毕竟花几个月造出来的东西，效果可能还不如刚刚发布的一个开源模型。所以AI底座这部分，建议多想想怎么结合第三方技术；如果非要自己研发，得想清楚优势到底在哪里。当然，能把平台价值和自研能力都兼顾到，那是最好的。 再说AI能力组件。从一些交付经验里发现，这些组件往往比完整的产品更好卖。很多企业希望借助专业技术公司搭建的组件，去构建自己的上层应用。在大模型时代下，卖AI能力组件就像是卖铲子——金矿还是让大企业自己去挖。 到了上层应用，一般会从AIGC应用、知识智能和智能营服这三个方向去落地，探索哪个方向价值更大。知识图谱在整个体系里，被归为知识智能的核心环节。这里有一点很重要：知识图谱是核心，但绝不是唯一。之前遇到过不少场景，客户有大量关系型数据库和非结构化文档，希望把这些知识体系和资产全部纳入到知识图谱里。这个代价非常大。未来的知识架构，应该是异构的——一部分知识在文档里，一部分在关系数据库中，还有一部分可能来自图谱网络。大模型要做的，是基于多源异构数据做综合分析。比如一个情报，可以从关系型数据库里提取数值指标，在文档中找到建议，从工单中搜索出历史信息，然后把所有内容整合在一起分析。这才是大模型和知识图谱结合的正确方式。在一个整体架构中，大模型负责最终的分析，而知识图谱通过其知识表示体系，帮助大模型更快速、更准确地找到背后隐藏的知识。

聊完大模型和图谱之间的关系，再回头看看图谱本身需要具备什么。 首先，图谱的背后是图数据库，比如开源的Neo4j、Genius Graph，还有一些国产的数据库品牌。知识图谱和图数据库是两个不同的概念。打造一个知识图谱产品，相当于在图数据库的上层做了一层封装，实现快速的图谱建模和可视化。 要打造知识图谱产品，可以先参考Neo4j或国内一些大厂的产品形态，这样大概就能了解需要实现哪些功能和环节。但更关键的是要知道如何搭建一个知识图谱。这看起来是个业务问题——不同企业、不同场景，图谱完全不一样。作为技术人员，如果不了解电力、设备、工业等领域的业务逻辑，就不可能搭出一个让业务满意的图谱。必须跟业务反复沟通，经过不断迭代才能拿到最终结果。讨论的过程，其实可以回归到schema的本质，把图谱的一套本体理论和逻辑概念全部呈现出来。schema定好后，后续就可以让更多相关人员参与进来，把内容丰富起来。这是目前积累下来的一些经验。

下面说说图谱的总体特征。目前知识图谱还是以三元组为主，在此基础上构建实体、属性、关系等多颗粒度、多层次的语义关系。在工业界，三元组有时解决不了所有问题——当我们用设定好的实体属性值去刻画真实的物理世界时，会遇到不少麻烦。这时候就需要带约束的条件，用CVT的方式来实现。所以在构建知识图谱之前，先论证清楚三元组能不能解决当前的问题。 这里特别想说的是，构建图谱一定要按需来。世界是无穷的，里面的知识内容也是无穷的。一开始，往往会有个美好的愿景：把物理世界中的所有实体都刻画到计算机世界里。但这样做带来的问题是，最后构建的整套schema过于复杂，对真实业务其实没什么帮助。比如“地球绕着太阳转”这个事实，完全可以构建在三元组里，但这个三元组能解决当下面对的实际问题吗？不能。所以一定要按需构建。 那常识类的问题怎么办？很多问题确实需要常识类的三元组。这一块可以交给大模型来做。知识图谱更擅长的，是发掘专业领域的知识，把真正相关联的内容构建在图谱里。大模型基于常识，再结合知识图谱提供的、在开放领域里无法获取的先验知识，才能实现更好的效果。

知识图谱的构建，需要业务人员和运营人员共同去设计，包括本体、关系、属性和实体的定义，以及如何可视化。最终会涉及到一个问题：从产品形态上，呈现哪些内容给用户？如果用户是最终的消费者，那只需要呈现可视化搜索和问答就够了。这类用户并不关心图谱是怎么构建的，不管是自动化还是手工。 这里又有一个很重要的问题：即使在大模型场景下，也不是所有的图谱都能自动化构建。图谱的构建成本非常高。与其花大量精力在图谱的建模上，不如把精力花在消费上。如果想达到业务能接受的效果，可能就得依赖手工构建。比如一个格式比较确定的表格，如果跨表很复杂，可以试试能不能用大模型来寻求一个baseline。这样就能把精力从构建转移到消费上。举个例子，一个项目周期有100天，如果花了70天来构建图谱，最后只剩30天来思考应用场景，甚至因为构建时间太长，导致根本没时间思考有价值的消费场景，那问题就大了。根据经验，应该在构建上花少量时间，或者默认用手工构建，然后用大量时间来思考如何让建好的图谱发挥最大价值。

上图展示的是知识图谱构建的流程。在构建本体的时候，一定要接受一个事实：本体是会变化的，就像数据库本身的表结构也可能更新。所以在设计时，必须考虑鲁棒性和扩展性。比如在做某一类设备的图谱时，应该考虑到整套设备的体系。未来可能要通过这个体系来搜索设备，也应该知道这个体系下还有其他设备还没构建图谱，未来可以补上。通过整个大的体系，才能为用户带来更大的价值。 经常有人问：既然通过FAQ或大模型也能找到答案，为什么还要用图谱？答案是这样的：如果把当前的知识和图谱做关联之后，看到的世界就不再是一维的，而是一个网状的世界。这是图谱在消费端能实现的价值，其他技术很难做到。目前大家的关注点往往放在量级、用了什么高级算法上，但其实更应该从消费和解决问题的角度出发，来思考图谱的构建。

在大模型盛行的当下，需要思考大模型和图谱怎么结合。可以把图谱看作上层应用，大模型是底层能力。从不同场景出发，能理解大模型对图谱带来了哪些帮助。 在图谱构建时，可以通过一些文档和提示词进行信息抽取，替代原来的UIE、NER等技术，让抽取能力进一步提高。同时要权衡一下，在zero-shot、few-shot和充足数据训练的情况下，究竟是大模型好还是小模型好。这个问题没有单一答案，不同场景、不同数据集会有不同方案。这是一个全新的知识构建路径。从目前来看，在zero-shot场景下，大模型的抽取能力更优。但一旦样本量增加，小模型在性价比和推理速度上的优势就体现出来了。 在消费端，图谱常常用来解决推理类问题，比如政策类的判断——判断一个企业是否能满足某个政策、能不能享受到相关的福利。以前的做法是通过图谱、规则和语句表达式来判断。现在的做法就像Graph RAG一样，通过用户的问句找到与当前企业类似的三元组或多元组，然后让大模型来获取答案、得出结论。所以很多图谱推理类、图谱构建类的问题，都可以通过大模型技术来解决。 图谱存储是个不一样的方向。图数据库和图谱本身的数据结构很重要，大模型短期内还无法处理长文本或整个图谱。所以图谱的存储是一个很重要的方向，它和向量数据库一样，会成为未来大模型生态圈里非常重要的组件。上层应用会决定是否要使用这个组件来解决实际问题。

图谱可视化偏向前端的问题，需要根据场景和要解决的问题来设计。更希望可以把技术做成中台，提供某种能力，来满足未来不同的交互形态——移动端、PC、手持设备等等。只需要提供一个结构，前端怎么渲染和呈现，根据实际需求来定。大模型也会是调用这类结构的一种方式。当大模型或agent能够基于需求来判断如何调用图谱，闭环就打通了。图谱需要封装更好的API，来适配未来各种应用的调用。中台的概念正越来越被重视，一个独立、解耦的服务，能更广泛地被各方使用。 比如有时候需要找到某个文档表格里的数值，通过搜索或大模型技术很难定位，但如果利用图谱的结构化能力把内容呈现出来，就可以在应用系统里调用某个接口，获得这个图谱的值，然后把所在文档、或者大模型的分析结果一并呈现。这种可视化方式对用户来说最高效。这也是目前流行的Copilot方式——通过调用图谱、搜索或其他应用能力，最后用大模型做“最后一公里”的生成，共同解决问题，达到提高效率的目的。

现在经常做知识库和图谱的各种融合。今年出现了很多知识类项目。以前知识主要供人搜索和消费，随着大模型出现，大家发现也可以把知识供给大模型来消费，所以对知识的贡献和构建更加关注了。本身有大量知识，为什么还需要第三方知识图谱系统？因为原来的知识都是非结构化的，里面有很多非常重要的知识——比如工单、设备维修案例——需要把这些知识以结构化的方式存储。以前是供搜索用，现在可以供大模型做SFT。 知识库和图谱天生可以结合。结合之后，就能对外统一提供一套知识服务类产品。这种产品的生命力非常旺盛，无论在OA、ERP、MIS还是PRM系统里，都会有对知识的需求。 融合的时候，要特别注意如何区分知识和数据。客户会提供大量数据，但这些数据可能并不是知识。需要从需求侧出发来定义知识。比如对于一个设备，通常需要了解什么内容？设备运行时的数据波动是数据，而设备的出厂时间、上次维修时间等，则是知识。如何定义知识，需要在业务的参与和指导下共同构建。

03 工业图谱进阶

在数字化转型过程中，调度、设备、营销和分析等场景里，都会用到AI与图谱的技术。尤其是调度场景——无论是交通调度、能源调度还是人力调度，都是以任务下发的方式开展的。比如发生火灾，要派多少人、多少车，调度时需要查询相关数据。目前的问题往往不是找不到结果，而是返回的内容太多，给不出真正有用的解决方案。原因在于，对知识的消费形态还停留在关键词检索上，所有包含“火灾”这个词的文档都会呈现出来。要想获得更好的呈现，就得靠图谱。比如在设计“火灾”这个本体时，它的上位本体是“灾难”，针对“火灾”这个实体，可以设计它的注意事项、保护措施和经验案例。通过这些内容把知识拆分开。这样一来，当用户输入“火灾”时，呈现出来的就是一个相关的图谱脉络和下一步该做的事。 在调度场景里，Agent这个方向其实特别值得关注。调度本身是多任务的场景，图谱返回的结果会更精确、更丰富。 智能设备方面也有很多应用场景。设备的信息会存储在不同的系统里——出厂信息在产品手册里，维修信息在维修工单里，运行状态在设备管理系统中，巡检状态在工业巡检系统中。工业上面临的一大问题就是系统太多。想查一个设备的信息，需要从多个系统里查，而且这些系统之间的数据互不相通。这时候就需要一个系统来打通连接，把所有内容关联映射起来。以知识图谱为核心的知识库，就能解决这个问题。 知识图谱可以通过本体，把相关的属性、字段、字段来源等囊括进来，从底层刻画和关联各个系统之间的串并联关系。但在构建图谱时，一定要牢记按需设计和构建。很多企业会把数据中台的数据通过D2R技术全部转移过来，结果这个图谱没有任何意义。构建图谱时，一定要考虑好动态图谱和静态图谱的关联。 在智能营销和多场景能源AI领域，也有很多应用场景和设计技巧，这里就不展开说了，后续可以再探讨。

构建图谱时，架构设计非常重要。怎么把底层的库和工艺流程，与图谱构建和消费结合起来？最终怎么交付？有很多细节需要思考。可以参考上图列出的环节来设计和实践。

在图谱KBQA方面也做了一些研究，比如上下位、图谱CVT查询等。以医疗场景为例，发烧和头疼对应的上位都是“身体表征异常”，知识库里不会对发烧或头疼单独存储，原始文档里都是以“身体轻微异常”来存储的。当用户表述和专业表述有差异时，就可以通过上下位的推理CVT来解决。 当前搭建的图谱可能只是SPO或多跳或TransE等实体对齐。但在实际复杂场景下，需要CVT结合上下位来实现。不少论文在英文数据集上表现很好，到了中文数据集效果就不太理想。所以必须结合自己的需求来设计，并不断迭代，才能达到好效果。 半自动化文档加工，包括文档解析、段落抽取、三元组抽取和人工审核。人工审核这一步常常被忽略，尤其是大模型出现后，大家更不关注人工审核了。但实际上，如果进行数据加工和数据治理，对模型效果的提升是非常明显的。所以必须想清楚，最终要解决的场景具备高价值吗？投入的资源是在图谱构建上，还是在大模型优化上？如果没有这些考虑，产品很容易被取代或挑战。 上图展示的是云问科技的一款设备生命周期管理产品。这类场景通过轻量化的中间模块，在不同场景下进行上层应用搭建。这些模块的生命力，远比知识图谱系统本身更旺盛。单卖或只卖中间件在图谱领域并不适用，尤其在工业场景里。很多工业问题在客户眼里是很复杂的，图谱和大模型都无法单独解决。需要做的，是用效果去说服客户。 在工业智改数转过程中，研发设计、生产管理、供应管理、售前营销和综合服务中，都有很多应用点。 上图是故障设备图谱的应用场景举例。在这个场景里，并没有把所有图谱元素都加进去，比如设备运行状态和关系型数据库里的简单数据。对于设备维修来说，主要关注三类数据：第一类是设备基本信息，比如出厂时间、生产厂家、投入运行多久；第二类是故障信息，比如故障的名称、上下级，此类故障会导致什么缺陷，什么缺陷会导致哪类故障；第三类是工单，描述在什么设备上发生了什么故障。通过这三种数据的连接，可以构建一个小型闭环的图谱。未来也可以根据动态数据进行延伸。所以在构建图谱时，更倾向于去做一个小而美、场景能闭环的图谱，而不是一味追求量级的高大上，结果却无法满足消费端的真实需求。 在构建工业知识图谱时，要从具体场景着手，通过分析场景需求来构建图谱，才能真正实现落地和应用。