Open R1: Update #2

Open R1 项目已经进行了两周，该项目旨在重建 DeepSeek R1 中缺失的部分——特别是训练流程和合成数据。

在这篇文章中，我们很高兴分享 OpenR1-Math-220k 的构建成果：这是我们首个大规模数学推理数据集！

我们还将关注社区在策划用于微调的小型、高质量数据集方面的一些令人兴奋的进展，以及关于如何在训练时和推理时控制推理模型的思维链长度的见解。

让我们深入了解一下！

OpenR1-Math-220k 数据集

DeepSeek R1 的主要优势之一是它能够通过知识蒸馏将高级推理能力转移到更小的模型。DeepSeek 团队通过生成 60 万条推理轨迹并微调一系列 Qwen 和 Llama 模型证明了这一点，表明直接从 R1 进行知识蒸馏可以在不使用强化学习的情况下实现有竞争力的推理性能。值得注意的是，DeepSeek-R1-Distill-Qwen-7B 在 AIME 2024 上取得了 55.5% 的成绩，超过了 QwQ-32B-Preview 等更大的模型。

然而，用于知识蒸馏的推理轨迹尚未公开，这促使社区独立重建类似的数据集。到目前为止，社区已经发布了多个开放数据集，包括 OpenThoughts-114k、Bespoke-Stratos-17k、Dolphin-R1 和 LIMO。

🐳 隆重推出 OpenR1-Math-220k，这是一个大规模数学推理数据集，在 512 个 H100 上本地生成，每个问题包含多个答案。为了创建 OpenR1-Math-220k，我们与 Numina 合作，他们开发了广受欢迎的 NuminaMath-CoT 数据集的全新版本。

与现有数据集相比，OpenR1 数据集的新特性：

• 80 万条 R1 推理轨迹：我们使用 DeepSeek R1 为 40 万个问题生成两个答案。过滤后的数据集包含 22 万个问题，并附带有正确的推理轨迹。
• 512 个 H100 本地运行：我们没有依赖 API，而是利用 vLLM 和 SGLang 在我们的科学集群上本地运行生成，每天生成 18 万条推理轨迹。
• 基于 NuminaMath 1.5： 我们专注于数学推理轨迹，并为 NuminaMath 1.5 中的问题生成答案，NuminaMath 1.5 是 NuminaMath-CoT 数据集的改进版本。
• 自动化过滤： 我们应用 Math Verify 仅保留至少有一个正确答案的问题。我们还利用 Llama3.3-70B-Instruct 作为评判器，以检索更多正确的示例（例如，对于答案格式错误且无法通过基于规则的解析器验证的情况）。
• 我们通过在我们的数据集上微调 Qwen-7B-Math-Instruct ，达到了 DeepSeek-Distill-Qwen-7B 的性能水平。

通过展示可扩展、高质量的推理数据生成，我们希望这个流程可以扩展到数学以外的领域，例如代码生成。

数据生成

为了构建 OpenR1-220k，我们提示 DeepSeek R1 为 NuminaMath 1.5 中的 40 万个问题生成解决方案。我们遵循模型卡的建议参数，并在用户提示前添加以下指令：

"请逐步推理，并将你的最终答案放在 \boxed{} 中。"

我们将每次生成的 token 限制设置为 16k，因为我们的分析表明，只有 75% 的问题可以在 8k token 以内解决，而其余大部分问题需要完整的 16k token。最初，我们使用 vLLM 进行推理，每台 H100 每小时实现 15 个生成的吞吐量，并在之前的更新和 OpenR1 repo 上分享了我们的生成脚本。最近，我们开始尝试 SGLang，我们能够每台 H100 每小时生成 25 个解决方案（速度几乎提高 2 倍！），使我们能够在 512 个 H100 上每天生成 30 万个问题解决方案。这使我们能够在短短几天内生成 80 万条推理轨迹。

我们为每个问题生成两个解决方案——在某些情况下，甚至四个——以便在过滤和训练方面提供灵活性。这种方法允许拒绝采样，类似于 DeepSeek R1 的方法，并且也使数据集适用于偏好优化方法，如 DPO。

数据生成的脚本可在此处找到：https://github.com/huggingface/open-r1/tree/main/slurm

数据过滤

为了仅保留高质量、正确的推理轨迹，我们利用 Math Verify，这是一个强大的数学表达式评估系统，旨在评估 LLM 生成的答案。我们从模型生成中提取最终答案，并将其与数据集中提供的标准答案进行比较。

我们发现 55% 的问题至少有一个正确的答案。然而，NuminaMath 1.5 中的一些标准答案是空的或格式不可验证，这使得自动验证具有挑战性。虽然我们改进了 Math-Verify 以更准确地处理这些不太常见的输出格式（请参阅下面的 Math-Verify 改进），但我们也探索了一种替代方法，从被拒绝的样本中恢复有效解：在被拒绝问题的一个子集上使用 Llama-3.3-70B-Instruct 作为评判器。在运行此验证步骤之前，我们过滤掉不完整的样本或包含空标准答案的样本，确保仅考虑格式良好且最终答案明确用方框标出的响应。此过程成功检索了 28,000 个先前被拒绝的问题。

