在企业客服系统中，每天都会产生大量用户咨询、投诉和售后工单。传统做法通常依赖人工客服手动选择分类，例如“退款问题”“物流异常”“账号登录”“发票申请”等。随着业务规模扩大，人工分类会带来三个明显问题：效率低、分类不一致、后续统计不准确。

大模型出现后，很多团队开始尝试用 AI 自动理解工单内容，并给出对应分类。相比传统关键词规则，大模型能更好地理解自然语言，例如用户说“东西还没到，但是页面显示签收了”，模型可以判断为“物流异常 / 虚假签收”，而不是简单匹配“签收”两个字。

本文聚焦一个具体场景：如何使用大模型实现客服工单自动分类，并在实际业务中控制准确率、稳定性和成本。

---

一、为什么客服工单分类适合用大模型？

客服工单分类本质上是文本理解任务。输入是一段用户描述，输出是一个或多个业务标签。

例如：

用户反馈：我昨天申请退款了，到现在钱还没退回来，客服也没人回复。分类结果：售后退款 / 退款进度查询

传统方案一般有三类：

1. 人工分类：准确率较高，但成本高、速度慢；
2. 关键词规则：实现简单，但维护成本高，容易误判；
3. 传统机器学习模型：需要大量标注数据，迁移成本较高。

大模型的优势在于：不需要一开始就准备海量训练数据，通过 Prompt 就能完成初步分类，并且能理解用户口语化表达、错别字和上下文含义。

---

二、先设计标签体系，而不是直接调用模型

很多团队做客服分类时，一上来就把用户问题丢给大模型，让它自由输出分类。这种做法很容易导致结果不可控，比如同一个问题今天输出“退款问题”，明天输出“售后退款”，后天又变成“退款咨询”。

因此，第一步应该是设计稳定的标签体系。

一个常见的二级分类结构如下：

订单问题  - 订单取消  - 订单修改  - 订单状态查询
支付问题  - 支付失败  - 重复扣款  - 退款进度查询
物流问题  - 物流延迟  - 虚假签收  - 地址修改
售后问题  - 退货申请  - 换货申请  - 商品质量投诉
账号问题  - 登录失败  - 修改手机号  - 账号冻结

标签体系要注意几点：

• 标签数量不要一开始就过多；
• 标签名称要清晰，避免含义重叠；
• 每个标签最好配有定义和示例；
• 允许设置“其他问题”或“无法判断”。

如果分类标签本身混乱，大模型再强也很难输出稳定结果。

---

三、Prompt 设计：让模型只能从候选标签中选择

在工单分类场景中，Prompt 的核心不是让模型“自由发挥”，而是让它在指定范围内做选择。

示例 Prompt：

你是客服工单分类助手。请根据用户描述，从给定标签中选择最合适的一个二级分类。
要求：1. 只能从标签列表中选择，不能创造新标签；2. 如果无法判断，输出“无法判断”；3. 输出 JSON 格式；4. 不要输出多余解释。
标签列表：- 订单问题/订单取消：用户要求取消订单- 订单问题/订单状态查询：用户询问订单当前状态- 支付问题/支付失败：用户支付时失败或报错- 支付问题/重复扣款：用户反馈被扣款多次- 支付问题/退款进度查询：用户询问退款多久到账- 物流问题/物流延迟：物流长时间未更新或未送达- 物流问题/虚假签收：显示签收但用户未收到- 售后问题/商品质量投诉：商品破损、损坏、质量异常- 账号问题/登录失败：用户无法登录账号
用户描述：页面显示快递已经签收了，但我根本没有收到东西。

期望输出：

json

{  "category_level1": "物流问题",  "category_level2": "虚假签收",  "confidence": 0.92}

需要注意的是，模型输出的 confidence 并不一定是真实概率，只能作为参考。真正上线时，还要结合评测集和人工复核机制。

---

四、单标签还是多标签？

客服工单中经常出现一个问题涉及多个诉求。例如：

我买的耳机坏了，申请退货后一直没有退款。

这句话同时涉及：

• 商品质量投诉；
• 退货申请；
• 退款进度查询。

如果业务只需要工单流转到一个部门，可以采用单标签分类；如果后续要做数据分析和自动处理，可以支持多标签。

多标签 Prompt 可以这样约束：

