电商客服意图识别实战规则小模型LLM三层混合架构详解聊意图识别之前先讲个真实场景。我接手过一个电商客服项目日均消息量在十万级用户进来第一句话大概率是“在吗”“发货没”“怎么退”“有优惠吗”——就这几板斧。一开始团队拍脑袋想直接用大模型说效果好、泛化强结果一算账十万日活消息每轮调用最快也要三百毫秒单条成本虽然看着不贵但叠加并发高峰和上下文重复处理一个月账单直接超出预期。更麻烦的是延迟用户问一句“发货没”等两秒才弹答案情绪马上就上来了。后来我们换了一套思路把意图识别拆成三层规则层打底、小模型做主路、大模型兜底也就是常说的“规则小模型LLM三层混合架构”效果立竿见影——P99延迟从一千二降到两百毫秒以内单条调用成本降了九成以上准确率还稳中有升。这篇文章就把这套架构从设计到落地的完整过程盘一遍重点讲清楚每层该放什么、不该放什么以及那些不踩一遍根本不知道的坑。这套方案适合谁如果你在做客服机器人、工单分派、私域运营、甚至任何涉及文本意图分类的场景只要消息量大、意图种类多、预算有限都可以直接参考这套思路。如果你只是好奇大模型怎么用在实际业务里这篇文章也能回答一个核心问题大模型不是万能的也不是唯一解它只是拼图里的一块。1. 为什么是三层而不是端到端一个大模型1.1 单一大模型在业务场景里的三个真实问题很多人一听到“意图识别”第一反应就是“这不是LLM最擅长的事吗”。确实大模型在理解复杂语义、处理口语化表达上的能力规则和小模型都追不上。但放到真实的电商客服场景里只靠大模型会撞上三堵墙。第一堵墙是延迟。电商客服对响应速度的要求其实非常苛刻用户发完消息超过1秒没动静很多人就会重复发或者直接转人工。而大模型生成式响应天生是慢的即使只是做一次意图分类带着整段历史上下文去调一次接口往返时间也在几百毫秒到一两秒之间。当并发量一起来排队等待更会让延迟不可控。第二堵墙是成本。别只看单次调用的token价格真实业务里要跑通一条完整的对话链路往往不止调一次模型。意图识别要调一次识别完还要触发后续的回答生成又要调一次。一个十万级日活的场景按每条消息两三次调用算一个月下来是一笔相当可观的账单。而且随着业务量增长这个数字还会线性往上走。第三堵墙是稳定性。大模型有一个很要命的问题不稳定。同样的输入上午可能返回“退款”下午可能返回“退货退款”两次都算对了但格式不一样下游逻辑处理起来就麻烦。更不用说幻觉问题——模型把语义理解偏了会得出一个逻辑自洽但完全错误的分类结果这种错误在客服场景里往往会造成用户投诉。1.2 三类技术的边界条件对比与其争论“哪个模型最强”不如老老实实承认规则、小模型、大模型各有自己的舒适区根本不存在谁替代谁的问题。我习惯用一个比喻规则层是值班保安小模型层是前台接待大模型是店长。日常问题保安和前台就处理了只有搞不定的疑难杂症才需要店长上。规则层对确定性强的表达最擅长。“发货没”“到哪了”“物流”这些词一出现基本连猜都不用猜。适合做第一道过滤器秒回且零成本。小模型层能处理一定程度的语义变化但只擅长“见过”的表达。通过意图分类或序列标注模型把用户输入映射到一个固定类别集合上。速度快、成本低、稳定可控。大模型层负责复杂、模糊、多轮关联的语义理解。适合做兜底或深层理解比如用户绕了一大圈其实是想要补偿这种“潜台词”小模型很难学会。三层架构的核心逻辑不是技术炫技而是用合适的工具处理合适的问题把最贵的资源留给最少数量的请求。说白了就是让绝大多数简单问题在低层就结束只有少数复杂问题才逐层上报到最贵的模型那里。1.3 三层架构的业务价值不只是省钱算完账你会发现三层架构最大的价值其实不是省钱而是让系统的延迟、成本、准确率变得可预期。规则层是确定性的小模型层是概率性的但可控大模型只负责处置那批“必须上强度”的case。这样每一层的资源消耗都是可估算的不会出现某个月账单突然暴涨的情况。另外还有一个隐藏好处可解释性。如果哪类意图识别效果不好你可以直接从三层里定位问题。规则漏接了就补规则小模型分错了就加样本大模型抽风了就调prompt或者回流badcase。每一层都有针对性的优化方案而不是面对一个黑盒干瞪眼。2. 规则层最廉价也最容易被低估的第一道防线2.1 规则层到底放什么内容规则层的定位是处理高置信度、低语义复杂度、高频出现的意图。它不是用来覆盖全量场景的而是用来做“一刀切”的切得越准越好。放得过多规则之间会互相打架放得过少又起不到分流作用。我一般按三个标准来挑选放进规则层的意图频次高、表达模式固定、误判代价低。拿电商客服场景举例几个典型的规则层选手物流查询命中“发货”“物流”“快递”“到哪了”“多久到”等直接判定为物流意图。退换货命中“退货”“换货”“退款”“七天无理由”等关键词组合。开发票命中“发票”“开票”“抬头”等。人工客服命中“人工”“转人工”“真人”“客服”等直接转接不废话。这里面有个小技巧不要把单个词作为触发条件要尽量用短语或者词组合。比如单看“退”字它可能是“退货”也可能是“不退”但“退货”两个字一起出现基本没跑了。规则层的命中门槛设得高一些宁可不命中交给下层也不要错误命中把用户带跑偏。2.2 规则表达的三种写法实际工程里规则层的实现一般有三种写法从简到繁都有第一是关键词匹配。最直接遍历一段文本看是否包含某个词或短语。实践中常用的是把关键词和同义词扩展成数组比如“快递”“快件”“物流”“包裹”“到哪了”谁先命中谁赢。实现成本最低但需要配合词序和上下文判断不然容易误伤。第二是正则表达式。适合匹配带结构、带模式的表达比如“订单号123456”或“单号是ABC123”这种。正则的优点是精准缺点是写起来费劲、容易漏维护也是噩梦。我一般只在需要匹配强结构化信息时才用比如订单号、手机号、地址。第三是布尔逻辑组合。用AND/OR/NOT组合关键词比如“退款 AND NOT 退款政策”这类过滤逻辑。结合否定词的排除能显著降低误判率。实践中我会在判定“退款”意图时排除“退款政策”“退款到账时间”这种咨询类表达因为它们虽然包含关键词但想要的不是退款操作而是政策说明。2.3 规则层的三个致命误区规则层看着门槛低其实处处是坑。第一个坑是规则爆炸。今天加一个关键词明天加一个同义词规则表越滚越长最后自己都忘了哪条规则在生效。我的建议是每条规则必须带生效时间和添加理由并且定期用线上日志做复盘把半年以上零命中的规则清理掉。第二个坑是误判。规则层是硬匹配一旦触发就跳过后续所有环节如果规则太宽泛很容易把用户导向错误的流程。比如用户发一句“你们的发货速度怎么这么慢”如果只看到“发货”两个字就命中了物流查询那就完全错了——用户显然在抱怨而不是查询。这就是为什么规则层必须设置高门槛关键词至少要组合到“表达确定性很强”才让过。第三个坑是无法自学习。规则是人写的意味着人想不到的表达它永远覆盖不到。同一个意思十个用户有十种说法即使调了半天规则覆盖率也上不去。这也是为什么必须有下一层小模型来兜住规则层做的是“稳准狠”的清除工作不是大而全的覆盖。3. 小模型层整个架构的性价比核心3.1 为什么用小型分类模型而不是继续堆规则当你发现规则层把最简单的那批意图过滤掉之后剩下的流量依然庞大而且表达方式五花八门规则怎么也覆盖不完。这时候就是小模型登场的时机。我在项目里用的方案是意图分类模型输入一段用户文本输出预定义的意图标签。和规则层相比它最大的优势是能泛化同一个意思换十种说法只要训练数据里见过类似表达模型大概率能把它归到正确的类别里。和LLM相比它的优势是快、便宜、稳定固定模型结构和参数输入输出都是定长的推理延迟可以压到几十毫秒单次调用的成本约等于零而且是完全可控的。小模型的定位不是替代规则层而是填补规则层覆盖不到的中间地带。规则层像是精确制导炸弹小模型则是覆盖面积更广的区域火力两者互为补充。3.2 模型选型从FastText到BERT变体选型大概率是大家最关心的部分。直接说结论如果意图数量少比如十个以内、句子结构简单用FastText性价比最高训练快、部署轻、CPU上就能跑得飞快。如果意图数量多几十个、句子表达复杂建议用BERT-small或DistilBERT这类蒸馏过的预训练模型做微调准确率能比FastText高一个数量级。我实际用的是BERT-small中文预训练模型做微调隐藏层只有6层参数量大概是BERT-base的一半不到。在电商客服这个场景里它的准确率已经能到93%以上推理延迟在CPU上用ONNX Runtime跑大概30毫秒完全够用。给你一份比较直观的模型选型参考模型参数量推理延迟CPU准确率相对适用场景FastText~百万级5ms以内基准意图少、句子短、资源极度受限TextCNN~千万级10ms左右比FastText高5%-10%中等规模意图分类部署简单BERT-small~千万级30ms左右比TextCNN高3%-5%意图多、语义复杂、需要泛化BERT-base~亿级100ms比BERT-small高1%-2%对准确率要求极高不差钱注意准确率的提升是边际递减的。从FastText到BERT-small准确率提升明显从BERT-small到BERT-base提升就非常有限了但延迟和显存开销涨上去好几倍。在电商客服这个场景里真的没必要上BERT-base性价比最优解是BERT-small这个级别。3.3 训练数据的坑从标注到清洗小模型的效果七成靠数据三成靠调参。而数据处理这一步恰恰是最多团队翻车的地方。首先是标注标准要统一。多人标注同一个句子可能有人标“退货”有人标“退款”还有人觉得是“售后”。我的做法是写一份标注规范文档把容易混淆的意图边界讲清楚并定期做标注一致性抽检不一致率超过5%就打回重标。这一步看起来繁琐但能省掉后面无数麻烦。其次是类别不平衡问题。电商场景里“物流”意图的数量可能是“投诉”意图的几十倍。如果不做处理模型会学成一个“只会认物流”的偏科生。我的处理方式是先按原始比例训练一版看基线然后用欠采样或过采样把每个类别的样本量拉平再训练最后选择在测试集上表现更好的那版。另外对样本量特别少的意图可以借用LLM做数据增强——让大模型基于现有的少量标注样本改写同义表达生成更多训练数据。再一个坑是数据泄漏。做训练集和测试集切分时一定要按用户而不是按句子切分。同一个用户的几十条消息如果一部分进了训练集、一部分进了测试集模型其实是变相“见过”了测试数据跑出来的准确率会虚高。切分的时候要保证同一用户的所有句子里要么全在训练集要么全在测试集。3.4 模型训练的工程细节训练流程其实很常规但有几个细节值得单独说。第一是文本预处理要克制。很多人习惯上来就做去停用词、繁简转换、标点清洗但BERT这类预训练模型本身对噪声有很强的鲁棒性过度清洗反而会丢掉上下文的语义线索。我实际只做两件事把全角字符转成半角把URL和订单号这种纯结构信息替换成占位符比如“订单号123456”变成“订单号[MASK]”。这样模型学的是“订单号”这个词本身的语义而不被具体的数字干扰。第二是类别数量控制在20个以下。小模型的分类能力是有限的并不是像大模型那样什么都能做。如果你发现意图类别超过30个互相之间还有交叉就要考虑是不是把意图体系设计得太细了——比如“不喜欢”和“不合适”在业务上也许根本不需要区分成两个意图。把意图合并到业务动作可区别的粒度模型压力小效果也更好。第三是置信度阈值必须做校准。分类模型对每个意图都会输出一个概率值你不可能百分之百信任它。我一般设一个0.6的置信度线大于这个值就采用模型结果小于这个值就交给下一层。阈值不是拍脑袋定的是对验证集做概率分布分析后选出来的。原则很简单宁可让模型说“不确定”也好过它强行分一个错的把用户带进错误流程后面要花十倍的精力来挽回。4. LLM层兜底复杂场景的“终审法官”4.1 LLM在所有层里到底负责什么LLM层的定位不是取代规则和小模型而是处理那些前两层搞不定的长尾请求。这些请求的特点是表达绕、隐含意图、多轮关联、需要一定程度的推理。典型场景比如“我上周买的那个蓝色的耳机当时有活动送的赠品到现在还没收到我想问问怎么回事”——这里既有“物流”又带着“投诉”性质小模型大概率会分错。“你们家东西质量也太差了吧我才用两天就坏了你们自己说怎么办”——这句话没有一个明确的关键词但意图是“售后投诉”加“补偿倾向”。“我看直播间里说下单备注会送赠品我怎么没收到啊”——这属于“优惠/赠品咨询”但表达方式和常规咨询差异很大。这类消息占比通常在10%到15%之间但恰恰是这部分决定了客服体验的成色。规则层和小模型追求的是“快”LLM层追求的是“准”和“懂”。4.2 Prompt设计的四条实战经验LLM层本质上是用上下文学习来做少样本分类prompt写得好不好直接决定准确率上限。我踩过很多坑之后总结出四条经验。第一条是给出明确的角色和任务定义。不要只写“对下面的句子做意图分类”要让模型有代入感。我习惯这样开头“你是一名资深的电商客服质检专员负责判断用户的真实意图。用户的输入可能包含抱怨、提问、索要补偿等多种诉求你需要从给定的意图列表中选择最匹配的一个意图。”第二条是意图类别要带定义和示例。不能让模型猜“售后”和“投诉”有什么区别要把每个意图配上一句话解释和两个典型示例。比如“售后用户主动要求处理商品问题包括退款、换货、维修、索要赔偿等。示例‘这个坏了能换吗’‘我要申请退款’”。这一步相当于在做少样本学习示例的质量直接决定模型的理解质量。第三条是要求模型输出结构化结果。我要求模型严格按照固定格式输出比如“{intent: 售后, confidence: high}”并说明如果意图不在列表中就输出“{intent: other, confidence: low}”。输出结构化之后下游代码处理起来就非常顺滑不需要解析一堆自然文本。第四条是把判断依据也问出来。我会在prompt里加一句“请简述你的判断依据不超过20字。”这一步看着多余其实对badcase分析极其有用。当模型分错的时候你能从它的判断依据里看出是prompt写得不够清楚还是这个case本身太模糊。有了判断依据后续优化prompt不是盲人摸象。4.3 成本控制的三个手段很多人担心LLM层成本失控实际上做好三件事就能把它管住。第一是入口控制。只有规则层没命中、小模型置信度又不足的句子才会进到LLM层这一层天然就是少数流量。我实测下来十万条用户消息里能走到LLM层的只有一万条左右。只要把前面的门槛设好LLM层的量级就压住了。第二是输入裁剪。很多case其实不需要带完整的多轮上下文截取当前句加前一轮就足够了。上下文长度直接决定token消耗能塞200字就绝不塞2000字。我在实际中会做一轮“裁剪优先级”设计当前问句 上一轮用户消息 上一轮机器人回复 更早历史。裁到差不多够用就停不为理论上的完整性多花token。第三是缓存和降级。同一个用户用同样的表达反复提问第一次查LLM后面直接缓存结果。另外要预留降级方案当LLM接口超时或出现异常时自动降级到小模型结果哪怕置信度不足也先顶上总比给用户一个错误的好答复要强。线上稳定比单次准确性更重要。4.4 大模型的“幻觉”怎么防即使prompt写得再完美LLM也有概率抽风分出一个明显离谱的结果。我见过最经典的一次用户问“你家怎么发货这么慢”模型竟然分到了“赞美”。为了防止这种离谱结果挡住正确识别我在LLM层后面加了一个结果校验器——一个轻量的关键词过滤器检查模型输出的意图和输入文本之间有没有基本的语义重合。如果完全没有重合直接判定为无效结果。这个校验器不追求找出所有错误只负责拦住最离谱的那一批。它不完美但很实用。5. 三层架构的落地从流程图到工程实现5.1 完整请求链路设计抛开抽象讨论直接看一套生产可用的落地链路。当一个用户消息进来请求会依次经过以下节点数据接入消息进入服务做基础清洗繁简转换、URL替换、字符归一化。规则层判定走规则引擎如果命中高置信度规则直接产出意图结果并结束未命中则进入下一层。小模型层判定调用意图分类模型如果输出概率高于阈值比如0.6直接产出结果低于阈值则进入下一层。LLM层兜底构造prompt包含当前消息、历史上下文、意图列表及示例调用大模型接口获取结构化结果执行结果校验。兜底保护如果LLM超时或校验失败回落到“other”意图走兜底话术或转人工。结果入库无论哪一层命中最终结果都统一写入日志用于后续效果分析和badcase回捞。需要特别强调的是这个链路内部的超时控制。我把每一层的时间预算都设得很严格规则层5毫秒小模型层50毫秒LLM层500毫秒。一旦某层超时立即放弃本层结果要么降级到上一层结果要么直接用兜底方案。绝不能因为一个慢请求让整条链路的用户体验被拖垮。5.2 置信度设计与动态调优三层架构里置信度机制是核心粘合剂。每一层都要输出一个“我有把握吗”的信号这个信号的质量直接决定了整体效果。规则层的置信度由匹配条件决定命中的关键词越多、模式越复杂置信度越高。小模型层用softmax概率值作为置信度。LLM层则通过prompt让模型自己输出confidence等级并结合校验器的检查结果做校准。实操上我建议给每一层都预设一个最低置信度门槛并定期用线上数据做动态调整。比如小模型的0.6阈值如果发现测试集里0.5到0.6区间内有大量正确样本就往下调到0.55如果发现这个区间全是错误样本就往上调到0.65。这个调整过程要和badcase分析配合做它的核心是回答一个问题“我们到底可以多信任这个模型”5.3 兜底策略的三道保险即使有三层架构线上依然会遇到各种没法预料的输入。我准备了三个兜底手段按优先级排第一个是转人工。当所有层的置信度都低或者LLM直接判定为“other”意图时第一时间转人工客服并且在转交记录里附带意图识别链路的信息让人工客服能快速接手。第二个是小模型高置信度强制覆盖。当LLM层超时或校验失败但小模型层置信度在0.4到0.6之间不够单独出结果但也没有明显冲突时我可以选择用小模型结果顶上去。这个策略的前提是下游话术足够通用即使分错也不会出大问题。第三个是通用澄清话术。当确实无法判断意图时机器人会回复一句“抱歉我没太理解您的意思您可以换一种说法吗或者直接回复‘人工’转接人工客服。”这个话术不需要任何模型能力但能有效减少用户重复输入带来的负面体验。三道保险的逻辑是一以贯之的系统不知道答案时不要装作知道更不要让用户承担错误后果。6. 线上踩坑实录四个最常见的问题6.1 规则层误判率飙升根源是规则太宽我们曾经把规则层的关键词做得很宽觉得多匹配一条是一条的赚结果误判率直接翻倍。核心问题是“发票”这个词用户发“发票怎么还不开啊”本意是催促但命中“发票”关键词后被当成“开发票”意图跳到了开票流程。排查之后我们把规则改成短语级别匹配只用“开发票”“开票”“发票抬头”这类完整词组触发误判率才降下来。规则层宁可漏接不要错接漏接了下面还能补救错接了用户直接流失。6.2 小模型训练集切分错误导致指标虚高有一版模型训练完测试集准确率95%上线后直接跌到86%。复盘发现数据切分时按句子随机切同一个用户的多轮对话分散在训练集和测试集里模型在训练的时候已经见过了测试数据的上下文风格导致评估指标严重虚高。后来改成按用户ID做切分准确率的预估值才回归真实水平。6.3 LLM返回格式突变导致解析崩溃大模型接口升级后有一阵连续收到格式不符的返回我们在代码里直接报了空指针异常。后来在解析逻辑里加了对异常情况的捕获同时把解析失败的情况全部降级到小模型结果。这件事给我的教训是大模型的输出格式只能当协议不能当约定下游解析必须有兜底否则它的一次抽风就是你的一次线上事故。6.4 兜底话术被用户吐槽“像机器人”转人工和澄清话术我们一开始写得特别机械——“抱歉我未能理解您的意图请重新描述。”用户反馈极差。后来改成了口语化表达“不好意思刚才没太听明白您能换个说法吗或者回复‘人工’也行我帮你转人工客服。”同一套逻辑体验提升一个档次。技术链路再完善最后面对用户的还是那一句话值得多花一点时间打磨。7. 未来扩展这套架构还能怎么长三层架构不是终点它更像一个成长骨架可以在不改变整体结构的前提下持续扩展。一个明显的方向是从意图识别走向情感识别。把“情感倾向”作为和意图并列的输出比如用户带着愤怒情绪来投诉和心平气和来咨询对应的服务策略应该不同。小模型层可以轻松扩展一个情感分类任务LLM层也可以在prompt里增加情感判断字段。另一个方向是从单轮分类走向多轮会话状态管理。目前这套架构处理的是单条消息的意图但真实客服场景里用户往往要经过多轮对话才把诉求说清楚。可以把每一轮的意图识别结果累加成一个“会话状态”并结合状态决定下一步动作。这个扩展对规则层和小模型层改动不大主要是增加一个状态机层。还有一个值得尝试的方向是用户画像加权。把用户的会员等级、历史订单记录、售后次数等信息作为特征输入理论上可以帮助系统更准确地判断意图强度比如黑钻会员说“我有点不满意”可能比普通用户说“我要投诉”更值得认真对待。这些信息对规则层没有帮助但可以作为小模型层的输入特征或者作为LLM层prompt的一部分。8. 写在最后的实操心得三层架构这套东西理论听起来不复杂真正的难度在于坚持“层与层之间不越界”的原则。规则层就想好怎么把简单问题切干净别跃跃欲试想处理复杂语义小模型层就老老实实提高泛化能力别想着零样本泛化到一切场景LLM层就努力把兜底做稳不要什么都让它来做。每一层把自己那一亩三分地耕好整体效果自然不会差。我实际跑下来的数据是规则层能拦截掉约40%的流量小模型层能处理约50%LLM层负责剩余的10%。每十万条消息真正调用LLM的只有一万条左右这个比例让成本完全在可控范围内。最后再分享一个小技巧。无论你使用哪种模型一定要把badcase回流机制做成自动化。每天定时从线上日志里捞取预测错误样本去重后自动进标注池。每周做一次标注和重训。这个闭环一旦跑起来系统的意图识别准确率会是稳步上升的而不是永远停留在你上线那一刻的水平。很多团队搭好了架构就跑路不管了三个月后效果下滑却怪架构不对其实只是没有让它持续进化而已。电商客服意图识别做到最终拼的从来不是单个模型的智商而是整个系统的工程控制力。希望这篇文章能让你少走一些弯路。