可验证奖励（RLVR）：测试通过了，任务就做对了吗？

奖励从模型变成可检查规则

让模型写一个排序函数，可以请另一个模型判断“写得好不好”，也可以把结果拿去跑测试。后者把一部分判断变成了可重复检查的程序。

如果测试只包含 [3, 1, 2]，一直返回 [1, 2, 3] 也能过。换成空列表、重复元素或负数，这个实现马上露馅。可验证奖励（拿它做强化学习（reinforcement learning, RL），就是常说的 RLVR）的价值在于检查明确、方便复现，不在于它天然没有漏洞。

换掉了什么

回顾 RLHF 的四种角色：Policy、Critic、Reward、Reference。对于能用规则检查的那部分目标，可以用验证器代替从偏好数据学出的 Reward Model；其他目标仍可以用人或模型评价，不必把整个系统都变成同一种奖励。

$$r(x,y) = \operatorname{verify}(x,y) \in \{0, 1\}$$

这里 x 包含题目及检查所需的上下文，y 是候选（candidate）回答。0/1 只是一个例子，也可以用通过测试的比例或多项分数。规则是否可重复，还取决于测试输入、运行环境、随机种子和超时设置是否固定。可验证奖励描述奖励来源，不决定必须用 PPO 还是 GRPO，也不决定是否训练 Critic。

为什么它能收窄 reward hacking

用测试替换 RM 后，不再需要让一个模型从语言外观猜代码是否正确。测试检查的性质更明确，失败也更容易复现。这能减少一类奖励模型泛化错误。

但“奖励是离散的、不可微”并不能阻止模型钻空子。Policy gradient 根据采样结果的分数调整概率，并不需要把梯度穿过测试程序。能通过不完整测试的错误实现，仍可能被逐渐强化。

规则也可能漏掉真正的要求

Reward hacking 指得到更高代理奖励的行为，没有带来我们真正想要的结果。它不要求奖励来自神经网络，手写规则也可能给错激励。

如果检查覆盖不全，训练可能强化这些本来不想要的行为：

• 针对测试用例硬编码返回值；
• 捕获所有异常让程序不崩溃，从而通过"不报错"这类检查；
• 找到测试框架本身的漏洞。

这些不是假想：agent 任务里已经测到过的钻空子案例，见前沿草稿Agent RL：环境与奖励从哪里来。反过来，奖励上升也不一定说明模型学到了奖励要求的东西：Spurious Rewards（Shao 等，2025）报告，Qwen2.5-Math-7B 用随机分配的奖励做 RLVR，MATH-500 也涨了 21.4 个百分点（真实奖励是 29.1），换到 Llama3、OLMo2 上常常没有这种效果。

数学题也一样：最终答案匹配，不足以证明中间每一步都成立。模型可能蒙对，或者过程有错却碰巧得到正确结果。是否需要检查过程，取决于你到底要求一个正确答案，还是一份可依赖的论证。

这不表示任何模型都会找到所有漏洞。更准确地说，奖励提供了优化方向；模型能否利用漏洞，还取决于它的能力、采样和训练过程。排查时，不要只看奖励是否升高，要看独立检查是否也支持“任务做得更好了”。

一个排序检查，少验了哪一件事？

输入是 [3, 1, 1]。如果验证器只检查输出是否从小到大，下面 3 个结果都会通过：

排序不仅要求有序，还要求输出是输入的一个排列。只对整数列表演示，可以写成：

from collections import Counter

def verifies_sort(original, candidate):
    ordered = all(
        left <= right
        for left, right in zip(candidate, candidate[1:])
    )
    return ordered and Counter(original) == Counter(candidate)

这段代码是检查一对输入输出的教学函数，不验证所有可能输入，也不负责安全执行未知程序。实际代码评估还要考虑输入类型、是否修改输入、异常、超时和隔离；这些约定要按任务写清楚。

现在假设模型在 [1, 3] 和 [] 之间等概率选择：输出很多样，熵为 $\log2$，但两个都没完成任务。它也可以总返回正确的 [1, 1, 3]，熵为 0，却完全满足这道题。奖励漏洞和熵下降是两条不同的检查线。 熵的算例把这个区别列成了对照表。

