制造业 RAG 这个方向我盯了大半年最后实在受不了通用框架在产线上的那些拧巴干脆自己动手把设备手册问答、故障诊断、工单检索这些常见能力揉成了一个开源框架。从最开始只能“让模型翻手册”到后来能够照着故障树一步步引导老师傅排查设备异常这套框架在我的测试环境里走了快三个月的弯路。这篇文章不聊 PPT只说我在车间和服务器两头跑的时候到底踩了哪些坑、框架里每个模块为什么这么设计、以及你想在自己厂里复现的话该从哪下手。如果你也是被制造业文档折磨过的人——扫描版 PDF、零件号的简写、领导一句“这个报警到底啥意思”——那这篇应该能帮你省点时间。我默认你了解 RAG 的基本流程也就是“索引-检索-生成”这条主线但不需要你写过完整的生产级系统代码层面的重点我都会尽量解释清楚。1. 制造业 RAG 到底特殊在哪1.1 设备手册不是网页是给“人查”而不是给“机器读”的做通用 RAG 的人一开始很难理解为什么制造业的知识库这么难搞。因为通用场景里知识库大多是网页、Markdown、PDF 文档内容结构相对规整段落之间语义清晰。但制造业的设备手册完全是另一个物种。我接触过的设备资料包括某个型号的液压站操作手册共二百多页前三十页是安全警告和符号说明中间是机械结构图最后才藏着参数表还有一批老设备的维修手册是扫描件连文字层都没有必须走 OCR更别提那些 Excel 格式的备件清单、CSV 格式的历史工单、甚至设备监控系统导出的报警日志。这些文档有一个共同点它们的排版是为“人类翻阅”设计的不是为“机器切块”设计的。表格在 PDF 里看起来是一张完整的表用工具提取出来就变成一行行断开的碎片。参数表前面通常有一段说明文字但说明和表格在版面位置上并不相邻固定长度切片很容易把它们拆到两个块里。更麻烦的是各厂商的编号规则不统一。有的用 AB-1200 表示某个型号有的写成 AB1200还有的带后缀 -S1、-R2。这种词在语义上几乎一模一样但字面上差一个字符检索时如果不做处理就会漏结果或者混入别的型号。所以我在框架里做的第一件事就是不再把文档当作“纯文本流”来处理而是先做版面分析还原标题层级、表格结构、图注、警告框再基于这些结构去做切块。这个思路贯穿了后面所有的能力设计。1.2 通用 RAG 在车间里总会答非所问通用 RAG 擅长的是“综述性回答”。你问“什么是轴承”它能给你整理一段百科式的说明。但车间里的问题不是这样的。车间里的问题是“这台设备今天报了 E-1043 故障是什么原因”“2 号产线的液压站压力掉到 40 bar 了该先查哪里”“备件编码 830012 的油滤对应的替代型号是什么”。这些问题属于“查询型”和“决策型”问题不是“摘要型”问题。如果只是把手册切块后塞进向量库然后让大模型自由发挥你会发现两个问题。第一检索结果不够精确时模型会把不同章节的内容拼在一起生成一段看起来通顺、但实际上没法操作的答案。第二故障诊断天然是一个“排除法”过程你需要先确认电机是否正常、再检查油位、再去查溢流阀而不是一口气把八个可能原因全部列给用户。用户拿到八个原因依然不知道从哪一步开始。通用 RAG 框架不会替你考虑这些它只能保证“找出来的内容相关”不能保证“相关的内容能支撑一个决策流程”。这就是我认为制造业需要专门框架的根本原因制造业 RAG 的目标不是让模型更会说话而是让每一步操作都有依据、有顺序、可执行。1.3 生产环境还有一堆硬约束除了文档和问题的特殊性制造业的部署环境也有不少限制。我在设计框架时把下面几条当作硬性约束不能连外网。很多工厂的知识库建设要求全链路私有化设备数据、维修记录不允许出内网。算力有限。产线机房不一定有高端 GPU很多时候只能用 CPU 服务器跑推理。使用者不是极客。一线操作工人和维修师傅不会用复杂的对话系统他们需要的是“你告诉我先按哪个按钮”。答案必须有依据。老师傅可以接受系统说“不确定”但不能接受系统编造一个不存在的报警码含义。这些约束决定了技术选型的方向模型要轻量、部署要简单、答案要带引用、交互要贴近实际工作流。我后面所有实现细节都是围绕这些约束展开的。2. 框架能力地图从手册问答到故障诊断2.1 设备手册问答把“能找到”变成“找得准”框架的第一个核心能力是设备手册问答。它不是简单地把手册丢给向量库而是先对文档做“版面分析”识别标题层级、表格、警告框、图注然后按“设备型号-章节-小节-段落”建立层级索引。检索的时候我采用“先按型号过滤、再按语义检索、最后重排序”的三段式流程。为什么一定要先按型号过滤因为多型号设备的参数表非常相似比如 A 型号油温上限是 65 度B 型号是 70 度字面上只差一个数字纯向量检索很容易混淆。但如果先通过查询词识别出设备型号再用型号作为过滤器把搜索范围锁定到某一本手册准确率会有质的提升。举个例子。某车间的用户问“P-2000 泵出口压力默认设定值是多少”。如果只有一个全局向量库候选结果里会混进 P-1500 泵的数据因为它们的参数表长得太像。加上型号过滤之后系统会直接锁定 P-2000 的章节再在章节内做向量检索这样返回的结果基本不会跑偏。除了检索流程引用溯源也是手册问答的关键。框架在切块时会保留页码、章节路径、表格编号等元数据模型生成的每一条结论后面都会跟一个“依据操作手册 P.87 第 3.4 节”的引用。有了这个引用老师傅才愿意信你否则就是花架子。2.2 故障诊断从“搜文档”到“推原因”的跃迁框架里最花时间的不是问答而是故障诊断。故障诊断不是一个“搜索问题”而是一个“流程问题”。我的做法是把设备维修手册里的“故障现象-可能原因-检查方法-处理措施”表格抽取出来构造成一棵故障树。每个故障节点挂相关的操作步骤和判断条件。用户输入故障现象后系统先通过检索定位到故障树节点然后根据节点的检查项用多轮对话引导用户逐步排查。举个例子。“液压系统压力不足”这个现象下面故障树会有这些分支油泵磨损、溢流阀设定值偏低、油位过低、滤芯堵塞。系统不会一次性把所有可能原因告诉用户而是先问“电机是否正常运转”再问“油位是否在标线以上”每问一步都检索对应的检查方法给出具体的操作说明和判断标准。这背后的逻辑是维修过程讲究“先易后难、先外后内”。油位检查只需肉眼观察溢流阀调整需要工具油泵拆卸是大工程。框架要把这个顺序固化到诊断流程里而不是让模型临时决定先查哪个。模型在故障诊断环节只做两件事理解用户当前给出的状态信息以及从故障树节点关联的文档中检索相应的操作依据。这套设计落地之后效果非常明显。原来一个新手维修工遇到报警只能翻手册从目录开始找翻半天还未必找对。现在直接在对话框里输入报警码系统告诉他第一步做什么、第二步做什么、每一步依据在哪一页整个排查时间缩短了不少。2.3 历史工单与维修记录的二次价值很多制造企业的维修记录都躺在 Excel 里除了做月度统计基本没人回头看。但这些东西其实是极有价值的“经验库”。我在这套框架里加了一个能力把历史工单里的“故障描述-处理措施-备件更换”转成可检索的案例库。当新故障发生时系统先在案例库里做相似度检索如果历史上有类似故障直接把当时的处理方案推荐给维修人员。案例库和手册库是两套独立的索引。手册库解决“标准怎么做”的问题案例库解决“上次实际怎么解决”的问题。检索时两个库可以同时查按权重融合排序。比如一个故障手册里说“更换溢流阀”但历史案例显示“这个车间之前的老师傅其实是先调设定值就解决了”那案例库的方案就会排在前面。这相当于给老师傅的经验做了一个“外置记忆”。框架不会取代老师傅的判断但能把老师傅积累的判断方法复用到每一个新员工身上。3. 关键实现每一块都是被现场逼出来的3.1 分块策略排版感知而不是纯按字数分块是 RAG 系统里最基础也最容易被忽视的环节。通用框架常用的做法是“固定字符数 重叠窗口”比如每 800 字切一块重叠 100 字。这种方法在新闻、网页语料上表现尚可但在制造业手册上会出大问题。设备手册里的表格是完整的语义单元固定切块会把一张参数表拦腰截断。警告框里的内容通常很短但它和安全操作强相关如果和上下文切到一起检索时权重会被稀释。更麻烦的是多级标题结构固定切块根本不会理会“第 3 章”“第 3.1 节”这类层级关系。我在框架里实现了“排版感知分块”。流程是先用版面分析模型识别出一个页面的标题、正文、表格、图注区域然后按文档结构树来切块。每个块都带有完整的元数据包括设备型号、章节路径、页码、块类型。保存到向量库之后检索时可以直接用这些元数据做条件过滤。同时也支持父子分块小的片段用于精确检索大的片段作为上下文喂给模型。小片段保证命中率大片段保证语义完整。我在实际测试里发现加了父片段后模型生成的答案明显更连贯因为它在拿到参数表局部内容的同时还能看到表格上方的说明文字。3.2 混合检索与重排序别迷信向量数据库很多做 RAG 的人一上来就搞向量数据库好像向量检索就是一切。但制造业场景会给你上残酷的一课向量模型对“字面精确”的把握很差。比如“M8 螺栓”和“八毫米螺栓”语义是相近的但字面差很多向量模型不一定能召回“AB-1200”和“AB-1201”语义几乎一样但厂家可能是两款完全不同的设备向量模型会把它们当近义词导致检索串型号。所以框架必须用混合检索BM25 负责精确的词面匹配向量检索负责语义召回两者结果做融合排序。融合时我试用过多种策略最终选择了 RRFReciprocal Rank Fusion方式。它的思路很简单把两个排序结果里的名次取倒数求和排名越靠前分数越高。这个方法不依赖绝对分数不容易受不同检索算法分数量纲的影响融合结果稳定。不过混合检索之后还有一步不能省重排序。第一次召回的前一百个候选里真正有用的可能只有五六个。直接用 BM25 和向量的融合分数还是会有一些噪音。所以在喂给大模型之前我用交叉编码器对候选做二次精排。交叉编码器会把查询和文档拼接在一起整体打分比向量模型的双塔结构更准确代价是速度慢。所以它只用来精排 Top 50 的候选最终只保留 Top 5 给生成模型。经过这一套组合拳检索命中的准确率提升非常明显。某次测试我只用向量检索的时候目标文档的命中排在第十几位加上 BM25 和 RRF 融合后进入前三再加交叉编码器重排直接到第一。3.3 故障树与状态约束让模型在轨道上跑故障诊断最怕的是模型自由发挥。制造业场景里确定性优先你不能让模型“创作”一个维修步骤出来。所以框架的故障诊断模块不是靠一个大 Prompt 硬怼而是用代码来约束流程。我用一个 JSON 文件来表示故障树节点{ fault_id: HYD_PRESSURE_LOW, fault_name: 液压系统压力不足, symptom_keywords: [液压, 压力不足, 压力低, P-2000], first_check: 检查油位是否在标线以上, steps: [ { step: 1, action: 检查液压油位低于标线则补充至标准位置, next_if_ok: 2, next_if_fail: HYD_OIL_LOW }, { step: 2, action: 检查溢流阀设定值对比手册第 3 章参数表, next_if_ok: 3, next_if_fail: HYD_RELIEF_VALVE } ], references: [P-2000_manual_chapter_3, MAINT_LOG_2023_HY01] }用户输入“压力不足”后系统先通过词表匹配和向量检索定位到 HYD_PRESSURE_LOW 节点然后按照 steps 数组的顺序逐项展示检查动作。每一项动作都关联到对应文档块确保输出不过线。这个设计的关键在于把“判断逻辑”放在代码里把“语言表达”放在模型里。模型负责把标准动作翻译成自然语言但动作本身由故障树决定。这样的系统才可控、可测试、可审计。3.4 评估体系没有评测指标你根本不知道改没改好RAG 项目最头疼的问题是你改了一个参数到底变好了还是变差了凭感觉是不行的。所以我在这套框架里内置了一套评测脚本用来回答“改得好不好”这个问题。评测集的数据来自两种渠道一是历史工单里真实出现过的故障描述二是设备手册的 FAQ 章节。每条样本包含四部分问题、标准答案、答案对应的参考文档块、以及答案在手册中的页码。评测指标我重点看四个Recall5正确答案是否出现在前五个检索结果里MRR正确答案的排名有多靠前引用命中率模型生成内容中的引用是否真的能在给定文档里找到对应依据答案准确性把生成结果和标准答案做语义相似度评估制造业场景里我最看重的是引用命中率。因为只要引用是真实的、可溯源的即使语言组织得不够华丽用户也能接受。如果引用是模型编的再漂亮的回答也是灾难。所以框架在生成阶段强制要求模型输出引用编号并且引用必须来自检索返回的给定文档列表一旦超出列表系统直接拦截。4. 完整实操从零部署一个可用的设备问答助手4.1 部署选型没有 GPU 也能跑在开始之前先确认你自己的环境。我用这套框架做过两种部署一种是有一张普通显卡的测试环境另一种是纯 CPU 的车间内网服务器。结论是没有 GPU 也能跑只是重排序阶段会慢一点。Embedding 模型我用的是轻量级开源模型参数量很小CPU 上跑一个句子大概几十毫秒完全可以接受。大模型选了 7B 量级的开源对话模型量化之后在 CPU 上单请求延迟在几秒到十几秒之间作为车间辅助工具是够用的。向量库我用的是轻量级本地方案不需要单独启动服务直接嵌入主进程减少了部署运维的复杂度。如果你有条件用 GPU延迟会好看很多。但我的建议是先按 CPU 标准来设计能跑通再谈优化。4.2 数据准备与索引构建具体操作流程我以一台设备的手册问答系统为例。第一步准备数据。把该设备的 PDF 手册、Word 操作说明、Excel 备件清单放入指定目录。如果是扫描版 PDF先跑 OCR 脚本生成带文字层的临时文件。第二步解析文档。运行文档解析模块会自动做版面分析和表格抽取。这一步会把文档转成结构化的 JSON 文件每一块包含 content、metadata 和 source。解析完成之后我强烈建议你先人工抽查几个页面确认表格没有碎、标题层级没有乱。这个检查很关键因为后续的所有检索效果都取决于这一步的质量。第三步配置元数据。在配置文件中设定设备型号、所属产线、手册版本号。如果框架没有自动识别型号需要手动在元数据里补上。第四步构建索引。运行构建命令系统会同时生成向量索引和 BM25 索引。向量索引用来做语义检索BM25 索引用来做字面匹配。第五步启动服务。框架提供一个轻量级 API 服务同时也带一个简单的前端问答页面。跑起来之后先用几个已知问题验证召回效果比如问“安全阀设定压力是多少”看看返回的引用页码是否正确。这一套流程做完一个可用的设备手册问答助手就上线了。4.3 检索参数怎么调参数调整是 RAG 项目里最耗时间的一环。我把自己调参的经验记录下来供你参考。第一top_k 不要设太小。第一次召回阶段我通常设置成 80 到 100。因为 BM25 和向量检索的融合结果里真正有用的候选可能排得很靠后如果一开始就限死 20很多相关文档根本进不了后续重排环节。重排之后再保留 5 到 8 个给大模型既保证覆盖又不至于把上下文撑爆。第二向量相似度阈值要按经验设。我见过很多人把阈值设在 0.8结果大量相关文档被过滤掉。我的经验是语义召回阶段阈值设在 0.55 到 0.7 之间比较合适。BM25 的命中是字面的不需要阈值反正后面有重排兜底。第三混排权重不用太复杂。我一开始尝试给向量和 BM25 分配权重后来又试过动态加权最终发现 RRF 融合加交叉编码器重排已经足够好权重调参的意义不大。只要保证两种召回方式都在融合策略简单一点反而更稳健。4.4 故障诊断场景的配置如果你要接入故障诊断需要手工构造一棵故障树或者从维修手册的“故障现象-原因-对策”表格中批量生成。以“液压系统压力不足”为例在配置文件中定义好节点和步骤然后启动诊断模式。一次真实的诊断对话大概是这样的用户设备报了压力不足的故障该怎么办系统已定位到“液压系统压力不足”故障树。请先执行第一步检查液压油位是否在标线以上。如果油位偏低补充液压油至标准位置。依据操作手册第 3 章第 6 节配套工单记录 2023-HY01。用户油位正常。系统第二步检查溢流阀设定值与操作手册第 3 章参数表进行对比。如果实际设定值低于标准值请按手册操作步骤调整。依据操作手册第 3 章参数表第 88 页。整个过程用户不需要翻手册只需要照着系统给的步骤做每做一步回一个结果系统会继续引导下一步。这就是故障诊断工作流和普通问答的本质区别普通问答给你一段文字诊断工作流带你把事情做完。4.5 前端交互给老师傅用不搞花架子最后是交互层。我给框架配了一个极简的 Web 页面左边是对话记录右边是引用来源每条回复下方都有“查看依据”按钮点开能看到原文摘录和页码。同时支持一键导出对话记录为维修工单方便师傅们把排查过程贴进企业的工单系统。另外也支持接入企业微信这类 IM 渠道。产线上的师傅不会天天开着浏览器但微信他们一定会用。把问答机器人接进去师傅在手机上报故障现象机器人推回排查步骤这样使用门槛最低。5. 常见问题与排障实录5.1 检索质量差先查数据再查参数检索质量出问题时我踩过最多的坑其实是“数据没准备好”而不是“参数没调对”。有一个典型现象检索出来的永远是别的设备章节。排查下来发现是切块时没有正确把设备型号写入元数据导致过滤条件失效。解决办法不是改检索配置而是回到解析环节检查元数据生成逻辑。另一个现象表格内容被切断后检索命中率很低。排查后发现是固定长度切块的锅整张参数表被切成了三段三段单独检索都很难命中。解决办法是切换成排版感知分块让表格作为独立块保留检索到表格块时整表返回。还有一个现象扫描版 PDF 识别出来一堆乱码。关键是 OCR 之前先做图像矫正倾斜校正、去黑边、增强对比度这些预处理直接影响识别准确率。OCR 之后的文本还要做一步后处理把明显异常的字符修正掉再进切块流程。5.2 幻觉问题模型乱编号、乱引用制造业场景对幻觉的容忍度极低。我处理幻觉的招数是“硬约束加软提示”双管齐下。硬约束方面生成阶段我会在 Prompt 里写明只能引用给定文档列表中的内容每条回答末尾标注引用编号如果没有找到依据直接回答“手册中未找到相关说明”。框架层还会检查模型输出的引用编号是否落在允许范围内一旦超范围就拦截并重试。软提示方面我会在 Prompt 里加一句不要解释引用之外的零件号、故障码或操作步骤。这句话看起来简单实际效果很明显能把模型“编一个差不多的答案”的冲动压住不少。5.3 性能与并发重排是最大的瓶颈整套框架里最影响延迟的是交叉编码器重排因为它是真正的深度学习计算不像 BM25 那样走文本索引。单个请求可能还好一旦并发上来CPU 环境下的重排队列会迅速拉长。我做过的优化有三个。第一重排的候选数从 50 降到 30效果损失很小延迟降了约三成。第二把多个请求的重排任务合并成 batch充分利用 CPU 的并行能力比逐条处理吞吐量高很多。第三如果响应时间依然超过预期可以把重排序模型换成更小的蒸馏版本精度稍微下降一点但延迟能大幅缩短。5.4 索引更新换个手册版本不用全量重建设备手册经常更新比如某个型号发布了新的维护保养规范。如果每次更新都要把所有文档重新切块、重新向量化非常浪费算力。框架的做法是支持“增量更新”只对变更的文件重新解析删除旧版本对应的索引块再写入新块的索引。实现的核心是给每个文档块打上“设备型号 手册版本 块 ID”的标识。更新时按标识定位旧块删除后插入新块。实测下来一个二百页的 PDF 全量重建需要几分钟增量更新只要几十秒差距很明显。6. 开源之后的一点体会把框架开源出去之后我最深的体会是开源项目的价值不在于代码本身有多炫而在于别人能不能沿着你踩过的路快速走通。所以我把评测集、样例配置文件、测试文档都放进去了还写了一份部署说明从零开始照着做基本一个下午能跑通。如果你准备在自己的厂里复现这套方案我的建议是先别追求大而全挑一个具体场景比如“某台设备的故障诊断助手”把数据准备好、故障树建起来、验证检索准确率跑通之后再逐步扩展其他设备。RAG 这类系统的效果很大程度上不取决于模型多聪明而取决于知识库整理得有多细。把文档结构吃透比换一个更强的模型更有用。最后分享一个小技巧没事的时候拿历史工单里的真实问题去跑你的问答系统然后把回答里“看着正确但实际不准确”的截屏留档。这些截屏是你优化系统最宝贵的素材比任何指标报告都直观。我就是靠着一堆这样的截屏一点点把框架调到了现在这个状态。
