基于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拿到的上下文是完整的，生成的回答也更有条理。

具体来说，一个合格的知识单元包含以下字段：

这个结构看起来简单，但实际拆解时有很多坑。比如“可能原因”的排序，不能拍脑袋，要基于历史工单的统计频率。我们写了个小脚本，从三年的维修工单里提取故障现象和更换备件的对应关系，用频率统计来给原因排序。这样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 Wiki

4.1 环境准备与工具选型

硬件方面，我们用的是一台工控机，配置如下：Intel i7-13700K、64GB DDR5、RTX 4090 24GB、2TB NVMe SSD。这个配置能同时跑14B参数的模型和嵌入模型，响应速度在2秒以内。如果预算有限，RTX 3090 24GB也可以，但推理速度会慢30%左右。

软件栈：

• 推理框架：Ollama（管理模型加载和推理）
• 编排框架：LangChain（处理检索和生成流程）
• 向量数据库：Milvus（存储和检索嵌入向量）
• 文档解析：Unstructured（处理PDF、Word、Excel）
• Wiki前端：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 检索召回不准：先查嵌入模型，再查知识单元质量

最常见的问题是用户问了一个问题，系统召回了一堆不相关的文档。排查顺序如下：

1. 先看嵌入模型是否适合领域。用几个典型问题测试，如果通用模型对行业术语区分度差，就考虑微调嵌入模型。
2. 再看知识单元的质量。很多召回不准是因为知识单元本身写得模糊，比如“设备异常”这种描述，向量化后跟什么都像。解决办法是强制要求知识单元必须包含具体的现象描述和型号信息。
3. 最后看检索策略。如果向量检索和关键词检索的结果差异很大，说明需要调整权重。我们最终把向量检索权重设为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 常见问题速查表

5.6 几个只有踩过坑才知道的细节

第一，知识单元的“来源”字段一定要填。我们一开始觉得来源不重要，后来发现用户看到回答后第一反应是“真的假的”，有来源标注的回答信任度明显更高。而且来源字段还能用于权限控制，比如某些供应商提供的保密文档，只对特定人员可见。

第二，LLM的回答长度要控制。太短了信息不全，太长了用户没耐心看。我们的经验是，故障诊断类回答控制在200-300字，操作规范类控制在150字以内，备件查询类直接给表格。

第三，一定要做移动端适配。车间里维修工很少带笔记本电脑，都是用手机或平板。Wiki界面必须能在手机上流畅使用，问答输入框要大，回答要能一键复制。

第四，定期做“知识体检”。我们每季度跑一次全量检索测试，用一百个标准问题检查召回率和准确率，发现下降就及时调整。知识库跟设备一样，不维护就会退化。

6. 这套实践后续还能怎么扩展

目前这套LLM Wiki主要用在故障诊断和操作规范查询上，但设备管理的场景远不止这些。我们正在尝试几个方向：一是把备件库存系统和知识库打通，用户问“HT-160加热圈坏了怎么办”，系统不仅给出更换步骤，还能直接显示备件库存位置和替代型号。二是把设备运行数据接进来，比如温度、压力、振动传感器数据，让LLM结合实时数据做预测性维护建议。三是做多模态，让用户直接拍设备照片或录声音，系统识别异常后自动检索相关知识。

技术栈上，我们计划把LangChain换成LangGraph，因为设备管理流程往往涉及多步推理和条件分支，LangGraph的图结构更适合。另外，我们正在测试用更小的模型（3B-7B）做边缘部署，把推理能力下沉到车间网关，进一步降低延迟。

我个人在实际操作中的体会是，LLM Wiki这类项目，技术只占三成，七成是知识运营。模型可以换，框架可以调，但如果没有一套机制让老师傅愿意贡献经验、让一线员工愿意使用反馈，再好的技术也是摆设。我们花了大量时间在设计激励机制和审核流程上，这些“非技术”工作才是项目能持续运转的关键。