1. 设备管理为什么需要一套“活”的知识库干了十几年设备管理的人都有一个共同感受最值钱的东西不在台账里也不在备件库里而是在老师傅的脑子里。一台进口注塑机报了个从没见过的故障码操作工翻遍手册找不到对应条目最后是干了二十年的老张过来听了听声音、摸了摸油管温度说了句“比例阀卡了拆下来用煤油泡半小时”问题就解决了。这种事在工厂里每天都在发生但老张退休那天这套判断逻辑就跟着他一起走了。我所在的团队从2022年开始尝试把这类隐性经验沉淀下来。最初用的是传统Wiki按设备类型建目录每台设备下面挂故障案例、维修记录、备件清单。写了半年文档数量上去了但真正用的人很少。原因很简单检索太费劲。一台设备可能有几十个故障模式每个模式又对应不同的工况、批次、环境条件靠目录树和关键词搜索一线维修工在抢修现场根本没耐心一层层点进去找。他们宁可打电话问人。大语言模型LLM的出现让这件事有了转机。LLM的核心能力是语义理解和生成它不需要你精确匹配关键词你用大白话描述现象它就能从一堆非结构化文本里找到相关段落甚至能综合多个来源给出判断建议。这正好切中了设备管理知识库的痛点知识是碎片化的、口语化的、依赖上下文的而LLM擅长处理的就是这种“不规整”的信息。于是我们启动了一个内部项目代号就叫“LLM Wiki”。目标很明确把设备管理相关的操作手册、维修工单、故障案例、专家访谈记录、备件规格书全部喂给一个本地部署的大模型再配上一套Wiki式的知识管理界面让一线人员能用自然语言提问系统给出带出处的回答。这个项目不是要替代老师傅而是要把老师傅的判断逻辑“翻译”成系统能理解的知识结构让更多人在更多场景下能调用这套经验。适合谁来参考这套实践如果你是工厂设备科长、维修班组长、工业互联网平台的产品经理或者正在做企业知识库的IT负责人这篇文章里的思路和踩坑记录应该对你有用。如果你只是好奇LLM怎么落地到传统行业也可以看看我们是怎么把“油管温度”这种口语描述变成可检索、可推理的知识单元的。2. 整体设计思路为什么不是简单的“文档ChatGPT”2.1 从“人找知识”到“知识找人”的转变传统Wiki的逻辑是“人找知识”你知道自己要查什么然后去目录里翻。但设备抢修场景下维修工往往不知道问题出在哪只知道“机器声音不对”“产品有飞边”“温度忽高忽低”。他需要的是系统主动把可能相关的知识推到他面前而不是让他自己去猜该搜什么关键词。LLM Wiki的设计逻辑是“知识找人”。用户输入一段自然语言描述系统先做意图识别和实体抽取判断这是故障诊断、备件查询还是操作规范问题然后从向量数据库中召回相关文档片段再让LLM综合这些片段生成回答。回答里必须标注引用来源比如“根据《XX注塑机液压系统维护手册》第3.2节”或者“参考2023年6月12日维修工单#4521”。这样既保证了可信度也让用户能顺着线索去查原文。2.2 为什么选择本地部署而不是调用公有云API设备管理知识库涉及大量工艺参数、设备图纸、供应商信息很多工厂对数据外流非常敏感。我们试过用公有云API做原型效果确实好但法务和保密部门直接否了。后来转向本地部署开源模型比如Qwen2.5-14B和Llama3-8B用Ollama做推理服务配合LangChain做编排。硬件成本大概是一台带RTX 4090的工控机两万出头对于年产值几千万的工厂来说完全可以接受。本地部署的另一个好处是可控。我们可以针对设备管理领域的术语做微调比如“飞边”“缩水”“拉伤”这些注塑行业黑话通用模型可能理解偏差但用几百条领域问答对做LoRA微调后准确率明显提升。而且本地模型响应速度稳定不依赖外网车间断网也能用。2.3 知识库的分层架构原始层、加工层、索引层我们把知识库分成三层。最底层是原始层存放所有未经修改的文档PDF手册、Excel台账、Word工单、甚至微信聊天记录截图OCR后转文字。这一层只做存储和版本管理不做任何加工保证原始信息的完整性。中间是加工层这是最耗人力的部分。我们把原始文档拆成“知识单元”每个单元包含设备型号、故障现象、可能原因、处理步骤、所需备件、安全注意事项、来源出处。比如“注塑机液压油温度过高”这个知识单元会关联到“油冷却器堵塞”“比例阀内泄”“冷却水流量不足”三个可能原因每个原因下面又有具体的排查步骤和判断标准。最上层是索引层用向量数据库我们用的是Milvus存储知识单元的嵌入向量同时保留关键词索引作为补充。用户提问时先做混合检索向量检索召回语义相近的单元关键词检索召回精确匹配的单元然后合并去重再交给LLM生成最终回答。2.4 为什么需要“Wiki”这个外壳有人会问既然有LLM了为什么还要Wiki界面直接做个聊天窗口不就行了我们的经验是聊天窗口适合快速问答但不适合系统性学习。新员工入职培训时他需要按设备类型、按系统模块去浏览知识而不是随机提问。Wiki界面提供了目录导航、版本对比、评论批注、权限管理这些功能让知识库不仅是“问答工具”更是“培训教材”和“协作平台”。而且Wiki的编辑功能很重要。老师傅在聊天窗口里回答了一个问题系统可以自动把这段对话整理成知识单元推送给知识管理员审核。审核通过后这条新知识就正式进入知识库下次别人问类似问题就能直接调用。这就形成了一个“使用即贡献”的正循环。3. 核心细节解析知识单元怎么拆、模型怎么调、检索怎么做3.1 知识单元的颗粒度控制太粗没用太细太累知识单元的颗粒度是项目成败的关键。我们一开始拆得太细把每个操作步骤都单独建一个单元结果检索时召回一堆碎片LLM拼出来的回答逻辑混乱。后来调整策略以“一个完整的故障处理闭环”为一个单元从现象描述到原因分析到处理措施到验证方法全部放在一个单元里。这样LLM拿到的上下文是完整的生成的回答也更有条理。具体来说一个合格的知识单元包含以下字段字段名说明示例设备类型设备大类注塑机设备型号具体型号HT-160故障现象用户可观察到的现象产品表面有银色条纹可能原因按概率排序的原因列表1. 料筒温度过低 2. 射速过快 3. 模具排气不良排查步骤逐步排查方法1. 检查料筒三段温度是否达到设定值 2. 检查射速参数是否被修改处理措施确认原因后的处理方法若温度偏低延长预热时间15分钟所需备件可能需要的备件加热圈、热电偶安全注意操作禁忌拆卸加热圈前必须断电并等待冷却来源文档出处或工单号《HT-160操作手册》P45工单#4521这个结构看起来简单但实际拆解时有很多坑。比如“可能原因”的排序不能拍脑袋要基于历史工单的统计频率。我们写了个小脚本从三年的维修工单里提取故障现象和更换备件的对应关系用频率统计来给原因排序。这样LLM给出的建议才符合实际概率而不是教科书上的理论排序。3.2 向量化模型的选择通用模型够不够用我们试过三种嵌入模型OpenAI的text-embedding-3-small、BGE-M3、以及针对工业领域微调过的GTE-large。在设备管理场景下通用模型对“飞边”“缩水”“拉伤”这类行业术语的区分度不够经常把“飞边”和“毛刺”混为一谈。后来用两千条设备故障问答对GTE-large做对比学习微调检索准确率从72%提升到89%。微调的方法不复杂用Sentence-Transformers框架构造正样本对同一故障的不同描述和负样本对不同故障的描述跑几个epoch就能看到明显效果。关键是样本质量我们让三个老师傅分别标注了五百条故障描述取交集作为正样本这样标注一致性有保证。3.3 检索策略混合检索重排序单纯向量检索有个问题对精确匹配不敏感。比如用户问“HT-160的加热圈功率是多少”向量检索可能召回一堆关于加热圈故障的文档但就是找不到具体功率数值。所以我们加了关键词检索作为补充用BM25算法做精确匹配然后把两路结果合并再用一个交叉编码器Cross-Encoder做重排序。重排序模型我们用的是BGE-Reranker-Large它会把用户问题和每个候选文档片段一起输入输出相关性分数。实测下来加了重排序之后Top3召回率从81%提升到94%。代价是响应时间增加了300毫秒左右但在车间场景下完全可以接受。3.4 提示词工程让LLM说“人话”且“有据可查”LLM生成回答时最容易犯两个毛病一是胡编乱造二是过于笼统。我们的提示词模板经过十几版迭代最终固定为以下结构你是一名设备管理专家请根据以下知识片段回答用户问题。 要求 1. 只使用知识片段中的信息不要编造。 2. 如果知识片段不足以回答请明确说“当前知识库中没有相关信息”。 3. 回答要分点列出每点注明来源。 4. 如果涉及安全操作必须在开头用【安全提示】标注。 5. 语言要口语化像老师傅带徒弟一样。 知识片段 {context} 用户问题{question}这个模板的关键在于“只使用知识片段中的信息”和“注明来源”。前者限制了LLM的自由发挥空间后者让用户能追溯验证。我们还加了一个后处理步骤用正则表达式检查回答中是否包含“根据”“参考”“来源”等词如果没有就自动追加一条提示“本回答基于知识库检索生成建议结合现场实际情况判断”。4. 实操过程从零搭建一套可用的LLM Wiki4.1 环境准备与工具选型硬件方面我们用的是一台工控机配置如下Intel i7-13700K、64GB DDR5、RTX 4090 24GB、2TB NVMe SSD。这个配置能同时跑14B参数的模型和嵌入模型响应速度在2秒以内。如果预算有限RTX 3090 24GB也可以但推理速度会慢30%左右。软件栈推理框架Ollama管理模型加载和推理编排框架LangChain处理检索和生成流程向量数据库Milvus存储和检索嵌入向量文档解析Unstructured处理PDF、Word、ExcelWiki前端Outline开源Wiki系统支持Markdown和API模型Qwen2.5-14B-Instruct主模型、BGE-M3嵌入、BGE-Reranker-Large重排序安装过程不复杂Ollama一条命令就能拉取模型Milvus用Docker Compose启动。关键是网络环境要稳定因为要下载几十GB的模型文件。我们第一次部署时因为车间网络波动模型下载中断了三次后来把工控机搬到办公室下载完再搬回去。4.2 文档解析与知识单元抽取文档解析是最脏最累的活。PDF手册还好用Unstructured能提取出大部分文字和表格。但扫描版的手册需要OCR我们用的是PaddleOCR对中文识别效果不错。Excel台账相对简单用pandas读取后按行转成知识单元。最麻烦的是Word工单格式五花八门有的用表格有的用段落还有的夹杂手写批注。我们写了一个规则引擎先按标题层级切分再用正则表达式提取关键字段最后人工审核补漏。知识单元抽取的自动化程度大概能做到70%剩下30%必须人工干预。我们的做法是先用脚本批量生成候选单元然后让两个老师傅在Wiki界面里逐条审核修改字段、补充遗漏、删除重复。审核一条大概需要3-5分钟一千条知识单元两个人一周能搞定。4.3 向量化与索引构建知识单元审核通过后用BGE-M3生成嵌入向量。每个知识单元生成两个向量一个基于“故障现象可能原因”的摘要向量用于语义检索一个基于全文的详细向量用于重排序。向量维度是1024存入Milvus的Collection中同时把知识单元的ID和元数据设备类型、型号、来源一起存进去方便过滤。索引构建时要注意Milvus的索引类型选IVF_FLAT还是HNSW我们实测下来HNSW的检索速度更快但内存占用高。对于一万条以内的知识单元IVF_FLAT足够用内存占用只有HNSW的三分之一。如果知识库规模超过十万条再考虑HNSW。4.4 Wiki界面集成与权限管理Outline作为Wiki前端通过API和我们的检索服务对接。用户在Outline里搜索时除了传统的全文检索还会触发LLM问答。问答结果以“AI助手”的形式展示在侧边栏点击引用链接可以跳转到对应的知识单元页面。权限管理分三级普通员工只能查看和提问班组长可以编辑知识单元和审核AI生成的回答知识管理员可以管理目录结构和用户权限。我们还加了一个“贡献积分”机制员工每提交一条被采纳的知识单元积10分积分可以兑换小礼品。这个机制上线三个月知识库新增了四百多条来自一线的故障案例。4.5 模型微调与持续迭代基础模型用Qwen2.5-14B-Instruct在通用任务上表现不错但对设备管理领域的术语理解不够精准。我们用LoRA做轻量微调训练数据是两千条“问题-回答”对格式如下{ instruction: 注塑机产品表面有银色条纹是什么原因, output: 根据知识库可能原因有1. 料筒温度过低建议检查三段温度是否达到设定值2. 射速过快建议降低射速10%-15%3. 模具排气不良建议清理排气槽。来源《HT-160操作手册》P45。 }微调在单卡4090上跑了6个小时损失降到0.8左右。微调后的模型在领域问答测试集上的准确率从76%提升到91%。关键是微调后的模型更“听话”不会动不动就扯到无关话题上。5. 常见问题与排查技巧实录5.1 检索召回不准先查嵌入模型再查知识单元质量最常见的问题是用户问了一个问题系统召回了一堆不相关的文档。排查顺序如下先看嵌入模型是否适合领域。用几个典型问题测试如果通用模型对行业术语区分度差就考虑微调嵌入模型。再看知识单元的质量。很多召回不准是因为知识单元本身写得模糊比如“设备异常”这种描述向量化后跟什么都像。解决办法是强制要求知识单元必须包含具体的现象描述和型号信息。最后看检索策略。如果向量检索和关键词检索的结果差异很大说明需要调整权重。我们最终把向量检索权重设为0.7关键词检索权重设为0.3重排序后再取Top5。5.2 LLM胡编乱造提示词约束后处理校验即使提示词里写了“不要编造”LLM偶尔还是会自由发挥。我们的应对策略是在提示词里加入“如果知识片段中没有相关信息请直接说不知道”并且在生成后做一次校验——用另一个小模型判断回答中的每个事实性陈述是否能在知识片段中找到对应。如果找不到就在回答末尾加一条警告“部分内容可能不准确请核实后使用。”5.3 响应速度慢模型量化缓存14B模型在4090上跑首次响应大概3-5秒连续对话时因为KV缓存能降到1-2秒。如果觉得慢可以用4-bit量化速度提升一倍准确率下降不到3%。另外常见问题可以加缓存比如“HT-160加热圈功率”这种高频问题第一次生成后把回答存起来下次直接返回响应时间降到毫秒级。5.4 知识库更新滞后自动化流水线人工审核设备管理知识更新很快新故障、新备件、新工艺不断出现。我们建了一条自动化流水线维修工在工单系统里提交故障处理记录后系统自动提取关键信息生成知识单元草稿推送到Wiki的审核队列。审核人员确认后知识单元自动向量化并入库。从工单提交到知识入库最快只要半小时。5.5 常见问题速查表问题现象可能原因排查方法解决方案检索结果不相关嵌入模型领域适配差用典型问题测试Top5召回微调嵌入模型或更换模型LLM回答编造信息提示词约束不足检查回答中是否有来源标注加强提示词约束加后处理校验响应时间超过5秒模型太大或硬件不足查看GPU利用率和显存占用量化模型或升级硬件知识单元重复抽取规则不完善统计相似度高于0.9的单元加去重步骤人工合并用户不用界面复杂或入口太深观察用户点击热力图简化界面把问答入口放在首页5.6 几个只有踩过坑才知道的细节第一知识单元的“来源”字段一定要填。我们一开始觉得来源不重要后来发现用户看到回答后第一反应是“真的假的”有来源标注的回答信任度明显更高。而且来源字段还能用于权限控制比如某些供应商提供的保密文档只对特定人员可见。第二LLM的回答长度要控制。太短了信息不全太长了用户没耐心看。我们的经验是故障诊断类回答控制在200-300字操作规范类控制在150字以内备件查询类直接给表格。第三一定要做移动端适配。车间里维修工很少带笔记本电脑都是用手机或平板。Wiki界面必须能在手机上流畅使用问答输入框要大回答要能一键复制。第四定期做“知识体检”。我们每季度跑一次全量检索测试用一百个标准问题检查召回率和准确率发现下降就及时调整。知识库跟设备一样不维护就会退化。6. 这套实践后续还能怎么扩展目前这套LLM Wiki主要用在故障诊断和操作规范查询上但设备管理的场景远不止这些。我们正在尝试几个方向一是把备件库存系统和知识库打通用户问“HT-160加热圈坏了怎么办”系统不仅给出更换步骤还能直接显示备件库存位置和替代型号。二是把设备运行数据接进来比如温度、压力、振动传感器数据让LLM结合实时数据做预测性维护建议。三是做多模态让用户直接拍设备照片或录声音系统识别异常后自动检索相关知识。技术栈上我们计划把LangChain换成LangGraph因为设备管理流程往往涉及多步推理和条件分支LangGraph的图结构更适合。另外我们正在测试用更小的模型3B-7B做边缘部署把推理能力下沉到车间网关进一步降低延迟。我个人在实际操作中的体会是LLM Wiki这类项目技术只占三成七成是知识运营。模型可以换框架可以调但如果没有一套机制让老师傅愿意贡献经验、让一线员工愿意使用反馈再好的技术也是摆设。我们花了大量时间在设计激励机制和审核流程上这些“非技术”工作才是项目能持续运转的关键。 基于LLM与Wiki的设备管理知识库：从隐性经验到智能问答的落地实践
1. 设备管理为什么需要一套“活”的知识库干了十几年设备管理的人都有一个共同感受最值钱的东西不在台账里也不在备件库里而是在老师傅的脑子里。一台进口注塑机报了个从没见过的故障码操作工翻遍手册找不到对应条目最后是干了二十年的老张过来听了听声音、摸了摸油管温度说了句“比例阀卡了拆下来用煤油泡半小时”问题就解决了。这种事在工厂里每天都在发生但老张退休那天这套判断逻辑就跟着他一起走了。我所在的团队从2022年开始尝试把这类隐性经验沉淀下来。最初用的是传统Wiki按设备类型建目录每台设备下面挂故障案例、维修记录、备件清单。写了半年文档数量上去了但真正用的人很少。原因很简单检索太费劲。一台设备可能有几十个故障模式每个模式又对应不同的工况、批次、环境条件靠目录树和关键词搜索一线维修工在抢修现场根本没耐心一层层点进去找。他们宁可打电话问人。大语言模型LLM的出现让这件事有了转机。LLM的核心能力是语义理解和生成它不需要你精确匹配关键词你用大白话描述现象它就能从一堆非结构化文本里找到相关段落甚至能综合多个来源给出判断建议。这正好切中了设备管理知识库的痛点知识是碎片化的、口语化的、依赖上下文的而LLM擅长处理的就是这种“不规整”的信息。于是我们启动了一个内部项目代号就叫“LLM Wiki”。目标很明确把设备管理相关的操作手册、维修工单、故障案例、专家访谈记录、备件规格书全部喂给一个本地部署的大模型再配上一套Wiki式的知识管理界面让一线人员能用自然语言提问系统给出带出处的回答。这个项目不是要替代老师傅而是要把老师傅的判断逻辑“翻译”成系统能理解的知识结构让更多人在更多场景下能调用这套经验。适合谁来参考这套实践如果你是工厂设备科长、维修班组长、工业互联网平台的产品经理或者正在做企业知识库的IT负责人这篇文章里的思路和踩坑记录应该对你有用。如果你只是好奇LLM怎么落地到传统行业也可以看看我们是怎么把“油管温度”这种口语描述变成可检索、可推理的知识单元的。2. 整体设计思路为什么不是简单的“文档ChatGPT”2.1 从“人找知识”到“知识找人”的转变传统Wiki的逻辑是“人找知识”你知道自己要查什么然后去目录里翻。但设备抢修场景下维修工往往不知道问题出在哪只知道“机器声音不对”“产品有飞边”“温度忽高忽低”。他需要的是系统主动把可能相关的知识推到他面前而不是让他自己去猜该搜什么关键词。LLM Wiki的设计逻辑是“知识找人”。用户输入一段自然语言描述系统先做意图识别和实体抽取判断这是故障诊断、备件查询还是操作规范问题然后从向量数据库中召回相关文档片段再让LLM综合这些片段生成回答。回答里必须标注引用来源比如“根据《XX注塑机液压系统维护手册》第3.2节”或者“参考2023年6月12日维修工单#4521”。这样既保证了可信度也让用户能顺着线索去查原文。2.2 为什么选择本地部署而不是调用公有云API设备管理知识库涉及大量工艺参数、设备图纸、供应商信息很多工厂对数据外流非常敏感。我们试过用公有云API做原型效果确实好但法务和保密部门直接否了。后来转向本地部署开源模型比如Qwen2.5-14B和Llama3-8B用Ollama做推理服务配合LangChain做编排。硬件成本大概是一台带RTX 4090的工控机两万出头对于年产值几千万的工厂来说完全可以接受。本地部署的另一个好处是可控。我们可以针对设备管理领域的术语做微调比如“飞边”“缩水”“拉伤”这些注塑行业黑话通用模型可能理解偏差但用几百条领域问答对做LoRA微调后准确率明显提升。而且本地模型响应速度稳定不依赖外网车间断网也能用。2.3 知识库的分层架构原始层、加工层、索引层我们把知识库分成三层。最底层是原始层存放所有未经修改的文档PDF手册、Excel台账、Word工单、甚至微信聊天记录截图OCR后转文字。这一层只做存储和版本管理不做任何加工保证原始信息的完整性。中间是加工层这是最耗人力的部分。我们把原始文档拆成“知识单元”每个单元包含设备型号、故障现象、可能原因、处理步骤、所需备件、安全注意事项、来源出处。比如“注塑机液压油温度过高”这个知识单元会关联到“油冷却器堵塞”“比例阀内泄”“冷却水流量不足”三个可能原因每个原因下面又有具体的排查步骤和判断标准。最上层是索引层用向量数据库我们用的是Milvus存储知识单元的嵌入向量同时保留关键词索引作为补充。用户提问时先做混合检索向量检索召回语义相近的单元关键词检索召回精确匹配的单元然后合并去重再交给LLM生成最终回答。2.4 为什么需要“Wiki”这个外壳有人会问既然有LLM了为什么还要Wiki界面直接做个聊天窗口不就行了我们的经验是聊天窗口适合快速问答但不适合系统性学习。新员工入职培训时他需要按设备类型、按系统模块去浏览知识而不是随机提问。Wiki界面提供了目录导航、版本对比、评论批注、权限管理这些功能让知识库不仅是“问答工具”更是“培训教材”和“协作平台”。而且Wiki的编辑功能很重要。老师傅在聊天窗口里回答了一个问题系统可以自动把这段对话整理成知识单元推送给知识管理员审核。审核通过后这条新知识就正式进入知识库下次别人问类似问题就能直接调用。这就形成了一个“使用即贡献”的正循环。3. 核心细节解析知识单元怎么拆、模型怎么调、检索怎么做3.1 知识单元的颗粒度控制太粗没用太细太累知识单元的颗粒度是项目成败的关键。我们一开始拆得太细把每个操作步骤都单独建一个单元结果检索时召回一堆碎片LLM拼出来的回答逻辑混乱。后来调整策略以“一个完整的故障处理闭环”为一个单元从现象描述到原因分析到处理措施到验证方法全部放在一个单元里。这样LLM拿到的上下文是完整的生成的回答也更有条理。具体来说一个合格的知识单元包含以下字段字段名说明示例设备类型设备大类注塑机设备型号具体型号HT-160故障现象用户可观察到的现象产品表面有银色条纹可能原因按概率排序的原因列表1. 料筒温度过低 2. 射速过快 3. 模具排气不良排查步骤逐步排查方法1. 检查料筒三段温度是否达到设定值 2. 检查射速参数是否被修改处理措施确认原因后的处理方法若温度偏低延长预热时间15分钟所需备件可能需要的备件加热圈、热电偶安全注意操作禁忌拆卸加热圈前必须断电并等待冷却来源文档出处或工单号《HT-160操作手册》P45工单#4521这个结构看起来简单但实际拆解时有很多坑。比如“可能原因”的排序不能拍脑袋要基于历史工单的统计频率。我们写了个小脚本从三年的维修工单里提取故障现象和更换备件的对应关系用频率统计来给原因排序。这样LLM给出的建议才符合实际概率而不是教科书上的理论排序。3.2 向量化模型的选择通用模型够不够用我们试过三种嵌入模型OpenAI的text-embedding-3-small、BGE-M3、以及针对工业领域微调过的GTE-large。在设备管理场景下通用模型对“飞边”“缩水”“拉伤”这类行业术语的区分度不够经常把“飞边”和“毛刺”混为一谈。后来用两千条设备故障问答对GTE-large做对比学习微调检索准确率从72%提升到89%。微调的方法不复杂用Sentence-Transformers框架构造正样本对同一故障的不同描述和负样本对不同故障的描述跑几个epoch就能看到明显效果。关键是样本质量我们让三个老师傅分别标注了五百条故障描述取交集作为正样本这样标注一致性有保证。3.3 检索策略混合检索重排序单纯向量检索有个问题对精确匹配不敏感。比如用户问“HT-160的加热圈功率是多少”向量检索可能召回一堆关于加热圈故障的文档但就是找不到具体功率数值。所以我们加了关键词检索作为补充用BM25算法做精确匹配然后把两路结果合并再用一个交叉编码器Cross-Encoder做重排序。重排序模型我们用的是BGE-Reranker-Large它会把用户问题和每个候选文档片段一起输入输出相关性分数。实测下来加了重排序之后Top3召回率从81%提升到94%。代价是响应时间增加了300毫秒左右但在车间场景下完全可以接受。3.4 提示词工程让LLM说“人话”且“有据可查”LLM生成回答时最容易犯两个毛病一是胡编乱造二是过于笼统。我们的提示词模板经过十几版迭代最终固定为以下结构你是一名设备管理专家请根据以下知识片段回答用户问题。 要求 1. 只使用知识片段中的信息不要编造。 2. 如果知识片段不足以回答请明确说“当前知识库中没有相关信息”。 3. 回答要分点列出每点注明来源。 4. 如果涉及安全操作必须在开头用【安全提示】标注。 5. 语言要口语化像老师傅带徒弟一样。 知识片段 {context} 用户问题{question}这个模板的关键在于“只使用知识片段中的信息”和“注明来源”。前者限制了LLM的自由发挥空间后者让用户能追溯验证。我们还加了一个后处理步骤用正则表达式检查回答中是否包含“根据”“参考”“来源”等词如果没有就自动追加一条提示“本回答基于知识库检索生成建议结合现场实际情况判断”。4. 实操过程从零搭建一套可用的LLM Wiki4.1 环境准备与工具选型硬件方面我们用的是一台工控机配置如下Intel i7-13700K、64GB DDR5、RTX 4090 24GB、2TB NVMe SSD。这个配置能同时跑14B参数的模型和嵌入模型响应速度在2秒以内。如果预算有限RTX 3090 24GB也可以但推理速度会慢30%左右。软件栈推理框架Ollama管理模型加载和推理编排框架LangChain处理检索和生成流程向量数据库Milvus存储和检索嵌入向量文档解析Unstructured处理PDF、Word、ExcelWiki前端Outline开源Wiki系统支持Markdown和API模型Qwen2.5-14B-Instruct主模型、BGE-M3嵌入、BGE-Reranker-Large重排序安装过程不复杂Ollama一条命令就能拉取模型Milvus用Docker Compose启动。关键是网络环境要稳定因为要下载几十GB的模型文件。我们第一次部署时因为车间网络波动模型下载中断了三次后来把工控机搬到办公室下载完再搬回去。4.2 文档解析与知识单元抽取文档解析是最脏最累的活。PDF手册还好用Unstructured能提取出大部分文字和表格。但扫描版的手册需要OCR我们用的是PaddleOCR对中文识别效果不错。Excel台账相对简单用pandas读取后按行转成知识单元。最麻烦的是Word工单格式五花八门有的用表格有的用段落还有的夹杂手写批注。我们写了一个规则引擎先按标题层级切分再用正则表达式提取关键字段最后人工审核补漏。知识单元抽取的自动化程度大概能做到70%剩下30%必须人工干预。我们的做法是先用脚本批量生成候选单元然后让两个老师傅在Wiki界面里逐条审核修改字段、补充遗漏、删除重复。审核一条大概需要3-5分钟一千条知识单元两个人一周能搞定。4.3 向量化与索引构建知识单元审核通过后用BGE-M3生成嵌入向量。每个知识单元生成两个向量一个基于“故障现象可能原因”的摘要向量用于语义检索一个基于全文的详细向量用于重排序。向量维度是1024存入Milvus的Collection中同时把知识单元的ID和元数据设备类型、型号、来源一起存进去方便过滤。索引构建时要注意Milvus的索引类型选IVF_FLAT还是HNSW我们实测下来HNSW的检索速度更快但内存占用高。对于一万条以内的知识单元IVF_FLAT足够用内存占用只有HNSW的三分之一。如果知识库规模超过十万条再考虑HNSW。4.4 Wiki界面集成与权限管理Outline作为Wiki前端通过API和我们的检索服务对接。用户在Outline里搜索时除了传统的全文检索还会触发LLM问答。问答结果以“AI助手”的形式展示在侧边栏点击引用链接可以跳转到对应的知识单元页面。权限管理分三级普通员工只能查看和提问班组长可以编辑知识单元和审核AI生成的回答知识管理员可以管理目录结构和用户权限。我们还加了一个“贡献积分”机制员工每提交一条被采纳的知识单元积10分积分可以兑换小礼品。这个机制上线三个月知识库新增了四百多条来自一线的故障案例。4.5 模型微调与持续迭代基础模型用Qwen2.5-14B-Instruct在通用任务上表现不错但对设备管理领域的术语理解不够精准。我们用LoRA做轻量微调训练数据是两千条“问题-回答”对格式如下{ instruction: 注塑机产品表面有银色条纹是什么原因, output: 根据知识库可能原因有1. 料筒温度过低建议检查三段温度是否达到设定值2. 射速过快建议降低射速10%-15%3. 模具排气不良建议清理排气槽。来源《HT-160操作手册》P45。 }微调在单卡4090上跑了6个小时损失降到0.8左右。微调后的模型在领域问答测试集上的准确率从76%提升到91%。关键是微调后的模型更“听话”不会动不动就扯到无关话题上。5. 常见问题与排查技巧实录5.1 检索召回不准先查嵌入模型再查知识单元质量最常见的问题是用户问了一个问题系统召回了一堆不相关的文档。排查顺序如下先看嵌入模型是否适合领域。用几个典型问题测试如果通用模型对行业术语区分度差就考虑微调嵌入模型。再看知识单元的质量。很多召回不准是因为知识单元本身写得模糊比如“设备异常”这种描述向量化后跟什么都像。解决办法是强制要求知识单元必须包含具体的现象描述和型号信息。最后看检索策略。如果向量检索和关键词检索的结果差异很大说明需要调整权重。我们最终把向量检索权重设为0.7关键词检索权重设为0.3重排序后再取Top5。5.2 LLM胡编乱造提示词约束后处理校验即使提示词里写了“不要编造”LLM偶尔还是会自由发挥。我们的应对策略是在提示词里加入“如果知识片段中没有相关信息请直接说不知道”并且在生成后做一次校验——用另一个小模型判断回答中的每个事实性陈述是否能在知识片段中找到对应。如果找不到就在回答末尾加一条警告“部分内容可能不准确请核实后使用。”5.3 响应速度慢模型量化缓存14B模型在4090上跑首次响应大概3-5秒连续对话时因为KV缓存能降到1-2秒。如果觉得慢可以用4-bit量化速度提升一倍准确率下降不到3%。另外常见问题可以加缓存比如“HT-160加热圈功率”这种高频问题第一次生成后把回答存起来下次直接返回响应时间降到毫秒级。5.4 知识库更新滞后自动化流水线人工审核设备管理知识更新很快新故障、新备件、新工艺不断出现。我们建了一条自动化流水线维修工在工单系统里提交故障处理记录后系统自动提取关键信息生成知识单元草稿推送到Wiki的审核队列。审核人员确认后知识单元自动向量化并入库。从工单提交到知识入库最快只要半小时。5.5 常见问题速查表问题现象可能原因排查方法解决方案检索结果不相关嵌入模型领域适配差用典型问题测试Top5召回微调嵌入模型或更换模型LLM回答编造信息提示词约束不足检查回答中是否有来源标注加强提示词约束加后处理校验响应时间超过5秒模型太大或硬件不足查看GPU利用率和显存占用量化模型或升级硬件知识单元重复抽取规则不完善统计相似度高于0.9的单元加去重步骤人工合并用户不用界面复杂或入口太深观察用户点击热力图简化界面把问答入口放在首页5.6 几个只有踩过坑才知道的细节第一知识单元的“来源”字段一定要填。我们一开始觉得来源不重要后来发现用户看到回答后第一反应是“真的假的”有来源标注的回答信任度明显更高。而且来源字段还能用于权限控制比如某些供应商提供的保密文档只对特定人员可见。第二LLM的回答长度要控制。太短了信息不全太长了用户没耐心看。我们的经验是故障诊断类回答控制在200-300字操作规范类控制在150字以内备件查询类直接给表格。第三一定要做移动端适配。车间里维修工很少带笔记本电脑都是用手机或平板。Wiki界面必须能在手机上流畅使用问答输入框要大回答要能一键复制。第四定期做“知识体检”。我们每季度跑一次全量检索测试用一百个标准问题检查召回率和准确率发现下降就及时调整。知识库跟设备一样不维护就会退化。6. 这套实践后续还能怎么扩展目前这套LLM Wiki主要用在故障诊断和操作规范查询上但设备管理的场景远不止这些。我们正在尝试几个方向一是把备件库存系统和知识库打通用户问“HT-160加热圈坏了怎么办”系统不仅给出更换步骤还能直接显示备件库存位置和替代型号。二是把设备运行数据接进来比如温度、压力、振动传感器数据让LLM结合实时数据做预测性维护建议。三是做多模态让用户直接拍设备照片或录声音系统识别异常后自动检索相关知识。技术栈上我们计划把LangChain换成LangGraph因为设备管理流程往往涉及多步推理和条件分支LangGraph的图结构更适合。另外我们正在测试用更小的模型3B-7B做边缘部署把推理能力下沉到车间网关进一步降低延迟。我个人在实际操作中的体会是LLM Wiki这类项目技术只占三成七成是知识运营。模型可以换框架可以调但如果没有一套机制让老师傅愿意贡献经验、让一线员工愿意使用反馈再好的技术也是摆设。我们花了大量时间在设计激励机制和审核流程上这些“非技术”工作才是项目能持续运转的关键。