制造业的师傅们都知道设备一停产线等着领导催着维修工单堆成山这时候最怕的就是翻手册、找图纸、问了一圈没人说得清故障代码的含义。这个大模型智能问答项目就是冲着这个痛点去的——把分散在老师傅脑子里的经验、设备手册里的参数、历史工单里的处理记录统一收进一个问答系统里让维修工在现场通过自然语言提问就能拿到可执行的答案。我当时参与落地这个项目的时候踩了不少坑从知识库搭建到检索调优都有一些值得复盘的地方这篇就完整拆一遍给正在做企业知识库问答的团队一些参考。这个场景其实非常有代表性。很多人一提到大模型就想着让它写诗、写代码但放到制造业里它真正值钱的能力是“把知识变成生产力”。同样是QA面向C端闲聊和面向产线维修完全是两码事维修场景要的是准确、可溯源、能立刻指导动作。如果你的团队也准备在企业内部做大模型应用尤其是知识密集但数字化基础一般的制造场景这篇文章值得收藏。1. 场景拆解制造业设备维修到底需要什么样的问答系统我一开始以为设备维修问答就是“拿一本手册喂给大模型然后它就能回答”真正接触了现场之后发现完全不是这个逻辑。你得先搞清楚谁在问、问什么、怎么判断答案好不好这三件事决定了整个系统的设计方向。1.1 三类用户、三种问法决定系统的交互设计制造业设备维修场景里面向的用户大致可以分成三类他们提问的习惯和需求都不一样。第一类是产线操作工。他们的典型问法是“这台机床报警代码2013是什么意思”“液压站油温正常范围是多少”“更换滤芯需要停机吗”。这些问题相对简单答案在手册里基本都有原文但操作工往往没时间也不愿意去翻几百页的PDF。他们对系统的核心诉求是快速、准确、直接给结论。第二类是维修工程师。他们的问题要复杂得多典型问法是“主轴异响伴随振动值偏大可能是什么原因”“A轴伺服报警后复位不了除了排查电缆还能查什么”。这类问题没有标准答案需要综合多个知识源甚至要基于故障现象做推理。系统如果只给一段手册摘录很难满足他们的需求。第三类是设备管理员。他们问的是“最近一个月哪类故障发生频次最高”“某个型号的变频器更换周期怎么定”。这已经上升到设备管理和预防性维护的层面了对系统的要求更高——不仅要知道知识还要能结合工单数据做统计分析。有意思的是这三类用户对“答案好不好”的判断标准完全不同。操作工觉得“20秒内给出三步操作”就是好答案维修工程师能容忍答案长一点但必须包含排查路径和判断依据设备管理员则更看重答案是否有数据支撑。设计问答系统的时候不能只用一套Prompt和一套交互逻辑去满足所有人而是要允许用户选择答案深度或者通过追问来细化。1.2 盘点知识资产维修手册、工单记录和老师傅的经验建问答系统之前最重要的一步是盘点企业里到底有哪些知识可以被利用。很多制造企业做数字化转型最不缺的就是数据缺的是把这些数据变成“知识”的整理能力。维修场景的知识源大概有这几类设备手册和操作说明书包括机械部分、电气部分、液压部分通常以PDF形式存在页数从几十页到上千页不等。这是最基础、也最容易“喂”给系统的语料。故障代码表这是非常关键的结构化知识。每台设备都有自己的故障代码体系代码含义、触发条件、处理建议一目了然。历史维修工单工单是宝藏记录了真实的故障现象、排查过程和处理结果。但工单质量参差不齐有的写得很详细有的就一句话“更换了传感器”。标准作业流程SOP与点检表这部分知识决定了维修动作是否规范问答系统在给出建议时如果能关联到对应的SOP答案的专业度会明显提升。老师傅的经验这部分最难处理。经验往往不成文存在于老维修工的脑子里和笔记本上。我们当时是通过访谈、整理故障案例库的方式把口头经验转成文字条目再归入知识库。盘完这些资产之后你要做一个非常重要的判断哪些知识适合进知识库哪些不适合。我们的原则是“有据可查的进口口相传的先整理再进”。比如“这台设备老毛病多经常是PLC电池没电”——这种经验可以整理成故障案例条目但必须注明是非官方经验系统返回答案时要加以区分避免误导。知识资产盘点完成后你会得到一张知识地图明确各类知识的格式、质量和更新频率。这一步做好了后面知识库构建才能有的放矢否则就是一股脑把文档丢给模型结果检索出来一堆噪音。2. 方案选型为什么是RAG而不是微调技术栈怎么搭聊技术方案之前先说一个常见的误区。很多团队一上来就想着“要不要微调一个自己的大模型”这个方向在这个场景里大概率是走不通的。微调适合的是改变模型的行为风格或特定任务的输出格式而不是给它注入新知识。制造业设备维修的知识是高度动态的——设备升级了、工艺改了、新故障出现了如果靠微调去更新知识每一次知识变化都要重新训练成本和时间都不可接受。RAG检索增强生成才是这个场景的正确答案。它的核心思想很简单不把知识存在模型的参数里而是存在外部的知识库中用户提问时先从知识库检索出相关内容再让大模型基于这些检索结果来生成答案。这种方式的好处有三个知识可以随时更新、答案可以溯源、幻觉问题能被有效控制。2.1 RAG架构的整体流程和核心模块一个标准的工业级RAG系统链路大致是这样离线阶段文档加载 → 文档解析与清洗 → 切分 → 向量化 → 存入向量数据库同时建立倒排索引用于关键词检索。在线阶段用户提问 → 问题理解与改写 → 检索向量检索关键词检索 → 重排序 → 构造Prompt → 大模型生成 → 答案后处理与溯源展示。每一步都有各自的坑。我一个个说。文档加载与解析这一步制造业场景里最大的问题是PDF格式五花八门。有的是文本型PDF可以直接提取文字有的是扫描件需要OCR光学字符识别还有的是CAD图纸导出的PDF里面全是矢量线段提取出来根本没法用。我们当时用了一套组合策略文本型PDF直接提取扫描件用OCR服务识别实在复杂的图纸类文档直接放弃全文识别只录入图纸编号和标题作为检索元数据使用。文档清洗没做好后面全白搭。我举个例子设备手册里经常有“注意”“警告”“小心”这类警示词在原文里是带有特殊格式的提取出来之后格式丢了文字混在一起切分出来的片段语义就不完整。还有一些手册使用了多层级的目录结构自动提取时目录和正文会混在一起。这些都需要清洗规则去处理比如识别页码、去掉页眉页脚、合并因格式断裂的段落。2.2 技术栈选择向量模型、向量库和大模型的搭配技术栈怎么选直接关系到成本和效果。我分享一下我们在实际项目里用的配置以及为什么这么选。向量模型选用了一个中文效果较好的通用向量模型维度是1024维。为什么不用更大的模型因为在制造业问答场景里文档主要是中文技术文档专业术语密集。通用向量模型对古文、诗词、网络用语这些可能不擅长但技术文档属于它见得比较多的内容效果足够。另一个考虑是硬件成本和推理速度向量模型越大召回越慢在产线现场的使用体验会差很多。向量数据库选择了开源的Milvus。选它的原因主要有几点一是支持混合检索可以把向量检索和标量过滤结合起来用比如按设备型号过滤这个能力在制造业场景里很实用二是社区活跃问题好排查三是支持常用的索引类型比如HNSW在千万级数据量下也能保持毫秒级召回。大模型当时选了通用大模型的API没有做私有化部署。原因很简单设备的故障代码表和维修手册属于企业的核心数据资产直接调外部API确实有合规风险。我们是先做了数据脱敏和安全审查再通过企业的私有网关去调用确保请求记录可审计。如果你所在企业数据敏感度极高那就只能考虑私有化部署开源模型成本会高不少但可控性更强。工具方面还要补充一个重排序模型Reranker。检索阶段拿回来的top-k个片段可能顺序不合理相关性高的混在后面重排序模型的作用就是把它们重新排一遍让最相关的内容排到最前面这能显著提升答案质量。我们用的是bge-reranker-large效果不错。这一段技术栈选型完成后我建议团队做一个小的效果验证先建一个只包含2-3台设备手册的最小知识库跑通整条链路看端到端的回答质量和延迟。这个小验证能帮你发现很多问题比如PDF解析失败、切分不合理、检索召回为空、大模型不按照Prompt要求回答等远比直接铺开做要划算得多。3. 知识库构建从原始资料到高质量可检索语料知识库构建是整个系统里最耗时、也最决定成败的部分。大模型问答的下限取决于检索检索的下限取决于知识库质量。我再强调一遍如果没有一个干净、结构化、覆盖完整的高质量知识库后面所有环节都是空中楼阁。3.1 文档切分策略你是“一刀切”还是“按结构切”文档切分是RAG里最容易被低估的技术细节。切得太粗每个片段包含太多信息向量化之后语义会被稀释检索精度下降切得太细一个完整知识点被拆成好几段检索结果就会出现碎片化大模型拿到的是不完整的上下文。我的建议是“按结构切分优先兼顾长度”。比如设备手册通常有明确的章节结构1. 概述 2. 技术参数 3. 安装调试 4. 操作说明 5. 维护保养 6. 故障排除。你可以先用结构识别把文档切成章、节、子节然后在每个最小语义单元内部如果文本还是太长比如超过模型Token限制再继续切分同时保留相邻片段的重叠。具体来说我们当时的切分参数是这样的最大片段长度500个字符大约750个token重叠长度80个字符。但这个参数并不是万能的需要根据你的文本特点来调整。设备手册里技术参数表很多表格被切成几块之后每一块单独看都不完整这时候就要对表格做特殊处理——把表格转成Markdown格式尽量整表保留在同一个片段里。还有一个很关键的细节不要把目录、页眉页脚、纯空白页这些东西切进来否则检索结果里会出现大量无意义的内容。我们当时在清洗阶段就做了规则过滤把明显是目录的文本块特征是连续行都只有标题和页码直接删除这些噪音虽然不会导致严重错误但会稀释检索结果的密度。3.2 元数据设计让检索多一个“过滤器”知识库不只是把文档切碎了存进去就完事还要给每个片段挂上元数据。制造业场景里这类元数据特别重要设备型号比如某系列加工中心、某系列注塑机。有了这个过滤条件检索时可以只搜对应设备的文档大幅提升精度。文档类型是操作手册、故障代码表、还是工单记录。不同类型的文档在答案可信度上权重不同。故障代码故障代码表里的每个条目都对应一个代码这个可以直接作为标量字段。更新时间设备手册常有版本更新检索时最好能优先返回新版本的内容。知识等级官方文档、经验整理、还是维修案例在生成答案时可以让模型注意区分。有了这套元数据之后你可以实现一个非常有用的功能用户在提问时系统可以自动识别问题中涉及的设备型号然后把检索范围锁定到该设备的文档子集里面。比如用户问“加工中心主轴异响怎么排查”系统识别出“加工中心”这个设备类型就优先在加工中心相关手册和案例里检索过滤掉其他设备的无关内容。这一步对精度提升的帮助非常明显。3.3 向量化与混合检索的配置细节向量化这一步要注意的不只是“把所有文本转成向量”而是“如何保证不同来源的文本在向量空间里有区分度”。设备手册里的专业术语和通用中文的词向量分布差异很大如果直接混合可能会出现语义偏移。我当时选择一个稳妥的做法先做一遍文档分类把语料分成“手册类”“故障代码类”“工单案例类”“经验整理类”四个大类每一类单独建立索引空间。查询的时候根据问题的类型走对应的索引。比如故障代码类问题优先检索故障代码表现象排查类问题优先检索工单案例和经验整理。这个做法虽然增加了一点工程复杂度但效果非常明显——答案的相关性和准确性都比“一个索引打天下”高出不少。混合检索是另一个提升点。纯向量检索在制造业技术文档里有个天然弱点专业术语的“同义改写”能力有限。比如用户说“电机不转”手册里写的是“电动机无法启动”向量检索可能只搜到“电机”相关的片段未必能把“无法启动”关联起来。所以还要叠加一层BM25关键词检索把字面匹配的结果也召回然后通过重排序模型把两路结果合并排序。我给大家一个参考配置向量检索召回top-20关键词检索召回top-10合并之后去重再经过重排序模型取top-5。这个参数搭配在多数场景下效果比较稳定。这里说的数量和具体业务有关如果你的知识库规模很大或者问题类型很杂可以适当调整。混合检索做完之后还要处理一个问题检索结果之间的上下文连贯性。有时候top-5的结果虽然每一条都相关但它们分别来自不同的文档章节相互之间没有逻辑关联。大模型拿到这些片段后可能生成果断但论据不足的回答。解决方案是做一个“片段扩展”把命中的片段所在的整节内容一并取回作为上下文。比如命中了一个故障排查步骤的一小部分就把整个排查步骤完整拿过来确保上下文完整。3.4 知识库更新的“保鲜”机制知识库如果建好之后就一劳永逸三个月后基本就废了。制造业现场变化快设备软件升级、维护周期调整、新的故障模式出现都需要知识库跟着更新。我们当时的做法是建立知识库更新的“定时触发”双机制。定时每周自动扫描指定目录检查有没有新增或修改的文档有变化就执行增量向量化并更新元数据。触发当工单系统里出现新的故障代码或新的处理方案且被标记为“已验证”时自动追加一条知识片段并标注更新时间。还有一个细节点值得说知识库更新不只是增加新文档还要处理老文档的“下架”。设备手册的旧版本如果和新版本冲突应该设一个“版本生效时间”字段让系统默认检索新版本的内容旧版本仅作为备选。否则新旧表述混在一起大模型会无所适从。4. 问答链路实现Prompt设计、引用溯源与权限控制知识库搭建完成之后就要面对整个系统中直接和用户体验相关的部分——问答链路。这里包含Prompt工程、答案结构化、引用溯源、权限控制这些环节任何一个做得不到位都可能让前面的努力白费。4.1 系统提示词把大模型“约束”成维修顾问很多团队写Prompt就是三行字“你是一个助手请根据以下内容回答问题”。这种Prompt在制造业维修场景里完全不够用。你想想大模型如果没有约束它会自己发挥把搜索引擎里看到的内容或者自身训练数据里的知识混进来甚至回答“根据我的理解”这种话。在维修场景里这是绝对不能接受的。我们的系统提示词大概这几个部分组成角色定义、回答规则、输出格式、约束条件。角色定义要明确“你是某工厂设备维修知识助手”回答规则要强调“只基于给定的检索内容回答如果检索内容不包含答案明确说不知道”输出格式要定义“故障排查类回答必须包含原因分析、排查步骤、参考文档编号”约束条件要写明“不要编造参数不要给出超出知识库范围的维修建议”。这里我提供一个简版Prompt模板供参考你是一名经验丰富的工业设备维修顾问。请基于【检索片段】中的内容回答用户问题。 要求 1. 只使用【检索片段】提供的信息不得使用模型自身知识补充 2. 如果【检索片段】无法回答问题回复“库中没有找到相关答案请上传相应设备手册或联系设备工程师” 3. 回答需包含具体操作步骤步骤编号清晰 4. 对于故障排查类问题请按“现象确认-原因分析-排查顺序-处理建议”的结构组织回答 5. 涉及参数压力值、温度值、转速等必须原样引用不得近似改写 6. 在回答末尾列出引用的文档编号和片段页码。这套Prompt看起来简单但实际调优过程花了不少功夫。最大的教训是不要写“如果不知道请回答抱歉”因为模型会非常频繁地道歉哪怕它其实检索到了内容。你要给它一个明确的兜底策略而且“兜底”本身也要有实用价值——引导用户下一步怎么做而不是干巴巴地道歉。4.2 答案结构化与引用溯源维修场景的答案不能是一段纯文本最好是有结构的、可执行的。我们在设计输出格式的时候把答案分成了三种类型分别对应不同的输出模板参数查询类输出“参数名称标准值 / 允许范围 / 注意事项”用表格呈现。操作指导类输出“准备工具 → 操作步骤分步 → 安全注意”步骤必须带序号。故障诊断类输出“可能原因列表按概率排序 → 排查方法 → 处理措施 → 验证方式”。结构化输出的好处是肉眼扫一遍就能定位到关键信息而不是在一大段话里找重点。这个在产线现场尤其重要——维修工通常是边看手机边操作目光在屏幕和设备之间来回切换要是答案是一大段话他根本来不及读。引用溯源是这个场景的红线要求。维修人员用问答系统是基于对系统的信任做事如果系统给出错误建议可能造成设备二次损坏甚至人身安全风险。所以每条回答必须标明信息来自哪份文档、哪个章节、哪一页。我们在前端展示时用了角标引用把文档编号和页码跟在结论后面用户可以点击查看原文。这个做法不仅提升了可信度也大大方便了后续的知识审核。4.3 权限控制不同角色看到不同知识边界企业内部的知识并不都是可以公开查询的。有些核心工艺参数操作工不该看有些商业敏感的设备改造方案外部供应商不该看。所以在问答系统的设计里权限控制不能省。我们的做法是在知识库的元数据上增加“可见范围”字段分为“公开”“维修组”“管理员”三个级别。检索时系统根据当前用户的角色过滤检索范围没有权限的知识片段直接不出现在召回结果里。这个方案比“生成之后再过滤”要靠谱因为大模型生成阶段的不可控性太大在输入端就把关才安心。有一个实施细节值得注意权限控制的粒度不要做得太细。我见过有的团队把权限切到段落级结果检索效率大幅下降而且管理成本很高。一般来说做到“文档级”或“安全类别级”就够了制造业场景里不太需要更细的粒度。4.4 对话历史与多轮追问的处理维修场景中一次问答往往不够。用户会基于上一个答案继续追问比如先问“主轴异响怎么办”得到答案后再问“排查到轴承间隙过大怎么换轴承”。这个多轮能力如果处理不好第二问往往就答非所问了。处理多轮问答的常用策略是“问题改写”。在把用户当前问题送入检索之前先用大模型基于之前的对话历史把当前问题改写成一个独立的完整问句。比如上面的例子第二问“怎么换轴承”被改写成“主轴轴承间隙过大时更换主轴轴承的具体步骤是什么”然后拿这个改写后的问题去检索。问题改写要注意控制历史对话的长度。我们当时的做法是只保留最近的3轮对话用于改写超出部分直接丢弃。原因是对话历史越长改写模型会越困惑而且会产生内容漂移把早期对话中的噪音引入当前检索。3轮是一个经验值你可以根据实际效果微调。5. 实测效果与踩坑记录现场问答实录和常见问题排查方法项目做完不能只看演示DEMO要在真实产线上跑一段时间才能见真章。这一节我复盘几个典型的问答案例再把我们遇到过的典型问题整理成一个问题排查表给后来者一些参考。5.1 三类典型问答的实测分析第一个案例是操作工的高频问题“注塑机炮筒温度偏差超过±5度怎么处理”。系统返回答案结构为先给出温度偏差的标准范围来自手册技术参数表再列出可能的偏差原因排序加热圈老化、热电偶接触不良、温控模块PID参数漂移最后给出对应的检查步骤。这个答案格式很理想操作工不需要翻手册就能直接按顺序排查。这个案例背后用到的是“参数查询故障诊断”的混合链路检索召回的是手册的参数表和故障排查章节重排序后取到了最相关的5个片段Prompt结构也适配了故障类问题的输出模板。第二个案例是维修工程师的中级问题“CPK值不稳定且有周期性波动可能是哪里的问题”。这个问题没有标准答案。系统检索后发现知识库中有一篇经验整理的案例描述的场景很接近同时召回了一条工单记录。系统结合两段内容给出了“检查液压系统压力波动→检查伺服电机反馈信号→检查机械传动间隙”的排查顺序并备注“本建议综合自内部维修案例未经设备厂商确认请谨慎参考”。这个备注是Prompt里约束的目的就是让经验类回答和官方手册类回答分开避免误导。第三个案例是边界情况的处理“某个操作工问了一个完全不在知识库里的型号”。系统兜底策略生效回复“库中没有找到该型号的相关资料请确认设备型号或联系设备管理员补充文档”。实测下来这个兜底场景出现的频率比想象的高因为制造业设备更新换代后老型号的文档可能还是纸质的没有归入系统。兜底策略加上“引导上传资料”的功能能够把知识缺口暴露出来推动知识库的持续完善。实测下来整个系统从提问到答案生成完毕平均耗时在2.8秒左右其中检索和重排序耗时占比超过一半生成反而很快。用户反馈最满意的是引用溯源功能——他们在确认关键参数时可以直接点开原文而不是像以前一样凭经验猜。5.2 高频问题排查速查表检索失败、幻觉答案、耗时过长做这个项目半年多团队踩了不少坑。我把典型问题整理成一张表方便后来者按图索骥。问题现象可能原因排查手段解决建议检索结果完全无关回答答非所问切分粒度过大语义被稀释或问题改写失败检查检索片段的词嵌入相似度看top-1结果与问题的相关性调小片段长度检查问题改写模型是否需要补充上下文答案里出现知识库之外的参数系统提示词未充分约束检索片段里混入了网页抓取的噪音数据逐条检查检索片段确认来源复现时查看检索命中的文档编号强化Prompt约束增加“不得使用自身知识”的字段清洗阶段加强噪音过滤同问题不同日期的回答差异大知识库更新后旧版本未下架向量检索排序不稳定对比两次回答使用的检索片段看是否有版本混用建立版本生效时间机制检索时按时间过滤调优重排序参数回答太慢超过5秒召回量太大或重排序模型推理慢查看每一阶段的耗时日志定位瓶颈在召回层还是排序层降低top-k召回数量换更轻量的重排序模型开启向量索引量化同一个问题多次追问后跑偏多轮会话历史过长导致问题改写失真检查改写后的独立问句是否偏离原意限制历史轮次为3轮增加改写结果的置信度判断低置信度时退回单一问题检索部分敏感数据泄漏在答案中权限过滤未生效检索范围未按角色裁剪检查用户角色与知识元数据的权限字段是否匹配在检索层强制加入权限过滤条件而不是在生成后过滤这张表是我们在实践中摸索出来的不一定覆盖所有情况但至少能帮你少走弯路。我现在还记着一个很深刻的问题有一次系统对“液压油更换周期”返回了两种互相矛盾的答案一个说1000小时一个说2000小时。排查原因发现是知识库里同时存在设备手册的旧版和新版旧版写的是1000小时新版因为工艺改进改成了2000小时。我们的版本生效时间机制没有完全覆盖这种情况导致检索时新旧版本被同时召回。后来我们专门加了一个规则当同一文档存在多个版本时低版本号的段落默认不参加检索除非用户显式指定要查看历史版本。这个教训告诉我们知识库的“保鲜”不只是新增数据那么简单更要管理好数据之间的冲突关系。6. 还有一件重要的小事去钓鱼、盘点知识库、搭一个回归测试集项目上线之后我强烈建议团队做三件“不起眼但影响深远”的事。第一件事是建一个回归测试集。你改了一个Prompt参数、换了一个重排序模型怎么知道效果是变好了还是变差了不能靠感觉要在固定测试集上跑一遍看分。我们的做法是从真实用户的问题里抽样了大约200条覆盖三类用户和三种问题类型每一条问题都人工标注了标准答案和关键评分点。每次系统迭代后就在这个测试集上跑一遍计算命中率、完整性和格式合规率。这个测试集是整个项目迭代的“方向盘”没有它后面的优化就是在盲人摸象。第二件事是知识库的内容盘点要定期做。我们每季度会导出一份知识库报告看每个设备的文档覆盖率、用户的未命中问题Top50、新增资料数量。这些数据看起来不起眼但它们会告诉你哪些设备的知识还是一片空白哪些用户问的问题系统答不上来。设备维修的知识库不是建完就完了它是需要持续运营的资产。第三件事是线下知识库和线上问答系统的联动。我们后来把问答系统里“未命中”的问题自动导出成工单发给对应的设备工程师请他们补充资料或给出答案。这样形成了一个闭环系统发现问题→人补充知识→系统更新知识库→下次回答命中。这个机制跑通了之后整个系统的命中率在一个季度内提升了差不多10个百分点效果非常显著。我最后想说一个心得体会。做企业级大模型应用最让我意外的不是模型能力本身有多强而是“把人找对、把数据理清、把流程跑通”这三件事有多关键。我们花在清洗手册、整理工单、访谈老师傅上的精力和对大模型及RAG的调优精力相比大概是三比一。但恰恰是那三份的投入决定了最后效果的上限。技术只是工具知识才是核心资产这个认知在整个项目做完之后变得特别牢固。如果你的团队也在规划类似的智能问答系统我的建议是别急着上模型先花一个月走访现场、盘点文档、弄清用户真正的提问习惯这一个月不会白费。