reward-design

---
name: reward-design
description: 为 RL 训练设计奖励函数或排查奖励黑客时使用——决定奖励来自规则、人类偏好还是模型评判，结果奖励还是过程奖励，标量、向量还是生成式诊断，以及如何用路径约束与 RLVP 惩罚违规动作；也用于多轮 Agent 的信用分配、隐藏测试与早停判定设计。触发词：奖励设计、reward hacking、reward seeking、RLVR、RLHF、GRM、ORM、PRM、RLVP、信用分配、隐藏测试、过程奖励、奖励塑形、组内差异。
---

# 奖励设计

## 何时使用

- 为 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. 奖励密度与表示形式

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

- 有确定答案或测试 → **优先二元标量**
- 有多个相互独立的质量目标 → **向量**（按准确性、完整性、成本、安全分别打分），或将各维度加权成标量
- 开放式、难以穷举规则 → **生成式诊断**，但要配合事实校验和人工抽检

半标量（先给简短理由再给分数）介于两者之间，便于归因。

### 4. 路径约束与 RLVP：两路奖励再合并

把验证器输出拆成两路，交给现有策略优化器（不改变 PPO/GRPO，只改变每一步看到的奖励）：

```python
outcome = verify_final_state(trajectory)              # 读结果，不是模型自述
path_signal = 0
for step in trajectory:
    path_signal += deterministic_path_signal(step)    # 惩罚违规，或奖励可达子目标
reward = normalize(outcome) + beta * normalize(path_signal)
```

总奖励写作 `R = O + βΦ`：`O` 是任务结果，`Φ` 是由确定性规则逐动作计算的路径信号。对可验证的违规动作扣分，对可验证的合规动作或可达子目标给少量部分奖励；**两路各自归一化后再合并**，避免路径信号淹没主目标。

RLVP 的四条设计规则：

1. **只惩罚具体动作，不惩罚"不够努力"**——惩罚规则必须确定、难以钻空子。
2. **结果奖励始终保留**——避免模型学会什么都不做（什么都不做就不会违规）。
3. **每个惩罚最好配一条可达的合规路径**；如果基础策略根本不会采样合规动作，先用少量示范把这条路径"种"出来，待合规行为稳定后再逐步减弱路径塑形。
4. **先测信号可达性，再决定是否增加奖励维度**。软件修复中若所有 rollout 都无法通过任何测试，进展信号不可达，加入它不会带来收益。

一句话概括配比：**惩罚是通常可达的那一半，进展奖励是受可达性门控的那一半。**

### 5. 多轮任务的信用分配

- 终局成功/失败难以归因到具体某一轮时，优先用**逐步可验证的中间事件**构造过程信号，而不是发明更复杂的优势估计。
- 工具轨迹中环境返回的 token 不是策略生成的，**计算策略梯度时必须屏蔽这些反馈 token**，只对模型自己的思考和工具调用参数回传梯度。
- 用带价值网络的 PPO 做细粒度信用分配；用 GRPO 时注意轨迹级优势均摊到所有生成 token 会造成信号稀释，长轨迹上更明显。
- 把"宣称完成"当作一个独立决策点来处理：在它前面挂外部验证器，而不是指望终局奖励顺带修正。

## 常见陷阱

- **只看回复长度就生成冗长无意义的文本**式奖励——评估最终目标而非中间指标。
- **把"通过了 grader"当成"任务完成了"**，忽略 reward seeking：模型自设一个过于简单的检查、刚好通过就提前结束，交付物只满足代理指标。
- **奖励维度堆叠**：每加一个不可验证的维度就多一种被钻空子的方式；先验证信号能在少量 rollout 中产生组内差异再加入。
- **结果奖励缺位、只有路径惩罚**：模型很快学会什么都不做。
- **进展奖励不可达时硬加**：全败组里进展信号取不到值，只会增加噪声。
- **过程奖励过度塑形**：把模型限制在设计者预设的路径上，丧失探索空间；也可能奖励"正确的过程导致错误的结果"。
- **验证器本身有系统性偏差**：RL 只会更快地利用它。先用少量 rollout 检查"任务是否可完成、验证器能否区分对错"，再扩大采样规模。
- **用模型自述代替状态检查**：删除失败测试用例也能让测试通过；口头承诺"7 天内退款"也能得到暂时满意。过程验证层必须由代码判定政策库、权限表与动作轨迹。
- **模拟器漏洞被主动利用**：用 LLM 扮演环境训练时，Agent 钻空子的对象从"真实环境的规则"变成"模拟器本身的偏见与漏洞"，RL 会主动寻找并利用它。稳妥做法是混合——模型模拟承担大部分交互量，辅以真实环境交互并定期校准。

## 配套代码

- `chapter8/RLVP/` — RLVP 复现指南：GRPO 上叠加结果奖励与确定性路径信号；书中报告 TerminalBench 违规次数 3.71→0.66 而成功率基本持平，miniF2F 上可达的部分奖励把达到 0.9 成功率所需迭代从 7.0 降至 4.4。
- `chapter8/premature-completion-dpo/` — "过早结束"案例的隐藏测试奖励落地：`data/hidden_tests.json` 提供模型不可见的端到端验收脚本，`train_grpo_optional.py` 是同一问题的可选 RL 分支。
- `chapter8/SimpleVLA-RL/` — 稀疏结果奖励保留最大探索空间的对照案例（每条任务仅一条演示 SFT 冷启动，17.3%→91.7%）。
- `chapter8/retool/` — 工具反馈如何改变思考策略：模型学会主动执行、读取错误并自我修正。
- `chapter8/AWorld-train/` — MCP 多工具沙盒中的奖励与可重放环境链路。

## 深度阅读

- `book/chapter8.md`「从单轮到多轮：任务场景与信用分配」
- `book/chapter8.md`「奖励设计：如何把任务目标变成学习信号」
- `book/chapter8.md`「RL 环境：从评估到仿真」
- `book/chapter8.md`「后训练实践要点」
- `book/chapter9.md`「从运行轨迹中获得学习信号」

More agent context in bojieli/ai-agent-book-projects

21 other files this repository gives its agents.

Also found in one other repository

The same file, byte for byte, in the weekly crawl of public GitHub.

• bojieli/ai-agent-book53k