客服工单自动化分流（DEMO 复盘）

示例内容（DEMO） — 本文为站点功能验证用的占位内容，发布前将整体替换。

背景

示例场景：一家中等规模的 SaaS 公司，客服团队每天接收几千条工单。工单需要先按类目分流（计费问题、技术故障、账号安全、功能咨询等），再路由到对应小组处理。人工分流占用了客服约两成的工作时间，且夜间和高峰期错分率明显上升。团队希望引入文本分类模型，把分流这一步自动化。

模型在离线测试集上的整体准确率约 92%。听起来不错，但项目能不能上线，恰恰取决于怎么处理那 8% 的错误。

约束

• 错分的代价不对称：把"支付故障"错分进"功能咨询"队列，用户可能多等几个小时，投诉升级；反过来错分，代价小得多。
• 各类目准确率差异大：高频类目接近 96%，长尾类目可能只有 70% 出头。
• 客服一线对自动化有天然戒心，一旦前两周频繁返工，信任会很快耗尽，再想推就难了。
• 不允许为了自动化引入用户侧的额外等待。

核心问题

准确率到不了 100% 时，真正的问题不是"怎么把模型做到 100%"——短期内做不到，而且边际成本极高。真正的问题是：剩下的错误落在谁头上、单次代价多大、由谁兜底、兜底动作要多少成本。这是产品设计问题，不是算法问题。

判断过程

当时摆在桌面上的有三条路：全量自动分流、模型只做建议人工全量确认、按置信度分层。先给结论：选了第三条。

全量自动看起来效率最高，但 8% 的错误会随机砸在所有类目上，包括高代价类目，而且错误是静默发生的，发现时往往已经造成延误。全量人工确认则等于没有节省人力，模型沦为摆设，一线会很快忽略建议。

分层方案的核心判断是：模型输出的置信度本身就是有用的产品信号，不该被丢掉。高置信的部分让模型独立完成，低置信的部分明确交还给人，中间地带让人用最低成本确认。

模型的职责不是替人做完所有判断，而是把确定的事做掉，把不确定的事明确地交出去。交出去的方式越清晰，整个系统越可信。

解决方案

按置信度切成三层，并对高代价类目单独抬高阈值：

阈值配置示意（虚构数值）：

routing:
  auto_threshold: 0.90
  assist_threshold: 0.60
  high_risk_categories:
    - 支付故障
    - 数据安全
  high_risk_auto_threshold: 0.97

配套机制有三件事，缺一不可：每周对自动路由的工单做抽样复核，错误率回流给模型侧；接收方小组有一个"分错了"按钮，申诉直接计入类目级指标；高代价类目即使置信度达标，也走更严格的独立阈值。

结果

在这个虚构设定下，可以预期的形态是：大部分高频、表述清晰的工单走自动通道，人工精力集中在中置信确认和低置信兜底上，分流的整体人力占用明显下降，而高代价类目的错分由于独立高阈值反而比纯人工时期更可控。更重要的是，一线知道哪些单是模型分的、哪些是自己确认的，责任边界清楚，信任建立得起来。具体数字此处不列——这是示例场景，列了也是编的。

复盘

• 阈值是产品决策，不是算法参数。0.90 还是 0.85，差的不是准确率，是哪一类用户在多等、哪一组同事在返工，应该由产品和业务一起拍板。
• 兜底路径必须先于自动化上线。先把人工队列、申诉按钮、抽样复核跑通，再放开自动路由，顺序反了就是在拿信任做赌注。
• 准确率要按类目乘以代价来看，整体 92% 这个数字单独拿出来没有任何决策价值。
• 一个当时没料到的坑：中置信层的"一键确认"上线后，部分确认会退化成无脑点击。后来在改判率异常低的账号上加了抽检，才把这层的质量稳住。人机协作的设计里，人的惰性也是系统的一部分。