- Authors
- Name
- Youngju Kim
- @fjvbn20031
引言 — 排行榜为何变得难以信任
编程模型的 SWE-bench 分数每周都在刷新，可一旦真正接入自己的代码库，就常常会遇到排名和体感对不上的情况。眼下在 GeekNews 上热议的 OpenAI 评测团队（Frontier Evals）的文章 "Separating signal from noise in coding evaluations" 正面处理了这种落差。结论相当强硬 — 最广泛使用的编程基准 SWE-bench Verified 因为污染和设计缺陷，已经无法再给出有意义的信号。
这并不是"基准本来就不完美"这种常见的搪塞。核心是一套方法论 — 把信号（signal）和噪声（noise）分开来看。本文用这个视角重新梳理编程评测，并一路落到团队实际该做什么。
时机也很关键。编程模型几乎每周都有新的，团队越来越频繁地凭排行榜上一个小数点的差距来做实际的选型决定。如果那个差距只是噪声，那这个决定不过是穿着实验服的抛硬币。
信号与噪声这两个维度
Allen Institute for AI（Ai2）的框架把定义给得最为清晰。
- 信号 是基准的 区分力 — 它把更好的模型和更差的模型的分数拉开多远。Ai2 将其测量为"在特定规模下模型之间的离散程度"。
- 噪声 是同一个模型再次运行时（或每个训练检查点）分数发生摇摆的 波动性。
好的基准，这两者的比值 — 也就是 信噪比（SNR） — 很高。有意思的是，大小并不是答案。在 Ai2 的实验里，只用 SNR 高的 16 个 MMLU 子任务，比用全部 57 个更好，误差减少了 32%。 把评分指标从对/错换成 bits-per-byte 后，MBPP 的 SNR 从 2.0 一跃升到 41.8。
Ai2 报告说，这个比值比基准的大小更能预测其有用性 — 换用 SNR 高的指标后，在两个模型中正确选出更好那个的"决策准确率"从 68% 升到了 93%。小而干净的评测，可能比大而嘈杂的评测更可信 — 这是大多数排行榜并不假设的一个直觉。
落到实务上，规则只有一条 — 比较两个分数时，先问那个差距是否大于噪声。 如果排行榜上的第 1 名和第 3 名都落在噪声范围之内，那这个排名就不是信息，而是错觉。
编程基准的噪声从何而来
编程评测的噪声大致来自四个方向。
1）污染（contamination）。 OpenAI 评测团队展示了模型仅凭 task_id 就能几乎原样重现原始的 gold patch 或问题描述。这不是编写软件的 能力，而是 背诵 训练数据的结果。分数会涨，但信号不会涨。
2）评分缺陷（design flaws）。 同一篇文章指出，SWE-bench Verified 剩下的未解决问题中，有 60% 以上按评分标准根本无法通过。有 49 个测试会把功能上正确的提交判为错误，还有 26 个测试要求文档里没有的行为。这是一种即便模型答对也拿 0 分的结构。
3）测试框架与基础设施差异。 Anthropic 测量到，不改动任何模型权重、只调整运行环境，分数就会变化。在 Terminal-Bench 2.0 上，资源给得最充裕的配置与给得最紧的配置之间差了 6 个百分点（p < 0.01），基础设施错误率从 5.8% 降到了 0.5%。这意味着，分出排名的可能不是模型，而是容器配置。
4）基准的过拟合与磨损。 新基准也撑不了太久。为改进 SWE-bench Verified 而推出的 SWE-bench Pro，在独立审计中，按自动流水线口径有 27.4%、按人工复核口径有 34.1% 的任务本身就是坏的。而且同一个模型仅仅换个基准就会大幅摇摆 — 一份报告里，同一模型在 SWE-bench Verified 上约为 81%，在更难的 SWE-bench Pro 上约为 46%。
麻烦之处在于，这些效应并不是单调的。Anthropic 确认，只是适度改变资源余量时，差距会停留在噪声之内（统计上无意义，p = 0.40），但在两个极端却会大幅拉开 — 在 SWE-bench 上，即便给一个任务 5 倍的 RAM，分数也只移动了约 1.54 个百分点。同一个旋钮，在某个区间可以忽略不计，在另一个区间却是决定性的。测试框架差异在你眼前藏身的方式，正是如此。
团队实际该做的事
排行榜对模型开发者也许是信号，但对挑选助手的团队来说，大多是噪声。实务指南可以这样归纳。
- 用自己的任务来评测。 用团队真实的 30~50 个 PR 和 issue 做一个小的私有评测集。比起排行榜第 1 名，"在我们自己代码库上的通过率"是强得多的信号。
- 看置信区间，而不是名次。 Anthropic 的建议很明确 — 对于小于 3 个百分点的排行榜差距，在评测配置被记录并相互对齐之前，都要保持怀疑。
- 选择抗污染的设计。 滚动时间截止的做法（LiveCodeBench）或非公开测试集（GAIA），能从结构上阻止背诵刷分。
- 固定并记录测试框架。 不明确写出提示词、重试、超时、资源上限的比较，就是拿苹果和橙子做对比。
- 如果要公开评测，就先做校准。 Anthropic 的建议是，为每个任务同时标明资源的下限与上限，并让两端的分数彼此落在噪声范围之内 — 否则配置就会悄悄成为分数的一部分。
- 用多种类型做三角验证。 把静态基准、人类偏好竞技场、智能体测试套件放在一起看，某一个维度的噪声就会相互抵消。
- 多跑几次。 一次性的通过/失败运行会把波动藏起来。每个任务跑 3~5 次，就能看见分数的幅度，而那个幅度正是你需要看穿的噪声。
- 警惕饱和。 如果头部模型都挤在几分之内，那个基准就已经不再区分了 — 信号很低，它们之间的顺序几乎是随机的。
具体做法是这样 — 把脚手架固定为一套（同样的提示词、同样的重试策略、同样的超时），让每个模型在私有任务集上跑多次，然后把平均值和幅度一并报告。如果两个模型的幅度重叠，那就没有赢家 — 是平局，此时不如用价格、延迟、许可证来决定。
这一切都收敛到 eval-first 原则。评测集先于模型（或助手）而存在 — 正是 AI 模型开发生命周期一文 中讲过的那个顺序。评测先在，选用哪个模型的决定就不再是口味，而是实验。
结语
分辨信号与噪声，归根结底是谦逊的问题。排行榜最顶端的那几位小数大多是营销，真正的信号是 在你自己的任务上能复现的差异。OpenAI 从污染和评分缺陷出发，Anthropic 从基础设施波动出发，Ai2 从统计区分力出发，但落点相同 — 不要相信单独一个数字，而要问那个数字是否大于噪声。对挑选编程助手的团队来说，比这更实用的建议并不多见。
这并不意味着基准没用 — 对训练模型的人来说，它是不可或缺的工具。只是排行榜是问题的起点，而不是答案。