设备故障排查知识问答怎么落地？图数据库加多级智能体的实践路径

手册翻到第 47 页，上面写着「可能原因：供电异常、主板故障、通讯线松动」。三个人围着机柜站了十分钟，谁也没动手。不是不会修，是这页纸给的是三选一，而现场要的是先测哪一个——测供电得拆外壳，测主板得停机，看一眼通讯线只要三十秒。三个动作的代价差着量级，能排除的可能也差着量级。文档检索能答「可能是什么」，答不了「先做什么」，而设备故障排查知识问答的成败，恰恰落在后一半——这也正是图数据库在这类场景里的位置：它存的不是答案，是判断下一步所需要的那些关系。

这篇讲四件事：普通检索在排障上为什么失灵，图里该放哪些点和边，多级智能体怎么分工，以及知识怎么才不至于三年就僵掉。

一、排障的终点是一个动作，不是一段文字

判断一套排障问答好不好，有个很粗糙但很准的测法：答完之后，用户还需不需要再问一次。

如果答案是「需要，我得再问它先测哪个」，那这套系统本质上还是个搜索框，只是换了一层皮。这不是模型不够强，是目标从一开始就定错了。文本问答的优化目标是相似度，给一段和问题最像的文字；排障的优化目标是信息增益，给一个做完之后能把候选空间砍掉一半的动作。两个目标不在同一个维度上，指标也就没法互相替代。

举个具体的差别。同一个现象「设备启动后无输出」，手册里列了七条可能原因，每条后面跟一段解释。一位干了五年的师傅会先看一眼风扇转不转——这个动作零成本，却能直接排除四条。这个判断在手册里找不到，因为它不算知识，算策略。策略从来不写在文档里。

这也解释了一个常见现象：同一台设备，老师傅十五分钟定位，新人两个小时还在换件。差的不是文档看得多少，是先做哪个的顺序。

二、普通 RAG 在排障上失灵的三层原因

多数团队的第一反应是把手册全部向量化，接个大模型上去。这条路在排障场景里大概率走不通，原因还不在召回率。

第一层，故障知识是带条件的。 同一个故障码，在 A 型号上要换部件，在 B 型号上刷一次固件就好。文档里这两段的措辞几乎一样，向量检索会把它们一起召回，模型看到两段都「很像」，于是给一个四平八稳的综合答案。可现场要的是确定的那一个——型号本来就是已知条件，不该被模糊掉。

第二层，排障是有状态的。 第二个动作取决于第一个动作的结果。单轮检索没有状态，用户每问一次都得把「我测过什么、结果是多少」重讲一遍，讲到第三轮自己都嫌烦。这不是体验问题，是多轮之后上下文被压缩，最关键的证据在压缩里丢了。

第三层，最有价值的信息是排除。 排障里最省时间的知识不是「是什么」，而是「不是什么」——这个点上午测过了、这条路径上个月走过一遍、这个部件是上批换的已经可以排除。这类信息在文档里根本不存在，因为它依赖这一台设备自己的历史。

三层叠起来，结论很清楚：要检索的不是段落，是故障模式到处置工序的映射。映射是结构，结构装不进向量空间。这也是为什么单靠 RAG 补不上这块，为什么说没有图数据库的 RAG 是不完整的从检索链路的角度谈过同一件事，本篇落在排障这一个切面上。

三、图里放什么：五类点、六类边

排障知识的骨架其实很稳定，无论行业是电力、机床还是通信设备，拆下来都是下面这几类对象。

点类型	承载什么	缺了会怎样
设备型号	型号、批次、固件版本	同一现象在不同型号上给出同一个答案
部件	可更换单元及其寿命、批次	换件建议落到总成一级，成本翻倍
现象	故障码、报警文本、可测量项	用户的口语描述无法归一到可查的键
工序	一个具体的检测或处置动作	只能回答原因，回答不了动作
证据	测量值、已测项、历史工单结论	排除逻辑无处落脚，每次从零开始

