拓冰网站定制 
1. 博世维修场景下故障工单为什么值得用AI智能体重做一遍在博世这类家电售后体系里干过的人都知道故障工单是整个维修流程的中枢神经。客户报修时说的那句冰箱不制冷了经过客服记录、派单、工程师上门、检测、填写维修记录、归档最后变成一张工单。这张工单写得好不好直接决定了后续三件事第一工程师能不能快速定位问题第二备件能不能一次带对第三这个案例以后能不能被检索出来复用。我接触过不少售后团队工单质量参差不齐是普遍现象。有的工程师写已维修正常有的写压缩机启动电容失效更换后制冷恢复运行电流0.8A符合铭牌标称。后者才是真正有价值的工单但要求每个工程师都这么写靠培训和考核很难长期维持。这就是我决定用AI智能体切入这个场景的起点——不是要替代工程师而是把写工单这件重复性高、格式要求严、又极度依赖经验的事交给一个能理解故障语义、能检索历史案例、能按规范输出的智能体来辅助完成。这个智能体要解决的核心问题有三个。故障工单编写工程师只需要输入零散的检测信息比如冷藏室温度12度压缩机不启动听不到继电器吸合声智能体就能生成结构完整、术语规范、包含初步判断的工单草稿。旧案例检索当工程师遇到一个不太确定的故障时智能体能从历史工单库里找出相似案例告诉他上次遇到类似现象最终是主控板继电器驱动电路虚焊。知识沉淀每一次新工单的生成和确认都会反哺案例库让检索越来越准。适合读这篇内容的人我大致分三类。一是做售后系统数字化的技术负责人想知道智能体到底能落地到什么程度二是售后团队的运营管理者关心工单质量和工程师效率能不能同时提升三是对AI智能体开发感兴趣、想找一个真实业务场景练手的开发者。我会把架构设计、提示词工程、检索策略、踩过的坑都摊开讲代码和配置能给的地方尽量给全。需要先说明一点博世官方并没有公开过这样一套系统的完整技术细节下面讲的是我基于家电售后行业的通用实践、以及智能体开发的常见工程方案做的合理还原和补充。如果你所在的团队要做类似的东西这套思路可以直接参考但具体参数和接口需要按你们自己的系统调整。2. 智能体的能力边界它到底该做哪几件事不该做哪几件事2.1 把工单编写拆成三个可独立验证的子任务很多人一上来就想做一个全能维修助手结果做出来的东西什么都沾一点什么都不精。我的做法是把工单编写拆成三个子任务每个子任务单独设计提示词、单独验证效果。第一个子任务是信息结构化。工程师的输入往往是一段口语化的描述比如客户说冰箱下面结冰上面不冷我看了下风扇在转但是风好像没上来蒸发器结霜很厚。智能体要做的第一件事是把这段话映射到标准字段故障现象、检测部位、检测结果、初步判断。这一步不涉及任何推理纯粹是信息抽取和归类用大模型做非常稳。第二个子任务是故障推理。基于结构化的检测信息智能体要给出可能的故障原因排序。这里的关键是推理必须基于案例库和维修手册不能凭空发挥。我的做法是在提示词里强制要求你的判断必须引用检索到的历史案例或手册条目如果检索结果不足以支撑判断明确说需要进一步检测不要猜测。第三个子任务是工单文本生成。把前两步的结果按照博世售后工单的字段规范生成一段可以直接粘贴进系统的文本。这里要控制的是格式和术语比如压缩机不能写成马达主控板不能写成电脑板这些术语一致性靠提示词里的术语表来约束。提示三个子任务分开做最大的好处是出了问题能定位。如果工单写得不好你能判断是信息抽取错了、推理错了、还是格式生成错了。如果揉成一个提示词调试起来就是一团乱麻。2.2 旧案例检索不是关键词搜索是语义匹配加结构化过滤一开始我图省事直接用关键词匹配做案例检索。结果很糟糕工程师输入不制冷搜出来一堆制冷正常但噪音大的工单因为都含制冷两个字。后来改成向量语义检索效果好了一些但又出现新问题语义相似的案例可能机型完全不同维修方案根本不通用。最终的方案是混合检索先用结构化字段做硬过滤比如机型系列、故障大类、年份范围把候选集从几万条压到几百条再在这几百条里做向量语义匹配找出最相似的Top 5最后用一个轻量级的重排序模型结合故障现象的匹配度和维修结果的相似度给出最终排序。这个设计背后的逻辑是维修案例的相似性不只是文本相似还包括设备相似和故障机理相似。一个博世6系冰箱的制冷故障和一个4系冰箱的制冷故障文本可能很像但内部结构差异可能导致维修方案不同。所以结构化过滤必须放在语义匹配之前这是我在实际调试中踩坑之后才想明白的。2.3 明确智能体不碰的领域安全判断和最终决策有一条红线我定得很死智能体不输出任何涉及安全操作的最终判断。比如这个电容可以带电更换这种话智能体绝对不能说。它的输出里如果涉及电气安全、制冷剂操作、高压部件必须强制附加请遵循博世安全操作规范由持证工程师确认后执行。另一个不碰的是最终维修决策。智能体可以给出可能原因排序和建议检测步骤但最终换什么件、怎么修必须由工程师确认。这不是技术做不到而是责任边界问题。售后场景里一个错误的维修建议可能导致返修甚至安全事故这个责任智能体承担不了也不应该承担。3. 从零搭一个能用的智能体架构选型与核心模块实现3.1 为什么我选平台智能体自建检索服务的混合架构现在做智能体的路径大概有两条。一条是用Coze、Dify这类平台拖拽式搭建上手快但检索逻辑和数据处理受平台限制。另一条是纯Python自建用LangChain或类似框架灵活但工作量大。我的选择是混合对话编排和提示词管理放在平台上检索服务和数据处理用Python自建。原因很实际。平台智能体在对话管理、多轮上下文、插件调用这些方面做得很成熟没必要重复造轮子。但案例检索涉及向量库、结构化过滤、重排序这些平台要么不支持要么支持得很浅必须自己写。具体分工是这样的平台智能体负责接收工程师输入、调用检索插件、组织提示词、生成最终工单文本。Python服务负责案例库的向量化、索引维护、混合检索接口。两者通过HTTP接口通信平台智能体把工程师的查询发给检索服务拿到Top 5案例后再交给大模型做推理和生成。这个架构还有一个好处检索服务可以独立迭代。我调整检索策略、换嵌入模型、优化重排序都不需要动平台上的智能体配置。反过来智能体换平台或者换模型检索服务也不受影响。3.2 案例库的数据结构设计字段比模型更重要做检索的人容易犯一个错花大量时间调模型却忽略了数据结构。我的经验是案例库的字段设计决定了检索效果的上限模型只是逼近这个上限。下面是我实际用的案例表结构字段不多但每个都有明确用途字段名类型用途是否参与检索case_id字符串唯一标识否product_line枚举产品线如冰箱、洗衣机硬过滤model_series字符串机型系列硬过滤fault_category枚举故障大类如制冷、电气、噪音硬过滤symptom_text文本故障现象描述向量检索detection_text文本检测过程和结果向量检索root_cause文本根本原因展示用solution文本维修方案展示用parts_replaced列表更换的备件展示用engineer_id字符串工程师标识否created_at日期工单创建时间排序权重这里有几个设计细节值得说。fault_category用枚举而不是自由文本是为了硬过滤时能精确匹配如果让工程师自由填会出现制冷故障不制冷制冷问题三种写法过滤就失效了。symptom_text和detection_text分开存是因为检索时两者的权重不同——故障现象相似度比检测过程相似度更重要分开存才能分别计算相似度再加权。created_at参与排序权重是因为维修方案会随产品迭代变化。三年前的维修方案可能因为备件更新或设计变更已经不再适用。我的做法是给近期案例更高的排序权重但不是简单按时间排而是结合相似度做加权。3.3 混合检索的完整实现从查询到Top 5案例检索服务的核心逻辑我用一段伪代码来说明实际实现是Python加向量数据库def hybrid_retrieve(query, filters, top_k5): # 第一步结构化硬过滤 candidates db.filter( product_linefilters.product_line, model_seriesfilters.model_series, fault_categoryfilters.fault_category ) # 如果过滤后候选太少放宽机型系列限制 if len(candidates) 20: candidates db.filter( product_linefilters.product_line, fault_categoryfilters.fault_category ) # 第二步向量语义匹配 query_vector embed(query.symptom_text) scored [] for case in candidates: symptom_sim cosine(query_vector, case.symptom_vector) detection_sim cosine(query_vector, case.detection_vector) # 故障现象权重0.7检测过程权重0.3 combined 0.7 * symptom_sim 0.3 * detection_sim scored.append((case, combined)) # 第三步时间衰减加权 now current_date() weighted [] for case, score in scored: days_old (now - case.created_at).days # 一年内的案例不衰减超过一年按天衰减 time_factor 1.0 if days_old 365 else max(0.5, 1.0 - (days_old - 365) / 3650) weighted.append((case, score * time_factor)) # 第四步排序返回 weighted.sort(keylambda x: x[1], reverseTrue) return weighted[:top_k]这段代码里有几个参数是我反复调出来的。故障现象权重0.7、检测过程0.3是因为实际使用中工程师更关注现象像不像检测过程只是辅助。时间衰减的下限设0.5是为了避免老案例被完全压死——有些经典故障的维修方案多年不变完全排除掉反而损失了有价值的信息。注意硬过滤放宽策略要谨慎。我一开始设的阈值是候选少于50条就放宽结果经常把不同产品线的案例混进来。后来改成先按产品线过滤只在机型系列层面放宽效果好很多。3.4 提示词工程让大模型按维修逻辑思考而不是按语言逻辑智能体生成工单的质量八成取决于提示词。我见过很多提示词写的是请根据以下信息生成维修工单这种提示词出来的结果就是语言通顺但逻辑混乱。我的提示词结构是这样的分四段第一段定角色和边界你是一名博世家电售后技术支持助手。你的任务是辅助工程师编写故障工单和检索历史案例。你不做最终维修决策不输出安全操作判断。第二段给输入格式说明工程师会提供故障现象和检测信息可能是不完整的、口语化的。你需要先将其结构化为故障现象、检测部位、检测结果、初步判断四个字段。第三段给推理规则基于结构化信息和检索到的历史案例给出可能故障原因排序。每个原因必须标注依据来源案例编号或手册条目。如果检索结果不足以支撑判断输出需要进一步检测并说明建议的检测方向。第四段给输出格式工单文本按以下模板生成故障现象、检测过程、原因分析、处理方案、备注。术语使用博世标准术语表见附录。这个提示词的关键在于它把大模型的思考过程约束到了维修逻辑上。不是让模型自由发挥而是让它按现象→检测→推理→方案这个工程师熟悉的路径走。实测下来这样生成的工单工程师修改量能减少六成以上。4. 实测中暴露的问题检索不准、工单跑偏、术语混乱怎么破4.1 检索看起来像但修起来不一样的案例问题出在嵌入模型上线第一周工程师反馈最多的就是搜出来的案例不对。我拿了一个具体例子排查工程师输入洗衣机脱水时剧烈晃动地面不平已排除检索出来的Top 1是一个洗衣机脱水晃动减震器更换的案例。看起来很像但工程师说这个案例的机型是旧款减震结构完全不同参考价值不大。问题出在嵌入模型上。通用的文本嵌入模型对减震器减震结构减震弹簧这些专业术语的区分度不够它更多是在匹配晃动脱水这些通用词。解决方案是用维修领域的语料对嵌入模型做微调或者至少用领域词典做查询扩展。我采用的是后者成本更低。具体做法是维护一个维修术语同义词表查询时把减震器扩展成减震器 OR 减震弹簧 OR 减震结构把扩展后的查询再去做向量匹配。同时在结构化过滤里增加一个机型代际字段把同系列但不同代的机型区分开避免跨代检索。这个改动之后检索准确率以工程师点击有用的比例衡量从不到五成提升到了七成多。剩下的问题主要是长尾故障案例库里本身就没有足够相似的记录这个靠检索策略解决不了只能靠持续积累。4.2 工单生成术语漂移同一个部件三种叫法大模型生成文本时有个通病同一个东西前面叫主控板后面叫控制板再后面叫电脑板。在维修工单里这是大忌因为后续备件系统、知识库都依赖术语一致性。我的解决方案是术语强制映射。在提示词里嵌入一个术语表格式是标准术语允许的同义表达比如主控板控制板、电脑板、主板。生成之后再用一个后处理脚本做一次术语替换把所有非标准表达统一替换成标准术语。这个后处理脚本很简单就是一个字典替换但效果立竿见影。这里有个经验术语表不要一次性建太大先从高频部件开始覆盖前50个部件就能解决八成以上的术语漂移问题。建太大反而维护不过来而且容易误替换。4.3 工程师不信任AI工单修改率高的真正原因系统刚上线时工程师的修改率高达七成。我一开始以为是生成质量问题后来跟几个工程师聊了才发现问题不在质量在信任。工程师看到AI生成的工单第一反应是它懂什么然后习惯性地按自己的写法改一遍哪怕AI写的是对的。解决信任问题靠的不是把模型调得更好而是让推理过程可见。我在工单草稿里增加了判断依据一栏明确写出本判断基于案例#12345该案例故障现象相似度0.87维修结果为更换启动电容。工程师看到依据才会认真评估AI的建议而不是无脑改掉。另一个做法是让工程师参与案例库建设。每次工程师修改了AI生成的工单系统会问一句是否将修改后的版本作为新案例入库。工程师有了参与感对系统的接受度明显提高。三个月后修改率降到了三成左右而且剩下的修改大多是补充现场细节不是推翻AI的判断。5. 让智能体越用越准案例回流、反馈闭环与迭代节奏5.1 新工单如何自动变成可检索的案例案例库不能靠人工录入那样成本太高且更新慢。我的做法是工单确认即入库。工程师在系统里确认工单后后台自动触发一个处理流程抽取结构化字段、生成向量、写入案例库、更新索引。整个过程对工程师透明他不需要做任何额外操作。但这里有个质量控制问题不是所有确认的工单都值得入库。有些工单写得很简略入库反而会污染检索结果。我的过滤规则是工单文本少于50字的不入库没有明确根本原因的不入库根本原因是其他或未知的不入库。这三条规则过滤掉了大约四成的工单但保留下来的案例质量明显更高。入库之后还有一个去重步骤。同一个故障可能被多个工程师写成多个工单内容高度相似。如果全部入库检索时会出现大量重复结果。我用向量相似度做去重相似度超过0.95的案例只保留最新的一个旧的标记为已合并。5.2 用工程师的点击行为做隐式反馈检索结果好不好工程师最清楚。我在检索结果展示时加了两个隐式反馈信号点击和停留时长。工程师点击了某个案例说明它可能相关如果点击后停留超过30秒说明他认真看了相关性更高如果点击后立刻返回说明不相关。这些信号被记录下来用于调整检索排序。具体做法是给每个案例维护一个历史点击质量分初始为1.0被点击且停留时间长则加分被点击但立刻返回则减分。这个分数作为排序的一个加权因子权重设得不高大概0.1左右避免短期波动影响太大。这个机制运行两个月后Top 1案例的点击率从四成提升到了六成多。效果不算惊艳但胜在稳定而且不需要人工标注数据。5.3 迭代节奏不要追求一次做完美要追求每周都有小改进做这类智能体最大的忌讳是憋大招。我见过团队花半年做一个完美版本上线后发现工程师根本不用。我的节奏是两周一个迭代每次只改一个点。第一个迭代只做信息结构化工单生成还是模板填充但工程师已经觉得比手写快了。第二个迭代加入案例检索但只做关键词匹配准确率一般但工程师开始用检索功能了。第三个迭代换成向量检索准确率提升工程师开始信任检索结果。第四个迭代加入术语映射工单规范性明显改善。每个迭代都收集工程师反馈反馈最多的那个问题就是下个迭代要解决的。这个节奏看起来慢但每一步都踩在真实需求上不会做无用功。而且工程师能看到系统在持续变好对系统的耐心和信任也会增加。6. 几个只有实际做过才知道的细节先说一个关于输入引导的细节。工程师输入信息时如果完全自由输入质量参差不齐。我的做法是在输入框上方放一个简短的引导建议包含故障现象、发生条件、已做的检测、检测结果。就这一句话让结构化抽取的准确率提升了不少。因为工程师看到引导会下意识地按这个结构组织语言抽取自然更容易。再说冷启动的问题。案例库刚建时只有几百条检索效果很差。我的做法是先用维修手册和培训资料生成一批虚拟案例虽然不如真实工单鲜活但至少让检索有东西可返回。等真实工单积累到一定量再逐步替换掉虚拟案例。这个过渡期大概需要两三个月。还有一个关于模型选择的经验。工单生成这种任务不需要用最大的模型。我用的是中等规模的模型生成质量足够响应速度更快成本也低得多。真正需要大模型能力的是故障推理环节那里我会调用更强的模型。不同环节用不同规模的模型这个策略让整体成本降了一半以上效果几乎没有损失。最后说一个安全兜底的设计。智能体生成的所有内容在展示给工程师之前会经过一层规则检查如果包含带电操作短接跳过保护等危险词汇直接拦截并提示该建议涉及安全风险请遵循标准操作流程。这层检查是纯规则的不依赖模型响应快且不会漏。规则库需要定期更新把新出现的风险表达加进去。这套东西做下来我的体会是智能体在售后场景的价值不在于它有多聪明而在于它能把老师傅的经验固化下来让每个工程师都能用上。工单编写和案例检索只是切入点真正有价值的是背后那个持续积累、越用越准的知识库。技术方案可以复制但案例库的积累需要时间这才是真正的壁垒。 博世家电售后故障工单AI智能体：案例检索与工单编写实战
1. 博世维修场景下故障工单为什么值得用AI智能体重做一遍在博世这类家电售后体系里干过的人都知道故障工单是整个维修流程的中枢神经。客户报修时说的那句冰箱不制冷了经过客服记录、派单、工程师上门、检测、填写维修记录、归档最后变成一张工单。这张工单写得好不好直接决定了后续三件事第一工程师能不能快速定位问题第二备件能不能一次带对第三这个案例以后能不能被检索出来复用。我接触过不少售后团队工单质量参差不齐是普遍现象。有的工程师写已维修正常有的写压缩机启动电容失效更换后制冷恢复运行电流0.8A符合铭牌标称。后者才是真正有价值的工单但要求每个工程师都这么写靠培训和考核很难长期维持。这就是我决定用AI智能体切入这个场景的起点——不是要替代工程师而是把写工单这件重复性高、格式要求严、又极度依赖经验的事交给一个能理解故障语义、能检索历史案例、能按规范输出的智能体来辅助完成。这个智能体要解决的核心问题有三个。故障工单编写工程师只需要输入零散的检测信息比如冷藏室温度12度压缩机不启动听不到继电器吸合声智能体就能生成结构完整、术语规范、包含初步判断的工单草稿。旧案例检索当工程师遇到一个不太确定的故障时智能体能从历史工单库里找出相似案例告诉他上次遇到类似现象最终是主控板继电器驱动电路虚焊。知识沉淀每一次新工单的生成和确认都会反哺案例库让检索越来越准。适合读这篇内容的人我大致分三类。一是做售后系统数字化的技术负责人想知道智能体到底能落地到什么程度二是售后团队的运营管理者关心工单质量和工程师效率能不能同时提升三是对AI智能体开发感兴趣、想找一个真实业务场景练手的开发者。我会把架构设计、提示词工程、检索策略、踩过的坑都摊开讲代码和配置能给的地方尽量给全。需要先说明一点博世官方并没有公开过这样一套系统的完整技术细节下面讲的是我基于家电售后行业的通用实践、以及智能体开发的常见工程方案做的合理还原和补充。如果你所在的团队要做类似的东西这套思路可以直接参考但具体参数和接口需要按你们自己的系统调整。2. 智能体的能力边界它到底该做哪几件事不该做哪几件事2.1 把工单编写拆成三个可独立验证的子任务很多人一上来就想做一个全能维修助手结果做出来的东西什么都沾一点什么都不精。我的做法是把工单编写拆成三个子任务每个子任务单独设计提示词、单独验证效果。第一个子任务是信息结构化。工程师的输入往往是一段口语化的描述比如客户说冰箱下面结冰上面不冷我看了下风扇在转但是风好像没上来蒸发器结霜很厚。智能体要做的第一件事是把这段话映射到标准字段故障现象、检测部位、检测结果、初步判断。这一步不涉及任何推理纯粹是信息抽取和归类用大模型做非常稳。第二个子任务是故障推理。基于结构化的检测信息智能体要给出可能的故障原因排序。这里的关键是推理必须基于案例库和维修手册不能凭空发挥。我的做法是在提示词里强制要求你的判断必须引用检索到的历史案例或手册条目如果检索结果不足以支撑判断明确说需要进一步检测不要猜测。第三个子任务是工单文本生成。把前两步的结果按照博世售后工单的字段规范生成一段可以直接粘贴进系统的文本。这里要控制的是格式和术语比如压缩机不能写成马达主控板不能写成电脑板这些术语一致性靠提示词里的术语表来约束。提示三个子任务分开做最大的好处是出了问题能定位。如果工单写得不好你能判断是信息抽取错了、推理错了、还是格式生成错了。如果揉成一个提示词调试起来就是一团乱麻。2.2 旧案例检索不是关键词搜索是语义匹配加结构化过滤一开始我图省事直接用关键词匹配做案例检索。结果很糟糕工程师输入不制冷搜出来一堆制冷正常但噪音大的工单因为都含制冷两个字。后来改成向量语义检索效果好了一些但又出现新问题语义相似的案例可能机型完全不同维修方案根本不通用。最终的方案是混合检索先用结构化字段做硬过滤比如机型系列、故障大类、年份范围把候选集从几万条压到几百条再在这几百条里做向量语义匹配找出最相似的Top 5最后用一个轻量级的重排序模型结合故障现象的匹配度和维修结果的相似度给出最终排序。这个设计背后的逻辑是维修案例的相似性不只是文本相似还包括设备相似和故障机理相似。一个博世6系冰箱的制冷故障和一个4系冰箱的制冷故障文本可能很像但内部结构差异可能导致维修方案不同。所以结构化过滤必须放在语义匹配之前这是我在实际调试中踩坑之后才想明白的。2.3 明确智能体不碰的领域安全判断和最终决策有一条红线我定得很死智能体不输出任何涉及安全操作的最终判断。比如这个电容可以带电更换这种话智能体绝对不能说。它的输出里如果涉及电气安全、制冷剂操作、高压部件必须强制附加请遵循博世安全操作规范由持证工程师确认后执行。另一个不碰的是最终维修决策。智能体可以给出可能原因排序和建议检测步骤但最终换什么件、怎么修必须由工程师确认。这不是技术做不到而是责任边界问题。售后场景里一个错误的维修建议可能导致返修甚至安全事故这个责任智能体承担不了也不应该承担。3. 从零搭一个能用的智能体架构选型与核心模块实现3.1 为什么我选平台智能体自建检索服务的混合架构现在做智能体的路径大概有两条。一条是用Coze、Dify这类平台拖拽式搭建上手快但检索逻辑和数据处理受平台限制。另一条是纯Python自建用LangChain或类似框架灵活但工作量大。我的选择是混合对话编排和提示词管理放在平台上检索服务和数据处理用Python自建。原因很实际。平台智能体在对话管理、多轮上下文、插件调用这些方面做得很成熟没必要重复造轮子。但案例检索涉及向量库、结构化过滤、重排序这些平台要么不支持要么支持得很浅必须自己写。具体分工是这样的平台智能体负责接收工程师输入、调用检索插件、组织提示词、生成最终工单文本。Python服务负责案例库的向量化、索引维护、混合检索接口。两者通过HTTP接口通信平台智能体把工程师的查询发给检索服务拿到Top 5案例后再交给大模型做推理和生成。这个架构还有一个好处检索服务可以独立迭代。我调整检索策略、换嵌入模型、优化重排序都不需要动平台上的智能体配置。反过来智能体换平台或者换模型检索服务也不受影响。3.2 案例库的数据结构设计字段比模型更重要做检索的人容易犯一个错花大量时间调模型却忽略了数据结构。我的经验是案例库的字段设计决定了检索效果的上限模型只是逼近这个上限。下面是我实际用的案例表结构字段不多但每个都有明确用途字段名类型用途是否参与检索case_id字符串唯一标识否product_line枚举产品线如冰箱、洗衣机硬过滤model_series字符串机型系列硬过滤fault_category枚举故障大类如制冷、电气、噪音硬过滤symptom_text文本故障现象描述向量检索detection_text文本检测过程和结果向量检索root_cause文本根本原因展示用solution文本维修方案展示用parts_replaced列表更换的备件展示用engineer_id字符串工程师标识否created_at日期工单创建时间排序权重这里有几个设计细节值得说。fault_category用枚举而不是自由文本是为了硬过滤时能精确匹配如果让工程师自由填会出现制冷故障不制冷制冷问题三种写法过滤就失效了。symptom_text和detection_text分开存是因为检索时两者的权重不同——故障现象相似度比检测过程相似度更重要分开存才能分别计算相似度再加权。created_at参与排序权重是因为维修方案会随产品迭代变化。三年前的维修方案可能因为备件更新或设计变更已经不再适用。我的做法是给近期案例更高的排序权重但不是简单按时间排而是结合相似度做加权。3.3 混合检索的完整实现从查询到Top 5案例检索服务的核心逻辑我用一段伪代码来说明实际实现是Python加向量数据库def hybrid_retrieve(query, filters, top_k5): # 第一步结构化硬过滤 candidates db.filter( product_linefilters.product_line, model_seriesfilters.model_series, fault_categoryfilters.fault_category ) # 如果过滤后候选太少放宽机型系列限制 if len(candidates) 20: candidates db.filter( product_linefilters.product_line, fault_categoryfilters.fault_category ) # 第二步向量语义匹配 query_vector embed(query.symptom_text) scored [] for case in candidates: symptom_sim cosine(query_vector, case.symptom_vector) detection_sim cosine(query_vector, case.detection_vector) # 故障现象权重0.7检测过程权重0.3 combined 0.7 * symptom_sim 0.3 * detection_sim scored.append((case, combined)) # 第三步时间衰减加权 now current_date() weighted [] for case, score in scored: days_old (now - case.created_at).days # 一年内的案例不衰减超过一年按天衰减 time_factor 1.0 if days_old 365 else max(0.5, 1.0 - (days_old - 365) / 3650) weighted.append((case, score * time_factor)) # 第四步排序返回 weighted.sort(keylambda x: x[1], reverseTrue) return weighted[:top_k]这段代码里有几个参数是我反复调出来的。故障现象权重0.7、检测过程0.3是因为实际使用中工程师更关注现象像不像检测过程只是辅助。时间衰减的下限设0.5是为了避免老案例被完全压死——有些经典故障的维修方案多年不变完全排除掉反而损失了有价值的信息。注意硬过滤放宽策略要谨慎。我一开始设的阈值是候选少于50条就放宽结果经常把不同产品线的案例混进来。后来改成先按产品线过滤只在机型系列层面放宽效果好很多。3.4 提示词工程让大模型按维修逻辑思考而不是按语言逻辑智能体生成工单的质量八成取决于提示词。我见过很多提示词写的是请根据以下信息生成维修工单这种提示词出来的结果就是语言通顺但逻辑混乱。我的提示词结构是这样的分四段第一段定角色和边界你是一名博世家电售后技术支持助手。你的任务是辅助工程师编写故障工单和检索历史案例。你不做最终维修决策不输出安全操作判断。第二段给输入格式说明工程师会提供故障现象和检测信息可能是不完整的、口语化的。你需要先将其结构化为故障现象、检测部位、检测结果、初步判断四个字段。第三段给推理规则基于结构化信息和检索到的历史案例给出可能故障原因排序。每个原因必须标注依据来源案例编号或手册条目。如果检索结果不足以支撑判断输出需要进一步检测并说明建议的检测方向。第四段给输出格式工单文本按以下模板生成故障现象、检测过程、原因分析、处理方案、备注。术语使用博世标准术语表见附录。这个提示词的关键在于它把大模型的思考过程约束到了维修逻辑上。不是让模型自由发挥而是让它按现象→检测→推理→方案这个工程师熟悉的路径走。实测下来这样生成的工单工程师修改量能减少六成以上。4. 实测中暴露的问题检索不准、工单跑偏、术语混乱怎么破4.1 检索看起来像但修起来不一样的案例问题出在嵌入模型上线第一周工程师反馈最多的就是搜出来的案例不对。我拿了一个具体例子排查工程师输入洗衣机脱水时剧烈晃动地面不平已排除检索出来的Top 1是一个洗衣机脱水晃动减震器更换的案例。看起来很像但工程师说这个案例的机型是旧款减震结构完全不同参考价值不大。问题出在嵌入模型上。通用的文本嵌入模型对减震器减震结构减震弹簧这些专业术语的区分度不够它更多是在匹配晃动脱水这些通用词。解决方案是用维修领域的语料对嵌入模型做微调或者至少用领域词典做查询扩展。我采用的是后者成本更低。具体做法是维护一个维修术语同义词表查询时把减震器扩展成减震器 OR 减震弹簧 OR 减震结构把扩展后的查询再去做向量匹配。同时在结构化过滤里增加一个机型代际字段把同系列但不同代的机型区分开避免跨代检索。这个改动之后检索准确率以工程师点击有用的比例衡量从不到五成提升到了七成多。剩下的问题主要是长尾故障案例库里本身就没有足够相似的记录这个靠检索策略解决不了只能靠持续积累。4.2 工单生成术语漂移同一个部件三种叫法大模型生成文本时有个通病同一个东西前面叫主控板后面叫控制板再后面叫电脑板。在维修工单里这是大忌因为后续备件系统、知识库都依赖术语一致性。我的解决方案是术语强制映射。在提示词里嵌入一个术语表格式是标准术语允许的同义表达比如主控板控制板、电脑板、主板。生成之后再用一个后处理脚本做一次术语替换把所有非标准表达统一替换成标准术语。这个后处理脚本很简单就是一个字典替换但效果立竿见影。这里有个经验术语表不要一次性建太大先从高频部件开始覆盖前50个部件就能解决八成以上的术语漂移问题。建太大反而维护不过来而且容易误替换。4.3 工程师不信任AI工单修改率高的真正原因系统刚上线时工程师的修改率高达七成。我一开始以为是生成质量问题后来跟几个工程师聊了才发现问题不在质量在信任。工程师看到AI生成的工单第一反应是它懂什么然后习惯性地按自己的写法改一遍哪怕AI写的是对的。解决信任问题靠的不是把模型调得更好而是让推理过程可见。我在工单草稿里增加了判断依据一栏明确写出本判断基于案例#12345该案例故障现象相似度0.87维修结果为更换启动电容。工程师看到依据才会认真评估AI的建议而不是无脑改掉。另一个做法是让工程师参与案例库建设。每次工程师修改了AI生成的工单系统会问一句是否将修改后的版本作为新案例入库。工程师有了参与感对系统的接受度明显提高。三个月后修改率降到了三成左右而且剩下的修改大多是补充现场细节不是推翻AI的判断。5. 让智能体越用越准案例回流、反馈闭环与迭代节奏5.1 新工单如何自动变成可检索的案例案例库不能靠人工录入那样成本太高且更新慢。我的做法是工单确认即入库。工程师在系统里确认工单后后台自动触发一个处理流程抽取结构化字段、生成向量、写入案例库、更新索引。整个过程对工程师透明他不需要做任何额外操作。但这里有个质量控制问题不是所有确认的工单都值得入库。有些工单写得很简略入库反而会污染检索结果。我的过滤规则是工单文本少于50字的不入库没有明确根本原因的不入库根本原因是其他或未知的不入库。这三条规则过滤掉了大约四成的工单但保留下来的案例质量明显更高。入库之后还有一个去重步骤。同一个故障可能被多个工程师写成多个工单内容高度相似。如果全部入库检索时会出现大量重复结果。我用向量相似度做去重相似度超过0.95的案例只保留最新的一个旧的标记为已合并。5.2 用工程师的点击行为做隐式反馈检索结果好不好工程师最清楚。我在检索结果展示时加了两个隐式反馈信号点击和停留时长。工程师点击了某个案例说明它可能相关如果点击后停留超过30秒说明他认真看了相关性更高如果点击后立刻返回说明不相关。这些信号被记录下来用于调整检索排序。具体做法是给每个案例维护一个历史点击质量分初始为1.0被点击且停留时间长则加分被点击但立刻返回则减分。这个分数作为排序的一个加权因子权重设得不高大概0.1左右避免短期波动影响太大。这个机制运行两个月后Top 1案例的点击率从四成提升到了六成多。效果不算惊艳但胜在稳定而且不需要人工标注数据。5.3 迭代节奏不要追求一次做完美要追求每周都有小改进做这类智能体最大的忌讳是憋大招。我见过团队花半年做一个完美版本上线后发现工程师根本不用。我的节奏是两周一个迭代每次只改一个点。第一个迭代只做信息结构化工单生成还是模板填充但工程师已经觉得比手写快了。第二个迭代加入案例检索但只做关键词匹配准确率一般但工程师开始用检索功能了。第三个迭代换成向量检索准确率提升工程师开始信任检索结果。第四个迭代加入术语映射工单规范性明显改善。每个迭代都收集工程师反馈反馈最多的那个问题就是下个迭代要解决的。这个节奏看起来慢但每一步都踩在真实需求上不会做无用功。而且工程师能看到系统在持续变好对系统的耐心和信任也会增加。6. 几个只有实际做过才知道的细节先说一个关于输入引导的细节。工程师输入信息时如果完全自由输入质量参差不齐。我的做法是在输入框上方放一个简短的引导建议包含故障现象、发生条件、已做的检测、检测结果。就这一句话让结构化抽取的准确率提升了不少。因为工程师看到引导会下意识地按这个结构组织语言抽取自然更容易。再说冷启动的问题。案例库刚建时只有几百条检索效果很差。我的做法是先用维修手册和培训资料生成一批虚拟案例虽然不如真实工单鲜活但至少让检索有东西可返回。等真实工单积累到一定量再逐步替换掉虚拟案例。这个过渡期大概需要两三个月。还有一个关于模型选择的经验。工单生成这种任务不需要用最大的模型。我用的是中等规模的模型生成质量足够响应速度更快成本也低得多。真正需要大模型能力的是故障推理环节那里我会调用更强的模型。不同环节用不同规模的模型这个策略让整体成本降了一半以上效果几乎没有损失。最后说一个安全兜底的设计。智能体生成的所有内容在展示给工程师之前会经过一层规则检查如果包含带电操作短接跳过保护等危险词汇直接拦截并提示该建议涉及安全风险请遵循标准操作流程。这层检查是纯规则的不依赖模型响应快且不会漏。规则库需要定期更新把新出现的风险表达加进去。这套东西做下来我的体会是智能体在售后场景的价值不在于它有多聪明而在于它能把老师傅的经验固化下来让每个工程师都能用上。工单编写和案例检索只是切入点真正有价值的是背后那个持续积累、越用越准的知识库。技术方案可以复制但案例库的积累需要时间这才是真正的壁垒。