简介这份245页PDF方案面向工业设备维修领域的算法工程师、知识图谱开发者与智能问答系统建设者围绕自然语言处理技术系统讲解如何基于DeepSeek大模型构建领域知识库与维修问答系统。内容从场景痛点与技术适配性切入依次覆盖知识图谱schema设计、非结构化维修文档采集与预处理、结构化与半结构化数据抽取、领域词典与故障词汇库建设、实体对齐消歧、关系推理、图数据库与关系数据库协同存储、知识库增量更新以及实体、关系、意图、问答对等标注任务设计与质量控制并延伸至DeepSeek训练环境搭建、预训练数据清洗、目标函数设计、批次与学习率调度、梯度累积与混合精度训练等工程实践。资源包为1个PDF文件约11.58MB支持目录跳转与左侧书签大纲定位共50个大章节条理清晰、图表完整。目前已有68人学习适合希望打通从知识抽取到模型训练全链路、落地工业维修智能问答的中高级读者参考。1. 工业设备维修问答为什么不能直接拿通用大模型硬上一台进口注塑机半夜报液压油温异常现场值班的维修工翻完纸质手册、又去群里问老师傅前后折腾四十分钟才定位到是冷却水阀卡滞。这类场景在工厂里天天发生而通用大模型面对「液压油温异常」这种提问大概率会给你一段教科书式的原理说明却答不出这台设备该先查哪个阀、报警代码对应哪一页。工业设备维修智能问答要解决的就是把散落在手册、工单、故障记录里的领域知识用自然语言处理的方式组织成可检索、可推理的知识库再挂上 DeepSeek 这类大模型做问答出口。它适合设备密集、维修经验依赖老师傅、停机成本高的制造企业也适合想把领域知识库构建这套方法迁移到其他垂直行业的工程师。整件事的核心不是模型多大而是知识库构建得够不够扎实、检索匹配够不够准。2. 领域知识库构建从设备手册到可检索语料2.1 工业维修语料的三种来源与清洗策略工业设备维修的知识来源比通用问答复杂得多常见的有三类。第一类是设备手册和图纸通常是 PDF里面混着表格、参数表、爆炸图文字提取后往往断行错乱。第二类是历史维修工单格式不统一有的是一句话「换了轴承就好了」有的是完整故障树。第三类是老师傅的口头经验需要整理成问答对。这三类语料决定了后面检索的质量清洗不到位再好的模型也救不回来。我一般会先做一轮结构化提取。手册类用 pdfplumber 抽文本和表格工单类用正则把「故障现象 / 排查过程 / 更换件 / 结论」拆成字段。下面是一段手册文本清洗的代码重点处理断行和表格残留。import re import pdfplumber def clean_manual_text(pdf_path): full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # 先抽表格避免表格文字混进正文 tables page.extract_tables() for table in tables: for row in table: # 表格行拼成 参数名: 参数值 形式方便后续检索 cells [c for c in row if c] if len(cells) 2: full_text.append(f{cells[0]}: {cells[1]}) text page.extract_text() or full_text.append(text) raw \n.join(full_text) # 去掉页眉页脚常见模式比如 第 X 页 和纯数字行 raw re.sub(r第\s*\d\s*页, , raw) raw re.sub(r^\s*\d\s*$, , raw, flagsre.MULTILINE) # 合并被 PDF 强制换行拆断的句子中文行尾无标点则与下一行拼接 raw re.sub(r([^\n。])\n([^\n]), r\1\2, raw) # 压缩多余空白 raw re.sub(r[ \t], , raw) return raw.strip()这段代码的逻辑是先把表格单独抽出来转成键值对再处理正文。参数上extract_tables对有线框的表格效果好无线框表格需要换用extract_text配合布局参数。断行合并那条正则只处理行尾没有标点的情况因为中文句子正常以标点结尾被 PDF 拆断的行尾通常没有标点。清洗完的文本要人工抽检尤其是参数表错一个数值后面问答就会给错答案。2.2 按设备型号和故障类型做知识分块清洗完的语料不能整篇塞进向量库必须分块。工业维修场景的分块和通用文档不一样不能只按字数切。我的做法是按「设备型号 故障类型」两级切分保证每个块是一个完整的排查单元。比如「注塑机 / 液压系统 / 油温异常」是一个块「注塑机 / 液压系统 / 压力不足」是另一个块。这样检索时命中的块直接就是可用的排查步骤不用模型再去拼凑。分块时保留元数据很关键。每个块要带上设备型号、系统分类、故障现象、来源文档页码。元数据在检索阶段能做过滤比如用户问的是某型号设备就只在对应型号的块里检索匹配度会明显提升。下面是一个分块和元数据组织的示例。import json def build_chunks(cleaned_text, device_model, system_type): chunks [] # 按二级标题或故障编号切分这里假设手册用 故障现象 开头 blocks re.split(r(?故障现象[:]), cleaned_text) for idx, block in enumerate(blocks): block block.strip() if len(block) 30: # 太短的块没有检索价值 continue chunks.append({ chunk_id: f{device_model}_{system_type}_{idx}, device_model: device_model, system_type: system_type, content: block, source: manual, }) return chunks chunks build_chunks(text, HT-160, 液压系统) with open(chunks.jsonl, w, encodingutf-8) as f: for c in chunks: f.write(json.dumps(c, ensure_asciiFalse) \n)参数说明len(block) 30这个阈值是经验值太短的块往往是标题残留检索时容易误命中。chunk_id用型号加系统加序号方便后续排查是哪条数据出了问题。实际项目里块大小控制在 200 到 500 字比较合适超过 500 字检索精度下降低于 100 字上下文又不够模型回答。2.3 向量化与检索索引的选型知识块建好后要向量化。工业领域术语多通用 embedding 模型对「伺服驱动器过载」「液压泵容积效率」这类词的区分度不够常见做法是用中文领域语料微调过的 embedding或者直接用 bge-large-zh 这类在中文上表现稳定的模型。向量库选型上数据量在十万块以内FAISS 本地索引就够用部署简单如果要多租户、要动态更新Milvus 或 Qdrant 更合适。检索不能只靠向量。工业维修问答里型号、报警代码这类精确匹配很重要纯向量检索会把「HT-160」和「HT-180」当成相似。我的做法是向量检索加关键词检索做混合召回再用元数据过滤。下面是一个混合检索的骨架。from sentence_transformers import SentenceTransformer import faiss import numpy as np model SentenceTransformer(bge-large-zh) texts [c[content] for c in chunks] embeddings model.encode(texts, normalize_embeddingsTrue) index faiss.IndexFlatIP(embeddings.shape[1]) index.add(np.array(embeddings)) def hybrid_search(query, device_modelNone, top_k5): q_vec model.encode([query], normalize_embeddingsTrue) scores, ids index.search(np.array(q_vec), top_k * 3) results [] for score, i in zip(scores[0], ids[0]): chunk chunks[i] # 元数据过滤型号不匹配直接跳过 if device_model and chunk[device_model] ! device_model: continue # 关键词加权查询词出现在内容里给额外分 keyword_bonus 0.1 if any(w in chunk[content] for w in query.split()) else 0 results.append((score keyword_bonus, chunk)) results.sort(keylambda x: x[0], reverseTrue) return results[:top_k]这里normalize_embeddingsTrue配合IndexFlatIP做内积等价于余弦相似度。top_k * 3是先多召回再过滤避免元数据过滤后结果不够。关键词加权那行是简化版生产环境会用 BM25 单独做一路召回再融合。参数上top_k最终给 3 到 5 条比较合适太多会稀释上下文太少可能漏掉正确排查步骤。3. 智能问答系统搭建DeepSeek 接入与提示词工程3.1 DeepSeek API 调用与流式输出知识库建好后问答出口用 DeepSeek。接入方式常见两种一是直接调 API二是本地部署。API 调用简单适合快速验证本地部署适合数据不能出厂的场景但需要 GPU 资源。下面先给 API 调用的最小可用代码重点是把检索到的知识块拼进提示词。import requests import json def ask_deepseek(query, retrieved_chunks, api_key): context \n\n.join([c[content] for _, c in retrieved_chunks]) prompt f你是工业设备维修助手。根据下面的维修资料回答问题不要编造资料里没有的内容。 如果资料不足以回答直接说资料中没有相关内容。 维修资料 {context} 问题{query} 回答 resp requests.post( https://api.deepseek.com/chat/completions, headers{Authorization: fBearer {api_key}, Content-Type: application/json}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.2, # 维修场景要稳定温度调低 stream: True, }, streamTrue, ) for line in resp.iter_lines(): if line: line line.decode(utf-8).replace(data: , ) if line [DONE]: break try: delta json.loads(line)[choices][0][delta].get(content, ) print(delta, end, flushTrue) except Exception: continue参数说明temperature设 0.2 是因为维修回答要可复现不能这次说查 A 阀下次说查 B 阀。streamTrue是为了现场体验维修工等不了整段生成。提示词里明确「不要编造」和「资料不足直接说」这两句能挡掉大部分幻觉。实际部署时 API key 不要写死在代码里走环境变量或配置中心。3.2 提示词模板让回答落到具体排查步骤通用提示词在工业场景不够用回答容易飘。我一般会把提示词拆成角色、约束、输出格式三部分。角色定成「有二十年经验的设备维修工程师」约束里写清「按排查顺序输出」「每步给出判断依据」「涉及安全操作要提醒断电泄压」输出格式固定成「可能原因 / 排查步骤 / 注意事项」三段。这样现场维修工拿到回答能直接照着做。下面是一个更贴近落地的提示词模板配合检索结果使用。PROMPT_TEMPLATE 你是一名资深工业设备维修工程师擅长{system_type}故障排查。 请严格根据以下维修资料回答资料没有的内容不要补充。 维修资料 {context} 用户问题{query} 请按以下格式回答 可能原因 1. ... 排查步骤 1. ...每步说明判断依据 注意事项 - ...涉及安全操作必须提醒 如果资料不足以定位故障回答现有资料无法确定建议补充以下信息...并列出需要的信息。这个模板的关键在最后一段。工业现场信息经常不全与其让模型硬答不如让它主动追问。比如用户只说「设备报警」模型应该问清型号、报警代码、发生时机。system_type从检索结果的元数据里取这样提示词能带上具体系统名回答更聚焦。3.3 多轮追问与上下文管理维修排查天然是多轮的。第一轮用户说「注塑机不动作」模型给出几个方向用户排查后回来说「油泵有声音但压力上不去」这时候需要把上一轮的检索结果和对话历史一起带上。上下文管理有两个坑一是历史太长超出窗口二是旧检索结果和新问题不相关反而干扰。我的做法是每轮重新检索只保留最近两轮对话摘要检索结果用当轮的。def build_messages(history, query, retrieved_chunks): context \n\n.join([c[content] for _, c in retrieved_chunks]) messages [] # 只保留最近两轮更早的压缩成一句摘要 for turn in history[-2:]: messages.append({role: user, content: turn[q]}) messages.append({role: assistant, content: turn[a][:200]}) messages.append({role: user, content: PROMPT_TEMPLATE.format( system_typeretrieved_chunks[0][1][system_type] if retrieved_chunks else 通用, contextcontext, queryquery, )}) return messageshistory[-2:]是控制上下文长度[:200]是截断旧回答避免占满窗口。每轮重新检索而不是复用旧结果是因为用户追问后问题焦点变了旧结果可能完全不相关。这个策略在实测里比固定拼接全部历史效果好回答准确率能稳住。4. 避坑与排查知识库问答上线后最容易翻车的五件事4.1 检索命中率低回答总是「资料中没有」现象是用户问得很具体系统却一直说资料不足。原因通常是分块太粗一个块里混了好几个故障类型向量被平均掉了。解决方法是把块切细按故障现象单独成块同时给块加上故障类型标签检索时先按标签过滤再算相似度。另一个原因是 embedding 模型不匹配领域换成中文领域微调过的模型命中率会有明显变化。4.2 型号张冠李戴A 设备的答案给了 B 设备现象是回答里的参数和步骤对不上用户设备。原因是检索时没做元数据过滤向量把不同型号的相似描述都召回了。解决方法是检索阶段强制按device_model过滤过滤后结果不足再放宽。元数据在分块时就要打好后期补代价很大。这个坑我在项目里踩过返工重新分块花了两天。4.3 模型编造手册里没有的排查步骤现象是回答看起来很专业但手册里根本没这条。原因是提示词约束不够或者检索结果为空时模型自由发挥。解决方法是在提示词里写死「资料不足直接说」同时在代码层判断检索结果为空时直接返回固定话术不调模型。温度调低也有帮助但不能根治关键还是检索结果要喂对。4.4 表格参数提取错位数值对不上现象是回答里给的扭矩值、压力值明显不对。原因是 PDF 表格提取时行列错位尤其是跨页表格。解决方法是提取后做校验比如参数值是否在合理范围、单位是否匹配。跨页表格要单独处理把上一页最后一行和下一页第一行拼接。这个环节建议人工抽检至少百分之十的表格。4.5 多轮对话后回答越来越飘现象是前几轮还准聊到后面开始答非所问。原因是历史上下文太长旧检索结果干扰了新问题。解决方法是每轮重新检索历史只保留最近两轮且截断长度。如果业务需要长记忆把历史摘要单独存不要全塞进提示词。上下文窗口是稀缺资源要留给当轮检索结果。5. 把问答准确率再往上推一档的两个技巧第一个技巧是给检索结果做重排序。混合召回拿回来的块顺序未必对用一个小的交叉编码器做重排能把真正相关的块顶到前面。常见做法是用 bge-reranker 对 top 20 重新打分取前 3 给模型。实测在工业维修语料上重排后回答准确率比纯向量召回高出一截代价是每次查询多几十毫秒。参数上重排的候选数不要超过 30再多收益递减还拖慢响应。from FlagEmbedding import FlagReranker reranker FlagReranker(bge-reranker-large, use_fp16True) def rerank(query, candidates, top_k3): pairs [[query, c[content]] for _, c in candidates] scores reranker.compute_score(pairs) ranked sorted(zip(scores, candidates), keylambda x: x[0], reverseTrue) return [c for _, c in ranked[:top_k]]use_fp16True省显存top_k3是给模型的最终上下文。重排模型比 embedding 模型大推理慢所以只对召回结果重排不对全库跑。第二个技巧是建一个「未命中问题」回流表。用户问了但检索没命中的问题定期人工整理补进知识库。这个习惯坚持三个月知识库覆盖率会有肉眼可见的提升。我一般每周看一次回流表把高频未命中问题优先补。工业设备维修的知识是长尾的靠一次建库不可能全覆盖持续回流才是正路。这两个技巧都不复杂难在坚持。重排是工程优化回流是运营习惯缺一个问答系统都会慢慢退化。我自己踩过的最大坑就是建完库就不管了三个月后准确率掉得厉害后来把回流做成固定流程才稳住。希望帮到你。本文还有配套的精品资源点击获取 工业设备维修智能问答：领域知识库构建与DeepSeek接入实战
简介这份245页PDF方案面向工业设备维修领域的算法工程师、知识图谱开发者与智能问答系统建设者围绕自然语言处理技术系统讲解如何基于DeepSeek大模型构建领域知识库与维修问答系统。内容从场景痛点与技术适配性切入依次覆盖知识图谱schema设计、非结构化维修文档采集与预处理、结构化与半结构化数据抽取、领域词典与故障词汇库建设、实体对齐消歧、关系推理、图数据库与关系数据库协同存储、知识库增量更新以及实体、关系、意图、问答对等标注任务设计与质量控制并延伸至DeepSeek训练环境搭建、预训练数据清洗、目标函数设计、批次与学习率调度、梯度累积与混合精度训练等工程实践。资源包为1个PDF文件约11.58MB支持目录跳转与左侧书签大纲定位共50个大章节条理清晰、图表完整。目前已有68人学习适合希望打通从知识抽取到模型训练全链路、落地工业维修智能问答的中高级读者参考。1. 工业设备维修问答为什么不能直接拿通用大模型硬上一台进口注塑机半夜报液压油温异常现场值班的维修工翻完纸质手册、又去群里问老师傅前后折腾四十分钟才定位到是冷却水阀卡滞。这类场景在工厂里天天发生而通用大模型面对「液压油温异常」这种提问大概率会给你一段教科书式的原理说明却答不出这台设备该先查哪个阀、报警代码对应哪一页。工业设备维修智能问答要解决的就是把散落在手册、工单、故障记录里的领域知识用自然语言处理的方式组织成可检索、可推理的知识库再挂上 DeepSeek 这类大模型做问答出口。它适合设备密集、维修经验依赖老师傅、停机成本高的制造企业也适合想把领域知识库构建这套方法迁移到其他垂直行业的工程师。整件事的核心不是模型多大而是知识库构建得够不够扎实、检索匹配够不够准。2. 领域知识库构建从设备手册到可检索语料2.1 工业维修语料的三种来源与清洗策略工业设备维修的知识来源比通用问答复杂得多常见的有三类。第一类是设备手册和图纸通常是 PDF里面混着表格、参数表、爆炸图文字提取后往往断行错乱。第二类是历史维修工单格式不统一有的是一句话「换了轴承就好了」有的是完整故障树。第三类是老师傅的口头经验需要整理成问答对。这三类语料决定了后面检索的质量清洗不到位再好的模型也救不回来。我一般会先做一轮结构化提取。手册类用 pdfplumber 抽文本和表格工单类用正则把「故障现象 / 排查过程 / 更换件 / 结论」拆成字段。下面是一段手册文本清洗的代码重点处理断行和表格残留。import re import pdfplumber def clean_manual_text(pdf_path): full_text [] with pdfplumber.open(pdf_path) as pdf: for page in pdf.pages: # 先抽表格避免表格文字混进正文 tables page.extract_tables() for table in tables: for row in table: # 表格行拼成 参数名: 参数值 形式方便后续检索 cells [c for c in row if c] if len(cells) 2: full_text.append(f{cells[0]}: {cells[1]}) text page.extract_text() or full_text.append(text) raw \n.join(full_text) # 去掉页眉页脚常见模式比如 第 X 页 和纯数字行 raw re.sub(r第\s*\d\s*页, , raw) raw re.sub(r^\s*\d\s*$, , raw, flagsre.MULTILINE) # 合并被 PDF 强制换行拆断的句子中文行尾无标点则与下一行拼接 raw re.sub(r([^\n。])\n([^\n]), r\1\2, raw) # 压缩多余空白 raw re.sub(r[ \t], , raw) return raw.strip()这段代码的逻辑是先把表格单独抽出来转成键值对再处理正文。参数上extract_tables对有线框的表格效果好无线框表格需要换用extract_text配合布局参数。断行合并那条正则只处理行尾没有标点的情况因为中文句子正常以标点结尾被 PDF 拆断的行尾通常没有标点。清洗完的文本要人工抽检尤其是参数表错一个数值后面问答就会给错答案。2.2 按设备型号和故障类型做知识分块清洗完的语料不能整篇塞进向量库必须分块。工业维修场景的分块和通用文档不一样不能只按字数切。我的做法是按「设备型号 故障类型」两级切分保证每个块是一个完整的排查单元。比如「注塑机 / 液压系统 / 油温异常」是一个块「注塑机 / 液压系统 / 压力不足」是另一个块。这样检索时命中的块直接就是可用的排查步骤不用模型再去拼凑。分块时保留元数据很关键。每个块要带上设备型号、系统分类、故障现象、来源文档页码。元数据在检索阶段能做过滤比如用户问的是某型号设备就只在对应型号的块里检索匹配度会明显提升。下面是一个分块和元数据组织的示例。import json def build_chunks(cleaned_text, device_model, system_type): chunks [] # 按二级标题或故障编号切分这里假设手册用 故障现象 开头 blocks re.split(r(?故障现象[:]), cleaned_text) for idx, block in enumerate(blocks): block block.strip() if len(block) 30: # 太短的块没有检索价值 continue chunks.append({ chunk_id: f{device_model}_{system_type}_{idx}, device_model: device_model, system_type: system_type, content: block, source: manual, }) return chunks chunks build_chunks(text, HT-160, 液压系统) with open(chunks.jsonl, w, encodingutf-8) as f: for c in chunks: f.write(json.dumps(c, ensure_asciiFalse) \n)参数说明len(block) 30这个阈值是经验值太短的块往往是标题残留检索时容易误命中。chunk_id用型号加系统加序号方便后续排查是哪条数据出了问题。实际项目里块大小控制在 200 到 500 字比较合适超过 500 字检索精度下降低于 100 字上下文又不够模型回答。2.3 向量化与检索索引的选型知识块建好后要向量化。工业领域术语多通用 embedding 模型对「伺服驱动器过载」「液压泵容积效率」这类词的区分度不够常见做法是用中文领域语料微调过的 embedding或者直接用 bge-large-zh 这类在中文上表现稳定的模型。向量库选型上数据量在十万块以内FAISS 本地索引就够用部署简单如果要多租户、要动态更新Milvus 或 Qdrant 更合适。检索不能只靠向量。工业维修问答里型号、报警代码这类精确匹配很重要纯向量检索会把「HT-160」和「HT-180」当成相似。我的做法是向量检索加关键词检索做混合召回再用元数据过滤。下面是一个混合检索的骨架。from sentence_transformers import SentenceTransformer import faiss import numpy as np model SentenceTransformer(bge-large-zh) texts [c[content] for c in chunks] embeddings model.encode(texts, normalize_embeddingsTrue) index faiss.IndexFlatIP(embeddings.shape[1]) index.add(np.array(embeddings)) def hybrid_search(query, device_modelNone, top_k5): q_vec model.encode([query], normalize_embeddingsTrue) scores, ids index.search(np.array(q_vec), top_k * 3) results [] for score, i in zip(scores[0], ids[0]): chunk chunks[i] # 元数据过滤型号不匹配直接跳过 if device_model and chunk[device_model] ! device_model: continue # 关键词加权查询词出现在内容里给额外分 keyword_bonus 0.1 if any(w in chunk[content] for w in query.split()) else 0 results.append((score keyword_bonus, chunk)) results.sort(keylambda x: x[0], reverseTrue) return results[:top_k]这里normalize_embeddingsTrue配合IndexFlatIP做内积等价于余弦相似度。top_k * 3是先多召回再过滤避免元数据过滤后结果不够。关键词加权那行是简化版生产环境会用 BM25 单独做一路召回再融合。参数上top_k最终给 3 到 5 条比较合适太多会稀释上下文太少可能漏掉正确排查步骤。3. 智能问答系统搭建DeepSeek 接入与提示词工程3.1 DeepSeek API 调用与流式输出知识库建好后问答出口用 DeepSeek。接入方式常见两种一是直接调 API二是本地部署。API 调用简单适合快速验证本地部署适合数据不能出厂的场景但需要 GPU 资源。下面先给 API 调用的最小可用代码重点是把检索到的知识块拼进提示词。import requests import json def ask_deepseek(query, retrieved_chunks, api_key): context \n\n.join([c[content] for _, c in retrieved_chunks]) prompt f你是工业设备维修助手。根据下面的维修资料回答问题不要编造资料里没有的内容。 如果资料不足以回答直接说资料中没有相关内容。 维修资料 {context} 问题{query} 回答 resp requests.post( https://api.deepseek.com/chat/completions, headers{Authorization: fBearer {api_key}, Content-Type: application/json}, json{ model: deepseek-chat, messages: [{role: user, content: prompt}], temperature: 0.2, # 维修场景要稳定温度调低 stream: True, }, streamTrue, ) for line in resp.iter_lines(): if line: line line.decode(utf-8).replace(data: , ) if line [DONE]: break try: delta json.loads(line)[choices][0][delta].get(content, ) print(delta, end, flushTrue) except Exception: continue参数说明temperature设 0.2 是因为维修回答要可复现不能这次说查 A 阀下次说查 B 阀。streamTrue是为了现场体验维修工等不了整段生成。提示词里明确「不要编造」和「资料不足直接说」这两句能挡掉大部分幻觉。实际部署时 API key 不要写死在代码里走环境变量或配置中心。3.2 提示词模板让回答落到具体排查步骤通用提示词在工业场景不够用回答容易飘。我一般会把提示词拆成角色、约束、输出格式三部分。角色定成「有二十年经验的设备维修工程师」约束里写清「按排查顺序输出」「每步给出判断依据」「涉及安全操作要提醒断电泄压」输出格式固定成「可能原因 / 排查步骤 / 注意事项」三段。这样现场维修工拿到回答能直接照着做。下面是一个更贴近落地的提示词模板配合检索结果使用。PROMPT_TEMPLATE 你是一名资深工业设备维修工程师擅长{system_type}故障排查。 请严格根据以下维修资料回答资料没有的内容不要补充。 维修资料 {context} 用户问题{query} 请按以下格式回答 可能原因 1. ... 排查步骤 1. ...每步说明判断依据 注意事项 - ...涉及安全操作必须提醒 如果资料不足以定位故障回答现有资料无法确定建议补充以下信息...并列出需要的信息。这个模板的关键在最后一段。工业现场信息经常不全与其让模型硬答不如让它主动追问。比如用户只说「设备报警」模型应该问清型号、报警代码、发生时机。system_type从检索结果的元数据里取这样提示词能带上具体系统名回答更聚焦。3.3 多轮追问与上下文管理维修排查天然是多轮的。第一轮用户说「注塑机不动作」模型给出几个方向用户排查后回来说「油泵有声音但压力上不去」这时候需要把上一轮的检索结果和对话历史一起带上。上下文管理有两个坑一是历史太长超出窗口二是旧检索结果和新问题不相关反而干扰。我的做法是每轮重新检索只保留最近两轮对话摘要检索结果用当轮的。def build_messages(history, query, retrieved_chunks): context \n\n.join([c[content] for _, c in retrieved_chunks]) messages [] # 只保留最近两轮更早的压缩成一句摘要 for turn in history[-2:]: messages.append({role: user, content: turn[q]}) messages.append({role: assistant, content: turn[a][:200]}) messages.append({role: user, content: PROMPT_TEMPLATE.format( system_typeretrieved_chunks[0][1][system_type] if retrieved_chunks else 通用, contextcontext, queryquery, )}) return messageshistory[-2:]是控制上下文长度[:200]是截断旧回答避免占满窗口。每轮重新检索而不是复用旧结果是因为用户追问后问题焦点变了旧结果可能完全不相关。这个策略在实测里比固定拼接全部历史效果好回答准确率能稳住。4. 避坑与排查知识库问答上线后最容易翻车的五件事4.1 检索命中率低回答总是「资料中没有」现象是用户问得很具体系统却一直说资料不足。原因通常是分块太粗一个块里混了好几个故障类型向量被平均掉了。解决方法是把块切细按故障现象单独成块同时给块加上故障类型标签检索时先按标签过滤再算相似度。另一个原因是 embedding 模型不匹配领域换成中文领域微调过的模型命中率会有明显变化。4.2 型号张冠李戴A 设备的答案给了 B 设备现象是回答里的参数和步骤对不上用户设备。原因是检索时没做元数据过滤向量把不同型号的相似描述都召回了。解决方法是检索阶段强制按device_model过滤过滤后结果不足再放宽。元数据在分块时就要打好后期补代价很大。这个坑我在项目里踩过返工重新分块花了两天。4.3 模型编造手册里没有的排查步骤现象是回答看起来很专业但手册里根本没这条。原因是提示词约束不够或者检索结果为空时模型自由发挥。解决方法是在提示词里写死「资料不足直接说」同时在代码层判断检索结果为空时直接返回固定话术不调模型。温度调低也有帮助但不能根治关键还是检索结果要喂对。4.4 表格参数提取错位数值对不上现象是回答里给的扭矩值、压力值明显不对。原因是 PDF 表格提取时行列错位尤其是跨页表格。解决方法是提取后做校验比如参数值是否在合理范围、单位是否匹配。跨页表格要单独处理把上一页最后一行和下一页第一行拼接。这个环节建议人工抽检至少百分之十的表格。4.5 多轮对话后回答越来越飘现象是前几轮还准聊到后面开始答非所问。原因是历史上下文太长旧检索结果干扰了新问题。解决方法是每轮重新检索历史只保留最近两轮且截断长度。如果业务需要长记忆把历史摘要单独存不要全塞进提示词。上下文窗口是稀缺资源要留给当轮检索结果。5. 把问答准确率再往上推一档的两个技巧第一个技巧是给检索结果做重排序。混合召回拿回来的块顺序未必对用一个小的交叉编码器做重排能把真正相关的块顶到前面。常见做法是用 bge-reranker 对 top 20 重新打分取前 3 给模型。实测在工业维修语料上重排后回答准确率比纯向量召回高出一截代价是每次查询多几十毫秒。参数上重排的候选数不要超过 30再多收益递减还拖慢响应。from FlagEmbedding import FlagReranker reranker FlagReranker(bge-reranker-large, use_fp16True) def rerank(query, candidates, top_k3): pairs [[query, c[content]] for _, c in candidates] scores reranker.compute_score(pairs) ranked sorted(zip(scores, candidates), keylambda x: x[0], reverseTrue) return [c for _, c in ranked[:top_k]]use_fp16True省显存top_k3是给模型的最终上下文。重排模型比 embedding 模型大推理慢所以只对召回结果重排不对全库跑。第二个技巧是建一个「未命中问题」回流表。用户问了但检索没命中的问题定期人工整理补进知识库。这个习惯坚持三个月知识库覆盖率会有肉眼可见的提升。我一般每周看一次回流表把高频未命中问题优先补。工业设备维修的知识是长尾的靠一次建库不可能全覆盖持续回流才是正路。这两个技巧都不复杂难在坚持。重排是工程优化回流是运营习惯缺一个问答系统都会慢慢退化。我自己踩过的最大坑就是建完库就不管了三个月后准确率掉得厉害后来把回流做成固定流程才稳住。希望帮到你。本文还有配套的精品资源点击获取