一张开票工单进了设备售后队列，客服把它转回去，问题暂时解决了。复盘时若只记“AI分类错误”，下一轮仍可能分错：模型可能判错类别，也可能已经判对，后面的队列映射却用了旧规则。

先沿这张单保留五段记录：当时的标签定义、用户原始描述、业务参考判定、模型候选标签、实际进入的队列。哪两段开始出现差异，决定下一步该找谁处理。只保存最终分类名称，会把中间的问题压成同一种错误。

## 先看分类口径能否让人作出一致判断

下面的六条工单、标签规则与故意设置的输出均为编辑演示，没有调用模型。设本期只受理开票、账号访问、设备售后三类业务：开票处理发票申请与补发；账号访问处理登录和账号使用；设备售后处理设备运行问题。涉及多个诉求、信息不足或范围外的问题，另有处理状态。

| 编号 | 用户描述 | 本例参考判定 | 需要检查的地方 |
| --- | --- | --- | --- |
| T01 | 请补开发票 | 开票 | 候选写成设备售后，回查输入与分类依据 |
| T02 | 更换手机号后无法登录 | 账号访问 | 候选标签正确，实际却进开票队列，查映射与路由 |
| T03 | 设备无法启动 | 设备售后 | 正常分支；保留症状，具体故障原因待技术处理 |
| T04 | 无法登录，同时请补发发票 | 两个诉求均需保留 | 查产品是否支持拆分，或主任务关联待办 |
| T05 | 还是不行 | 缺少上下文 | 补取原会话或追问所指问题 |
| T06 | 请问招聘进度 | 当前服务范围外 | 使用已确定的范围外入口 |

标签字典最好同时写“包含什么”“容易与哪类混淆”“遇到什么先补信息”。例如把“其他问题”既当账号兜底类，又当所有未知事项的去向，人工标注就容易摇摆。先请业务人员分别判同一组输入，再核分歧；若两个人依据同一份规则仍给出不同类别，应先修改规则或明确例外。

微软的[自定义文本分类生命周期文档](https://learn.microsoft.com/en-us/azure/ai-services/language-service/custom-text-classification/how-to/build-train-deploy-model)将类别歧义、范围外数据和样本来源列为设计事项，并区分单标签与多标签任务。这里值得借鉴的是先确定要识别什么，再准备对应材料；企业自己的分类边界仍需业务负责人确认。

## 标签判对后，还要沿队列查下去

T02可以把排查范围明显缩小。核对当时送给模型的文字和返回标签后，再查标签怎样转换成队列：是否沿用旧名称，规则优先级是否改变，某条兜底规则是否先命中，人工改过标签后有没有重新路由。

[Dynamics 365分类规则说明](https://learn.microsoft.com/en-us/dynamics365/customer-service/administer/configure-work-classification)展示了一种具体机制：先依次执行分类规则集，再执行路由到队列的规则；前面写入的属性可被后面的规则使用。使用其他工单产品时，应找到对应配置与执行记录，按实际顺序复查。

修正队列映射后，继续核目标队列是否受理、是否有人接手。分类正确、路由正确和处理结束是三个不同的观察点；队列长期无人接收，应由服务负责人处理，而不是继续调分类提示。

## 把错分、缺信息和多诉求分别交给人处理

T01的参考类别明确，接下来要核模型实际收到的输入。若原文在传递时被截断，先修输入；若完整输入和规则都已送达，再检查提示、示例或模型输出。没有日志的地方保留待查，避免把修复动作建立在猜测上。

T05先需要上下文。补到了前一条“无法登录”之后，它才有条件进入账号访问分类。把这类短句全部归为模型错分，容易催出一种有害修正：系统开始对信息不足的工单大胆猜测。

T04则是任务设计问题。业务可选择拆成两张关联工单，或保留一个主任务加一个待办。无论采用哪种方式，都应让接手人看到另一个诉求及其去向，避免只处理登录后就关闭整单。

## 复查时看错往哪里分，别只看一个总数

固定输入、标签规则和参考判定，按类别汇总误分方向，才能发现开票是否常被分到账号，或者某个小类别一直被吞进兜底队列。[scikit-learn混淆矩阵文档](https://scikit-learn.org/stable/modules/generated/sklearn.metrics.confusion_matrix.html)采用“行是参考类别、列是预测类别”的方向；记录时写明方向，便于复算。

多诉求、缺上下文和参考判定未决项应另列，并与全部输入数量对上。微软的[分类评估说明](https://learn.microsoft.com/en-us/azure/ai-services/language-service/custom-text-classification/concepts/evaluation-metrics)也建议结合错分后果选择指标，尤其留意工单进入错误团队的影响。小类别里的严重错派，值得单独检查。

每项修复留下负责人和复查对象：业务修改标签边界，产品调整补问与多诉求状态，实施团队核输入和路由。修订后保留原失败例，也复看原本正常的T03这类输入，确认修错没有带来新的误分。

需要继续设计接收与交接时，可接着核对[带上下文的人工接管](https://hloxi.com/insights/agent-human-handoff-context/)。


一张开票工单进了设备售后队列，客服把它转回去，问题暂时解决了。复盘时若只记“AI分类错误”，下一轮仍可能分错：模型可能判错类别，也可能已经判对，后面的队列映射却用了旧规则。

AI工单分错了，先改分类口径、补上下文，还是查路由？

工单误分先沿标签定义、原始输入、参考判定、模型候选与实际队列定位。用六条演示区分分类、上下文、多诉求与路由问题，按错误后果复查。

人工智能

架构设计

后端

路由

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI工单分错了，先改分类口径、补上下文，还是查路由？-腾讯云开发者社区-腾讯云

AI工单分错了，先改分类口径、补上下文，还是查路由？

AI工单分错了，先改分类口径、补上下文，还是查路由？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