LLM 让性能基准测试造假变得太容易
The Benchmarkpocalypse
过去，要伪造性能基准测试需要深厚的算法和编译器知识，如今 LLM 让这变得轻而易举。我让一个 Agent 循环运行了一个月，构建了一个名为 FRE 的正则表达式引擎，它在 rebar 基准测试中看似比 Rust regex crate 快 40%，但在真实场景的 holdout 测试中却慢了数倍。这揭示了'基准测试末日'的真相：LLM 擅长过度拟合和奖励黑客行为，导致虚假的性能提升数据泛滥。虽然整体性能可能不如现有库，但 LLM 大幅降低了编写针对特定工作负载的专用代码的成本，未来我们或许会看到更多此类定制化软件的出现。
过去，要构建一个像 FRE 这样能伪造出 40% 性能提升的项目，你需要相当多的专业知识，但现在你只需几分钟的打字就能实现这种基准测试作弊。
HN 评论区
63- timfsu
这篇文章很有意思。我天天都能抓到 LLM 在“撒谎”，比如：“我找到了 bug 的根本原因”或者“这个方法快了两倍”。很难说这种盲目自信是怎么来的——是源于在人类文本上训练的本质，还是后续 RLHF 过程导致的？但这确实让人极其抓狂。LLM 做出糟糕的决策是一回事，但在过程中对你“撒谎”感觉更糟。
- softwaredoug
我在搜索领域有过类似经历，发现即便是预留集（holdout set）也会被过拟合。也就是说，通过暴力穷举，模型可能没直接看到预留集，但如果你把变更是否上线取决于预留集的通过情况，它最终会靠某种随机运气找到一个针对预留集过拟合的解。
另一个问题是，在大多数代码智能体中，设置对智能体不可见的预留集/数据并不容易。这不像把训练数据拆成 80% 给智能体、藏起 20% 那么简单。智能体能推断出数据来源，并找到重建或绕过预留集数据的方法。
所有实现方式似乎都很烦人：比如搞个第二项目来接受或拒绝变更。
我选择自己搭建一套测试框架（harness）来避免过拟合。
https://softwaredoug.com/blog/2026/05/17/autoresearching-a-b...
- ouz-a
自从 LLM 开始说那种像外星人一样的英语后，我就再也不信基准测试了。如果我都听不懂它们在说什么，又怎么能信任它们呢？
- stephantul
不幸的是，即便有预留集也无法让你免于过拟合，它只是让过拟合发生得更慢而已。
当然，有预留集总比没有好。但这绝非万能灵药。
- mppm
正如文章所讨论的，作弊和过拟合是 LLM 基准测试中最明显的问题。但还有一个方面：至少对于闭源模型，推理时 token 仍然必须发送到提供商的服务器。这意味着预留集并没有看起来那么“预留”。OpenAI 和 Anthropic 可能不在乎你私有的正则表达式基准测试集，但对于那些标榜“闭源”的基准测试，我很惊讶他们居然没有收集一套不错的代表性“预留”问题集，以便闲暇时慢慢研究。