Reward Model

Reward model 把 prompt-response 或完整轨迹映射为质量信号，用于排序、筛选或策略优化。

数据

常见数据不是简单的 Input,Reward CSV，而是：

  • (prompt, chosen, rejected) 偏好对
  • 多候选排序
  • 带过程步骤的标注
  • 可验证结果和规则奖励

类型

  • Outcome reward：评价最终结果。
  • Process reward：评价中间步骤。
  • Verifier：判断答案、代码、格式或环境结果是否满足条件。

从偏好到奖励的中间层

偏好模型常把同一 prompt 下的 chosen/rejected 转成概率比较，例如 Bradley–Terry 形式 P(chosen)=σ(r_chosen-r_rejected)。训练完成后，奖励再进入排序、筛选或 RL，而不是直接等于 ground truth。

1
2
3
4
5
标注/规则
→ reward signal
→ 排序或 advantage
→ policy 改变生成分布
→ 新轨迹反过来暴露 reward 偏差

Outcome reward 对最终答案清晰但信用分配稀疏；process reward 更密集却更容易把中间形式当目标；verifier 对数学、代码、格式等可验证任务最直接，但覆盖范围有限。上线前要做 reward 与真实成功率的校准、长度/格式分层和对抗性 reward-hacking 测试。

相关节点：DPO、PPO、Reasoning RL。

风险

标注偏差、分布外泛化、reward hacking 与代理指标失真。Reward model 的高分不等同于真实任务成功。

奖励的粒度决定信用分配

如果一整条 500 token 轨迹只在结尾得到 1/0，policy 知道结果，却不知道哪一步导致成功；这就是 outcome reward 的稀疏信用。把奖励分到每个中间步骤能提高训练密度，但 process 标注本身可能把“看起来像推理”的句式当成正确步骤。verifier 则把信用绑定到可执行结果，例如代码测试通过、方程校验正确或 JSON schema 合法，但它只能覆盖能被可靠验证的任务。

因此 reward model 的训练集要按信号来源拆开：人类偏好适合风格、帮助性和安全边界，规则/verifier 适合可判定正确性，环境回报适合工具和长期任务。把三者简单加权会掩盖量纲差异；先做每个 reward 的分布、长度相关性和与真实成功率的校准，再决定组合方式。

识别 reward hacking 的实验

固定问题内容，只改变答案长度、免责声明数量、引用格式和工具调用次数，观察 reward 是否异常上升；再把高 reward 样本交给独立 verifier 或人工盲评。若 reward 对长度、特定词或格式极敏感而真实成功率不变，说明模型找到代理目标。训练中监控 reward 与 success 的 rank correlation、分桶曲线和 out-of-distribution prompts，不能用 reward 的单调上升证明能力提升。

Reward model 更新后，旧 policy 的历史分数也可能不可比。每次改 reward 版本都应重算一小批固定轨迹，并在 PPO/GRPO 的 checkpoint 中记录 reward hash、归一化方式和截断规则，否则训练回归无法区分策略变化与评分器变化。