去年我们做客服消息意图识别的时候最开始的想法特别简单大模型那么强直接把用户消息丢给LLM分类不就完了吗结果一上线就发现不是那么回事。线上每天的会话消息量在十万级每条都走LLM成本直接爆表而且线程一多延迟就开始抖动客服那边又催得急。后来我把方案改成了规则加小模型加LLM的三层混合架构单条消息的平均处理成本降了一个数量级准确率和稳定性反而提上去了。这篇文章就把这套架构的思路、每一层的具体实现以及层与层之间的调度细节完整拆开讲一遍。这套架构适合谁如果你正在做电商客服机器人、工单自动分类、或者客服会话路由又不想让每一句话都烧大模型的token那这篇文章应该能给你一套可以直接落地的参考。我尽量把代码示例、阈值设置、踩坑记录都写出来是那种可以照着抄作业的级别。1. 为什么客服意图识别不适合“无脑上大模型”1.1 电商客服场景的三个硬约束很多人一提意图识别就想到大模型是因为Demo阶段效果确实惊艳。但电商客服的真实场景有三个约束是Demo里看不出来的。第一是请求量大。一个中大型店铺每天的客服消息量轻松过十万条双十一这种大促能到百万级别。每一轮用户消息都要判断意图这就是实打实的推理请求量。第二是实时性要求高。用户发一句“我东西怎么还没到”系统需要在几百毫秒内给出意图判断好让机器人立即响应。超过两三秒用户就会开始狂发问号。LLM的推理延迟在非流式场景下通常要一秒以上量大时还不稳定。第三是成本敏感。客服消息不像搜索广告那种高价值请求单条消息对应的商业价值就那么点花几厘钱去处理还可以接受但如果每条都要花几分钱甚至更贵业务账就完全算不过来了。这三条约束放到一起决定了我们不能拿LLM当默认选项去处理所有流量。它应该是“最后出场的专家”而不是“前台接待”。1.2 三层各管一块核心目标不是准确率而是“性价比”这套三层混合架构的出发点很简单让便宜的模块处理大部分常见问题只让贵重的模块处理真正复杂的问题。第一层是规则层用正则和词典把那些表达高度固定的请求直接拦下来。比如“查一下快递到哪了”“转人工”“我要投诉”这些话说来说去就那么几种写法没必要让任何模型出场。第二层是小模型层处理的是规则层没有覆盖的、有一定表达变化但整体不复杂的请求。我们用的是TextCNN参数量很小在CPU上单条推理只要几毫秒几乎不占成本。第三层才是LLM层专门处理小模型拿不准的、语义绕的、有多重意图的请求。用户说得再莫名其妙LLM凭借它的常识理解能力能给出一个基本靠谱的判断。准确率当然重要但这套架构真正优化的指标是“单位成本下的准确率”。我的目标是LLM处理的流量占比控制在5%以内但整条链路的意图识别准确率不低于95%。这个目标靠任何单一层都做不到合在一起就能做到。1.3 我踩过的“纯大模型方案”的坑说一个我们自己的反面案例。最早我们用纯LLM方案的时候一开始测试集准确率确实很好看96%以上。但线上跑了一周就发现问题了。首先是账单。纯LLM方案每天十万级请求日成本直接冲到几千块而且这还是在模型输出很短的情况下。其次是延迟波动。早高峰时段模型服务的排队时间拉到三四秒客服机器人出现大量超时未响应用户满意度掉得厉害。最离谱的是稳定性同一个意思换几种表达比如“东西什么时候到”和“货发出来了吗”有时判断成查物流有时判断成催发货行为不可控。后来我们才意识到意图识别这种场景最怕的不是某一条判错了而是“同类型请求处理逻辑不一致”。规则和小模型的输出是完全确定的同样的输入永远给同样的输出这本身就是一种价值。2. 第一层规则层正则和词典先把六成流量拦住2.1 先定意图标签再写规则词典动手写规则之前第一件事是把意图标签体系定下来。这一步必须跟业务方对齐因为后续所有层、所有模块都围绕这套标签工作。我们目前的电商客服场景常用标签如下意图标签含义后续动作示例track_order查物流/催发货查订单物流接口modify_address修改收货地址触发地址修改流程refund申请退款进入退款引导after_sale退换货/维修进入售后流程invoice发票问题推送开票入口product_inquiry商品咨询规格/库存返回商品信息price_discount价格/优惠券咨询返回优惠信息complaint投诉/强烈不满转人工优先处理human_service要求转人工直接转接chitchat闲聊/无关内容闲聊应答或不处理other其他/不确定转人工兜底标签不是越多越好。粒度过细会导致数据稀疏、小模型学不动粒度过粗业务侧又不好用。比如“查物流”和“催发货”在表达上很接近我们一开始合并成一个track_order但运营希望区分“只在问状态”和“已经表达不满”的用户后来才分拆。建议你根据业务方的“后续动作”来定标签动作不同才拆成不同意图。2.2 正则怎么写才不容易误伤写规则层的正则最核心的教训是宁可漏不要错。漏了还有下一层小模型和LLM兜底错了就直接走到错误业务流程用户体感非常差。以track_order为例。我们一开始写了一个很粗糙的正则import re pattern_track_order re.compile(r快递|物流|发货|到哪|没到)结果一堆误判。例如“你们发货地址是在哪”被命中成track_order实际是product_inquiry。再比如“这个物流方式支持顺丰吗”也被误判。后来我们把规则拆成“强规则”和“弱规则”两类。强规则要求同时包含动作词和对象词比如# 强规则动作 对象 pattern_track_order_strong re.compile( r(查|看|问).{0,6}(快递|物流|单号|到哪)| r(快递|物流).{0,6}(到哪|发货|发出)| r(怎么).{0,4}(还没到|没收到|不发货) )弱规则则只作为候选不能单独下结论要交给小模型复核。比如只出现“发货”这个词但没有明确动作就属于弱命中。正则的另一个关键点是排除规则。比如“改地址”和“发货地址”虽然有“地址”和“发货”两个词但真实意图是modify_address或product_inquiry。所以规则层要有一套负向词典把这些常见干扰项排除掉。2.3 规则层的入口拦截清单与优先级规则层不是平均用力而是按优先级排序。我们实际用的优先级大致是转人工只要出现“人工/客服/真人/专员”这类词直接命中human_service且不再做任何后续判断。这个意图风险最低、回报最高。投诉出现“投诉/差评/曝光/315”等词或者语气词组合“太过分了”“气死我了”直接命中complaint。投诉用户不能按常规流程处理必须优先介入。强指令类改地址、退款、开发票这些有明确动作词且动作对象唯一。比如“把地址改成”“申请退款”“开票”。查询类查物流、查商品、查价格等这类即使误判造成的损失也相对小优先级放后面。每一层命中后规则模块会返回一个置信度。规则命中时置信度直接给1.0但如果是弱规则就给0.7左右并标记需要小模型复核。规则层的目标覆盖率我们定在“拦下40%到60%的线上请求”。如果你发现线上请求里大量是千奇百怪的表达说明你的规则还不到位但如果你发现规则越写越复杂、越来越多的正则互相打架说明这部分流量该交给小模型处理了规则层的边际收益到头了。2.4 规则层为什么能养出小模型的训练集这一条我觉得是三层架构里最妙的地方规则层不仅在生产环境干活它还是小模型训练集的主要来源。冷启动阶段没有标注数据怎么办我们把线上历史消息过一遍规则层凡是强规则命中的直接当作该意图的伪标注样本。比如命中了“申请退款”强规则的句子就自动标记为refund。这样不花一分钱标注费就能拿到几万条高质量训练样本。当然伪标注会有噪声。我们的做法是规则命中后抽样人工复核确认精度达到95%以上才把这些样本放入训练集。后续每次规则更新都会自动沉淀一批新样本标注成本几乎为零。这个思路其实很朴素规则是最确定的先验知识用小模型把规则的泛化能力扩展开比人肉写几万条正则靠谱得多。3. 第二层小模型层TextCNN在CPU上做意图分类3.1 为什么不直接选BERT系列小模型层的选型我们在FastText、TextCNN、BERT小模型之间纠结过。最终选了TextCNN主要考虑三个因素。第一是推理速度。线上环境我们用的是普通CPU服务器没有给这个小模型单独上GPU。TextCNN在这种环境下单条推理只需要2到5毫秒FastText更快但在语义理解上稍弱。第二是训练和维护成本。BERT系列即使是小模型也需要GPU训练、需要更复杂的微调和蒸馏流程对小团队来说太重了。TextCNN在一张普通的T4上训练半小时就能收敛迭代节奏可以快到一天一版。第三是场景适配。电商客服消息普遍比较短大部分在20个字以内这类短文本恰恰是CNN的舒适区。它通过卷积核提取局部n-gram特征能捕捉到“不退款”和“退款不”这类关键语序差异应付客服意图分类足够了。FastText不是不能用只是它对词序不敏感遇到“我不想要了要退款”和“退款我不想要了”这种语义相近但词序不同的句子FastText容易学不到。TextCNN的局部卷积对这个问题有明显改善。3.2 TextCNN的训练数据怎么来训练集由三部分构成按比例混合规则层伪标注样本占比约60%。这是基础盘量最大。人工标注样本占比约20%。主要覆盖规则层没有覆盖到的长尾表达每周从线上抽样让运营同学标注几百条。线上bad case回流样本占比约20%。后面会详细讲回流机制。每条样本格式很简单用户的一条消息文本加一个意图标签。需要注意一条消息如果有多个意图我们默认取“主意图”作为标签。多意图问题单独走LLM层不在小模型这里处理。数据预处理上我们做了几个动作。一是清理无意义符号但保留表情符号周边的文本比如“老板在吗”里的表情对判断情绪有用。二是对口语化表达做词典归一比如“木有”归一成“没有”“咋还不发”归一成“怎么还不发”。三是切词中文用jieba但字级别特征也会保留一部分原因是电商口语里很多新词和错别字字级别能兜底。3.3 模型结构与训练要点我们的TextCNN结构非常经典不搞花活。核心参数如下import torch import torch.nn as nn class TextCNN(nn.Module): def __init__(self, vocab_size, embedding_dim128, filter_sizes(2, 3, 4), num_filters256, num_classes11): super().__init__() self.embedding nn.Embedding(vocab_size, embedding_dim, padding_idx0) self.convs nn.ModuleList([ nn.Conv1d(embedding_dim, num_filters, kernel_sizesize) for size in filter_sizes ]) self.dropout nn.Dropout(0.5) self.fc nn.Linear(len(filter_sizes) * num_filters, num_classes) def forward(self, x): x self.embedding(x) # [batch, seq_len, emb] x x.transpose(1, 2) # [batch, emb, seq_len] pooled [] for conv in self.convs: c torch.relu(conv(x)) # [batch, filters, seq_len - k 1] p torch.max_pool1d(c, c.size(2)).squeeze(2) pooled.append(p) out torch.cat(pooled, dim1) out self.dropout(out) return self.fc(out)词表大小5万左右pad到固定长度32因为客服消息超过32个字的比例不高。embedding用随机初始化没有用预训练向量因为数据量足够大之后随机初始化训练出来的效果不差还省去加载预训练模型的部署体积。训练时用带权重的交叉熵损失因为refund和track_order这类请求占比高complaint这类请求占比低不处理类别不均衡的话模型会对高频类过拟合把投诉误判成查物流。类别的权重可以按出现频率的倒数来设置。训练5个epochbatch size 64学习率1e-3用Adam优化器。验证集准确率一般能到93%到95%。之后导出ONNX格式部署Python端用onnxruntime加载兼容性很好。3.4 置信度阈值和OOD样本放行小模型层输出的不是意图本身而是一个概率分布。我们不会直接取argmax作为最终结果而是看最高置信度落在哪个区间。我们的阈值设定如下最高概率大于等于0.85直接采用该意图。最高概率在0.55到0.85之间进入“犹豫带”不直接下结论而是把top2候选意图交给LLM层让LLM从两个候选中选一个。这样能显著降低LLM的自由发挥空间准确率更高。最高概率小于0.55模型对输入完全没有把握大概率是OODout-of-distribution样本也就是训练分布之外的新表达。此时也交给LLM层但LLM面对的是全量意图列表而不是top2候选。这里还有一个细节小模型判断为“other”时我们不会直接返回other而是先检查概率。如果other的概率也不高说明是其他类别的边缘样本同样优先给LLM。只有小模型高置信度地判断为other我们才相信它不是任何已知意图。4. 第三层LLM层只在长尾语义里出场4.1 哪些请求注定要落到LLMLLM层的定位是兜底但“兜底”二字的边界需要明确。我总结了三类必须落到LLM层的请求。第一类是语义含蓄的表达。比如“你们这个也太慢了吧我都能走到你们仓库去拿了”这句话没有出现“快递”“发货”等关键词但真实意图是催发货还带点不满。规则层和小模型很难理解这种反讽LLM可以。第二类是双重甚至多重意图。比如“我上周买的那个数据线到现在还在揽收客服能帮我改一下地址吗”这里既有查物流又有改地址且明显改地址才是主意图。文本分类模型默认是单标签输出处理多意图容易漏。LLM能识别出主次意图。第三类是带上下文依赖的请求。比如用户上一句问了商品参数这一句说“那这个呢”单看当前消息完全无法判断。规则层和小模型只看单条文本而LLM层可以把最近两轮对话拼进prompt里做理解。这三类请求占比可能只有5%但恰恰是最影响用户体验的5%。前面的层判断错了用户会觉得这个机器人很蠢LLM把这部分接住整体体验就上了一个档次。4.2 Prompt设计与输出约束LLM层用的系统提示词我迭代了很多版目前看起来比较稳的版本大概是这样的你是电商客服意图识别器。请判断用户最新一条消息最可能的意图。 可选意图 - track_order: 查物流、催发货 - modify_address: 修改收货地址 - refund: 申请退款 - after_sale: 退换货、维修 - invoice: 发票问题 - product_inquiry: 商品咨询、规格、库存 - price_discount: 价格、优惠券、活动 - complaint: 投诉、强烈不满 - human_service: 要求转人工 - chitchat: 闲聊、与购物无关 - other: 以上都不匹配 规则 1. 只输出JSON不要输出任何解释。 2. 格式{intent: ..., confidence: 0.0, reason: 一句话判断理由} 3. 如果用户明确要求转人工intent必须为human_service。 4. 如果消息包含多个意图选择用户最想让客服执行的意图。 5. confidence低于0.6时intent设为other。 示例 用户麻烦看看我的快递到哪了 输出{intent: track_order, confidence: 0.98, reason: 用户明确询问快递位置} 用户这个衣服我要退货 输出{intent: after_sale, confidence: 0.95, reason: 用户表示退货意愿} 用户最新消息{user_message}开发者需要设置response_format{type: json_object}之类的参数前提是你用的模型服务支持结构化输出。如果不支持就在规则里强调只输出JSON然后在代码里做强解析。4.3 模型选型、成本与优化的取舍LLM层的模型选型核心是在效果、成本和延迟之间找平衡。我们试过好几家主流模型最终长期用的是中型规模的API模型而不是最大最强的版本。原因很简单意图识别这个任务对模型的“理解深度”要求没有那么极端反而对输出格式稳定、延迟低、价格可控有更高要求。中等规模的模型在精心设计的prompt下准确率和强模型差距不大但单次调用成本可能只有强模型的五分之一。成本控制可以算一笔账。假设每天10万条请求目标是LLM层只承担5%也就是5000条。每条消息的输入输出token平均约800个模型单价按当时的市场价格粗算每天LLM成本大约在十元左右量级。如果全部请求都走大模型每天成本要高出两个数量级。这就是混合架构的意义。延迟方面我们给LLM调用设置了2秒超时和异步降级。如果2秒内没返回系统不会继续傻等而是直接转人工兜底。客服场景宁可让真人来接也不要让用户干等。4.4 LLM幻觉怎么防枚举校验与失败兜底LLM在这类任务上有一个特别常见的毛病不按枚举输出。比如我们在prompt里给定了11个意图它有可能会自作主张输出一个“refund_status”之类的新标签这在语义上似乎合理但我们下游业务流程根本没有这个分支一旦冒出来就会挂掉。我们的解决办法是三层校验。第一层是枚举校验代码解析LLM输出的JSON后检查intent字段是否在候选意图集合里。不在就直接视为无效输出触发后续兜底逻辑。第二层是置信度校验LLM输出的confidence如果低于0.6我们同样不采用就算它选了一个看起来很合理的意图也要转人工。第三层是业务规则校验比如LLM判断为refund但用户消息里完全没有退款、退货、不想要这类的语义那就算环境概率再高也会被拦住。这一步相当于业务知识的最后一道保险。兜底链路是LLM输出无效降级返回小模型置信度最高的候选如果小模型也不靠谱再降级进人工队列。总之宁可多花人工成本也不能给出一个错误意图让下游流程执行离谱操作。5. 调度与数据流三个层怎么握手才不出乱子5.1 调度主线优先级加置信度的握手流程三层架构不是简单的“规则→小模型→LLM”顺序执行那样的话每一层都要跑一遍延迟和成本都是浪费。我们的调度主线是按优先级加置信度来做“短路”判断的。伪代码大概是这样的def recognize_intent(user_message, session_contextNone): # 1. 规则层先命中 rule_result rule_engine.match(user_message) if rule_result.is_high_priority: # 转人工、投诉这类高风险直接短路 return rule_result.intent, rule, 1.0 # 2. 规则弱命中规则给了候选但需要小模型复核 if rule_result.is_weak_match: small_prob small_model.predict_proba(user_message) # 如果小模型和规则意见一致直接返回不一致则进入犹豫带 if small_prob.argmax() rule_result.intent and small_prob.max() 0.6: return rule_result.intent, rulesmall, small_prob.max() # 否则走犹豫带逻辑 # 3. 小模型正常预测 small_prob small_model.predict_proba(user_message) max_prob small_prob.max() if max_prob 0.85: return small_prob.argmax(), small, max_prob if 0.55 max_prob 0.85: top2 small_prob.argsort()[-2:][::-1] llm_intent llm_choose_from_candidates( user_message, candidatestop2, contextsession_context ) return llm_intent, llm_select, max_prob if max_prob 0.55: llm_intent llm_classify_full( user_message, contextsession_context ) return llm_intent, llm_classify, max_prob你可能会问为什么规则层已经弱命中了还要小模型复核因为弱正则的误伤率不低如果只用规则判断某些语句会错误进入业务流程。让小模型复核一次成本几乎可以忽略但准确率能拉回来不少。5.2 双重意图与上下文问题怎么处理前面提到双重意图最好交给LLM在调度上要有对应逻辑。小模型输出的是单标签分布它无法告诉你“用户可能同时想查物流和改地址”。所以我们做了一个轻量检测当规则层同时命中两个以上不同意图的强规则时直接跳过小模型层进入LLM层。比如一条消息同时包含“快递到哪了”和“改地址”规则层会同时命中track_order和modify_address我们就知道这是多意图请求让小模型去硬选一个没有意义直接交给LLM做主次判断。上下文问题也是类似。我们的调度器会维护一个会话状态当用户当前消息很短比如“那这个呢”“还能改吗”就会携带最近两轮对话一起拼进LLM的prompt。小模型只处理当前消息不处理上下文。这里有一个成本控制策略并不是所有消息都带上下文只有当小模型置信度低、或者消息本身非常短时才把上下文拼接给LLM。因为多传一轮对话token数量可能翻倍成本也要翻倍。能用当前消息判断的就不要浪费token。5.3 降级策略LLM超时或限流时怎么办线上跑久了你会发现LLM API不可能永远稳定。白天高峰期经常有超时、限流甚至偶发5xx错误。调度模块必须考虑降级。我们的降级逻辑是这样的LLM状态降级策略正常返回且校验通过使用LLM结果超时超过2秒返回小模型置信度最高的意图不再等待返回格式无法解析尝试重新解析一次仍失败则用小模型结果枚举校验不过直接使用小模型结果API限流当前请求走小模型结果同时触发限流保护后续几分钟减少进入LLM的比例降级的核心原则是不阻塞、不无限重试。LLM只是三层中的一层它挂了不能影响整个系统。在我们看来小模型的答案虽然可能不如LLM聪明但至少是稳定的、可预期的比超时无响应强得多。5.4 线上效果要盯哪些指标架构上线后除了关注整体准确率我还会盯一组分层指标这样才能知道每一层干得怎么样。规则层覆盖率规则层直接命中的流量占比目标40%到60%。如果低于这个数说明规则词典需要补充。小模型层直接采用率小模型高置信度直接返回的流量占比目标30%到40%。这个比例能反映训练数据有没有覆盖住主流表达。LLM层调用率目标5%以内。如果超过10%要么是前两层没优化好要么是线上出现了大量新表达要警惕成本。人工介入率最终转人工的占比。这个指标比准确率更有业务意义因为它直接关系到客服团队的工作量。分层bad case数量每周抽检每层的结果记录误判数量和类型。这些指标我们通过日志系统实时统计每天出一份报表。看到LLM调用率异常上升多半是线上有大促活动用户表达开始出现新变化这时候就需要快速补充规则和训练数据。6. 线上迭代闭环每一层的bad case都有自己的修法6.1 三个层各自的bad case长什么样三层架构有个好处任何一个bad case出现后你能很清楚地知道是谁的锅然后对症下药。规则层的典型bad case是过度匹配。比如“你们的发货地址是在上海吗”被track_order的弱规则命中实际上用户在问仓库位置。修法很直接给这条规则加排除词“地址”“在哪”或者把这条规则从强规则降为弱规则让小模型去复核。小模型层的典型bad case是语义混淆。比如“这个订单我不想要了”和“这个订单我没收到”前者是refund后者是track_order如果文本太短、上下文不足小模型很容易混淆。修法是把这类bad case加入训练集让模型在下一次训练时记住这个教训。LLM层的典型bad case是过度解读。比如用户说“你可真行啊”本来可能是吐槽也可能反讽LLM经常会把这种话判成complaint但实际上很多用户只是口头禅。修法是调整prompt在示例中补充类似表达并强调“不要过度推断情绪”。6.2 小模型数据回流别把LLM的错误蒸馏给小模型每周我们会从线上日志里抽取一批LLM层高置信度的结果把它们作为小模型的训练样本回流。这个操作本质上是在“蒸馏”LLM的能力但一定要小心LLM也会犯错。我们的回流流程有一个人工确认步骤。运营同学会对抽样的500条LLM结果做快速标注确认只把确认正确的样本放进训练集。如果这个步骤省掉LLM的系统性错误会被小模型学走而且小模型会把错误泛化得更远最后三层一起错问题会被放大。另外回流的样本不是简单追加到训练集就完事还要做去重和分布控制。如果连续两周线上大量出现“仅退款”相关请求而这些样本在训练集中占比过高模型就会偏向refund导致其他意图误判率上升。我们一般把每周新增回流样本控制在总训练集增量的20%以内避免数据分布被带偏。6.3 一周一次的快节奏迭代这套架构上线后我们的迭代节奏是每周一次。周一到周二运营同学抽检线上bad case标记出典型问题。 周三算法更新规则层词典和正则同时把确认过的bad case加入小模型训练集重新训练和评估。 周四如果有必要更新LLM层的prompt用一组固定测试集做回归验证确保改动没有让其他意图变差。 周五灰度发布先放5%流量观察指标稳定后全量。这个节奏比纯LLM方案的prompt迭代要快很多因为大部分bad case都能在规则层或小模型层快速修复不需要每次都在prompt上反复试探。而规则层的修改是可以精确控制影响范围的不像改prompt那样可能牵一发动全身。6.4 一个容易被忽略的细节版本回溯线上跑久了你一定会遇到“这次优化把原本对的搞错了”的情况。所以每一层的规则、模型、prompt都要版本化管理。模型文件用版本号命名规则词典放配置中心prompt存Git。每次发布都在日志里记录当时的版本组合。这样一旦线上指标异常可以快速对比是哪个版本的变化导致的一键回滚到上一个稳定版本。我之前有一次更新了LLM的prompt加了几个示例后整体准确率提升了但“投诉”意图的召回率明显下降。如果没有版本回溯机制光靠肉眼很难定位是prompt改动导致的。后来我们建立了标准的回归测试集每次改版都跑一遍所有意图的准确率和召回率这种问题就能在发布前发现。三层混合架构相比纯大模型方案真正的优势不在于某一层有多强而在于每一层都有清晰的边界和修复手段。规则层错了改规则小模型错了加数据LLM错了调prompt问题永远能在最合适的位置解决而不是每次都要拿大模型从头试到尾。如果你现在也在做类似的客服意图识别系统我建议你从这套思路出发做一下小规模验证先用规则层加一个小模型跑起来再逐步加入LLM兜底。它可能不是最炫的方案但一定是能长期稳定跑下去、还让运营成本可控的方案。
