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