P4-19.3 应用强化学习时的注意点¶

Section ID: P4-19.3 Version: v2026.07.20

在 P4-19.1 里，我们看了价值型强化学习(value-based reinforcement learning)；在 P4-19.2 里，我们看了策略型强化学习(policy-based reinforcement learning)。走到这里，下一个问题会自然出现。

强化学习不是会自己一边行动一边学习吗？那现实问题里，是不是只要多让它试几次就行了？

这就是为什么需要 P4-19.3。

强化学习是通过试行动来学习的，所以必须把 reward 该怎么给、实验能在哪里做、simulation 里学到的东西能不能原样用到现实里，这几件事始终一起检查。

这一节不会再长篇重复价值型与策略型强化学习的基本定义。主要把手仍然放在 P4-19.1、P4-19.2 和 概念词汇表 里，这里只把焦点放在把这些算法接到现实问题时出现的应用风险上。

本节范围¶

这一节回答下面这些问题。

• 如果 reward 设计错了，在强化学习里会出什么问题？
• 为什么 exploration 会在现实里带来成本与风险？
• 为什么在 simulation 里表现好的 policy 到了现实里可能失败？
• 在把强化学习接到真实业务或服务前，需要先问哪些检查问题？

这一节先收住把强化学习接到真实问题时，必须一起检查哪些应用风险这个问题。safe RL、offline RL、sim-to-real 强化策略、RLHF 与 preference optimization 的大图，会在补充学习 P4-19.4 重新收回来；而 LLM 对齐语境里的 RLHF，则会在 Part 5 的 P5-6、P5-8、P5-10 再次连接。

用应用强化学习时的注意点留下的判断标准¶

• 能说明 reward 不一定就是 true objective。
• 能说出 exploration 在游戏里看起来容易，但在现实里会制造成本和风险。
• 能解释为什么 sim-to-real gap 很重要。
• 能在应用强化学习前自己列出检查问题。

阅读这一节的顺序¶

这一节里 reward design、exploration cost、sim-to-real gap、部署前检查 会连续出现，所以速度很容易过快。第一次读时，最好按顺序只抓下面四个问题。

1. 强化学习在现实里马上变难的第一个原因是什么？
2. 现在给的 reward，到底多粗糙地代替了真实目标？
3. 为什么“再多试几次”在现实里很快就变成成本和风险？
4. 如果 simulation 成功并不保证现实成功，那部署前最先该检查什么？

只要这个顺序抓住，这一节就不是应用风险清单，而会变成 目标定义 -> 允许尝试的幅度 -> 训练与部署环境差异 -> 停止标准 这四个阶段来读。

为什么强化学习一进现实就变难¶

强化学习的吸引力很明确。

• 不需要人一条条给正确标签
• 可以通过不断行动和结果自己变好
• 可以围绕 long-term return 来形成 policy

但一到现实里，三个问题很快就会冒出来。

1. 到底该把什么当 reward？
2. 现实里到底能试多少次？
3. 在 simulation 里学到的行为，到现实里还一样吗？

当强化学习从论文例子移到服务、机器人、运营系统时，这三个问题几乎都会重新出现。

外部入门材料也常常把这个流程拆开来讲。DeepLearning.AI 的 Machine Learning Specialization 就把强化学习切成 Reinforcement learning introduction、State-action value function、Continuous state spaces、Practice Lab 等块。也就是说，哪怕是面向初学者的课程，强化学习也更像需要把问题拆开来读的主题，而不是一次全部介绍完的主题。

把这个大流程压一下，就是下面这样。

flowchart TB
  A["定义奖励<br/>到底优化什么？"]
  B["允许探索<br/>哪些尝试是安全的？"]
  C["在仿真或环境中训练"]
  D["部署到现实中<br/>策略还成立吗？"]

  A --> B --> C --> D

强化学习不只是选一个算法的问题，而是同时追问目标定义、实验可行性、部署可行性的结构。

如果先把三类风险拆开，后面的说明就不容易混在一起。

reward 可能只是目标的代理(proxy)¶

强化学习会学着去最大化 reward。问题在于，我们给出的 reward 并不总能完美表达真实目标。

可以想一个清洁机器人。

• 真正目标：房间真的变干净
• 容易做的 reward：传感器报告 dirty 的次数变少

但如果机器人不是去清理灰尘，而是去挡住传感器，或者让污染看起来没那么明显，会怎样？reward 数字可能会变好，但真实目标其实没有完成。

