面向智能体的 RLVR 与 GRPO

三阶段配方：SFT、偏好对齐、可核验奖励的 RL。

2026 年任何一支认真的后训练团队都按同一条流水线跑，顺序如下，消融实验让这个顺序难以反驳。第一阶段是在示范语料上做有监督微调：正确轨迹，通常从更强的模型蒸馏而来，教策略掌握任务形状、把输出分布拉到"有用行为"的邻域。跳过 SFT，后续的 RL 会把大半预算耗在教语法而不是教技能上。第二阶段是偏好对齐——在离线偏好对上跑 DPO，或者用更简单、长度归一的 SimPO——把策略推向人类（或更强的 AI 评判者）偏好的排序，而不必付一份完整学习奖励模型的成本。RLHF 与 RLAIF 讲解更细地覆盖了排序逻辑；这里要点在于：第二阶段发生在可核验奖励阶段之前，而不是取而代之。

第三阶段是 2026 与 2024 分道扬镳的地方。优化器是 GRPO 或其 DAPO 系变体，奖励是可核验的：来自单元测试的通过／失败、来自证明检查器、来自基准字符串比对、来自可执行的 oracle。这就是 "RLVR" ——可核验奖励强化学习——所命名的东西。这里的主张不是"可核验奖励是新东西"；而是：它是唯一在大规模下能挺过奖励黑客那一篇所罗列的奖励黑客动力学的信号。学习到的奖励模型可被博弈；编译器不行。第三阶段的预算，就是能力增益出现在硬基准上的地方，也是本文其余部分点名的失败模式的居所。

唯一值得点名的排布问题：DPO 与 GRPO 不是可互换的替代品。DPO 便宜、离线、无法利用面向核验器的新 rollout；GRPO 昂贵、on-policy、离开核验器根本跑不起来。跳过第二阶段、从 SFT 直接跳到 GRPO 的团队会发现，在尚未对齐的策略上做组内相对优势估计噪声很大，然后把样本预算花在 DPO 本来就能便宜教会的偏好上。跳过第三阶段、停在 DPO 的团队则得到一个对齐良好、却在核验器本可解锁的水位之下停滞的模型。三阶段是组合关系；每一阶段都挣得起自己那份预算。

可核验奖励：什么配这个标签，什么不配。

当校验便宜、确定性、难以博弈——一个不带学习模型的、可执行的 oracle 返回一个标量——奖励才算是可核验。代码是标准范例：跑单元测试，通过返 1.0，失败返 0.0。数学第二：把数值答案送进检查器，或做符号相等性判断。SQL 与结构化数据抽取任务第三：在固定的评估集上把产出的行与基准比对。它们都具备让 RLVR 奏效的两个性质——校验器每次 rollout 花的钱比策略更少，且策略无法通过写"看起来靠谱"的输出去糊弄它。

只要上述任何一条性质变弱，标签就开始脱落。由一个 LLM 评判者按 rubric 打分的重写，不是可核验的；它是学习到的，与奖励模型是同一意义上的学习，遭遇同样的奖励黑客动力学。"代码能不能编译"这类奖励技术上可核验，但太弱以至于策略学会产出"能编译却什么都不做的"平凡代码。会把答案泄漏进观测的校验器——工具在模型该自行推导之前就把 ground truth 交回给模型——是训练层面的 bug，策略会在几千次 rollout 内找到并利用它。守纪的做法是先写下"你的校验器接受什么、拒绝什么"，然后在开跑之前对它做对抗性探测，而不是事后。

# Verifiable reward: an executable oracle, not a learned RM.
# For each rollout, run the check; the scalar goes back to GRPO.
def verifiable_reward(task, trajectory):
    final = extract_final(trajectory)
    if task.kind == "code":
        return 1.0 if run_tests(final, task.tests) else 0.0
    if task.kind == "math":
        return 1.0 if numeric_equal(final, task.answer) else 0.0
    if task.kind == "sql":
        return 1.0 if rows_equal(execute(final), task.gold_rows) else 0.0
    raise NotVerifiable(task.kind)

决定"你到底有没有 RLVR 项目"的领域问题，就写在那段代码的最后一行：如果答案不是代码、数学、也不是结构化查询，task.kind 应该是什么？对智能体任务，答案往往是"一串工具调用，加上末尾的一个状态检查"，这个方向由面向工具使用的 RL 一文细讲；此时校验器变成"环境加一个终点谓词"，而不是一次性函数。对散文类任务，诚实的答案是"你没有校验器"，配方于是变成"DPO 配 AI 评判者"，而不是 GRPO。到底你在做哪一件事，比"用哪种优化器"更要紧。

