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

背景

尽管大型语言模型（LLMs）在数学推理基准测试中取得了令人印象深刻的准确率，但研究表明，当问题被简单的修改（如更改名称或数字）时，其性能往往会下降。这种对输入微小变化的敏感性揭示了模型在“推理鲁棒性”（Reasoning Robustness）方面的潜在缺陷——即模型在面对问题变体时维持准确性的能力。

为了解决这一问题，业界提出了代码执行方法，即让模型生成并运行 Python 代码，而非仅依赖自然语言进行推理。然而，代码执行方法是否真的能提升模型在应对问题变体时的鲁棒性，此前并未得到系统性的测试。

核心内容

本研究旨在评估不同方法在处理数学问题变体时的鲁棒性。研究团队使用了 GSM-Symbolic 数据集中的 1,000 个问题，并针对每个问题生成了对应的“原始版本”和“修改版本”（包含名称或数字的扰动）。实验基于 Claude Haiku 4.5 模型进行，对比了三种主要方法：

1. 纯推理（Pure Reasoning）：使用思维链（Chain-of-Thought, CoT）提示技术，让模型通过自然语言逐步推导答案。
2. 单次代码执行（Single-shot Code Execution）：使用程序辅助语言模型（Program-Aided Language models, PAL），让模型一次性生成完整的 Python 代码并执行。
3. 迭代代码执行（Iterative Code Execution）：使用逐步编码（Step-by-Step Coding, SBSC）方法，让模型分步生成和执行代码。

实验结果分析

研究主要关注两个指标：准确率下降幅度（Accuracy Drop）和问题在扰动下“崩溃”的比例（即从正确变为错误的比例）。

• 纯推理（CoT）：表现最为鲁棒。在问题变体下，准确率仅下降 1.3 个百分点，仅有 1.8% 的问题在扰动后出错。
• 单次代码执行（PAL）：表现最不鲁棒。准确率下降 1.7 个百分点，3.1% 的问题在扰动后出错。
• 迭代代码执行（SBSC）：表现介于两者之间。

统计显著性

尽管数据显示 CoT 方法的鲁棒性优于代码执行方法，且 PAL 最差，但经过统计检验，这些差异并未达到统计显著性水平（$p = .096$）。然而，所有衡量指标均显示出一致的方向性趋势：代码执行方法（无论是单次还是迭代）并未在小学水平的数学问题变体上展现出比纯自然语言推理更好的鲁棒性。

关键要点

• LLM 的脆弱性：大型语言模型对数学问题中的简单扰动（如数字或名称替换）非常敏感，即使是在基准测试中表现良好的模型也是如此。
• 代码执行并非万能药：虽然引入 Python 代码执行旨在提高准确性，但本研究发现，它并没有显著提升模型处理问题变体的鲁棒性。
• 自然语言推理更具韧性：在本研究的实验设置下，基于思维链（CoT）的自然语言推理方法比代码执行方法更能抵抗输入扰动，出错率更低。
• 趋势一致但统计不显著：虽然三种方法的差异在统计上未达到显著性（$p > 0.05$），但方向性趋势一致，暗示代码执行在提升鲁棒性方面可能没有预期优势。
• 模型与数据集：实验基于 Claude Haiku 4.5 模型和 GSM-Symbolic 数据集，主要针对小学水平的数学问题。

意义与影响

这项研究对当前大语言模型在数学推理领域的应用具有重要启示：

1. 挑战“代码即真理”的假设：业界普遍假设生成可执行代码能提供更强的逻辑约束和准确性。然而，本研究结果表明，在应对输入变化时，代码生成过程本身可能引入新的脆弱点，或者代码执行并未像预期那样增强模型的泛化能力。
2. 提示工程的重要性：对于需要高鲁棒性的应用场景，简单的思维链（CoT）提示可能比复杂的代码生成管道更可靠，尤其是在处理结构化但内容可变的数学问题时。
3. 未来研究方向：由于差异未达到统计显著性，未来的研究需要更大规模的数据集或更复杂的扰动类型来确认这一趋势。此外，研究也暗示可能需要探索混合方法，或者改进代码生成中的错误处理机制，以真正发挥代码执行在鲁棒性上的潜力。
4. 评估标准的完善：现有的数学推理基准往往只关注静态准确率，本研究强调了引入“扰动测试”和“鲁棒性指标”的必要性，以更全面地评估模型在实际应用中的稳定性。