ReTool 来了！强化学习+代码解释器，让 LLM 数学推理能力飙升

各位股东，大家好呀。我是 Warren。

今天咱们聊个硬核点的，关于大模型（LLM）怎么在数学推理这种需要精确计算和逻辑的地方做得更好。现在很多模型，像 OpenAI 的 o1 或者 DeepSeek R1，搞文本推理挺溜，靠的是强化学习（RL）优化思考链（CoT）。但一碰到需要算数、解方程、搞几何这种硬骨头，纯文本推理就容易抓瞎，错误累积起来没法看。

这时候，代码解释器（Code Interpreter, CI）这种计算工具就显得特别香了，它能精确计算、验证，还能搞点编程探索。问题是怎么让 LLM 聪明地、恰到好处地使用这些工具，而不是瞎用或者不敢用？

今天拆解的这篇论文《ReTool: Reinforcement Learning for Strategic Tool Use in LLMs》，就是来解决这个问题的。他们搞了个叫 ReTool 的框架，用强化学习教 LLM 在推理过程中动态地、实时地调用代码解释器，并且能根据执行结果（对错、报错信息）来调整策略，学习什么时候用、怎么用工具最有效。

一、LLM 推理的困境与工具的价值

咱们都知道，现在的大模型搞文本理解、生成对话那是越来越强了。通过像 CoT（思维链）这样的技术，模型能一步步地思考，解决一些逻辑问题。特别是用了强化学习之后，模型还能自我反思、修正，看起来有点“开窍”了。

但是，光靠“想”，在某些领域是不够的。比如解复杂的数学题，涉及到大量精确计算、符号推演，纯文本推理很容易在中间步骤出错，而且一步错、步步错。这就好比你心算一个超复杂的乘法，算着算着可能就乱了。

这时候，计算器（或者更强的，代码解释器）就派上用场了。代码解释器有几个好处：

1. 精确性：代码执行结果是精确的，不会有模糊地带，能有效避免计算错误。
2. 验证能力：可以用来验证中间步骤的猜想或计算结果。
3. 探索能力：可以通过编程来系统地探索解空间，比如枚举可能性。

简单说，工具能弥补纯文本推理在精确计算和结构化探索上的短板。

之前也有工作尝试让 LLM 用工具，比如通过提示工程（Prompting）或者监督微调（SFT）教模型模仿一些使用工具的例子。但这些方法比较死板，模型只是在“背菜谱”，遇到没见过的场景或者需要灵活决策（比如啥时候该用工具？用哪个工具？代码写错了咋办？）时，就容易掉链子。

所以，ReTool 提出用强化学习（RL）来解决这个问题。RL 的核心思想是“试错学习”，让模型自己去探索不同的策略（什么时候用代码、怎么写代码），然后根据最终结果的好坏（比如题目答对了没）来调整策略。这使得模型能够超越 SFT 的数据限制，自主发现更优、更灵活的工具使用方法。

二、ReTool 的核心方法：两步走策略

ReTool 的方法论主要分两步：

1. 冷启动（Cold-start）：先通过监督微调（SFT），让模型对“如何在推理中使用代码”有个基础认知。
2. 强化学习（RL）：在 SFT 的基础上，通过 RL 让模型在实践中（解决问题）学习更优的工具使用策略。

2.1 冷启动：打好工具使用的基础

强化学习虽然能探索，但如果模型一开始完全不懂怎么用工具，那探索效率会很低。所以需要先“扶上马”，给模型喂一些高质量的、带有代码解释器使用范例的数据。

ReTool 的数据构建流程大致是这样的：

1. 收集高质量文本推理数据：先收集一批纯文本的数学推理过程数据（比如来自 OpenThoughts），然后用人工和强模型（Deepseek-R1）进行筛选，确保推理逻辑本身是靠谱的。得到基础数据集 $\mathcal{D}_{\mathrm{init}}$。
2. 自动化转换为代码集成数据：设计一个模板（见论文附录 Figure 8），让一个强大的 LLM 把 $\mathcal{D}_{\mathrm{init}}$ 里的纯文本推理过程，自动改写成“文本推理 + 代码执行”的混合模式。主要是识别出哪些手动计算步骤可以用代码替代，然后插入代码块和模拟的执行结果。
3. 两阶段验证：
   • 格式验证：确保代码块标记（如 <code>...</code>）清晰规范，方便后续 RL 阶段识别。
   • 答案验证：确保改写后的推理过程最终答案仍然是正确的。
   • 通过验证后，得到代码增强的推理数据集 $\mathcal{D}_{\mathrm{CI}}$。
4. 监督微调 (SFT)：用 $\mathcal{D}_{\mathrm{CI}}$ 对基础 LLM 进行微调。目标是让模型学会基本的代码调用语法、理解代码执行结果，并初步知道在哪些场景下可以尝试使用代码。