请从标签列表中选择 1 到 3 个最相关标签，按相关性从高到低排序。如果只有一个明确问题，只输出一个标签。

输出示例：

{  "labels": [    {      "category_level1": "售后问题",      "category_level2": "商品质量投诉"    },    {      "category_level1": "支付问题",      "category_level2": "退款进度查询"    }  ]}

在实际项目中，建议先从单标签开始，保证主流程稳定，再逐步引入多标签能力。

---

五、如何降低调用成本？

如果每一条工单都调用一次大模型，成本可能会比较高，尤其是日工单量达到数万条时。可以采用分层处理策略。

1. 规则优先

对于非常明确的问题，可以先用规则处理：

包含“发票”“开票”“抬头” → 发票问题包含“登录不了”“验证码收不到” → 账号问题包含“重复扣款”“扣了两次” → 重复扣款

规则命中且置信度高时，不再调用大模型。

2. 小模型初筛

可以用本地文本分类模型或轻量 Embedding 模型先做初筛，只有低置信度样本交给大模型。

流程如下：

用户工单  ↓规则匹配  ↓ 未命中小模型分类  ↓ 低置信度大模型分类  ↓人工复核

这种方式可以显著减少大模型调用次数。

3. 缓存相似问题

客服工单中有大量重复表达，例如“退款多久到账”“为什么还没退款”“退款什么时候到账”。可以对用户问题做向量化，相似度很高时直接复用历史分类结果。

---

六、准确率评估：必须准备标注集

上线前不能只看几个例子觉得效果不错，而是要准备一批真实历史工单作为评测集。

建议至少准备：

• 每个二级分类 50 条样本；
• 高频分类样本更多一些；
• 包含口语化、错别字、长文本和多诉求工单；
• 包含“无法判断”样本。

常用指标包括：

• Accuracy：整体分类准确率；
• Precision：某个标签预测为真时有多少是正确的；
• Recall：某个标签的真实样本有多少被识别出来；
• Confusion Matrix：哪些标签最容易混淆。

例如，可能会发现：

易混淆标签	原因
物流延迟 vs 订单状态查询	用户常说“订单怎么还没到”
退款进度查询 vs 退货申请	退货和退款流程关联较强
登录失败 vs 账号冻结	用户无法区分具体原因

评估结果可以反过来指导标签调整和 Prompt 优化。

---

七、人工复核与置信度策略

工单分类并不一定要求 100% 自动化。更合理的目标是：让 AI 处理高置信度样本，把低置信度或高风险样本交给人工。

可以设定策略：

confidence >= 0.85：自动分类0.6 <= confidence < 0.85：进入人工确认confidence < 0.6：标记为无法判断

此外，对于投诉、退款、风控等敏感业务，也可以强制人工复核，避免错误流转造成用户体验问题。

---

八、落地架构示例

一个较完整的客服工单自动分类系统可以设计为：

工单创建  ↓文本清洗  ↓规则分类  ↓小模型分类  ↓大模型分类  ↓结果校验  ↓人工复核  ↓写入工单系统  ↓持续收集反馈数据

其中“结果校验”非常重要，比如检查模型输出是否为合法标签，JSON 是否可解析，分类层级是否匹配。如果模型输出不合法，应自动重试或进入人工处理。

---

九、持续优化：用人工反馈反哺模型

上线后，客服人员对 AI 分类结果的修改非常有价值。可以记录：

• AI 原始分类；
• 人工最终分类；
• 用户问题文本；
• 工单处理结果；
• 是否发生转派。

这些数据可以用于：

1. 优化 Prompt；
2. 调整标签定义；
3. 训练轻量分类模型；
4. 发现新增业务问题。

例如，当大量“直播间优惠券无法使用”的问题被人工归到“其他问题”，说明标签体系需要新增“优惠券使用异常”。

---

总结

基于大模型的客服工单自动分类，不是简单地把用户文本丢给模型，而是一个完整工程问题。真正可落地的方案通常包括：

• 清晰稳定的标签体系；
• 受约束的 Prompt 输出；
• 规则、小模型和大模型的分层处理；
• 标准评测集和混淆分析；
• 人工复核与持续反馈机制。

对于企业客服场景来说，大模型可以显著降低人工分类成本，提高工单流转效率。但要想稳定上线，关键不在模型本身，而在于标签设计、流程控制和评估闭环。