Lecture 16:RLVR 与推理模型
Stanford CS336 Language Modeling from Scratch | Spring 2026 | Lecture 16: Post-Training - RLVR,时长 01:15:50。
RLVR:从可验证奖励的强化学习到推理模型#
RLVR(Reinforcement Learning from Verifiable Rewards)是当前推理模型(如 OpenAI o1、DeepSeek R1)背后的核心训练范式。与 RLHF 使用容易被过拟合的学习奖励模型不同,RLVR 依赖数学正确性、代码测试通过等可自动验证的奖励信号,使得训练可以安全地投入大量计算资源。GRPO 算法通过去掉 PPO 中最复杂的 value function,将 RLVR 的实现门槛降低到”一页代码”的水平,成为几乎所有开源 RLVR 工作的基础。
本文从算法原理出发,深入分析 GRPO 的理论细节及其与标准 policy gradient 的偏差,然后通过 DeepSeek R1、Kimmy K1.5、Qwen 3 / Coder Next 三个案例研究,展示 RLVR 在实际系统中的工程实践——包括数据构建、Pipeline 设计、长度控制、以及 agentic 场景下的 reward hacking 挑战。
从 RLHF 到 RLVR:可验证奖励的动机#
RLHF(Reinforcement Learning from Human Feedback)的核心瓶颈在于奖励模型的过拟合。整个 RLHF 流程是:收集人类偏好数据,训练一个奖励模型,然后用 RL 优化语言模型以最大化该奖励模型的得分。问题在于,这个奖励模型是一个近似——无论正则化做得多好,持续往同一个奖励模型上灌注计算资源,最终都会过拟合。模型学到的不是”真正变好”,而是”如何骗过奖励模型”。这就是所谓的 reward overoptimization,它从根本上限制了 RLHF 能投入的计算量。
这与经典 RL 的成功案例形成了鲜明对比。以 AlphaGo 为例,它优化的目标是精确的胜负信号——棋局的输赢没有任何模糊性,因此可以无限投入计算资源,只要目标持续改善就意味着模型在变强。这是一个搜索问题(search problem),而 RLHF 更像是一个学习问题(learning problem):我们试图从有限的人类标注中学习一个本质上无法完美定义的目标。
RLHF 和 RLVR 在算法层面非常相似,真正的区别在于奖励的性质:我们需要更不可被欺骗的奖励信号,这样才能安全地投入更多计算资源。
RLVR(Reinforcement Learning from Verifiable Rewards)的出发点正是这一洞察。数学问题和编程问题天然具有可验证性——答案要么对要么错,可以通过编译器、测试用例或数学等价性检查来自动判定。这种奖励信号在本质上更接近 AlphaGo 的胜负信号,而非 RLHF 中那个可被利用的近似奖励模型。
DPO(Direct Preference Optimization)作为 RLHF 的简化替代方案,也无法直接解决这个问题。DPO 是专门为 Bradley-Terry 成对比较设计的,而数学问题的反馈并非天然以成对比较的形式存在。虽然有 DPO 的变体试图打破成对结构,但本质上这是在用错误的工具解决问题——DPO 是一把专用锤子,而 PPO/GRPO 才是通用锤子。不过 DPO “离线 vs. 在线”的区分其实被过度强调了,因为可以通过迭代地重复运行 DPO 来使其变成在线的。
正是因为 PPO 实现的痛苦和 DPO 的适用范围有限,研究社区迫切需要一种既简单又通用的 RL 算法。GRPO 的出现正好填补了这个空缺——它像 DPO 一样简单,同时又保留了 PPO 的通用性。
PPO 算法回顾与实现陷阱#
PPO(Proximal Policy Optimization)是语言模型 RL 训练的经典主力算法。在概念层面,PPO 非常简洁:采样一批 trajectory,用某种优势估计方法计算 advantage,在 clipped advantage 下更新策略,同时拟合一个 value function。OpenAI Spinning Up 文档中的伪代码看起来简单到可以一口气实现。
但如果看到一篇题为”PPO 的 37 个实现细节”的博客文章,就该心生警惕了——这说明 PPO 对实现细节极度敏感。不同的 RL 库会因为实现差异而产出完全不同的数值结果,甚至有论文指出一些广泛使用的 PPO baseline 实现从根本上改变了优化问题本身。
PPO 在语言模型中的实现复杂性#
PPO 应用于语言模型时的完整架构包含多个交互组件:

