刚把一个“设备维修智能问答系统”从概念推进到产线实地运行，这个项目让团队印象很深。大模型在企业里的落地，真正难的地方往往不在模型本身，而在怎么把企业内部的知识管好、检索准、生成稳。我们做的是制造业设备维修场景——生产车间里，一线维修工直接在终端上问“三号注塑机液压油温过高怎么排查”，系统会给出结构化的排查步骤、可能原因、参考案例和对应手册出处，不再需要抱着几百页的PDF翻半天。

这篇文章把这个项目从需求拆解、技术选型、知识库构建、系统实现到现场效果评估、疑难排障，完整复盘一遍。它不是通用的大模型科普，也不是纯粹的AI代码教程，而是把一个面向制造业产线的智能问答系统从头到尾怎么搭、怎么调、怎么踩坑的过程讲清楚。适合正在做企业内部知识库、AI问答助手、RAG应用落地的开发者，也适合制造业IT、设备管理、精益数字化团队参考。不管你是要自己复现一套，还是评估这个方向值不值得做，这里面应该有你能直接用的东西。

1. 项目背景与核心需求拆解

1.1 为什么偏偏是设备维修这个场景

制造业的设备维修是个典型的高价值、强知识依赖场景。一线维修工每天面对的问题是：设备突然报警停机，需要快速判断故障点。这种时候手册未必来得及查，即使查了，手册里的标准描述和现场实际故障往往对不上。更麻烦的是，大量维修经验沉淀在老师傅脑子里——哪个型号的设备爱出什么毛病、哪种异响一般是轴承问题、哪个阀块漏油先查O型圈。这些经验若能系统化传承，能显著缩短故障排查时间、降低误操作风险。

从企业角度看，维修知识的资产化已经提了很多年，但一直没做好。设备手册、标准作业流程、历史维修工单分散在文件服务器、旧OA系统、纸本记录里。工单记录很多就是几行字的登记：“X301停机，换了个传感器好了”。这种记录的价值完全没被挖掘。大模型恰好能把这些零散的、非结构化的资料变成一个可对话的知识服务。

另外一个重要原因是停机损失太直接。关键设备停机一个小时，可能直接就影响到当批订单交付。维修工凭经验排除故障的平均时间如果缩短哪怕十分钟，在一个多班倒的车间里，一年积累下来都是实打实的效益。车间主任和技术主管愿意为这种系统投预算、给资源，这也是项目能推进的前提。

1.2 要的不是“能聊天的AI”，而是“能用的问答工具”

这个项目启动前，团队内部先明确了一个原则：不在制造现场做一个“智能玩具”。一线维修工没时间跟聊天机器人寒暄，他们需要的是输入故障现象之后，直接看到“可能原因—排查步骤—操作注意事项—参考案例”这样的结构化答案。

核心需求整理下来有几条：

• 回答必须基于企业内部资料，不能凭空编造。故障排查涉及安全，错误建议可能带来严重后果。
• 回答要带出处。告诉维修工“这个判断来自哪个手册哪一章、哪个历史工单”，他才会真正信任系统。
• 不确定的时候要承认不确定。资料库没有覆盖的问题，直接说“暂无相关资料”，而不是硬答一通。
• 操作建议要安全合规。涉及断电、高压、拆装等操作，必须有安全提示，高危场景不能乱给建议。

这也是后来技术选型的出发点。通用大模型效果虽好，但不了解企业内部设备型号，不知道历史故障规律。直接拿通用模型问“X301设备”，它只会给出泛泛的工业维护建议，对现场没有实际价值。真正可行的是把企业知识库和检索增强生成（RAG）结合，让模型在回答时引用企业自己的资料。

2. 技术方案选型与整体架构

2.1 为什么选RAG，而不是微调大模型

很多人一上来就问：为什么不做微调？我的回答是：对这个场景，RAG的优势远大于微调。

第一个原因是知识更新速度。设备维修的手册会改版，新的故障案例每天在产生。RAG的知识存在向量库里，更新文档时重新构建相关索引就行，几分钟完成。微调则需要准备训练集、训练、评估、部署，一套流程下来周期长成本高，维修案例还在不断增长，不可能每个月做一轮微调。