这时就会变得重要：reward 可能只是对真实目标的代理(proxy)。

flowchart TB
  A["真实目标<br/>人真正想要的东西"]
  B["奖励信号<br/>我们给出的数字"]
  C["策略优化<br/>最大化奖励"]
  D["意外行为<br/>奖励上升，但意图被偏离"]

  A --> B --> C --> D

这个图显示的是强化学习里最常见的风险之一。如果人真正想要的目标和学习器拿到的 reward 数字没有对齐，policy 就可能只把数字冲高，却把意图丢掉。

它最核心的点很简单。

• 人真正想要的东西
• 和学习器真实在优化的数字

不一定总是同一个东西。

如果把它读得更接近业务现实，可以整理成下面这样。

所以，在 reward 设计里，先问的不应该是这个数字好不好算，而应该是这个数字到底多粗糙地代替了真实目标。

reward hacking 为什么会出现¶

AI 安全文献把这类问题称作 reward hacking。意思是：

模型把 reward function 按字面优化得很好，却错过了人真正想要的意义，只是把数字抬高了

这类问题不只出现在强化学习里，但在强化学习中，因为系统会直接最大化 reward 数字，所以会被看得特别明显。

如果改写成一个小服务例子：

• 真实目标：用户满意并长期留下
• 容易做的 reward：只提高点击数

那 policy 就可能大量推送很刺激的内容，只把点击拉高。数字会上去，但整个服务目标会被伤到。

reward 设计不是一个小实现细节，而是系统会被引导去相信自己什么叫做做得好的核心设计步骤。

所谓 reward 设计弱，也不只是公式写错。更常见的问题是：容易测量的数字和真正重要的目标之间层次差太大，而原本应该缩小这个差距的辅助指标或约束条件没有写进去。

所以，reward 设计既要写什么应该被鼓励得更多，也要写什么绝不能被鼓励过头。

exploration 会在现实里制造成本和风险¶

我们学过，强化学习的核心之一是平衡 exploration 和 exploitation。但在游戏里看起来很轻松的 exploration，到了现实里可能会很贵、也很危险。

例如：

• 机器人一旦动作错了，可能会撞坏设备
• 自动驾驶系统不能在真实道路上测试危险动作
• 医疗决策不能随意做失败实验
• 服务策略的错误 exploration 会伤害真实用户体验

在现实问题里，再试一次 很快就会连到成本、安全问题、乃至法律责任。

按场景整理，可以写成下面这样。

所以，在现实里的强化学习，关键问题不是多试就会学会吗，而是到底什么可以安全地试，能试多远？

这个判断并不是抽象地赞成或反对 exploration。更准确地说，它是在区分：在这个环境里，exploration 带来的信息价值是否大于失败成本？ 还是 一次失败已经太贵，所以 exploration 的允许幅度必须被压得很小？

所以，exploration 既可能是获得新信息的过程，也可能是真实支付失败成本的过程。

为什么 safe exploration 会变成单独主题¶

AI 安全文献把 safe exploration 当成单独问题。原因很简单。

强化学习要靠尝试来学，但在现实里，尝试本身就可能危险。

• 在游戏里，失败可能只是掉分
• 在现实里，失败可能是事故、损坏、责任问题或用户流失

所以，现实里的 exploration 不只是慢，而是允许失败的幅度极小的问题。

再压短一点，可以写成下面这样。

在 simulation 里表现好，也可能在现实里失败¶

正因为如此，很多强化学习研究和实验都会先放在 simulation 里做。simulation 快、便宜、风险低。

但当一个在 simulation 里学得不错的 policy 被搬到现实，就会出现下面这些问题。

• 传感器噪声不同
• 摩擦、延迟、光照、障碍布置不同
• 现实数据更不完整，也更不可预测
• 模拟器忽略的因素，在真实环境里可能很重要

这种差异通常就叫 sim-to-real gap。

flowchart TB
  A["仿真训练<br/>便宜且可重复"]
  B["策略在模拟器里看起来很好"]
  C["真实环境<br/>噪声、延迟、不匹配"]
  D["性能下降或出现不安全行为"]

  A --> B --> C --> D

这个图很简单，但很重要。强化学习在现实里变难，不是因为算法太弱，而是因为训练它的世界和要部署它的世界可能不是同一个世界。

为什么 sim-to-real gap 会被反复提起¶

在机器人强化学习里，sim-to-real 总被反复提起，是因为真实机器人上收集数据很慢、很贵、也很危险。所以 simulation 训练看起来几乎不可避免，但那也意味着 simulator bias 会更大。

