外观
RL 设计原则
一句话定位：这一页把 RL 项目反复踩坑的教训沉淀成十条设计原则——每条原则配一个真实反例和一条可执行的做法。它解决"为什么我的 RL 项目总在加班返工"的根因，适合项目负责人、独立开发者和任何要真正交付 RL 系统的人。读完你会有两张纸：一张贴在工位前的十条原则，一张项目自查清单。
先说数据。为什么 RL 项目失败率显著高于普通 ML 项目？因为 RL 的失败模式更多、更隐蔽、更晚暴露：
- 失败更隐蔽：训练不涨时，你分不清是算法问题、超参问题、奖励问题还是环境 bug（常见陷阱 专门讲这个）。
- 失败更晚：监督学习半天就能判断数据有没有问题；RL 往往要跑一两天后才发现"学的是错的信号"。
- 失败更贵：试错要环境，环境越真实越贵——机器人、交易、真实用户，试错成本都极高。
这十条原则就是从这些失败里长出来的。它们不是灵感，是防止重复交学费的备忘录。
一、为什么 RL 项目容易失败：三张"失败账单"
| 失败类型 | 典型占比（非严格统计） | 代表症状 | 对应原则 |
|---|---|---|---|
| 问题建模错误 | 约 30% | "这不是 RL 问题"，或奖励写歪 | 原则一、二 |
| 工程问题 | 约 30% | 环境 bug、复现不了、日志丢失 | 原则二、五、七 |
| 算法/调参问题 | 约 25% | 学不动、学崩、方差大 | 原则三、四、六 |
| 业务/落地问题 | 约 15% | 做出来了没人用、指标和业务对不上 | 原则八、九、十 |
注意：只有四分之一的问题出在"算法"上。但绝大多数团队的资源都砸在算法上——这就是原则一存在的理由。
二、十条原则总览
| # | 原则 | 一句话 | 反例 |
|---|---|---|---|
| 1 | 奖励先于算法 | 奖励是产品需求，先写奖励文档再选算法 | 奖励写歪，PPO 再强也白费 |
| 2 | 环境先行 | 环境即产品，环境质量决定一切 | 环境 bug 让所有人白干两周 |
| 3 | 简单优先 | 从最简单可行的策略开始，逐步升级 | 一上来就 SAC，三天没动静 |
| 4 | 基线先行 | 没有基线，无从判断"变好" | 没跑随机/启发式，误判"算法有效" |
| 5 | 可复现实验 | 复现不了的实验等于没做 | 换机器后结果翻天覆地 |
| 6 | 安全护栏 | 上线前想好失败会怎样 | 策略乱动，业务线上翻车 |
| 7 | 样本效率意识 | 每一步交互都有成本，先算预算 | 训练预算只有 1 万步，却用 on-policy |
| 8 | 小步迭代 | 一次只改一件事，一天一转 | 同时改 5 个变量，2 小时后不知归因 |
| 9 | 文档化失败 | 把每次失败写成教训库 | 同一坑被三拨人各踩一次 |
| 10 | 与业务对齐 | 指标要能翻译成业务语言 | 算法分数高，业务指标没动 |
三、原则一：奖励设计先于算法选择
反例：某团队为"让 NPC 不卡墙"设计奖励——"离目标每近一步 +1，撞墙 −10"。结果智能体学会了贴着墙走（每步 +1 稳赚，撞墙概率低）。算法越优化，行为越"聪明地坏"。
奖励是产品需求唯一机器可读的表达。你选什么算法只决定"学得动学不动"，奖励决定"学会之后是什么样"。
可执行的做法
- 动手前写一页奖励设计文档：每个奖励项的来源、取值、为什么这样取、可能被钻的空子。
- 用"奖励量级"做体检：先跑随机策略，看平均单步奖励是多少——如果奖励量级在 1e-4，浮点精度都在干扰学习；先归一化。
- 上线前做"奖励审计"：列出策略可能找到的最省力的刷分路径，逐个堵上。
与相关页面的衔接
奖励设计的完整方法论（势能塑形、稀疏奖励对策、Reward Hacking 案例集、逆强化学习）见奖励工程。RLHF 场景里"奖励"变成人类偏好模型，同样遵守本原则——奖励模型过优化就是对齐翻车，见LLM 对齐：RLHF 实战。
一句话测试
给非技术人员讲一遍你的奖励函数。如果他们能指出"智能体可以怎么偷懒刷分"，你的奖励还有漏洞。
四、原则二：环境先行（环境即产品）
反例：某调度项目用自建仿真训练，训练了四周，智能体表现完美。上线时发现仿真的"机器故障概率"是硬编码 5%，真实产线是 15% 且随时间漂移——策略在真实分布上崩溃。
RL 系统解剖里那句"环境即产品"不是口号：环境决定了你的数据分布，数据分布决定策略能学成什么样。环境错了，后面全是无用功。
可执行的做法
- 环境验收单（在从零构建一个 RL 项目里有完整清单）：冒烟测试、随机策略跑 1000 步、奖励有界、同一 seed 可复现、启发式可达成。
- 先验证"环境可信"再写算法：用最简单策略跑通环境，确认学习信号存在，再投入算法资源。
- 环境与训练解耦：环境独立成服务/模块，换实现（Python→C++→分布式）不碰训练代码。
- 域随机化意识：仿真与真实分布有 gap，训练时就随机化物理参数（机器人场景见机器人控制与 Sim2Real）。
环境也是"需求规格"
把环境当成产品需求文档来写：状态有哪些、动作边界、奖励公式、终止条件、随机性来源。这份文档同时是测试用例、评审对象和交接材料——它比算法代码更值得反复评审。
五、原则三：从简单算法开始（随机 → 启发式 → 简单 RL → 复杂 RL）
反例：某团队项目一立项就上 SAC，配了 8 块 GPU 并行调参。两周后回报纹丝不动。改用最朴素的 ε-greedy 线性策略，一天就追平了启发式基线——原来问题根本不需要 SAC 的复杂度。
复杂度是负资产：越复杂的算法，越难排查、越难复现、越难解释。先跑最简单的，直到"简单"被证明不够。
复杂度阶梯
text
随机策略 ──→ 启发式/规则 ──→ 简单 RL（DQN/REINFORCE）
│ │ │
验证环境可交互 验证问题可解 验证 RL 信号通路
│
复杂 RL（PPO/SAC）+ 调优
│
只在简单方案不够时升级| 阶梯 | 用途 | 什么时候往下走 |
|---|---|---|
| 随机 | 环境冒烟、奖励采集 | 立刻 |
| 启发式 | 问题可解性、奖励合理性 | 有分数后 |
| 简单 RL | RL 信号通路、训练管线正确 | 管线验证后 |
| 复杂 RL | 追求上限 | 简单方案证明不够 |
六、原则四：基线先行
反例：团队调 PPO 一个多月，最终回报比随机策略高 3 倍，全员庆祝。补跑启发式基线后发现：一条 50 行的贪心规则就能达到随机策略的 4.5 倍。三个月的"算法工作"毫无增量。
"基线先行"是最便宜、最能救命的原则：它把"我的算法好不好"变成可回答的问题。
可执行的做法
- 第一周内就产出一条随机基线和一条启发式基线的完整学习曲线。
- 所有后续实验都在这两条线上叠加展示（
plt.axhline画两条参考线就行）。 - 评估协议与基线一致（同样的 seed、预算、指标）——否则基线没意义。协议细节见从零搭一套 RL 评估。
基线不是走形式
如果"基线先行"只做了一次然后忘了更新，就等于没做。基线的价值在于它是持续参照物：每次算法改动都要问"这次比基线强在哪、强多少"。基线线画在每张图上，直到项目结束。
七、原则五：可复现实验
反例：A 工程师用 PyTorch 1.13 跑出 PPO 480 分，B 工程师在新环境 PyTorch 2.0 复现同一代码，只有 390 分。两人吵了三天，最后发现是
numpy随机数状态没有在环境里播种——同一 seed 在两人机器上走了不同的环境序列。
RL 的可复现问题比监督学习严重：同样的 seed、同样的代码，换 GPU、换版本、换并行方式结果都不同。
可执行的做法
- 三层播种：全局（python/numpy/torch）+ 环境（
reset(seed=...)）+ 算法（框架 seed 参数）。 - 配置即代码：实验配置进 yaml/Hydra，命令行可覆盖，每次实验自动存档。
- 记录一切：git commit、依赖版本、机器信息进实验目录。
- 多 seed 是复现的一部分：能复现的是"性能分布"，不是"一条曲线"。
完整工程细节见从零构建一个 RL 项目的可复现性加固一节；「复现论文失败」的诊断清单见常见陷阱。
八、原则六：安全护栏
反例：某推荐排序策略上线前只在离线评测好，没有 shadow mode。上线第一天，策略对一小撮用户给出极端动作（不停推荐同一商品），CTR 暴跌，回滚花了 3 小时。
RL 策略比规则系统更可能"聪明地越界"。护栏不是可选项。
可执行的做法
| 护栏 | 做法 | 时机 |
|---|---|---|
| 动作限幅 | 动作范围硬限制，越界回退安全值 | 设计期 |
| 影子模式 | 新策略只记录不执行，对比一周 | 上线前 |
| 渐变放量 | 1% → 5% → 50% 分阶段放量 | 上线期 |
| 兜底规则 | 业务侧保留规则/人工接管路径 | 全程 |
| 监控告警 | 动作分布、观测分布、业务指标的漂移检测 | 上线后 |
RL 场景的安全设计可以很硬核（约束 RL、安全集），但工程上最便宜的护栏永远是"别让它直接碰真实系统"。
九、原则七：样本效率意识
反例：某团队用 on-policy 算法（每次交互的样本只用一次）在只能采集 5 万条样本的业务环境上训练。学到第 3 万步才明白：这个预算连一个像样的 on-policy 更新周期都不够，应该用 off-policy（SAC）或离线数据。
RL 的"数据"是交互出来的，每一步都有真实成本。先算预算，再选算法。
可执行的做法
- 立项时回答三个数：每小时能采多少样本、总预算多少步、每一步的货币成本。
- 按预算选算法族（Actor-Critic 家族的选型表）：预算紧 → off-policy（SAC/TD3）；预算足 → on-policy（PPO）更稳。
- 样本效率与最终性能两个维度都要报告（见评估实践）。
- 有历史数据时先考虑离线 RL——能白嫖的样本先白嫖。
十、原则八：小步迭代
反例：工程师周一改了奖励函数 + 换了网络 + 调了 clip，周三看到结果变差，无法判断是哪个改动导致——只好回滚全部，一周白费。
RL 实验的变量太多，一次只改一个是最省时间的做法（调参实践的纪律核心）。
可执行的做法
- 每次实验改动列表不超过 1 个变量（批量搜索除外，那是有记录的并行）。
- 一天一转：每天至少完成"改代码 → 跑实验 → 看曲线 → 写结论"一个循环。
- 每轮实验留一行文字结论，哪怕只是"lr 1e-3 → 崩了"。
小步迭代的反直觉之处
看起来"每天只改一个变量"很慢，实际上它是 RL 项目里最快的推进方式——因为 RL 的归因成本极高，变量一多，每个实验的信息量趋近于零。
十一、原则九：文档化失败
反例：团队在项目 A 踩了"奖励数值溢出导致 NaN"的坑，花了 3 天定位。半年后项目 B 的同事独立地又踩了一遍。
失败是可以复用的知识，而且是最贵的一种知识。不文档化，等于每次失败都付全价学费。
可执行的做法
- 维护一份
KNOWN_FAILURES.md：症状 → 根因 → 检测方法 → 修法，一条一行。 - 每次排掉一个超过一天的 bug，就补一条。
- 把它写进 README 或 wiki，新成员入职先读。
这也正是常见陷阱与反模式整页在做的事——把它当团队知识的起点，往里加自己的条目。
十二、原则十：与业务对齐
反例：某库存补货项目，RL 团队把"模拟器里的累计利润"当指标，优化到 +18%。上线后仓库经理说：预测需求波动时，策略下单量忽高忽低，工人排班崩溃，真实利润 +0%。指标没翻译成业务约束（下单平稳性）。
RL 指标的胜利 ≠ 业务胜利。两者之间隔着约束、风险和解释成本。
可执行的做法
- 指标翻译表：把每个 RL 指标写清楚对应什么业务动作（回报 → 利润、成功率 → 履约率、方差 → 排班波动）。
- 约束先行：把业务约束（平稳性、库存上限、伦理边界）提前写进奖励或动作空间，别等上线后被业务方发现。
- 解释预算：业务方会问"它为什么这么做"。RL 策略解释性差，提前准备好"指标归因"或"行为审计"的答案。
十三、项目自查清单
把下面这张清单打印出来，贴在工位前。每个阶段结束时过一遍：
立项时
- [ ] 决策清单确认这是 RL 问题（见从零构建一个 RL 项目第 0 步）
- [ ] 样本预算三问（步数/成本/小时产量）已回答
- [ ] 奖励设计文档已写、已做"刷分审计"
- [ ] 业务指标翻译表已定
开发时
- [ ] 环境验收单全部通过，启发式基线有分数
- [ ] 训练管线在 CartPole 类基准上验证过
- [ ] 基线曲线画进每张结果图
- [ ] 三层播种 + 配置存档就位
上线前
- [ ] 多 seed 评估 + IQR 报告完成
- [ ] 安全护栏（限幅/影子/兜底/监控）就位
- [ ] 失败文档已更新到最新一条
延伸阅读
- 奖励工程 —— 原则一的完整方法论：塑形、稀疏奖励、Reward Hacking、逆强化学习
- 常见陷阱与反模式 —— 本页十条原则对应的翻车点与检测手段
- LLM 对齐：RLHF 实战 —— 奖励设计原则在大模型对齐里的极端形态（奖励过度优化）
- RL 系统解剖 —— 六层系统架构，"环境即产品"的理论出处
- 从零构建一个 RL 项目 —— 本页原则落地的八步流水线
参考资料
- Sutton, R. S. & Barto, A. G. (2018). Reinforcement Learning: An Introduction, 2nd ed. MIT Press.（奖励假设与试错学习的理论根基，免费版见 incompleteideas.net）
- Amodei, D. et al. (2016). Concrete Problems in AI Safety. arXiv:1606.06565（安全护栏问题的经典清单：错误奖励、探索风险等）
- Irpan, A. (2018). Deep Reinforcement Learning Doesn't Work Yet. alexirpan.com/2018/02/14/rl-hard.html
- Henderson, P. et al. (2018). Deep Reinforcement Learning that Matters. AAAI 2018. arXiv:1709.06560
- Tobin, J. et al. (2017). Domain Randomization for Transferring Deep Neural Networks from Simulation to the Real World. arXiv:1703.06907（环境不确定性的应对，原则二延伸）
- OpenAI (2017). Learning Dexterous In-Hand Manipulation. arXiv:1808.00177（环境先行 + 域随机化的工业级案例）