★ FEATURED ARTICLE 1. 项目缘起从一张手写工单说起我在家电售后这行干了快十二年前六年跑现场修机器后六年蹲在后台做技术支持。你要问我最头疼的事是什么不是那些疑难杂症而是故障工单的编写。一张工单写得好不好直接决定了后续维修效率、配件调拨准确率甚至客户满意度。但现实是大部分维修师傅在客户家里蹲着手上全是油污掏出手机对着工单系统戳半天最后写出来的东西是这样的“冰箱不制冷换了压缩机好了。”——就这十几个字信息量几乎为零。博世这个品牌大家都熟德系精工的代表产品线从冰箱、洗衣机到洗碗机、烤箱型号多如牛毛。同一个“不制冷”的故障现象背后可能是压缩机启动器坏了、可能是温控板故障、可能是制冷剂泄漏、也可能是门封条老化导致冷气外泄。如果工单上只写“不制冷”后台的配件计划员就得靠猜猜错了配件发过去装不上师傅白跑一趟客户多等三天三方全输。所以当我第一次接触到“博世维修AI智能体”这个概念时我的反应是这事要是真能落地功德无量。这个智能体要干两件事第一帮师傅把故障工单写规范、写完整第二从海量旧案例里快速检索出相似故障给出维修建议。说白了就是给每个师傅配一个“老师傅外挂”——你描述个大概它帮你补全细节、匹配历史经验。这篇文章我就把这个智能体的设计思路、技术选型、实操细节和踩过的坑从头到尾捋一遍。不管你是做售后管理的、搞智能体开发的还是单纯对AI落地感兴趣都能从中拿到可以直接抄作业的东西。2. 整体设计思路为什么是“检索生成”双引擎2.1 核心需求拆解师傅到底需要什么在动手设计之前我先干了件笨但管用的事跟着三个不同工龄的师傅跑了整整一周的现场。工龄分别是两年、五年、十年。我记录了他们写工单的全过程发现几个关键痛点。两年经验的师傅最大的问题是不知道该写什么。他看到一个故障码知道要换某个件但说不清楚故障现象和判断依据。五年经验的师傅能写清楚现象和操作但懒得写全觉得“反正后台懂”。十年经验的师傅写得又快又准但他脑子里那套经验根本传不出来——你让他教新人他只会说“你多修几年就知道了”。这三个痛点对应了三个需求补全、规范、传承。补全是帮新手把信息补完整规范是让老手别偷懒传承是把老师傅的隐性知识显性化。一个智能体要同时满足这三个需求单靠一个大模型生成是不够的必须结合检索。这里插一句我的判断纯生成式AI在维修场景下有个致命问题——它会“编”。你问它“博世某型号冰箱E01故障码什么意思”它可能给你编一个听起来很合理的解释但实际上是错的。维修这行错一个判断可能就是几百块的配件和几个小时的人工。所以检索必须作为生成的锚点让AI基于真实历史案例来说话而不是凭空发挥。2.2 双引擎架构检索增强生成的实际落地最终确定的架构是检索增强生成业内叫RAG。这个架构不新鲜但用在维修工单场景有几个关键设计点。整个流程是这样的师傅在手机端输入一段自然语言描述比如“客户说冰箱冷冻室结冰很厚冷藏室不冷压缩机一直响”。系统先把这段描述做意图识别和实体抽取提取出品牌、品类、故障现象、关键部件等结构化信息。然后拿这些信息去案例库做混合检索——既做关键词匹配也做语义向量匹配。检索出Top 5相似案例后把这些案例作为上下文连同师傅的原始描述一起喂给大模型让大模型生成一份规范的工单草稿并附上“参考案例”和“建议排查方向”。这里有个细节值得展开为什么用混合检索而不是纯向量检索。我实测过纯向量检索在维修场景下有个坑——它太“语义”了。比如“不制冷”和“制冷效果差”向量距离很近但实际维修中前者可能是完全不制冷后者可能是制冷慢排查方向完全不同。而关键词检索能精确匹配“不制冷”这个短语。所以混合检索是必须的关键词保精度向量保召回。2.3 技术选型为什么没选纯平台方案现在市面上智能体平台很多扣子、Dify这些我都试过。平台方案的好处是快拖拖拽拽就能搭一个Demo。但真要用在博世维修这种场景平台方案有几个绕不过去的问题。第一是数据安全。维修案例库里有客户地址、电话、机器序列号这些数据不可能传到第三方平台。第二是检索可控性。平台自带的检索功能你没法精细调整关键词权重、没法自定义分词词典。维修这行有大量专业术语和型号编码通用分词器根本切不对。第三是成本。平台按调用次数收费我们日均工单量几千条长期算下来比自己部署贵得多。所以最终选了自建方案Python FastAPI做后端向量库用Milvus关键词检索用Elasticsearch大模型用本地部署的开源模型加一个云端API做兜底。这个组合听起来复杂但每个组件都有明确的理由。Milvus处理千万级向量检索性能稳定Elasticsearch的IK分词器可以自定义词典本地模型保证核心数据不出内网。3. 核心细节解析从工单文本到结构化知识的转化3.1 故障描述的结构化抽取让机器看懂“人话”师傅写的原始描述是典型的非结构化文本。要让机器能检索、能匹配第一步就是结构化抽取。我们定义了一个维修领域的实体框架包含以下几个维度。实体类型说明示例产品品类冰箱、洗衣机、洗碗机等冰箱产品型号博世具体型号编码KGN56AL40C故障现象客户感知到的异常冷冻室结冰、冷藏室不冷故障代码机器显示的Error CodeE01、F23涉及部件可能相关的零部件压缩机、蒸发器、温控板使用年限机器已使用时间3年环境信息安装位置、环境温度等厨房、靠近灶台抽取用的是微调后的小模型而不是直接调大模型API。原因很简单大模型抽取慢、贵而且对于“KGN56AL40C”这种型号编码大模型经常识别错。我们用一个7B参数的开源模型在标注了五千条工单数据上做了LoRA微调抽取准确率从基线的72%提升到了94%。这个投入是值得的因为抽取质量直接决定了后续检索的精度。实操心得标注数据的时候一定要让一线维修师傅参与而不是让标注公司随便找人标。我试过让外包标注他们把“压缩机不启动”和“压缩机不工作”标成了两个不同实体实际上这俩是一回事。后来我拉了三个老师傅花了两天时间统一了标注规范后面模型效果才起来。3.2 案例库的构建与清洗垃圾进垃圾出检索系统的效果七分靠数据三分靠算法。案例库的质量直接决定了智能体是“老师傅”还是“糊涂蛋”。我们最初的案例库是从旧工单系统直接导出的大概有八十万条。但导出来一看能用的大概只有六成。问题包括重复工单、测试工单、信息残缺工单、甚至还有师傅随手写的“测试123”。清洗规则我列一下你可以直接参考。去重同一机器序列号、同一故障现象、时间间隔在24小时内的工单只保留信息最完整的一条。过滤故障描述少于10个字的、包含“测试”“作废”“误报”等关键词的直接剔除。补全对于有故障代码但无描述的通过故障代码表反查补全标准描述。脱敏客户姓名、电话、地址全部替换为占位符保留地域信息用于分析区域故障特征。标准化把“不制冷”“不冷”“制冷不行”统一映射到标准术语“制冷效果差”。清洗完之后剩下大概四十八万条高质量案例。这个量级对于向量检索来说不算大Milvus单机就能扛住。但关键词检索那边Elasticsearch的索引需要优化我们把型号、故障代码、部件名称设为keyword字段故障描述设为text字段并配置了自定义IK词典。3.3 提示词工程让大模型说“维修话”大模型生成工单草稿提示词的设计是核心。我见过太多人写提示词就是“你是一个维修助手请帮我写工单”这种提示词出来的结果要么太啰嗦要么太笼统。我们的提示词模板经过十几版迭代最终定型为角色定义任务说明格式约束参考案例输出示例五段式。具体内容我脱敏后贴出来。SYSTEM_PROMPT 你是一名博世家电维修领域的资深技术支持工程师拥有十五年一线维修经验。 你的任务是根据维修师傅的原始描述和检索到的相似历史案例生成一份规范的故障工单草稿。 要求 1. 工单必须包含故障现象、故障代码如有、初步判断、建议排查步骤、可能涉及配件。 2. 语言简洁专业使用维修行业标准术语避免口语化表达。 3. 如果原始描述信息不足在工单末尾标注“需补充信息xxx”。 4. 参考案例仅作为判断依据不要直接复制案例中的客户信息。 5. 输出格式为JSON字段包括fault_phenomenon, fault_code, diagnosis, steps, parts。 这个提示词的关键在于格式约束和参考案例的定位。格式约束让输出可以直接被工单系统解析不需要二次处理。参考案例的定位说明是为了防止大模型把案例里的具体信息比如“王女士家”直接抄进新工单。注意提示词里的“十五年一线维修经验”不是随便写的。我对比过写“资深工程师”和写“十五年一线维修经验”后者生成的工单在细节丰富度上明显更好。大模型对具体数字有更强的角色代入感这算是个小技巧。4. 实操过程从零搭建一个可用的维修智能体4.1 环境准备与依赖安装整个系统跑在Ubuntu 22.04上Python版本3.10。为什么不用3.11或3.12因为Milvus的Python SDK对3.11的支持当时还不稳定踩过坑之后退回了3.10。依赖管理用Poetry比piprequirements.txt清爽得多。核心依赖清单如下。# 后端框架 fastapi0.104.1 uvicorn0.24.0 # 向量检索 pymilvus2.3.4 # 关键词检索 elasticsearch8.11.0 # 大模型推理 transformers4.36.0 torch2.1.0 peft0.7.0 # 文本处理 jieba0.42.1 sentence-transformers2.2.2安装过程中最容易出问题的是torch和CUDA的版本匹配。我们用的是A100显卡CUDA 11.8对应的torch版本必须是2.1.0cu118。如果你用CPU推理速度会慢到无法接受——实测一条工单生成要8秒GPU上只要0.6秒。4.2 向量化模型的选择与微调把故障描述转成向量用的是sentence-transformers的paraphrase-multilingual-MiniLM-L12-v2。选这个模型的原因有三支持中文、体积小只有118M、推理速度快。但直接用预训练模型有个问题——它不懂维修术语。比如“压缩机启动器”和“PTC启动器”在通用语义空间里距离较远但在维修场景下它们是强相关的。所以我们做了领域微调。构造了大概两万对正样本相似故障描述和四万对负样本不相似故障描述用对比学习的方式微调了三个epoch。微调之后在自建的测试集上Top 5召回率从68%提升到了89%。这个提升非常关键因为检索不准后面生成得再好也是白搭。微调的代码不复杂核心就是构造InputExample然后跑MultipleNegativesRankingLoss。但数据构造很费功夫我们花了大概三周时间让维修师傅一对一对地标注“这两条描述是不是同一个故障”。4.3 混合检索的权重调优关键词检索和向量检索的结果怎么融合直接影响到最终效果。我们试过三种方案。融合方案原理实测效果串行先关键词检索再向量检索召回率低关键词没匹配上就全挂了并行加权两路各取Top 20加权合并效果最好但权重要调并行RRF用倒数排名融合效果稳定不需要调权重最终选了并行RRF。RRF的好处是不需要手动调权重它对两路检索的排名做倒数融合排名越靠前的文档得分越高。公式很简单score Σ 1/(k rank)k一般取60。这个方案在测试集上的Top 5准确率是91%比加权方案高了3个百分点而且省去了调参的麻烦。实操心得RRF的k值不要随便改。我试过k10和k100效果都不如k60。这个值是经过大量实验验证的直接抄作业就行。4.4 工单生成与后处理检索出Top 5案例后连同师傅的原始描述一起喂给大模型。大模型用的是Qwen-7B-Chat的量化版本4-bit量化后显存占用大概6G一张A100可以同时跑多个实例。生成出来的JSON还需要做后处理校验。校验规则包括故障代码是否在已知代码表中、建议配件是否在博世配件库中存在、排查步骤是否包含安全提示比如“断电后再操作”。如果校验不通过系统会降级到模板生成保证师傅至少能拿到一份可用的工单。整个流程从师傅提交描述到返回工单草稿端到端延迟在1.2秒左右。这个速度师傅是可以接受的不会觉得“等半天”。5. 常见问题与排查技巧实录5.1 检索结果不相关从数据到算法的排查路径这是最常见的问题。师傅输入“冰箱不制冷”检索出来的案例却是“洗衣机不脱水”。排查思路按以下顺序来。第一步检查实体抽取结果。如果抽取出来的产品品类是“洗衣机”那说明抽取模型出问题了。这时候要看原始描述里有没有“冰箱”这个词如果有但没抽出来说明模型需要补充训练数据。第二步检查向量化结果。把输入文本和检索结果的向量拿出来算一下余弦相似度。如果相似度低于0.6说明向量模型没学好。这时候要考虑是不是微调数据不够或者输入文本太短导致向量表征能力不足。第三步检查ES分词。把输入文本用IK分词器切一下看看切出来的词是不是合理。我遇到过“不制冷”被切成“不”和“制冷”导致关键词匹配失效。解决办法是在自定义词典里加上“不制冷”这个短语。第四步检查RRF融合权重。如果两路检索各自的结果都还行但融合后变差了那可能是RRF的k值需要调整。不过这种情况比较少见。5.2 大模型“胡说八道”幻觉的抑制与兜底大模型生成工单时偶尔会编造不存在的故障代码或配件名称。这个问题在维修场景下是零容忍的因为师傅可能真的会照着去订配件。我们的抑制策略分三层。第一层是提示词约束明确要求“只使用参考案例中出现的故障代码和配件名称”。第二层是后处理校验生成结果中的故障代码和配件名称必须通过白名单校验不在白名单里的直接剔除。第三层是置信度阈值如果大模型对某个判断的置信度低于阈值就在工单上标注“建议人工确认”而不是直接给出结论。实测下来三层策略叠加后幻觉率从最初的12%降到了0.8%。剩下的0.8%主要是型号编码的细微错误比如把“KGN56AL40C”写成“KGN56AL40”这种通过正则校验也能拦住。5.3 师傅不愿意用推广中的真实阻力技术问题好解决人的问题最难。系统上线第一个月使用率只有23%。我找师傅聊了聊发现几个真实阻力。一是觉得麻烦。师傅说“我本来写十个字就完事了现在还要等AI生成再改一遍更费时间”。这个反馈让我意识到AI生成的工单必须比师傅自己写的更快否则就没有价值。后来我们优化了交互师傅只需要语音输入一段话系统自动转文字并生成工单师傅确认或微调即可。这样操作步骤从“打字-提交-等待-修改”变成了“说话-确认”时间反而省了。二是不信任。老师傅觉得“AI懂什么维修”。这个只能靠实际效果说话。我们挑了几个典型故障让AI生成工单然后让老师傅盲评。结果老师傅对其中80%的工单表示“写得比我徒弟好”。这个结果在内部群里一发使用率第二个月就涨到了67%。三是担心被替代。有些师傅觉得“教会AI饿死师傅”。这个心态很真实。我们在推广时反复强调AI是辅助工具不是替代方案。工单上最终署名的还是师傅本人AI只是帮他写得更快更好。而且AI检索出来的旧案例反而让老师傅的经验被更多人看到提升了他们在团队里的影响力。5.4 常见问题速查表问题现象可能原因排查方法解决方案检索结果完全不相关实体抽取错误检查抽取出的品类、型号补充训练数据修正抽取模型相似故障检索不到向量模型领域适配不足计算输入与案例的余弦相似度增加领域微调数据关键词匹配失效分词器切分错误用IK分词器测试切分结果添加自定义词典生成工单包含幻觉提示词约束不足检查生成结果中的代码和配件加强后处理校验端到端延迟过高GPU资源不足或模型过大监控推理耗时量化模型或增加GPU师傅使用率低交互流程繁琐收集师傅反馈优化交互支持语音输入6. 效果评估与持续迭代6.1 量化指标工单质量提升了多少系统上线三个月后我们做了一次全面的效果评估。评估维度包括工单完整率、配件准确率、首次修复率、师傅满意度。指标上线前上线后变化工单完整率54%89%35%配件准确率71%92%21%首次修复率68%81%13%师傅满意度-4.2/5-工单完整率的提升最明显因为AI会强制补全必填字段。配件准确率的提升直接带来了成本节约——配件发错一次来回运费加人工大概200块按日均3000单算每天少发错200单一年省下的钱相当可观。6.2 持续迭代案例库的自动更新机制系统上线不是终点案例库需要持续更新。我们设计了一个自动入库流程每天凌晨系统把前一天已完成的工单做清洗和结构化然后增量写入案例库。同时对于检索命中率高但生成质量低的案例会打上“待优化”标签由人工复核后决定是否保留。这个机制的关键是质量闭环。师傅对AI生成工单的修改本身就是一种反馈信号。如果师傅大幅修改了AI的建议说明AI判断不准这条工单就会被标记为负样本用于后续模型迭代。6.3 后续扩展方向这个智能体的框架是通用的换一个品牌、换一个品类只要替换案例库和微调数据就能快速复用。我们已经在规划几个扩展方向。一是多模态输入。师傅可以直接拍一张故障代码的照片系统通过OCR识别代码自动填充工单。这个功能在测试中识别准确率已经达到96%。二是语音交互优化。现在师傅需要说普通话但很多老师傅习惯说方言。我们正在收集方言语音数据训练一个方言识别模型让师傅用家乡话也能写工单。三是预测性维护。基于历史工单数据分析哪些型号、哪些批次的机器容易出特定故障提前向客户推送保养提醒。这个方向的数据基础已经具备就差业务侧的配合了。最后分享一个小技巧如果你也在做类似的维修智能体建议先从单一品类切入比如只做冰箱。把冰箱的案例库做深做透跑通整个流程再扩展到其他品类。我见过太多项目一上来就全品类覆盖结果每个品类都做得半吊子师傅用两次就放弃了。聚焦是落地成功的关键。
阅读完成 · 觉得有帮助？
的排查与解决方法)