我们按如下方式提示 Llama3.3-70B-Instruct：

你是数学答案验证器。你将获得一个数学问题，你需要比较参考答案中的答案和模型解决方案中的最终答案，以确定它们是否等效，即使格式不同。

问题：

{problem}

参考答案：

{answer}

模型解决方案：

{generation}

仅关注比较模型提供的最终数学答案，同时忽略以下差异：

- 格式（例如，\\boxed\{\} 与纯文本）
- 多项选择格式（例如，“A” 与完整解决方案）
- 坐标对或解的顺序
- 等效的数学表达式或符号变体
- 如果模型的答案是无意义的，则返回“Verdict: AMBIGUOUS”

首先简要解释你的比较（2-3 句话）。然后以以下格式之一输出你的最终答案：

- “Verdict: EQUIVALENT”
- “Verdict: DIFFERENT”
- “Verdict: AMBIGUOUS”

通过将基于规则的验证（Math Verify）与基于 LLM 的评估相结合，我们在保持规模的同时提高了数据集质量。最终数据集包含 22 万个带有验证推理轨迹的问题，使其成为训练推理模型的宝贵资源。为每个问题提供多个解决方案，使社区可以灵活地过滤出更好的生成结果，并根据 NuminaMath 数据源和问题类型应用更有针对性的改进。

该数据集分为两个 split：

• default (94k 个问题)，在 SFT 之后实现了最佳性能。
• extended (131k 个问题)，其中包括额外的 NuminaMath 1.5 数据源，如 cn_k12，提供更多推理轨迹。但是，我们观察到，在此子集上进行 SFT 后的性能低于 default split，这可能是因为与其他来源相比，cn_k12 包含更简单的问题。

对于具有多个正确答案的行，我们还尝试应用奖励模型 (RM) 作为最终过滤器，以选择最佳响应。对于 R1 生成的多个正确答案的每一行，我们通过删除思考 token (<think>…</think>) 来提取最终答案，然后将问题 + 提取的答案传递给使用 vLLM 提供的 Qwen/Qwen2.5-Math-RM-72B 以获得分数。使用这些分数，我们为每个包含多个正确响应的行构建了一个排名。选择了排名第一的正确生成并将其包含在训练数据集中，但遗憾的是，训练消融实验表明，相对于选择一个随机的正确生成，这种方法无助于提高模型性能。一个可能的改进是在使用 RM 评分时包含推理轨迹，而不仅仅是最终答案。

与 DeepSeek-Distill-Qwen-7B 的性能比较

我们使用 5e-5 的学习率在数据集的 default split 上对 Qwen2.5-Math-Instruct 进行了 3 个 epoch 的微调。为了将上下文长度从 4k 扩展到 32k，我们将 RoPE 频率增加到 30 万。训练遵循线性学习率 schedule，并具有 10% 的预热阶段。下表使用 lighteval 比较了 OpenR1-Qwen-7B、DeepSeek-Distill-Qwen-7B 和 OpenThinker-7B 的性能。

该数据集代表一个初始版本，为进一步改进奠定了基础。社区可以探索其他过滤策略来提高性能，例如 DeepSeek R1 中使用的拒绝采样，以提高质量。

Math-Verify 改进

在检查验证结果期间，我们发现了 Math-Verify 中的几个失败案例。为了解决这些问题，我们实施了重大改进和修复。我们强烈建议更新到最新版本 (0.5.2) 以从这些增强功能中受益：

pip install math-verify==0.5.2

以下是最重要的改进摘要：

• 改进了纯文本答案的解析和验证（例如 $\text{E}$ == $E$）
• 改进了答案列表的解析（例如 $1$ and $2$ and $3$ == $1,2,3$）
• 修复了单个 latex 环境中多个 boxed 答案的解析（例如 $\boxed{1},\boxed{2}$ == {1,2}）
• 引入了有序元组。推断列表是元组还是集合非常困难，因此我们使用标准答案来指导我们：
  • (1,2,3) ≠ {3,2,1}; 1,2,3 == {3,2,1}; {3,2,1} == {1,2,3}
• 支持标准答案中的关系运算符（例如小于）和预测中的区间（例如 $1 < x < 2$ == $(1,2)$）

社区亮点

本周，社区从许多不同的角度探索了 GRPO，同时多家研究实验室表明，仅需约 1000 个高质量训练样本可能就足以在现有开放模型中引发推理。

GRPO 的实际应用

