从 RAG 召回失败到故障链推理

设备运维智能诊断的一种可行工程方案

在设备运维领域，很多团队在尝试用 RAG（Retrieval-Augmented Generation） 来做"智能运维问答"或"故障诊断助手"时，都会遇到一个高度一致的问题：

文档不少，Embedding 也做了，
但一到真实故障，系统就是"答不上来"或"答不准"。

本文结合真实运维工单场景，系统性分析 RAG 在设备运维中的结构性瓶颈 ，并给出一种 可落地的替代方案：基于故障链的图推理模型 ，重点讨论其中最关键、也最容易被忽视的一步------"现象匹配"问题。

一、问题背景：为什么 RAG 在设备运维里效果不理想？

问题 1：运维不是"查知识"，而是"走路径"

RAG 的基本假设是：

用户问题 ≈ 文档中某一段描述

→ 通过语义相似度召回

→ 大模型整合生成答案

但真实的设备运维流程是：

观察现象

→ 提出假设

→ 执行排查步骤

→ 排除或确认

→ 收敛到根因

这是一个路径决策问题，而不是"语义相似问题"。

问题 2：运维语料"密集但不可区分"

在设备工单中，常见特征包括：

术语高度集中（部件名、告警码反复出现）
描述差异小，但决策差异大
关键价值不在"描述"，而在"下一步做什么"

在这种语料分布下：

通用 embedding 难以拉开差距
子父文档切块只能缓解，但无法根治
召回率和可控性同时下降

二、转变思路：从"检索文本"到"复用维修经验路径"

如果我们回到运维工程的本质，会发现一个非常重要的事实：

工单中真正有价值的，不是那几段文字，
而是"从现象到根因，工程师走过的那条路径"。

典型历史工单中，天然包含以下结构信息：

观察到的现象（Symptom）
初步怀疑的问题（Hypothesis）
实际执行的排查步骤（Check Step）
最终确认的根因（Root Cause）

这正是一个天然的"故障链"结构。

三、方案概述：构建"故障链推理图"

我们不再把系统目标定义为"回答问题"，而是：

在给定现象的情况下，
帮助工程师尽可能少走弯路，找到正确的排查路径。

1. 图的基本结构（最小可行）

节点类型：

Symptom（现象）
Hypothesis（可能问题）
CheckStep（排查步骤）
RootCause（根因）

关系类型：

Symptom → Hypothesis（出现该现象时，通常怀疑什么）
Hypothesis → CheckStep（验证该怀疑怎么查）
CheckStep → RootCause（通过该步骤确认什么）

每条边附带统计信息：

出现次数
成功定位比例
平均确认成本

2. Neo4j 的角色定位

在该方案中：

Neo4j 只负责存储图结构 + 局部展开
不负责诊断状态
不负责全局推理
不承担"智能决策"

诊断状态（已排除假设、已执行步骤）由应用层维护。

这使得系统结构清晰、可控、易演进。

四、核心难点：如何匹配"观察到的现象"？

当系统上线后，第一个实际问题往往是：

用户或工程师的描述
对不上工单中的现象描述 ，

或者看起来完全不像，但走的是同一条维修链。

这类问题如果处理不好，整个系统会在入口就崩溃。

五、现象匹配的两个典型难题

难题一：同一现象，不同表述（语义不对齐）

例如：

工单中写的是：

"发动机无法启动"
用户输入的是：

"设备参数 X 显示异常，发动机不工作"

本质一致，但文本差异很大。

难题二：描述不同，但维修路径相同（语义不相似）

例如：

"显示参数异常"
"设备无输出"

在工程上可能最终都指向：

控制板供电异常

文本不相似，但诊断路径等价。

六、错误直觉：用一个更强的大模型"直接匹配"

一个常见但危险的想法是：

"那我用更强的 LLM / embedding，

让它直接选出正确的 Symptom。"

这个思路的问题在于：

不可控
不可解释
无法保证稳定性
一旦错配，后续推理全部偏离

七、正确解法：把"现象匹配"拆成三层

第一层：LLM 只负责结构化输入

大模型的职责不是"判断"，而是"拆解"。

对用户输入：

"设备参数 x 的显示器显示异常，发动机不工作"

结构化为：

复制代码

{
  "observed_phenomena": [
    "参数显示异常",
    "发动机不工作"
  ],
  "affected_subsystem": ["显示模块", "发动机"],
  "severity": "不可工作"
}

这一层稳定、可控、鲁棒。

第二层：Symptom 不是一句话，而是"入口模板"

Symptom 节点不是自然语言描述，而是诊断入口条件集合，例如：

复制代码

{
  "symptom_id": "ENGINE_NO_START",
  "subsystems": ["发动机"],
  "severity": "fatal",
  "signals": ["无法启动", "不工作"]
}

第三层：多策略匹配，而不是单一相似度

匹配流程：

规则过滤
- 子系统是否重叠
- 严重程度是否一致
Embedding / rerank
- 只在候选 Symptom 上使用
- 只作为排序信号之一
输出 Top-N 入口，而不是唯一答案

八、关键设计：让"不同现象"在 Hypothesis 层自然汇合

针对"语义不相似，但方案一样"的问题，不在入口强行合并。

正确做法是：

允许不同 Symptom → 指向同一个 Hypothesis

例如：

参数显示异常
发动机不工作

都可能指向：

控制板供电异常

这符合真实工程经验，也保持了系统的可解释性。

九、为什么这种方案比 RAG 更鲁棒？

因为在这个体系里：

现象匹配只是候选生成
真正的"对不对"由后续排查步骤验证
错误入口会被快速剪枝
系统能"自己纠偏"

你不再追求：

"一开始就 100% 匹配正确"

而是追求：

"错误路径能否被尽早淘汰"

十、总结

在设备运维领域：

RAG 更适合"解释知识"
故障链图更适合"做决策"

当你把系统目标从"回答问题"改为"推进诊断状态"，

很多长期困扰的问题（召回不足、语义不匹配、不可控）会自然消失。

这不是模型能力的问题，

而是系统范式是否匹配业务本质的问题。

如果你正在做运维智能化，而 RAG 已经让你开始怀疑人生，

那么也许该停下来问一句：

我们到底是在"找文本"，
还是在"复用工程经验"？

这两者，差别很大。