1. 内容整体设计与思路拆解1.1 为什么客服意图识别这么难搞做电商客服系统的朋友应该都有体会意图识别这个环节看着不起眼实际做起来特别容易翻车。用户进线之后问的第一句话往往就决定了这次会话的走向是转人工、推优惠券、发物流单号还是引导退货流程全都靠这一步。但用户的话术实在太野了同一个意思能给你变出十几种说法今天问“什么时候到”明天问“货发了吗”后天直接来一句“我的东西呢”你要是不做点针对性的处理光靠单一模型很难兜住这些五花八门的表达。我在早期做客服系统的时 候最开始只用了一个基于BERT的小模型来做分类准确率看上去还行上线之后才发现问题一堆。常见问题倒是认得很准可一旦遇到低频说法、拼写错误、中英文混搭、方言口语分类结果就开始飘了。后来我复盘了一下数据发现用户进线消息里大概有30%到40%的表述都不在训练数据分布里这部分如果处理不好客服机器人的体验就会变得非常机械。所以后来我在项目里换了一套思路把意图识别拆成三层来搞。第一层用规则做兜底和拦截第二层用小模型做常见意图的主分类第三层用LLM做疑难杂症和上下文相关的判断。这套架构跑下来整体效果比单一模型稳定得多尤其是在长尾表达处理上提升非常明显。1.2 三层架构不是叠罗汉而是各管一段很多同学一听到“混合架构”第一反应是把规则、小模型、LLM串在一起跑先走规则规则不中走小模型小模型不中再走LLM。这种串联方式不是不行但会有一个很大的隐患——延迟和成本不可控。因为最坏情况下每一条消息都要走完三层而LLM那层的响应时间和调用成本摆在那里如果量大的话根本扛不住。我在这套方案里做的第一件事是把“分层判断”改成“分流处理”。规则层不只是用来做兜底它还承担了相当一部分的流量拦截。凡是规则能明确判定的意图就直接出结果根本不给下游模型增加负担。小模型层处理的是规则不好描述但常见度高的意图比如“查物流”“申请退款”“改地址”这类高频场景。而LLM层只在两种情况下才会被调用一是规则和小模型的置信度都低于阈值二是需要结合对话历史才能判断用户意图的场景。这样设计的好处是三个模块各管一段互不拖累。规则层跑得快单条判断成本几乎为零小模型层处理的是高频场景训练和推理成本都可控LLM层虽然贵但只处理边缘Case总体调用量被压到很低。实测下来整个系统里LLM的调用量大概只占所有消息量的8%到12%成本完全在可接受范围内。1.3 这方案适合谁不适合谁这套三层混合架构比较适合处理量大、意图类别多、话术变化多的客服场景。如果你在做的是垂直领域的客服机器人比如电商、外卖、出行、教育行业用户进线诉求相对集中但又经常出现说法多变的情况这套架构能给你省不少事。反过来如果你的业务场景意图类别非常固定用户表达也比较标准比如工单系统、表单提交类应用那直接用一个小模型分类就足够了搞三层架构反而有点过度设计。另外如果你的调用量特别小一天就几百条消息直接全部走LLM也不会贵到哪里去没必要为了分层而分层。2. 核心细节解析与实操要点2.1 规则层别小看关键词和正则的组合规则层是整个架构里最不被重视、但实际最出效果的一环。很多人一听“规则”两个字觉得就是写几个关键词匹配太Low了。但实际上规则层的设计质量直接决定了后续模型层的压力大小写得好能拦下50%以上的常见问题写得烂就只能做做空转拦截。我常用的规则手段有三类。第一是关键词精确匹配适用于那些意图信号特别强的词比如“退货”“退款”“投诉”这类出现基本就能确定意图。第二是正则表达式适用于有明确格式特征的输入比如订单号、手机号、物流单号。第三是组合条件规则把多个条件拼在一起判断比如消息里同时出现“地址”和“改”且前后文有正确的订单信息才判定为修改地址意图。这里有一个关键经验规则层要做的是“高精度拦截”不是“高召回判断”。宁可漏掉一部分让下游模型处理也不能误杀。因为规则一旦判断错后面就没有挽回机会了用户明明是想退货却被规则层判定成“闲聊”体验会非常差。所以我在每条规则上都设置了置信度评分只有命中置信度足够高的规则才会直接出结果模糊命中的规则只做标注继续往下游传。2.2 小模型层分类不是终点特征才是小模型层我用的还是BERT类的预训练模型具体是6层的蒸馏版本精度接近原版但推理速度快很多。很多同学在做小模型的时候容易把注意力全放在分类准确率上忽略了特征质量的问题。实际上小模型层的输出不应该只是一个意图类别ID还应该附带置信度分数和特征向量。置信度分数用来决定是否需要继续走LLM特征向量则可以用于后续的相似问题聚类分析。我在实际项目里会把这两份信息都存下来置信度用于线上路由特征向量用于离线分析用户话术的分布情况。这套数据积累到一定量之后你会发现很多新的意图类别其实是从特征聚类里发现的而不是靠人工拍脑袋定义的。训练数据的构建上我建议不要在原始标注数据上直接训练。先把历史客服会话里已解决的用户首次消息抽出来做一轮预聚类把明显同一个意图但表达不同的句子归到一起然后再人工审核打标。这样出来的训练集覆盖度会好很多模型不容易出现“只认标准说法”的问题。2.3 LLM层提示词工程在这里就是核心逻辑LLM层最大的问题不是模型能力不够而是怎么让它稳定输出、不乱发挥。我的做法是把LLM当成一个“偏分类器”来用而不是让它自由生成回复。具体来说我在提示词里会给出一整套意图列表、每个意图的判定标准、以及边界情况的处理说明让LLM只返回结构化结果比如意图ID和置信度理由。这里有个特别重要的细节LLM的输入不能只看当前这一条用户消息必须把对话历史的摘要一起喂进去。电商客服场景里很多用户是在连续对话中逐步交代清楚诉求的。用户先说“我那个东西不太行”你根本不知道他要干嘛下一句才说“想退了怎么操作”。如果只看当前消息规则和小模型很容易误判成“咨询”但LLM结合了上文之后就能准确判断出这是一个退款意图。LLM层的超参数我也建议做特殊配置temperature调低到0.1到0.2关闭随机性让输出尽量稳定。另外一定要给LLM设定输出格式模板我一般用JSON格式并且在提示词里明确要求不要输出多余内容否则后续解析会有很多坑。3. 实操过程与核心环节实现3.1 整体架构与数据流设计先说一下这套系统的整体数据流。用户进线消息先进入一个统一的预处理模块做文本清洗包括去空白、全半角统一、表情符号处理、URL过滤等。清洗完之后消息进入规则引擎规则引擎返回两部分信息命中的规则列表和置信度。如果最高置信度超过0.9直接返回意图结果流程结束。如果没有命中高置信度规则消息进入小模型推理层。小模型输出意图分布和置信度如果置信度超过0.8直接返回结果流程结束。如果置信度不足消息连同对话摘要一起进入LLM层做最终判断。这套流程里我加了一个降级开关如果LLM接口超时或者调用失败系统会直接用置信度最高的小模型结果作为兜底保证用户体验不受影响。这个降级机制在线上非常重要因为LLM服务毕竟是外部依赖出问题的时候你总不能让人工客服去扛所有流量。3.2 规则引擎的落地实现规则引擎我用的是一套自研的轻量级方案没有引入Drools这类重型规则引擎。原因很简单电商客服领域的意图规则数量通常在几十到一两百条之间逻辑复杂度不高用自研方案反而更灵活便于和Python生态集成。规则的表征形式我用的是JSON配置每条规则包含触发条件、优先级、意图ID、置信度配置。触发条件支持三种类型关键词、正则、表达式组合。# 规则配置示例 rules [ { intent: after_sale_refund, priority: 90, conditions: [ {type: keyword, value: 退款, weight: 0.6}, {type: keyword, value: 退货, weight: 0.5}, {type: regex, value: 不想要|想退了|申请退, weight: 0.4} ], min_score: 0.8 }, { intent: logistics_inquiry, priority: 80, conditions: [ {type: keyword, value: 物流, weight: 0.5}, {type: keyword, value: 发货, weight: 0.4}, {type: regex, value: 到哪|多久到|什么时候到, weight: 0.4} ], min_score: 0.7 } ]规则匹配引擎的核心逻辑是遍历所有规则对每条规则计算加权得分得分通过规则阈值后进入候选集。候选集按优先级排序取最高优先级且得分达标的规则作为最终输出。如果得分达标但和最高分差距过小我会标记为“模糊命中”并直接降级给下游模型处理。这里有个顿悟性的经验分享规则层的正则表达式要格外小心匹配范围过宽的情况。比如你写了一个匹配“什么时候到”的正则会同时命中“快递什么时候到”和“你们什么时候上班”前者是物流意图后者是营业时间咨询。所以我在设计正则时会加上前后文约束尽量让表达式只匹配意图信号最明确的那部分短语。3.3 小模型层的训练与部署小模型部分我用的是HuggingFace上的蒸馏BERT模型具体是distilbert-base-chinese如果你处理的文本里包含大量英文品牌名或SKU编号我建议用bert-base-multilingual-cased对中英混合场景表现更好。训练数据的构建我分了几个步骤。第一步是历史会话挖掘从已解决会话中提取用户首次进线消息大概拿了两万条。第二步是预聚类我用TF-IDF加K-Means做了初步聚类重点观察聚类结果里那些和已有意图类别对不上的簇这些往往是新的意图或者已有意图的新表达方式。第三步是人工标注把聚类结果映射到意图体系里大概两万条数据分给了三个人标注标注一致性做了Kappa系数验证整体在0.85以上。模型训练这块我直接帮大家踩过坑整理几个关键参数from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, TrainingArguments, Trainer ) model_name distilbert-base-chinese num_labels 23 # 意图类别数量 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained( model_name, num_labelsnum_labels ) training_args TrainingArguments( output_dir./intent_model, learning_rate2e-5, per_device_train_batch_size32, per_device_eval_batch_size64, num_train_epochs6, weight_decay0.01, eval_strategyepoch, save_strategyepoch, load_best_model_at_endTrue, metric_for_best_modelf1, )训练的时候有个容易忽略的点类别不均衡问题。客服场景里“查物流”和“退换货”的样本量远远大于“投诉”“开发票”这类低频意图。如果不做处理模型会对高频意图过拟合低频意图召回率很低。我的做法是在损失函数里加类别权重低频类别的权重提高2到3倍另外把低频类别的训练样本做了简单的回译增强。小模型服务部署我用的是FastAPI加ONNX Runtime把蒸馏BERT转成ONNX格式后单条推理延迟大概在8到15毫秒单机可以扛住每秒100次以上的请求完全够用。GPU服务器都不需要8核CPU的机器就能撑住。3.4 LLM层的调用与降级策略LLM层我用的提示词结构给大家看一份实际可用的模板你是一个电商客服系统的意图分类器。请判断用户当前消息属于以下哪个意图 1. logistics_inquiry查询物流、发货时间、配送进度 2. after_sale_refund退换货、退款、售后问题 3. address_modify修改收货地址或联系方式 4. product_inquiry咨询商品信息、规格、库存 5. price_discount询问价格、优惠券、活动折扣 6. complaint投诉、差评、负面情绪反馈 7. human_transfer要求转人工、找人工客服 8. chitchat与业务无关的闲聊 请参考以下对话历史 {conversation_history} 用户当前消息{user_message} 只输出JSON格式不要输出任何其他内容 {intent: 意图ID, confidence: 0.0到1.0之间, reason: 判断理由一句话}这里有个问题要提醒大家LLM的置信度输出不能直接信。大模型的置信度校准往往不够好它可能给出0.9的置信度但实际上是错的。我在项目里会做一层LLM结果的校验逻辑主要是检查输出的意图ID是否在枚举范围内、回传的reason是否和意图ID语义一致同时对已标注样本做定期回归验证确保LLM层的准确率没有悄悄下降。调用策略上我建议给LLM层设置单次和每日的调用预算。单次调用如果超过5秒还没返回就直接走降级逻辑。每日预算用完了就切换成“小模型结果规则结果”的兜底方案。这套策略在双十一这类大促期间特别有用流量暴涨的时候不会因为LLM的限流导致全链路故障。3.5 三层路由的阈值怎么调很多同学拿到这套架构之后最纠结的问题就是每层置信度阈值该设多少我的建议是不要拍脑袋定要用线上数据来调。具体做法是在系统上线初期把所有三层的结果都记录下来包括节点判定、置信度分数、最终路由结果。然后定期抽样做人工复核看那些置信度在0.6到0.9之间的样本到底哪些被判定错了。真实数据会让你很快发现一个规律不同意图的最佳阈值是不一样的。比如“转人工”这个意图用户表达通常很直白规则和小模型都能高置信度命中阈值可以设高一点。而“投诉”这个意图很多用户不会直接说“我要投诉”而是带着情绪描述问题这种情况下规则的置信度天然偏低阈值就要适当放低让LLM层多参与。阈值调整我有一个经验公式先用上线前测试集跑一遍记录每个意图在规则层和小模型层的置信度分布取分布的下四分位数作为初始阈值然后上线观察一周根据误判率微调。这个过程多迭代几轮之后各层的路由比例会达到一个比较稳定的状态。4. 常见问题与排查技巧实录4.1 规则层误杀严重怎么办这是做规则层最容易遇到的头号问题。表现形式是某些用户的正常消息被规则错误拦截判成了完全不相干的意图。我之前遇到一个案例用户问“这个手机壳有蓝色的吗”结果因为“蓝色”命中了一个关于“色差退货”的规则关键词直接被拦成了售后意图。排查这类问题的思路很清晰。第一步把规则引擎的每次命中日志打开记录命中的规则ID和计算得分。第二步把误杀样本收集起来逐条看是关键词太宽泛还是正则写得太松。第三步也是最有效的一步给每条规则加一个“排除词”列表。比如刚才那个案例在“色差退货”规则里排除“有蓝色”“买蓝色”“喜欢蓝色”这类表达问题立刻解决。规则层还有个容易被忽视的问题规则的优先级设置不合理。多个规则可以同时命中一条消息时如果优先级高的规则得分低、优先级低的得分高会导致路由结果不合理。我的解决办法是给规则引擎增加一个“平滑层”逻辑取得分最高的前三条规则做加权融合而不是单纯按优先级取最高分。4.2 小模型对没见过的话术分类错误率高这是小模型的天然短板无法完全避免但可以降到最低。我的做法是建立一套“未知意图采样”机制线上系统把置信度低于0.5的小模型输出全部存下来每天做一次聚类汇总。运营同学每周花十分钟看一下这些聚类结果把那些重复出现的、明显属于某个已有意图但表达比较新颖的样本补充到训练集里。这样跑一个月之后小模型对新话术的适应能力会明显提升。因为训练集里表达多样性越来越丰富模型学到了更多公共特征而不是死记硬背标准表述。另外一个补充手段是做对抗训练把那些小模型容易混淆的样本对抽出来用FGM或PGD做对抗扰动能小幅提升模型鲁棒性。4.3 LLM返回格式不稳定、偶尔解析失败做LLM层的朋友应该都碰到过这个问题明明提示词里要求只返回JSON但它偶尔还是会在JSON前后加一段解释性文字。我的排查经验是通过结构化提示词加后处理兜底双保险。提示词方面我会在所有的示例里都给出“输入输出对”的示范让模型通过few-shot的方式学会输出格式。后处理方面我用了一个容错解析函数把LLM的原始输出先做一次JSON解析失败了就用正则把JSON部分抽出来再解析还不行就按换行符做暴力解析取包含意图ID的那一行。如果解析依然失败这个样例会进入“llm_parse_error”日志桶标记为处理失败并直接走小模型兜底。这样一个星期下来统计解析失败率正常情况下应该在1%以下如果超过这个水平说明提示词结构需要调整。4.4 线上准确率怎么持续监控客服意图识别系统上线不等于结束持续监控比开发更重要。我建议搭建一个基于抽样的监控看板每天对每个意图类别抽样50条已处理消息做人工复核计算出分层准确率。这个指标比整体的准确率更有参考价值因为高频意图的小幅波动可能被淹没在整体数据里。监控看板还要展示一个重要指标LLM分流的准确率是否比小模型高。如果发现某类意图LLM的准确率并没有优势甚至更低就应该调整路由策略让这类意图更多的流量走小模型。这本质上是一个动态优化的过程我基本上每两周会看一次这个分布数据做一轮阈值微调。另外强烈建议大家把样本做长期积累每季度重新训练一次小模型。随着业务发展用户的表达习惯也在变化比如新玩法、新政策出现后一定会产生新的话术模式。定期用线上积累的高置信度样本来做增量训练能让小模型长期保持稳定表现。5. 一些实测中的经验心得5.1 成本和性能到底怎么权衡用这套架构的朋友最关心的就是成本问题。我给你算一笔实际账假设日均消息量10万条规则可以拦截40%小模型处理55%LLM只需要处理剩下的5%也就是5000条。按每条LLM调用消耗约1000到1500个token来计算一天的token消耗量在500万到750万之间按常见模型价格算一天的LLM成本大约在几十块钱到一百多块钱。这个成本对绝大多数电商业务来说完全能接受。相比之下如果全部消息都走LLM日均10万条消息的token消耗量是这方案的20倍成本自然也跟着翻到几千块。所以三层混合架构在规模化场景下的成本优势是非常明显的这也是我一直坚持这套方案的关键原因。5.2 事先就要想清楚的演进方向最后我分享一下这套系统后续可以怎么演进。首先是规则层会逐渐被压缩因为小模型通过持续的数据反馈会变得更强能覆盖更多原本需要规则判断的场景。但规则层不会完全消失一些业务上要求100%精确的硬规则比如政策限制类意图还是要保留规则的实时可控性。其次是LLM层的接入会变得更灵活。目前方案里LLM只做意图分类但下一步完全可以引入Agent能力让LLM在判断意图之后自动完成一些后续动作比如调用查询接口、生成回复话术、判断是否需要转人工。我认识的很多同行已经在做这类扩展效果看起来很不错。还有一个演进方向是多模态意图识别。电商客服里很多用户会发截图比如发一张物流详情截图或商品页面截图这种情况下文本信息不足但图像里包含了很多关键信息。在现有架构上增加一个图像理解模块把截图信息先转成文本摘要再进入意图分类流程能覆盖更多用户场景。这套三层混合架构从设计到落地我前前后后花了大概两个多月中间踩了不少坑但最终跑起来的稳定性让我觉得这些投入都是值得的。如果你也在做客服意图识别方向的系统不妨按照这套思路先搭一个最小可行版本把数据流跑通后再逐步优化每层的效果。尤其是规则层别看它技术含量似乎不高做好的话帮你省下的模型训练成本和线上事故处理成本会非常可观。 电商客服意图识别三层混合架构：规则+小模型+LLM实战拆解
1. 内容整体设计与思路拆解1.1 为什么客服意图识别这么难搞做电商客服系统的朋友应该都有体会意图识别这个环节看着不起眼实际做起来特别容易翻车。用户进线之后问的第一句话往往就决定了这次会话的走向是转人工、推优惠券、发物流单号还是引导退货流程全都靠这一步。但用户的话术实在太野了同一个意思能给你变出十几种说法今天问“什么时候到”明天问“货发了吗”后天直接来一句“我的东西呢”你要是不做点针对性的处理光靠单一模型很难兜住这些五花八门的表达。我在早期做客服系统的时 候最开始只用了一个基于BERT的小模型来做分类准确率看上去还行上线之后才发现问题一堆。常见问题倒是认得很准可一旦遇到低频说法、拼写错误、中英文混搭、方言口语分类结果就开始飘了。后来我复盘了一下数据发现用户进线消息里大概有30%到40%的表述都不在训练数据分布里这部分如果处理不好客服机器人的体验就会变得非常机械。所以后来我在项目里换了一套思路把意图识别拆成三层来搞。第一层用规则做兜底和拦截第二层用小模型做常见意图的主分类第三层用LLM做疑难杂症和上下文相关的判断。这套架构跑下来整体效果比单一模型稳定得多尤其是在长尾表达处理上提升非常明显。1.2 三层架构不是叠罗汉而是各管一段很多同学一听到“混合架构”第一反应是把规则、小模型、LLM串在一起跑先走规则规则不中走小模型小模型不中再走LLM。这种串联方式不是不行但会有一个很大的隐患——延迟和成本不可控。因为最坏情况下每一条消息都要走完三层而LLM那层的响应时间和调用成本摆在那里如果量大的话根本扛不住。我在这套方案里做的第一件事是把“分层判断”改成“分流处理”。规则层不只是用来做兜底它还承担了相当一部分的流量拦截。凡是规则能明确判定的意图就直接出结果根本不给下游模型增加负担。小模型层处理的是规则不好描述但常见度高的意图比如“查物流”“申请退款”“改地址”这类高频场景。而LLM层只在两种情况下才会被调用一是规则和小模型的置信度都低于阈值二是需要结合对话历史才能判断用户意图的场景。这样设计的好处是三个模块各管一段互不拖累。规则层跑得快单条判断成本几乎为零小模型层处理的是高频场景训练和推理成本都可控LLM层虽然贵但只处理边缘Case总体调用量被压到很低。实测下来整个系统里LLM的调用量大概只占所有消息量的8%到12%成本完全在可接受范围内。1.3 这方案适合谁不适合谁这套三层混合架构比较适合处理量大、意图类别多、话术变化多的客服场景。如果你在做的是垂直领域的客服机器人比如电商、外卖、出行、教育行业用户进线诉求相对集中但又经常出现说法多变的情况这套架构能给你省不少事。反过来如果你的业务场景意图类别非常固定用户表达也比较标准比如工单系统、表单提交类应用那直接用一个小模型分类就足够了搞三层架构反而有点过度设计。另外如果你的调用量特别小一天就几百条消息直接全部走LLM也不会贵到哪里去没必要为了分层而分层。2. 核心细节解析与实操要点2.1 规则层别小看关键词和正则的组合规则层是整个架构里最不被重视、但实际最出效果的一环。很多人一听“规则”两个字觉得就是写几个关键词匹配太Low了。但实际上规则层的设计质量直接决定了后续模型层的压力大小写得好能拦下50%以上的常见问题写得烂就只能做做空转拦截。我常用的规则手段有三类。第一是关键词精确匹配适用于那些意图信号特别强的词比如“退货”“退款”“投诉”这类出现基本就能确定意图。第二是正则表达式适用于有明确格式特征的输入比如订单号、手机号、物流单号。第三是组合条件规则把多个条件拼在一起判断比如消息里同时出现“地址”和“改”且前后文有正确的订单信息才判定为修改地址意图。这里有一个关键经验规则层要做的是“高精度拦截”不是“高召回判断”。宁可漏掉一部分让下游模型处理也不能误杀。因为规则一旦判断错后面就没有挽回机会了用户明明是想退货却被规则层判定成“闲聊”体验会非常差。所以我在每条规则上都设置了置信度评分只有命中置信度足够高的规则才会直接出结果模糊命中的规则只做标注继续往下游传。2.2 小模型层分类不是终点特征才是小模型层我用的还是BERT类的预训练模型具体是6层的蒸馏版本精度接近原版但推理速度快很多。很多同学在做小模型的时候容易把注意力全放在分类准确率上忽略了特征质量的问题。实际上小模型层的输出不应该只是一个意图类别ID还应该附带置信度分数和特征向量。置信度分数用来决定是否需要继续走LLM特征向量则可以用于后续的相似问题聚类分析。我在实际项目里会把这两份信息都存下来置信度用于线上路由特征向量用于离线分析用户话术的分布情况。这套数据积累到一定量之后你会发现很多新的意图类别其实是从特征聚类里发现的而不是靠人工拍脑袋定义的。训练数据的构建上我建议不要在原始标注数据上直接训练。先把历史客服会话里已解决的用户首次消息抽出来做一轮预聚类把明显同一个意图但表达不同的句子归到一起然后再人工审核打标。这样出来的训练集覆盖度会好很多模型不容易出现“只认标准说法”的问题。2.3 LLM层提示词工程在这里就是核心逻辑LLM层最大的问题不是模型能力不够而是怎么让它稳定输出、不乱发挥。我的做法是把LLM当成一个“偏分类器”来用而不是让它自由生成回复。具体来说我在提示词里会给出一整套意图列表、每个意图的判定标准、以及边界情况的处理说明让LLM只返回结构化结果比如意图ID和置信度理由。这里有个特别重要的细节LLM的输入不能只看当前这一条用户消息必须把对话历史的摘要一起喂进去。电商客服场景里很多用户是在连续对话中逐步交代清楚诉求的。用户先说“我那个东西不太行”你根本不知道他要干嘛下一句才说“想退了怎么操作”。如果只看当前消息规则和小模型很容易误判成“咨询”但LLM结合了上文之后就能准确判断出这是一个退款意图。LLM层的超参数我也建议做特殊配置temperature调低到0.1到0.2关闭随机性让输出尽量稳定。另外一定要给LLM设定输出格式模板我一般用JSON格式并且在提示词里明确要求不要输出多余内容否则后续解析会有很多坑。3. 实操过程与核心环节实现3.1 整体架构与数据流设计先说一下这套系统的整体数据流。用户进线消息先进入一个统一的预处理模块做文本清洗包括去空白、全半角统一、表情符号处理、URL过滤等。清洗完之后消息进入规则引擎规则引擎返回两部分信息命中的规则列表和置信度。如果最高置信度超过0.9直接返回意图结果流程结束。如果没有命中高置信度规则消息进入小模型推理层。小模型输出意图分布和置信度如果置信度超过0.8直接返回结果流程结束。如果置信度不足消息连同对话摘要一起进入LLM层做最终判断。这套流程里我加了一个降级开关如果LLM接口超时或者调用失败系统会直接用置信度最高的小模型结果作为兜底保证用户体验不受影响。这个降级机制在线上非常重要因为LLM服务毕竟是外部依赖出问题的时候你总不能让人工客服去扛所有流量。3.2 规则引擎的落地实现规则引擎我用的是一套自研的轻量级方案没有引入Drools这类重型规则引擎。原因很简单电商客服领域的意图规则数量通常在几十到一两百条之间逻辑复杂度不高用自研方案反而更灵活便于和Python生态集成。规则的表征形式我用的是JSON配置每条规则包含触发条件、优先级、意图ID、置信度配置。触发条件支持三种类型关键词、正则、表达式组合。# 规则配置示例 rules [ { intent: after_sale_refund, priority: 90, conditions: [ {type: keyword, value: 退款, weight: 0.6}, {type: keyword, value: 退货, weight: 0.5}, {type: regex, value: 不想要|想退了|申请退, weight: 0.4} ], min_score: 0.8 }, { intent: logistics_inquiry, priority: 80, conditions: [ {type: keyword, value: 物流, weight: 0.5}, {type: keyword, value: 发货, weight: 0.4}, {type: regex, value: 到哪|多久到|什么时候到, weight: 0.4} ], min_score: 0.7 } ]规则匹配引擎的核心逻辑是遍历所有规则对每条规则计算加权得分得分通过规则阈值后进入候选集。候选集按优先级排序取最高优先级且得分达标的规则作为最终输出。如果得分达标但和最高分差距过小我会标记为“模糊命中”并直接降级给下游模型处理。这里有个顿悟性的经验分享规则层的正则表达式要格外小心匹配范围过宽的情况。比如你写了一个匹配“什么时候到”的正则会同时命中“快递什么时候到”和“你们什么时候上班”前者是物流意图后者是营业时间咨询。所以我在设计正则时会加上前后文约束尽量让表达式只匹配意图信号最明确的那部分短语。3.3 小模型层的训练与部署小模型部分我用的是HuggingFace上的蒸馏BERT模型具体是distilbert-base-chinese如果你处理的文本里包含大量英文品牌名或SKU编号我建议用bert-base-multilingual-cased对中英混合场景表现更好。训练数据的构建我分了几个步骤。第一步是历史会话挖掘从已解决会话中提取用户首次进线消息大概拿了两万条。第二步是预聚类我用TF-IDF加K-Means做了初步聚类重点观察聚类结果里那些和已有意图类别对不上的簇这些往往是新的意图或者已有意图的新表达方式。第三步是人工标注把聚类结果映射到意图体系里大概两万条数据分给了三个人标注标注一致性做了Kappa系数验证整体在0.85以上。模型训练这块我直接帮大家踩过坑整理几个关键参数from transformers import ( AutoTokenizer, AutoModelForSequenceClassification, TrainingArguments, Trainer ) model_name distilbert-base-chinese num_labels 23 # 意图类别数量 tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForSequenceClassification.from_pretrained( model_name, num_labelsnum_labels ) training_args TrainingArguments( output_dir./intent_model, learning_rate2e-5, per_device_train_batch_size32, per_device_eval_batch_size64, num_train_epochs6, weight_decay0.01, eval_strategyepoch, save_strategyepoch, load_best_model_at_endTrue, metric_for_best_modelf1, )训练的时候有个容易忽略的点类别不均衡问题。客服场景里“查物流”和“退换货”的样本量远远大于“投诉”“开发票”这类低频意图。如果不做处理模型会对高频意图过拟合低频意图召回率很低。我的做法是在损失函数里加类别权重低频类别的权重提高2到3倍另外把低频类别的训练样本做了简单的回译增强。小模型服务部署我用的是FastAPI加ONNX Runtime把蒸馏BERT转成ONNX格式后单条推理延迟大概在8到15毫秒单机可以扛住每秒100次以上的请求完全够用。GPU服务器都不需要8核CPU的机器就能撑住。3.4 LLM层的调用与降级策略LLM层我用的提示词结构给大家看一份实际可用的模板你是一个电商客服系统的意图分类器。请判断用户当前消息属于以下哪个意图 1. logistics_inquiry查询物流、发货时间、配送进度 2. after_sale_refund退换货、退款、售后问题 3. address_modify修改收货地址或联系方式 4. product_inquiry咨询商品信息、规格、库存 5. price_discount询问价格、优惠券、活动折扣 6. complaint投诉、差评、负面情绪反馈 7. human_transfer要求转人工、找人工客服 8. chitchat与业务无关的闲聊 请参考以下对话历史 {conversation_history} 用户当前消息{user_message} 只输出JSON格式不要输出任何其他内容 {intent: 意图ID, confidence: 0.0到1.0之间, reason: 判断理由一句话}这里有个问题要提醒大家LLM的置信度输出不能直接信。大模型的置信度校准往往不够好它可能给出0.9的置信度但实际上是错的。我在项目里会做一层LLM结果的校验逻辑主要是检查输出的意图ID是否在枚举范围内、回传的reason是否和意图ID语义一致同时对已标注样本做定期回归验证确保LLM层的准确率没有悄悄下降。调用策略上我建议给LLM层设置单次和每日的调用预算。单次调用如果超过5秒还没返回就直接走降级逻辑。每日预算用完了就切换成“小模型结果规则结果”的兜底方案。这套策略在双十一这类大促期间特别有用流量暴涨的时候不会因为LLM的限流导致全链路故障。3.5 三层路由的阈值怎么调很多同学拿到这套架构之后最纠结的问题就是每层置信度阈值该设多少我的建议是不要拍脑袋定要用线上数据来调。具体做法是在系统上线初期把所有三层的结果都记录下来包括节点判定、置信度分数、最终路由结果。然后定期抽样做人工复核看那些置信度在0.6到0.9之间的样本到底哪些被判定错了。真实数据会让你很快发现一个规律不同意图的最佳阈值是不一样的。比如“转人工”这个意图用户表达通常很直白规则和小模型都能高置信度命中阈值可以设高一点。而“投诉”这个意图很多用户不会直接说“我要投诉”而是带着情绪描述问题这种情况下规则的置信度天然偏低阈值就要适当放低让LLM层多参与。阈值调整我有一个经验公式先用上线前测试集跑一遍记录每个意图在规则层和小模型层的置信度分布取分布的下四分位数作为初始阈值然后上线观察一周根据误判率微调。这个过程多迭代几轮之后各层的路由比例会达到一个比较稳定的状态。4. 常见问题与排查技巧实录4.1 规则层误杀严重怎么办这是做规则层最容易遇到的头号问题。表现形式是某些用户的正常消息被规则错误拦截判成了完全不相干的意图。我之前遇到一个案例用户问“这个手机壳有蓝色的吗”结果因为“蓝色”命中了一个关于“色差退货”的规则关键词直接被拦成了售后意图。排查这类问题的思路很清晰。第一步把规则引擎的每次命中日志打开记录命中的规则ID和计算得分。第二步把误杀样本收集起来逐条看是关键词太宽泛还是正则写得太松。第三步也是最有效的一步给每条规则加一个“排除词”列表。比如刚才那个案例在“色差退货”规则里排除“有蓝色”“买蓝色”“喜欢蓝色”这类表达问题立刻解决。规则层还有个容易被忽视的问题规则的优先级设置不合理。多个规则可以同时命中一条消息时如果优先级高的规则得分低、优先级低的得分高会导致路由结果不合理。我的解决办法是给规则引擎增加一个“平滑层”逻辑取得分最高的前三条规则做加权融合而不是单纯按优先级取最高分。4.2 小模型对没见过的话术分类错误率高这是小模型的天然短板无法完全避免但可以降到最低。我的做法是建立一套“未知意图采样”机制线上系统把置信度低于0.5的小模型输出全部存下来每天做一次聚类汇总。运营同学每周花十分钟看一下这些聚类结果把那些重复出现的、明显属于某个已有意图但表达比较新颖的样本补充到训练集里。这样跑一个月之后小模型对新话术的适应能力会明显提升。因为训练集里表达多样性越来越丰富模型学到了更多公共特征而不是死记硬背标准表述。另外一个补充手段是做对抗训练把那些小模型容易混淆的样本对抽出来用FGM或PGD做对抗扰动能小幅提升模型鲁棒性。4.3 LLM返回格式不稳定、偶尔解析失败做LLM层的朋友应该都碰到过这个问题明明提示词里要求只返回JSON但它偶尔还是会在JSON前后加一段解释性文字。我的排查经验是通过结构化提示词加后处理兜底双保险。提示词方面我会在所有的示例里都给出“输入输出对”的示范让模型通过few-shot的方式学会输出格式。后处理方面我用了一个容错解析函数把LLM的原始输出先做一次JSON解析失败了就用正则把JSON部分抽出来再解析还不行就按换行符做暴力解析取包含意图ID的那一行。如果解析依然失败这个样例会进入“llm_parse_error”日志桶标记为处理失败并直接走小模型兜底。这样一个星期下来统计解析失败率正常情况下应该在1%以下如果超过这个水平说明提示词结构需要调整。4.4 线上准确率怎么持续监控客服意图识别系统上线不等于结束持续监控比开发更重要。我建议搭建一个基于抽样的监控看板每天对每个意图类别抽样50条已处理消息做人工复核计算出分层准确率。这个指标比整体的准确率更有参考价值因为高频意图的小幅波动可能被淹没在整体数据里。监控看板还要展示一个重要指标LLM分流的准确率是否比小模型高。如果发现某类意图LLM的准确率并没有优势甚至更低就应该调整路由策略让这类意图更多的流量走小模型。这本质上是一个动态优化的过程我基本上每两周会看一次这个分布数据做一轮阈值微调。另外强烈建议大家把样本做长期积累每季度重新训练一次小模型。随着业务发展用户的表达习惯也在变化比如新玩法、新政策出现后一定会产生新的话术模式。定期用线上积累的高置信度样本来做增量训练能让小模型长期保持稳定表现。5. 一些实测中的经验心得5.1 成本和性能到底怎么权衡用这套架构的朋友最关心的就是成本问题。我给你算一笔实际账假设日均消息量10万条规则可以拦截40%小模型处理55%LLM只需要处理剩下的5%也就是5000条。按每条LLM调用消耗约1000到1500个token来计算一天的token消耗量在500万到750万之间按常见模型价格算一天的LLM成本大约在几十块钱到一百多块钱。这个成本对绝大多数电商业务来说完全能接受。相比之下如果全部消息都走LLM日均10万条消息的token消耗量是这方案的20倍成本自然也跟着翻到几千块。所以三层混合架构在规模化场景下的成本优势是非常明显的这也是我一直坚持这套方案的关键原因。5.2 事先就要想清楚的演进方向最后我分享一下这套系统后续可以怎么演进。首先是规则层会逐渐被压缩因为小模型通过持续的数据反馈会变得更强能覆盖更多原本需要规则判断的场景。但规则层不会完全消失一些业务上要求100%精确的硬规则比如政策限制类意图还是要保留规则的实时可控性。其次是LLM层的接入会变得更灵活。目前方案里LLM只做意图分类但下一步完全可以引入Agent能力让LLM在判断意图之后自动完成一些后续动作比如调用查询接口、生成回复话术、判断是否需要转人工。我认识的很多同行已经在做这类扩展效果看起来很不错。还有一个演进方向是多模态意图识别。电商客服里很多用户会发截图比如发一张物流详情截图或商品页面截图这种情况下文本信息不足但图像里包含了很多关键信息。在现有架构上增加一个图像理解模块把截图信息先转成文本摘要再进入意图分类流程能覆盖更多用户场景。这套三层混合架构从设计到落地我前前后后花了大概两个多月中间踩了不少坑但最终跑起来的稳定性让我觉得这些投入都是值得的。如果你也在做客服意图识别方向的系统不妨按照这套思路先搭一个最小可行版本把数据流跑通后再逐步优化每层的效果。尤其是规则层别看它技术含量似乎不高做好的话帮你省下的模型训练成本和线上事故处理成本会非常可观。