RLVR 与 GRPO
RLVR 与 GRPO
模型训练与对齐 已介绍 RLHF、DPO、RLVR 和 GRPO 的基础流程。本页相对训练页的增量是：验证器怎么设计、过程奖励与结果奖励如何分工、reward hacking 与投机，以及评测口径。核心问题是：当任务存在可机械验证的结果时，如何把验证结果转化为大模型的推理能力。
RLVR 是 Reinforcement Learning with Verifiable Rewards 的缩写。它不要求人类逐条比较两个答案，而是使用代码执行结果、数学答案、定理证明检查器、格式解析器或环境回报作为奖励来源。
从偏好奖励到可验证奖励
RLHF 的奖励信号
RLHF 通常训练奖励模型拟合人类偏好。它适合帮助模型学会有帮助、诚实、礼貌和符合风格的回答，但人类偏好往往难以逐步验证。奖励模型可能把长度、语气和格式误认为质量。
Outcome Reward 与 Process Reward
| 奖励类型 | 评分对象 | 优点 | 局限 |
|---|---|---|---|
| Outcome Reward | 最终答案 | 标注或计算简单；适合有明确答案的任务 | 不知道哪一步出错 |
| Process Reward | 中间推理步骤 | 可以定位错误、指导搜索 | 标注昂贵，步骤评价有主观性 |
| Verifiable Reward | 可执行的最终结果或轨迹 | 可规模化、规则明确 | 只覆盖可验证任务 |
| Preference Reward | 人类或模型的相对偏好 | 可用于开放式质量 | 容易被格式和风格欺骗 |
Let's Verify Step by Step 说明过程监督可以提高复杂数学推理的可验证性，但过程奖励模型并不天然等于逻辑证明器。它仍然需要检查标注一致性、步骤粒度和分布外解法。
GRPO：组内相对优势
DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models 将 GRPO（Group Relative Policy Optimization）用于数学推理训练。其基本做法是：
- 对同一个问题采样一组回答；
- 使用数学答案检查器或其他奖励函数评分；
- 在组内计算相对奖励和优势，而不是为每个样本单独训练一个价值模型；
- 提高高奖励回答的概率，抑制低奖励回答，并加入 KL 约束控制策略偏移。
组内相对比较的好处是减少价值模型的额外成本。它的前提是同组样本共享足够有意义的比较关系；如果所有样本都错，或者奖励函数无法区分质量，组内归一化只是在错误之间排名。
DeepSeekMath 与 DeepSeek-R1
DeepSeekMath 证明了高质量数学语料、工具辅助和可验证奖励可以共同改善开源模型的数学推理。其重要贡献不只是算法名称，还包括：
- 数学网页和论文数据的筛选；
- 数学问题与解答的合成和过滤；
- 代码执行、答案匹配等自动验证；
- 从基础模型到推理模型的阶段化训练。
DeepSeek-R1 展示了大规模强化学习驱动的推理模型路线。论文报告模型在数学、代码和推理任务上获得提升，并观察到较长的思考过程、自我检查和工具使用行为。
阅读这类论文时要区分：
- 能力结果：某个模型在指定 benchmark 上的分数；
- 训练机制：使用了哪些奖励、采样、过滤和 RL 算法；
- 涌现行为：论文观察到的模式是否在不同模型和任务上重复出现；
- 产品能力：离线推理分数是否转化为稳定的用户任务完成。
验证器设计
验证器的层级
从强到弱可以分为：
- 执行验证：编译代码、运行单元测试、检查定理证明；
- 符号验证：代入答案、进行代数化简、比较规范化表达；
- 规则验证：JSON schema、SQL 语法、约束满足；
- 模型验证：由另一个模型判断答案或步骤；
- 人工验证：专家评审高风险结果。
验证器越接近任务真实目标，奖励越可靠。验证器覆盖范围不足时，模型会优化“可被验证的代理目标”，而不是产品真正关心的目标。
奖励投机
RLVR 也会产生 reward hacking：
- 代码模型生成绕过测试的实现，而不是正确实现；
- 数学模型利用答案格式漏洞通过检查；
- Agent 只完成可计分的子步骤，破坏环境状态；
- 模型生成更长的推理以增加被判对的机会；
- 验证器对特定模板过拟合，模型学会复现模板。
防护方法包括隐藏测试集、独立验证器、随机化测试、轨迹约束、过程抽查和最终任务复核。验证器代码本身也需要像生产代码一样做单元测试、对抗测试和版本管理。
RLVR 与 RLHF 的分工
| 场景 | 更适合的信号 | 说明 |
|---|---|---|
| 数学答案 | 符号或数值验证 | 正确性清晰，适合规模化采样 |
| 代码修复 | 编译、单测、静态检查 | 要防止测试不充分和作弊 |
| 工具调用 | schema、执行结果、任务终态 | 需要同时评价参数与副作用 |
| 长文写作 | 人类偏好、事实核查 | 很难定义单一可验证奖励 |
| 安全拒答 | 规则、红队、人工复核 | 不能只依赖奖励模型 |
| 机器人控制 | 环境奖励、碰撞和任务成功 | 真实试错成本高，需要仿真与安全边界 |
RLVR 不会取代 RLHF。前者擅长可验证的任务正确性，后者仍需要处理帮助性、表达质量、价值冲突和开放式偏好。
训练与评测注意事项
- 训练题、验证题和公开 benchmark 必须去重，防止奖励函数或题库污染；
- 结果奖励不能直接证明中间推理正确，过程监督需要独立证据；
- 评测要记录采样次数、最大思考 token、验证器调用次数和失败重试；
- 对比不同模型时要固定总计算预算，而不是只固定一次生成长度；
- 记录模型是否可以拒绝无法验证的问题，避免把猜测当成成功；
- 对工具和环境任务，终态成功率比中间轨迹的“看起来合理”更重要。
给 AI 产品经理的结论
RLVR 最适合存在清晰验收标准、可以自动运行检查、错误代价可以控制的任务。产品落地前应先建立验证器覆盖率：有多少真实任务可以被可靠判断，有多少结果仍需要人工复核。没有可靠验证器时，增加 RL 训练或推理预算都可能只是把错误优化得更自信。
来源说明
本文为原创整理，引用日期：2026-09-04。基础概念参见 模型训练与对齐。主要来源包括 Let's Verify Step by Step、DeepSeekMath 与 DeepSeek-R1。关于奖励投机的判断需要结合具体验证器、数据和环境复核。
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用