1. 从一张维修工单说起这个智能体到底在解决什么问题干过家电售后的人都知道维修工单这东西看着简单写起来要命。一台博世冰箱报修用户描述是“冷藏室不冷冷冻室正常显示屏没报错”你上门一看可能是风门故障、可能是蒸发器结冰、也可能是传感器漂移。修完之后要写工单故障现象、诊断过程、更换配件、处理结果、用户反馈一套下来十几分钟。一天跑八单光写工单就干掉两个小时。更麻烦的是旧案例检索。博世的产品线拉得很长冰箱、洗衣机、洗碗机、烤箱每个品类下面又有几十个型号系列。一个新来的维修师傅遇到一台不常见的机器想查以前有没有人修过类似故障得在系统里翻半天关键词稍微不对就搜不出来。老师傅脑子里有经验但经验没法复制给新人。这套“博世维修AI智能体”就是冲着这两个痛点去的故障工单自动编写和旧案例智能检索。简单说维修师傅在现场用手机说几句话或者拍几张照片智能体帮你把工单草稿生成出来遇到拿不准的故障用自然语言描述一下它从历史维修记录里把最相关的案例捞出来给你参考。适合谁看如果你是做售后系统开发的技术人员这里面有智能体架构设计和LLM落地的具体思路如果你是维修团队的管理者能看清楚这套东西怎么跟现有工单系统对接如果你只是对AI智能体在垂直行业的应用感兴趣这是一个非常典型的“窄场景深挖”案例比那些泛泛而谈的通用助手有参考价值得多。我接下来会从整体设计、核心模块拆解、实操落地、踩坑排查几个维度把这套东西讲透。不是概念科普是能直接拿去跟团队讨论方案的那种内容。2. 整体架构设计为什么不做成一个“万能助手”2.1 两个场景两条技术路线很多人一上来就想做一个“博世维修万事通”什么都能问、什么都能答。我试过效果很差。原因很简单工单编写和案例检索对模型能力的要求完全不同。工单编写是生成任务输入是结构化的现场信息故障描述、检测数据、更换配件输出是格式规范的工单文本。它要求模型严格遵循模板不能自由发挥字段该填的必须填不该编的绝对不能编。这里用的是指令微调后的生成模型配合严格的输出Schema约束。案例检索是语义匹配任务输入是一段自然语言描述的故障现象输出是历史案例列表。它不要求生成新内容而是要求理解语义、找到最相关的记录。这里用的是向量检索重排序的方案Embedding模型负责召回Cross-Encoder负责精排。把这两个场景塞进一个模型里结果就是两边都做不好。生成模型被检索任务带偏开始“编造”不存在的案例检索模型被生成任务干扰输出的相关性下降。所以架构上第一刀就是场景分离各走各的链路只在最上层用一个路由模块做分发。2.2 智能体的“手脚”和“大脑”怎么分工这套系统里LLM是大脑负责理解和生成工具调用是手脚负责查数据库、调API、写文件。具体分工是这样的意图识别模块判断用户当前是要“写工单”还是“查案例”还是两者都要比如先查案例再写工单。这个用一个小型的分类模型就够了不需要上大模型响应快、成本低。工单生成链路接收现场信息调用LLM生成工单草稿然后通过字段校验器检查必填项是否完整、格式是否合规。校验不通过就回退给LLM重新生成最多重试三次。案例检索链路把用户描述转成向量在案例库中做近似最近邻搜索召回Top-50再用重排序模型精排出Top-5最后用LLM对结果做摘要和适配性说明。反馈闭环维修师傅对生成结果的修改比如改了故障分类、补充了配件信息会被记录下来定期用于模型的微调和检索策略的优化。这个架构的核心思想是LLM不做它不擅长的事。精确的数据库查询交给检索系统格式校验交给规则引擎LLM只负责它最擅长的语义理解和文本生成。2.3 为什么选择“智能体”而不是“工作流”有人会问这不就是一个工作流吗为什么要叫智能体区别在于自主决策能力。工作流是固定的A步骤完了走BB完了走C。智能体可以根据中间结果动态调整路径。举个例子用户说“这台冰箱冷藏不冷我查了一下好像是风门问题帮我写个工单顺便看看以前有没有类似的”。工作流会傻傻地先写工单再查案例或者反过来。智能体会先判断用户提到了“风门问题”这是一个关键诊断信息应该先检索案例确认这个判断是否合理如果检索到高度相似的案例且处理方式一致再把这个信息带入工单生成工单里的“故障原因”字段就能写得更准确。这种动态编排的能力是智能体和工作流的核心差异。实现上靠的是一个轻量的规划模块用LLM做Few-shot推理决定下一步调哪个工具、传什么参数。3. 故障工单编写从“口述”到“规范文本”的完整链路3.1 现场信息采集让维修师傅少打字维修师傅在现场最烦的就是打字。手上可能有油污屏幕又小输入效率极低。所以信息采集层做了三种输入方式语音输入是最主要的入口。师傅对着手机说“博世冰箱KGN56用户报冷藏室温度偏高实测冷藏室12度冷冻室零下18度正常检查风门电机不动作更换风门总成试机两小时温度降到4度。”语音转文字之后LLM从这段非结构化文本里抽取结构化字段。拍照识别是辅助手段。拍铭牌自动识别型号拍故障代码自动识别错误码拍配件包装自动识别配件编号。这里用的是OCR正则匹配不需要上多模态大模型成本低且准确率足够。表单补填是兜底方案。语音和拍照都没覆盖到的字段用下拉菜单和快捷选项让师傅点选。比如“故障分类”这种枚举值点选比语音输入更可靠。实操心得语音输入的环境噪音是最大的敌人。冰箱运行时的压缩机噪音、厨房的抽油烟机噪音都会影响识别率。我们的做法是在App端做降噪预处理同时训练了一个小的关键词唤醒模型只有检测到“博世”“报修”“故障”等触发词才开始录音减少无效音频的传输和处理。3.2 字段抽取与结构化LLM怎么“听懂”师傅的话语音转文字的结果是一段口语化的描述LLM需要从中抽取出工单所需的各个字段。我们定义的工单Schema包含以下核心字段字段名类型是否必填说明产品品类枚举是冰箱/洗衣机/洗碗机/烤箱等产品型号字符串是从语音或铭牌识别故障现象文本是用户描述的现象检测数据结构化否温度、电压、电阻等实测值故障原因文本是诊断结论处理措施文本是更换配件/调整参数/软件升级更换配件列表否配件编号和名称处理结果文本是修复后状态服务时间日期时间是自动填充抽取的实现方式是Few-shot Prompting JSON Schema约束。给LLM几个示例每个示例展示一段口语描述和对应的JSON输出然后在Prompt里明确要求输出必须符合给定的JSON Schema。实测下来GPT-4级别的模型在Few-shot条件下字段抽取准确率能到92%以上漏抽的主要是“检测数据”里的数值单位比如“12度”可能被抽成“12”。解决单位问题的办法是在后处理层加一个单位归一化模块用规则匹配把“度”“摄氏度”“℃”统一成“℃”把“伏”“V”“电压”统一成“V”。规则能搞定的事不要麻烦模型。3.3 工单文本生成模板LLM的混合策略字段抽取完之后生成完整工单文本。这里有个关键决策是让LLM直接生成整篇工单还是用模板填充纯LLM生成的问题是不可控。同样的字段每次生成的措辞可能不一样有时候还会“脑补”一些不存在的信息。纯模板填充的问题是太死板遇到模板没覆盖的情况就抓瞎。我们的方案是混合策略固定部分用模板灵活部分用LLM。固定部分包括工单头部服务单号、日期、客户信息、字段标题“故障现象”“处理措施”、尾部服务工程师签名、客户确认。这些内容格式固定模板填充最快最稳。灵活部分是每个字段的具体内容。比如“故障现象”字段模板只提供占位符具体文字由LLM根据抽取的字段生成。Prompt里会要求“用简洁的维修行业术语描述故障现象不超过50字不要包含诊断结论。”这样既保证了格式统一又让内容有足够的灵活性。实测下来维修师傅对生成工单的直接采纳率不做任何修改直接提交在65%左右轻微修改后采纳率在90%以上。剩下的10%主要是师傅觉得“措辞不够专业”或者“想补充一些细节”。3.4 质量校验三道防线拦住错误工单工单是要存档的出了问题要追溯所以准确性至关重要。我们设了三道校验第一道Schema校验。检查必填字段是否为空枚举值是否在允许范围内日期格式是否正确。这是纯规则校验毫秒级完成。第二道一致性校验。检查字段之间的逻辑是否自洽。比如“故障原因”写了“风门电机故障”但“更换配件”列表是空的这就矛盾了。再比如“处理结果”写了“温度恢复正常”但“检测数据”里没有修复后的温度记录也可疑。这一层用规则小模型结合的方式做。第三道LLM自检。把生成的工单和原始输入一起给LLM让它判断“工单内容是否忠实于原始描述有无编造信息”。Prompt里会强调“如果工单中的某个信息在原始描述中找不到依据标记为‘存疑’。”这一层能抓住一些隐蔽的幻觉问题。三道校验都通过工单才进入待提交状态。任何一道不通过都会触发重新生成或人工干预。注意事项LLM自检本身也可能出错所以这一层的输出只作为提示不作为阻断。也就是说自检发现“存疑”的内容会高亮显示给维修师傅由师傅最终决定是否修改。不要让AI替人做最终决策尤其是在涉及责任认定的场景里。4. 旧案例检索让老师傅的经验变成可搜索的资产4.1 案例库的构建从历史工单到结构化知识博世售后系统里积累了大量历史工单但这些工单是给内部管理用的格式不统一、信息密度低、很多关键细节缺失。直接拿来做检索效果很差。我们做了一次案例库重构把历史工单转化成结构化的案例条目。每个案例包含案例标题自动生成格式为“产品品类型号系列故障现象摘要”比如“冰箱KGN56系列-冷藏室温度偏高-风门电机故障”。故障现象描述从原工单的“故障现象”字段提取做标准化处理统一术语、补充缺失信息。诊断过程从“检测数据”和“故障原因”字段整合形成“检测了什么→发现了什么→判断为什么”的逻辑链。处理方案从“处理措施”和“更换配件”字段整合。结果验证从“处理结果”字段提取标注是否修复成功。元数据服务日期、服务工程师、地区、产品批次等。这个重构过程用了LLM做辅助抽取和标准化但最终每条案例都经过人工抽检。抽检比例是10%发现问题的案例会回溯修正抽取规则。4.2 向量化与索引让语义搜索真正“懂”故障案例库建好之后下一步是做向量化。这里的关键决策是用什么文本做Embedding。试过几种方案只用故障现象描述召回率不错但精确率低。因为很多故障现象描述很相似比如“不制冷”但背后的原因完全不同。用故障现象故障原因精确率提升但召回率下降。因为用户描述故障时往往不知道原因用原因去匹配会漏掉相关案例。用故障现象诊断过程处理方案综合效果最好。诊断过程里包含了检测数据和推理逻辑处理方案里包含了配件信息这些都能帮助区分不同案例。最终采用的方案是多字段拼接加权。故障现象权重最高0.5诊断过程次之0.3处理方案再次之0.2。Embedding模型用的是针对中文维修领域微调过的版本在通用语义理解的基础上加强了对维修术语的敏感度。索引结构用的是HNSWHierarchical Navigable Small World在召回速度和准确率之间取得了很好的平衡。案例库规模在十万级单次检索的响应时间控制在200ms以内。4.3 检索流程召回→精排→摘要三步走用户输入一段故障描述比如“洗碗机洗完程序结束后底部有积水排水泵声音正常但水排不出去”。检索流程分三步第一步向量召回。把用户描述转成向量在HNSW索引中搜索Top-50最相似的案例。这一步追求高召回宁可多召回一些不相关的也不能漏掉相关的。第二步Cross-Encoder精排。把用户描述和召回的50个案例逐一配对用Cross-Encoder模型打分。Cross-Encoder会同时看两段文本判断它们的相关性比单纯的向量相似度准确得多。精排后取Top-5。第三步LLM摘要与适配。把Top-5案例的完整信息给LLM让它生成一段摘要说明每个案例与当前故障的相似点和不同点并给出“建议参考优先级”。比如“案例3与当前故障最相似同样是排水泵正常但排水不畅处理方案是检查排水管是否弯折。案例1虽然也是积水问题但原因是排水泵故障与当前情况不符。”这一步的价值在于降低维修师傅的阅读负担。不用自己一条条看案例LLM已经帮你做了对比分析。4.4 检索效果评估怎么知道搜得准不准检索系统的评估不能只看“感觉”要有量化指标。我们用了三个核心指标Recall5前5个结果中包含正确案例的比例。目标值≥85%。MRRMean Reciprocal Rank正确案例在结果列表中的平均排名倒数。目标值≥0.7。人工满意度维修师傅对检索结果的评分1-5分。目标值≥4.0。评估数据来自两个渠道一是历史工单的回溯测试拿已知答案的工单做查询看系统能不能找回原始案例二是线上A/B测试随机分流一部分查询请求到新系统对比新旧系统的满意度评分。实测下来Recall5在87%左右MRR在0.73人工满意度4.2分。主要失分场景是罕见故障和跨品类故障比如用户描述像冰箱问题实际是洗碗机问题这两类场景的召回率明显偏低。实操心得罕见故障的检索效果差根本原因是案例库里就没有类似案例。这时候与其硬搜不如让LLM基于通用维修知识给出推测性建议并明确标注“此建议基于通用知识非历史案例”。维修师傅看到这个标注就知道参考价值有限不会盲目照搬。5. 实操落地从零搭建这套系统的关键步骤5.1 环境准备与工具选型如果你要复现这套系统以下是核心工具链组件选型理由LLMGPT-4 / Claude 3.5 Sonnet字段抽取和文本生成需要强语义理解Embedding模型BGE-M3 / text-embedding-3-large中文语义匹配效果好支持长文本向量数据库Milvus / Qdrant支持HNSW索引十万级数据性能稳定重排序模型BGE-Reranker-v2中文Cross-Encoder精排效果好后端框架FastAPI轻量、异步支持好、部署简单语音识别Whisper / 讯飞中文识别准确率高支持降噪这套组合的总成本按日均1000次查询估算大约在每月300-500美元主要是LLM API调用费用。如果预算有限可以把LLM换成开源模型如Qwen2.5-72B部署在自己的服务器上成本能降到每月100美元以内但效果会有一定下降。5.2 工单生成模块的代码实现要点核心逻辑用Python实现关键代码如下import json from openai import OpenAI client OpenAI() WORK_ORDER_SCHEMA { type: object, properties: { product_category: {type: string, enum: [冰箱, 洗衣机, 洗碗机, 烤箱]}, product_model: {type: string}, fault_phenomenon: {type: string, maxLength: 100}, diagnosis: {type: string}, solution: {type: string}, parts_replaced: {type: array, items: {type: string}}, result: {type: string} }, required: [product_category, product_model, fault_phenomenon, diagnosis, solution, result] } def extract_fields(voice_text: str) - dict: prompt f从以下维修现场描述中抽取工单字段输出JSON格式。 描述{voice_text} 要求 1. 严格按照给定的JSON Schema输出 2. 如果某个字段在描述中没有提及不要编造留空或标注未提及 3. 故障现象用简洁的维修术语不超过50字 response client.chat.completions.create( modelgpt-4, messages[{role: user, content: prompt}], response_format{type: json_object} ) return json.loads(response.choices[0].message.content) def validate_work_order(fields: dict) - list: errors [] for field in WORK_ORDER_SCHEMA[required]: if not fields.get(field): errors.append(f必填字段缺失{field}) if fields.get(diagnosis) and not fields.get(solution): errors.append(有诊断结论但无处理措施) return errors这段代码的关键点在于response_format{type: json_object}强制LLM输出合法的JSON。没有这个约束LLM可能会在JSON外面包一层解释文字导致解析失败。5.3 案例检索模块的索引构建索引构建是一次性任务但需要定期更新新工单入库后要重新索引。核心代码如下from pymilvus import Collection, FieldSchema, CollectionSchema, DataType from sentence_transformers import SentenceTransformer # 定义Collection Schema fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1024), FieldSchema(namecase_text, dtypeDataType.VARCHAR, max_length2000), FieldSchema(namemetadata, dtypeDataType.JSON) ] schema CollectionSchema(fields) collection Collection(namerepair_cases, schemaschema) # 构建索引 index_params { metric_type: COSINE, index_type: HNSW, params: {M: 16, efConstruction: 200} } collection.create_index(field_nameembedding, index_paramsindex_params) # 向量化并插入 model SentenceTransformer(BAAI/bge-m3) def index_case(case: dict): text f{case[fault_phenomenon]} {case[diagnosis]} {case[solution]} embedding model.encode(text).tolist() collection.insert([[case[id]], [embedding], [text], [case[metadata]]])HNSW的参数M16和efConstruction200是经过调优的。M控制每个节点的邻居数越大索引越精确但内存占用越高efConstruction控制构建时的搜索深度越大构建越慢但索引质量越好。对于十万级数据这组参数在召回率和构建时间之间取得了不错的平衡。5.4 与现有工单系统的对接这套智能体不是独立运行的它要嵌入到博世现有的售后管理系统中。对接方式有两种API对接是最干净的方式。智能体暴露RESTful API工单系统在需要生成工单或检索案例时调用。优点是解耦彻底智能体可以独立部署和升级缺点是需要工单系统改造增加调用逻辑。数据库对接是侵入性更强的方式。智能体直接读写工单系统的数据库在工单表里增加“AI生成草稿”字段。优点是工单系统几乎不用改缺点是耦合太紧智能体的任何改动都可能影响工单系统。我们最终选择了API对接消息队列的方案。智能体通过API接收请求处理完成后把结果写入消息队列工单系统从队列里消费结果。这样既解耦又能处理异步场景比如语音识别需要几秒钟不能让工单系统一直等着。6. 常见问题与排查技巧实录6.1 工单生成中的典型问题问题一LLM编造不存在的配件编号这是最危险的问题。维修师傅说“更换了风门”LLM在“更换配件”字段里填了一个看起来很像但实际不存在的配件编号。排查思路检查Prompt里是否明确要求“配件编号必须从原始描述中提取不得自行生成”。如果没有这个约束LLM会倾向于“补全”信息。解决方法在Prompt里加一条硬约束同时在Schema校验层加一个配件编号白名单校验只有存在于配件库中的编号才允许通过。问题二故障现象描述过于笼统LLM生成的故障现象是“冰箱不制冷”但原始描述里其实有更具体的信息“冷藏室温度12度冷冻室正常”。排查思路检查Few-shot示例里是否有“笼统描述”的反面案例。如果没有LLM会倾向于生成更“安全”的通用描述。解决方法在Few-shot里加入对比示例展示“笼统描述”和“具体描述”的区别并在Prompt里强调“尽量保留原始描述中的具体数值和细节”。问题三多语言混杂博世是德国品牌有些工单里会混入德语术语比如“Kältekreis”表示制冷循环。LLM有时候会把德语术语直接输出到中文工单里。排查思路检查训练数据里是否有德语样本。如果有需要在预处理层做术语归一化把常见德语术语映射到中文。解决方法维护一个领域术语映射表在LLM生成之前先把输入中的德语术语替换成中文生成之后再检查输出中是否残留德语。6.2 案例检索中的典型问题问题一检索结果“看起来相关但实际不相关”用户搜“冰箱不制冷”返回的案例都是“不制冷”但原因各不相同有的是压缩机故障有的是制冷剂泄漏有的是温控器问题。用户需要自己一条条看效率很低。排查思路检查Embedding是否只用了“故障现象”字段。如果只用故障现象确实会出现这个问题。解决方法在Embedding文本里加入“故障原因”和“处理方案”让向量包含更多区分性信息。同时在精排阶段用Cross-Encoder重点对比“故障原因”字段的相似度。问题二新品类案例检索效果差博世新出了一款蒸烤一体机历史案例库里几乎没有相关记录。用户搜蒸烤一体机的故障返回的都是烤箱或蒸箱的案例参考价值有限。排查思路这是冷启动问题不是检索算法的问题。案例库里没有就是没有再好的算法也搜不出来。解决方法在检索结果里明确标注“此案例来自烤箱品类与蒸烤一体机可能存在差异”。同时对于新品类启用通用知识兜底策略让LLM基于通用维修知识给出建议并标注“非历史案例”。问题三检索响应时间波动大大部分查询在200ms内返回但偶尔会有查询耗时超过2秒。排查思路检查HNSW索引的efSearch参数。efSearch控制搜索时的候选集大小越大越精确但越慢。如果efSearch设置过高在数据量增长后会导致响应时间飙升。解决方法把efSearch从默认的64降到32同时监控Recall5的变化。实测Recall5只下降了1.5个百分点但P99响应时间从2.1秒降到了800ms。6.3 系统集成中的坑坑一语音识别的方言问题维修师傅来自全国各地普通话不一定标准。语音识别对方言的准确率明显下降导致字段抽取错误。应对策略在App端做方言适配让师傅选择自己的方言类型后端调用对应的方言识别模型。同时对于识别置信度低的片段高亮显示让师傅手动修正。坑二工单系统的字段长度限制现有工单系统的“故障现象”字段限制200个字符但LLM生成的描述有时候会超过。直接截断会导致信息丢失。应对策略在生成阶段就限制输出长度Prompt里明确“不超过150字”。同时在API层做长度校验超长的内容触发重新生成。坑三并发请求下的LLM限流售后高峰期比如夏季空调维修旺季同时有几十个维修师傅在生成工单LLM API触发限流请求失败。应对策略在智能体层加请求队列超出并发限制的请求排队等待。同时设置降级策略当LLM不可用时回退到纯模板填充模式保证基本功能可用。6.4 常见问题速查表问题现象可能原因排查方法解决方案工单字段缺失Prompt未强调必填检查Prompt和Few-shot加硬约束Schema校验配件编号编造LLM补全倾向检查原始描述是否有编号白名单校验Prompt约束检索结果不相关Embedding字段单一检查索引文本构成多字段拼接精排新品类搜不到案例库冷启动检查案例库覆盖通用知识兜底标注响应时间波动efSearch过高监控P99延迟降低efSearch监控召回方言识别差语音模型不匹配检查识别置信度方言适配人工修正并发限流API配额不足监控请求失败率队列降级策略7. 这套系统后续还能怎么扩展工单编写和案例检索只是起点。这套智能体的架构是开放的后续可以往几个方向扩展。预测性维护是一个方向。把历史工单数据和产品运行数据结合起来训练一个故障预测模型。在用户报修之前就预测到某个部件可能出问题提前安排预防性维护。这需要把智能体从“被动响应”变成“主动预警”。配件库存优化是另一个方向。案例检索的数据可以反哺配件需求预测。某个地区某款产品的某个配件更换频率突然上升可能意味着这批产品有批次性问题也可能是库存不足需要补货。智能体可以自动生成预警报告。维修知识图谱是更长期的方向。把案例库里的实体产品、故障、配件、工具和关系导致、解决、替代抽出来构建一个知识图谱。检索的时候不仅匹配文本相似度还能沿着图谱关系做推理。比如“风门故障”导致“冷藏室不冷”而“风门故障”的解决方案是“更换风门总成”知识图谱能自动建立这些关联。我在实际落地这套系统的过程中最大的体会是垂直场景的AI应用价值不在于模型有多强而在于对业务的理解有多深。同样的LLM用在通用场景里只能做个玩具用在维修工单这种窄场景里配合好领域数据和业务规则就能产生实实在在的效率提升。维修师傅从“每天花两小时写工单”变成“每天花二十分钟确认AI生成的草稿”这就是价值。