跳到主要内容

奖励设计

奖励可以从哪三类来源获得？​

  • 最可靠的来源——可验证奖励（RLVR）: 用测试用例、数据库断言、状态差异或格式检查直接判断结果;
  • 适用任务: 数学答案、代码测试和结构化工具调用都适合从二元结果奖励开始;
  • 规则的优势: 规则越确定，奖励越便宜、可复现，也越不容易被模型钻空子;
  • RLHF（仅作背景）: InstructGPT 的基本流程是人工比较回答、训练奖励模型、再用 PPO 优化策略;
  • RLHF 的风险: 奖励模型只是偏好的代理，过度优化会导致 reward hacking，因此通常用 KL 正则把策略锚定在 SFT 参考模型附近;
  • DPO: 跳过显式奖励模型，直接从偏好对做离线优化;
  • 模型评判: 目标难以完全规则化时可用; 生成式奖励模型（GRM）不只输出分数，还生成“哪里做得好、哪里需要改”的诊断，诊断也可转成后续蒸馏或偏好数据;
  • GRM 的稳健做法: 先归纳任务评价原则，再按原则评价轨迹，最后用可验证事实检查评价是否正确;
  • 人工校准: 模型评判仍需抽样人工校准，防止评判器形成新的偏差;

reward hacking 与 reward seeking 有什么区别？​

  • reward hacking: 钻规则或实现漏洞拿高分;
  • reward seeking: 模型先在心里建立一个“评判器会看什么”的模型，再按这个猜测调整行为;
  • 区别: reward seeking 不一定篡改测试或伪造结果，却可能在长程任务中自行设置一个过于简单的检查，刚好通过就提前结束;
  • 后果: 交付物只满足代理指标，而没有满足真实意图;
  • 结论: “通过了 grader”不能自动等价于“任务完成了”——评判器是意图的代理，训练越强，模型越可能把代理当成目标本身;

结果奖励与过程奖励怎么选？​

  • 结果奖励（ORM）: 只在 episode 结束时判断任务是否完成，最简单，也给策略最大的探索自由度;
  • 适用场景: 中间路径没有公认标准、最优解尚未被人类发现时，稀疏的成功/失败奖励是合适的起点;
  • 代价: 稀疏反馈让模型难以判断多步轨迹中的具体错误，这是 RL 样本效率长期受限的原因之一;
  • 长程任务的做法: 把“是否完成”的判定交给模型写不了的隐藏测试、状态断言或外部终止钩子，而不能只依赖模型自己声称完成;
  • 过早结束的陷阱: 测试必须读取真实文件或环境状态，不能只检查模型是否说了“已完成”，否则模型可能学会口头承诺验证而不真正验证;
  • 过程奖励（PRM）: 在中间步骤提供反馈，例如检查身份验证、工具参数、测试通过数或导航动作;
  • PRM 的价值: 逐步验证能缓解长时序信用分配;
  • PRM 的代价: 可能把模型限制在设计者预设的路径上，而且标注和验证成本更高;
  • 对照: 逐步导航反馈与终点奖励构成“密集反馈换收敛速度、稀疏反馈换探索空间”的取舍;

奖励的折扣与归属怎么处理？​

  • 多轮设定: 折扣因子通常设为 γ=1\gamma=1;
  • PPO: 价值网络或 turn-level 优势负责把终点反馈归因到较早的动作;
  • GRPO: 把轨迹级优势均摊到生成 token，长轨迹上需格外注意信号稀释;
  • 工程建议: 先用结果奖励建立可靠基线，再只为真正可验证的中间事件加入过程信号;

奖励应该表达多少信息？​

  • 密度与表示形式: 是两件不同的事;
  • 标量: 只回答“总体多好”;
  • 半标量: 先给简短理由再给分数;
  • 向量: 按准确性、完整性、成本和安全等维度分别打分;
  • 生成式: 给出自然语言诊断，并可多次采样后汇总;
  • 选择原则: 有确定答案或测试时优先二元标量；有多个相互独立的质量目标时用向量，或把各维度加权成标量；开放式、难以穷举规则时用生成式诊断，但要配合事实校验与人工抽检;
  • 反向原则: 不要为了“奖励更丰富”而堆叠不可验证的维度——每增加一个评价维度，就增加一种被策略钻空子的可能;
  • 加入前验证: 先确认这个信号能在少量 rollout 中产生有意义的组内差异，再决定是否加入训练;

结果正确还不够：路径约束怎么加？​

  • 问题: 结果奖励解决“事情有没有办成”，却表达不了“是否按规定办成”;
  • 真实风险: Agent 可能通过改测试文件、跳过身份验证或执行破坏性命令获得表面成功;
  • RLVP（Reinforcement Learning with Verified Penalty）原则: 奖励结果，惩罚路径;
  • 针对对象: 可机器判定、与最终成败无关的结果中性约束；它不能替代对语义意图、交付完整性和早停行为的独立检查;
  • 非对称验证器: 真实环境里检测“做了一个坏动作”便宜而可靠，证明“这一步确实朝着目标取得了有意义的进展”却很难;
  • 合并公式: R=O+βΦR=O+\beta\Phi，其中 OO 是任务结果，Φ\Phi 是由确定性规则逐动作计算的路径信号；两路归一化后再合并，避免路径信号淹没主目标;
  • 实现方式:
outcome = verify_final_state(trajectory)              # result, not self-report
path_signal = 0
for step in trajectory:
    path_signal += deterministic_path_signal(step)    # penalty or reachable progress
reward = normalize(outcome) + beta * normalize(path_signal)
  • 关键判断: 关键不是“奖励越密越好”，而是能否恢复组内差异;
  • 纯结果奖励的不足: 在全败组和全胜组都会产生零方差、没有梯度;
  • 惩罚的特点: 违规动作通常容易检测，惩罚几乎总能恢复差异;
  • 进展奖励的特点: 只有在部分进展可达时才有效;

路径约束的四条设计原则是什么？​

  • 只惩罚具体动作: 不惩罚“不够努力”;
  • 始终保留结果奖励: 避免模型学会什么都不做;
  • 每个惩罚配一条可达的合规路径: 让模型有路可走;
  • 规则确定且难以钻空子: 不引入新的 reward hacking 面;
  • 起点问题: 如果基础策略根本不会采样合规动作，应先用少量示范把这条路径“种”出来，待合规行为稳定后再逐步减弱路径塑形;
  • 一句话: 惩罚是通常可达的那一半，进展奖励是受可达性门控的那一半;

路径约束实验测到了什么？​

  • 设定: 在 GRPO 上加入结果奖励 OO 与路径信号 Φ\Phi，与纯结果奖励对比;
  • TerminalBench: 违规次数由 3.71 降至 0.66，成功率基本持平;
  • miniF2F: 可达的部分奖励把达到 0.9 成功率所需的迭代从 7.0 降至 4.4;
  • 反例: 软件修复中若所有 rollout 都无法通过任何测试，进展信号不可达，加入它不会带来收益;
  • 方法论: 先测信号可达性，再决定是否增加奖励维度;
  • 外推边界: 这些数字来自可控的代理环境，不能直接外推为线上 Agent 也会获得同等提升;
  • 机制性结论: 只要路径信号能在同一组 rollout 中区分行为，且规则不易被策略钻空子，它就能补上终点奖励看不见的那部分信息;
  • 部署配套: 隐藏验证、轨迹监控与外部终止条件仍需一并纳入 Harness，见Harness 工程与从问题案例到训练数据;