🤖 machine learning

Is Code Better Than Language for Algorithmic Reasoning

本文表明，对于工具增强型语言模型而言，代码在算法推理方面相较于自然语言的性能优势主要源于可靠的外部执行，而非中间代码表示本身，因为代码模拟推理相比自然语言推理并未产生显著增益。

原作者： Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

发布于 2026-06-16

📖 1 分钟阅读☕ 轻松阅读

原作者： Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下你正在试图解决一个非常棘手的数学谜题。你有两种主要的解决方式：

“演说家”模式（The "Talker" Method）： 你要求一位聪明的助手用纯正的英语进行逻辑思考，一步步地在脑海中推导，然后告诉你答案。
“程序员”模式（The "Coder" Method）： 你要求同一个助手编写一段计算机程序来解决这个谜题，然后你让计算机实际运行这段程序来获取答案。

长期以来，人们注意到“程序员”模式通常效果更好。但没人确定其中的原因究竟是什么。是因为编写代码迫使助手思考得更清晰了？还是因为让计算机运行代码比信任助手在脑海中进行数学计算要可靠得多？

这篇论文设计了一个巧妙的实验，旨在弄清楚哪个因素才是真正的功臣。

三条路径实验

作者创建了一条“三车道高速公路”来测试这一点，使用了包含 40 个算法谜题（如排序列表、寻找路径或进行复杂数学运算）的基准测试。

路径 1（纯粹的演说家）： 助手完全使用英语解决问题。它进行思考，写下一段推理过程，然后给出答案。
- 结果： 它的正确率约为 17%。
路径 2（伪装的程序员）： 助手编写了代码（如 Python），但随后假装在运行它。助手并没有将代码交给计算机，而是阅读自己的代码并在脑海中模拟执行步骤，最后用英语写出结果。
- 结果： 它的正确率约为 17%。
- 重大发现： 这与路径 1 的结果几乎完全相同。编写代码并没有帮助助手更好地思考；它只是改变了思考的形式。
路径 3（真正的程序员）： 助手编写了与路径 2 中完全相同的代码，但这一次，它将代码交给了一个真实的计算机（Python 运行时）去执行。
- 结果： 它的正确率约为 49%。

“为什么”背后的奥秘

论文使用了几种极具创意的手段来解释这些结果：

1. “翻译”类比（表示法 vs. 执行）
把“追踪过程”（推理步骤）想象成一份食谱。

路径 1 是用长篇累牍、辞藻华丽的故事写成的食谱。
路径 2 是同样的食谱，但被写成了一份严格、结构化的清单。
路径 3 是那份严格的清单，但不再是让人类厨师去阅读并猜测结果，而是交给了一个机器人厨师，由它完美地执行指令。

实验表明，将食谱从故事（英语）改为清单（代码），并没有让这位人类厨师变得更聪明。无论是在读故事还是读清单时，这位人类厨师（LLM）犯的错误都是一样的。性能的大幅跃升只发生在机器人厨师（计算机执行器）接手之后。

2. “干扰”理论（The "Nuisance" Theory）
作者认为自然语言充满了“噪声”。你可以用一千种不同的方式表达同一个意思（“把数字相加”、“求和”、“把它们凑在一起”）。这种额外的多样性会让模型感到困惑。代码则更加严谨；它表达同一事物的方式较少。
然而，论文证明了即使代码更加“干净”，模型仍然无法仅凭自身力量利用这种简洁性来解决数学问题。代码并不会神奇地赋予模型新的数学技能。

3. “恢复”测试（The "Recovery" Test）
作者观察了那些计算机得出正确答案、但人类助手（模拟代码执行）却得出错误答案的情况。这种情况发生的频率为 33%。
反之，他们观察了那些计算机失败（可能是代码有误）但人类助手却猜对答案的情况。这种情况仅发生了 1.6%。
这证明了计算机是一个比人类助手模拟代码执行要可靠得多的“执行器”。

结论

论文的结论是：代码之所以优于语言，并不是因为它是一种更好的“思考”方式。

使用代码的优势不在于它强迫 AI 变得更聪明，而在于代码允许 AI 将工作移交给一台不会犯数学错误的机器。

瓶颈： 问题不在于 AI 不能写出好的代码，而在于 AI 很难检查自己的工作或在脑海中进行数学运算。
解决方案： 真正的力量来自于工具（运行代码的计算机），而不是语言（代码本身）。

简而言之：如果你想让 AI 解决一个困难的数学问题，不要只是让它写代码并寄希望于它能算出答案。你应该让它写代码，然后让计算机实际运行它。 这才是奇迹发生的地方。

技术摘要：在算法推理中，代码是否优于语言？

问题陈述

在工具增强型语言模型（LLM）系统中，已有一项共识：将问题转化为可由求解器执行的代码（将执行权委托给外部工具），在处理复杂算法任务时通常优于端到端的自然语言（NL）推理。然而，这种性能提升的来源仍存在歧义。先前的比较混淆了两个截然不同的因素：

中间表示（Intermediate Representation）： 从自然语言轨迹向代码轨迹的转变。
执行机制（Execution Mechanism）： 从基于 LLM 的模拟（前向传播）向确定性外部执行（例如 Python 运行时）的转变。

由于之前的研究直接将“自然语言推理”与“代码 + 外部执行”进行对比，因此无法隔离出这种改进究竟源于代码的结构化特性、外部执行器的可靠性，还是两者兼而有之。本文旨在探讨以下研究问题：代码表示本身在算法推理中本质上优于自然语言吗？还是说这种优势主要由可靠的外部执行所驱动？