GRPO 与 DAPO：组内相对优势和它换来什么。

GRPO——组内相对策略优化——是把价值函数拿掉的 PPO。它不再学一个 critic 去估计 baseline，而是在同一任务上采一组轨迹、以这一组的平均奖励作为 baseline、把每条轨迹的优势算作"奖励减 baseline"。效果是：优化器再也不需要一张价值网络，训练每一步的算力砍半，也消除了一类"critic 不稳"的失败模式。代价是：组要够大以让均值成为稳定 baseline（通常每任务 8 到 64 条轨迹），且奖励得是这一组能有意义地互比的一个标量。二值可核验奖励与此天生契合：组内半数通过、半数失败，优势信号恰好就是"这条轨迹是否站在赢的一边"。

DAPO——直接优势策略优化，以及几个同名的变体——沿着两个方向扩展 GRPO。其一，用更精巧的估计器（按任务族的滚动统计、按难度归一化）替换组内相对 baseline，以在通过率极高或极低的任务上降低方差。其二，加上从 PPO 邻近更新借来的裁剪与约束项，避免策略在一步里走得太远。之所以要知道这个名字：一旦朴素 GRPO 的方差在规模上无法忍受，生产团队会伸手去够的正是 DAPO 系。之所以别过度投资于这套分类：DAPO 家族仍在收敛中，隔一个季度出的论文常常在给同一个核心技法换标签。

# GRPO training step, simplified. Group size G, task t, policy pi.
for t in batch_of_tasks:
    trajs = [sample(pi, t) for _ in range(G)]
    rewards = [verifiable_reward(t, tr) for tr in trajs]
    baseline = mean(rewards)
    advs = [r - baseline for r in rewards]
    for tr, a in zip(trajs, advs):
        loss = -a * logprob(pi, tr)
        loss += beta * kl(pi, pi_ref, tr)   # KL leash to the base
        optimizer_step(loss)

决定一次 GRPO 训练是否成功的两个实现细节几乎每次都是同一对。其一：对冻结的参考策略——代码里的 pi_ref——的 KL 项是根牵绳，防止策略漂进"核验器仍接受、但人类评判者主观质量已崩"的区域。系数 beta 设太低，第三阶段会抹掉第二阶段付过钱的对齐；设太高，策略动不了、优化不起来。其二：如何处理"整组全过"或"整组全败"的情形——此时优势为零、更新不带信号；多数实现会检测到并要么重采任务、要么跳过更新，因为把这些步计入训练进度，正是"按 run 平均的 loss 曲线骗你"的方式。

熵坍缩与 KL 漂移：两种带面板的失败模式。

熵坍缩是最早出现、也最容易被发现的失败模式。GRPO 的组内相对信号会强化"赢的那条轨迹所走的动作"，当同一类任务被反复抽到，策略在"要紧的那些 token"上的动作分布会窄下去，直到组内产出近乎相同的轨迹、进而产出近零优势、进而停止训练。面板上的特征：按 token 计的组内平均熵在几千步里单调下滑、然后在接近零处平台化；通过率还能爬一段、然后也平台化，位于"更健康的熵曲线本可到达"的水位之下。有效干预都便宜——loss 里加一个熵奖励项、通过在阈值以下加均匀噪声设一个熵下限、rollout 时用略高一点的温度采样——多数团队搞砸的地方是"发现坍缩正在发生"。

step  |  pass_rate  |  group_entropy  |  kl_to_ref  |  status
------+-------------+-----------------+-------------+--------
  200 |   0.42      |   1.83          |   0.04      |  healthy
  800 |   0.61      |   1.51          |   0.11      |  healthy
 1600 |   0.73      |   1.02          |   0.19      |  entropy trending down
 2400 |   0.79      |   0.48          |   0.28      |  ENTROPY COLLAPSE
 3200 |   0.79      |   0.11          |   0.44      |  stalled + KL drifting

KL 漂移是第二种失败模式，且更隐蔽——通过率仍在攀升，策略却在悄悄走离参考。失败面不在核验器分数上，而在核验器不度量的一切之上。一次以代码为核验器的 RL run，当它到参考的 KL 越过某个 run 特定阈值——对 7B 底座，每 token 0.5 nats 是个像样的早期预警——就会开始产出"测试能过、但没人愿意看"的代码，或"数值答案对、推理胡说"的数学解。只盯通过率是抓不出来的。缓解办法不是消灭 KL 漂移——第三阶段的整个用意就是让策略动起来——而是限它一个上界，把 beta 系数当作一个主动的旋钮用；同时保留一小份留出评估集，让核验器不再是唯一的裁判。跳过那份留出集的团队，就是那些上线了回归、然后把锅甩给校验器的团队。