第二个原因是可溯源性。RAG生成时明确告诉模型“只基于这些检索到的片段回答”，回答后可以把引用来源展示给用户。微调模型的知识是隐性的，你很难让它准确说出“这个结论来自哪份文档”。对维修场景来说，可溯源几乎等同于可信度。

第三个原因是对幻觉的约束能力。虽然RAG也不能完全消除幻觉，但至少可以把模型的自由度限制在检索到的知识上下文内。如果没有检索到相关片段，系统可以直接短路掉生成环节，告诉用户“没找到”。这种可控性是纯微调无法提供的。

当然我不是说微调完全不能用。如果要做的是一个小范围、固定场景的专项工具，比如只针对某一种型号设备的故障诊断分类，数据量充足且规则相对固定，微调是可行的。但我们这次的目标是覆盖一个车间多类设备的知识问答，范围一直在扩展，RAG无疑是更合理的主线。

2.2 整体技术架构

这个系统的整体架构并不复杂，核心分为离线和在线两条链路。

离线知识处理链路的任务是：把企业内部零散的文档、工单、记录变为可检索的向量索引。流程是：多格式文档导入，解析文本，清洗，按结构切分，向量化，写入向量库。这个链路可以每天定时跑，新工单进来后自动增量更新。

在线问答链路的任务是把用户的提问转化为可信的回答。流程是：用户输入问题，先做查询预处理，再分别走向量检索和关键词检索，多路召回后合并去重，重排序，把筛选出的知识片段与Prompt拼装，交给大模型生成，最后做输出校验，把结果以结构化卡片形式返回到前端。

两个链路的关系可以理解为：离线链路负责“把书整理好放进书架”，在线链路负责“根据读者的问题快速找到相关页码并组织成回答”。书架质量决定了回答质量的上限，检索质量决定了你能达到这个上限的多少。

2.3 关键组件选型与理由

大模型推理服务：考虑到制造企业的数据敏感性和网络边界，不适合把所有内部资料请求送到外部API。最终选择私有化部署，基于开源底座微调增强中文能力的衍生版本，使用70亿参数级别的量化模型部署在内网GPU服务器上。实测效果在设备维修问答场景足够用。如果对长文生成和复杂推理要求更高，可以换百亿级别模型，代价是显存和推理延迟上升。

向量数据库：选的是自托管的开源向量库，部署在普通Linux服务器上。选择原因很简单：社区活跃，接口标准，支持HNSW索引和向量+标量混合过滤，能满足按车间、按设备类型过滤访问权限的需求。数据量在百万级向量以下时性能完全够用，不需要上分布式方案。

Embedding模型：最初用通用中文Embedding模型，效果基本可用，但在专业术语区分上偏弱。例如“溢流阀”和“减压阀”在语义空间比较接近，通用模型容易混淆。后续利用企业内部的设备术语表和故障记录，对Embedding模型做了小规模领域的继续训练，区分度有明显提升。这一步属于锦上添花，初期可以不做，但要留出优化空间。

前端与交互：简化到极致。就是一个内网网页应用，打开直接是输入框。支持拍照上传设备铭牌或报警代码，自动识别后跳转到对应设备的维护知识。这个功能后期加的，一线反馈很实用。

3. 设备维修知识库的构建细节

3.1 数据来源与清洗难点

知识库的数据来源比想象中杂：

• 设备使用手册和维护手册，PDF格式，大量是扫描件或旧式排版
• 标准作业流程文档，Word和Excel混用
• 历史维修工单，Excel台账，填写质量参差不齐
• 设备电气原理图、气路图，转化价值高但解析难度大
• 老师在技术讨论群里的问答记录，口语化严重

清洗是最花时间的一步。PDF里的表格跨页断行是常态，一个故障排查表可能被拆成上下两页，需要拼接处理。扫描件必须过OCR，识别错误率在专业术语上尤其高，比如“伺服阀”被识别成“伺服罚”。工单里的口语化描述也是大问题——“机子老是嗡嗡响”“动不动就停机”，这类描述需要人工做归类修正，才能和手册中的标准术语对上。

我的经验是：清洗环节一定要有懂设备的人参与，纯技术人员做不了。让维修骨干把高频口语表述和标准术语的对应关系梳理出来，这件事比模型调参重要得多。

3.2 文档切分：最容易被忽视却最关键的一步

