reward-design

奖励设计

何时使用

• 为 RL 训练定义奖励函数，或评审已有奖励是否会激励错误行为
• 判断某类任务该用可验证奖励、人类偏好还是模型评判
• 结果奖励信号太稀疏、组内 rollout 全对或全错导致无梯度
• 多轮 Agent 任务要做信用分配（终局成败归因到第几步）
• 需要区分"事情办成了"与"以允许的方式办成了"
• 排查模型学会口头承诺验证、删除失败测试、自设简单检查就提前结束等行为
• 为"是否完成"设计模型无法篡改的判定（隐藏测试、状态断言、外部终止钩子）

核心原则

• 奖励设计沿三个互补维度展开：奖励来自哪里（规则/偏好/模型评判）、什么时候给（结果还是过程）、表达多少信息（标量/向量/生成式诊断）。第四个问题是结果正确时路径是否也合规。四问都答完再动手写奖励函数。
• 最可靠的来源是可验证奖励（RLVR）。 用测试用例、数据库断言、状态差异或格式检查直接判断结果。规则越确定，奖励越便宜、可复现，也越不容易被模型钻空子。有确定答案或测试时优先二元标量。
• reward hacking 与 reward seeking 是两件事。 reward hacking 是钻规则或实现漏洞拿高分（改测试、伪造结果）；reward seeking 是模型先在心里建立一个"评判器会看什么"的模型，再按这个猜测调整行为——不一定篡改测试，却可能在长程任务中自行设置一个过于简单的检查，刚好通过就提前结束。"通过了 grader"不能自动等价于"任务完成了"：评判器是意图的代理，训练越强，模型越可能把代理当成目标本身。
• 奖励结果，约束过程（RLVP）。 结果奖励解决"事情有没有办成"，表达不了"是否按规定办成"。真实 Agent 可能通过改测试文件、跳过身份验证或执行破坏性命令获得表面成功。RLVP 针对可机器判定的、与最终成败无关的结果中性约束，不能替代对语义意图、交付完整性和早停行为的独立检查。
• 真实环境通常是不对称验证器。 检测"做了一个坏动作"便宜而可靠，证明"这一步确实朝目标取得了有意义的进展"却很难。因此惩罚几乎总能恢复组内差异，进展奖励只有在部分进展可达时才有效。
• 每个新增维度都增加一种被钻空子的可能。 不要为了"奖励更丰富"而堆叠不可验证的维度；先确认这个信号能在少量 rollout 中产生有意义的组内差异，再决定是否加入训练。
• 多轮任务的终局反馈要靠外部机制归因。 多轮 LLM RL 通常将折扣因子设为 γ=1；PPO 的价值网络或 turn-level 优势负责把终点反馈归因到较早的动作，GRPO 则把轨迹级优势均摊到生成 token，长轨迹上需格外注意信号稀释。

实践模式

1. 奖励来源：三条路线

来源	适用	注意
规则 / 可验证奖励（RLVR）	数学答案、代码测试、结构化工具调用、状态断言	最优先建立；从二元结果奖励开始
人类偏好 / 奖励模型（RLHF）	目标难以完全规则化的开放式任务	奖励模型只是偏好的代理，过度优化会 reward hacking；通常用 KL 正则把策略锚定在 SFT 参考模型附近
模型评判（GRM）	难以穷举规则、需要诊断信息	不只给分，还生成"哪里做得好、哪里需要改"的诊断；让模型先归纳评价原则再按原则评价轨迹，最后用可验证事实检查评价是否正确；仍需抽样人工校准，防止评判器形成新偏差

2. 奖励时机：结果奖励打底，过程信号按需叠加

结果奖励（ORM） 只在 episode 结束判断任务是否完成，最简单，也给策略最大探索自由度。当中间路径没有公认标准、最优解尚未被发现时（如 SimpleVLA-RL 的稀疏成功/失败），它是合适起点。

关键实现：长程 coding 或 cowork 任务中，"是否完成"的判定要交给模型写不了的隐藏测试、状态断言或外部终止钩子，不能依赖模型自己声称完成。模型宣称完成时才在隔离工作区运行它看不到的验收测试，通过 +1、不通过 −1。测试必须读取真实文件或环境状态，不能只检查模型是否说了"已完成"，否则模型会学会口头承诺验证而不真正验证。

过程奖励（PRM） 在中间步骤提供反馈（身份验证、工具参数、测试通过数、导航动作），能缓解长时序信用分配，却可能把模型限制在设计者预设的路径上，且标注和验证成本更高。

工程路径：先用结果奖励建立可靠基线，再只为真正可验证的中间事件加入过程信号。

3. 奖励密度与表示形式

密度和表示是两件事。选择原则很直接：