第三种模式在更长的 run 上会出现，值得点名：核验器过拟合。若校验器是一份固定的单元测试，策略会具体地对那些测试做模式匹配，在同域新测试上的泛化能力受损。修法是轮换校验器——从更大的池里采样测试、生成同义改写、留一部分出——这很贵，但决定了"这次 RL 是让模型变强，还是只让基准分数变高"。

多轮：ARPO、StepPO、Turn-PPO，以及"一种算法不够用"。

以上所有讨论都假设一条轨迹以一个标量奖励收尾。智能体后训练立刻打破这一假设：轨迹是一串轮次、其间穿插工具调用，末端的结果奖励是"对一条做了几十次决策的轨迹"给出的一个标量。朴素 GRPO 把终点优势平均施加到轨迹里的每一步，训练信号被摊得太薄，迫使策略去猜"我这么多动作里到底是哪一次真的要紧"。多轮算法家族——ARPO、StepPO、Turn-PPO，以及自 2025 年以来它们的几个近同义名——都是同一件事的尝试：把信号集中到"真正配得上信用的那一步或那一轮"。

ARPO（优势重加权策略优化）用一个轻量 critic——只在轮次级状态上训练，不在单个 token 上训练——按"每一轮让轨迹的期望价值变了多少"来在轮次间重分配优势。StepPO 走同类思路但粒度更细，用过程奖励模型（过程 vs 结果奖励一文细讲）给每一步打分、按步施加优势。Turn-PPO 把轨迹切成"每轮一次 PPO 更新"，每轮附带一个小型学习优势；它是三者里最简单的，也是早期实验里最稳的。截至撰稿三者都还没有分出胜负；团队按手里有没有过程标签（StepPO）、能不能负担 critic（ARPO）、还是想要最少的基础设施（Turn-PPO）来选。

本文想让你带走的设计判断不是"三选一"。而是：只有当轨迹长到"信用分配变成瓶颈"时——三十步及以上、rollout 计数上万——这个选择才要紧。轨迹更短时，朴素 GRPO 的均摊信用够接近正确，多出来的机构会成为死重。这与面向工具使用的 RL 一文给出的、更一般的"按时程做选择"的模式相同：先测时程，再把算法配上去，别反过来。

何时单用 PPO、单用 DPO、或什么都不上仍然是对的。

上面的配方是昂贵的。第一阶段便宜；第二阶段中等；第三阶段是账单所在——on-policy RL 打真核验器，意味着要在几万次 rollout 上跑核验器，除最简单的 oracle 外，算力都花在这里。三种情形值得把配方留给更轻的路径：底座能力已然是瓶颈的小策略、核验器不够稳以致挺不过对抗 rollout 的任务、以及"SFT 加轻量偏好对齐"就已把策略拉进可接受质量带的负载。

小策略——对推理型任务，参数量在约 3B 以下的——从"SFT 加蒸馏"收获的常常比从 RL 更多，因为 RL 信号很难穿过"底层表征缺失"的网络找到有用的梯度。这正是SFT、拒绝采样与蒸馏 一文所讲的模式：从更强的教师拉知识进来、再对齐，除非你有具体理由认为"小模型有未释放的能力等着 RL 挖出来"，否则跳过 RL 阶段。7B 以下的推理模型经常在 GRPO 上停止爬升，而在同期蒸馏路径上仍在攀升。

核验器不稳的任务——通过／失败信号会随运行时环境变化，或"可接受的答案"会被严格 oracle 拒绝——会毒化 RLVR，因为奖励变噪、策略学会博弈这份噪声。修法是先把核验器"变硬"，跟"在把一份易碎测试跑一百万次之前先修好它"是同一个精神。已经"SFT 加 DPO"就落在可接受带内的负载不欠自己"第三阶段"；第三阶段的价值出现在"第二阶段的天花板显著低于任务要求"的地方，而不是天花板已经舒适的地方。RLVR + GRPO 是 2026 年智能体后训练的标准配方，因为在推理、代码、工具使用这些任务上，第三阶段的回报是真的；纪律在于承认这份回报是有条件的，并在条件不成立时跳过它。