切分策略直接影响检索效果。刚开始我们采用固定长度切分，每段500字，重叠100字，结果发现大量语义被切断。比如手册里完整的“故障排除流程图”，文字部分被切成三段，检索时只命中其中一段，模型拿到的信息不完整，回答自然偏了。

后来改成按文档结构切分：

先解析出章节标题，以章、节、小节为边界，完整段落为一个基础块。对特别长的段落，按语义逻辑进一步拆分，比如每个子步骤单独成段。对FAQ类型的资料，直接按“问题—答案”对切分。切分块大小控制在300~800字之间，但这不是硬性规定，而是让结构决定长度。

另一个重要细节是给切分块补上下文元数据。每个块除了正文内容，还要带上文档名、章节路径、页码、设备型号适用范围、生效日期。这些元数据一方面用于检索后的重排和过滤，另一方面也用于最终回答中的引用溯源。

3.3 向量化与领域术语处理

向量检索的本质是把自然语言映射到高维语义空间，找到与查询语义相近的文本片段。但通用Embedding模型并不了解制造业设备的专业语料。它可能知道“液压”和“油压”语义接近，却不知道在注塑机场景下“顶针”和“顶出杆”指的是同一个东西。

这里做了两个关键处理：

第一是构建设备维修改领域术语表，涵盖设备型号、故障码、部件名称、同义俗称。查询进来后先做术语提取和同义扩展。维修工说“三零一机”会被映射为设备编号X301，说“油温高”会被扩展出“液压油温度过高”“液压系统过热”等表述，再进行检索。

第二是对Embedding模型做领域继续训练。用企业内部积累的故障工单、手册片段，以对比学习的方式调整模型参数，让模型在设备部件的语义区分上更细腻。这一步需要一些AI基础，初期可以先用通用模型上线，跑通后再逐步优化。

3.4 知识库的权限、版本与生命周期管理

设备维修资料在公司内部算敏感信息，不能所有内容无差别开放。系统按两个维度控制访问：组织维度按车间、班组过滤，内容维度按设备型号、文档保密等级过滤。一个维修工只能检索自己负责区域的相关资料。

版本管理同样关键。经常出现的情况是：设备手册更新了，旧版还在库里，新旧内容冲突。维修工问同一个故障，系统两次给出的步骤不一样，信任度立刻下降。我们的做法是知识块增加“生效日期”和“失效日期”字段，检索时默认只取当前有效版本。过期手册单独归档，不参与在线召回。

4. 系统实现与核心流程编排

4.1 查询预处理与多路召回

维修工的提问方式五花八门，直接拿原始问句去做向量检索，效果不够稳。查询预处理器会先做几个动作：去停用词，提取设备型号和故障代码，做同义术语映射，把问句拆出“对象+现象”的组合。

举个例子。维修工输入“三号机锁模压力掉得厉害”，预处理器会识别：设备是X301，现象是“锁模压力下降”。然后构建出多个查询变体，包括“X301锁模压力下降”“注塑机锁模压力不足”“锁模油缸压力异常”等，分别做检索。

召回阶段采用双路并行：向量召回负责语义相似，BM25关键词召回负责精确匹配。两路结果合并后，按相关度排序取Top60候选。这一步的目标是保证召回率——宁可在候选里多放一些不太相关的片段，也不能把正确答案挡在门外，因为后面的重排环节还有机会把噪声滤掉。

4.2 重排环节的优化

重排是提升准确率的关键。刚开始我们直接把向量检索的Top5塞给大模型，发现效果不稳定。有些在语义上相似但不含关键答案的片段排名靠前，把真正有用的片段挤到后面了。

后来引入独立的rerank环节。先用轻量级模型对候选片段和查询做交叉编码打分，再结合几个工程规则：包含设备型号精确匹配的加分，片段元数据中“适用范围”和查询设备一致的加分，来源于权威手册的优先级高于工单记录。重排后取Top5作为最终上下文。

这个环节做完，回答准确率提升非常明显。多路召回的候选质量波动较大，重排是承上启下的关键节点。

4.3 Prompt设计与生成约束

Prompt结构是这个系统输出的核心。我们采用的Prompt模板包含四部分：

