写在前面说实话制造业的 RAG检索增强生成做起来比互联网场景要棘手得多。互联网做问答文档多半是排版规范、语言通用的网页切片、召回、重排的套路都能直接复用。但制造业的文档是什么样设备手册、维修记录、SOP、点检表、故障代码表动辄几百页 PDF里面全是扫描图片、复杂的表格、专业术语和行业缩写。你拿一个通用 RAG 框架直接套上去大概率会得到一本正经地胡说八道或检索五分钟、答非所问的结果。我做这个开源框架的初衷很简单把制造业落地 RAG 时的常见能力收敛成一套开箱即用的方案从设备手册的解析入库到故障诊断场景的检索增强再到召回效果的评估调优尽量让做工业智能化的团队不用每次从零开始踩坑。这篇文章就把这个项目的核心设计拆开来讲包括我自己在设计和实测里的思路、取舍、踩过的坑希望能给正在做或准备做制造领域知识问答的朋友一点参考。1. 制造业 RAG 为什么这么难做1.1 文档形态复杂到超纲制造业知识库里的文档和你在技术社区看到的 Markdown 文档完全不是一回事。常见的几类设备操作手册重型设备的手册动辄几百页大量内容是说明书扫描件每一页里的图是整张位图机器根本看不到那个急停按钮在哪个位置。故障代码表以表格为主一个故障码对应一个描述、一个可能原因、一个处理动作。表格结构一旦错乱检索出来的内容就完全没法看。维修工单与点检记录半结构化日期、设备编号、故障现象、处理措施混在一起有时还是手写体扫描件。SOP 作业指导书步骤叙述中夹杂大量如图 XX 所示参照设备左侧旋钮这类指代如果图片信息没有被识别到模型就理解不了。通用 RAG 管线在这类文档上最容易崩的地方在于它假设内容是按自然语言段落组织的但制造业文档是图表短句的结构。你按常规的 500 token 切块切割点很可能落在表格中间把完整的两列数据劈成两半你用了通用文本嵌入模型它对主轴温度传感器、编码器分辨率、液压油清洁度等级 NS6这类高度领域化的词向量表达能力极差。1.2 问题形态和文档形态严重不对称故障诊断场景下的用户提问往往是设备在加工过程中突然报 EMC 故障主轴停转如何处理。这个问题涉及的信息点非常多设备型号、故障代码、故障现象、当前状态、可能的处理动作。它和文档里的描述不是一一对应的关系更像是一个多路召回的检索密度要求——既要在故障代码表里找到 EMC 的含义又要在操作手册里找到主轴停转相关的复位步骤还要在维修记录里找到同类型问题的历史处理方式。而且制造业问答对准确性的要求是硬性的。互联网问答答错一句用户可能笑笑划走设备维护场景答错一句轻则误操作重则停产甚至出安全事故。所以制造业 RAG 不能只做能找到相关片段它必须做到找到的片段可靠、来源可追溯、结论有依据。我自己在设计这个框架时定了一个底线原则不在只有 60% 把握的非结构化内容上去生成 100% 笃定的结论。很多场景下框架宁可告诉用户未找到足够依据请人工核实也不应该给出一个听起来无比专业但实际是模型编造的处置方案。1.3 通用嵌入模型在制造业术语上的力不从心很多人忽略一个问题通用中文嵌入模型训练数据里制造业的实体、术语比例太小了。你拿主传动箱油温异常花键磨损节流口堵塞这类文本去 embed得到的向量之间区分度很低检索时很容易把不相干的段落排到前面。这个框架在嵌入层做了领域适应用制造业语料微调了嵌入模型同时在索引侧引入了术语词典和同义词扩展。比如用户问主轴发热系统能自动把它扩展为主轴温升轴温过高主传动系统过热等近义表述缓解术语表达不对齐导致的召回失败。2. 框架的整体设计思路2.1 能力分层从工具链到场景方案这个项目在设计上分了三个层次第一层文档解析与知识加工层。负责把各种格式的制造业文档转成可检索的干净文本。核心能力包括PDF 扫描件 OCR、表格结构还原、页眉页脚过滤、图文切割分离、标题层级识别。第二层检索增强层。包含多路召回、混合检索、重排、动态上下文拼装等能力。多路召回指同一问题同时用向量检索、关键词检索、知识图谱查询三种方式找候选内容重排则用统一的 rerank 模型对多路结果做交叉验证筛掉语义相关但实际不解决提问的片段。第三层应用场景层。内置故障诊断、设备操作问答、维修辅助建议三个场景模板。每个模板都预先配置好了提示词策略、检索策略、结果呈现策略。比如故障诊断场景会要求框架输出可能原因 排查步骤 参考文档出处不接受直接给结论。为什么要做这种分层因为制造业项目和纯互联网项目有个本质区别每个工厂的 IT 基础设施、数据现状、业务口径都不一样。你给一套固定管线落地时一定被各种意外打穿。分层设计的好处是每一层都能被独立替换。某个客户的文档都是可复制文本的 PDF那就不需要 OCR直接把解析层换成轻量方案另一个客户的业务方只想要故障代码检索那就不接大模型生成只保留检索和排序直接把召回结果表格化。框架不绑定任何一层的能力下限让使用者根据实际场景裁剪。2.2 技术选型背后的权衡项目早期我在用现成大模型直接做问答和走完整的 RAG 管线之间犹豫了很久。最终选完整管线的原因很朴素直接丢给大模型做问答制造业文档的长尾问题根本答不准。模型对专业设备的理解本质上是统计分布它擅长编一个听感合理的回答但这种回答在没有文档约束的情况下无法验证对错。RAG 不是把大模型变聪明了而是强行给大模型加了一个如实引用资料的约束边界。在向量库选择上框架默认提供两类接口一类是本地化的轻量向量库适合单机部署和数据不出厂的场景另一类是标准的向量数据库接口适合数据量大、并发高的企业级部署。为什么保留两套因为制造业客户普遍对数据要不要出内网这个问题极其敏感很多企业连云端向量库都不接受。本地化部署虽然查询性能不如云端方案但胜在可控、合规、零数据泄露风险。嵌入模型也做了双轨设计。框架内置一个通用中文 embedding 模型同时提供了用制造业语料微调的脚本。我在一个电机生产线数据集上做过对比通用模型在故障诊断问题上的 Recall10 大概是 62%微调后模型能到 79%召回效果提升非常显著。做制造业 RAG微调 embedding 几乎是性价比最高的一步。2.3 为什么不做一个黑盒问答盒子项目设计过程中也有同行劝我说搞这么复杂干什么用户想要的就是一个输入问题、输出答案的盒子背后细节他们不关心。这个观点在消费级产品上成立在企业级知识管理场景完全不成立。制造业的工程师在故障诊断时不只是要一个答案他需要知道这个答案的依据是什么。同样一个主轴异响的问题维修老手和新手的差距就在于对依据的理解程度不同。所以框架在输出层面做了一个特别重要的设计每个回答都必须携带引用来源并且来源要精确到第几章第几节表格编号页码。没有来源的依据框架默认不纳入回答生成。这个设计一开始会降低系统的智能感——用户问个问题得不到一个随口答话的答案反而要跳转到文档上下文。但实测下来工程师群体对这个设计非常买账。他们本来就不信任凭空生成的答案看到每个结论都有出处反而更愿意把系统当工具用。3. 文档解析与知识加工层实现细节3.1 PDF 解析不能只靠通用库制造业文档解析最大的问题是把非数字化的信息变成可检索的文本。市面上的通用 PDF 解析库比如常见的几种 Python 解析方案在标准文本型 PDF 上表现不错但一遇到扫描件就束手无策。框架在这一层的策略是混合解析 多级降级第一级尝试直接抽取文本如果 PDF 自带文本层直接用不走 OCR。第二级如果检测到页面是整图常见于扫描版手册切图后交给 OCR 引擎处理。第三级模型输出存在大量重叠文本框时判定是复杂图文混排启用版面分析先识别阅读顺序再重组文本。这套逻辑里最容易被低估的是版面分析。很多扫描版手册是两栏排版印刷年份不同版式也会变化。如果你不做版面分析让 OCR 按物理坐标从左往右读两栏文字会全部交叉混在一起后续检索时完全没法用。框架默认采用了一个轻量级的版面模型先识别出标题、正文、表格、图片区域再按逻辑顺序拼装文本。3.2 表格结构化故障代码表的生命线故障代码表是制造业知识库里信息密度最高、也最容易解析出错的结构。我在这个项目上花时间最多的就是表格识别。以某种设备的故障代码表为例原始 PDF 中表格长这样故障码故障名称可能原因处理建议EMC-01主轴驱动异常变频器过载检查负载复位变频器EMC-02主轴驱动异常编码器信号丢失检查编码器连线重新插拔如果直接走文本抽取这四列数据经常被抽成一大段无法分割的连续字符串。框架里专门实现了表格三阶段处理检测表格区域、识别单元格坐标、按行列关系还原成结构化数据。还原后再和原文区域做双向映射保证之后引用时能定位回原始表格位置。我强烈建议做制造业 RAG 的朋友不要迷信某个通用表格解析库因为制造业表格的边框残缺率非常高。很多扫描版表格竖线是断的横线有位移通用算法很容易把整张表识别成一堆孤立的文字块。框架里对这类情况做了启发式修复先按文字块坐标聚类成分组再按 y 坐标投影划分行按 x 坐标投影划分列最后在行列交点处生成虚拟单元格。这个办法在边框不清晰的表格上反而更加稳健。3.3 图片和示意图制造业知识的重要组成很多设备手册里关键信息放在图上。比如液压系统油路示意图里标注了各阀的编号和位置——这些内容如果不处理检索系统面对液压系统第 3 号阀在哪里的问题会直接哑火。框架的图片处理策略是OCR 识别图中所有文字标注同时用视觉语言模型生成图片描述并把描述作为额外的文本块写入知识库。具体来说每个图片会生成两条记录一条是图片区域描述文本包含图片位置、主题、图中的文字标注一条是图文关联记录把图片所在章节的正文文本与图片描述建立链接。这样当用户问3 号阀的位置时即使正文没有明确提到图片描述里也会命中3 号阀这个关键词。这个能力在实操中挽救了非常多原本检索不到的边缘性问题。我在实际测试中还发现一个细节制造业图片的清晰度差异极大。部分扫描版图片分辨率只有 72dpi直接丢给 OCR 会丢失大量文字。框架在图片预处理阶段做了自适应升采样和对比度增强在识别前先把图片质量拉高再走 OCR 识别。这一步看似朴素但让整体文字识别召回率提升了约 12%15%。3.4 知识切分为什么不能一刀切 500 token制造业文档的段落结构差异太大固定窗口切块几乎是必踩的坑。同一段文本里操作步骤、安全警告、参数表各自的组织规律都不一样。框架默认采用结构感知切分先根据文档的标题层级切出逻辑章节再在章节内按语义边界列表标记、表格边界、段落间隔细分成块。切分时保留三级上下文信息设备型号、章节路径、相邻块的标题。这样检索到的每个片段都能回答这个内容是哪台设备、哪个章节下的内容用户拿到答案时可以直接追溯上下文。板块内粒度也做了差异化处理长段落文本按 300500 字切片表格则整个存入知识库、不做物理拆分。原因是表格一旦切碎行列关系就会丢失召回一个不完整表格没有任何实际价值。4. 检索增强层设计详解4.1 多路召回向量、关键词、知识库的三管齐下制造业问答单纯靠向量检索会遇到几个致命问题。首先故障代码一般是 EMC-01、LE-207 这种结构 embedding 模型对短代码的编码能力非常差其次设备维修时用户用的是口语化描述和文档里的书面语差距极大第三很多知识是结构化的故障码和处置建议的映射关系用向量检索去查结构化数据本身就是绕远路。所以在检索层框架默认启动三路召回向量检索针对语义匹配问题适合设备运行异常但用户描述模糊的场景。关键词检索针对故障代码、型号、编号类精确匹配用 BM25 和倒排索引做支撑。知识图谱查询针对设备、故障现象、原因、措施之间的关系性查询。三路结果召回后统一进重排阶段。重排不是简单把三路结果合并去重而是用交叉编码器cross-encoder对问题候选文档逐条打分。交叉编码器的优势在于它能把问题文本和文档文本同时输入模型计算相关性比双塔式的向量检索精度要高不少。代价是慢但重排阶段本来就只处理三路召回后的少量候选默认 Top 30性能完全可控。4.2 术语扩展消除说法不一致的检索黑洞制造业术语在不同厂家、不同设备、不同工程师群体里表述差异大到离谱。同一台设备的主传动箱温度过高在 A 厂的手册里叫主传动箱油温异常在 B 厂的工单里叫齿轮箱温度高在维修师傅嘴里可能就叫箱体发热。如果你不做术语归一检索系统检索箱体发热时和主传动箱油温异常片段之间的向量相似度可能连 0.5 都不到。框架内置了一个制造业术语词典支持自定义扩展。词典在查询阶段做两件事查询改写把用户输入的概念映射到文档中的标准表述扩展出多个检索词索引扩展对文档中的同义词建立指向关系让不同表述能检索到同一块知识。这个词典设计成可增量维护的。落地项目时通常的做法是先导入行业通用术语表再把设备手册中出现的高频实词抽取出来人工确认最后通过线上搜索日志积累没有覆盖到的新词。每增加一批术语检索质量的提升往往立竿见影。4.3 动态上下文拼装不是简单堆 Prompt很多 RAG 项目的上下文拼装就是把检索到的文本块拼进提示词里然后让大模型生成答案。这个做法在制造业场景会踩到几个坑检索结果里如果包含多台不同设备的段落大模型容易把不同设备的参数混在一起生成一个四不像的答案。如果检索到的段落里包含相互矛盾的处置方法比如一个说立即重启一个说重启前必须泄压大模型会自行调和但调和出来的内容很可能是文档中从没出现过的安全风险操作。框架的上下文拼装策略做了三层控制第一层按设备过滤。先识别问题中提到的设备型号只保留同一设备的知识片段。第二层冲突检测。对检索到的多个片段做语义比对如果发现同一主题存在矛盾表述不强行融合而是把所有片段原样呈现在候选列表里并标注该问题存在多种说法请参考原始文档。第三层相关性排序。上下文里并不总是放所有 Top 片段而是根据重排分数动态选择最相关的 35 个片段。多不代表好有时 5 个高质量片段比 10 个半相关片段生成的答案更准确。4.4 置信度机制让系统学会承认不知道这个设计是我自己最坚持的一点。制造业 RAG 正式落地时系统一定会遇见知识库覆盖不到的问题。此时有两种处理路径一种是硬着头皮生成答案一种是有机制地承认不确定性。我选择了后一种。整个链路里嵌了三处置信度判断检索端如果多路召回的得分普遍偏低说明知识库中缺少直接相关内容直接进低置信分支。生成端大模型生成答案后框架会做一次答案-依据一致性的自检比对答案中的关键实体是否都在检索片段中出现。如果答案里有知识库中不存在的处理措施自动标红提示。输出端对低置信结果不采用生成式回答默认模板而是切换到检索式反馈模板——直接展示检索到的相关片段和来源位置并提示用户系统未找到足够可信的答案以下为相关参考资料。这套机制运行下来框架的错误率大幅下降。用户对这个老实设计的评价远高于对聪明但胡说的设计。5. 实操过程从设备手册到故障诊断的完整落地5.1 一个模拟案例环境搭建我拿一个模拟的某型数控加工中心操作手册 维修记录数据集来演示完整落地流程。这个模拟数据集包含约 300 页操作手册其中约 120 页是扫描件、50 页故障代码表、200 条历史维修工单。环境配置上我用的是 8 核 CPU、16GB 内存的 Linux 节点本地跑向量库和推理服务。标准的制造企业内网服务器大部分是这个配置刻意不用云端大内存方案目的就是验证框架在普通硬件下的可用性。部署步骤安装框架检查依赖确认本地向量库可以正常启动。把 PDF 手册放入输入目录框架自动识别文件类型并启动解析流程。运行文档解析任务观察日志中每一页 PDF 的识别状态。解析完成后进入知识加工阶段检查切分数量、表格识别数量、图片描述数量。运行索引构建任务等待向量库写入完成。启动 API 服务进行问答测试。整个流水线从原始文档到可用问答服务大约耗时 40 分钟其中大部分时间花在 OCR 和 embedding 生成上。5.2 解析效果的关键检查项解析完成后不能急于上线。我通常会做一轮人工抽查重点检查这几个方面表格是否完整还原打开故障代码表的解析结果看每一行的列数量是否一致、是否有多列被合并。章节段落是否错乱随机打开几个章节看阅读顺序是否连贯、页眉页脚是否混入正文。图片描述是否准确抽查几张图片的描述文本看视觉模型是否把关键文字标注识别正确。在这个模拟案例中第一轮解析结束后发现故障代码表里有约 7% 的行存在列错位。排查后定位到了原因某一部分扫描页的表格线褪色严重启发式修复算法把两列误合并为了一列。处理方式是在该页做人工标注校正并把这一页的表格识别结果导出为带坐标的 JSON 格式存档后续迭代不再重复处理。5.3 检索效果测试故障诊断场景的真实问答框架内置了评估脚本可以自定义测试问答案例。我取三条典型问题进行测试每条标注了期望检索到的知识所在章节测试问题期望命中的知识是否命中主轴在加工中突然停转报 EMC-01怎么处理故障代码表 EMC-01 行 手册主轴复位章节是液压系统开机后压力持续偏低可能是哪些原因液压系统章节 常见故障原因列表是冷却液温度高会导致什么后果冷却系统章节是三条全部命中。查看重排后的上下文拼装结果确实把相关的代码表内容、操作步骤、安全提醒按逻辑放到了一起。输出答案时每条处理建议后面都附上了引用位置——比如EMC-01 故障代码参见《操作手册》第三章 3.2 节。这种带出处的回答在真实工程场景里才有说服力。5.4 这一版实现踩过的性能瓶颈第一次在低配机器上跑全链路时整体速度非常不理想。问题出在 OCR 阶段PDF 解析是单进程跑的遇上 120 页扫描件OCR 一页耗时约 3 秒光解析就花了将近十分钟。后来做了两处优化第一OCR 进程改为多进程并行按可用 CPU 核数分配页面第二对扫描页做了文本层检测发现已有文本层的页面直接跳过 OCR。优化后整个解析耗时压缩到 3 分钟内体感提升明显。向量索引构建也有瓶颈。通用向量库在插入大量小片段时底层索引的构建速度受限于写入批的大小。框架里把向量写入改成批量提交模式每批 256 条写入吞吐显著提升。6. 常见问题与排查心得汇总6.1 高发问题速查表问题现象可能原因处理建议扫描版 PDF 识别出大量乱码页面旋转角度未矫正开启自动旋转矫正对页面做 90/180/270 度检测表格解析后列数忽多忽少表格线不完整启发式归并逻辑失效导出中间结果定位问题页手动微调该页参数向量检索对短故障码无响应代码类短文本嵌入表征不充分启用关键词检索路保证故障码走精确匹配同一问题反复返回相同但不是最佳答案重排阶段打分区分度不足调整重排候选数量增加同义词扩展范围答非所问的幻觉答案上下文拼入过多无关片段启用冲突检测降低上下文拼接片段上限知识库里文档很多但检索命中率低切分粒度过大或关键表格被拆分改用结构感知切分表格整体入库6.2 排查思路先分环节定位再逐层解决遇到效果问题时我习惯按文档解析 → 索引阶段 → 召回阶段 → 重排阶段 → 生成阶段的顺序逐层排查不跳步。文档解析层的问题最容易暴露直接把解析后的文本打印出来看如果这段文本是人都读不懂后面所有环节的优化都是白费功夫。索引层的问题集中在字段设置检查索引字段分词是否适配、同义词映射是否生效。召回层的问题就对比三路结果哪一路召回了直接相关文档、哪一路没有基本能定位到向量模型或关键词配置的问题。生成层的幻觉问题优先检查上下文拼装和置信度策略不要急着换大模型。我自己最常用的一招是中间结果可视化把一次完整问答链路中每一个环节的输出都落盘然后逐个环节看数据。有一次用户反馈某设备问题回答不准确我打开中间文件一看发现问题出在设备名匹配——用户提问里用了设备的通俗名台钻而文档里全是标准型号编号向量检索根本关联不上。加了同义词映射后问题直接消失。6.3 几个容易被忽略但很致命的细节这个项目做到后期我总结出几个通用文档里不会写、但实战中非常关键的细节一是关于编码规范。制造业文档里大量夹杂全角半角符号、特殊单位符号、复杂的括号嵌套。解析后清洗文本时如果统一把全角转半角会把某些单位符号如 Ω、μF也破坏掉。清洗阶段必须做针对性的白名单保护把单位符号、法定计量符号、设备型号中的特殊字符明文保留。二是关于时间口径。维修工单是有强时效性的数据。框架在索引阶段会提取每个工单的时间字段并把时间作为召回后的过滤条件。用户问这台设备最近 3 个月出现过多少次报警如果没有时间过滤能力系统只能做全局统计结果完全不可信。三是关于安全警告的处理。设备手册里的安全警告内容不应该进生成链路。原因是在生成答案时安全警告往往会被模型当作普通上下文处理导致语气弱化、重点丢失。框架默认把标注为危险警告注意的段落单独入库检索时只在用户问题明确涉及安全风险时才召回否则宁可漏检也不稀释其他内容的重要性。7. 开源框架的边界与适用性说明7.1 适合什么场景、不适合什么场景用一句话概括如果你的知识库是结构化程度低、以设备手册和维修记录为主的文档集且你的核心诉求是从文档里找到依据、辅助人做判断那么这套框架的性价比非常高。它特别适合设备运维辅助、售后技术支持、内部知识管理这几类场景。反过来有两个场景不适合硬上。一是内容量极少比如只有一份 20 页的说明文档这套流程的完整链路反而显得笨重直接做关键词搜索就够了。二是对实时性要求极高的场景设备一旦报警需要毫秒级响应时纯粹的内容检索框架并不是最合适的方案。这种场景需要实时数据接入和规则引擎配合RAG 只是辅助不应该做主角。7.2 落地的正确姿势从试点场景切入如果要在企业里落地这个框架我的建议是不要一上来就想着覆盖全厂所有设备和所有知识。先选一个知识库质量较高、业务痛点清晰的试点场景比如某类核心设备的故障诊断跑通之后再复制到其他产线。原因是 RAG 项目的效果高度依赖知识库本身的质量和覆盖度。你铺得越广知识库里的脏数据越多最终效果反而越差。试点的过程中有一个容易被忽略的环节找真实用户做种子问题收集。不要只搞一两百条测试问题要去找机修师傅、设备工程师、售后人员问他们日常真实会搜什么问题。这些真实问题中大约有 15%20% 会暴露知识库的盲区或检索策略的不足它们才是调优的真正引擎。结语性质的补充项目现在仍然在迭代中这个框架并不是制造业知识问答的完整终点。我自己测试下来体会最深的一点是RAG 这个技术在制造业落地最缺的不是某个模型的聪明程度而是对领域数据本身的理解和处理能力。文档解析、术语归一、表格还原、置信度控制哪一个环节没有做好后面的模型能力再强也补救不回来。如果你准备在自己的场景里试这套思路我的建议是先拿一小批真实手册跑一遍完整的链路观察中间产物质量再逐步扩大规模。不要跳过检查中间结果也不要相信一键构建就能产生可靠的知识库。数据质量和处理管线的打磨才是制造业 RAG 真正的护城河。后面如果大家感兴趣我再单独写一篇关于制造业领域 embeddings 微调的具体方法和效果对比以及怎么设计一套适用于工厂环境的离线评估集。那部分内容我在这个项目里积累了不少干货值得单独展开。