那个因为模型拒绝处理难题而提升的成功指标

你在周二升级了模型。到了周五，“任务完成率”仪表盘从 71% 爬升到了 78%。领导层注意到了。有人在全员大会上截图展示了它。两周后，客服部门悄悄反馈说，特定一批复杂工单的流失率翻了一番。没人把这两件事联系起来，因为从纸面上看，智能体（agent）变得更好了。而现实情况是，新模型只是变得更擅长拒绝了。

这就是指标脱钩问题，也是以 LLM 为动力的产品欺骗其开发者的最昂贵方式之一。你的成功率并没有衡量你认为它在衡量的东西。它衡量的是“模型尝试的内容”与“模型尝试时做对的内容”的交集。当模型升级、提示词更改或安全调优（safety-tuning）改变了“尝试”的边界时，你的分子和分母会同步移动——即使在用户感知的质量一落千丈时，该比率也可能上升。

没人告诉过你的拒绝校准 (Refusal Calibration)

每一个前沿模型的发布都带有一个重新校准的拒绝表面（refusal surface）。Anthropic 自家的 Claude Opus 4.5 系统卡片提到，相对于 4.1，其拒绝率有“轻微上升”，且在测试的所有语言中都是一致的。这句话是为了透明度而写的，听起来似乎无伤大雅。但如果你的产品成功率指标没有区分“模型回答正确”和“模型完全拒绝回答”，那么这就不是无伤大雅的事了。

这种转变在能力基准测试（benchmarks）中很少被宣传。基准测试衡量的是模型尝试案例的性能。模型在安全评估后停止尝试的案例，会悄无声息地同时从分子和分母中滑落。针对某一类失败案例的针对性 RLHF 更新并不像外科手术式编辑那样精准——它会改变整个分布的行为。模型学会了“这种问题有风险”，并将该信号泛化到邻近的问题上，而这些问题在你的产品语境中风险其实要低得多。

因此，当你从版本 N 切换到版本 N+1 时，三件事会同时发生：

• 简单案例：尝试率大致保持不变，成功率大致不变或略有上升。
• 临界案例：尝试率下降，而那些被丢弃的案例，正是旧模型过去尝试过但失败了的案例。
• 用户付费解决的难题：尝试率下降最明显，取而代之的是礼貌的“我无法提供帮助”，而你的监控工具会将其标记为 no_error。

将这三类情况聚合在一起，成功率就会上升。图表在技术上是真实的。但产品却变差了。

为什么“成功率”是不该使用的单一指标

关于选择性预测（selective prediction）的文献近十年来对此已有定论。一个可以弃权的分类器有两个性能维度，而不是一个：覆盖率（coverage，即预测输入所占的比例）和风险（risk，即在预测输入上的错误率）。完整的性能轮廓是一条曲线，而不是一个数字。只报告准确率而不报告覆盖率，相当于只报告了半个测量结果。

LLM 产品在拒绝成为响应分布的一部分那一刻起，就继承了这一属性。在一个具有可变拒绝边界的随机系统上，单一数字的“成功率”不是指标——它是底层行为可以在仪表盘察觉不到的情况下重写的一个故事。这个数字上升可能是因为模型变聪明了。也可能是因为模型变谨慎了。还可能是因为用户在看到模型两次拒绝较难的请求后，开始自我筛选，转向更简单的请求。仅凭仪表盘，你无法判断是哪一种。

客服领域已经以昂贵的代价吸取了教训。“分流率”（Deflection rate）——AI 在没有人工干预的情况下处理的工单量——看起来像是一个节省成本的指标，直到你审计了那些被分流的工单。行业对基于 RAG 的客服部署审计发现，15–25% 的“已分流”工单是以错误或不完整的答案结案的。客户离开了。问题并没有解决。滞后 30 天的 CSAT 图表讲述了真实的情况；而实时的分流率图表则在愉快地撒谎。

解决率（Resolution rate）——确认问题已解决——才是真正与留存率相关的指标。而分流率指标只与模型那周的心情相关。

能抓住这类问题的指标分解法

解决方法并不玄妙，但需要重新配置监测工具。将成功看作两个独立绘图的量的乘积：

• 尝试率（按任务类别）：代理参与请求（而非拒绝、推迟或上报）的比例。
• 尝试后的成功率：在尝试的请求中，产生正确、完整结果的比例。

头条成功率变成了这两者的乘积，顶层指标的任何波动现在都可以通过哪个因素发生了变化来解释。一个带有拒绝校准的模型升级会使尝试率下降，并使尝试后的成功率上升。产品指标仍可能上升。但这种波动现在应该触发警报，而不是庆祝。

按任务类别（task-class）进行切片在这里至关重要。全局尝试率只是一个受全局平均值影响的数字：整个分布中 2 个百分点的下降可能是均匀分布的，也可能集中在你收入最高的群体中出现了 20 个百分点的下降。按任务类型、客户群和请求复杂度等级进行切片。尝试率与尝试后成功率的脱钩本身是基于类别的——安全性临界类别最先变动，技术难度类别在多个版本中发生漂移，而长尾的异常请求则在悄无声息地变化，因为没人关注那个桶。