经过冷启动 SFT，模型就有了一个不错的起点，可以开始真正的“实战演练”了。

2.2 强化学习：精通工具使用的艺术

这是 ReTool 的核心创新所在。它改进了传统的 RL 训练流程，让模型在生成推理步骤时，可以实时地与代码解释器交互。

核心机制：带实时代码执行的 Rollout

想象一下模型解题的过程（Rollout）：

1. 模型开始生成思考步骤（自然语言）。
2. 当模型觉得需要计算时，它会生成一个代码块，并用特定标记（比如 <code>...</code>）包起来。
3. 一旦检测到代码块结束标记（</code>），模型的文本生成暂停。
4. 系统提取这段代码，发送到一个安全的沙箱环境（Code Sandbox）中执行。
5. 沙箱返回执行结果（可能是计算输出，也可能是报错信息）。
6. 系统将这个结果用特定标记（比如 <interpreter>...</interpreter>）包裹，反馈给模型。
7. 模型接收到反馈，继续生成后续的思考步骤，直到给出最终答案或生成下一个代码块。

这个过程如下图所示（对比了纯文本 RL 和 ReTool 的 RL）：

Figure 2: (a) 传统纯文本 RL 的 Rollout vs (b) ReTool 的 Rollout，后者可以实时调用代码解释器并获得反馈。

关键点在于这个实时交互和反馈闭环。模型写的代码能不能跑通？结果对不对？甚至代码写错了报了什么错？这些信息都会实时返回给模型，模型可以根据这些反馈调整后续的推理和代码生成。比如，代码错了，模型可以尝试修正代码（后面会看到例子）。

学习信号：简单的结果导向奖励

怎么让模型学得更好呢？ReTool 使用了非常简单的奖励机制：只看最终答案对不对。

这里 $a$ 是标准答案，$\hat{a}$ 是模型给出的答案。答对给 +1 奖励，答错给 -1 奖励。

这种简单的奖励设计避免了复杂的奖励工程（比如去判断代码写得好不好、用得巧不巧），不容易被模型“钻空子”（Reward Hacking）。它迫使模型完全为了“解决问题”这个最终目标去优化自己的策略，包括如何有效利用工具。这有点像考试，只看最终分数，过程怎么做对题目你自己琢磨。

训练细节亮点

为了让这个 RL 过程跑得顺畅高效，ReTool 还用了一些工程技巧：

• 解释器反馈屏蔽 (Interpreter Feedback Mask)：从沙箱返回的结果（<interpreter>...</interpreter> 里的内容）在计算 PPO 损失时不参与计算。这防止了外部注入的信息干扰模型自身生成内容的学习，保证训练稳定性。
• KV 缓存重用 (KV-Cache Reuse)：在每次调用代码解释器前，缓存当前的 KV 状态。收到解释器结果后，只计算和追加这部分反馈的 KV 缓存。这大大减少了每次 Rollout 的显存开销，尤其是在需要多次调用代码的长推理链中。
• 异步沙箱 (Asynchronous Sandbox)：构建了一个分布式的异步代码执行沙箱。多个沙箱 worker 并行处理代码执行请求，提高了 RL 训练的吞吐量，避免了代码执行成为瓶颈。

总的来说，ReTool 的 RL 阶段通过实时代码交互、简单的结果奖励、以及高效的训练工程，让 LLM 能够在使用工具的过程中不断试错、学习和进化。

三、效果怎么样？看实验！

理论讲完了，是骡子是马得拉出来遛遛。ReTool 主要在 AIME（美国数学邀请赛）这种高难度数学竞赛数据集上进行了测试。

3.1 主要结果：又快又强

核心发现：

1. ReTool 效果显著：基于 Qwen2.5-32B 模型，ReTool 在 AIME2024 上达到了 67.0% 的准确率，AIME2025 上达到 49.3%。
2. 碾压纯文本 RL：同样基于 Qwen2.5-32B，纯文本 RL（只用文本思考，不用 CI）的准确率只有 40.0% (AIME24) 和 36.7% (AIME25)。ReTool 的提升幅度巨大。
3. 训练效率更高：达到这个效果，ReTool 只用了 400 个训练步数，而纯文本 RL 则用了超过 1000 步。说明集成工具学习不仅效果好，收敛还快。
4. 超越 SOTA：ReTool (Qwen2.5-32B) 的 67.0% 超过了当时的强基线 s1-32B (56.7%)，49.3% 也超过了 OpenAI 的 o1-preview (37.9%)。如果换用更强的基模型 (DeepSeek-R1-Distill-Qwen-32B)，ReTool 效果还能进一步提升到 72.5% (AIME24) 和 54.3% (AIME25)。
5. 冷启动 SFT 有效：只经过冷启动 SFT、没有经过 RL 的模型（w/o RL），准确率能达到 40.9%，远超原始基础模型（26.7%），并且和纯文本 RL 的效果相当。这证明了第一阶段的 SFT 确实为模型打下了良好的工具使用基础。