二元奖励带来的新问题：信号太稀疏

回到排序函数：同一个题目采样 4 份实现，测试结果是 [0, 0, 0, 0]。如果训练只用减去组均值的结果奖励，4 个 advantage 都是 0；这一项无法区分谁更值得提高概率。[0, 1, 0, 0] 才给出了组内差异。

这里说的是结果奖励对应的策略梯度项。若还有 KL、熵或其他辅助目标，参数仍可能更新。程序奖励也不必只能是 0/1：测试通过比例可以更密，但也改变了目标，可能鼓励只做容易通过的部分。

题目难度和采样预算因此很重要。先统计多少组全对或全错，再判断是需要更合适的题目、更强的起点，还是更多尝试。

全同分组有多常见，可以用 DAPO 页的混合组概率估算：固定一道题，每次独立采样的成功概率为 p、每组 G 个回答时，它的补集 $p^G+(1-p)^G$ 就是全同分的概率。G=4 时，p=0.5 只有 12.5% 的组全同分，p=0.1 或 0.9 时都升到 65.62%：太难和太容易都可能让组内信号很弱。这是独立同分布的算例；实际题目难度不同、采样相关时，应直接记录每题各组的结果，不能用整个数据集的平均 p 硬套。

像 DAPO 那样过滤全同分组，能提高更新中有区分度的组的比例，但需要额外采样，也会改变进入更新的题目分布。它不凭空创造困难题的正确解法。与筛选后 SFT一样，要同时看保留量和题目覆盖。

结果奖励还是过程奖励

只检查最终结果，容易接进训练，但无法定位错误发生在哪一步。过程奖励可以给出更细的反馈；前提是那些中间步骤确实能被可靠判断。人来标成本高，模型来标有模型误判，形式化证明的检查又需要合适的表示和工具。

不必把二者当成只能选一个。例如最终结果由测试判定，过程信号帮助搜索；但要单独验证增加过程信号后，是否真的在相同预算下更容易做对，而不是只让过程分更高。

推理时怎样用结果奖励模型和过程奖励模型挑答案、在中间步骤上搜索，见前沿草稿测试时计算：多采样、投票与验证器。读论文时也要看收益出现在哪一步。Let's Verify Step by Step，§2.1固定生成模型，比较奖励模型从多个候选中选答案的能力，并没有用 RL 更新生成模型。因此，“过程评分更会选答案”不能直接改写成“过程奖励训练出的 policy 更强”；后者需要另做训练与评估。

可验证性是个连续谱，不是二分

更实用的分类是“到底验证了哪一层”：

一个任务可以同时用几种检查。例如生成报告时，程序核对数字和链接，人再判断论证是否合理。让每个判断用合适的证据，比把所有要求都压成一个分数更容易排查问题。

设计可验证奖励时检查什么

1. 哪些故意错误的答案仍能得满分？能否加入针对性的反例测试？
2. 如果奖励是二元的，我的 batch 里有多少比例的组是全对或全错？
3. 我验的是结果还是过程？验结果的话，蒙对的比例有多高？
4. 我这个任务真的"不可验证"吗，还是我没拆开？哪一部分其实是可验的？
5. 若增加模型评判，独立检查能否发现它偏爱的错误？

继续阅读

• 偏好从哪来：学出来的奖励模型有哪些结构性上限
• PPO、GRPO 与 DPO：二元稀疏奖励和组相对基线（baseline）怎么互相放大弱点
• 对齐税：熵、解法覆盖和实际质量怎样分别检查
• Evaluation：验证器和评估集不是一回事

快速学习：可验证奖励换掉了什么

参考论文

• DeepSeek-R1，§2.2.2 — 规则式准确率与格式奖励的一个具体设计
• DAPO — 动态采样，针对全对/全错组无梯度
• Let's Verify Step by Step — 过程奖励与结果奖励的对比
• 本页排序与概率算例可用标准库教学脚本复算；没有执行模型生成代码或声称复现训练效果。