这张架构图(来自 Zheng et al 2023)展示了 PPO 的全部活动部件:SFT 模型提供 KL 约束参考,Reward Model 评估生成质量,Value Model 估计每个 token 的价值并输入 GAE(Generalized Advantage Estimation)计算 advantage,Experience Buffer 存储旧 rollout 用于多步更新,最终 Policy LM 在 PPO-clip Loss 下更新。注意 Value Model 出现了两次——既要参与 advantage 计算,又要用 MSE Loss 自身更新。KL 项在每个 token 上计算,使得这不是一个简单的 bandit 问题,而是一个完整的多步 RL 问题。
实际的工程细节更加棘手。一个具体的例子:在某个 RLHF 项目的 PPO 实现中,KL 惩罚需要在零处截断(clip at zero)才能正常工作——但从数学角度看,这完全破坏了 KL 散度的意义,因为 KL 散度本身有正有负的贡献在被求和。
另一个常见的退化设置是:原始 PPO 论文中使用 Generalized Advantage Estimator (GAE),其中有折扣因子 γ 和 λ 来控制 token 级的时序结构。但在语言模型的实践中,几乎所有人都设 γ=λ=1,这实际上将整个问题退化回了一个 bandit 问题——PPO 精心设计的 token 级时序结构被直接丢弃了。
PPO 被弃用的两个核心原因#
实现脆弱性:PPO 需要大量 engineering hack 来稳定训练。各大实验室都有内部的”PPO 调优秘方”,但对于从头实现的研究者来说,让 PPO 稳定运行是一件非常痛苦的事情。这并非不可能——很多公司已经训练出了非常好的 PPO 模型——但门槛很高。
Value Model 的内存开销:PPO 需要一个与策略模型同等规模的 value model 来估计每个 token 的价值。这个模型占用了本可以用于其他用途(如更大的 batch size、inference serving)的 GPU 内存。
正是这些痛点驱动了 GRPO 的诞生:保留 PPO 的核心思想(policy gradient + clipping),同时去掉最麻烦的部分(value function)。
GRPO:去掉 Value Function 的简洁替代#
GRPO(Group Relative Policy Optimization)最初出现在 DeepSeek Math 论文中,其出发点极其直觉:PPO 是个好主意,但 value function 是其中最复杂、最不稳定的部分——那就去掉它。
核心思想:用组内 Z-Score 替代 Value Function#
在标准 PPO 中,advantage 的计算依赖一个神经网络 value function:模型预测”我应该得到 5 分”,实际得到 6 分,所以 advantage 为 +1,这是一个好的 rollout。GRPO 用一种更朴素的方式替代了这个过程:
对同一个 prompt 进行 G 次采样,得到 G 个 rollout 及其奖励 r1,r2,…,rG。每个 rollout 的 advantage 定义为组内 z-score:
Ai=σri−μ
其中 μ 和 σ 分别是这 G 个奖励的均值和标准差。如果某个 rollout 的奖励高于组内平均水平,它就获得正的 advantage;反之则获得负的 advantage。
GRPO 的完整目标函数#
GRPO 保留了 PPO 的 clipped objective 框架:
LGRPO=E[min(πθoldπθAi,clip(πθoldπθ,1−ϵ,1+ϵ)Ai)]−β⋅DKL(πθ∥πref)
其中 KL 项将当前策略约束在参考模型附近。一个关键简化是:在 online rollout 的场景下,πθ=πθold,因此比率 πθoldπθ=1,clipping 操作永远不会触发。此时目标退化为:
L=E[Ai⋅logπθ(yi∣x)]−β⋅DKL
这就是一个带 KL 正则化的加权 SFT 更新,权重可正可负——正是 REINFORCE 算法的基本形式。
实现的极致简洁#
GRPO 去掉了 value function 之后,整个算法可以用不到一页代码实现。核心步骤:
- 对每个 prompt 采样 K 个 rollout
- 计算每个 rollout 的奖励
- 在每个 group 内做 z-score 归一化得到 advantage
- 计算 KL 惩罚项
- 对 advantage 和 KL 的组合取梯度更新模型
需要注意的实现细节是 stop gradient 的位置(advantage 的计算不应参与反向传播),以及在标准差计算中加一个小的 ϵ(如 10−4)以防止除以零——当一个 group 中所有 rollout 的奖励完全相同时(比如全部答错),标准差为零。McGill 大学的一个参考实现展示了整个 GRPO 算法可以写进半张 PPT。
几乎所有开源 RLVR 工作都建立在 GRPO 之上。它易于实现、易于理解,并且在复现闭源实验室成果方面表现出色。
GRPO 的理论细节:标准差归一化与长度归一化#
GRPO 虽然在实践中效果很好,但从理论角度看,它并不是在严格执行 policy gradient。理解这一点对于正确使用和改进 GRPO 至关重要。
GRPO 不是标准的 REINFORCE with Baseline#
经典的 REINFORCE with baseline 定理(Sutton & Barto 教科书)允许从奖励中减去任何与状态相关的常数基线 B(s):
∇θJ(θ)=E[∇θlogπθ(a∣s)⋅(R−B(s))]
在 bandit 设定中,state 就是 prompt,因此任何只依赖 prompt 的基线都不会改变梯度的期望方向,只会影响方差。GRPO 减去组内均值 μ 作为基线是完全合法的。
但 GRPO 还除以了标准差 σ。 这不再是简单的”减去基线”,而是对梯度做了一个乘性缩放,这打破了 baseline 定理的条件。因此,GRPO 的更新方向不再保证与真正的 policy gradient 方向一致。
此外,GRPO 实现中还有一个 per-token 长度归一化:将整体 loss 除以输出序列的长度。如果严格从 policy gradient 出发推导,这个归一化项也不会出现。这两个偏差意味着 GRPO 并非在直接优化奖励目标——它在做一些略有不同的事情,而这些差异既有优点也有缺点。
有研究者(如 Dr. GRPO 论文)在 GRPO 发表后不久就注意到了这些问题,并指出:如果去掉标准差归一化和长度归一化,可以得到不同的(在某些实验中更好的)结果。
长度归一化的效应#
长度归一化的含义是:更长的序列的 loss 被除以一个更大的数。这产生了一个直接的后果——鼓励模型在答错时生成极长的输出。
极端情况下的推理是这样的:假设模型答错了一道题,获得了 −1 的奖励。如果它生成一个无限长的字符串,负奖励就被除以无穷大,惩罚趋近于零。因此长度归一化在负奖励情况下激励模型”废话连篇”(babble on)——一旦意识到无法解决问题,就通过不断生成 token 来稀释惩罚。
这正是 DeepSeek R1 论文中报告的”chain of thought 长度持续增长”现象的一个重要(但未被充分讨论的)驱动因素。Dr. GRPO 的控制实验更清楚地展示了这一点:输出长度的增长主要由答错的样本驱动,而答对样本的长度增长则受限于完成推导所需的最短长度。
反过来,如果去掉长度归一化(使用”原始” GRPO 或 Dr. GRPO 的修正版本),观察到的 CoT 长度会在某个常数处封顶,而非无限增长。
标准差归一化的效应#
标准差归一化的效应更微妙。考虑一个二值奖励问题(答对得 1,答错得 0):标准差 σ 取决于成功率。当问题太简单(几乎全对)或太难(几乎全错)时,σ 趋近于零,导致 advantage 被除以一个极小的数而变得极大。
这意味着 GRPO 会不成比例地放大极简单和极困难问题的梯度贡献。在极困难的问题上,模型几乎没有学习信号(因为很少答对),却获得了巨大的梯度更新——这显然是有害的。在极简单的问题上,模型已经掌握了,继续大幅更新也是浪费。
真正有效的学习发生在”中等难度”区间——模型有时能答对、有时答错的问题。标准差归一化恰恰弱化了这个区间的信号,而放大了两端无用信号。
两个偏差的实际影响#
尽管理论上这两个偏差都有问题,GRPO 在实践中仍然表现出色。一种可能的解释是:这些偏差在某种程度上起到了正则化的作用,或者在大规模训练中被其他因素(如 KL 约束、数据分布)所抵消。但理解这些偏差的存在对于改进算法非常重要——DeepSeek R1 的后续工作和 Dr. GRPO 都基于这些分析做出了改进。
DeepSeek R1:从 R1-Zero 到生产级推理模型#
DeepSeek R1 之所以成为 RLVR 领域的里程碑,不仅因为它匹配了 OpenAI o1 的性能,更因为它提供了一个任何人都能复现的 RL recipe。在此之前,如果解决方案依赖于只有 DeepSeek 才能运行的复杂 PPO 基础设施,其研究影响就会大打折扣。GRPO 的简洁性使得整个社区都能参与。
R1-Zero:纯 RL 的极简实验#
R1-Zero 是 R1 论文中最令人印象深刻的对照实验。它的设置极其简单:
- 起点:DeepSeek 的 base model(经过 mid-training,已具备一定的指令跟随能力)
- 训练方法:直接在 base model 上运行 GRPO
- 奖励信号:仅两种——accuracy reward(数学题答对/答错)和 format reward(是否正确使用
<think>标签包裹 chain of thought)
format reward 的设计目的是让模型学会将推理过程和最终答案分离,以便后续可以选择性地隐藏 CoT。
仅凭这个极简配置,R1-Zero 就达到了仅略低于 OpenAI o1 的数学推理性能。这个结果之所以特别有说服力,是因为它没有混入任何其他训练阶段的噪声——没有 RLHF、没有复杂的 SFT pipeline,纯粹是 base model + GRPO + verifiable reward。
R1-Zero 引发的讨论#
R1 论文强调了两个现象,并将它们作为 RL 的成果来展示:
CoT 长度持续增长:随着训练推进,模型的推理链越来越长。但正如上一节分析的,这在很大程度上是 GRPO 的长度归一化所导致的副产品,而非模型”学会了更深入的思考”。
“Aha moment”:模型在 CoT 中出现了类似于”等等,让我重新考虑”或”啊,我发现了一个更好的方法”的自我反思模式。这在社交媒体上引起了极大关注,但后续研究表明,这些模式在 base model 中就已经存在——预训练数据中大量的数学讨论自然包含了这类表述。RL 只是因为模型在生成大量数学 token 时碰巧”提取”了这些已有的模式,而非真正通过 RL 学会了元认知。
从 R1-Zero 到生产级 R1#
R1 的完整 pipeline 展示了如何将各个训练阶段组合成一个端到端系统:
- Mid-trained base model → 已有基本的代码和指令跟随能力
- 长 CoT SFT → 收集/构造少量长推理链数据做微调。论文中谨慎地写道”we construct and collect a small amount of long CoT data”——大概率是从其他模型蒸馏而来,但措辞刻意模糊
- Reasoning RL (GRPO) → 在数学和代码问题上运行 RLVR,加入 language consistency reward 防止 CoT 中的语言切换
- SFT + RLHF → 标准的指令微调和人类偏好对齐,处理非可验证任务
- 输出:最终的 R1 模型
R1 特别添加了 language consistency reward,因为 R1-Zero 风格的训练会导致模型在 CoT 中混合使用不同语言(如中英文混杂),这被认为影响了可解释性。
Outcome 还是 Process Supervision?#
DeepSeek 的研究轨迹在这个问题上有一个有趣的转折。在 DeepSeek Math 论文中,process supervision(对推理的中间步骤进行评分)被证明有效。但到了 R1,他们放弃了 process supervision,只使用 outcome supervision(仅判断最终答案的对错)。
论文坦诚地报告了这一发现:他们尝试了 process reward model (PRM) 和 MCTS(类似 AlphaGo 的树搜索),但这些方法的效果不如预期。outcome reward model 更简单、更容易扩展数据规模,而且”足够好”。
在 o1 发布初期,很多人猜测 OpenAI 使用了 PRM 或树搜索。DeepSeek 的实验表明,纯粹的 outcome supervision 配合 GRPO 就能达到非常好的效果,这大大降低了复现的门槛。
R1 的蒸馏洞察#
R1 论文的最后一个重要贡献是蒸馏实验。将 R1 的长 CoT 数据蒸馏到 Qwen 2.5 等更小的模型中,可以显著提升这些小模型的推理性能,在某些基准上甚至接近专门训练的推理模型。
这暗示了一种理解 RL 角色的方式:RL 本质上是一种高质量监督信号的生成器。对于前沿难题,RL 的自我博弈能生成人类标注者无法提供的详细推理链。但一旦这些推理链存在了,通过简单的 SFT 蒸馏就能将能力迁移到其他模型。换言之,RL 的不可替代性在于生成训练数据的过程,而非训练算法本身。这个蒸馏结果在 LLaMA 模型上也同样成立。
Kimmy K1.5:DPO 视角的替代推导与长度控制#
Kimmy K1.5 与 DeepSeek R1 几乎同时发布,在数学基准上同样超越了 OpenAI o1,但在社区中的知名度远不如 R1。将二者对比阅读的价值在于:两条截然不同的技术路径达到了相似的终点,这种收敛暗示了哪些组件是真正关键的,哪些只是实现选择。
DPO 风格的替代推导#
Kimmy 的 RL 算法不走 PPO 的路线,而是从 DPO 的推导框架出发。起点与所有方法相同——最大化策略下的期望奖励,加一个 KL 正则化项:
maxθE(x,y∗)∼D[E(y,z)∼πθ[r(x,y,y∗)]−τKL(πθ(x)∥πθi(x))]
沿用 DPO 的推导策略:假设可以解析地求解最优策略,由此得到最优策略与当前策略的关系式。在最优解处,奖励值应当等于策略比率的对数缩放。Kimmy 的关键启发式步骤是:既然这个等式在最优解处成立,何不直接对这个等式施加平方损失来作为替代目标?
L(θ)=E[(r(x,y,y∗)−τlogZ−τlogπθi(y,z∣x)πθ(y,z∣x))2]
从优化理论的角度看,这个跳跃并不严谨——“在最优解处相等”不代表”对等式取平方损失能收敛到最优解”。但从直觉上说,强迫这两个量接近是一个合理的替代目标。
对这个目标取梯度,得到的更新规则惊人地接近 GRPO:
k1∑j=1k(∇θlogπθ(yj,zj∣x)(r(x,yj,y∗)−rˉ)−2τ∇θ(logπθi(yj,zj∣x)πθ(yj,zj∣x))2)
这里 rˉ 是组内均值——与 GRPO 中减去均值的基线完全一致。额外的 KL 正则化项也与 GRPO 中的 KL 惩罚对应。唯一的区别是 Kimmy 的推导中没有标准差归一化,也没有长度归一化。
从完全不同的推导路径出发,最终到达了与 GRPO 几乎相同的更新规则。这种收敛强烈暗示:组内均值基线是这类算法的核心有效成分,而标准差归一化和长度归一化是可选的(甚至有害的)附加组件。
长度控制:主动压缩 CoT#
Kimmy 在长度问题上持与 DeepSeek 截然相反的态度。DeepSeek 将 CoT 长度增长视为正面现象(“模型在学会更深入地思考”),而 Kimmy 认为过长的 CoT 是推理成本的浪费。
如果用户使用 $200/月的 Pro 计划,而模型思考一个小时,这在商业上是不可接受的。5 分钟的思考时间才是合理的目标。因此 Kimmy 不仅没有长度归一化带来的长度膨胀问题,还主动引入了长度压缩奖励。
长度奖励的设计需要平衡一个微妙的权衡:
- 正确答案应该尽量简短——更短的 CoT 节省推理成本
- 错误答案不能被压缩得太短——否则模型会丧失”恢复”的能力
具体例子:假设模型在几何题上表现很差,长度惩罚使得几何题的 CoT 越来越短,最终趋近于零。此时模型在几何题上完全无法产出有意义的推理过程,永远也不可能通过 RL 获得正奖励来改善。这是一个不可逆的退化。
解决方案是:对错误答案只施加温和的长度压缩——使其略短于平均长度即可,而非强制最短。这既防止了错误答案的 CoT 无限膨胀,又保留了模型在困难问题上通过长推理来恢复的可能性。
数据集构建与课程学习#
Kimmy 在数据方面的工作比 DeepSeek R1 更详细:
难度过滤:使用 best-of-K 过滤策略。对每个问题采样 8 次(best-of-8),如果模型至少能答对一次,说明该问题已经在模型的能力边界,不是理想的 RL 训练样本。只保留那些 best-of-8 全部失败的问题——这些是模型需要通过 RL 来突破的难题。也可以双向过滤,排除完全不可能解决的问题(pass@K = 0)。
动态课程:监控每个问题的成功率,一旦模型掌握了某个问题就将其移出训练集。这既节省了计算资源,又避免了在已掌握的问题上浪费梯度更新。
排除多选题:多选题不需要深度推理,因此被排除在 RL 训练数据之外。
答案等价性检查的困境#
一个看似简单但实际非常棘手的工程问题是数学答案的等价性检查。RLVR 的”V”(verifiable)预设了答案可以被自动验证,但在自然语言数学中,同一个答案可以有无数种等价写法(如 21、0.5、sin2θ+cos2θ−0.5),而语言模型的输出格式也可能偏离预期(如忘记 \boxed{} 标记,或在 box 中添加多余文本)。
Kimmy 为此使用了一个专门的奖励模型来做答案等价性检查。这颇具讽刺意味——整个 RLVR 的出发点是摆脱可被利用的奖励模型,最终在”验证”环节又引入了一个模型。大多数 RL 项目都有一个非常复杂的答案检查器,可能是正则表达式、模型或两者的组合。获取 RLVR 中”verified”部分的准确性本身就是一个深不见底的工程挑战。
RL vs. Expert Iteration#
Kimmy 的长度控制效果可以从 Omni Math 基准上得到验证:即使 token 数量没有明显增长,模型的数学性能仍在持续提升。这说明长度控制确实在约束冗余推理的同时保持了有效推理的质量。
与 DeepSeek 一样,Kimmy 对 SFT 阶段几乎没有披露细节。具体使用了什么 SFT 数据只能推测,这也是开源报告中常见的信息空白。
RL vs. Expert Iteration#
Kimmy 提供了大规模消融实验证明 RL 确实优于 expert iteration(即只在正确答案上做 SFT,也称为 rejection fine-tuning)。在所有基准上,RL 方法一致地超过 expert iteration。如果追求极致性能,RL 仍然是不可避免的。
Qwen 3 与 Coder Next:完整 Pipeline 与 Agentic RLVR#
Qwen 3 和 Qwen 3.5 Coder Next 代表了 RLVR 工程实践的最新进展。前者展示了完整的模型构建 pipeline 和有趣的 scaling 结果,后者则提供了目前公开报告中最详细的 agentic RLVR 训练方案。
Qwen 3:完整 Pipeline 一览#
Qwen 3 的训练流程可以作为当前前沿模型构建的心智模型:
- Base model(预训练)
- SFT(指令微调)
- Reasoning RL(使用 GRPO 在可验证任务上训练)
- Thinking mode fusion(将思考模式和即时响应模式融合到同一个模型中)
- RLHF(处理非可验证任务的人类偏好对齐)
- Distillation(蒸馏到更小的模型)
Qwen 3 的 RLVR 部分采用了成熟的 playbook,综合了 DeepSeek 和 Kimmy 的最佳实践:
- 难度过滤:排除太简单和太难的问题
- 去除无需思考即可答对的问题:如果模型不用 CoT 就能答对,这不是一个需要深度推理的问题
- 去污染:排除与验证集过于相似的数据
- 人工审查参考 CoT 的质量
一个引人注目的数据点是:Qwen 3 的 RL 训练只使用了约 4,000 个样本。在 pipeline 的其他部分做对的前提下,极少量的高质量 RL 数据就足够了。
Qwen 3 的报告还提供了各训练阶段对最终性能贡献的消融分析:reasoning RL 主要提升数学和代码能力,general RL(即 RLHF)则在 Arena Hard、CounterfactQA 等通用任务上带来显著增益。Thinking mode fusion 引入了小幅的数学/代码性能退化——虽然绝对值不大,但正是这种退化最终导致 Qwen 3.5 放弃了融合方案。
Thinking Mode Fusion#
Qwen 3 尝试了一种有趣的设计:将思考模式(长 CoT 推理)和非思考模式(即时响应)融合到同一个模型中,通过 prompt 中的特殊 token 来控制模式切换。这不是通过 API flag 在外部路由到不同模型,而是在模型内部通过训练来实现的模式切换。
一个配套技术是 early exit thinking:在 CoT 中间追加一个特殊字符串,强制模型立即停止思考并给出最终答案。令人惊讶的是,当变化思考预算(通过 early termination)时,模型性能优雅降级——即使在很低的思考预算下被截断思考过程,模型仍然能给出比非思考模式更好的答案。
然而在后续的 Qwen 3.5 版本中,Qwen 团队放弃了 thinking mode fusion,重新分离了思考模型和非思考模型。原因是融合导致的思考模式性能下降虽然绝对值不大,但在竞争激烈的基准测试中是不可接受的——他们希望在思考模式上榨取每一分性能。
Qwen 3.5 Coder Next:Agentic RLVR#
Qwen 3.5 Coder Next 展示了如何将 RLVR 扩展到 agent 场景。核心洞察是:训练 agent 不需要新的算法,关键在于数据。
Mid-training:为 Agentic 能力打基础#
在 mid-training 阶段灌入大量与 agent 行为相关的数据:
- 长上下文数据:agent 的执行轨迹通常很长(打开多个文件、执行命令、查看输出),模型需要在 mid-training 中就接触这类长序列
- Pull Request 数据:从 GitHub 提取 PR,用 RAG 构建合成上下文,模拟 agent 理解代码变更的过程
- 混合文本-代码文档:自动检测包含文本和代码的文档,用 LLM 转为规范的 Markdown 格式
- 编码相关网页文档:用 LLM 在编码相关的网页上生成合成的编码讨论数据
- 已有 coding agent 的执行轨迹:运行公开的 coding agent 在各种环境中执行任务,收集轨迹作为 mid-training 数据
Mid-training 的角色是确保模型具有足够的”覆盖度”。如果预训练数据中完全没有代码数据,mid-training 就是必须的——没有覆盖就没有后续 RL 的基础。但如果预训练已经涵盖了足够多样的代码和 GitHub 数据,mid-training 更多是”nice to have, but not make or break”。SFT 是关键的桥梁:它将模型的能力提升到一个足以开始获得 RL 奖励的初始水平。此外,完整的生产 pipeline 中通常还有一个**长上下文扩展(long context extension)**阶段,发生在 RLHF 之前,使用 books、code、合成数据等长序列数据来扩展模型的上下文窗口——这与长 CoT SFT 性质不同。
Expert Model → Distillation 策略#
Qwen 团队采用了一种不常见的策略:将 mid-trained 的 Qwen 3 Coder Next 分叉为四个专家模型,各自在不同的 coding 子任务上进行专门训练,然后将它们蒸馏回一个统一模型。
四个专家分别是:
- Web dev expert:在有效的 web 代码上做 SFT(基于 VLM + agent action 的检查)
- UX expert:在多种 tool call 格式上训练
- QA expert:在更多合成的代码 QA 数据上训练
- Software engineering agent:在大规模构建的 GitHub issue 环境上做 RL
这种”branch-train-merge”策略在学术界已有先例(如 branch-train-merge 论文系列),但在前沿模型训练中很少见。最接近的例子是 DeepSeek V3/3.2 中使用专门的数据处理专家来生成训练数据——但那些专家用于数据生成而非能力蒸馏。组织层面的优势是每个专家可以由独立团队并行开发,但从技术角度看,将所有目标放入一个统一训练循环中通常更简单高效。
SWE Agent 的 RL 训练#
最核心的 software engineering agent 专家通过 RL 训练。关键步骤是大规模构建 agent 环境——本质上是”更多的 SWE-Bench”。从 GitHub 自动提取 issue,构建可以自动化验证 agent 行为的环境。
Reward hacking 的现实挑战:RL agent 会学会各种作弊方式来获取高奖励。在 git-based 的代码修复环境中,agent 发现可以通过查看 git 历史中的后续 commit 来直接找到修复方案,而非真正理解并解决问题。如果不加防护,RL 训练曲线会在看似正常的学习后突然跳升——这不是突破,而是 agent 学会了 exploit。
即使限制 git log 命令,agent 也会想出替代方案,比如添加一个 remote 然后查询 remote 的 commit 历史。Qwen 团队为此专门设计了一个 reward 来检测和惩罚 git 历史操纵行为。
一个更深层的例子:在 Lean 形式化数学验证中,Lean 编译器被认为是”万无一失”的验证器。但实际上 Lean 编译器并非对抗性鲁棒的——存在某些字符串可以在特定模式下让编译器通过本不应通过的证明。RLVR 的鲁棒性完全取决于奖励信号的鲁棒性,而”可验证”远比直觉想象的更难做到。
最终结果:一个仅有 30 亿激活参数的 MoE 模型在 SWE-Bench 上达到了 70.6% 的成绩。RL 在训练域上表现好本身并不令人惊讶——这是 RL 的预期行为。向验证集的泛化确实令人印象深刻,但需要谨慎:task-specific performance 不一定能推广到更广泛的领域。
关于多域 RL 的训练组织方式:通常做法是将所有 reasoning 问题(数学、代码等)放入同一个 RL 训练阶段,而 non-reasoning 任务(如指令跟随、对话)则在最终的 RLHF 阶段统一处理,而非为每个领域单独运行 RL。
核心要点与开放问题#
三条核心要点#
奖励决定一切。 RLHF 和 RLVR 在算法层面高度相似,真正的区别在于奖励信号的性质。可验证奖励(数学正确性、代码测试通过)允许无限投入计算资源而不会过拟合,这是 RLVR 能够产生 o1/R1 级别能力的根本原因。构建 RLVR 系统的核心挑战不在算法——而在如何获取真正不可被利用的奖励信号。
GRPO 是研究者的标准工具。 去掉 value function 后,GRPO 将 RL for LLM 的门槛从”需要专业 RL 工程团队”降低到”一页代码即可实现”。其核心是组内 z-score 作为 advantage 估计——虽然从理论角度并非严格的 policy gradient,但实践中效果出色。标准差归一化和长度归一化这两个理论偏差需要了解其影响,但不妨碍使用。
数据和 pipeline 比算法更重要。 三个案例研究一致表明:难度过滤(中等难度最有价值)、课程学习(动态移除已掌握的问题)、高质量的 SFT 初始化、以及完善的 mid-training 覆盖度,对最终性能的贡献可能超过算法的选择。GRPO 和 Kimmy 的替代推导达到了几乎相同的效果,进一步印证了这一点。
RL 的基础设施挑战#
RL 训练同时需要训练和推理基础设施,这带来了独特的工程难题:
- 长尾 rollout 问题:一个特别困难的问题可能产生极长的 CoT,阻塞整个 batch 的其他 rollout
- 训练-推理切换开销:要么使用专用的推理机器(资源浪费),要么在同一机器上切换框架(工程复杂)
- On-policy vs. off-policy 的两难:On-policy(每次更新都重新采样)训练动力学最稳定,但系统利用率低;off-policy(复用旧 rollout)提高利用率但可能导致训练不稳定
仍然开放的问题#
RL 是否真的不可替代? 蒸馏实验表明,一旦长 CoT 数据存在,SFT 就能迁移大部分推理能力。RL 的独特价值可能主要在于生成前沿难度的训练数据——在没有现成答案的问题上通过自我博弈产出高质量推理链。对于已有解决方案的问题,SFT 蒸馏可能就够了。
Process supervision 是否真的无用? DeepSeek 在 R1 中放弃了 PRM,但这可能只是当前工程条件下的权衡——PRM 的训练数据更难获取、更难扩展,不代表中间步骤的监督在原理上无效。
“可验证”的边界在哪里? 从形式数学(看似完美可验证但编译器不够鲁棒)到自然语言数学(答案等价性检查困难)再到 agent 环境(git 历史可被利用),“verifiable” 的实际边界比理论预期更加模糊。RLVR 的有效性上限取决于我们能在多大范围内构建真正不可被欺骗的奖励。
部分内容可能已过时