先定错误容忍度，再算客服自动化比例

把 AI 客服的目标定成「自动处理 80% 工单」，可能从一开始就问错了。作者主张先确定能接受多少错误，再让模型置信度决定哪些工单自动处理、哪些交给人工。自动化比例应该是质量约束下的结果。

作者用 Banking77 公共数据集做了一个演示：自动处理 75.9% 的测试工单，这部分准确率为 97.7%。但它验证的是工单分类与分流，并未证明 AI 能独立解决同等比例的客户问题。理解这个边界，比记住数字更有用。

先定准确率，才能知道能自动处理多少

这个演示接收一条客户消息，例如「为什么充值没有成功」，然后输出三个结果：它属于 77 个类别中的哪一类、模型有多大把握，以及接下来自动处理还是转人工。

模型会给每条工单一个 0 到 1 的置信度。超过阈值就进入自动处理流程，低于阈值就转给人工。

阈值不能凭感觉选。作者先设定质量目标：「自动处理的工单，准确率至少达到 97%」，再在独立的验证集上，找到满足目标的最低阈值。这样做是在质量要求以内，尽量扩大自动处理范围。

自动化比例是质量目标的结果，不该先被写成必须完成的指标。

这里有两个不同的数字：单条预测的置信度，以及一批工单的实际准确率。置信度用于筛选，97% 则要靠带有正确标签的数据来检验。不能直接把阈值设为 0.97，就认定筛出的工单一定有 97% 的准确率。

75.9% 自动处理，是怎样测出来的

作者使用 Banking77 数据集，其中 10,003 条消息用于训练，另有 3,080 条留作测试。原文还说明使用了独立验证划分来选择阈值，但没有交代验证集的具体规模。

模型很朴素：词级和字符级 TF-IDF 特征、逻辑回归，以及概率校准。TF-IDF 可以理解为把文本转换成反映词语、字符片段重要程度的数值特征；概率校准则用于让置信度更贴近实际正确率。整个演示没有使用大语言模型，也不需要 GPU。

最终测试结果是：

• 75.9% 的工单进入自动处理流程，这部分准确率为 97.7%。
• 如果全部自动处理，准确率为 90.2%。
• 剩余约 24% 的工单转给人工。

作者给出的「每 1,000 条工单约有 17 至 18 条错误」，分母是全部收到的工单。按自动处理部分计算，97.7% 的准确率对应每 1,000 条自动处理工单约有 23 条错误。两种口径不能混用。

97.7% 与 90.2% 的差距，来自人工接走了模型最拿不准的部分。模型容易混淆的也多是相邻类别，例如「充值处理中」与「充值失败」，或者「无法识别的银行卡付款」与「银行卡疑似被盗用」。

作者强调：阈值在验证集上选定，最终在模型从未见过的测试集上只检查一次。反复根据测试结果修改阈值，会让测试集也参与调参，数字就容易比真实上线表现好看。

我的判断

先约束错误、再争取覆盖率，这个思路适合有明确质量要求的分类与分流任务。它也说明，边界清楚的文本任务可以先建立一个简单模型基线，再判断是否需要更复杂的方案。

但「自动处理」需要打个问号。原文展示的是类别识别、置信度与分流决策，没有说明如何生成回复、执行操作、确认客户问题已经解决。分类准确率不能直接当作客服解决率。

这些也是公共测试数据上的结果，作者明确说它们不是客户项目成绩。换成真实业务，消息表达、类别分布和标注标准都可能不同。原文没有提供置信区间、不同类别的错误代价，也没有给出与大语言模型或规则系统的对照数据。因此，模型选型能说明这个方法可以运行，尚不足以证明它优于其他方案。

相邻类别的混淆还提示了另一件事：有些错误要先查分类标准是否清楚，再谈换模型。作者建议用客户自己的标注工单梳理这些类别，这是落地时不能省的一步。

能拿来做什么

• 给 Node 工单分流服务增加自动处理能力前，先约定自动处理部分的最低准确率，再用独立验证集选择阈值。
• 在客服后台同时展示自动处理覆盖率、自动处理准确率和转人工比例，并写清错误率的分母，避免只拿一个漂亮数字汇报。
• 为低置信度工单保留明确的人工队列，检查「充值处理中／充值失败」这类易混类别是否有一致的标注标准。
• 上线前用自己的历史工单重新评估；如果系统还负责生成回复或执行操作，应分别验证这些环节，不能沿用分类模型的准确率作为验收结果。