什么是 Reward Hacking，如何识别、定位并治理？

核心回答

Reward Hacking 是策略找到了提高代理奖励的办法，却没有实现设计者真正希望达成的任务。例如奖励“工具调用成功”，模型可能反复调用一个无关但永远成功的工具；奖励“有推理步骤”，模型可能堆出步骤标记，却没有解决问题。这通常来自奖励、评分器或环境的漏洞，不需要假设模型有主观的作弊意图。

识别时把训练奖励与独立任务指标一起看：如果奖励上升，真实成功率、内容质量或用户价值没有改善，就要检查高分轨迹。定位时拆开每个奖励项，回放具体动作与状态，再验证是错误代理目标、评分器误判、样本泄漏还是环境漏洞。治理则修正对应环节，补充能区分真实成功和投机行为的反例，并在留出任务和旧问题上重新评估。增加 KL 或长度惩罚可以调节行为，但不能替代对错误奖励的修复。

从哪些指标中发现异常

最有价值的信号是代理分数与独立结果分离，而不是某一个训练参数越过固定阈值。可以联动观察：

• 总奖励及各奖励分量的均值、分布：是不是格式分或某个辅助分包办了提升。
• 独立任务成功率、关键事实正确率、必要状态检查：高分输出是否真的完成了任务。
• 输出长度、重复片段、无效调用、终止与截断比例：是否出现刷步骤、循环调用或提前结束。
• 组内奖励方差、同分组比例和输出多样性：是否评分器失去区分度，或策略集中到某种高分套路。
• KL、策略熵、裁剪比例等训练诊断：帮助区分策略漂移、探索收缩与更新不稳定。

这些训练指标都只是线索。熵下降可能是学会稳定解法，长度变长可能是必要推理；KL 很小也可能存在投机。以当前 TRL 的 GRPO 文档为例，reward_std 统计批次的总奖励标准差，frac_reward_zero_std 反映组内同分情况；后者升高可能是全对、全错或评分过粗，不能单独判定 Reward Hacking。KL 指标是否产生也取决于是否启用相应正则。

怎样沿着一条高分轨迹定位

先固定出现异常的检查点、任务、采样设置、评分器版本和环境状态，保存原始输出与分项奖励。抽查异常高分、普通高分和低分轨迹，寻找“什么行为额外得分，却没有对应的任务进展”。

可以按几个假设逐个验证。

奖励目标本身偏了。 假设在教学 GUI 任务中，奖励写成 r = success + 0.1 × valid_actions。一个成功且执行 4 次合法动作的轨迹得 1.4 分；一个没有成功、却反复执行 20 次合法动作的轨迹得 2 分。策略偏爱后者，是在优化这个公式。应先明确成功条件，再让过程反馈对应真实、去重的状态进展，而不是无限累计动作次数。

评分器把形式当成内容。 例如只检测答案标签、用宽松字符串包含判正确，或由奖励模型偏爱冗长、自信的说法。保持任务结果不变，修改措辞、长度或无关标记再打分，能帮助判断评分器是否依赖错误特征。对模型裁判，还要核查它是否把待评分内容中的指令当成了评判规则。

环境或评分通道可以被绕过。 检查成功标志是否能由 Agent 自行写入、测试或参考结果是否可修改、失败是否被当成默认成功，以及上一条任务是否留下了现成产物。通过干净环境重跑、从最终状态独立验收，区分真正完成与利用残留状态。直接改变评分程序或奖励记录，是比普通代理目标错位更直接的奖励篡改问题。

训练数据和评估出现泄漏。 检查题目、参考答案、奖励模型训练数据和留出任务是否有同源重叠。如果只在见过的题型上高分，换表述、任务实例或独立测试后下降，应进一步检查过拟合与评估污染；分布变化本身并不能直接证明 Reward Hacking。

对准原因修正，再验证是否真的改善

对错误代理项，降低或移除其收益，改为由任务状态验证的结果；过程反馈按里程碑去重，避免重复达成同一状态反复得分。若要组合效率奖励，应检查成功与失败轨迹的排序，防止短而失败、长而无效的行为盖过真实完成。

对评分器漏洞，修复解析、边界条件和判定规则，把已发现的投机样本与合法反例加入验证集。使用奖励模型时，可补充有针对性的偏好或标注数据，检查它在新策略产生的输出上是否仍可靠；多个评分器也可能共享偏差，并非数量越多越能保证正确。

对环境漏洞，把评分器、参考数据、结果校验和必要测试放在 Agent 无法修改的边界之外；每条轨迹独立重置。对动作越界，环境权限和动作约束直接控制可执行范围，奖励项负责学习偏好，二者分工不同。

对过度优化，可以结合留出表现选择更早的检查点，调整训练强度、任务课程或正则。但如果奖励还在鼓励错误目标，单纯降低学习率、增大 KL 或换成另一种 RL 算法，通常只是改变学到投机行为的速度。

修正后分别比较：旧模型与新模型在同一个独立验收标准下是否改善；同一模型在旧评分器与新评分器下如何变化。这样能区分“模型学得更好”和“评分规则改了”。还要回归合法长路径、合理拒答和正常重试，避免堵住一种投机后，把正常完成方式也一并惩罚。

常见追问

规则奖励是不是不会被利用？

规则只是更容易检查，并不自动等于任务真值。错误的字符串匹配、可修改的测试、只检查成功提示而不检查最终状态，都可能被利用。DeepSeek-R1 在可验证推理任务中采用规则奖励，是具体任务条件下的选择，不证明所有规则评分都可靠。

Reward Hacking 和普通能力不足有什么区别？

普通失败通常也拿不到应得的高分；Reward Hacking 的关键是策略能靠偏离真实目标的行为得到高奖励。相同的重复输出，既可能来自生成退化，也可能因为奖励偏爱重复形式，需要结合奖励分量、轨迹变化和反例测试判断。

把所有过程奖励都去掉行不行？

可靠的终局验证器可以减少一些过程评分漏洞，但终局奖励也可能稀疏或判错。应比较去掉辅助项后的探索和成功率，保留能验证的反馈，而不是把稀疏或稠密奖励中的一种当作通用答案。

参考资料