推理、代码，还是两者兼有？大型语言模型如何处理数学问题的变化

# 推理、代码，还是两者兼备？大型语言模型如何处理数学问题的变体
来源：https://arxiv.org/html/2605.26414
###### 摘要

大型语言模型（LLM）在数学推理基准测试中达到了令人瞩目的准确率，但当问题被简单修改（如更换名字或数字）时，其性能会下降。代码执行方法——让模型生成并运行Python代码而非用自然语言推理——被认为是一种解决方案，但其对推理鲁棒性（即面对问题变体时保持准确性的能力）的影响尚未得到系统检验。本研究在GSM-Symbolic数据集中的1000个问题上评估了三种方法：纯推理（使用思维链提示）、单次代码执行（使用程序辅助语言模型PAL）以及迭代代码执行（使用逐步编码SBSC）。三种方法均在配对的原问题与修改后问题上使用Claude Haiku 4.5运行。CoT是最鲁棒的方法，准确率下降1.3个百分点，1.8%的问题在扰动下出错；而PAL最不鲁棒，准确率下降1.7个百分点，3.1%的问题出错，SBSC介于两者之间。尽管这些差异在统计上不显著（p=.096），但所有指标上的趋势方向一致，表明无论是单次还是迭代代码执行，在小学校级问题变体上都不能提升推理鲁棒性。

††publicationid:pubid: © 2026 Matthew Kutakh

## 一、引言