• nrehiew 展示了 直接将 GRPO 应用于 Qwen2.5-0.5B 基础模型，在 GSM8k 基准测试中产生了约 51% 的准确率，比 Qwen2.5-0.5B-Instruct 模型提高了 10 个百分点。如此令人印象深刻的结果引发了许多关于 instruct 数据在预训练中作用的 讨论，因为人们（尚未）能够在将 GRPO 应用于 Llama 3 等其他基础模型时获得类似的收益。特别是，Sea AI Lab (SAIL) 的研究人员表明，基础模型可以很容易地被提示产生自我反思，并且 DeepSeek-R1 论文中的“顿悟”时刻可能更多的是基础模型的一种症状，而不是 RL 优化过程。
• Unsloth 应用了他们的 优化魔法，使参数高达 15B 的模型能够仅用 15GB VRAM 🤯 通过 GRPO 进行训练。这意味着你现在可以在 Google Colab 中免费使用 GRPO！
• 来自 Axolotl 的 Wing Lian 表明，DoRA 的收敛速度 比 LoRA 和全参数微调都快。
• Alexander Doria 找到了一种为 诗歌设计奖励函数的方法。这令人兴奋，因为它提供了 GRPO 应用于传统上不被视为“可验证”领域的首批公开示例之一。

评估

AIME 2025 的第一部分于本周发布，其中包含 15 个难度很大的数学问题，这些问题用于培训高中生参加国际数学奥林匹克竞赛。在过去一年中，AIME 2024 一直是探测 LLM 数学能力的主要基准，社区很高兴看到模型在新的一组未见过的问题上的表现如何：

• 苏黎世联邦理工学院 (ETH Zurich) 的研究人员评估了一系列封闭和开放模型，发现 性能漂移 远小于预期，通常在 10-20 个百分点范围内。
• 然而，Dimitris Papailiopoulos 发现 AIME 2025 的几个问题已经存在于互联网论坛上！这可能充当一种意外的训练-测试泄漏形式，突显了 为 LLM 创建新问题有多么困难。

LLM 需要用自然语言推理吗？

一篇有趣的新 研究论文 表明，通过使用循环语言模型，可以通过在潜在空间中隐式推理来扩展测试时计算。这类似于 Meta 的 Coconut 工作，在潜在空间中训练语言模型，但现在已适应推理任务。这些方法的优势在于它们在计算效率方面更高：通过探索潜在空间，无需生成大量的“思考”token 即可获得高性能。

转向更小、更高质量的推理数据？

虽然 DeepSeek R1 利用 60 万条推理轨迹进行知识蒸馏，但最近的工作表明，复杂的推理能力可以在语言模型中涌现，并非通过大规模训练，而是通过少量精心策划的样本。

这种方法的一个例子是 s1K 数据集。它由 1,000 个精心挑选的数学问题组成，这些问题带有来自 Gemini Flash 的知识蒸馏推理轨迹。选择方法侧重于难度、多样性和质量。作者在 s1K 上微调 Qwen2.5-32B-Instruct，并设法在竞赛数学基准测试中超越 OpenAI 的 o1-preview 高达 27%。

另一个数据集 LIMO 进一步推进了这一想法，仅使用 817 个训练样本就在 AIME 和 MATH 基准测试中取得了出色的性能。作者假设，当模型在预训练期间已经获得了广泛的领域知识时，可能只需要少量结构良好的示例即可解锁高级推理能力。

CoT 长度：预算强制与奖励塑造

s1K 中微调的 Qwen2.5-32B-Instruct 模型能够达到如此强大性能的一个重要因素是 预算强制 (budget forcing)，这是一种测试时计算技术，通过分别在模型生成中附加 “Wait” 或思考结束 token 分隔符来扩展或截断推理。该工具使作者能够改变思考时间，并得出结论，他们的模型表现出测试时扩展性：随着思考时间的增加，不同数学基准测试的准确率也会提高。

同样，Demystifying Long Chain-of-Thought Reasoning in LLMs（Yeo 等人）也研究了思维链 (CoT) 长度对模型性能的影响。他们引入了 余弦奖励 (Cosine Reward) ——一种新颖的奖励函数，他们使用它来激励正确生成结果的 CoT 更短，错误生成结果的 CoT 更长 —— 这稳定了 RL 训练，特别是当模型具有相对有限的最大上下文大小并且平均响应长度可能爆炸时。当模型开始在难题上表现出奖励攻击 (reward hacking) 的迹象时，也会采用 重复惩罚 (Repetition penalty)，通过人为地增加 CoT 长度而不是尝试解决问题。

下一步是什么？

现在 GRPO 正在 TRL 中顺利运行，我们正在进行广泛的实验，以了解哪些超参数和奖励函数对训练的影响最大。你可以在 社区选项卡 中关注我们的进展，我们将在下一次更新中撰写我们的发现！

如果你想做出贡献，请查看 GitHub 上的 open-r1 仓库 或关注 Hugging Face open-r1 组织。