回归测试应该断言：在没有记录刻意的校准更改的情况下，任何受监控类别的尝试率下降都不能超过 X%。这种断言是结构性的——它不需要预测哪些类别会变动；它要求团队在发布前确认并承认任何变动。

你的评估套件中缺失的用户影响层

即使是“尝试率 + 尝试成功率（success-given-attempt）”也处于真正关键指标的上游。这两个指标都是从智能体（Agent）的角度评分的：我 是否尝试了，我 是否成功了。而用户的问题则完全不同：我 是否得到了我需要的？

一个请求被礼貌拒绝的用户并没有得到他们需要的。由于没有发生崩溃，也没有违反任何政策，你的智能体监测系统将这一轮对话标记为 no_error（无错误）。你的评估套件从未标记这个案例，因为回复在内部是自洽的。你的仪表盘上捕捉不到任何用户体验的信息，因为“用户影响（User-impact）”是你的技术栈原生状态下无法产出的层级。

弥补这一差距的模式是一种存在于智能体自我报告之外的“用户结果（User-outcome）”指标。可行的实现方案包括：

• 后续信号：用户是否在 N 分钟内重新提问、转人工频道，或者在接下来的 K 轮对话中放弃了会话？
• 满意度探测：在对话结束后进行单次提问的满意度调查，其评分独立于智能体是否尝试了任务。
• 人工复核审计（Reconciled audit）：对被拒绝的任务进行抽样重新评判，以分类为“正确拒绝”与“本应尝试”。这是针对“弃权率（Abstention-rate）”的误报审计（False-positive auditing），也是区分“合理的拒绝”与“过度拒绝”的唯一方法。

人工复核审计是这三种方法中成本最高但信息量最大的。它是将“选择性分类（Selective-classification）”的风险-覆盖曲线转化为产品语言：在这个拒绝阈值下，拒绝本身的出错率是多少？大多数团队从未测量过这一点，也无法告诉你他们的智能体是过度拒绝了 5% 还是 50%。这个数字是客观存在的，只是没人去统计它。

为什么领导层看错了图表

“成功率看板”与“流失率看板”之间的脱节很少是由于测量 Bug 导致的。这本质上是一个组织鸿沟。成功率图表存在于智能体团队的监控栈中；流失率图表存在于客户成功团队的表格中，且滞后数周。它们不在同一个屏幕上，不在同一个会议上讨论，甚至不将同一个模型版本作为它们的自变量。

领导层看的是成功率。它是实时的，有一个具体的数值，而且数值在增长。隐含的结论是：上一次改动生效了，所以多做类似的改动。负责评估的团队发布了另一次提示词改动或模型升级。数值再次增长。图表鼓励团队向任何能让该指标最大化的方向狂奔——而在存在“拒绝校准漂移（Refusal calibration drift）”的情况下，最大化该指标的方向就是“更多拒绝”的方向。

这就是智能体系统版本的“麦克纳马拉谬误（McNamara fallacy）”：优化你能测量的，然后假定你不能测量的并不重要。这里未被测量的并不是像“感觉（Vibes）”这种软变量，而是一个硬变量，即“用户是否得到了他们需要的”。它被掩盖了，因为模型被赋予了拒绝的权利，而仪表盘却没有被赋予将“拒绝”计入“失败”的权利。

一种能经受住这种考验的管理准则，要求在核心成功率的同一个屏幕上展示三样东西：按类别统计的尝试率、按类别统计的弃权率，以及用户结果信号。除此之外的任何做法，都会导致领导层从仪表盘得出的结论在版本更迭中不断向错误的方向叠加。

每次发布的隐形成本

无论团队初衷如何，每一次模型升级和每一次提示词改动都是一次“拒绝边界扰动（Refusal-boundary perturbation）”。不测量它的代价并不是错过一次单一的回归错误，而是在长达一年的“改进”中，智能体的帮助性（Helpfulness）发生了缓慢的漂移——每一次改进都让成功率看板变得更好看，却让用户体验变得更糟。

那些确实测量了这一指标的团队，继承了一套更诚实的工程流程。他们可以将模型升级作为一种审慎的权衡来执行：这次发布将“尝试成功率”提高了 3 个点，但在“法律审查”类别中损失了 4 个点的“尝试率”——我们要发布它吗？这种对话的逻辑是正确的。而以“任务完成率上升了，发布吧”结尾的对话，其逻辑是错误的，且最终将由一批再也无法挽回的流失客户来买单。

架构上的意识简单却令人不安：一旦你的模型可以拒绝，你的成功率就不再是你以为的那个指标了。它测量的是“能力”与“意愿”的联合分布，而“意愿”是一个移动的目标，会随着供应商发布的每一次更新而改变。请将其视为移动目标。拆解指标。审计拒绝案例。将用户结果信号与智能体自我报告信号并列放在团队周一评审的仪表盘上。

由于模型拒绝了更难的任务而上涨的图表，是最危险的一抹绿色。它看起来像是进步，实则是一个产品正在悄无声息地流失它最想留住的客户。