聊知识图谱在制造业落地这件事，我最大的感触是：它本质上不是技术难题，而是数据组织和业务认知的难题。我在制造业信息化这个圈子里待了多年，前前后后参与过几个知识图谱相关的项目，有从零搭平台的，也有在现有系统上做改造的，踩过的坑比收获的掌声多得多。知识图谱这个词在制造业里已经喊了好几年，但真正能用起来、并且让业务部门愿意天天用的场景，其实非常集中。
这篇文章我想围绕"知识图谱如何在制造业实际落地应用"这个命题，把从场景选择、本体设计、技术选型，到数据抽取、图谱构建、查询推理，再到问题排查和规模化推广的一整套经验讲清楚。不管你是企业的信息化负责人，还是正在做智能制造相关项目的技术人员，这篇文章提供的思路和步骤，可以直接拿去做项目参考。我不会只讲理论，会把实操过程、踩坑记录、排查技巧都写出来，尽量让内容能直接落地。
1. 为什么制造业需要知识图谱：从数据混乱到知识网络
1.1 制造业数据的真实困境
制造业和互联网行业有个本质区别：互联网的数据天生就是结构化的，用户行为、点击流、交易记录，一切规规矩矩躺在日志和数据库里；而制造业的数据基本都散落在各种老系统的犄角旮旯里。点检记录在Excel表里，维修工单在设备管理系统里，工艺参数在控制系统的采集程序里，老师傅的经验则只存在于脑子里。这些数据之间不是没有关联，而是关联关系没有被显式地表达出来。
举个例子，一台离心泵报"异响"这个故障，维修工单上可能只写了"更换轴承"。但造成轴承损坏的真正原因是润滑脂加注周期过长，而润滑脂加注周期又和这台泵所处的车间环境温度有关。这些因果关系在关系型数据库里需要多次连接操作才能勉强摸到一点线索，而且前提是你知道该往哪个方向去查。知识图谱的价值恰恰在于，它把"泵—轴承—异响—润滑不足—环境温度"这条链路的所有节点和关系，原原本本地组织成一张网，让查询和推理变得直接而自然。
我在某个机加工车间做过一次摸底调研，发现一个很典型的现象：维修工单里"更换轴承"这个描述出现了上百次，但导致更换轴承的根本原因五花八门，有润滑问题、有对中问题、有轴承本身的质量问题。这些深层次原因分散在不同时期的工单备注里，从来没有人系统整理过。这其实就是知识图谱最擅长解决的事情——把散落在历史数据里的隐性关联挖掘出来，形成可检索、可推理的知识网络。
1.2 知识图谱在制造业到底解决了什么问题
有人会把知识图谱理解成一种"高级搜索引擎"，这个理解不准确。在制造业场景里，知识图谱解决的是三类问题。
第一类是知识关联与检索。比如"历史上出现过哪些和当前故障特征相似的案例"，这种跨文档、跨系统的检索，是传统的关键词搜索做不到的。关键词搜索只能给你一堆含有关键词的文档，而知识图谱可以直接告诉你故障模式、发生过的设备型号、当时的处理方案和最终效果。
第二类是隐式关系的发现。设备、部件、故障、原因、维修操作之间往往存在多跳关系，这些关系不会直接记录在任何一张表里，但通过图的结构可以推导出来。举个例子，某类故障频繁出现在A型号设备上，而A型号设备都用了同一家供应商的某种部件，这个"供应商—部件—故障"的关联链，在关系型数据库里几乎不可能被主动发现，在图里却是一跳就能看出来的模式。
第三类是经验的显性化沉淀。老师傅脑子里的"只能意会不能言传"的经验，通过知识图谱可以变成可检索、可复用、可训练新人的结构化知识。这个价值在制造业里尤其突出，因为一线技术骨干的流失率在上升，而经验的传承速度远远跟不上。
这三类问题的共同特征是：单点数据本身价值有限，价值隐藏在数据之间的连接关系里。这也是为什么传统的关系型数据库和二维表格，在处理这类问题时显得力不从心——你无法预料未来会沿着哪条路径去查询，而图的模型天生就支持任意深度的关系遍历。
2. 落地前的顶层设计：场景选择与本体建模
2.1 场景选择：为什么故障诊断是最佳切入点
知识图谱在制造业的应用场景很多，包括供应链协同、质量追溯、工艺优化、设备健康管理等，但我强烈建议第一个试点场景选设备故障诊断与维修辅助。原因有三个。
第一，设备故障的数据基础相对最好。点检记录、维修工单、备件更换记录、设备运行参数，这些数据在绝大多数制造企业里已经存在，哪怕是纸质台账也能快速数字化。不需要额外投资大量的传感器或采集设备，起点门槛低。
第二，业务价值最容易量化。一次错误的维修决策导致的停产损失、备件浪费、紧急采购成本，都是可以直接算钱的。管理层对这种"看得见的经济效益"最有感知，项目汇报的时候说服力最强。
第三，故障诊断天然是多跳关系查询的场景。"设备—部件—故障—症状—原因—维修动作"这条链路本身就适合用图来组织，设置关系型数据库需要大量连接查询才能实现的功能，在图上就是几行查询语句的事。
我不建议第一个试点选供应链协同或研发知识沉淀这种大场景，原因很直接：这些场景涉及的系统多、部门多、数据格式差异大，协调成本极高，一个试点项目很难在短期出成果。先从小切口解决一个具体的痛点，比画一张大蓝图要实际得多。
2.2 本体设计：实体、关系与属性怎么定
本体设计是整个知识图谱项目中最关键、也最容易出问题的一步。我见过太多项目，技术选型讨论三个月，图数据库一天搭好，最后卡在本体设计上反复返工。本体设计说白了就是回答几个问题：你的图里有哪些类型的节点？节点之间有哪些类型的关系？每个节点上有哪些属性？
在设备故障诊断场景里，一个比较稳妥的最小本体包括这几类实体：设备、部件、故障模式、症状、原因、维修操作、备件。我用一个表格来呈现它们的关键属性：
| 实体类型 | 典型示例 | 关键属性 |
|---|---|---|
| 设备 | 离心泵、电机、减速机 | 资产编号、设备名称、安装位置、投运日期 |
| 部件 | 轴承、机械密封、叶轮 | 部件编号、规格型号、更换日期 |
| 故障模式 | 轴承过热、密封泄漏、振动超标 | 故障编码、严重等级 |
| 症状 | 异响、温升、泄漏、振动大 | 特征描述、检测方式 |
| 原因 | 润滑不足、对中不良、长期过载 | 发生频率、可检测性 |
| 维修操作 | 更换轴承、补充润滑脂、重新对中 | 标准工时、所需技能等级 |
| 备件 | 轴承6205、骨架油封 | 库存编码、安全库存 |
关系类型则包括：设备与部件之间的"包含"关系，部件与故障模式之间的"发生"关系，故障模式与症状之间的"表现"关系，故障模式与原因之间的"由...导致"关系，故障模式与维修操作之间的"通过...解决"关系，维修操作与备件之间的"需要"关系。
设计本体有三条原则，是我反复踩坑之后总结出来的。第一条原则是"最小够用"，第一版宁可做得简单，也不要追求大而全。本体越复杂，数据标注工作量越大，业务人员越看不懂。第二条原则是"属性先少后多"，先把节点和关系建起来，属性后面根据应用需求逐步补充，不要一开始就试图把所有字段都塞进图里。第三条原则是"预留扩展位"，比如设备实体上预留一个所属产线的属性，为后续做产线级分析留好口子。很多团队在设计本体时容易陷入完美主义，总想一次性把所有业务场景都覆盖到，结果就是项目迟迟无法启动，数据团队和业务团队相互拉扯。
2.3 技术栈选型：图数据库、抽取工具与推理引擎怎么配
技术选型的争论在制造业往往比业务讨论还热闹，但我的建议很务实：分阶段选型，试点阶段一切从简。能用手工整理的数据就不上自动化抽取，能用开源方案就不上商业套件，能不引第三方服务就不引。
图数据库方面我首推Neo4j社区版，它在试点阶段有几个优势是其他图数据库替代不了的：Cypher查询语言非常直观，技术底子薄弱的人也能在几天内上手；自带图谱可视化界面，给管理层汇报的时候展示效果直观，一张图胜过十页PPT；社区活跃，网上能搜到大量现成的故障诊断图谱案例作参考。下表是主流图数据库的选型对比：
| 图数据库 | 适合阶段 | 优势 | 劣势 |
|---|---|---|---|
| Neo4j社区版 | 试点项目 | 查询友好、可视化好、资料多 | 单机部署有性能上限 |
| NebulaGraph | 规模化生产 | 分布式架构、性能强 | 生态相对弱、学习曲线陡 |
| JanusGraph | 规模化生产 | 能对接大数据体系 | 部署复杂、运维成本高 |
| 自研图存储 | 不建议 | 没有 | 研发和维护成本极高 |
抽取工具方面，我强烈不建议在试点阶段就上大模型做关系抽取。成本高、结果不可控、出了问题还不好解释。先用规则模板加分词工具把结构化程度高的数据抽出来。维修工单里的设备编码、故障编码、备件编码这些字段本身是有格式的，用正则表达式就能搞定；非结构化的维修描述文本，用分词工具配合自定义行业词典就能达到够用的效果。等试点跑通了，积累了足够的标注数据，再考虑引入大模型或预训练语言模型做更智能的抽取。这个顺序不仅省钱，更重要的是可控——你在试点阶段最需要的不是抽取准确率提升几个点，而是快速把端到端的流程跑通。
3. 实操演示：某装备制造企业设备故障诊断知识图谱构建全流程
3.1 步骤一：数据准备与清洗
我以之前参与过的项目为例，背景是某装备制造企业的机加工车间，现场有数十台数控机床和辅助设备，维修记录散落在设备管理系统、Excel台账和纸质点检表里。项目启动后的第一步不是搭数据库，而是把数据摸清楚：有多少张表、多少份文档，每份数据有哪些字段，哪些字段是可靠的、哪些是手工填的废数据。这个环节在项目计划里经常被压缩，但实际工作量往往占整个项目的一半以上。
清洗环节有几个具体做法可以参考。第一，统一编码规范。设备编码有的地方写"P-101"，有的写"P101"，有的写"泵101"，必须制定映射规则统一转换，否则后面实体对齐一定会出乱子。第二，处理时间字段。维修记录里的日期格式五花八门，有"2023-1-5"、有"20230105"、还有"23.01.05"，全部转成统一标准格式。第三，去掉空值和明显错误值。有些维修工单的工时填了9999小时，这种数据直接剔除或者标记为异常，不要进图。
这个环节我的一个深刻体会是：一定要让熟悉业务流程的人参与数据清洗。因为很多判断需要业务知识，比如"更换轴承"和"更换轴承座"在维修操作上完全不同，但如果不了解设备结构，很容易在清洗时混为一谈。纯技术人员做数据清洗，容易把技术规范做对了，业务语义做错了，后期返工的代价非常大。
3.2 步骤二：实体与关系抽取
数据清洗完成后进入实体抽取环节。对结构化数据，比如系统导出的维修工单，直接用脚本读取字段值即可。设备编码、故障编码、维修人员这些字段本身就是实体，不需要额外抽取。真正麻烦的是非结构化的维修描述文本，比如一条记录写的是"操作工反映泵的声音有点大，检查发现轴承间隙已经超标，更换了轴承，问题解决"。
对这种文本，我的做法分三步。第一步，建行业自定义词典，把"轴承""机械密封""叶轮""对中""润滑脂"这些词加入分词工具的自定义词库，确保分词不会把这些专业词拆碎。第二步，写规则模板做匹配，比如"更换了+部件词"可以匹配出维修操作实体，"检查发现+部件词+状态词"可以匹配出症状描述。第三步，人工抽检一部分抽取结果，根据错误类型快速迭代规则。
这套规则加词典的方法在试点阶段完全够用，抽取准确率能做到八成以上，剩下的小部分交给人工补录即可。关系抽取和实体抽取是同步进行的。对结构化数据，关系往往是隐性的，比如同一张维修工单里出现了设备编号和故障编码，那么"设备—发生—故障"这个关系就是通过工单编号关联起来的。对非结构化文本，用规则模板同样能解决，比如"由于+原因词"可以匹配"由...导致"关系，"更换了+部件词"可以匹配"通过...解决"关系。
3.3 步骤三：图谱入库与索引配置
实体和关系抽取完成后，就把数据导入图数据库。我给出一个典型的导入脚本示例，用的是批量导入方式：
// 导入设备节点 LOAD CSV WITH HEADERS FROM 'file:///equipment.csv' AS row MERGE (e:Equipment {asset_id: row.asset_id}) ON CREATE SET e.name = row.name, e.location = row.location; // 导入部件节点并建立与设备的关系 LOAD CSV WITH HEADERS FROM 'file:///components.csv' AS row MATCH (e:Equipment {asset_id: row.asset_id}) MERGE (c:Component {component_id: row.component_id}) SET c.name = row.component_name, c.spec = row.spec MERGE (e)-[:HAS_PART]->(c); // 导入故障模式、症状和原因 LOAD CSV WITH HEADERS FROM 'file:///faults.csv' AS row MATCH (c:Component {component_id: row.component_id}) MERGE (f:FaultMode {fault_code: row.fault_code}) SET f.name = row.fault_name, f.level = row.severity MERGE (c)-[:EXPERIENCES]->(f); // 导入维修操作关系 LOAD CSV WITH HEADERS FROM 'file:///repairs.csv' AS row MATCH (f:FaultMode {fault_code: row.fault_code}) MERGE (r:RepairAction {action_id: row.action_id}) SET r.name = row.action_name, r.hours = row.std_hours MERGE (f)-[:SOLVED_BY]->(r);这个脚本里有几个细节值得拿出来单独说。
第一，MERGE和CREATE的语义完全不同。MERGE会先查重再创建，防止重复导入，这在源数据存在重复行时特别关键。如果你用CREATE，同样的故障编码可能被创建两次，图谱里就会出现内容相同但身份不同的节点，后续所有查询结果都会带上脏数据。第二，大批量导入时建议先把索引和约束全部关掉，导入完成后重新创建，速度能提升很多倍。很多新手一开始就建好约束，导入几万条数据等得怀疑人生，其实就是顺序错了。建索引和约束的语句如下：
CREATE CONSTRAINT equipment_asset_id IF NOT EXISTS FOR (e:Equipment) REQUIRE e.asset_id IS UNIQUE; CREATE INDEX fault_code_index IF NOT EXISTS FOR (f:FaultMode) ON (f.fault_code);第三，看似简单的导入脚本，实际上需要反复调试。我第一次跑批量导入的时候，CSV文件里有个字段带有不可见的特殊字符，导致几百条设备的名称后面跟着乱码，排查了很久才定位到问题。这种细节在文档里永远不会写，只能靠实际操作积累经验。
3.4 步骤四：查询与规则推理
图谱建好后，最有价值的应用是"症状反查故障原因"和"维修方案推荐"。车间维修工报障时最常见的问法是这样的："这台泵声音大，温度也偏高，之前遇到过类似的吗？当时是怎么处理的？"
把这个问法翻译成查询语句就是：
// 根据症状找到所有匹配的故障模式，再关联出原因和维修方案 MATCH (s:Symptom) WHERE s.name IN ['异响', '温度高'] MATCH (f:FaultMode)-[:EXHIBITS]->(s) MATCH (f)-[:CAUSED_BY]->(c:Cause) MATCH (f)-[:SOLVED_BY]->(r:RepairAction) RETURN f.name AS 故障模式, collect(DISTINCT c.name) AS 可能原因, collect(DISTINCT r.name) AS 维修方案 LIMIT 10;这种多跳查询在关系型数据库里要写一大串连接操作，而且每增加一个条件，语句就成倍变复杂。在图数据库里就这么几行，这就是图模型的核心优势：关系是图的一等公民，查询多跳关系是它的本能操作，不需要预先定义索引路径。
更进阶一步是规则推理。举个例子，我们可以定义一条规则："如果设备A的部件X和设备B的部件X是同一型号，且设备A的X发生过故障M，那么设备B的X存在发生故障M的潜在风险。"这条规则在试点阶段不需要上复杂的推理引擎，用脚本定期扫描图谱、输出风险预警清单就够了：
# 同一型号部件的跨设备风险预警 results = graph.run(""" MATCH (a:Equipment)-[:HAS_PART]->(p1:Component) MATCH (b:Equipment)-[:HAS_PART]->(p2:Component) WHERE a <> b AND p1.spec = p2.spec MATCH (p1)-[:EXPERIENCES]->(f:FaultMode) RETURN b.asset_id AS target_device, p2.name AS part_name, f.name AS risk_fault """) for record in results: alert(record["target_device"], record["part_name"], record["risk_fault"])这个功能在传统方式下很难实现，因为"同型号部件"这层关联根本没有被记录在任何一张业务表里，只有把设备结构建模成图，才能自然地把这层隐含关系暴露出来。我在实际项目中用这套逻辑给客户发现了一个真实风险：某型号液压泵在一号机床上出现过密封件早期失效，图谱扫描后发现另外两台同型号设备用了同一批次的密封件，及时做了预防性更换，避免了一次潜在的生产中断。
我自己的体会是，知识图谱项目的效果往往不在图本身，而在于你围绕图写了多少这样的查询和规则。图只是一个基础设施，真正的业务价值来自基于图的应用程序。
4. 落地过程中的典型问题与排查技巧
4.1 数据层面的坑：术语不一致和实体指代不明
制造业的数据质量比想象中还要差。同一个部件，点检表里叫"轴承"，维修描述里叫"6205轴承"，采购系统里叫"深沟球轴承"，如果不做实体对齐，图里就会长出好几个"看起来是同一个东西"的节点。解决这个问题的标准做法是建立实体映射表，把学名和别名的关系维护好，导入前统一替换。我见过一个企业导入了上万条维修记录，结果图谱里出现三个"机械密封"节点，每个节点后面挂了一堆互不相通的关系，整个图谱的价值直接打了对折。
实体对齐这件事不能完全依赖技术手段，必须有业务人员参与维护映射表。技术团队可以建一个候选映射列表，但最终确认必须由熟悉设备和备件的人来做，否则会闹出"把两个不同型号的轴承当成同一个实体"的笑话。
4.2 性能层面的坑：批量导入慢和深度查询失控
批量导入慢的问题上面提过，解决办法是导入前关闭索引、导入后重建。还有一个坑是深度查询失控。图的深度遍历是乘数级消耗，如果初始节点选择不当，一条查询就能把数据库拖垮。举个具体例子，如果你用一个比较常见的属性值作为起点展开五层关系，返回的结果数量可能会膨胀到百万级别，此时的查询时间不再是秒级，而是分钟级甚至直接超时。
我的经验是先查出一个锚点节点，限定范围再往下展开。比如先精确匹配到某台设备的资产编号，确认它是唯一节点，然后再展开三层关系，同时用LIMIT限制返回行数。另外要养成习惯，在开发环境用完整数据量做测试，而不是只用一小部分样例数据验证，否则上线后才发现真实数据量下的性能问题，返工成本很高。
4.3 组织和业务层面的坑：业务部门不用等于白做
这个坑最容易被技术团队忽视。很多知识图谱项目死在最后一步：图建好了，演示的时候全场鼓掌，之后业务人员该查表格还查表格。原因很简单，知识图谱要么没有集成到业务人员日常使用的系统里，要么交互方式不符合他们的习惯。维修工人普遍学历不高，你让他敲查询语句是不现实的，必须做一个简单的前端界面，最好是"选中症状、点按钮、出结果"的模式。
我建议第一个演示版本不要追求炫酷的图谱可视化大屏，不要搞一堆花花绿绿的关系图在屏幕上旋转。做一个最简单的搜索框加条件筛选页面，让维修工人在手机上也方便填、方便查。等业务人员形成了使用习惯，口碑起来了，后续再加入更复杂的可视化功能。试点阶段最怕的是技术团队自嗨，把精力放在自己觉得"酷"的功能上，而忽略了最终用户的实际感受。
5. 知识图谱在制造业的扩展应用场景
5.1 质量追溯与供应链协同
设备故障诊断只是切入点，知识图谱在质量追溯场景的价值同样很高。以汽车零部件制造为例，一个零件从原材料、热处理、机加工、装配到检测，涉及十几道工序，每道工序都有参数记录和操作人员。传统追溯方式是按批号查数据库，一旦出现质量客诉，往往要花几天时间才能定位到可能的问题工序。用知识图谱把"零件—批次—原材料—工序—设备—人员—质检结果"建模成一张网，从客诉症状反推问题源头，多跳查询的效率要快得多。更关键的是，图结构能发现那些以前查不出来的隐性关联，比如"某台设备加工的零件在同一道工序的缺陷率异常偏高"这类模式，在关系型数据库里很难主动浮现，在图上却是一眼可以看出来的聚集现象。
5.2 工艺设计与研发知识沉淀
制造业老师傅的流失是一个长期难题。一个在机加工车间干了二十年的老师傅，脑子里装着大量"遇到什么情况怎么调参数"的经验，这些经验从来没有被写成文档，或者写了也存在个人电脑里。知识图谱可以把这些经验结构化，把工艺参数调整的原因、触发条件、调整幅度、验证结果，按照"工艺问题—原因—调整方案—效果验证"的模式组织起来。新人遇到类似问题的时候，可以先查图谱，再决定要不要找老师傅。这不仅仅是效率问题，更是降低老师傅被挖走后带来的知识断层风险。
我在一个项目中遇到过这样一个案例：某关键工序的良率波动，老师傅凭经验判断是车间湿度和冷却液浓度的问题，但这条经验从未被记录。后来把老师傅口述的判断逻辑结构化进了图谱，当车间湿度数据异常时，系统会自动触发提示，把老师傅的经验变成了一个可复用的预警规则。这种"知识显性化"的价值，比单纯做一个查询工具要大得多。
5.3 安全风险与合规管理
把安全巡检记录、隐患整改记录、设备维保记录关联成图之后，安全管理可以从"按台账查"升级为"按关系看"。比如某类隐患多次出现在同一区域，可以沿着"区域—设备—隐患类型"的路径快速定位高频风险点，把有限的整改资源投到最需要的地方。这类应用落地的门槛比前两个场景都低，因为安全巡检的数据格式相对规整，业务价值却非常直观，管理层接受度高。如果有企业刚开始接触知识图谱，也可以考虑从这个场景切入试试水。
6. 从试点到规模化：实施路径与团队配置建议
6.1 试点项目怎么选
我总结试点项目的三条标准：数据基础好、业务痛点痛、影响范围小。数据基础好指的是相关数据已经数字化或很容易数字化，不需要额外建设大量采集设施；业务痛点痛指的是这个问题让管理层和一线人员都有切身体会，有强烈的解决意愿；影响范围小指的是试点最好只覆盖一个车间或一类设备，不要一上来就铺到全工厂。
满足这三条的场景，大概率能快速出结果。有了结果，才能在汇报的时候拿出实例和数据，才能说服管理层投入更多资源做二期。很多知识图谱项目死在第一步，就是因为选了"全厂级设备健康管理"这种超级宏大的场景，做了半年还在建数据平台，业务价值遥遥无期。
6.2 团队需要什么人
知识图谱项目需要的不是一堆算法工程师，而是三类人：一个懂图数据库和自然语言处理的技术人员，一个懂业务的行业专家，一个善于把技术语言翻译成业务语言的产品经理或项目经理。在很多企业里，第三类人最难找，但换个思路，从IT部门找一个沟通能力强、懂业务的同事兼任，往往也能扛起来。团队规模不需要大，三到五个人足够跑通一个试点，人多了反而容易陷入会议和文档的泥潭。
这里要特别强调业务专家的重要性。没有业务专家参与，技术团队很容易把本体设计成技术人员理解的"理想模型"，而不是业务人员实际使用的"工作语言"。一个好的业务专家能把"设备—部件—故障—原因—维修"这些概念定义得清清楚楚，能告诉你哪些关系在业务上是有意义的，哪些只是技术上的牵强附会。
6.3 价值度量与持续运营
最后说说投入产出比的问题。制造业的决策者看知识图谱项目，最关心的是到底省了多少钱。我的建议是，试点阶段就选定两到三个可量化的指标，比如平均故障排查时间从几个小时降到多少分钟、备件重复采购率下降多少、维修工单填写完整率提升多少。这些指标必须在项目开始前就做好基线数据的测量，否则后面无法证明价值。
我见过不少项目，图做得漂漂亮亮，但问业务部门"用起来到底省了什么"，答不上来，这样的项目在预算评审时撑不过一个季度。反过来，如果试点阶段就能拿出"平均故障定位时间从两小时降到十五分钟""历史相似案例检索时间从半天降到三十秒"这类硬指标，后面的资源争取可以说顺理成章。
还有个关键观点必须强调：知识图谱不是一次建设、终身受益的系统，它的价值依赖于数据的持续更新和规则的持续迭代。一定要建立运营机制，明确谁来更新数据、谁来审核新词条、多久做一次质量巡检。很多企业的知识图谱项目，上线时数据是新鲜的，三个月后就没人管了，图谱慢慢变成一座没人更新的死矿。定期维护和运营，可能比建设本身更重要。
根据我个人做过的几个项目，最后分享两点体会。第一，制造业知识图谱的成败，七分在数据治理，两分在业务场景设计，只有一分在算法和图技术。很多团队把精力放在模型调优上，实际上把数据洗干净、把业务问题定义清楚，项目的成功率会高很多。第二，不要迷信大而全的平台，从一个具体的痛点和一小撮数据开始，做出一件业务人员真正愿意用的工具，比画一百页架构图都管用。如果这个试点能撑过六个月还被人天天使用，那这份知识图谱的价值基本就立住了。