你是[工厂名]设备维修助手。你的任务是基于提供的技术资料，回答设备故障排查问题。 【可用的技术资料】 {此处拼接检索到的知识片段，每条前标注来源序号，格式为：[来源1]章节名/文档名/页码} 【回答要求】 1. 只能使用上述技术资料中的信息，不得依据通用知识推测 2. 回答结构为：故障可能原因 → 排查步骤 → 注意事项 → 参考来源 3. 如果资料中没有提供某个问题的答案，必须明确写“资料库中暂未找到相关内容”，不要编造 4. 涉及电气、液压系统操作时，必须在回答开头添加安全提示 5. 使用简练的工程语言，避免冗长解释

这里有个设计细节：给每个知识片段加上来源序号，并要求模型在回答末尾引用对应的来源编号，目的是让回答和出处严格绑定。生成之后后端还有一道校验脚本来核对引用编号是否都在给定的片段范围内，防止模型自己编造引用。

关于生成参数，温度设为0.1到0.2，极低采样温度让输出更确定性。维修问答不是文学创作，不需要发散性。最大生成长度设置在500字左右，防止模型展开太多无关内容。

4.4 输出安全校验与前端呈现

输出校验是最后一道防线。系统会对生成的文本做规则检查：是否包含“断电前必须悬挂警示牌”“操作前请确认……”之类安全提示；是否出现引用了上下文之外的编号；是否是空回答或全编造。出现问题直接拦截，返回预制的兜底文案。

前端交互设计的基本原则是低门槛。一线维修工大多不是技术人员，界面只需要一个大输入框和结果卡片。结果卡片分四块：故障可能原因（列表）、排查步骤（分步序号）、注意事项（红色底框）、参考来源（折叠展开）。每条来源可以点开查看原文片段。

这个设计在试用中收到的反馈最好。很多维修工说“我不关心你这系统怎么实现的，只要告诉我下一步该查哪里、注意什么，就行”。

5. 试点实施与效果评估

5.1 试点场景怎么选

选试点场景是个策略性问题。一开始不要把整个工厂铺开，而是找一个边界清晰、知识相对完备、人员配合度高的车间。我们选的是某制造基地的注塑车间，设备类型相对集中，覆盖注塑机、配套模温机、冷水机、机械手四类设备，共30多台。历史工单存量约3000条，设备手册和SOP文档基本齐全。

更重要的是人员因素。选了一个维修班组参与试点，班长是干了十几年的老师傅，愿意花时间给系统做测试核对。这种“种子用户”非常关键。没有他们帮忙标注标准答案、反馈检索问题，系统优化就是无头苍蝇。

5.2 测试集构建与评估指标

评估前先建测试集。从历史故障工单中随机抽了100条真实故障描述，由维修主管独立整理标准参考答案，包括故障原因和排查步骤。测试集覆盖了高频故障类型、中频故障类型，也包含少量低频罕见故障。

评估维度定了五个：

• 检索命中是否正确：Top5候选片段中是否包含能回答问题的知识片段
• 回答语义准确率：生成的回答与参考答案在关键步骤和原因上是否一致
• 引用正确率：回答中标注的来源编号是否真正对应正确的知识片段
• 无中生有率：回答中是否存在资料中没有的信息
• 安全合规率：涉及高危操作时是否正确输出安全提示

5.3 实测效果数据与迭代过程

第一轮测试结果不算理想。检索命中率约75%，准确率约65%。主要问题集中在查询口语化严重、术语映射缺失，以及切分导致的信息不完整。

优化的过程是一步步来的：先建术语表和同义映射，解决“说法不一致”问题，检索命中率提升到85%左右。再做重排优化，引入交叉编码打分，准确率提升到75%。再调Prompt和输出校验，准确率到80%。随着Embedding微调和知识库增量清洗，最终稳定在检索命中率90%出头、回答准确率接近85%的水平。一次未造成延误的维修任务中，系统给出的建议和老师傅的判断基本一致，这算是个不错的正反馈。

这个过程中还有一个重要发现：把无中生有率压下去，比提升准确率更能赢得一线信任。早期系统偶尔会编出一条不存在的排查步骤，被维修工抓住一次，后面说什么他都会打折扣。后来我们把生成短路策略加上了：检索不到高相关片段时，一律不进入生成环节，直接返回“暂未找到相关内容，请联系维修主管”。宁可回答没有，也不要硬编。

5.4 一线使用反馈与后续改进