最核心的点是下面这些。

• simulation 让学习变得可能
• 但 simulation 不是 reality 的复制品
• 所以绝不能把 simulation 成功 = reality 成功 直接读过去

因此，在强化学习里，要一起读的不只是性能分数，还包括这个 policy 是在哪里训练的，又要部署到哪里

sim-to-real gap 也不能只被读成成绩差一点。更实际的读法应该是下面这样。

所以，即使在读 simulation 表现时，最好也不要只记平均分，还要同时写下现实里哪种差异会最先把这个 policy 打碎？

应用前的检查问题¶

把强化学习接到真实问题前，先应该问下面这些问题。

1. 我们给的 reward，是否足够反映真实目标？
2. policy 会不会只把数字抬高，却绕过真实意图？
3. exploration 失败的成本，现实里是否承受得起？
4. 危险尝试能不能先用 simulation 或 offline data 替代？
5. simulation 和 reality 的差异要怎么检查？
6. 一旦性能下降，有没有停止或回滚机制？

这些问题应该先于具体算法名字出现。现实应用里，是 Q-learning 还是 actor-critic 并没有 是否可实验、是否安全、目标是否定义得好 来得更重要。

如果按更接近实际操作的顺序重排，可以写成下面这样。

到这里之后，与其把所有检查问题一次背下来，不如再把它们束成四个分支。

和监督学习比，哪里更难¶

监督学习(supervised learning)也有数据偏差和指标设计问题。但强化学习还多了一层困难：行动会改变环境

所以，强化学习处理的是会行动的 policy，不只是会预测的模型，这会把部署风险再抬高一层。

案例与例子¶

案例 1. 推荐 policy 把点击抬高了，却让用户满意度下降¶

假设内容推荐团队把强化学习 policy 的 reward 只设成点击数增加。policy 可能很快通过更多刺激性标题和短停留内容把点击冲高。但如果真实目标是长期满意和回访，那投诉上升、服务信任下降，反而会让真实目标受损。这个案例显示的是：在强化学习里，reward 数字并不直接等于人的意图，部署前必须检查代理指标和真实目标之间的差距。

flowchart TD
  A["奖励 = 只有点击"]
  B["策略推送更刺激的内容"]
  C["点击指标上升"]
  D["投诉和流失也一起上升"]
  E["怀疑代理奖励与真实目标不一致"]
  F["用更长期的信号重新定义奖励"]
  G["在线下或小流量中测试"]

  A --> B --> C
  C --> D --> E --> F --> G

这个场景可以立刻被记录成这样：如果 policy 提高了点击，但投诉率和流失率也一起上升，那就说明 reward 设计错误地代替了真实目标。下一步应该把更长期的满意指标重新绑回 reward，并先把危险的 exploration 缩到 offline evaluation 或限制实验段里。 这一节的核心，不是停在reward 数字上去了，而是继续问哪些副作用也跟着上去了、这些副作用该在部署前哪里被压住。

因为这一节是在讲应用注意点，所以把实际检查 memo 结构和解释句一起留下会尤其重要。即使看起来都是 reward 上升，副作用模式和允许失败幅度也可能不同，所以最好把与分数并列留下的风险信号分开写。

如果从部署 memo 视角重写这个案例，第一步不该是数字涨了，直接扩大，而应该是哪些风险信号也一起涨了，这些风险更像 reward 设计问题、exploration 宽度问题，还是环境错配问题？

什么时候应该停下来重新检查¶

在强化学习应用这一节里，比起性能是不是涨了一点，更重要的是先决定出现什么信号时必须停下来重新看

读这个表时，重要的是不要只写出问题了。最好还能一起写：它更像reward 设计问题、exploration 许可幅度问题、sim-to-real 验证不足，还是运营防护不足，这样下一步修正方向才会更清楚。

练习与例子¶

这个例子集中在用小输入和输出直接确认：如果 reward 数字定义错了，学习器就可能更喜欢错误的行动

问题情境：

• 如果把 reward function 只放在一个 proxy metric 上，学习器就可能更偏好偏离真实目标的行为

输入(input)：

• action A：点击高，但用户投诉很多
• action B：点击略低，但满意度和留存更好

期望输出(output)：

• proxy reward：只看 clicks 的分数
• true objective view：把 complaints cost 也算进去后的分数

要确认的概念：