边比点更要紧，因为排障的判断几乎都发生在边上。

边类型	语义	举例
装配	型号包含哪些部件	型号 X 含电源模块、主控板、通讯板
疑似由	现象可能指向哪个部件	无输出 → 电源模块 / 主控板
对应处置	部件对应哪些工序	电源模块 → 测输出电压、测输入电压、替换
前置条件	这道工序要成立，先得满足什么	更换主控板 ← 供电输出正常
排除	做完这道工序能排除哪个现象	测输入电压正常 → 排除外部供电
顺序	工序之间的先后与依赖	先测输入，再测输出

最容易漏的是「前置条件」这条边。工序不是无条件可做的——「更换主控板」必须先确认供电正常，否则换完还是报同一个错，白停机两小时，还多了一次拆装风险。这句话在手册里通常只是一行小字，在图里是一条边，能被校验环节拦住，也能被排序环节算进代价。

第二容易漏的是工序之间的顺序。有些动作做完能排除三种可能，有些动作做完什么也排除不了、纯粹耗时间。文档按「原因」组织，不按「动作」组织，所以这一层在原文里天然缺失，只能靠自己补。

四、多级智能体怎么分工：分诊、检索、校验

拆成三级不是为了显得架构复杂，是因为这三件事的输入输出格式本来就不一样，塞进一个提示词里必然互相干扰。

层级	职责	输入	输出	拿不准时
分诊	把口语描述归一成标准现象	「机器嗡嗡响，屏幕黑的」	现象编码 + 型号 + 已测项	反问一个可测量的项
检索	在图上锁定故障族与工序集	现象编码 + 型号	候选工序及各自代价	扩大一跳，标注不确定
校验	检查前置条件与已排除项	候选工序 + 证据状态	排序后的下一步建议	提示需要人工确认

第一个关键设计：级与级之间传结构化状态，不传自然语言。这是多级智能体最容易做错的地方。如果第一级把归一化结果写成一段话交给第二级，第二级再总结一遍交给第三级，到第三级时原始的可测量项已经丢了一半，输出又退化成一段泛泛的解释。分诊的输出应该是一组字段：现象编码、设备型号、已测项、测量值。字段可以被校验，自然语言不能。

第二个关键设计：每一级都要有说「不知道」的权力。分诊置信度低于阈值，就直接回问一句「指示灯是什么颜色」，不要硬猜一个故障族往下走。硬猜一次的代价是后两级全跑在错误分支上，用户拿到一整套像模像样、逻辑自洽、但完全不沾边的建议。这种失败比直接说不知道伤得重得多，因为它消耗的是信任。

第三个关键设计：校验环节的输出是带理由的排序，不是结论。「先测电源输出，这一步能排除四条」和「请更换主控板」是两种东西。给结论的系统没人敢照着做，给理由的系统才有人愿意信，也才有人能在它错的时候发现它错。这套「先锁范围再定位答案」的思路在通用智能问答里已经比较成熟，动态知识引擎：Graph RAG 构建智能问答系统的实践有过完整拆解，排障只是把它推到了带动作的那一步。

五、「动态」在哪：知识得能长

静态图谱的宿命是装进去那天什么样子，三年后还是什么样子。可设备在老化、工艺在改、备件批次在换，手册的修订周期永远追不上现场。

动态排障的「动态」，指的是图能吸收现场跑出来的东西。

回写来源	触发时机	写回什么	治什么病
工单闭环	工单关闭时	实际路径与最终定位件，作为新的顺序边	手册没写的经验顺序
备件更换记录	换件登记时	批次与故障的关联，同一批次集中报错可提前预警	批次性缺陷被当成偶发
反例记录	按建议执行但未解决时	该建议在本型号上的失效标记	错误建议反复被推荐

第三类最容易被忽略，也最有价值。手册里只有「这样做能修好」，没有「这样做没修好」；而现场真正需要知道的是后一句。

