正文
这种依赖于架构的行为表明，RLVR 的有效性更多地取决于预先存在的模型能力，而不是监督信号的质量。
给未来工作的实践性警示
Qwen 模型凭借其开源权重和在推理任务上的高性能，已成为开源社区中 RLVR 研究事实上的选择 —— 近期一系列关于 RLVR 的研究都是基于以 Qwen 为中心的实验得出结论的（请参阅原论文以获取列表）。
然而，我们发现近期有两项研究表明，使用弱监督的 RLVR 在 Qwen 模型上效果良好，但这些结论无法泛化到其他模型家族。
我们在多种基础模型上评估了最近提出的两种弱监督 RL 方法 ——TTRL 和单样本 RL。我们发现，这些提出的训练奖励在 Qwen 模型上能够持续奏效。然而，除了少数例外，这些相同的信号在其他模型家族上通常无法带来收益，这与我们使用虚假奖励进行训练时观察到的有限泛化能力相呼应。
因此，我们建议未来的 RLVR 研究应该在其他模型上进行验证。
是什么让带有虚假奖励的 RLVR 生效呢？
现在，你可能会好奇 —— 为什么会发生这种情况？？为什么所有这些虚假奖励 都在 Qwen-Math 模型上有效？魔法究竟在哪里？
总的来说，我们假设 RLVR 训练结果的差异是由于每个模型在预训练过程中学到的特定推理策略不同所致。特别是，某些策略可能很容易被 RLVR 引出 (elicited)，而其他策略则可能更难显现，或者根本不存在。
我们识别出了一种这样的预存策略：
生成代码以辅助数学推理
，Qwen-Math 能够有效利用它，而其他模型家族则利用得较少。我们将代码推理作为一项
有启发性的案例研究
来进行调查，但这并非完整的解释：我们观察到其他一些行为也很容易被引出，并且常常与性能相关，例如「不重复」。更多详情请参阅论文。
个有启发性的案例研究：代码推理
通过仔细分析，我们发现了一个关键洞察：即使在进行 RLVR 训练之前，Qwen-Math 也有 65.0% 的时间会生成 Python 代码来解决数学问题。更惊人的是，在没有代码执行器的情况下，它常常能生成正确的代码输出以及问题的正确答案。
然而，这种频繁且高质量的代码推理能力在其他模型中并不存在。
下面是一个 Qwen-Math-7B 如何能精确预测
到小数点后 15 位 —— 比 iPhone 计算器还多一位的例子。
Qwen2.5-Math-7B 的代码推理回应示例。该问题从 MATH-500 测试集中随机选取。请注意，代码及其执行结果均由 Qwen2.5-Math-7B 自回归生成 。并未向模型提供外部代码解释器。
在应用 RLVR 之后，无论奖励质量如何，这种代码推理的频率平均增加到 90% 以上。
这种推理策略的转变——而非获取新的推理技能——似乎是驱动性能提升的原因。
Qwen 模型通过 RLVR 训练学会了使用更多的代码推理。从语言推理到代码推理的转变有效地提升了性能。
对于 Qwen-Math 和 Qwen 模型而言，代码频率与性能高度相关。代码越多 —> 正确答案越多，反之亦然。然而，在那些能产生代码但无法产生优质代码的模型（例如 OLMo2-7B-SFT）中，这种相关性是相反的。
细粒度准确率追踪 — 我们仅从选择正确的推理策略中能获益多少？
更有趣的是，我们追踪了那些在 RLVR 前后推理策略发生改变的问题，并分析了性能增益究竟从何而来。我们发现：
在成功引导模型推理策略的奖励上平均计算，对整体性能增益的部分贡献。
基于我们初步观察到的这些强相关性，我们假设代码推理是 Qwen 模型中导致良好数学性能的推理行为之一。
为了验证我们的假设，我们通过提示和强化学习明确地约束模型生成代码推理。我们观察到，在所有测试的模型中，代码推理的频率与
基准性能
之间存在强相关性。（相关性的方向取决于特定模型的代码质量）。
通过提示诱导代码推理
我们仅仅通过提示模型，让它以「让我们用 Python 来解决这个问题。」 (Let's solve this using Python) 这句话来开始其回应。这个简单的做法显著提升了 Qwen-math 模型的性能，但却降低了 Llama 和 OLMo 模型的性能。
通过强化学习 (RL) 诱导代码推理
鉴于提示实验的成功，我们设计了一种额外的虚假奖励：只要模型的回应中包含字符串 python，就给予奖励。这极大地鼓励了所有模型去使用代码推理（在训练 50 步之后，超过 99% 的回应包含代码）。