方法论：三路径框架

为了将表示与执行解耦，作者提出了一个系统的三路径框架，将推理流水线分解为两个阶段：轨迹生成（Trace Generation）和执行（Execution）。

路径 1（直接自然语言）： LLM 生成自然语言思维链（CoT）轨迹，随后使用同一个 LLM 来模拟推理并产生答案。
- 轨迹： 自然语言。
- 执行器： LLM（自然语言模拟）。
路径 2（代码 + 自然语言模拟）： LLM 生成代码轨迹（如 Python），但并非进行外部执行，而是由同一个 LLM 在自然语言中模拟代码执行以产生答案。
- 轨迹： 代码。
- 执行器： LLM（代码模拟）。
路径 3（代码 + 求解器执行）： LLM 生成与路径 2 相同的代码轨迹，但该代码由确定性的外部 Python 运行时执行。
- 轨迹： 代码。
- 执行器： 外部求解器（确定性）。

实验设置：

基准测试： 一个包含 40 个任务的可验证算法基准，涵盖算术、动态规划、图算法、字符串处理、几何、排序和 NP 难优化问题。
数据： 跨 3 个随机种子的 1,113 个唯一问题实例，在 6 个模型（包括闭源模型如 GPT-4o-mini 和开源模型如 Mixtral-8x22b）上进行评估。
指标： 基于 0–1 损失的最终任务准确率，通过配对统计检验（McNemar）和聚类自助法置信区间进行分析。

核心贡献

1. 因素的经验解耦

该框架允许进行隔离特定变量的成对比较：

路径 1 vs. 路径 2（隔离表示）： 通过保持 LLM 执行器不变，仅改变轨迹的模态（自然语言 vs. 代码），作者测试了代码表示本身是否提供优势。
路径 2 vs. 路径 3（隔离执行）： 通过保持代码轨迹不变，仅改变执行器（LLM 模拟 vs. Python 运行时），作者测试了执行机制是否是性能驱动因素。

2. 理论形式化（决策论模型）

作者将“代码是自然语言的一种规范化（canonicalization）”这一直觉进行了形式化。他们提出了一个线性模型：

两种轨迹都共享一个包含决策相关算法信息（如递推关系）的核心 ( $B$ )。
自然语言轨迹包含额外的干扰变异 ( $\eta_N$ )，例如释义、冗余性和风格选择，这些变异并不改变答案。
定理： 在此模型下，代码是**表示非劣于（representation-non-inferior）**自然语言的。自然语言中的额外干扰增加了有限样本学习者的风险（误差），却未提供额外的信号。因此，如果核心信息得以保留，仅改变表示形式不应产生显著收益。

3. 重构干预

为了从经验上验证该理论，作者进行了“重构干预”。他们获取由模型生成的代码轨迹，并使用固定的转换将其翻译回自然语言。他们发现，这些翻译后的自然语言轨迹恢复了与原生自然语言轨迹相当的性能。这证实了代码保留了所有决策相关的信息，且自然语言推理中的“损失”并非源于缺失算法内容，而是源于干扰变异的存在。

结果

性能比较

在 40 个任务的基准测试中，结果如下：

路径 1 (NL + NL)： 17.21% 准确率。
路径 2 (Code + NL Sim)： 17.37% 准确率。
路径 3 (Code + Python Exec)： 48.84% 准确率。

统计发现：

路径 1 vs. 路径 2： 差异为 +0.15 个百分点 (pp)，其 95% 置信区间为 $[-0.30, +0.61]$ pp ( $p=0.39$ )。这表明当执行器为同一 LLM 时，自然语言推理与代码模拟之间没有显著差异。
路径 2 vs. 路径 3： 差异为 +31.47 pp，其 95% CI 为 $[+29.20, +33.71]$ pp ( $p < 0.001$ )。这表明，即使代码轨迹完全相同，确定性的外部执行也比 LLM 模拟具有巨大的、统计学显著的优势。

难度缩放

随着任务难度增加（通过控制参数如数字长度或矩阵大小），路径 3 保持了较高的准确率，而路径 1 和路径 2 则显著下降。

恢复分析

作者分析了路径 2（模拟）成功但路径 3（执行）失败的情况（“恢复质量”）。

恢复质量 (Recovery Mass)： 1.61%（LLM 正确模拟了有缺陷的代码或忽略了执行失败的情况）。
执行获胜质量 (Execution-Win Mass)： 33.08%（执行成功但 LLM 模拟失败的情况）。
这证实了 LLM 很少能补偿执行错误；相反，外部求解器始终优于 LLM 模拟代码的能力。

意义与主张

本文声称，在评估的算法推理场景中：

表示不是瓶颈： 使用代码轨迹作为中间干预手段，在执行机制仍为 LLM 的情况下，并不会比自然语言轨迹显著提高性能。路径 1 与路径 2 之间的性能差距微乎其微。
执行是瓶颈： 在工具增强型系统中观察到的性能提升，其主要驱动力是外部执行器的可靠性，而非代码表示本身的结构化特性。
工具使用的机制： 基于代码的工具使用之所以具有优势，是因为它能够实现将生成的轨迹移交给确定性求解器。代码表示的主要作用是作为实现这种可靠执行的载体，而非作为一种优于自然语言的推理基质。

作者得出结论：对于具有可验证答案的算法任务，使用工具的核心优势在于能够将执行委托给确定性环境，而非代码作为一种比自然语言更优的推理格式。