Построение графа знаний о подвесных кранах и технологии семантического вывода — извлечение отношений между сущностями в базе знаний о неисправностях и практический опыт использования графовой базы данных Neo4j
📌 天车故障知识图谱技术方案
知识图谱将天车运维中分散的故障记录、维修工单、备件数据和设备参数转化为结构化的语义网络。技术链路包含四个层次:数据层(运维工单/故障记录/传感器报警/备件更换/行业标准/设备手册)、知识抽取层(BiLSTM+CRF实体识别+关系抽取+F1=91.2%)、图存储层(Neo4j Enterprise 5.x,属性图模型,节点数≥50万级)、应用层(故障诊断推理/维修方案推荐/相似故障检索/智能问答)。系统已在克鲁德重工内部知识库部署,覆盖8类天车设备、243种故障模式、1,580条故障案例。
天车(桥式起重机)的故障诊断长期依赖维修工程师的个人经验。一台天车从安装到退役的15~20年生命周期中,会产生数百份维修工单和故障记录——但这些分散在不同系统(ERP、CMMS、Excel)中的结构化/半结构化数据,没有形成可复用的知识资产。知识图谱(Knowledge Graph)技术通过实体识别(NER)、关系抽取(RE)和图存储(Neo4j),将这些碎片化信息转化为设备-故障-原因-措施-备件之间的语义关联网络。本文以克鲁德重工集团内部故障知识库建设为背景,完整介绍从数据采集到图查询推理的工程实现方案。以下技术方案参照Neo4j官方文档(Neo4j Graph Data Science Manual v5.x, 2024)、HanLP自然语言处理工具包(2.1版,2023)及克鲁德重工内部故障知识库项目(项目编号KL-KG-2024-001)的实际部署经验。
天车故障知识图谱——数据来源与实体体系
天车故障知识图谱的数据来自四个维度:①设备档案(型号/吨位/跨度/起升高度/工作级别/出厂编号/投产日期);②故障工单(故障时间/设备编号/故障现象/故障代码/排查过程/维修措施/更换备件/维修人员/停机时长);③传感器数据(振动有效值/温度/电流/超载次数历史记录);④行业标准(GB/T 3811/TSG 51/GB/T 14405等标准中相关故障判定条款)。经过实体关系抽取后,共定义6种实体类型和9种关系类型:
| 实体类型 | 标签名 | 示例 | 数量级 |
|---|---|---|---|
| 天车设备 | Crane | QD32t-023/ LD10t-156 | 500+ |
| 故障现象 | Fault | 起升溜钩/大车啃轨/制动器异响 | 243种 |
| 故障原因 | Cause | 制动衬垫磨损/车轮踏面点蚀/联轴器齿面磨损 | 480+ |
| 维修措施 | Action | 更换制动衬垫/调整制动间隙/更换联轴器 | 620+ |
| 备件物料 | Part | YWZ5-315/23制动器/车轮ZGY-600 | 1,200+ |
| Стандартные условия | Standard | GB/T 3811-2008 «Разъяснение основных положений нормативов по проектированию кранов: пять основных систем — нагрузка, конструкция, механизмы, электрооборудование и безопасность» 5.2.3 | 80+ |
| 关系类型 | 起点→终点 | Примечание |
|---|---|---|
| has_fault | Crane → Fault | 某台天车发生过某故障 |
| has_symptom | Fault → Fault | 故障A伴随故障B同时出现 |
| caused_by | Fault → Cause | 某故障由某原因导致 |
| resolved_by | Fault → Action | 某故障通过某措施解决 |
| uses_part | Action → Part | 某措施需要更换某备件 |
| ref_standard | Fault → Standard | 某故障相关的标准条款 |
| similar_to | Fault → Fault | 故障A与故障B相似(余弦相似度>0.8) |
| located_in | Crane → Location | 天车位于某车间/工段 |
| occurred_at | Fault → Time | 故障发生时间 |
实体关系抽取——BiLSTM+CRF工程实现
知识抽取是图构建中最关键的环节。系统采用BiLSTM+CRF(双向长短期记忆网络+条件随机场)序列标注模型,以HanLP 2.1为预处理管道(分词+词性标注+依存句法分析),在2,400条人工标注的天车故障文本上训练。标注方案采用BIOES(Begin/Inside/Outside/End/Single),实体标签6类×BIOES=30个标注标签。
Neo4j图数据库存储与Cypher查询
抽取后的三元组(头实体-关系-尾实体)存入Neo4j Enterprise 5.x图数据库。采用Labeled Property Graph(标签属性图)模型,每个节点一个标签(label),关系有类型(type)和方向(direction)。数据规模:节点数≥58,000个,关系数≥126,000条(截至2026年6月)。
典型Cypher查询示例:
// 查询QD32t-023天车所有历史故障及对应的维修措施
MATCH (c:Crane {id: 'QD32t-023'})-[r1:has_fault]->(f:Fault)
OPTIONAL MATCH (f)-[r2:resolved_by]->(a:Action)
OPTIONAL MATCH (a)-[r3:uses_part]->(p:Part)
RETURN f.name AS 故障现象, a.name AS 维修措施, p.name AS 更换备件
ORDER BY f.severity DESC
// 基于图路径的故障推理:某天车出现"起升溜钩",推荐排查方向和备件
MATCH path = (f:Fault {name: '起升溜钩'})-[*1..2]-(n)
WHERE ANY(label IN labels(n) WHERE n:Action OR n:Part OR n:Cause)
RETURN path LIMIT 30
// 相似故障检索(基于共有原因+措施的Jaccard相似度)
MATCH (f1:Fault {name: '制动器异响'})-[r1]->(n)
MATCH (f2:Fault)-[r2]->(n) WHERE f2 <> f1
WITH f2, COUNT(DISTINCT n) AS common,
COLLECT(DISTINCT n.name) AS shared_nodes
ORDER BY common DESC LIMIT 5
RETURN f2.name, common, shared_nodes
语义推理与智能问答
知识图谱的价值在于推理(Reasoning)。系统支持三种推理模式:
①规则推理——基于预定义的故障诊断决策树(IF-THEN规则集,由3位资深天车维修工程师编写,覆盖8类设备×243种故障×480+原因,规则总数1,520条),通过Cypher图遍历实现自动诊断;
②路径排序推理——给定故障节点,通过随机游走(Personalized PageRank,迭代次数20,重启概率0.15)对候选维修方案排序,Top-3推荐准确率86.4%(验证集N=500);
③语义问答——基于模板的NL2Cypher(自然语言→Cypher查询转换),支持12种问句模板(如”XX天车出现过什么故障”→MATCH(c:Crane)…)。
传统方案 vs 知识图谱方案对比
| Элементы сравнения | 传统方案(关系型数据库+关键词搜索) | 知识图谱方案(Neo4j+语义推理) |
|---|---|---|
| 数据模型 | 二维表,外键关联 | 属性图,节点-关系-属性 |
| 故障关联查询 | 多表JOIN(3~5张表),响应时间500ms~3s | 图遍历,响应时间<50ms |
| 多跳推理(如:故障→原因→措施→备件) | 需4次SQL查询+应用层拼装 | 单次Cypher图遍历[1..4]跳 |
| 相似故障发现 | 基于标签关键词匹配,精确率低 | 基于图结构Jaccard相似度+PageRank |
| 知识复用 | 依赖个人经验,人员流动导致知识流失 | 知识图谱持久化存储,团队共享 |
| 冷启动新设备 | 需积累足够故障记录 | 可基于同类设备图结构迁移推理 |
| 查询灵活性 | 预定义报表,临时查询需开发 | Cypher即席查询,Web界面自助 |
Часто задаваемые вопросы
问:知识图谱需要多少数据才能达到实用效果?
答:起步阶段建议至少500条故障记录(含现象+原因+措施),对应实体约6,000~8,000个,关系约12,000~15,000条。在此规模上,Top-3故障推荐准确率可达70%以上。当数据增长至2,000+条(本项目当前规模),准确率提升至86%。冷启动阶段可先导入行业公开故障数据和标准条款作为种子知识库。
问:Neo4j图数据库与MySQL/PostgreSQL在故障知识管理上的核心区别是什么?
答:核心区别在于多跳关联查询的效率。例如查询”某天车出过的故障的相似故障的维修措施”,MySQL需要5~8次JOIN(响应秒级),且表结构固定后难以扩展新的关联维度。Neo4j通过`[*1..4]`可变长度模式匹配,单条Cypher即可完成,响应<50ms。且图模型天然支持横向扩展——新增实体类型或关系类型无需改表结构。
问:知识图谱的实体关系抽取需要多少人工标注数据?
答:本项目使用2,400条人工标注数据(实体28,600个、关系12,400条),标注成本约¥1.2万(3名标注员×10天×¥400/天)。如果标注预算有限,也可采用远程监督(Distant Supervision)方法,利用现有的备件BOM表和故障代码表自动生成弱标注数据,再人工校验——可将标注量减少至400~600条,代价是F1值从91.2%降至约85%。
问:NL2Cypher语义问答的12种模板是否够用?
答:12种模板覆盖了故障知识库日常查询的约85%的场景(基于克鲁德重工内部3个月运维查询日志统计)。模板按功能分3类:故障查询类(某设备故障、某故障原因、某原因对应的措施)、备件查询类(某措施用的备件、某备件适用的措施)、统计分析类(故障频率TOP N、维修周期最长的设备)。超出模板范围的自然语言查询,目前降级为Cypher语法提示+人工补全。