GSM-Hard

为什么重要

GSM-Hard 是 PAL（Program-Aided Language Models） 论文里构造的一个变体集，目的很直接：GSM8K 的题数字都很小，模型可以靠「背过的中间结果 + 模式匹配」蒙对。把数字换成七位数、八位数之后，心算路径彻底失效——要么生成程序让解释器算，要么就得老实做长乘法。

这项基准的历史价值在于，它是「工具使用能补上推理短板」这条路线最早的量化证据之一：直接生成自然语言推理链（CoT）的准确率很低，而让模型输出 Python 程序再交给解释器执行，准确率大幅提升。这条结论后来发展成整个「代码即推理」的思路，也间接催生了今天各种带代码执行器的 Agent 架构。

今天 GSM-Hard 本身已经接近饱和——主流模型配上解释器都能做对大部分。但作为「算术鲁棒性」的最小检验它仍然好用：想快速判断一个模型是真的在算还是在猜，往里灌大数是最省事的办法。

构建方式

1. 取 GSM8K 测试集的题目
2. 把题面里出现的数值替换成随机大整数（通常是 7 位以上）
3. 用原题自带的求解程序重算正确答案，保证参考答案精确
4. 评测时允许两种解法：直接生成自然语言推理，或生成 Python 程序交给解释器执行

任务示例

原题：

面包店做了 12 个蛋糕，卖出 7 个，还剩几个？

GSM-Hard 变体：

面包店做了 3,724,109 个蛋糕，卖出 1,958,463 个，还剩几个？

正确做法（PAL 风格）是输出程序而不是硬算：

made = 3724109
sold = 1958463
remaining = made - sold

最新进展

• PAL 论文用它证明：程序辅助推理相比纯 CoT 有大幅增益，且增益随数字规模变大而扩大
• 随着主流模型普遍具备代码执行能力，GSM-Hard 的区分度明显下降，目前更多作为回归测试而非前沿标尺
• 它的思路被继承到更难的数学基准里：把「需要精确计算」作为一道独立的难度维度

关键发现

• 心算不可靠，程序可靠：LLM 的算术能力随位数增加急剧下降，但生成正确程序的能力下降得慢得多
• 「会算」和「会建模」是两件事：GSM-Hard 分离了这两者——建模对了但算错了，在这里会直接暴露
• 工具使用是最廉价的能力补丁：不需要改模型，给个解释器就能补上算术这块短板
• 饱和提醒：现在模型基本都能过，用它做选型判断已经不够，需配合更难的数学基准