试用反馈有几类：老师傅觉得排查步骤和自己的经验高度吻合，省了翻手册的时间；新入职维修工反馈“比问师傅压力小，问系统不怕被笑话”；但也有批评，比如对复合故障（多个故障码同时出现、现象叠加）处理不好，回答偏单点原因。这部分确实难处理，需要在知识库中补充关联故障案例，并且让Prompt支持多现象综合判断。

还有一个高频反馈是希望增加语音输入。车间里手上都是油污，打字不方便。目前语音识别在噪音环境下准确率还不够，但方向已经明确——下一期会专门优化语音输入的噪声抑制和术语识别。

6. 常见问题与排查技巧实录

6.1 检索不到对应维修方案怎么办

这是上线初期出现频率最高的问题。排查思路建议按顺序走一遍：

先看Top5候选中到底有没有正确答案。如果答案在候选中，问题出在重排环节，重点调重排打分逻辑。如果答案完全不在候选里，说明召回阶段就失败了。从查询预处理开始查：术语映射是否建立、同义扩展是否生效。很多“查不到”其实是同义词问题，维修工说“油管漏”手册里写的是“液压管路泄漏”，中间缺映射。

还有一个高频原因：文档切分把关键内容切碎了。比如一个排查表被切断，答案序列只有后半部分，缺乏主体语境。调整切分策略，按表格完整块保留，显著改善了这类问题。

6.2 回答出现编造信息怎么处理

编造（幻觉）是RAG应用中最需要警惕的问题。我们的处理策略是三层防线的组合。

第一层是前置可回答性判断。检索环节先计算查询与候选片段的相关度，如果最高分低于某个阈值，直接走“无结果”分支，不调用生成。从根上阻断编造。

第二层是Prompt强约束。明确要求“只能使用提供资料”，每条回答末尾引用来源编号，并且给出“资料库无相关内容”时的标准话术。

第三层是引用校验和后置规则。生成后检查引用编号是否合法，发现未标注引用的关键断言就拦截重试。

在实际使用中，temperature值也是一个因素。早期用0.7导致回答发散，调到0.1之后编造现象少了很多。可以这样理解：低温是让模型收敛到最可能的表达路径上。

6.3 同一问题不同回答，版本冲突怎么解决

知识库中并存新旧两个版本手册时会出现回答漂移。同一个故障，有时候引用新版步骤，有时候引用旧版步骤。关键在于版本过滤。在检索阶段，就对候选片段按照元数据中的生效日期和适用范围做严格过滤，过期内容一律不参与召回。上线前我还专门做了一轮数据清洗，把没标日期的历史文档补录了元数据。

这里给一个经验数字：知识库的版本混乱会造成约10~15%的回答不一致率，而且这种问题很难通过Prompt修正，必须从数据治理层面解决。

6.4 高频故障知识的日常运营机制

系统上线不是终点，维修知识需要持续运营。我们的运营机制是：每天凌晨自动拉取新增工单，做规则清洗后进入待审核池；每周由维修主管审核一次，将高质量故障记录转为正式知识条目；每月汇总一次高频检索但低命中率的问法，反馈给运维团队做术语表扩充。

这个机制保证了系统越用越准，而不是越用越旧。毕竟设备维修知识是持续产生的，一个不更新的知识库，价值会随时间快速衰减。

6.5 一个容易被忽略的运营细节

最后说一个容易被技术团队忽略的细节：给一线使用者的“说明书”要极简。我们做了完整的系统使用文档，结果没人看。后来把使用说明压缩成六行字，贴在平板支架旁边：

1. 输入设备号和故障现象
2. 看“可能原因”列表
3. 按“排查步骤”顺序排查
4. 注意“红色提醒”内容
5. 点来源可查看原文
6. 结果不对就点“反馈”，会自动记录

就这么简单。工具的价值不在功能多，在于它真的能被日常用起来。系统上线三个月后回访，维修班组已经习惯遇到故障先问一句“这个情况怎么办”，而不是直接翻通讯录找人。对我个人来说，这个变化比任何指标都更有说服力。

这个项目做下来，最大的体会是：大模型在企业场景落地，卡点往往不在模型选型，而在知识数据的工程化程度。文档干净、切分合理、检索精准，输出的质量自然不会差。工程师的精力应该放在打磨知识治理和检索链路上，而不是反复变着花样调Prompt。另外，回答的可溯源、可解释，对于建立一线信任的价值远超想象。系统给维修工一个“为什么这么判断”的理由，他才愿意把你的建议真正用在设备上。