FindStatBench: Evaluating Large Language Models on Combinatorial Code Synthesis
本文介绍了 FindStatBench，这是一个用于评估大型语言模型在组合代码合成方面能力的、严谨的基于执行的基准测试，研究揭示了尽管顶尖模型在性能上趋于收敛，但其准确性受到长提示词、示例在某些任务中产生的反直觉负面影响，以及映射合成（map synthesis）相比统计合成（statistic synthesis）具有更高固有难度这三方面的显著阻碍。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你正在试图教一个机器人如何成为一名数学家。你不仅仅是想让它聊聊数字；你希望它能写出解决谜题的实际代码。这就是**组合代码合成（combinatorial code synthesis）**的世界。把“组合学（combinatorics）”看作是对事物如何排列、洗牌或计数的研究——比如计算有多少种方式可以堆叠积木、排列一副扑克牌，或者在不让两种颜色接触的情况下为地图着色。“代码合成（code synthesis）”则简单来说就是让 AI 编写一个执行这些数学运算的计算机程序。
长期以来，我们一直在通过通用的编程任务来测试 AI，比如“写一个对姓名列表进行排序的函数”或“修复这个网站上的漏洞”。但这些测试有点像是在测试一位厨师是否会切洋葱；它们展示了厨师是否知道如何握刀，但不能展示他们是否能从头开始发明一道新菜谱。这篇论文提出了一个更难的问题：如果你给 AI 一个严格的、抽象的数学规则和几个示例，它能否写出一个完美的程序，使其能够遵循该规则处理任何可能的输入，甚至是它从未见过的输入？这就像是区分一个只会照着食谱操作的机器人，和一个理解烹饪化学原理以至于能够发明从未存在过的菜肴的机器人。
伟大的数学代码挑战：FindStatBench
欢迎来到 FindStatBench，这是一个全新的、超级硬核的 AI 训练场。该基准测试由 Scale AI 的研究人员创建，旨在压力测试大语言模型（LLMs）将纯数学描述转化为可用 Python 代码的能力。研究人员并没有要求 AI 编写简单的脚本，而是给了它 2,329 个不同的数学谜题。这些谜题来自一个名为 FindStat 的真实世界数据库，它就像是一个关于置换（排列列表）、图论（点与线的网络）和划分（将数字分解为求和形式）的“数学食谱”库。
游戏规则非常严格且属于“闭卷”性质。AI 会得到一个数学问题的描述以及最多五个输入输出示例。它必须编写一个名为 solve(obj) 的单一 Python 函数，该函数必须能够处理任何对象，而不仅仅是它看到的那些示例。AI 不能使用计算器，不能搜索互联网，也不能寻求帮助。它必须在第一次尝试时就做到正确无误。为了确保 AI 不是在死记硬背答案，研究人员使用 552 万个隐藏测试用例对代码进行了测试——这些是 AI 从未见过的数百万个数学问题。如果代码在其中任何一个隐藏测试中失败，就会被判定为错误。
结果：令人惊讶的平局与一些奇怪的故障
当尘埃落定后，结果非常有趣，甚至有些违反直觉。
1. “大”模型与“小”模型并驾齐驱
你可能会预期最昂贵、最强大的“闭源”模型（即那些你需要向大公司付费使用的模型）会碾压“开源”模型（即任何人都可以下载并运行的模型）。但在这种以数学为重心的竞技场中，情况并非如此。表现最好的开源模型 gpt-oss-120b 的得分几乎与表现最好的闭源模型 Claude Sonnet 4.6 持平。两者的差距不到 1 个百分点。这就像两名马拉松选手：一个拥有庞大企业赞助和豪华团队，另一个则是穿着自制鞋子的当地英雄。他们几乎在同一时间冲过了终点线。
更令人惊讶的是，如果你将测试的全部 11 个模型中的最佳答案结合起来，你只能将总分提高约 10%。这表明所有这些模型都遇到了一个类似的“能力天花板”。它们都在同一个难题上挣扎。
2. 示例过多反而可能适得其反
这里出现了一个奇怪的现象。在大多数 AI 测试中，给模型更多示例有助于它学习。但在 FindStatBench 上，对于某些被称为“双射（bijections）”（一种高级的“完美匹配规则”）的数学谜题，给模型提供五个示例的表现实际上比提供零个示例还要差。
想象一下你在教一名学生折纸鹤。如果你只说“把纸这样折”，他们可能会记住那个经典的、完美的折法。但如果你向他们展示五个别人折得略显凌乱的例子，学生可能会感到困惑，并试图模仿那些凌乱的折法，从而忘记了完美的规则。论文发现，对于某些经典的数学规则，示例会“挤掉”AI 的内部知识，导致它写出无法通过甚至连示例本身都无法通过的代码。这是一个“信息过多，理解不足”的案例。
3. “思考”陷阱
另一个重大发现是，一些模型，尤其是那些设计为在说话前先进行“思考”的模型，经常会耗尽空间。这些模型对生成的文本量有限制。有时，它们会把整个“预算”都花在写下内部推理过程（它们的思考过程）上，最后根本没机会去写实际的代码。这就像一名学生在考试时间里把时间全花在写一篇关于考试有多难的日记上，最后因为没时间而没能真正解题。研究人员发现，仅仅是给这些模型更多的空间来书写它们的想法（以及代码），就能解决很多这类失败。
4. 硬核内容依然很难
虽然 AI 在某些任务（如计数或处理简单形状）上做得相当不错，但在其他任务上却完全失败了。对于涉及“集合划分（set partitions）”（以各种可能方式对项目进行分组）和“二叉树（binary trees）”（层级结构）的任务，无论开源还是闭源模型，准确率几乎都接近于零。似乎无论模型规模有多大，或者成本有多高，这些特定类型的结构化谜题目前仍超出了它们的能力范围。
这意味着什么
论文得出结论，虽然 AI 在编写“看似合理”的数学代码方面已经变得非常出色，但在面对精确的符号规则时仍然很脆弱。模型可以经常猜对答案，但在为复杂结构推导出完美的逻辑方面仍面临困难。
最大的启示是？成本并不总是等于能力。 在这项特定的测试中，一个更便宜的开源模型的表现与最昂贵的专有模型不相上下。而且有时，给 AI 更多示例或更多的“思考时间”并不会有帮助——它反而会干扰 AI。研究人员建议，要真正掌握数学，AI 需要变得更擅长理解游戏的“规则”，而不仅仅是记住“招式”。目前来看，AI 是一位才华横溢的学徒，它能很好地遵循指令，但一旦被要求发明一种新的几何学，就会迷失方向。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。