设备管理这件事最让人头疼的从来不是修不好一台机器而是老师傅脑子里那套听声音就知道哪松了看油色就知道该换了的判断逻辑根本落不到纸面上。我所在的厂区有三十多台关键设备过去三年里两位核心维修师傅陆续退休带走了大量没来得及记录的故障判断经验。新来的技术员拿着厂家手册面对同一台设备报出的异响往往要花三四个小时才能定位到老师傅十分钟就能判断的问题。这个 LLM Wiki 项目就是想把这种人走经验散的困局用大语言模型加知识库的方式做成一套能持续沉淀、能被新人直接调用的设备管理系统。1. 设备管理知识为什么不能只靠文档堆砌1.1 传统设备台账的三个致命短板大多数工厂的设备管理资料本质上就是一堆静态文档设备说明书、维修记录表、点检标准、备件清单。这些东西不是没用但它们有个共同问题——检索维度太单一。你想查3号空压机排气温度偏高怎么处理得先知道它属于哪个系统、哪本手册、哪一章节然后翻半天。更麻烦的是维修记录里写的往往是更换轴承恢复正常至于为什么判断是轴承问题、当时振动值是多少、声音是什么特征全在师傅脑子里。我统计过我们厂过去两年的维修工单超过六成的故障描述只有一句话比如设备异常已处理。这种记录对后来人几乎零价值。真正有价值的是判断链路什么现象触发怀疑、排除了哪些可能、最终锁定哪个部件、更换后验证指标是什么。这些内容散落在师傅的微信聊天、交接班口头交代、甚至烟灰缸旁边的闲聊里从来没有被结构化地保存下来。第三个短板是知识更新滞后。设备改造、工艺参数调整、备件替代之后原来的手册和标准往往没有同步修订。新人拿着过时资料去判断轻则走弯路重则误判导致二次损坏。这三个问题叠加就造成了老师傅一走设备管理立刻掉一个档次的普遍现象。1.2 LLM Wiki 到底解决了哪个环节的问题LLM Wiki 不是要替代设备管理系统也不是要做一个万能问答机器人。它解决的核心问题是把非结构化的经验判断变成可检索、可追溯、可迭代的知识条目。传统 Wiki 靠人写词条写的人累读的人少最后变成僵尸页面。LLM Wiki 的思路是反过来——先用大语言模型把已有的零散记录、聊天内容、工单描述做初步结构化生成候选知识条目再由老师傅或技术骨干审核修正最后沉淀成标准词条。这里的关键在于LLM 做初稿人做审核。我试过让模型直接回答3号空压机异响怎么处理它给出的答案泛泛而谈没有现场价值。但当我把它接入我们自己的维修记录库让它先检索相似历史工单再生成判断建议时准确率明显提升。这说明 LLM Wiki 的价值不在模型本身多聪明而在于它能把检索、归纳、生成三个动作串起来降低知识沉淀的门槛。1.3 适合引入这套方法的设备类型不是所有设备都值得做 LLM Wiki。我的经验是满足以下三个条件中的两个以上投入产出比就比较高一是故障模式多、判断依赖经验比如液压系统、传动系统、老旧进口设备二是维修频次高每月至少三到五次三是新人上手周期长超过三个月才能独立判断。反过来那些结构简单、故障模式单一、厂家远程支持到位的设备用标准手册就够了硬上 LLM Wiki 反而是浪费。我们厂第一批纳入的是六台关键设备两台空压机、一台大型液压机、两台数控加工中心、一台老式锅炉。这六台设备的共同点是维修记录多但质量差、老师傅依赖度高、停机损失大。运行三个月后新人独立处理常见故障的平均时间从原来的两小时四十分降到了四十分钟左右这个数据后面我会详细说怎么统计的。2. 从零搭建 LLM Wiki 的完整链路2.1 数据采集先把散落各处的记录收拢搭建的第一步不是选模型而是把数据找齐。我们花了整整两周做这件事来源包括近三年的电子工单、老师傅手写的维修笔记拍照后 OCR、交接班记录本、微信群里的故障讨论、设备厂家的售后沟通邮件。这里有个坑要提醒不要一上来就追求数据干净先求全再求净。我们最初想只用工单数据结果发现工单里缺失的判断逻辑恰恰藏在微信聊天里。采集时我建议按设备编号建文件夹每个文件夹下再按时间倒序排列。对于手写笔记OCR 之后一定要人工过一遍因为设备型号、参数单位经常识别错比如0.8MPa被识别成0.8MPa还算好的有时候轴承会变成轴乘这种错误如果直接喂给模型后面生成的知识条目会跟着错。提示采集阶段就要开始做脱敏。涉及具体人员姓名、联系方式的内容在入库前统一替换成岗位代号比如张师傅改成维修一组资深技师。这不是为了保密而是避免后续知识条目里出现问张师傅这种无法执行的建议。2.2 数据清洗与分段让模型能读懂设备语言原始记录直接扔给模型效果很差因为一段工单可能混着故障现象、处理动作、备件消耗、停机时长四类信息。我们的做法是先做结构化分段把每条记录拆成固定字段设备编号、故障现象、判断依据、处理动作、更换备件、验证结果、记录人、日期。拆不出来的字段留空不要硬编。这个环节我用了一个简单的规则加人工的方式先用正则表达式提取设备编号和日期剩下的内容按段落切分每段不超过三百字。然后人工标注哪些段落属于判断依据哪些属于处理动作。标注了大约两百条之后模型就能比较准地自动分类了。这里的关键是判断依据这个字段它是 LLM Wiki 区别于普通维修台账的核心。比如一条记录写排气温度高检查冷却水流量正常听声音判断为轴承磨损更换后温度恢复正常其中检查冷却水流量正常听声音判断为轴承磨损就是判断依据必须单独拎出来。2.3 知识条目生成LLM 做初稿的提示词设计提示词这块我踩了不少坑。最开始用通用提示词请根据以下维修记录生成知识条目出来的东西像说明书没有现场感。后来改成角色设定加约束条件效果明显好转。核心提示词结构是这样的你是一名有二十年经验的设备维修技师正在为新人编写故障判断手册。 根据以下维修记录生成一条知识条目要求 1. 故障现象描述要具体包含可观测的指标温度、振动、声音、油色等 2. 判断依据要写清楚排除过程不要直接给结论 3. 处理动作要分步骤每步说明预期结果 4. 如果记录中信息不足用待补充标注不要编造 5. 输出格式为现象 / 判断链路 / 处理步骤 / 验证标准 / 关联备件这个提示词的关键在于要求写排除过程。设备维修的本质是排除法直接给结论的知识条目没有教学价值。比如异响是轴承问题这句话没用有用的是异响随转速升高而加剧排除皮带打滑皮带张紧度正常排除联轴器对中偏差激光对中仪读数在范围内锁定轴承室拆检发现滚珠点蚀。生成初稿后我们会让老师傅逐条审核。审核不是改文字而是判断这条知识能不能直接拿去用。不能用的打回重生成能用的标注置信度。置信度分三级A 级是老师傅亲自处理过的案例B 级是记录完整但非亲历C 级是信息不全需要后续补充。只有 A 级和 B 级条目才会进入正式知识库。2.4 检索层设计为什么不能只靠向量数据库很多人做 LLM Wiki 第一反应是上向量数据库做语义检索。我试过纯向量检索在设备管理场景下有个明显问题它太擅长找相似不擅长找精确。比如你查3号空压机排气温度高向量检索可能给你返回2号空压机排气压力低的条目因为语义相近。但设备管理里设备编号和故障类型是硬约束不能模糊。我们的方案是混合检索先用设备编号和故障类型做精确过滤再用向量检索在过滤后的结果里找语义最接近的条目。具体实现上用轻量级的关键词索引做第一层向量索引做第二层。这样既保证了设备维度的准确性又保留了语义匹配的灵活性。实测下来混合检索的命中率比纯向量检索高了将近四成尤其是在设备型号相近但故障模式不同的场景下优势非常明显。3. 让老师傅愿意配合的落地策略3.1 知识贡献的激励设计比技术更重要技术链路跑通只完成了一半另一半是让人愿意贡献知识。老师傅不写记录不是不会写是觉得写了没好处还担责任。我们的做法是把知识贡献和绩效脱钩改成荣誉加便利。具体来说每条被采纳的 A 级知识条目署名到人在系统里显示本条由某某技师贡献同时贡献者在使用系统时享有优先检索权比如新人只能看到标准条目贡献者能看到原始记录和讨论历史。这个设计的关键是让贡献者先受益。老师傅最烦的是被问重复问题系统上线后新人遇到常见故障先查 Wiki查不到再问人。运行两个月后老师傅被重复咨询的次数下降了大约六成他们自己感受到了便利配合度自然就上来了。反过来如果一上来就搞考核、搞排名老师傅会觉得你在榨取他的经验抵触情绪会很大。3.2 审核流程要短反馈要快知识条目从生成到入库我们控制在三天以内。流程是LLM 生成初稿 → 技术员初筛 → 老师傅审核 → 入库。老师傅审核一条平均花五到八分钟每天最多审核十条不占用大块时间。如果一条条目超过一周没审核系统会自动提醒但不会催得太紧。这里有个细节审核界面要极简最好在手机上就能完成点通过修改打回三个按钮就行。我们最初做了一个复杂的审核表单结果老师傅根本不用后来改成微信小程序里的卡片式审核通过率立刻上来了。注意不要让老师傅从零写条目。他们的价值在于判断和修正不在于打字。LLM 生成初稿虽然不完美但给了老师傅一个改错的起点比从空白开始写容易接受得多。3.3 处理老师傅的留一手心理这个必须坦诚说。部分老师傅确实有留一手的心理觉得经验是自己的饭碗全交出去就没价值了。我的处理方式是不强行要求全交而是先交已经过时或即将淘汰的那部分。比如某台设备明年就要报废相关经验留着也没用先引导贡献这部分。等系统跑起来老师傅看到自己的经验被新人用起来、被尊重再逐步引导贡献核心经验。这个过程急不得强行推动只会适得其反。另外我们设置了一个师徒绑定机制老师傅贡献的知识条目如果被某位新人频繁使用并解决了问题系统会记录这条传承链路在季度总结时给双方都记一笔。这个机制让老师傅觉得自己的经验在延续而不是被剥夺。4. 实测数据与踩坑复盘4.1 三个月运行的关键指标变化系统上线三个月后我统计了几个核心指标。需要说明的是这些数据来自我们厂的实际运行样本量不大但趋势比较明显。指标上线前上线后变化幅度新人独立处理常见故障平均耗时2小时40分40分钟下降约75%老师傅被重复咨询次数每周约35次约13次下降约63%维修记录完整率约22%约68%提升约46个百分点知识条目累计数量0217条—其中A级条目占比—31%—维修记录完整率的提升是个意外收获。因为技术员在生成知识条目的过程中会主动补充缺失的字段反过来倒逼了原始记录的规范化。这个正向循环是我们最初没有预料到的。4.2 踩过的三个大坑第一个坑是模型幻觉。早期我们让模型直接生成处理建议结果它编造了一个不存在的备件型号技术员照着去领料仓库说没这个东西查了半天才发现是模型瞎编的。后来我们在提示词里加了硬约束所有备件型号必须从已有备件库中检索检索不到就标注待确认不允许自由生成。这个改动之后备件相关的错误基本消失了。第二个坑是知识条目粒度失控。最初生成的条目有的太粗比如空压机故障处理一条包打天下有的太细比如3号空压机2023年5月12日排气温度高这种一次性事件也单独成条。后来我们定了粒度标准一条知识条目对应一类故障模式而不是一次具体事件。判断标准是如果两条记录的处理逻辑相同就合并成一条如果处理逻辑不同即使现象相似也分开。第三个坑是检索结果没有优先级。早期所有条目平权展示新人不知道该信哪条。后来我们加了权重A级条目优先展示B级次之C级折叠同时最近三个月内被验证有效的条目权重更高。这个改动让检索结果的可用性提升了很多。4.3 一个具体的故障判断链路示例拿我们厂3号空压机的一次实际故障来说。现象是排气温度从正常的75度升到92度触发报警。新人查 Wiki 后看到的条目是这样的现象排气温度持续升高超过85度报警值冷却水进出口温差小于5度。判断链路先查冷却水流量正常流量计读数12立方米每小时再查冷却器进出口温差偏小怀疑冷却器结垢同时听机头声音有轻微周期性摩擦声怀疑轴承磨损。两个疑点并存先处理冷却器成本低、停机短清洗后温度降至80度但仍有波动进一步拆检轴承发现滚珠点蚀更换后温度稳定在74度。处理步骤第一步记录冷却水流量和温差判断冷却系统是否正常第二步若冷却系统正常但温度仍高用听音棒判断机头轴承状态第三步优先处理低成本项验证后再决定是否拆机。验证标准排气温度稳定在75度正负3度冷却水进出口温差不小于8度机头无异响。关联备件轴承型号、冷却器清洗剂。这条条目是 A 级由一位退休返聘的老师傅审核确认。新人照着这个链路走四十分钟内完成了判断和处理。如果没有这条条目他大概率会先拆机头因为手册上写的是排气温度高优先检查轴承但实际这次是冷却器和轴承同时有问题先处理冷却器更合理。这就是经验的价值也是 LLM Wiki 要沉淀的东西。5. 后续扩展方向与个人体会5.1 从单厂知识库到多厂知识网络单厂的知识条目数量有限我们目前217条覆盖了六台设备的大部分常见故障。但设备管理里有个长尾问题罕见故障虽然发生频率低一旦发生往往损失巨大。解决思路是多厂联合建库把同型号设备的知识条目共享。我们正在和兄弟厂区做试点把同型号空压机的条目合并去重目前看效果不错合并后条目数量增加了约四成但重复率不到15%。这里的技术难点是条目对齐。不同厂区的记录习惯不同同一个故障可能叫法不一样。我们的做法是建一个设备本体Ontology把设备部件、故障类型、判断指标做标准化映射。比如机头异响主机声音异常压缩机摩擦声统一映射到机头异响这个标准术语。这个映射表目前是人工维护的后续考虑用模型辅助生成候选映射人工审核。5.2 和现有设备管理系统的对接思路LLM Wiki 不应该是一个孤岛。我们下一步的计划是把它和现有的工单系统、备件系统打通。具体来说工单系统里新建工单时自动推荐相关 Wiki 条目备件系统里领料时自动关联该备件相关的故障条目。这样知识就不是查了才用而是用到时自动出现。对接的技术方案上我们倾向于用 API 网关做中间层而不是直接改工单系统的数据库。原因是工单系统是核心业务系统稳定性要求极高任何改动都要走严格的变更流程。用 API 网关做旁路集成风险可控迭代也快。这个思路供参考具体要看各厂的系统架构和安全要求。5.3 我个人的几点实操体会第一不要追求一步到位。我们最初想做一个全厂所有设备的 LLM Wiki结果铺得太开数据质量参差不齐模型生成的内容也没人审核。后来收缩到六台关键设备做深做透反而跑通了。先做样板再推广这个节奏很重要。第二老师傅的审核不可替代。模型可以生成初稿可以检索可以归纳但它无法判断一条经验在特定设备上是否适用。我们试过让模型自己审核自己生成的内容错误率明显高于人工审核。老师傅的五到八分钟审核是整个链路里价值最高的环节。第三知识库要活。我们每个月会做一次条目复盘把三个月内没有被检索过的条目拿出来看要么合并要么降级要么删除。知识库不是越大越好而是越准越好。一个只有五十条但条条能用的库比五百条良莠不齐的库有价值得多。第四接受不完美。有些经验就是没法完全结构化比如听声音判断这种文字描述再细也不如现场听一次。我们的做法是在条目里嵌入音频片段或视频链接让新人先听标准音再去现场对比。这个补充手段虽然原始但确实管用。最后分享一个我们正在试的小技巧把高频故障的判断链路做成决策树嵌在 Wiki 条目里。新人不需要读完整条目只需要按树状分支回答是/否就能走到处理步骤。这个方式对完全没经验的新人特别友好目前在小范围试用反馈不错。后续如果跑通了再单独写一篇复盘。