大型语言模型（LLM）表现出非凡的性能，顶级模型在国际数学奥林匹克题目集上达到了金牌水平[3 (https://arxiv.org/html/2605.26414#bib.bib5)]。尽管如此，在简单数学题上仅做微小修改或添加无关内容时，它们的性能会急剧下降[5 (https://arxiv.org/html/2605.26414#bib.bib1)]，这引发了关于这些模型推理鲁棒性的根本问题。迭代代码执行作为一种有前景的方法由此进入视野，它将不可靠的语言转化为可执行代码[2 (https://arxiv.org/html/2605.26414#bib.bib2),7 (https://arxiv.org/html/2605.26414#bib.bib6)]，但其真正效果尚未得到系统性的探索。

请参见说明图1：实验设计概览。每种方法在GSM-Symbolic主集的1000个配对原问题和修改后问题上进行了评估。结果被分类为“出错”（原问题正确，修改后错误）、“修复”（原问题错误，修改后正确）或“保持”（两个结果相同）。
## 二、文献回顾

本文中，数据集是固定的问题集合及其对应答案。基准测试是利用数据集评估LLM的方式：将问题输入模型，从输出中提取数值答案并与预期答案比较，从而评估模型在给定数据集上正确回答问题的数量[1 (https://arxiv.org/html/2605.26414#bib.bib7),5 (https://arxiv.org/html/2605.26414#bib.bib1)]。

数学推理基准测试对于评估LLM的认知能力至关重要。GSM8K是一个包含8500道小学级数学题的数据集，“一个聪明的中学生应该能够解决”[1 (https://arxiv.org/html/2605.26414#bib.bib7)]，它常被用于基准测试LLM的数学推理能力。然而，这种方法的一个根本缺陷是：新模型会被训练于现有的互联网数据，而这些数据可能已包含该数据集。

GSM-Symbolic是基于原GSM8K创建的另一数据集，其中的信息片段（如问题中的数字或人物名字）被更改。GSM-Symbolic通过创建从未出现在互联网上的问题来应对这一评估缺陷，使得这些题目不可能存在于训练数据中[5 (https://arxiv.org/html/2605.26414#bib.bib1)]。GSM-Symbolic引入了推理鲁棒性的概念，指LLM在面对保持结构和难度的微小问题表述变化时，仍能保持其数学推理准确性的能力[5 (https://arxiv.org/html/2605.26414#bib.bib1)]。大型语言模型在原数据集与GSM-Symbolic之间表现出高达15%的性能差异，而两组问题之间唯一的区别是名字和数字，这些并不从根本上改变解决问题所需的推理[5 (https://arxiv.org/html/2605.26414#bib.bib1)]。更关键的是，当看似相关但逻辑上无关的条款被添加到问题时，所有最先进模型的性能显著下降，最高达65%[5 (https://arxiv.org/html/2605.26414#bib.bib1)]，这引发了人们对模型在现实场景和高风险应用中的可靠性的担忧。这种性能下降表明LLM可能依赖模式匹配而非真正的逻辑推理[5 (https://arxiv.org/html/2605.26414#bib.bib1)]。

作为针对上述问题的解决方案，代码执行方法应运而生。它使LLM能够生成并执行代码，然后将执行结果纳入模型的推理过程。程序辅助语言（PAL）模型证明了：将计算任务卸载到Python解释器，同时保持LLM进行问题分解，能显著提高纯推理或思维链（CoT）的准确性[8 (https://arxiv.org/html/2605.26414#bib.bib3),2 (https://arxiv.org/html/2605.26414#bib.bib2)]。

迭代代码执行是对该解决方案的改进。它允许LLM编写并运行代码，获取执行结果。但与单次代码执行不同，它会多次重复这一过程，使AI能够纠正之前的任何错误。例如，迭代代码执行的实现之一——逐步编码（SBSC）——已在数学竞赛题目上显示出优于单次代码执行的表现[7 (https://arxiv.org/html/2605.26414#bib.bib6)]。

Mirzadeh等人[5 (https://arxiv.org/html/2605.26414#bib.bib1)]通过GSM-Symbolic证明，当问题中的名字和数字被简单更改而保持原有结构时，最先进模型的性能下降高达15%。Shalyt等人[6 (https://arxiv.org/html/2605.26414#bib.bib8)]通过ASyMOB将这一发现扩展到符号化的大学级数学，显示大多数模型在扰动下的平均性能下降为50.4%。这些发现表明LLM架构存在一个根本限制：LLM执行的是复杂的模式识别而非形式化推理[5 (https://arxiv.org/html/2605.26414#bib.bib1)]。

针对这些限制，研究者探索了代码执行以将计算卸载给可靠的解释器，结果显示出混合的鲁棒性表现。为了更好地评估算术鲁棒性，Gao等人[2 (https://arxiv.org/html/2605.26414#bib.bib2)]开发了GSM-HARD，这是GSM8K的一个版本，使用更大的数字，在保持问题结构的同时挑战模型的算术能力。他们开发并展示了程序辅助语言模型如何在思考过程中利用代码执行，其表现优于纯CoT模型，准确率仅下降14.3%，而CoT模型下降约70%。然而，Li等人[4 (https://arxiv.org/html/2605.26414#bib.bib4)]通过引入GSM-Plus基准测试揭示了关键限制。GSM-Plus是GSM8K数据集的一个变体，通过八种不同的扰动类型测试数学推理。结果显示，虽然基于程序的方法在数值扰动上仅下降了11.8%（CoT为14.0%），但在插入不必要信息时，它们表现出显著更高的脆弱性（40.6%至43.9%），而CoT为31.8%至39.4%。作者得出结论：代码执行模型在算术变化应用于问题时表现出色，但在语义理解上存在困难，这挑战了代码执行是提高LLM鲁棒性的通用工具这一假设。

基于这些见解，研究者探索了带有反馈回路的迭代代码执行。Singh等人[7 (https://arxiv.org/html/2605.26414#bib.bib6)]介绍了逐步编码（SBSC），这是一种具有反馈回路的迭代代码执行模型。与单次代码执行和纯推理相比，它显示出显著改进，在AMC上提高了10.7%，在AIME（美国最高级别的数学竞赛之一）上提高了8%。尽管该论文未测试该方法的鲁棒性，但它清楚地展示了在数学问题解决上优于单次执行的优点，暗示了其在改进LLM鲁棒性方面的潜力。

## 三、研究空白

尽管基于代码的数学推理取得了显著进展[2 (https://arxiv.org/html/2605.26414#bib.bib2),7 (https://arxiv.org/html/2605.26414#bib.bib6),4 (https://arxiv.org/html/2605.26414#bib.bib4)]，但仍存在一个关键空白：即这些方法到底是提升了推理鲁棒性，还是仅仅提高了计算准确性。虽然GSM-Symbolic已经暴露了LLM推理在面对问题变体时的脆弱性[5 (https://arxiv.org/html/2605.26414#bib.bib1)]，但现有的代码执行研究（如PAL、SBSC和工具集成推理TIR）都是在GSM8K和MATH等静态数据集上评估迭代和单次代码执行方法的性能[2 (https://arxiv.org/html/2605.26414#bib.bib2),7 (https://arxiv.org/html/2605.26414#bib.bib6),4 (https://arxiv.org/html/2605.26414#bib.bib4)]。然而，目前还没有研究评估代码执行和迭代代码执行在面对问题变体（如GSM-Symbolic）时的性能表现。

## 四、研究问题与假设

本研究旨在回答以下研究问题：与单次代码生成和纯推理方法相比，迭代代码执行是否能在GSM-Symbolic的问题变体上改善推理鲁棒性？

我假设单次代码执行（PAL）对GSM-Symbolic扰动最为鲁棒，其次是纯推理（CoT），而迭代代码执行（SBSC）最不鲁棒。这一预测基于两个先前的研究结果。首先，Gao等人[2 (https://arxiv.org/html/2605.26414#bib.bib2)]显示，在GSM-HARD的算术扰动下，PAL大大优于CoT，这表明将计算卸载给Python解释器在问题变体涉及数值变化时能提高鲁棒性。其次，尽管Singh等人[7 (https://arxiv.org/html/2605.26414#bib.bib6)]证明了SBSC在竞赛级数学上优于单次代码执行，但其迭代结构预计会放大而非纠正小学级问题上的错误形式化问题，因为单个错误设置会传播到每一个后续步骤。

## 五、方法

为了回答研究问题，我们进行了一项实验。实现了三种方法：纯推理、单次代码执行和迭代代码执行。每种方法都包含一组工具和指令，迫使LLM以不同方式解决问题。这些方法基于三篇关键论文中描述的方法：纯推理方法遵循GSM-Symbolic中的思维链（CoT）方法[5 (https://arxiv.org/html/2605.26414#bib.bib1)]，单次代码执行基于PAL[2 (https://arxiv.org/html/2605.26414#bib.bib2)]，迭代代码执行基于SBSC[7 (https://arxiv.org/html/2605.26414#bib.bib6)]。这三种方法在GSM-Symbolic数据集的配对原问题和修改后问题上进行评估（见图1 (https://arxiv.org/html/2605.26414#S1.F1)）。然后，将输出与这些问题的正确答案进行比较，计算每个问题（原问题和修改后问题）的正确与错误答案数量，用于进一步分析。

每次对LLM的请求最多可包含三个主要部分：系统提示、少样本提示和问题本身。系统提示是一组供模型遵循的指令。包含示例问题和解答的少样本提示用于指定所需的模型输出格式。对于本研究使用的问题，采用了8-shot提示（包含8个示例的少样本提示），这是GSM8K和GSM-Symbolic评估的标准做法[5 (https://arxiv.org/html/2605.26414#bib.bib1),1 (https://arxiv.org/html/2605.26414#bib.bib7)]。这8个示例问题取自原始GSM8K数据集。

### 五-A 提示设计

首先，我为三种方法分别构建了初始提示（发送给模型的完整消息，结合了8-shot提示和（对于某些方法）系统提示）。对于CoT初始提示，直接使用了Mirzadeh等人[5 (https://arxiv.org/html/2605.26414#bib.bib1)]的8-shot提示，未作编辑。然而，经过多次LLM模型测试后，为了获得最一致的结果，系统提示从原始的“作为一名专家解题者，逐步解决以下数学问题”改为“遵循示例中提供的格式”。同样出于一致性的原因，添加了前缀“让我们逐步思考”，以确保模型在给出答案之前进行思考。

对于PAL，完整的8-shot提示改编自Gao等人[2 (https://arxiv.org/html/2605.26414#bib.bib2)]的附录J.4，该附录提供了所有8个示例。但为了确保从模型输出中提取答案的可靠性和简便性，格式做了更改：模型的代码不再直接输出最终答案，而是封装在一个函数`def solution():`中，这是一个可复用的代码块，用于计算并将答案传回脚本，从而更容易自动捕获。8-shot中的问题与CoT中的相同，以确保一致性，其顺序也调整为与CoT 8-shot一致[8 (https://arxiv.org/html/2605.26414#bib.bib3)]。由于PAL未使用系统提示，我也未使用。但为了确保一致性，我不得不使用前缀`def solution():`，以迫使模型立即生成代码。

对于迭代代码执行，提示改编自SBSC[7 (https://arxiv.org/html/2605.26414#bib.bib6)]论文；但为了与其他方法一致，原始问题从4-shot的AMC和AIME问题（美国数学竞赛，包含比GSM8K复杂得多的问题）更改为与其他方法相同顺序的8-shot GSM8K问题。8-shot提示的示例解答由Claude AI生成，随后由我检查。解答格式基本保持了Singh等人[7 (https://arxiv.org/html/2605.26414#bib.bib6)]的模式；但为了与单次代码执行保持一致，所有注释（代码中的解释性说明）被移除，转而使用有意义的变量名（如`trees_planted`而非`x`），这与原始PAL论文相同[2 (https://arxiv.org/html/2605.26414#bib.bib2)]。尽管SBSC论文确实提到添加思考链提示的改进，但这里我没有采用。