结论很明确：ReTool 提出的 RL + 实时 CI 交互的框架，在解决复杂数学推理问题上，无论是效果还是效率，都远超纯文本 RL，并且达到了业界领先水平。

3.2 模型行为分析：它学会了什么？

光看分数还不够，ReTool 训练出来的模型在使用工具的行为上有什么变化呢？研究者做了一些有趣的分析。

代码使用行为的进化 (Figure 3)

Figure 3: RL 训练过程中代码相关行为指标的变化趋势。

看图说话：

• (a) 回答长度：先是急剧下降，然后缓慢上升。初期下降是因为用简洁的代码替代了冗长的手动计算。后期上升可能是因为模型学会了用更复杂的代码解决问题。但最终长度比训练前短了约 40%，说明 CI 提高了推理的“token 效率”。
• (b) 代码使用率：稳步上升，最后几乎所有问题（约 98%）的回答都包含了代码。说明模型越来越倾向于使用工具。
• (c) 代码行数：持续增加，最后是训练前的近 5 倍。说明模型学会了写更复杂的代码来解决问题。
• (d) 正确代码数量：整体上升，从 1k 增加到 5k。说明模型使用代码的熟练度和准确性在提高。
• (f) 代码调用时机：代码在回答中出现的位置越来越靠前。说明模型学会了更早、更主动地规划使用工具。

总的来说，RL 训练让模型从“会用”工具进化到了“善用”工具，使用得更频繁、更复杂、更主动、更有效。

“灵光一现”：代码自修正能力

一个非常有意思的发现是，模型在 RL 训练中自发地学会了修正自己写的错误代码，尽管训练数据里并没有明确教它这么做。

这种 emergent behavior (涌现行为) 表明，基于结果反馈的 RL 不仅能优化已知策略，还能激发模型产生类似“元认知”的能力，学会从错误中学习和调整。

代码用途的变化 (Figure 5)

Figure 5: RL 前后代码主要用途的词云图对比。

分析代码的主要用途发现，RL 训练前，代码主要用于直接的“计算”和“验证”。训练后，代码的用途变得更加多样化，除了计算和验证，还可能包括“模拟”、“探索”、“数据处理”等更复杂的策略性用途。这说明模型学会了根据问题的需要，更灵活地选择和运用代码这个工具。

CI 推理 vs 纯文本推理 (Figure 6)

Figure 6: 同一个问题，左边是 ReTool (CI-powered) 的回答，右边是纯文本推理的回答。

上图是一个直观的对比。对于同一个问题，右边的纯文本推理需要进行大段的、易错的文本计算。而左边的 ReTool 模型则用简洁的代码块完成了计算，代码执行结果直接用于后续推理。CI 不仅保证了计算的准确性，还解放了模型的“心智”，让它可以更专注于整体的解题策略，而不是陷在繁琐的计算细节里。

四、总结

好了，总结一下 ReTool 的核心贡献：

1. 提出了一个创新的 RL 框架 (ReTool)，将实时代码解释器 (CI) 执行无缝集成到 LLM 的推理过程中。这使得 LLM 能够动态地调用工具并根据反馈学习。
2. 设计了一个有效的两阶段训练流程：先通过 SFT（基于自动构建的代码增强数据）打下基础，再通过 RL（基于简单的结果奖励和实时交互）精通工具使用策略。
3. 实验证明 ReTool 非常有效：在 AIME 数学竞赛基准上，显著提升了 LLM 的复杂推理能力和训练效率，超越了纯文本 RL 和当时的 SOTA 模型。
4. 观察到了有趣的涌现行为：如代码自修正能力，表明 RL 能够激发模型更深层次的适应性和学习能力。同时，模型学会了更高效、更策略性地使用工具。

ReTool 的工作表明，让 LLM 学会“使用工具”，特别是通过强化学习从结果中学习如何有效使用工具，是提升其解决复杂、精确任务能力的一个非常有前景的方向。它不仅仅是让模型多了个计算器，更是让模型学会了一种更强大的、结合符号计算和神经推理的混合思维模式。

对于我们后端开发者来说，虽然不直接训练这些大模型，但理解这种“模型+工具”的协同工作模式，以及如何通过类似 RL 的方式让系统具备自适应优化能力，或许能给我们带来一些架构设计或智能运维方面的启发。

好了，今天就聊这么多。各位股东，觉得有收获的话，点个赞再走呗！下次再见！