回写要有节制。全量回写会让图里长出一堆只出现过一次的边，噪声盖过信号，跑出来的建议和随机排序差不多。可行的规则是同一路径重复出现若干次才固化为推荐，单次只作备注。这条规则看着保守，其实是在保护图的可信度——一张到处是偶然边的图，比一张小但干净的图更难用。

这条路已经有可参照的实践。2024 年 3 月，助力某研究所打造的行业方案「基于图和多级智能体的动态排障知识问答系统」，入选中国「大模型+知识管理」最佳实践案例 15 强。这个案例值得看的地方不在模型选型，而在于它把排障工序和工序的前置条件建成了图——这正是前两节说的那些边。

六、落地顺序与两个常见误区

顺序比技术选型重要。同样的组件，按不同顺序装，结果差很远。

先统一现象字典。 故障码、报警文本、口语描述对到同一套编码上。这一步通常占到整个项目一半的工作量，跳过去后面全废——因为检索的键都不一致，图建得再漂亮也查不出东西。
选一条高频故障线做全。 二十个现象、对应的工序、每条工序的前置条件，做实一条线。不要一开始全设备铺开，铺开的结局是每条线都浅。
把前置条件逐条落成边，请老师傅过一遍。 这一步没有捷径，只能靠人对。但它是全流程里唯一能把隐性经验显性化的环节。
先只做「下一步建议」，不做自动执行。 让人在旁边看一段时间，看建议被采纳的比例、被跳过时的原因。
用三个月工单回测三个数。 建议采纳率、首次定位耗时、误判率。三个数里误判率最要紧，它决定系统会不会在第二个月被现场关掉。

两个误区值得单独说。

误区一：先把手册全部向量化。 手册是写给人读的，进图要做的是把它拆成工序。一本三百页的手册，拆完大概是两三百条工序，每条带两三个前置条件。这个工作量不小，但它是唯一产生效果的那部分工作；向量化本身只解决了「找得到」，而找得到从来不是排障的瓶颈。

误区二：把多级智能体理解成多个模型投票。 不是一回事。投票的前提是各方独立判断同一件事；多级分工是各方判断不同的事，连输出格式都不一样。做成投票，等于把三次推理压成一次平均，什么也没多出来，还多了三倍成本。

排障问答的难度不在模型，在于愿不愿意把「先做哪个」这件事从老师傅脑子里搬到图上来。搬过来了，问答才有终点；搬不过来，再强的模型也只是把手册念得更流畅一点。

相关阅读

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 国产自研、自主可控，原生支持 ISO-GQL 国际标准，采用存算分离与 Shared-Nothing 架构，面向千亿点万亿边规模的关系数据存储与查询。产品内置图算法库与原生 GraphRAG 能力，图检索、向量检索、全文检索在引擎层融合，可支撑设备排障这类需要「关系 + 条件 + 时序」共同成立的问答场景。

Q2：排障问答一定要上多级智能体吗？单级模型行不行？

A：取决于问题里有没有状态。如果场景是「这个故障码什么意思」这类单轮查询，单级模型加检索完全够用，上多级是浪费。但只要出现三种情况之一，单级就会明显吃力：一是需要根据上一次结果决定下一步，二是需要在多个高度相似的候选里按型号、批次做区分，三是答案必须带排除逻辑。这三种情况本质上都需要在两次推理之间保存结构化状态，而单级模型的上下文压缩保不住这些字段。

Q3：悦数图数据库在大模型与知识管理方向有哪些落地成果？

A：2024 年 3 月，助力某研究所打造的行业方案「基于图和多级智能体的动态排障知识问答系统」入选中国「大模型+知识管理」最佳实践案例 15 强；2024 年 8 月，悦数 Graph RAG 相关研究亮相 VLDB。产品侧，悦数 AI 应用平台以图数据库与知识图谱为底座，通过 Fusion GraphRAG 把文档层级、实体关系与业务规则纳入检索过程，提供图谱构建、多路召回、Text2GQL 与探索链等能力，并支持接入 DeepSeek 等主流大模型。