3. 知识图谱入门

在设备故障诊断场景中，知识图谱的价值不在于“把资料存起来”，而在于把设备、部件、故障、征兆、原因、处置措施之间的复杂关系表达成机器可推理、可查询、可追溯的结构。要真正用好知识图谱，必须先理解它的六块基础拼图：图结构、本体、RDF、OWL、SPARQL 与知识表示。它们分别回答“长什么样”“有哪些概念”“如何陈述事实”“如何约束语义”“如何提问”“如何把工程经验变成可计算知识”这六个问题。

一、核心原理：从三元组到可推理的图

知识图谱的底层是图结构。最常用的表示是“实体—关系—实体”或“实体—属性—值”的三元组。例如“1号给水泵—存在故障—轴承温度过高”“轴承温度过高—可能原因—润滑不足”“润滑不足—处置措施—补充润滑脂”。当大量三元组共享实体时，就自然连成一张有向标记图：节点是设备、部件、故障模式、征兆、原因、措施、工单、传感器测点等，边是“包含”“监测”“导致”“表现为”“处置”“关联工单”等语义关系。

图结构相比表格的优势在于：故障诊断知识天然是多跳的。表格擅长回答“某设备有哪些参数”，但难以高效回答“哪些设备因润滑不足导致轴承温度过高，且最近三个月有重复工单”。图结构则可以把多跳路径作为一等公民，支持路径查询、邻居扩展、子图匹配和社区发现。

二、本体、RDF、OWL：概念层与事实层的分工

本体（Ontology）是领域的概念骨架，定义类、属性、关系、层级和约束。例如定义“设备”类，其子类包括“泵”“风机”“压缩机”；定义“故障模式”类，其子类包括“轴承故障”“密封泄漏”“转子不平衡”；定义对象属性“安装于”“监测”“导致”，数据属性“额定功率”“报警阈值”。本体解决的是“这个领域里有哪些东西、它们如何合法地连接”。

RDF（资源描述框架）是事实层的通用语言，用主语—谓语—宾语三元组描述具体实例。RDF 不关心业务含义，只保证陈述可合并、可链接。例如：

@prefix eq: <http://example.org/equipment#> .
@prefix fault: <http://example.org/fault#> .

eq:Pump_01  a eq:CentrifugalPump ;
    eq:hasComponent eq:Bearing_01 ;
    eq:monitoredBy eq:VibrationSensor_01 .

eq:Bearing_01  fault:hasFaultMode fault:BearingOverheat .
fault:BearingOverheat  fault:possibleCause fault:InsufficientLubrication ;
    fault:hasSymptom fault:HighTemperature ;
    fault:hasAction fault:AddGrease .

OWL（Web 本体语言）在本体之上增加形式化语义和推理能力，例如类等价、不相交、传递属性、基数约束、逆属性等。工程上常用的推理包括：若“轴承故障”是“旋转部件故障”的子类，而“1号轴承”被诊断为“轴承故障”，则系统可推出“1号轴承存在旋转部件故障”；若定义“导致”具有传递性，则可沿因果链推导间接原因。OWL 让知识图谱从“可查”走向“可推”。

三、SPARQL：把诊断问题变成图查询

SPARQL 是 RDF 图的标准查询语言，核心是图模式匹配。它不要求用户描述“怎么查”，而是描述“要匹配的子图长什么样”。例如，要找出所有“因润滑不足导致轴承温度过高”的设备及其处置措施，可以写成：

PREFIX eq: <http://example.org/equipment#>
PREFIX fault: <http://example.org/fault#>

SELECT ?device ?action WHERE {
  ?device eq:hasComponent ?bearing .
  ?bearing fault:hasFaultMode fault:BearingOverheat .
  fault:BearingOverheat fault:possibleCause fault:InsufficientLubrication ;
                        fault:hasAction ?action .
}

在故障诊断平台中，SPARQL 常用于：按设备树展开故障影响范围、按征兆反查候选故障模式、按工单历史统计高频原因、按处置措施推荐相似案例。它把“老师傅的经验路径”变成可复现的查询模板。

四、方法流程：从设备台账到可推理图谱

1. 确定领域边界：明确覆盖哪些设备类型、故障模式、监测参数和处置流程，避免本体无限膨胀。
2. 设计本体骨架：定义核心类、对象属性、数据属性和层级关系，优先复用行业标准或企业已有编码体系。
3. 抽取事实三元组：从设备台账、点检记录、工单、传感器测点、故障树和专家访谈中抽取实体与关系。
4. 实例化 RDF：将三元组写入图数据库，统一命名空间和实体对齐规则，处理同义、别名和单位换算。
5. 补充 OWL 约束：加入子类、不相交、传递性、定义域和值域，使图谱具备一致性校验和推理能力。
6. 编写 SPARQL 查询：围绕诊断、检索、统计、推荐四类任务建立查询模板，并嵌入应用接口。
7. 验证与迭代：用真实故障案例回测查询结果，修正错误关系，补充缺失实体，持续提升覆盖率和准确率。

五、案例场景：给水泵轴承温度过高诊断

某电厂给水泵轴承温度持续偏高。传统方式下，运行人员需要翻阅规程、询问专家、比对历史工单。引入知识图谱后，系统可以沿图路径自动展开：设备“1号给水泵”包含“轴承_01”，轴承_01 监测点“振动传感器_01”和“温度传感器_02”；轴承_01 存在故障模式“轴承过热”，其可能原因包括“润滑不足”“冷却水中断”“安装偏心”；每个原因又关联征兆、处置措施和相似工单。SPARQL 查询可一次性返回候选原因排序及对应处置建议，显著缩短诊断路径。

六、误区与复盘