评测的成本

评测开销随变更速率增长，而不是随流量。

你模型账单上的其他每一行都是可变成本：用户更多、令牌更多、钱更多，比例还保持不变。评测不是这样运作的，而把它当成那样来编预算，正是根上的那个错误。

• 驱动因素是变更事件。一次模型版本升级、一次提示词修改、一个新工具、一次检索配置调整、一次框架升级、一次厂商侧的静默更新。每一件都是重跑测试集的理由，而它们没有一件与你有多少客户相关。
• 一个尚未发布的智能体流量近乎为零，评测账单却最高。那正是变更最密集的时期。任何把评测按推理支出的百分比来分配的预算模型，都会恰好在"评测决定你能否发布"的那个阶段给它拨不够钱。
• 它的行为像研发，就按研发来记账。把它放进变更预算里、与工程人力并列，而不是放进 COGS 里、与服务成本并列。一个任务的 单位经济性 不该背负评测摊销；该背负"证明这次变更是安全的"这笔成本的，是"决定改点什么"这个动作。
• 这也是它总被第一个砍掉的原因，以及为什么那是最贵的一种节省。一个坐在 COGS 里的评测科目，在任何读毛利报表的人眼里都像浪费；而它被削减的那个季度，正是你变更速率最高的季度。这就是 经济性在何处崩溃 里"评估账单"那一条背后的机制——只不过在这里它被讲成一个编预算的错误，而不是一次意外。

定下这个价格的那条平方关系。

假设你的智能体在 90% 的任务上成功，而你想以常规的置信水平知道某次变更是否挪动了这个数。你所需的样本量，几乎完全取决于你坚持要检测出多小的一次移动——而且是平方级地取决于它。

# Runs needed to detect a drop from a 90% baseline
# two independent arms, 5% significance, 80% power

  90% -> 80%   (10 points)     ~200 runs per arm      ~400 total
  90% -> 85%   ( 5 points)     ~700 runs per arm    ~1,400 total
  90% -> 88%   ( 2 points)   ~3,850 runs per arm    ~7,700 total
  90% -> 89%   ( 1 point )  ~15,000 runs per arm   ~30,000 total

• 乘的是每次运行的成本，不是每令牌的成本。一个现实的智能体任务——多轮、若干次工具调用、一条很长的轨迹——每次尝试的模型开销通常落在 $0.10 到 $1.00 之间。取这个区间的中值，抓住一次两个百分点的回归，光推理一项就要花掉大约两千美元。
• 然后再加上裁判。如果打分是由 LLM 完成的，每一次运行至少还要被评一遍，而一个做得好的裁判往往评两遍、或者用比被测智能体更强的模型。裁判成本经常占到总额的 20%–50%，也是人们在给测试集定规格时忘掉的那一行。
• 再加上标注。得有人为其中几百个任务判定"正确长什么样"，还得有人反复核查裁判是否仍与他们意见一致——这正是 用 LLM 做智能体裁判 里那份持续义务。人工标注是整套装置的资本性成本，而且它不会消失。
• 真正让人吃惊的是"每次变更"这个口径。上面那整份账单，是一次比较的价钱。如果你一个季度做三十次有意义的变更、每次都以满功效重跑，那你就是签下了三十份这样的账单。

在加买运行次数之前，先把比较配成对。

上面那张表假设的是两组独立样本。几乎没有哪次评测非得这么浪费，因为两个臂都在你手里，你可以让它们跑同一批任务。

• 让两个版本跑完全相同的任务集，并逐项比较。智能体评测里的方差大多存在于任务之间、而非版本之间——有些任务本来就更难。把任务固定住，就把那部分方差整个从比较中移除了，剩下的正是你真正在意的那个差值。
• 这份节省很大，而且不要钱。配对设计只检验两个臂给出不同结果的那些条目，所以有效样本量是"分歧数"而非"运行数"。当两个臂在多数任务上一致时——小变更的常态——在同样的检测功效下，这通常能把所需运行次数削掉数倍。
• 凡是能固定的都固定住。同样的随机种子、同样的任务顺序、同样的检索快照、同样的工具桩。你消除掉的每一份逐次运行的噪声，都是你不必花钱去买的样本量——这个论证在 评测方差与统计功效 里有充分展开。
• 永远把置信区间一起报出来。一个 60 个任务的测试集给出 88% 对 91%，其实什么也没告诉你；而危险不在于有人误读它——在于有人据此行动、为一次纯属噪声的变更花掉一周，然后在"改进"没能再现时对整个评测失去信心。

