制造业设备售后知识助手
把故障排查从「翻手册 + 问老师傅」变成「按现象问系统」：每次回答强制附手册章节号或工单编号，工程师自己就能核对原文。
这是我们自建的演示项目，不是真实客户交付，也没有真实客户授权数据。公开它的目的有两个：一是验证我们自己的交付方法是否成立，二是让你在签约前就能看到我们怎么定义验收口径、怎么对待失败。 文中的方案取舍与坑位来自同类项目的共性经验，不是某个客户的实测记录； 评测尚未进行，因此页面只给口径与方法，不给结果数字——没有样本量的数字比留空更容易误导人，我们不做这种表述。
背景与场景
演示项目，非真实客户交付。场景取自设备类制造企业的售后服务体系：终端客户报修后，由售后工程师判断故障原因并安排维修。
知识来源有三处：设备操作与维修手册（PDF 为主）、历史维修工单（含故障现象与最终处理方式）、常见问题汇总表（Excel，由售后主管维护）。
这个场景值得做的原因：售后工程师的培养周期长，老师傅的经验难以沉淀；而故障排查的过程高度依赖「按现象查步骤」，正是检索类 Agent 的合适任务。
痛点拆解
用客户视角的原话
- 排查故障要先翻厚厚的 PDF 手册，光定位到相关章节就相当耗时
- 手册版本与设备批次不完全对应，工程师经常照着不匹配的步骤操作
- 老师傅知道答案，但经验留在个人脑子里，新人只能反复问
- 历史工单里已经解决过的同类故障，没有被检索利用，每次都是重新排查
技术方案
以及为什么这样取舍
按「故障现象」而不是「设备型号」组织检索入口
工程师拿到的是客户的口头描述（异响、报警码、温度异常），不是型号。检索必须从现象出发，再收敛到具体型号与批次。
所有回答强制附带引用来源（手册章节号 / 工单编号）
维修操作涉及设备和人身安全，工程师必须能自己核对原文。没有来源的回答在工业场景里不可用，哪怕它是对的。
论文档优先于对话式生成：先返回排查步骤清单，再补充说明
排查是流程性任务，结构化的步骤清单比一段流畅的说明文字更容易被执行，也更容易被核验。
安全相关操作（带电检修、拆解高压部件）不生成具体步骤，只提示联系厂家
这类操作超出知识助手的责任边界，必须由具备资质的人员按规程执行。
这类项目最容易踩的坑
同类项目的共性经验，非本项目实测记录
坑 1
手册是扫描件或双栏排版的 PDF，直接抽取文本后顺序错乱，检索片段读起来上下句不连贯，导致排查步骤被拼接错。
怎么解决的
先做文档结构还原（按章节切分、双栏重排、表格单独提取），并把「知识治理」作为建造阶段的前置任务写进交付计划。这一步的工作量在实践中经常超过模型调试本身。
坑 2
同一个故障在不同设备批次上的处理方法不同。只按相似度检索的方案在这里必然出错：很容易把 A 批次的处理步骤给到 B 批次。
怎么解决的
在检索层增加批次与手册版本的元数据过滤，命中多版本冲突时并列展示并标注适用批次，不替工程师做选择。
坑 3
工程师不会因为「有了新工具」就改变习惯，他们仍然先问老师傅。工具做出来了但没人用，是这类项目最常见的死法。
怎么解决的
把入口嵌进已有的工单系统页面，不新建独立系统；同时把历史工单里已验证的处理方案作为「推荐答案」呈现，让工程师第一眼就能看到系统给出的东西确实有用。
验收指标与评测方法
尚未实测，只给口径不给数字
这个项目我们还没有跑成体系的评测，所以这里只写「准备怎么量」，不写「量出来是多少」。没有样本量的数字比留空更容易误导人——那正是我们不提供估算值的原因。评测完成后，样本量与判定方式会一并补在这里。
| 指标与口径 | 怎么测 |
|---|---|
| 首次定位故障时间口径：从工程师开始排查，到确定故障原因（或确定需要现场检查的具体部位）的时间，由参与测试的工程师自行记录。 | 选一批高频故障案例，按故障类型分层（报警码、异响、温升异常、精度偏差等）；人工基线与助手结果用同一批案例、同一批工程师对照测量，每个案例记录起止时间，不靠事后回忆估计。 |
| 引用来源可核验率口径：回答中给出的手册章节号或工单编号，经人工核对确实存在、且内容与结论相关的比例。 | 对助手给出的每一条回答逐条核对引用出处，统计「存在且相关」的比例。这个指标在工业场景里比准确率更重要——没有出处的回答，工程师不敢照着做。 |
| 批次混淆率口径：在不匹配的设备批次上给出错误处理步骤的比例（越低越好），需人工判定。 | 专门构造一批「同一故障现象、不同设备批次」的案例，判定助手给出的步骤是否适用于当前批次，统计错误比例。这是前面那个坑的回归测试，必须单独测，混在总体准确率里看不出来。 |
首次定位故障时间
口径：从工程师开始排查，到确定故障原因（或确定需要现场检查的具体部位）的时间，由参与测试的工程师自行记录。
怎么测：选一批高频故障案例，按故障类型分层（报警码、异响、温升异常、精度偏差等）；人工基线与助手结果用同一批案例、同一批工程师对照测量，每个案例记录起止时间，不靠事后回忆估计。
引用来源可核验率
口径：回答中给出的手册章节号或工单编号，经人工核对确实存在、且内容与结论相关的比例。
怎么测：对助手给出的每一条回答逐条核对引用出处，统计「存在且相关」的比例。这个指标在工业场景里比准确率更重要——没有出处的回答，工程师不敢照着做。
批次混淆率
口径：在不匹配的设备批次上给出错误处理步骤的比例（越低越好），需人工判定。
怎么测：专门构造一批「同一故障现象、不同设备批次」的案例，判定助手给出的步骤是否适用于当前批次，统计错误比例。这是前面那个坑的回归测试，必须单独测，混在总体准确率里看不出来。
说明
这个演示项目的知识库与检索部分已经做出来了，但评测还没有跑，所以上面只有口径、没有结果数字。之所以先公开口径：这三个指标里有两个（引用可核验率、批次混淆率）是工业场景特有的，能不能把它们测清楚，本身就反映交付方是否理解现场——把通用客服的那套指标搬过来是不够的。样本量与判定标准会在诊断阶段与你书面确认，评测结果出来后再补在这里。
已知局限
什么情况下这个方案不适用
- 图纸类资料（CAD、装配图）的检索效果明显差于文字手册，目前只做到「定位到图号」，做不到理解图纸内容
- 老旧设备没有电子版手册时，必须先做纸质资料数字化，这属于额外工作量，应单独立项
- 助手只能提供排查建议，不能替代具备资质的维修人员做现场判断
- 它只能覆盖手册与历史工单里已经记录过的问题。遇到从未出现过的新故障，系统给不出有效答案，最多返回几个相似的旧案例供参考
可复现性与下一步
评测用的故障案例集与判定标准，可以由客户用自己公司的真实工单重建——我们负责把抽样口径与记录模板定下来，这样测出来的结果对你才有意义
知识治理（文档结构还原）的具体做法可以单独输出方法说明，这部分经验对客户自建场景同样适用
如果你愿意开放部分测试记录，我们可以在脱敏后把评测集与判定记录一并交付，便于你的工程师复现同一套口径
这个项目的评测集对我们意味着什么
评测集是我们交付物的一部分。项目结束时它归你所有——包括判定口径和失败案例。 这样即使将来不再合作，你也有能力自己判断效果是否衰减。