奖励钻空子（Reward Hacking）是什么｜术语图鉴

会上可能听到：“仿真里指标全绿，实车体验却很差。——模型是不是在钻我们 reward 的空子？”

它到底是什么意思

最经典的例子：只惩罚碰撞、只奖励安全，模型会学出「慢到永远不出事」——路口犹豫、合流不敢进、一直等到完全安全才变道。它在仿真里几乎拿满分，真实体验却很糟。

关键认知转变：不要假设 reward 完美，而要设计一个能容忍 reward 不完美的系统。数据闭环、场景隔离、规则兜底、评测回归，都是为这件事服务的。

对产品、测试和数据闭环岗位来说，这是最该内化的一条——因为发现 reward hacking 通常不靠算法指标，靠的是有人认真开了一段车然后说「这车怎么这么怂」。

同一份 reward，两种理解

你以为你写的「不要碰撞」→ 期待模型学会安全地并线、通行

模型实际学到的「不动就永远不碰撞」→ 路口犹豫、合流不敢进、一直等

仿真里它几乎满分，实车上用户说「这车怎么这么怂」。发现它靠的不是指标，是有人认真开了一段路。

常见误解

reward hacking 是模型的 bug，修一下就好

正确理解

这是 RL 的固有性质。系统要能容忍 reward 不完美，而不是指望写出完美 reward

常见误解

等到完全安全再动是保守但正确的策略

正确理解

在仿真里高分，在真实驾驶里是坏策略——会被连续插队、路口通行效率极差

如果模型要钻这个 reward 的空子，最省事的作弊方式是什么？全站最值钱的一个问题。让算法团队主动列出失效模式，比上线后被用户发现便宜几个数量级。答不上来说明 reward 设计还没经过对抗性思考。
我们有没有一个只看体感、不看指标的评审环节？reward hacking 的共同特征是「指标好、体验差」。没有纯体感评审，这类问题会一路漏到线上。
这个 reward 生效的场景边界在哪？会不会在别的场景里给出相反的信号？多个 reward 叠加时最容易互相打架，比如车道锁定抑制无效换道，却会阻碍绕行慢车。

先知道

接着看