企业官网建设流程全解析

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_labels=num_labels ) training_args = TrainingArguments( output_dir="./intent_model", learning_rate=2e-5, per_device_train_batch_size=32, per_device_eval_batch_size=64, num_train_epochs=6, weight_decay=0.01, eval_strategy="epoch", save_strategy="epoch", load_best_model_at_end=True, metric_for_best_model="f1", )

训练的时候有个容易忽略的点：类别不均衡问题。客服场景里“查物流”和“退换货”的样本量远远大于“投诉”“开发票”这类低频意图。如果不做处理，模型会对高频意图过拟合，低频意图召回率很低。我的做法是在损失函数里加类别权重，低频类别的权重提高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在判断意图之后自动完成一些后续动作，比如调用查询接口、生成回复话术、判断是否需要转人工。我认识的很多同行已经在做这类扩展，效果看起来很不错。

还有一个演进方向是多模态意图识别。电商客服里很多用户会发截图，比如发一张物流详情截图或商品页面截图，这种情况下文本信息不足，但图像里包含了很多关键信息。在现有架构上增加一个图像理解模块，把截图信息先转成文本摘要再进入意图分类流程，能覆盖更多用户场景。

这套三层混合架构从设计到落地，我前前后后花了大概两个多月，中间踩了不少坑，但最终跑起来的稳定性让我觉得这些投入都是值得的。如果你也在做客服意图识别方向的系统，不妨按照这套思路先搭一个最小可行版本，把数据流跑通后再逐步优化每层的效果。尤其是规则层，别看它技术含量似乎不高，做好的话帮你省下的模型训练成本和线上事故处理成本会非常可观。