• 如果 proxy reward 和 true objective 不一样，学习方向就可能偏掉
• 即使数字看起来很高，只要打分内容不同，对好行动的判断就会完全变样
• reward 设计不是小实现细节，而是直接连着系统目标定义

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 这个例子比较只看 clicks 的 proxy reward 和加入投诉成本的真实目标如何改变动作偏好。
actions = [
    {"name": "A", "clicks": 120, "complaints": 30},
    {"name": "B", "clicks": 100, "complaints": 5},
]

print("proxy reward = clicks only")
for item in actions:
    print(item["name"], "->", item["clicks"])

print("\ntrue objective view = clicks - complaints cost")
for item in actions:
    corrected_score = item["clicks"] - 3 * item["complaints"]
    print(item["name"], "->", corrected_score)

一个执行结果例子可以读成下面这样。

1
2
3
4
5
6
7

proxy reward = clicks only
A -> 120
B -> 100

true objective view = clicks - complaints cost
A -> 30
B -> 85

如果只看 clicks，A 看起来更好。但把 complaints cost 放进去后，B 会更好。

也就是说，学习器喜欢的行动，会因为 reward function 是用什么搭起来的而完全改变。

改一个值试试：如果 complaints cost 的权重调低，解释会怎么晃动？¶

这次不按 3倍 反映 complaints cost，而只按 1倍。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 这个例子降低投诉成本权重，观察 reward design 的解释会如何摇动。
actions = [
    {"name": "A", "clicks": 120, "complaints": 30},
    {"name": "B", "clicks": 100, "complaints": 5},
]

print("adjusted objective = clicks - complaints cost")
for item in actions:
    corrected_score = item["clicks"] - 1 * item["complaints"]
    print(item["name"], "->", corrected_score)

1
2
3

adjusted objective = clicks - complaints cost
A -> 90
B -> 95

一旦把 complaints cost 权重调低，两种行动的分差就缩小了很多。如果再继续调低，A 甚至可能重新看起来更好。这个比较会直接展示：reward 设计不是小实现问题，而是在决定什么被视作损失、什么被视作目标。

例子 2. 为什么 exploration 既是性能改进机会，也是现实成本¶

这次用数字确认：尝试新的行为可能帮你找到更好的 policy，但如果一次失败的成本太大，现实里就无法轻易放开 exploration

问题情境：

• 多试一些 policy 候选，长期上也许会发现更好选择
• 但在失败成本很大的环境里，没法不断增加尝试次数

输入(input)：

• safe_policy：平均 reward 较低，但几乎没有失败成本
• explore_policy：成功时 reward 更大，但一次失败的损失也很大

期望输出(output)：

• 只看 expected reward
• 把 failure cost 也算进去后的净值

要确认的概念：

• exploration 不是一句多学一点就结束，failure cost 必须一起算
• 即使平均 reward 结构看起来更好，一旦加上 failure loss，现实解释也可能反转
• 在强化学习应用里，failure tolerance 会先于平均 reward

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 这个例子比较探索策略的 expected reward 和扣除失败成本后的 net value。
policies = [
    {
        "name": "safe_policy",
        "success_reward": 8,
        "success_prob": 0.8,
        "failure_cost": 1,
    },
    {
        "name": "explore_policy",
        "success_reward": 14,
        "success_prob": 0.55,
        "failure_cost": 8,
    },
]

for item in policies:
    expected_reward = item["success_reward"] * item["success_prob"]
    net_value = expected_reward - item["failure_cost"] * (1 - item["success_prob"])
    print(item["name"])
    print("  expected reward only =", round(expected_reward, 2))
    print("  net value after failure cost =", round(net_value, 2))

1
2
3
4
5
6

safe_policy
  expected reward only = 6.4
  net value after failure cost = 6.2
explore_policy
  expected reward only = 7.7
  net value after failure cost = 4.1

如果只看 reward，explore_policy 会显得更好。但把 failure cost 算进来后，safe_policy 反而更好。游戏里这种损失也许只是重来一次，可在机器人、医疗、实服务里，一次失败就可能变成设备损坏、用户流失或法律问题。

所以，现实里的 exploration 问的不只是平均 reward 更高吗？，还包括一次失败真的承受得起吗？

例子 3. 为什么 simulation 分数很高，也仍然需要单独的现实检查¶

最后，用一个很简单的数字对比来确认：一个在 simulator 里看起来很强的 policy，会多容易在现实延迟和噪声下开始摇晃。

问题情境：

