做电商客服意图识别这件事最开始我其实是有点抵触的。市面上聊意图识别的文章很多但大多只讲某一个点要么吹LLM万能要么把规则和关键词批得一文不值要么就只给你看一个准确率数字。但在真实的生产环境里尤其是电商客服这种意图密度极高、话术又碎又杂的场景单一方案根本撑不住。今天这篇不务虚直接把我这边落地的一套“规则小模型LLM”三层混合架构拆开来讲包括每一层解决什么问题、怎么实现、参数怎么调、上线后踩了哪些坑以及最关键的——为什么三层各干各的反而比单一大模型省钱又稳定。先花两句话说清楚这套东西是干什么的用户在电商平台找客服聊售后、物流、价保、发票、退换货等等系统需要实时判断用户来意也就是意图识别。这个结果会决定后续转人工、自动答复、还是走特定工单流程。它需要的是一个高并发、低延迟、带可解释性、且能持续迭代的分类通道。这套架构里我用规则兜底高频、小模型承接中频、LLM处理长尾和复杂推理三层按“先便宜后贵、先确定后模糊”的顺序联动。1. 内容整体设计与思路拆解1.1 为什么没直接用一整套大模型方案先讲结论纯LLM方案在电商客服场景里重推理但轻高频成本和延迟都是硬伤。我当时先做了个PoC把用户会话前两句丢给GPT-4级别的模型去做意图抽取效果确实好——至少文本理解上非常准连客服套话里的情绪、上下文翻转都能识别出来。但问题是这套方案扛不住电商场景的流量模型。大促期间平台客服的实时并发会冲到几千QPS每一路都要走大模型推理响应延迟和成本直接失控。而且每天有几百万条历史会话需要用离线方式批量跑一遍用来回流标注和修正规则这笔账单是天文数字。另外一个很重要的点是可解释性。电商客服和平台治理部门经常要复盘个案问“这个意图为什么走到这个分支”。LLM给出的是一个概率分布或者是一大段文字说明运营的人根本没法拿这个去做质检更没法指导规则优化。相比之下规则引擎虽然“笨”但每一步决策都有迹可循。所以我的结论是高频场景必须用确定性的方式解决LLM只做长尾兜底。这就是三层混合架构出现的核心原因。1.2 三层各自解决的核心问题这套架构的分工逻辑非常像公司的组织架构一线客服规则层处理标准化问题业务主管小模型层处理常见但表达多样的问题专家团队LLM层处理复杂和边界问题。规则层解决的是“确定性高、表达高度标准化”的意图。比如“我要退货”、“怎么开发票”、“运费谁出”。特点是请求量大、说法模式固定、必须零延迟响应。小模型层解决的是“意图明确但表达多样”的场景。同样是退款用户可能说“钱什么时候到账”、“我没收到退款”、“订单显示退款中但银行卡没动静”。这些说法规则覆盖不全但意图分布相对稳定适合用文本分类模型处理。LLM层解决的是“需要上下文理解、多意图混合、甚至情绪判断”的复杂场景。比如用户先问物流再问价保中间还穿插一句抱怨这时候需要大模型综合判断主次意图甚至区分真实诉求和情绪发泄。三层之间不是并列关系而是漏斗关系。请求先走最便宜的一层判不了再往下透传。这样既控制了平均成本又提高了整体的意图识别覆盖率。1.3 选型时对比过的几种方案在动手之前我对比过市面上主流的几种做法简单列一下优缺点方案优点缺点适用场景纯规则/词典匹配快、可控、成本低覆盖度差、维护成本高高频标准化场景传统机器学习SVM/贝叶斯训练快、可解释特征工程重、表达泛化差小样本、特征稳定的场景预训练小模型BERT系泛化好、效果好、可微调需要标注数据、部署较复杂中频、表达多样的场景Prompt工程LLM零样本、理解强、免训练贵、慢、不可控长尾复杂场景微调LLM效果上限高成本极高、训练复杂、易漂移专业领域深度定制我最终选择的组合就是第三行加第四行用规则去降低高频成本用LLM处理长尾覆盖小模型卡在中间做性价比最高的主力分类器。纯机器学习的传统方案在电商这种话术快速变化的场景里维护成本太高我放弃了。2. 核心细节解析与实操要点2.1 规则层的设计不是简单写一堆关键词很多人对规则层的理解就是维护一个关键词表哪个词命中就归类到对应意图。但实际做了以后你会发现直接在原文上做关键词匹配会遇到一堆问题。第一个问题是词面覆盖不够。用户很少会规规矩矩说“我要退货”更多的是“不合适想退”、“能退吗”、“七天无理由怎么弄”。关键词表很容易越加越大但覆盖率反而越来越低。第二个问题是歧义和冲突。“退”这个字至少关联“退货”、“退款”、“退运费”三个意图。如果只做字面匹配根本分不开。所以在规则层我用了意图触发词意图阻断词的双层匹配结构。举个例子设置“退货”意图时规则不是简单匹配“退”字而是定义一组触发条件触发词或模式包含退货|退回去|寄回|召回|不想穿了|不合适想退且会话中出现“商品本身”相关的实体比如商品链接、SKU这时候“快递退回来”这种物流场景就不会误命中到“退货”。类似的阻断词逻辑还用于区分“退款”和“退款原因”比如“为什么退款”、“退款要多久”其实是咨询类而不是退款申请类。第三个问题则是正则表达式的滥用。很多人觉得规则层就是写正则结果一条正则套三层转义维护的人的脑子直接过载。我这边规定正则只允许处理确定性的模式比如订单号提取、数量提取、日期提取。意图判定一律用组合式规则比如匹配词词性位置槽位条件而不是一锤子正则。为了保证规则层不失控所有规则上线前要做冲突测试。我会维护一批回归case至少覆盖现有所有意图的边界表达每次新增规则都跑一遍回归确认没有引入误杀。2.2 小模型层的选型与调优小模型层我最终选了BERT系列的中文预训练模型具体用的是bert-base-chinese。其实也试过更轻量的albert和textcnn但电商客服的句子不长语义却非常密集过浅的模型在意图边界上的表现确实略差。最后综合考虑效果和线上QPS选了12层的BERT base精度最高代价是推理延迟需要靠优化来补。分类的标签体系是整个模型效果的天花板。我一开始直接用十几个原始“标准意图”做标签训练效果很差。后来把所有意图体系重新梳理了一版分成两级一级意图大类比如“退货”、“退款”、“发票”、“物流”、“价保”、“客服投诉”等大概20个左右用于路由决策。二级意图细分场景比如“退货”下分“质量问题退货”、“七天无理由退货”、“多件商品部分退货”等用于具体业务处理。训练时我让模型直接预测二级意图再用映射表把二级汇总到一级。这样做的好处是模型学到的语义边界更细上级分类的混淆自然减少了。举个例子模型如果能区分“七天无理由退货”和“因缺货申请退货”回到一级就几乎不会把“退款”和“退货”混在一起。数据标注是这块最费人力的环节。我这边大概标了4.6万条客服会话首句分为三类标签意图标签、情绪标签正向/中性/负向、以及是否为有效业务请求。标注指南写了三版才稳定关键原则是如果一句话同时有两个意图标为主要意图次要意图训练时只学主要意图避免模型学出“骑墙”的分布。训练细节上有一个参数很关键——max_seq_len。电商客服语句平均不到20个字但偶尔会有60字以上的长句。我试过128和64两种情况64时虽然快一点但长句会被截断丢失关键信息准确率掉了约1.8个百分点。最后设为96兼顾速度和效果。2.3 LLM层的定位不是万能是兜底到LLM这一层我用了工业界很成熟的方案few-shot prompting 结构化输出约束。模型选的是通用中英文对话模型不追求最强推理但要求指令跟随稳、输出格式稳定。这里额外引入了一个类似RAG的思路把历史相似case的“意图标注”作为参考样本动态注入prompt帮助模型稳定行为而不是每次凭空推理。落地的prompt结构大概是你是电商客服意图识别系统。请判断用户最后一条消息的主要意图和次要意图。 可选意图退货、退款、发票、物流、价保、投诉、咨询、闲聊、其他。 规则只输出JSON格式如下 {primary: ..., secondary: ..., confidence: 0.0-1.0, reason: ...} 参考示例 用户你们这个衣服七天可以退吗 输出{primary: 退货, secondary: 七天无理由退货, confidence: 0.9, reason: 提到七天和退货触发条件} 用户输入{这里填实际输入}为什么不用微调LLM因为意图识别的标签体系本身就在持续迭代今天加了“价保”可能下个月又加了“补寄小配件”。如果每次改意图体系都要重新微调一次模型成本完全兜不住。而靠prompt注入标签定义和几个示例改起来就只是改文本的事。LLM层的QPS不需要高因为经过前两层过滤后到这里的基本只剩长尾case和低置信度case大概占总流量的8%左右。但这8%恰恰是影响用户满意度最致命的区域——规则和小模型都搞不定的一定是难缠的所以这里我宁可多花点推理成本也要把准确率做上去。3. 实操过程与核心环节实现3.1 整体处理链路与路由逻辑三层之间的路由逻辑是整套系统的骨架。我最终实现的是一个树状的判定流程用伪代码表示大概是这样def classify(session): # 第一层规则引擎 rule_result rule_engine.match(session) if rule_result.confidence 0.95: return rule_result.intent, rule # 第二层小模型 bert_result bert_model.predict(session) if bert_result.confidence 0.80 and bert_result.intent not in black_list: return bert_result.intent, bert # 第三层LLM llm_result llm_router.chat(session, examplesbuild_fewshot(session)) return llm_result.intent, llm规则引擎给的是离散置信度。我这边规则引擎支持三种命中等第“完全命中”、“候选命中”、“未命中”。只有当完全命中时才可以直接出结果候选命中会参考小模型的输出做加权。这里的置信度不是硬编码而是根据规则的历史胜算率动态调整的比如某条规则过去100次触发有96次判对了就把它调到完全命中档。小模型的阈值是拿验证集上做的代价敏感优化。业务上“把退货误判成退款”的代价比“把退款误判成退货”低很多因为后者会直接触发退款流程没法收回。因此我在不同意图上设置了不同的阈值而不是用一个全局0.8通吃。3.2 小模型的工程落地与性能优化小模型的推理部署我用了ONNX Runtime 动态量化。因为意图识别是纯文本分类任务对数值精度不敏感动态量化几乎无损掉点但在CPU上推理速度提升明显。部署环境是CPU没用GPU。原因很简单GPU资源要留给LLM层而且BERT base在CPU上跑优化后本来就能达到单实例几十毫秒的延迟。线上服务封装成了一个独立的微服务暴露两个接口/classify实时单条请求分类走完整链路/batch_classify离线批量分类用于回流标注接入层的超时控制很关键。我给每层都设了独立超时规则层要求5ms以内返回小模型要求50ms以内LLM要求500ms以内。如果LLM超时直接走默认的fallback策略即“转人工”而不是尝试猜测用户意图。在客服场景里猜错的代价远大于不猜。基本IO的预处理也踩了坑。文本清洗这步不能省特别是去掉各种不可见字符、统一数字和金额格式、把“8点”这种时间表述归一化否则同一个意思会变成两种特征。3.3 LLM层的成本控制单路成本直接打下来这是我要单独说的一节。LLM推理成本是三层里最不可控的但也是最能通过工程手段省钱的。第一招是缓存。电商客服的意图分布极不均衡少量高频表达占了超过一半。同一句话在10个订单上可能出现用户的表述几乎一样这就可以做语义级别的缓存。我按“归一化后的文本哈希历史意图”做key命中后直接复用上次的LLM结果缓存命中率约有30%直接砍掉接近三分之一的大模型调用量。第二招是用便宜模型做初筛贵模型只做纠错。LLM层内部我也分了级先用一个轻量模型跑一次如果置信度大于0.9就直接采纳不再调用更强模型。只有低置信度case才升级到强模型。这里实测的效果是大约55%的LLM层请求可以由轻量模型搞定整体大模型成本降了约40%。第三招是prompt长度控制。few-shot示例不能无限加示例越多token消耗越大延迟也越高。我需要的是“每类意图至少一个正例和一个反例”但控制在总长400 token以内。多轮对话只保留最近两轮作为上下文更早的信息全部截断因为意图识别看的是用户当前诉求看太久远的对话反而容易被噪音误导。3.4 数据回流这套系统长跑的关键三层系统上线不是终点真正的持续迭代靠的是数据回流机制。LLM层判出的结果不能直接当正确答案但可以作为“候选标注”和rule层、bert层给出的结果一起组成一条带多种判断的记录进入人工评测池。我这边搭建了一个很轻量的评测回测工具每天从线上日志里按策略抽样1000条case标注员在web界面上给出最终判定系统自动对比三个层的结果输出每天各层的准确率、召回率、误杀率。这个数据决定了第二天的阈值调整。其中有一个很重要的观察小模型的离线指标和线上指标会严重漂移。离线F1能有0.91上线后经常掉到0.85甚至更低。后来查了原因是线上会涌来大量训练集里完全没有的全新话术。所以我养成一个习惯每天看线上badcase抽20条人工看一遍然后按周把badcase回流进训练集再做增量微调。4. 常见问题与排查技巧实录4.1 意图边界模糊时怎么办最常见的badcase是两个意图在表达上高度重叠。比如“退款”和“投诉”用户说“你们这个质量也太差了我要退钱”表面是退款但内核是投诉。规则层的“阻断词”策略在这里往往失效因为两类词都出现了。我的解法是在规则层遇到“候选命中冲突”时放弃判定直接把case交给小模型。小模型学到的语义边界要比规则灵活它见过足够多的“退款”和“投诉”表达可以区分“要退钱”和“要讨说法”的细微差异。如果小模型的置信度依然低于阈值才动用LLM但必须要求LLM输出reason字段方便人工质检。4.2 LLM生成结果不稳定、偶尔带情绪大模型做结构化输出时偶尔会输出不规范的JSON比如键多了引号、值带了注释直接解析就会崩。我一开始用的是正则抽取后来发现太脆弱改成强制模型输出JSON后再用一个修复层去兜底先尝试json.loads失败就尝试提取大括号内的内容再解析再失败就返回“无法识别”走到转人工。另一个坑是模型会顺着用户的话说。比如用户抱怨了很久模型居然在reason字段里写“根据用户抱怨的情绪倾向转为投诉”这本身没问题但如果输出格式不受控很可能出现“reason”和“primary”矛盾的情况。所以我在prompt里额外加了规则“只根据业务意图判定不根据情绪判定”并且在后置校验里增加了逻辑一致性检查。4.3 线上实时数据倾斜问题大促期间用户话术会短时间剧变比如“618凑单怎么退”。小模型训练集里完全没有“凑单”这类词误判率急升。这类问题在初版上线时暴打过我一次后来在监控里加了“关键词新鲜度”指标每天统计线上Top意图下出现的新词如果某个词突然增速超过5%且从未出现在训练集里自动打标记送入人工审核。规则引擎应对这种情况有天然优势新词可以直接通过维护规则快速补齐模型层来不及重训时规则就能顶上。这也是为什么我不建议把这套架构里的规则层拿出来单独替代掉的原因——它是线上系统的急刹车。4.5 各层指标监控与报警整个系统接了一套简单的业务监控大盘但真正有意义的指标不是接口延迟和成功率而是各层意图分布的日环比波动。如果某天“退款”意图占比突然涨了5个百分点大概率不是用户行为变了而是某个规则或者模型分支出了问题。出现这种情况我会第一时间去看日志里的badcase往往几分钟内就能定位问题是哪一层导致的。关于报警阈值我这边设了一个“层间分歧率”指标同一条case在不同层的判定结果不一致的比例。正常情况下这个值在10%以内超过15%基本可以判定有弱分类器出了状态漂移需要立即人工介入。最后再分享一条我在这套系统上最深的体会三层混合架构真正难的地方不在模型选择而在每一层之间“如何优雅地放手”。规则层该让位的时候别硬撑小模型该认怂的时候别顶着低置信度输出LLM该兜底的时候也别过度信任它的答案。这套系统跑了半年多整体意图识别线上准确率稳定在91%到93%之间单条请求平均耗时在70毫秒左右大模型每条请求的token成本大概是纯LLM方案的六分之一。做AI应用的人心里都清楚能上线、扛得住、修得动比什么都重要。
做电商客服意图识别这件事最开始我其实是有点抵触的。市面上聊意图识别的文章很多但大多只讲某一个点要么吹LLM万能要么把规则和关键词批得一文不值要么就只给你看一个准确率数字。但在真实的生产环境里尤其是电商客服这种意图密度极高、话术又碎又杂的场景单一方案根本撑不住。今天这篇不务虚直接把我这边落地的一套“规则小模型LLM”三层混合架构拆开来讲包括每一层解决什么问题、怎么实现、参数怎么调、上线后踩了哪些坑以及最关键的——为什么三层各干各的反而比单一大模型省钱又稳定。先花两句话说清楚这套东西是干什么的用户在电商平台找客服聊售后、物流、价保、发票、退换货等等系统需要实时判断用户来意也就是意图识别。这个结果会决定后续转人工、自动答复、还是走特定工单流程。它需要的是一个高并发、低延迟、带可解释性、且能持续迭代的分类通道。这套架构里我用规则兜底高频、小模型承接中频、LLM处理长尾和复杂推理三层按“先便宜后贵、先确定后模糊”的顺序联动。1. 内容整体设计与思路拆解1.1 为什么没直接用一整套大模型方案先讲结论纯LLM方案在电商客服场景里重推理但轻高频成本和延迟都是硬伤。我当时先做了个PoC把用户会话前两句丢给GPT-4级别的模型去做意图抽取效果确实好——至少文本理解上非常准连客服套话里的情绪、上下文翻转都能识别出来。但问题是这套方案扛不住电商场景的流量模型。大促期间平台客服的实时并发会冲到几千QPS每一路都要走大模型推理响应延迟和成本直接失控。而且每天有几百万条历史会话需要用离线方式批量跑一遍用来回流标注和修正规则这笔账单是天文数字。另外一个很重要的点是可解释性。电商客服和平台治理部门经常要复盘个案问“这个意图为什么走到这个分支”。LLM给出的是一个概率分布或者是一大段文字说明运营的人根本没法拿这个去做质检更没法指导规则优化。相比之下规则引擎虽然“笨”但每一步决策都有迹可循。所以我的结论是高频场景必须用确定性的方式解决LLM只做长尾兜底。这就是三层混合架构出现的核心原因。1.2 三层各自解决的核心问题这套架构的分工逻辑非常像公司的组织架构一线客服规则层处理标准化问题业务主管小模型层处理常见但表达多样的问题专家团队LLM层处理复杂和边界问题。规则层解决的是“确定性高、表达高度标准化”的意图。比如“我要退货”、“怎么开发票”、“运费谁出”。特点是请求量大、说法模式固定、必须零延迟响应。小模型层解决的是“意图明确但表达多样”的场景。同样是退款用户可能说“钱什么时候到账”、“我没收到退款”、“订单显示退款中但银行卡没动静”。这些说法规则覆盖不全但意图分布相对稳定适合用文本分类模型处理。LLM层解决的是“需要上下文理解、多意图混合、甚至情绪判断”的复杂场景。比如用户先问物流再问价保中间还穿插一句抱怨这时候需要大模型综合判断主次意图甚至区分真实诉求和情绪发泄。三层之间不是并列关系而是漏斗关系。请求先走最便宜的一层判不了再往下透传。这样既控制了平均成本又提高了整体的意图识别覆盖率。1.3 选型时对比过的几种方案在动手之前我对比过市面上主流的几种做法简单列一下优缺点方案优点缺点适用场景纯规则/词典匹配快、可控、成本低覆盖度差、维护成本高高频标准化场景传统机器学习SVM/贝叶斯训练快、可解释特征工程重、表达泛化差小样本、特征稳定的场景预训练小模型BERT系泛化好、效果好、可微调需要标注数据、部署较复杂中频、表达多样的场景Prompt工程LLM零样本、理解强、免训练贵、慢、不可控长尾复杂场景微调LLM效果上限高成本极高、训练复杂、易漂移专业领域深度定制我最终选择的组合就是第三行加第四行用规则去降低高频成本用LLM处理长尾覆盖小模型卡在中间做性价比最高的主力分类器。纯机器学习的传统方案在电商这种话术快速变化的场景里维护成本太高我放弃了。2. 核心细节解析与实操要点2.1 规则层的设计不是简单写一堆关键词很多人对规则层的理解就是维护一个关键词表哪个词命中就归类到对应意图。但实际做了以后你会发现直接在原文上做关键词匹配会遇到一堆问题。第一个问题是词面覆盖不够。用户很少会规规矩矩说“我要退货”更多的是“不合适想退”、“能退吗”、“七天无理由怎么弄”。关键词表很容易越加越大但覆盖率反而越来越低。第二个问题是歧义和冲突。“退”这个字至少关联“退货”、“退款”、“退运费”三个意图。如果只做字面匹配根本分不开。所以在规则层我用了意图触发词意图阻断词的双层匹配结构。举个例子设置“退货”意图时规则不是简单匹配“退”字而是定义一组触发条件触发词或模式包含退货|退回去|寄回|召回|不想穿了|不合适想退且会话中出现“商品本身”相关的实体比如商品链接、SKU这时候“快递退回来”这种物流场景就不会误命中到“退货”。类似的阻断词逻辑还用于区分“退款”和“退款原因”比如“为什么退款”、“退款要多久”其实是咨询类而不是退款申请类。第三个问题则是正则表达式的滥用。很多人觉得规则层就是写正则结果一条正则套三层转义维护的人的脑子直接过载。我这边规定正则只允许处理确定性的模式比如订单号提取、数量提取、日期提取。意图判定一律用组合式规则比如匹配词词性位置槽位条件而不是一锤子正则。为了保证规则层不失控所有规则上线前要做冲突测试。我会维护一批回归case至少覆盖现有所有意图的边界表达每次新增规则都跑一遍回归确认没有引入误杀。2.2 小模型层的选型与调优小模型层我最终选了BERT系列的中文预训练模型具体用的是bert-base-chinese。其实也试过更轻量的albert和textcnn但电商客服的句子不长语义却非常密集过浅的模型在意图边界上的表现确实略差。最后综合考虑效果和线上QPS选了12层的BERT base精度最高代价是推理延迟需要靠优化来补。分类的标签体系是整个模型效果的天花板。我一开始直接用十几个原始“标准意图”做标签训练效果很差。后来把所有意图体系重新梳理了一版分成两级一级意图大类比如“退货”、“退款”、“发票”、“物流”、“价保”、“客服投诉”等大概20个左右用于路由决策。二级意图细分场景比如“退货”下分“质量问题退货”、“七天无理由退货”、“多件商品部分退货”等用于具体业务处理。训练时我让模型直接预测二级意图再用映射表把二级汇总到一级。这样做的好处是模型学到的语义边界更细上级分类的混淆自然减少了。举个例子模型如果能区分“七天无理由退货”和“因缺货申请退货”回到一级就几乎不会把“退款”和“退货”混在一起。数据标注是这块最费人力的环节。我这边大概标了4.6万条客服会话首句分为三类标签意图标签、情绪标签正向/中性/负向、以及是否为有效业务请求。标注指南写了三版才稳定关键原则是如果一句话同时有两个意图标为主要意图次要意图训练时只学主要意图避免模型学出“骑墙”的分布。训练细节上有一个参数很关键——max_seq_len。电商客服语句平均不到20个字但偶尔会有60字以上的长句。我试过128和64两种情况64时虽然快一点但长句会被截断丢失关键信息准确率掉了约1.8个百分点。最后设为96兼顾速度和效果。2.3 LLM层的定位不是万能是兜底到LLM这一层我用了工业界很成熟的方案few-shot prompting 结构化输出约束。模型选的是通用中英文对话模型不追求最强推理但要求指令跟随稳、输出格式稳定。这里额外引入了一个类似RAG的思路把历史相似case的“意图标注”作为参考样本动态注入prompt帮助模型稳定行为而不是每次凭空推理。落地的prompt结构大概是你是电商客服意图识别系统。请判断用户最后一条消息的主要意图和次要意图。 可选意图退货、退款、发票、物流、价保、投诉、咨询、闲聊、其他。 规则只输出JSON格式如下 {primary: ..., secondary: ..., confidence: 0.0-1.0, reason: ...} 参考示例 用户你们这个衣服七天可以退吗 输出{primary: 退货, secondary: 七天无理由退货, confidence: 0.9, reason: 提到七天和退货触发条件} 用户输入{这里填实际输入}为什么不用微调LLM因为意图识别的标签体系本身就在持续迭代今天加了“价保”可能下个月又加了“补寄小配件”。如果每次改意图体系都要重新微调一次模型成本完全兜不住。而靠prompt注入标签定义和几个示例改起来就只是改文本的事。LLM层的QPS不需要高因为经过前两层过滤后到这里的基本只剩长尾case和低置信度case大概占总流量的8%左右。但这8%恰恰是影响用户满意度最致命的区域——规则和小模型都搞不定的一定是难缠的所以这里我宁可多花点推理成本也要把准确率做上去。3. 实操过程与核心环节实现3.1 整体处理链路与路由逻辑三层之间的路由逻辑是整套系统的骨架。我最终实现的是一个树状的判定流程用伪代码表示大概是这样def classify(session): # 第一层规则引擎 rule_result rule_engine.match(session) if rule_result.confidence 0.95: return rule_result.intent, rule # 第二层小模型 bert_result bert_model.predict(session) if bert_result.confidence 0.80 and bert_result.intent not in black_list: return bert_result.intent, bert # 第三层LLM llm_result llm_router.chat(session, examplesbuild_fewshot(session)) return llm_result.intent, llm规则引擎给的是离散置信度。我这边规则引擎支持三种命中等第“完全命中”、“候选命中”、“未命中”。只有当完全命中时才可以直接出结果候选命中会参考小模型的输出做加权。这里的置信度不是硬编码而是根据规则的历史胜算率动态调整的比如某条规则过去100次触发有96次判对了就把它调到完全命中档。小模型的阈值是拿验证集上做的代价敏感优化。业务上“把退货误判成退款”的代价比“把退款误判成退货”低很多因为后者会直接触发退款流程没法收回。因此我在不同意图上设置了不同的阈值而不是用一个全局0.8通吃。3.2 小模型的工程落地与性能优化小模型的推理部署我用了ONNX Runtime 动态量化。因为意图识别是纯文本分类任务对数值精度不敏感动态量化几乎无损掉点但在CPU上推理速度提升明显。部署环境是CPU没用GPU。原因很简单GPU资源要留给LLM层而且BERT base在CPU上跑优化后本来就能达到单实例几十毫秒的延迟。线上服务封装成了一个独立的微服务暴露两个接口/classify实时单条请求分类走完整链路/batch_classify离线批量分类用于回流标注接入层的超时控制很关键。我给每层都设了独立超时规则层要求5ms以内返回小模型要求50ms以内LLM要求500ms以内。如果LLM超时直接走默认的fallback策略即“转人工”而不是尝试猜测用户意图。在客服场景里猜错的代价远大于不猜。基本IO的预处理也踩了坑。文本清洗这步不能省特别是去掉各种不可见字符、统一数字和金额格式、把“8点”这种时间表述归一化否则同一个意思会变成两种特征。3.3 LLM层的成本控制单路成本直接打下来这是我要单独说的一节。LLM推理成本是三层里最不可控的但也是最能通过工程手段省钱的。第一招是缓存。电商客服的意图分布极不均衡少量高频表达占了超过一半。同一句话在10个订单上可能出现用户的表述几乎一样这就可以做语义级别的缓存。我按“归一化后的文本哈希历史意图”做key命中后直接复用上次的LLM结果缓存命中率约有30%直接砍掉接近三分之一的大模型调用量。第二招是用便宜模型做初筛贵模型只做纠错。LLM层内部我也分了级先用一个轻量模型跑一次如果置信度大于0.9就直接采纳不再调用更强模型。只有低置信度case才升级到强模型。这里实测的效果是大约55%的LLM层请求可以由轻量模型搞定整体大模型成本降了约40%。第三招是prompt长度控制。few-shot示例不能无限加示例越多token消耗越大延迟也越高。我需要的是“每类意图至少一个正例和一个反例”但控制在总长400 token以内。多轮对话只保留最近两轮作为上下文更早的信息全部截断因为意图识别看的是用户当前诉求看太久远的对话反而容易被噪音误导。3.4 数据回流这套系统长跑的关键三层系统上线不是终点真正的持续迭代靠的是数据回流机制。LLM层判出的结果不能直接当正确答案但可以作为“候选标注”和rule层、bert层给出的结果一起组成一条带多种判断的记录进入人工评测池。我这边搭建了一个很轻量的评测回测工具每天从线上日志里按策略抽样1000条case标注员在web界面上给出最终判定系统自动对比三个层的结果输出每天各层的准确率、召回率、误杀率。这个数据决定了第二天的阈值调整。其中有一个很重要的观察小模型的离线指标和线上指标会严重漂移。离线F1能有0.91上线后经常掉到0.85甚至更低。后来查了原因是线上会涌来大量训练集里完全没有的全新话术。所以我养成一个习惯每天看线上badcase抽20条人工看一遍然后按周把badcase回流进训练集再做增量微调。4. 常见问题与排查技巧实录4.1 意图边界模糊时怎么办最常见的badcase是两个意图在表达上高度重叠。比如“退款”和“投诉”用户说“你们这个质量也太差了我要退钱”表面是退款但内核是投诉。规则层的“阻断词”策略在这里往往失效因为两类词都出现了。我的解法是在规则层遇到“候选命中冲突”时放弃判定直接把case交给小模型。小模型学到的语义边界要比规则灵活它见过足够多的“退款”和“投诉”表达可以区分“要退钱”和“要讨说法”的细微差异。如果小模型的置信度依然低于阈值才动用LLM但必须要求LLM输出reason字段方便人工质检。4.2 LLM生成结果不稳定、偶尔带情绪大模型做结构化输出时偶尔会输出不规范的JSON比如键多了引号、值带了注释直接解析就会崩。我一开始用的是正则抽取后来发现太脆弱改成强制模型输出JSON后再用一个修复层去兜底先尝试json.loads失败就尝试提取大括号内的内容再解析再失败就返回“无法识别”走到转人工。另一个坑是模型会顺着用户的话说。比如用户抱怨了很久模型居然在reason字段里写“根据用户抱怨的情绪倾向转为投诉”这本身没问题但如果输出格式不受控很可能出现“reason”和“primary”矛盾的情况。所以我在prompt里额外加了规则“只根据业务意图判定不根据情绪判定”并且在后置校验里增加了逻辑一致性检查。4.3 线上实时数据倾斜问题大促期间用户话术会短时间剧变比如“618凑单怎么退”。小模型训练集里完全没有“凑单”这类词误判率急升。这类问题在初版上线时暴打过我一次后来在监控里加了“关键词新鲜度”指标每天统计线上Top意图下出现的新词如果某个词突然增速超过5%且从未出现在训练集里自动打标记送入人工审核。规则引擎应对这种情况有天然优势新词可以直接通过维护规则快速补齐模型层来不及重训时规则就能顶上。这也是为什么我不建议把这套架构里的规则层拿出来单独替代掉的原因——它是线上系统的急刹车。4.5 各层指标监控与报警整个系统接了一套简单的业务监控大盘但真正有意义的指标不是接口延迟和成功率而是各层意图分布的日环比波动。如果某天“退款”意图占比突然涨了5个百分点大概率不是用户行为变了而是某个规则或者模型分支出了问题。出现这种情况我会第一时间去看日志里的badcase往往几分钟内就能定位问题是哪一层导致的。关于报警阈值我这边设了一个“层间分歧率”指标同一条case在不同层的判定结果不一致的比例。正常情况下这个值在10%以内超过15%基本可以判定有弱分类器出了状态漂移需要立即人工介入。最后再分享一条我在这套系统上最深的体会三层混合架构真正难的地方不在模型选择而在每一层之间“如何优雅地放手”。规则层该让位的时候别硬撑小模型该认怂的时候别顶着低置信度输出LLM该兜底的时候也别过度信任它的答案。这套系统跑了半年多整体意图识别线上准确率稳定在91%到93%之间单条请求平均耗时在70毫秒左右大模型每条请求的token成本大概是纯LLM方案的六分之一。做AI应用的人心里都清楚能上线、扛得住、修得动比什么都重要。
)
)
