你那个评测差值多半是噪声——而解法是加任务、做配对，不是加运行次数。
在一个 500 题的基准上，一个非配对的 50% 分数带着大约 ±4.4 个点的 95% 置信区间——于是你正准备上线的那"提升三个点"就落在误差棒里面，你分不清它和什么都没做有什么区别。把同一次比较改成配对——同样的任务、同样的随机种子——在完全相同的数据和完全相同的预算下，可检测效应会降到三个点以内。配对是智能体评测里回报最高的一处改动，而几乎没人在做。
你上线的那个数字是一次抽样，不是一次测量。
确定性的测试套件跑两遍会给出同一个答案。智能体评测不会，而且至少有四个彼此独立的原因，每一个都在贡献方差——那些方差最后都会被你算到自己的改动头上：
- 采样。任何大于零的温度都让轨迹成为一次抽签。而温度为零也救不了你——批量推理、专家混合路由、浮点数不满足结合律，都会让完全相同的输入返回不同的输出，这正是可复现性与确定性的主题。
- 环境。某个工具超时、某个页面渲染得不一样、限流恰好卡在第十二步。长周期任务会把这些累积起来；至少有一步撞上瞬时故障的概率，随步数增长。
- 评判器。如果打分的是模型，那么这个分数本身也是一次抽样——而且是会漂移的那种。参见评判器校准。
- 误差复合。这一条是智能体特有的。一个二十步任务把二十个步骤级成功概率乘在一起，于是每步很小的波动会产出端到端很大的波动。这就是为什么智能体评测比人们直觉赖以形成的单轮评测更吵。
标准的排行榜做法让这件事完全不可见。SWE-bench 及其多数亲戚都是每个实例只评一次，报一个不带区间的数字，于是读者无从知道第 3 名与第 6 名之间的差距是不是真的。任何不带置信区间发布的智能体分数，都该被当作一个精度未知的点估计——因为它就是。怎么读这些数字，见2026 年基准全景。
pass@k 与 pass^k 回答的是相反的问题。
两个指标只差一个字符，指向却相反。pass@k 是 k 次尝试中至少一次成功的概率。它随 k 上升，衡量的是能力：给它重试的机会，这模型到底做不做得到？pass^k 是 k 次尝试全部成功的概率。它随 k 下降，衡量的是可靠性：每次有客户来问，这东西都能成吗？
你要哪一个，直接由"谁在消费这个输出"决定。如果每个结果都有人复核、能重试，pass@k 是诚实的指标——你确实有 k 次机会。如果智能体是无人监督地行动，pass@k 就是幻想，因为你的用户只有一次尝试，而且他们不知道自己拿到的是不好的那一次。
两者之间的差距不是四舍五入的误差。为工具型智能体任务引入 pass^k 的 τ-bench 工作报告过：前沿模型单次尝试在 60% 上下，跨八次则塌到四分之一左右——同一个智能体、同一批任务、两个不同的问题。在各类智能体基准上，pass^1 与 pass^4 之间相差十五到二十五个点是常见的报道。如果你的产品承诺是可靠性，而看板上显示的是 pass@1，那么你的看板在衡量一个你并不出售的东西。
两个都报，永远都报，而且标注清楚。pass@1 是能力的下界，pass^k 是你能承诺什么的上界，而两者之间的距离就是你还没解决的那个可靠性问题的大小。夹在中间的单一数字，恰恰是唯一什么都不告诉你的东西。
方差究竟住在哪里——以及为什么"多跑几遍"是错的杠杆。
接下来这一段会推翻多数团队的直觉。你那个头条分数里的方差可以分解成两个来源，而它们对同一种药并不都有反应。把它对 T 个任务、每个跑 R 遍的平均分写出来：
Var(score) ≈ σ²_between / T + σ²_within / (T · R) σ²_between variance across tasks — some tasks are just harder σ²_within variance across runs — the same task, different draws
加运行次数只会缩小第二项。第一项只被 T 除，无论你重跑多少遍它都纹丝不动。而在智能体基准上，第一项通常是更大的那个，因为任务难度极端不齐——一个基准里有少数几道送分题、一长条中段，还有一些当前没有任何系统能解的。同一任务内的采样波动，跟"改一行配置"与"跨模块重构"之间的差别相比，小得不成比例。
实际后果是：如果你有预算再跑 500 次智能体，把它花在 500 个新任务上买到的精度，高于花在给现有 100 个任务各多跑 5 遍上。团队之所以伸手去要重复次数，是因为重复"感觉像严谨"，然后他们纳闷区间怎么几乎没动。区间几乎没动，是因为他们攻打的是本来就已经很小的那一项。
两条值得直说的推论。做自助法（bootstrap）时重采样的是任务，不是运行——任务才是独立观测的单元，而在运行上做自助法会报出一个窄得离谱的区间。以及，当你实在加不了任务时，至少别再假装手上这些比它们实际更有信息量：一个 50 题的评测在中段分数上的 95% 区间约为 ±14 个点，宽到只能检出那些根本不需要统计学就能看见的变化。
配对：不花钱却买到一切的那处改动。
你几乎从来不关心一个绝对分数。你关心的是差值——新提示词对旧的、模型 A 对模型 B、带检索器对不带。而只要你测得对，一个差值可以比构成它的那两个数字精确得多。
让两个系统跑同一批任务、用同一批种子，然后逐任务比较。第 3 步里那个占主导的项——任务间方差——会在差值里完全抵消，因为难题对两个系统都难，它的难度对两个分数贡献相同。剩下的只有逐任务差值的方差，而那要小得多。
在一个 500 题基准上（SWE-bench Verified 正是这个规模）的算术：
- 非配对。50% 附近的分数标准误约 2.2 个点，于是 95% 区间约 ±4.4。独立地比较两个这样的分数，差值要越过大约 6 个点你才敢下判断。
- 配对。假设两个系统在 500 题中的 460 题上一致、40 题上分歧。只有不一致的那些配对携带信息。差值的标准误约为 √40 / 500 = 1.3 个点，95% 区间约 ±2.5。
同样的数据、同样的成本，可检测效应降了一半以上。这就是 McNemar 检验，它有一百年历史，而且正是这种形状的比较的正确工具。把它摆在合并之前的那套做法见评测驱动开发与 CI 中的回归评测；本页讲的，是那道门禁该跑的这个统计量。
配对有一个人们会跳过的前提：两次运行之间必须只差你正在测的那一件事。如果你换了提示词，而供应商恰好在同一周更新了模型快照，那么你的配对比较同时在测两件事，并把全部功劳记到你头上。把模型版本钉死、把评判器钉死、把工具版本钉死，然后把这三样都记进评测日志。
具体跑多少遍。
诚实的答案是"取决于你要检出多大的效应"，但下面这些默认值站得住脚，而且便宜到真的能被采纳：
- 每个任务至少 5 遍，用你生产环境的温度。低于 5 遍，你根本估不出任务内方差，更算不出任何有用的 k 的 pass^k。5 遍不算多大的统计功效，它只是"这些数字不再无法解释"的下限。
- 报中位数和 5–95% 区间，别报最好那一遍。跨多遍取最大值是这个领域里最常见的一种无心作弊：它是一个有偏估计量，且花的钱越多它越好看，于是它奖励的是预算而不是质量。
- 在任务上做 10,000 次重采样的自助法来求区间。这是几秒钟的 CPU，而且不是可选项——不带区间的分数不算一个结果。
- 上面所有项都不如配对设计优先。如果被迫在"非配对跑 5 遍"和"固定种子集配对跑 1 遍"之间选，选配对。
成本是真正的约束，值得如实说出来：500 个任务各跑 5 遍就是 2,500 条智能体轨迹，按智能体的价格算，那是一条实打实的预算。两种可行的缓解。其一，给你的套件分层——一个小而快的子集卡每个 pull request，完整的配对比较每晚或每个版本跑一次。其二，别忘了每完成一个任务的成本本身就是你该追踪的数字，而一个需要试三次的"便宜"配置并不便宜。普林斯顿的 HAL 框架把"每解一题的成本"当作一等维度，正是出于这个理由；见 HAL 与异步智能体评测。
决策规则，以及它挡掉的那些失败方式。
把上面这一切变成一条你的团队不必重新推导就能用的规则：不要基于小于区间半宽的差值去行动。不是"记下来当个有希望的趋势"，不是"方向是正的就先上"——就是不要行动。如果这个差值重要到值得据以行动，那它就重要到值得一直测到它越过门槛；而如果在完整套件上用配对设计它始终越不过去，那它本来就不存在。
这条规则直接干掉三种失败方式：
- 在噪声上棘轮式推进。接受每一个差值为正的改动，就等于接受了大约一半的空操作改动，然后把它们永久烤进去。一个塞满了"每个都提升了两个点"的提示词微调的代码库，就是一个塞满了累积抛硬币结果的代码库。
- 重跑到绿为止。如果门禁失败后有人一直重跑到它通过，那么这道门禁现在衡量的是毅力。固定种子集，跑一次，把结果当作最终结果——重跑必须是一个刻意的、被记录在案的决定，不是一个按钮。
- 拿不可比的两次运行相比。上个月那个数字是在一个已经不存在的模型快照上跑出来的。它不是基线，它是回忆。永远把基线和候选放在同一批里重跑。
如果这个季度只改一件事，就改成配对。固定一个种子集，让基线与候选在同一批里跑同一批任务，报出带自助法区间的逐任务差值，然后拿这个区间当门禁，而不是拿两个分数中的任何一个。它相对你已经在花的算力不多花一分钱，把你能检出的效应量大约砍半，并且移除了这门学科里最大的一个"自信而错误"的来源。本页其余内容都是精修；这一条才是全部回报。