你没列进预算的"弃答税"

你教会了 Agent 在上下文不足时说"我不知道",然后把这当成一次安全胜利。OpenAI 账单确实降了。所有人都同意这是负责任的做法。三个月后,你的客服 VP 在追问为什么人头预算偏差 40%,AI 团队里没人答得上来——因为你跟踪的指标是弃答率,而真正动起来的指标是每周工单数,而那条把它们加起来的曲线没有任何 owner。

这就是弃答税。它不是一种模型成本。它不会出现在推理账单上。它出现在下游:出现在每接住一句"我无法回答"就要排队处理的人工团队队列深度里,出现在针对人工额外补足后的上下文再跑一次的第二次模型调用里,出现在等待期间流失掉的客户身上。只看模型成本的那张账面,悄悄把它藏了起来。再加上 AI 团队负责弃答、运营团队负责队列的那道组织接缝,意味着没有人有动力去看清这件事。

弃答已经成为一项承重的安全技术。2025 年的共形弃答(conformal abstention)文献把它当成约束幻觉风险的"原则性"做法:用留出集校准一个置信阈值,低于阈值则拒答,你就能拿到模型只在大概率正确时才回答的统计保证。级联系统进一步扩展了这个思路——先用小模型,不确定就弃答,再升级到更大模型或人工。做得好,这确实比"自信地幻觉"要强不少。基准也支持这个说法:学习得到的共形弃答策略能把校准误差降低 70%–85%,而提早弃答的级联以弃答率上升 4.1% 的代价换来了模型层 13% 的成本下降。

陷阱就藏在最后那句话里。在模型层。13% 的成本下降是对一个局部系统的真实测量。完整系统包含了模型弃答之后发生的一切事情。而在生产中,模型弃答之后发生的事情很少是免费的。

弃答不会消灭成本,它只是把成本搬走

"弃答能省钱"的直觉是:替代方案是一个错误答案,会触发退款、投诉、二次工单。弃答把这些都绕开了——理论上是这样。实际上,弃答会触发另一种连锁反应。

考虑一次弃答在客服场景里端到端究竟值多少钱。Agent 看到一个它没把握回答的查询。它升级。一个人工接过来——Gartner 的参考成本是每张人工处理的工单 8.01 美元,相对于自助解决约 0.10 美元。人工读完对话,再让客户把 Agent 在交接时没带上的上下文重复一遍(在生产审计中,这是对 CSAT 影响最大的单一失败模式),然后向解决推进。客户等待期间,留存在被侵蚀。一部分客户在排队期间流失。一部分客户因为第一张工单拖太久而提交了第二张。那个本来打着"我们自动化一线"招牌的 AI 功能,反过来制造了一线积压,留给人工团队去消化。

接下来算一下 12% 弃答率下的账。假设 Agent 每月处理一百万次对话,人工团队是按 Agent 本来就不该碰的那 5% 残差容量来配置的。当弃答率是 12% 时,人工队列要吸收的就不是 5%,而是总量的 17%——3.4 倍涨幅。Agent 层的成本下降了大约 20%。人工层的成本上升了 240%。单次"已解决对话"成本的净变动,取决于模型成本与人工成本之比——而每次 AI 解决 0.50–2.00 美元、对比每次人工解决 8.01 美元,这个比值是相当残酷的。你可以在 AI 层省下 50%,在系统层照样亏钱。

这不是假设。2025 年覆盖了 1,200 多个生产 AI 系统的 LLMOps 部署调研记录了完全一致的模式:某组织加了一个评审队列,Agent 的每条输出都要等人工审批,结果 48 小时之内堆积了 14,000 条待办、平均审批延迟 6.4 小时——彻底打掉了自动化的意义。三天之后,审核员的通过率达到了 99.7%,也就是说他们已经不读了。弃答税一次性以两种方式付清:队列成本,以及队列本该提供的安全控制悄悄失效。

评测 dashboard 看不到运营账单

之所以会反复出现这种情况,是因为存在一个测量空白。AI 团队按弃答率、幻觉率、回答工单的准确率来评估 Agent。把阈值收紧一点,这每一个数字都会更好看。如果只给 Agent 打分,收紧弃答是一次帕累托改进。

运营团队按工单总量、解决时间、CSAT、升级率来评估队列。这些指标在 AI 评测框架里都看不见。当弃答率从 8% 涨到 14% 时,Agent dashboard 显示一个绿色对勾(Agent 在模糊样例上变得更谨慎了)。运营 dashboard 看到入站工单暴涨 75%,团队归因于季节性、用户流失、营销活动——任何东西,就不会归因于他们并不直接 own 的那个 AI 部署。

这就是为什么 Gartner 的 2027 年预测——50% 因为 AI 而砍掉客服人头的公司会回头加招——读起来不像预报,更像必然。砍人头的依据是把所有非 AI 工单都当成成功交接的转移率算法。回头加招的账,是由没人列进预算的弃答税付的。

补救的办法不是放弃弃答,而是把它端到端测量出来。正确的成本口径是单次已解决任务成本(cost-per-resolved-task),它把以下几块加起来:

• AI 尝试的模型成本(无论它回答了还是弃答了)
• 升级成本,如果有(完全摊算的人工工单)
• 排队时间的机会成本(客户等待小时数,按流失风险建模)
• 重新触达成本(二次工单、回拨、客户以为被遗忘了而发的跟进邮件)
• Agent 答错时的恢复成本(退款、补偿额度、投诉处理)

只有第一列是你的 AI 基础设施团队不用插桩就能看到的。其他四列都要求把 Agent 的 trace 和下游的工单系统、客户旅程数据库、以及付钱的财务系统耦合起来。很少有组织真正完成了这套耦合。完成了的那些,会发现最优的弃答率显著低于安全评测推荐的水平——因为在边际上,额外一次弃答的代价,比一次"自信地答错"加上后续恢复的期望成本还要更高。

加载中…