制造业RAG框架实战：从设备手册解析到故障诊断落地

制造业 RAG 这两年几乎成了设备维护圈子的标配话题但大多数人讨论的是通用知识库问答真要把扫描版设备手册、故障代码表、维修记录和车间老师傅“凭耳朵听异响”的经验揉成一个能落地诊断的框架还是得自己动手。过去一年我照着这个目标写了一个开源框架内部代号 RAG-Works说白了就是把制造业场景里 RAG 的常见能力——文档解析、表格抽取、混合检索、重排序、引用溯源、多轮诊断——提前做好并打通让拿到新设备手册的人不用再从零搭一套。这篇我把设计取舍、踩坑过程和实测数据一起放出来希望对正在做设备知识库或故障诊断系统的人有实际参考价值。1. 为什么要做制造专用的 RAG 框架1.1 通用 RAG 在制造业的落差通用 RAG 在网页、论文和公众号文章上表现不错但一碰到制造业设备资料就露馅。设备手册通常是几百页的 PDF很多还是扫描件里面全是复杂表格、局部放大图、零件爆炸图目录页码和正文对不上。通用 RAG 对这类材料的处理方式基本是“把文字抽出来然后按固定字数切块”结果经常把完整的故障排除表拦腰截断或者把页眉上的“第 1 章 安全须知”当成正文内容。故障诊断也不是普通的问答检索。操作工问“注塑机锁模缓慢怎么处理”手册里可能根本没有“锁模缓慢”这个原词只有“合模速度下降”“低压锁模时间超限”这些描述。通用 RAG 习惯做字面上相似的匹配很难把“现象”和“原因”之间那一层经验关系建立起来。更别说现场口语经常会说“主轴有杂音”“油温跑上去了”这些和手册里的专业术语完全是两套表达体系。所以我做这个框架时最核心的出发点不是“再包装一个 ChatPDF”而是把制造业设备知识特有的结构化、术语差异、多跳推理问题一起解决掉。RAG-Works 这个名字听起来像强调“灵活组装”实际上我更看重的是一套面向场景的默认配置拿到一本新手册解析、建索引、跑诊断不需要先研究三天参数。1.2 常见能力盘点与框架边界开始写代码之前我先对制造业 RAG 的常见能力做了次梳理差不多是这几类设备手册接入PDF、Word、图片扫描件能处理双栏、跨页表格、页眉页脚。表格抽取与重建故障代码表、润滑周期表、扭矩参数表不能只抽成散文本。设备元数据管理每段资料要挂上“设备型号—系统—部件”的标签。混合检索与重排向量召回兼顾语义关键词召回兼顾故障代码这种精确标识。引用溯源与拒答回答必须能对应到手册页和章节查不到就明说查不到。多轮诊断记忆用户继续追问“那接下来呢”系统要记得上一轮的部件和现象。反馈闭环工程师把正确答案纠正回知识库后续检索质量能持续提升。我也划定了边界。这套框架不做实时数据采集不直接连 PLC不做预测性维护算法。原因很简单实时数据和预测模型是另一个领域混在一起会让 RAG 的定位变得模糊项目交付时更容易失控。RAG 的核心价值是“把已经存在的知识用起来”而不是替代现场经验。为什么不直接微调大模型因为设备手册会变微调一次成本高、周期长且无法覆盖每台设备的版本差异。RAG 的好处是知识更新只需要更新索引模型保持稳定这正好匹配制造业“一机一册、升级频繁”的特点。2. 核心技术的设计取舍2.1 文档解析扫描件、表格、图纸都怎么处理制造业文档处理的第一道坎是“把不可搜索的东西变得可搜索”。我设计了三级解析管线先做 OCR 和版面分析再做阅读顺序重建最后做表格结构还原。OCR 部分选用开源引擎中文识别效果足够用重点是版面分析。设备手册很多是双栏排版如果按视觉顺序直接读会把左栏下半段和右栏上半段拼在一起语义完全错乱。所以我先按区块切分再用版面坐标重建阅读顺序确保文字流是从左栏顶部到左栏底部再切到右栏顶部。这一步省不了直接影响后面的分块质量。表格是最容易被低估的部分。故障代码表往往长这样代码“E-102”描述“液压油温度过高”处理办法“检查冷却器、清洗滤芯”。如果按普通文本块切代码、描述、处理办法很可能被分到不同块里检索时根本拉不齐。我的做法是先把表格区域识别出来转成 Markdown 表格或 JSON 键值对再喂给后续的索引器。这样“E-102”和“冷却器”就能保持在一个结构化单元里精确检索才有意义。图纸本身不直接进 RAG。我遇到过不少需求是把 CAD 图纸变成对话对象但图纸上的尺寸、材料、公差靠 OCR 很难可靠抽取。现阶段我的做法是图纸先通过标注系统转成结构化参数表参数表进 RAG图纸作为附件提供下载链接。等后续视觉语言模型更成熟了再考虑把图纸整体纳入向量空间。2.2 分块与索引别把一台设备拆散分块策略我迭代了三个版本。第一版用固定 500 字切结果故障排除表被切成两半测试集命中率惨不忍睹。第二版按段落切但手册的标题层级混乱经常出现“小节标题”和“正文”分离。最终版是基于文档结构树分块先按照册的章节层级建立树再在每个标题下按语义段落聚合块大小控制在 500 到 800 个中文字符之间重叠 64 字符。这样做的核心价值是“每块都知道自己在哪”。每个分块会携带完整的元数据设备型号、章节编号、章节路径、页码、文档版本号。后续检索出来的结果能直接告诉用户“这个答案来自《注塑机维护手册》第 3 章第 2 节第 47 页”而不是一个无头无尾的文本片段。故障代码表是单独处理的。我把这类表看作“实体字典”不走普通文本索引而是先结构化成 JSON 记录再同步进一个便于精确匹配的搜索入口。查询“E-102”时系统会优先匹配代码字段而不是靠向量相似度猜。字段级倒排索引在这类场景里比向量检索可靠得多。还有一个容易被忽略的点分块时要把“上下文标题”写进文本内容。比如一块讲“溢流阀调节”的文字属于“液压系统—压力控制—溢流阀”我会把这条路径作为前置文本拼进去。这样模型在回答时能看到“溢流阀”和“压力控制”的关系而不是只看到一段孤立的调节步骤。2.3 混合检索与重排在故障场景的实际效果查询“机床主轴异响”向量检索能匹配到“主轴轴承磨损产生噪声”这种语义相近的描述关键词检索却可能因为手液体里的“异响”和手册里的“噪声”不同而失败。反过来查询“故障代码 E-102”关键词检索能靠精确字符命中向量检索却容易抓到一堆相似的“油温过高”段落。两者必须结合。我的实现是典型的“向量召回 关键词召回 结果融合 重排”四段式。向量召回负责语义泛化关键词召回负责精确匹配融合层用 RRF 方法把两个列表合并最后用交叉编码器重排模型对前 20 条做精排只保留前 3 到 5 条进大模型。这里有个关键点融合排在重排之前只是权宜之计真正让效果上台阶的是重排。我做过一组对比测试纯向量检索 top10 命中率只有 63%加上关键词召回后到 82%再用重排模型把精度集中在 top3命中率到 87%。对最终答案质量来说top3 的精准度远重要于 top10 的召回率因为大模型输入窗口有限垃圾进垃圾出。重排之后还要做意图路由。我把问题分成三类操作步骤类告知“怎么做”故障诊断类告知“先查什么再查什么”参数查询类告知“某个值是多少”。每类问题用不同的检索策略和不同的提示模板。例如诊断类问题我会强制要求模型输出“检查顺序”操作步骤类则要求“按步骤编号列出”。这个路由很轻量却能让回答结构直接对应用户预期。3. 从设备手册到故障诊断的落地实录3.1 框架目录结构与配置RAG-Works 的目录结构保持简单让接到项目的人能快速定位要改的地方rag-works/ ├── config/ │ └── default.yaml ├── src/ │ ├── ingest/ │ │ ├── ocr.py │ │ ├── layout.py │ │ ├── table_parser.py │ │ └── chunker.py │ ├── retrieval/ │ │ ├── vector_store.py │ │ ├── keyword_store.py │ │ └── fusion.py │ ├── rerank/ │ │ └── cross_encoder.py │ ├── generation/ │ │ ├── prompts.py │ │ └── llm_client.py │ └── memory/ │ └── session.py ├── data/ │ ├── manuals/ │ └── fault_codes/ └── tests/配置统一放在 YAML 里主要参数如下document: ocr_lang: zh chunk_size: 512 chunk_overlap: 64 parse: tables: structured figures: skip retrieval: top_k: 20 final_k: 4 fusion_method: rrf rerank: enabled: true model: local_cross_encoder generation: model: local_llm temperature: 0.1 max_tokens: 512 require_citation: true memory: max_turns: 6几个参数的说明temperature必须低制造业资料说不清的时候宁可拒答也不要模型自由发挥require_citation强制要求模型输出引用编号后续校验引用是否真实存在max_turns控制会话长度避免多轮以后把早期错误信息一直带下去。3.2 跑通一个最小诊断链路我先用一本注塑机维护手册做了端到端验证。场景是现场反馈“注塑机锁模缓慢合模时间超过设定值应该先查哪里”。整个链路只需要几行接口from rag_works import RagWorks app RagWorks.from_config(config/default.yaml) app.index(data/manuals/注塑机维护手册.pdf) answer app.ask(注塑机锁模缓慢合模时间超过设定值应该先查哪里) print(answer.text) print(answer.citations)实际输出大概是根据《注塑机维护手册》第7章液压系统 1. 先检查液压油温度是否超过 60℃。油温过高会导致黏度下降、系统压力不足。 2. 再检查合模压力设定值是否低于工艺卡要求。 3. 若压力正常检查比例溢流阀是否卡滞。 参考[7.2 锁模异常排查][液压原理图]这个输出之所以结构清晰是因为底层的检索链路先做了意图路由把“锁模缓慢”归类为故障诊断然后在重排结果中优先选择带“检查顺序”的手册段落最后在提示模板里要求模型按“先外部后内部、先电气后机械”的顺序组织回答。提示模板是这一段的核心我简化如下你是一名设备维护工程师。请仅根据以下资料回答问题。 如果资料不足以回答请直接说“手册未覆盖该情况”。 回答必须引用资料编号引用格式为[1]。 对于诊断类问题请按“检查顺序—可能原因—处理措施”结构输出。 资料 [1] {manual_chunk_1} [2] {manual_chunk_2}这里有三条强制约束不许用资料以外的事实、不够就拒答、必须给引用。实际运行中我发现只要这三条写死在系统提示词里幻觉率能明显下降因为模型都知道“有引用看着更可信”自然倾向于从资料里找依据。3.3 多轮诊断与会话记忆故障诊断几乎都是多轮对话。操作工不会一次把现象说全往往是先问“锁模缓慢怎么回事”再补一句“压力也不稳”最后才说“昨天换了新油”。如果系统每轮都当作独立问题处理第二轮很可能丢掉第一轮的设备型号和现象回答就会走偏。我实现了一个轻量级的会话记忆模块只保留结构化的关键信息设备型号、故障现象、已排查部件、已排除原因。每轮查询前系统会把最近几轮的关键信息组装成“检修上下文”拼到检索查询和提示模板里。对应代码大概是conversation Session() conversation.add(device_model, XM-200) conversation.add(phenomenon, 锁模缓慢压力不稳定) conversation.add(checked, 液压油温度正常) answer app.ask(那接下来该检查溢流阀还是液压泵, historyconversation)模型看到“那接下来”时能结合上一轮锁定的是“锁模动作异常”从而理解这轮问的是“下一步排查动作”而不是重新回答一遍整个锁模流程。多轮记忆还有一个副作用减少重复检索。如果上一轮已经确认“油温正常”这一轮我会把这个结果作为过滤条件在检索时直接排除“检查油温”相关段落把有限的 top_k 留给其他可能原因。3.4 评估怎么证明框架有用没有评估RAG 项目就是“看起来能聊”的演示。我从历史工单里整理了 200 条测试问题分为三类操作步骤类 80 条、故障诊断类 90 条、参数查询类 30 条。每条都人工标注了标准答案片段和引用来源。然后用三个指标评估Top3 文档命中率正确答案对应章节是否出现在最终 3 条上下文里。答案可用率生成文本是否包含关键操作或原因并由工程师主观判断。引用准确率所有引用编号是否真实指向对应资料。三种策略的对比结果方案Top3命中率答案可用率引用准确率纯向量检索55%61%45%混合检索78%74%66%混合检索重排87%86%83%从数据看重排带来的提升最明显因为它把高分但无关的章节挤下去让真正讲“怎么查”的内容进入生成环节。引用准确率提升同样靠重排因为交叉编码器能更好地区分“提到过该现象”和“在讲解该故障的排查方法”两种段落。评估集要保留版本手册更新后我会重新跑一遍防止某次调整让整体效果不升反降。4. 常见问题排查实录4.1 检索不到精准故障页这是被问得最多的问题。某次我用一台空压机的手册做测试问“排气温度过高怎么处理”返回的内容全是安全操作章节完全没提到冷却器。排查后发现两个原因一是扫描版 PDF 的目录页 OCR 后被当成正文污染了标题层级二是“排气温度过高”这段描述被跨页拆开温度报警表格和冷却器检查步骤分属两个块。解决方式分三步。第一在版面分析阶段把目录页识别出来并丢弃避免目录里的页码干扰章节判断。第二文档结构树构建时以册页脚的章节编号为准而不是靠 OCR 出来的标题文字。第三对故障排查类表格做“表头延伸”让表格的每一行都携带表头信息和前文故障现象确保拆开后的每一块都能独立表达完整含义。以后遇到同类问题先检查这三个位置大部分都能解决。4.2 生成的答案一本正经胡说有一阵子测试集里经常出现“资料里没有但模型说得很顺”的段落。例如问“油泵异响”模型回答“建议更换泵体”但手册里根本没有这个结论。检查后发现两个原因一是检索阶段top_k设得太小只拉回两条相关文本模型找不到足够资料就开始用自己的知识补二是温度参数设了 0.5给了模型自由发挥的空间。我把temperature降到 0.1同时把final_k从 3 提高到 4让模型多看一段相关文本。更重要的是在提示模板里加入“资料不足时必须拒答并提示咨询厂家”的指令。之后答案可用率从 74% 升到 86%。经验是宁可让模型说“手册未覆盖”也不要让它给出看似专业的猜测因为制造业里一个错误建议可能直接导致设备损坏。4.3 手册更新后索引不更新设备手册版本更新很频繁经常一章内容改了其他章节没动。早期我图省事每次更新都重建全量索引一台大型设备的册子要跑半小时而且重建期间查询服务不可用。后来改成增量更新每个文档分块时计算哈希存入版本表。新手册进来时先比对各章节哈希只对变化的章节重新解析和索引未变化的部分保留原索引。增量更新还能同步失效旧引用。如果第 3 章“液压系统”改版旧版本中指向第 3 章的引用记录会被标记为过期检索结果会显示“该章节已更新请查看最新版本”。这样既避免了旧知识残留又不会因为一次小更新让整个库推倒重来。4.4 性能与成本优化制造业环境不全是高端 GPU很多现场只有一台普通服务器。我的优化思路是“重排用贵模型生成用小模型检索尽量便宜”。向量化模型和重排模型可以本地化部署大语言模型优先选量化版。Embedding 结果做缓存相同文本块不重复计算。检索阶段先用轻量模型粗排到 top20再用交叉编码器精排到 top4计算量集中在最后一步整体开销可控。还有一个容易被忽略的成本点故障代码表这类结构化数据不要全部塞进大模型。我用字段匹配直接命中的方式把代码对应的处理办法以 JSON 形式拼进上下文这样既准确又省 token。实测在相同测试集下这种做法比纯向量生成减少约 30% 的模型调用费用同时答案可用率还略高。4.5 现场用语和手册术语的映射问题车间不会说“合模时间超限”会说“模老是合不上”不会说“液压油污染度超标”会说“油看起来有点脏”。这种口语化表达是通用检索模型处理不好的。我建立了一个“现象同义词表”把现场高频说法映射到手册术语。例如“合不上”映射到“合模异常/锁模力不足”“有杂音”映射到“异响/噪声/振动异常”。同义词表不需要一开始做全从历史工单里抽高频词慢慢积累即可。我先做了 50 条核心映射覆盖了测试集 70% 的口语查询检索命中率明显提升。另外查询改写也是有效手段把用户输入先通过大模型转换成“工单化表达”再用转换后的文本去检索。但要注意改写模型不能用太强的大模型否则成本上不划算我用一个参数量较小的模型足够。5. 最后再分享一个实际体会如果能重新回到项目开始我会第一件事就搭评估集而不是先堆功能。没有评估集你永远不知道一次检索参数调整到底是在提升还是在碰运气。我现在每次改完代码都会跑一遍 200 条测试问题用那个 87% 的数字当作基准线低于基线就回退。这个习惯帮我避免了很多“感觉好了但实际坏了”的陷阱。RAG-Works 目前覆盖的还只是知识检索和诊断辅助。后续我打算把离线工单挖掘也接进来从历史维修记录里抽取“现象—原因—措施”三元组自动扩充故障案例库。这一步如果能跑通框架就不再是手册的搬运工而能变成会从现场经验里学习的诊断助手。