把测试集分层，让贵的那一层难得跑一次。

一个每次提交都要跑的测试集，要么弱到什么都检测不出来，要么贵到不可能每次提交都跑。请按"这次运行是为了什么"把它切开。

• 冒烟层，每次提交，几十次运行。它不是一次质量测量，而是一个灾难探测器。它抓的是坏掉的工具 schema、如今只返回空的提示词、失败的鉴权。便宜到可以不计成本，而且它抓住了实践中真正会坏掉的大部分东西。
• 回归层，每个候选发布版，按你会据以行动的效应量配足功效。这就是第二步里那份账单，只是一个月付几次而不是一百次。用冒烟层卡合入，用这一层卡上线，参见 评测驱动开发与 CI。
• 深度层，每季度或每次模型迁移，包含所有慢切片。对抗样例、长程任务、多语言切片、轨迹评分。贵、罕见，而且当厂商弃用某个模型时，它是那次你绝不能跳过的运行——见 模型弃用与迁移。
• 把评分模型也往下层路由。schema 符合性、拒答检测、格式检查以及大多数客观断言，用一个小的本地模型就够了。把前沿裁判留给它能挣回差价的那些主观切片——正是 小模型与本地模型 里论证的那一刀。
• 用上你早就在付钱的那些便宜基础设施。评测运行按定义就是可批处理且对延迟不敏感的，这让它成为 批量推理 折扣的理想负载；而它们共享的系统提示词又让它们成为 提示词缓存 异常合适的候选。这里省下的 50% 只需要一天的管道工作，而且对今后每一次运行都有效。

分清哪些成本会缩、哪些是地板。

优化的力气只值得花在第一份清单上。团队却常常把它花在第二份上，然后得出"评测负担不起"的结论。

• 靠工程能缩的：每次运行的令牌数（缓存、更短的轨迹、更便宜的裁判）、基础设施（批处理档位、自建评分模型），以及重跑频率（分层、变更合批）。
• 只靠一个决定才能缩的：样本量。它由你的检测阈值定死，只要那个阈值还立着，再多的聪明也挪不动它。
• 根本不会缩的：那份带标注的黄金集以及它的维护。它是一项缓慢折旧的资产——任务会过时、产品行为会变，而一份一年没人碰过的集合，度量的是一个你早已不再交付的智能体。
• 会悄悄变大的：裁判漂移。裁判模型一旦升级，你的历史分数就不再与新分数可比，而对着人工标注重新校准是一笔真实的、周期性的、从不出现在任何人计划里的成本。
• 像对待其他任何开销一样把它归因。按测试集、按触发它的那次变更、按团队给评测运行打标签，好让有人问起"这钱买到了什么"时这个数字站得住。机制与 成本归因与预算 里一样；而没打标签的评测开销，是智能体预算里最常被质疑的一行。

先定阈值，然后恰好买这么多。

整套纪律归结为一个按正确顺序提出的问题，而多数团队把顺序问反了——他们先造一个测试集、跑起来，然后再琢磨这些数字是什么意思。

• 先问：多大的质量跌幅会让我们回滚？如果诚实的答案是"五个百分点"，那你从来就不需要为两个百分点的分辨率付钱，而你刚刚把回归账单砍掉了五倍。
• 逐个面去问，而不是只问一次。某个与安全相关的拒答率跌一个百分点，可能值三万次运行；某个摘要质量分跌一个百分点则不值。在整个测试集上采用统一功效，意味着在其中大部分上多付钱、又在真正要紧的地方付不够。
• 把细粒度的检测交给生产环境。离线评测是为你还没上线的那些变更服务的。小而持续的漂移，在线上流量里抓更便宜，因为那里的样本是白来的——这就是 在线评测与离线评测 里的那笔交易，其背后的定量计算在 检测质量回归 里。
• 有意识地把变更合批。三个变更一起评测，付的是一次比较而不是三次。代价是归因——批次一旦回归，你不知道是哪个变更干的——所以把容易拆解的变更合批，把难以拆解的单独评测。
• 把每次比较的成本印在结果旁边。"这道关卡花 1,900 美元，能检测出五个百分点的跌幅"是一句高管能据以行动的话；"我们需要更多评测预算"不是。

延伸：为何智能体评测很难 讲你到底在度量什么，评测方差与统计功效 讲本页底下的那套统计，衡量智能体投资回报 讲怎么把评测账单放到账本正确的一侧，以及 评测入门 讲最基础的那一层。