工单分类上线，关键是何时交回人工

一个每天处理约 4,000 张 IT 工单、分流到 11 个队列的系统，演示版准确率已经达到 94%，上线时却换掉了作为主分类器的 LLM。原因很实际：剩下 6% 的工单会被悄悄分错，等人发现，服务时限可能已经超标。

作者花了六周才把系统交付，最终最关键的参数是拒答阈值 0.60。这篇记录值得读的地方，是它把「模型答得准不准」推进到了另一个问题：哪些请求应该自动处理，哪些值得交给人，以及怎样让整套流程更便宜。

94% 的准确率，为什么还不够上线

作者最初用提示词让 LLM 根据工单正文输出队列名，每个队列提供 8 个示例。在 2,000 张留出工单上，准确率达到 94%。演示只花了一个下午，剩下五周零九天几乎都用在建模之外。

问题出在错误如何收场。没有拒答机制，系统就会为每张工单给出答案，包括它分错的那些。按每天约 4,000 张计算，6% 大约就是 240 张；这些错误可能两天后才被发现，此时 SLA 已经告警。

作者随后找服务台负责人估算代价。对方认为，一次错分的成本约为正常分流的 5 倍，包括返工、SLA 计时重新开始、接手者切换上下文，以及工单在多个队列间来回流转。

这个 5x 不是严格测算结果，而是承担实际成本的人给出的估计。作者明确承认它仍然是猜测，但它直接决定设计：如果是 2x，自动化可以更激进；如果是 10x，就需要更谨慎。

准确率回答模型分对了多少，成本才回答系统值不值得用。

置信度不能直接当成正确概率

要让系统在不确定时转交人工，得先有一个可信的分数。

作者尝试让 LLM 自报置信度，但答对和答错时都可能得到「high」。标签 token 的 logprobs 也没有解决问题：分数为 0.9，只能说明这个 token 在当前输出中很可能出现，不能直接解释成分类有 90% 的概率正确。

他还试过口头给出 1–10 分、采样 5 次检查答案一致性，以及让第二个模型担任评审。这些办法都增加了单张工单的成本，却没有给他一个可以放心设置阈值的分数。

这不代表 LLM 无法校准。作者的意思是，一旦补齐校准层、留出数据和阈值扫描，交付对象就已经是一套路由系统，LLM 只是其中一个组件。

最终上线的是 TF-IDF 加 logistic regression：词级使用 1–2 grams，字符级使用 3–5 grams，再用留出切片拟合 isotonic calibration，并检查可靠性图（reliability diagram）。校准要解决的问题很直接：被打成某个置信度的样本，实际正确比例是否接近这个分数。

这套模型单核推理约 8ms，不需要 GPU，体积只有几 MB，可以和 API 放在同一个容器里。

0.60 是怎么选出来的

作者没有凭感觉挑阈值，而是在 0.30 到 0.95 之间扫描，逐个计算每日总成本：推理费用、按 5x 计入的错分费用，以及拒答后转人工的费用。

成本曲线呈 U 形。在他的工单流量上，最低点对应 0.60：

• 78% 的工单自动分流，这部分的 precision 为 99.1%。
• 22% 转交人工。
• 每日错分从约 240 张降到约 31 张。
• 总成本约为始终自动分流的 LLM 版本的三分之一。

这里的 99.1% 只属于自动处理的那部分工单，不能拿来当作全量准确率。作者也明确说，LLM 版本的整体准确率更高，但最终输在成本上。

另一个关键改动发生在人工接手环节。最初，拒答工单只是被扔进人工队列；后来，系统会附上前三个候选队列，以及一句概括诉求的摘要。人工分流时间从约 90 秒降到约 40 秒。作者认为，这次流程调整对成本曲线的影响，超过了他的任何建模改动。

LLM 因此保留了一个合适的位置：为那 22% 的拒答工单写摘要、排列候选队列，每天约调用 880 次。

转人工的成本越低，系统就越有空间承认不确定。

我的判断

我赞同作者把拒答作为完整产品路径来设计。只加一个「转人工」按钮，却不提供上下文和候选项，往往只是把自动化省下的工作重新交给人。

但这里的结果有明确前提。5x 来自业务估计，原文没有披露完整成本表，也没说清人工成本、LLM 调用费用如何计价。因此，「总成本降到三分之一」是这个案例的结果，不能直接当作一般团队的收益预期。

同样，作者没有给出各模型在相同校准、相同人工辅助流程下的完整对照。它能支持「这套传统分类方案适合他的任务」，还不足以证明 TF-IDF 普遍优于 LLM。对于作者关于不同模型校准特性的判断，也应结合自己的数据验证。

还有一句需要拆开看：业务价格变化时，阈值可以一行修改，无需重训；但新阈值仍然应该重新计算。如果数据分布或分数校准已经变化，只改配置并不能保证结果可靠。

作者自己也划出了边界：错误便宜、各类错误代价接近时，直接全部自动处理，可能更省事。拒答机制解决的是错误代价高于人工交接的问题，并非每个分类任务都需要。

能拿来做什么

• 给工单分类或类似的 AI 分流功能定指标时，先找业务负责人写下错分和人工处理的相对成本，并记录估计者。不要只用准确率决定是否上线。
• 如果在 Node 服务里接入分类器，把阈值放进配置，同时记录它对应的成本假设、负责人和复核周期。作者使用 YAML，阈值为 0.60，并约定按季度复核。
• 给转人工页面展示候选分类和简短摘要，再测人工完成任务所需的时间。原文从约 90 秒降到约 40 秒的变化，说明接手体验值得单独优化。
• 把拒答率加入日常监控。作者的基线是 22%；如果升到 35%，应排查产品线、工单模板或队列名称等上游变化。他们曾靠这个信号发现损坏的提交表单。