知识图谱
Knowledge Graph
用实体与关系组织知识的结构化网络，把设备、部件、故障、备件、处置方法之间的关联显式表达，支撑推理与溯源。
定义
知识图谱以「实体—关系—实体」的三元组形式组织知识，形成一张可查询、可推理的网络。在工业设备领域，实体可以是设备型号、部件、故障现象、故障原因、备件、维修工艺；关系则表达它们之间的联系，例如某部件属于某设备、某现象可能由某原因导致、某原因需要更换某备件。与纯文本知识库相比，它的优势在于把隐含在文字中的关联显式表达出来，从而支持多跳查询（例如「这个现象涉及的所有部件对应哪些备件」）与一致性检查，也让答案的推导路径可追溯，这在对可靠性要求高的工业场景中价值明显。
与文档知识库的区别
文档知识库以文本为单位存储，检索时匹配相关段落，适合回答「手册里怎么说」这类问题，建设成本低、更新方便。知识图谱以结构化的实体与关系为单位，适合回答需要跨越多个事实推导的问题，例如「这个故障可能涉及哪些部件、这些部件近三个月的更换频次如何、当前库存是否充足」——这类问题的答案分散在多个来源中，文本检索难以一次性组合出来。两者并非替代关系：实践中常以文档知识库承载详细说明与操作步骤，以知识图谱承载实体间的结构化关联，查询时结合使用，既保留细节又具备推理能力。
工业场景的典型构成
设备领域的知识图谱通常围绕几类核心实体展开。设备与部件构成层级结构，从整机到总成再到零件，形成部件树，这是其他关联的骨架。故障现象与故障原因之间是多对多关系，同一现象可能有多种原因，同一原因也可能表现为多种现象。备件与部件关联，并带有规格、替代关系与供应信息。处置方法与原因关联，描述应采取的措施。此外还可以引入工况、环境、操作方式等影响因素。构建时的难点往往不在技术而在语义统一——同一部件在手册、工单与口语中有不同叫法，必须先建立统一的术语体系与别名映射，否则图谱会出现大量重复实体。
数据从哪里来
构建工业知识图谱的数据来源主要有三类，质量与提取难度各不相同。结构化数据包括设备台账、备件主数据、部件清单，这类数据规范性较好，可以直接映射为实体与关系，是图谱的基础骨架。半结构化数据包括手册中的表格、故障代码对照表、保养计划，需要解析但结构相对清晰。非结构化数据主要是维修工单的文字描述与技术文档正文，信息价值高但提取难度大，需要借助自然语言处理从中识别实体与关系，且准确率受原始记录质量制约。这再次指向工单治理的重要性——记录质量差时，最有价值的经验性知识无法被有效提取。
与大模型的配合
知识图谱与大模型的能力恰好互补。大模型擅长理解自然语言表述、组织流畅回答、处理表达的多样性，但可能生成看似合理实则错误的内容，且难以保证多步推理的严谨性。知识图谱的事实是显式存储的，推导路径可追溯，不会凭空产生关联，但对自然语言的理解与表达能力有限。组合方式通常是：由大模型理解用户问题并转换为图谱查询，图谱返回结构化的事实，再由大模型组织成自然语言回答并附上依据。这种方式既保留了交互的自然性，又让关键事实有据可查，相比纯粹依赖模型生成，可靠性明显提升。
建设建议
知识图谱建设容易陷入「追求完备」的陷阱——试图一次性覆盖所有设备与所有知识，结果周期漫长、投入巨大而迟迟不产生价值。更稳妥的路径是从具体问题出发：先选定一个高价值的查询场景，例如某类设备的故障辅助诊断，围绕这个场景确定最小必要的实体与关系范围，快速构建并投入使用，在实际反馈中迭代扩展。同时要把术语标准化作为前置工作，这是后续一切的基础。此外应建立维护机制，设备更新、备件变更、新故障模式出现都需要同步更新图谱，缺乏维护的图谱会随时间推移逐渐失真，最终无人信任。
常见问题
有了文档知识库，还需要知识图谱吗？
看要回答什么问题。文档知识库适合「手册里怎么说」这类问题，检索相关段落即可，建设成本低。知识图谱适合需要跨越多个事实推导的问题，例如「这个故障涉及哪些部件、近三个月更换频次如何、当前库存是否充足」——答案分散在多个来源，文本检索难以一次组合。实践中常两者结合：文档承载细节说明，图谱承载实体关联。
建知识图谱最容易卡在哪？
语义统一与数据质量。同一部件在手册、工单与口语中往往有不同叫法，若不先建立统一术语体系与别名映射，图谱会出现大量重复实体。另外最有价值的经验性知识存在于维修工单的文字描述中，提取准确率受原始记录质量制约——工单只写「已修复」时，这部分知识无法被有效提取。因此术语标准化与工单治理是前置工作。
相关术语
本术语库收录行业通用概念，用于技术交流与知识普及，不含任何特定厂商的非公开资料。具体设备的技术参数与操作规范，请以整车厂官方文档为准。