在设备运维领域，最常见的一个需求是：
工程师描述现场现象，系统给出可能原因和排查路径。
一开始，这件事看起来非常适合 RAG：
把历史维修工单、手册、经验文档切块，检索、生成即可。
但在真正落地之后，很快会遇到一个问题：
召回率不稳定，而且很难通过"调参"解决。
这篇文章记录一次从 RAG 转向"故障链图谱"的完整思考过程，重点不在技术名词，而在为什么这么设计。
一、RAG 在运维场景中为什么容易失效
问题并不在模型能力，而在输入本身。
在运维场景里，用户（工程师）输入通常具备三个特征：
-
描述不完整
很多关键信息当下并不知道，比如是否有报警、具体阶段、子系统归属。
-
描述不一致
不同工程师对同一现象的表述差异很大。
-
现象与方案并非一一对应
不同现象，可能走向同一条维修路径。
而 RAG 的隐含前提是：
"相似描述 → 相似答案"
这在运维领域并不总是成立。
二、一个更贴近现实的视角：工程师是如何诊断的
观察真实工程师的工作方式，会发现一个很明显的特点：
他们不是"直接找答案"，而是沿着一条排查链路逐步收敛。
典型过程是：
-
先确认发生了什么现象
-
再判断可能属于哪一类问题
-
接着执行若干排查步骤
-
最终确认具体故障点
这是一条结构化的因果链，而不是文本相似度问题。
三、从"文档检索"转向"故障链结构"
基于这个观察，系统设计的重心发生了变化：
不再围绕"文本"，而是围绕"诊断路径"。
于是引入了一个更明确的结构拆分：
-
Symptom（现象）：工程师能直接观察到的异常
-
Hypothesis（可能问题）：对现象的工程解释
-
CheckStep（排查步骤）：可以执行的检查动作
-
RootCause（根因）：最终确认的问题
历史维修工单的价值，不再是"作为答案文本"，
而是用于还原这些节点之间的连接关系。
四、用户输入该如何接入这样的结构
一个很容易踩的坑是：
试图在用户第一次输入时，就构造一个"完整、准确的现象"。
这在现实中是做不到的。
因此系统的第一步并不是"理解全部"，而是：
只提取用户明确说出的异常，其它信息允许为空。
例如用户说：
"设备开机后发动机不工作，显示参数异常。"
系统只确认两件事：
-
存在"发动机不工作"相关现象
-
存在"显示异常"相关现象
至于子系统、严重程度、发生阶段，此时并不强求。
这一步的产物，更准确地说是：
一次"不完整观测"
五、为什么一定要 Top-N，而不是唯一匹配
基于不完整观测，系统做的不是"下结论"，而是：
找可能的入口。
因此会得到多个候选 Symptom，而不是一个"最像的"。
这些候选并不是并列答案，而是：
-
多条可能的诊断起点
-
后续图推理的输入集合
这一步的目标是覆盖可能性，而不是追求精确。
六、图推理阶段只做一件事：收敛
从多个 Symptom 出发，沿着图向后展开，会得到多条维修路径。
如果不加控制，路径数量会迅速膨胀，这也是很多系统 token 爆炸的根源。
这里的关键设计是：
-
图层完成所有裁剪与合并
-
LLM 不参与枚举
具体做法包括：
-
路径打分（历史频率、覆盖现象数量等）
-
同源路径合并（指向同一 Hypothesis / RootCause）
-
强制 Top-K 截断
最终进入 LLM 的，不是"路径集合"，而是一个高度压缩的决策摘要。
七、当信息不足以收敛时，该怎么办
如果在 Top-K 限制下，仍然无法明显区分路径，这不是失败。
这意味着：
当前输入不足以支持唯一诊断。
系统此时最合理的行为不是"多给一点结果"，而是：
-
提出一个区分度最高的问题
-
或给出一个优先排查方向
这和真实工程师的行为完全一致。
八、关于子系统与严重程度的一个取舍
在构建图谱时，很容易陷入一个误区：
试图提前定义完整的子系统和严重程度。
但在实践中会发现：
-
子系统往往是诊断结果的一部分
-
严重程度高度依赖上下文（生产状态、是否有备机）
因此更合理的做法是：
-
子系统作为可选属性或后验标签
-
严重程度在推理结果阶段计算，而不是固化在图中
这样可以避免图谱过早僵化。
九、回头看：这套系统解决的到底是什么问题
它并不是为了"自动给出正确答案"，而是：
-
减少工程师走弯路
-
提供可解释、可执行的排查路径
-
在信息不完整时，知道该问什么
从这个角度看，
图谱承担的是"推理结构"，而不是"知识权威"。
结语
从 RAG 到故障链图谱，并不是否定大模型，而是重新划分职责：
-
模型负责理解与表达
-
图与程序负责推理与收敛
当系统开始接受"不完整""不确定"和"逐步逼近"时，
它反而更接近真实世界的运维工作方式。
这可能不是最快实现的方案，但往往是最不容易崩的那一种。