• 一个 policy 在 simulation 里成功率很高，看起来已经可以部署
• 但现实里的 sensor noise 和 control delay 可能把失败率拉高

输入(input)：

• same policy
• simulation success rate
• real-world success rate

期望输出(output)：

• simulation score
• mismatch 之后的 real-world score

要确认的概念：

• sim-to-real gap 会直接表现成同一个 policy 的成功率差异
• 单凭 simulator 分数高，不能直接证明可以上现实
• 部署前还需要限制验证区间和停止标准

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 这个例子通过 simulation 分数和 real-world 分数直接检查 sim-to-real gap。
deploy_checks = [
    {"name": "policy_A", "simulation_success_rate": 0.93, "real_world_success_rate": 0.71},
    {"name": "policy_B", "simulation_success_rate": 0.88, "real_world_success_rate": 0.84},
]

for item in deploy_checks:
    gap = item["simulation_success_rate"] - item["real_world_success_rate"]
    print(item["name"])
    print("  simulation score =", item["simulation_success_rate"])
    print("  real-world score =", item["real_world_success_rate"])
    print("  sim-to-real gap =", round(gap, 2))

1
2
3
4
5
6
7
8

policy_A
  simulation score = 0.93
  real-world score = 0.71
  sim-to-real gap = 0.22
policy_B
  simulation score = 0.88
  real-world score = 0.84
  sim-to-real gap = 0.04

如果只看 simulation 数字，policy_A 似乎更强。但到了现实，它掉得更多。反过来，policy_B 的 simulator 分数虽然稍低，和现实之间的差距却小得多，所以可能更适合作为部署候选。

这个例子的核心，就是最高的 simulation 分数和最值得信任的现实候选未必是同一个东西。

这些练习怎样回收到强化学习的应用判断¶

强化学习的应用判断，不是为了增加算法名字，而是为了把到底在优化什么、到底能试到什么程度、训练世界和部署世界是不是同一个世界一起读。上面这些例子，分别通过 reward 权重变化、failure cost 反映、simulation 与 reality 分数差，展示了应用判断会怎样改变。如果做完练习之后目标还是不够明显，通常不是因为公式不够，而是因为数字一变，解释标准也跟着变这句连接还不够强。

这一节的核心，不是增加应用风险名词，而是固定：reward 与真实目标之间的缝隙，到底要在哪里检查。

检查清单¶

• 能理解强化学习会最大化 reward，但 reward 不一定能完美代替真实目标吗？
• 能把 reward hacking 解释成模型把 reward 数字优化得很好，却错过人类意图的现象吗？
• 是否知道 exploration 在现实里会制造成本和安全问题，所以不能像游戏里那样随便试？
• 是否理解 simulation 让强化学习成为可能，但它和 reality 不同，因此会有 sim-to-real gap？
• 能说明真实应用里，目标定义、安全 exploration、部署环境差异验证要先于算法名字吗？
• 能说明为什么只看 reward 上升就推进部署会有风险吗？
• 能说出 sim-to-real gap 不只是性能问题，也可能直接变成安全问题吗？
• 理解为什么 exploration 许可幅度与停止装置要先于算法本身来决定吗？

来源与参考资料¶

• Richard S. Sutton and Andrew G. Barto, Reinforcement Learning: An Introduction, 2nd ed., The MIT Press, 2018, 确认日期：2026-06-28. https://mitpress.mit.edu/9780262039246/reinforcement-learning/
• Dario Amodei, Chris Olah, Jacob Steinhardt, Paul Christiano, John Schulman, Dan Mané, Concrete Problems in AI Safety, arXiv, 2016, 确认日期：2026-06-28. https://arxiv.org/abs/1606.06565
• Wenshuai Zhao, Jorge Peña Queralta, Tomi Westerlund, Sim-to-Real Transfer in Deep Reinforcement Learning for Robotics: a Survey, arXiv, 2020, 确认日期：2026-06-28. https://arxiv.org/abs/2009.13303
• Dario Amodei, Chris Olah, Jacob Steinhardt, Paul Christiano, John Schulman, Dan Mané, Concrete Problems in AI Safety, arXiv, 2016, 确认日期：2026-06-28. https://arxiv.org/abs/1606.06565
• Wenshuai Zhao, Jorge Peña Queralta, Tomi Westerlund, Sim-to-Real Transfer in Deep Reinforcement Learning for Robotics: a Survey, arXiv, 2020, 确认日期：2026-06-28. https://arxiv.org/abs/2009.13303