强化学习环境将工具、任务和验证器结合在一起，让智能体通过反复尝试来训练。

密室逃脱经济学

强化学习（RL）环境入门

强化学习（RL）环境是今年 ICML 的核心焦点之一。这本身并不意外，但我确实没想到它的普及程度如此之高。

从那之后，很多人向我询问 RL 环境，于是我整理了这篇入门指南。

RL 环境的高层类比

想象一下你被锁在一个房间里。桌上有一个带挂锁的盒子，椅子下面用胶带固定着一支紫外线手电筒，墙上贴着一首诗、其中三个词被划了线，门边有一个密码键盘。没有说明书，你只能开始到处摸索——用手电筒照一照、重读那首诗、输入各种密码组合——直到密码键盘闪出绿灯，你跌跌撞撞地走进走廊，还剩一分钟。

事实证明，密室逃脱是理解强化学习环境的完美类比。

密室就是你被困其中的世界，它有物体、规则和反馈（你输入一个密码，锁要么开、要么不开）。在强化学习中，这被称为环境。

手电筒、盒子、密码键盘就是你被允许使用的工具。你只能做房间/环境和工具允许你做的事情。

逃出去的目标就是任务。

然后你会在密室里摸索一段时间，尝试工具的各种组合组合，希望最终能逃出去。

一小时后，游戏结束：你要么逃出去了，要么没有。这被称为验证器，而密室逃脱干净利落的二元结果使验证变得非常简单。

现在想象一下，我们不是派一个人进去，而是派一个 AI 智能体。我们强迫它反复穿越这个密室一万次。它在每次尝试中都会尝试不同的东西，绝大多数情况下都会失败。但是，在少数几次尝试中，AI 智能体成功逃脱了。于是我们稍微调整模型，让它更像成功逃脱时的表现。然后我们再把它送进密室，运行数千次，给予反馈，再运行更多次。想象一下累计运行数百万次——最终，你会得到一台非常擅长这个特定密室的机器。

这就是 RL 环境的全部理念。你不是显式地教机器答案，而是让它通过经验来学习。你建一个房间，给它工具使用，告诉它要逃出去，定义什么是“逃脱成功“，然后让它不断地撞门，直到学会为止。

然后你建下一个房间，有不同的、更难的任务，接着重复……

再深入一层

为什么大家突然对 RL 环境如此兴奋？

到了现在，我们基本上已经把互联网数据用完了。预训练——即模型阅读人类几乎写过的一切内容的阶段——效果惊人，但当你已经把所有现有数据都喂进去之后该怎么办？研究人员对 RL 焯境感到兴奋，因为它们可以按需制造全新的训练信号。智能体每运行一次房间，就会产生全新的经验。

第二个原因是成本。预训练之后改进模型的初始方法都依赖直接的人类反馈。在监督微调（SFT）中，必须有人提供理想答案。在基于人类反馈的强化学习（RLHF）中，必须有人明确对模型的各个回答进行排序。这两种方法既慢又贵，而且把模型性能的上限锁定在人类水平。RL 环境的美妙之处在于，一旦正确构建完成，你就可以用大量算力来轰炸它，生成无穷无尽的数据。

随着这种转变，后训练的经济学发生了根本性的变化。以前，我们花 100 美元请专家解决一个任务。现在，这 100 美元花在让专家构建一个任务和验证器上，从而让模型从大量尝试中学习。

需要澄清的是，SFT 和 RLHF 仍然是标准流程的一部分，但 RL 环境是在它们之上叠加的。

最后，AI 正朝着更加任务导向的方向发展。自回归的 token 预测（即预测下一个词）给了我们能对话的模型，但我们希望模型做得更多：订机票、办登机、报税、发布 bug 修复，等等。这种行动导向是一项不同的技能，很难通过阅读来学会。你需要通过尝试、失败，并获得关于自己是否真正完成了任务的有用信号来学习。RL 环境是我们目前已知的、大规模教授“做事“的最佳方式。

那么，RL 环境到底是什么？

环境就是这个世界——工具、规则和反馈。动作空间是智能体在这个世界中被允许做的全部事情的集合。一个只有数字密码键盘的房间，其动作空间很小；而一个拥有可以浏览网页、发送邮件、编辑文件和运行代码的计算机的房间，则代表着巨大的动作空间。大致来说，动作空间越大、越逼真（即高保真环境），环境的能力就越强，构建成本也就越高。

在环境之中，智能体会被分配一个任务。在密室逃脱中，任务简单而单一：逃出去。相比之下，前沿实验室实际上会付费购买包含许多复杂任务的环境——一个“税务“环境可能包含“提交这份报税表“、“找出这份申报中的错误“和“回复这封 IRS 通知”。这些环境和任务甚至可能共享同一套工具供智能体使用。

验证器是给你的尝试打分的方式。与密室逃脱的类比不同，验证器的奖励不一定是二元的。一个直观的理解方式是：通过提供部分分数，你可以给模型提供更细粒度的反馈。

根据任务的不同，验证器有两种截然不同的类型。当答案可以被程序化检查时（并且假设你设置了正确的检查），验证就是平凡的。代码通过了测试吗？数字匹配了吗？密码键盘变绿了吗？许多科学和数学领域（例如编程）通常是可以验证的。对于这些领域，检查只是一个简短的脚本，运行十亿次也几乎零成本。可验证领域是整个领域中最干净、最可扩展的部分。

但最有价值的知识工作往往没有干净的检查方式。这篇文章写得好吗？这份法律摘要忠于原文吗？没有 Python 脚本能够判断这里说的“好“是什么。相反，你需要写一份评分标准——一份定义“好“的评分清单（例如，这篇文章涵盖了三个要点，没有事实错误，结构清晰）——然后交给另一个模型按照标准来打分。在这种情况下，好的验证器更加柔软、噪声更大、也更难做对：人类判断是稀缺的输入。

好了，你有了一个房间和一个验证器。那要怎么让模型变得更好呢？

在密室逃脱的小故事中，我一笔带过了这个步骤，说“我们调整（模型），让它更像成功逃脱时的表现。“让我们再深入一些。

每次智能体运行房间，它会产生一个 rollout（也称为轨迹），即该次尝试的完整记录。它按顺序记录了运行过程中所做的每一个动作，再加上最后的验证器评分。运行房间一万次，就有一万个 rollout。同样，其中大多数是失败的，只有极少数是成功的。

接下来就是真正的强化学习。RL 算法（通常是 PPO 或 GRPO）比较多组尝试，然后微调模型的参数，使得优于平均水平的尝试中出现的选择更有可能被选中，而更差的尝试中的选择则不太可能被选中。保持合适的任务难度是一个棘手的平衡——如果所有尝试要么全部成功、要么全部失败，这些算法就无法提取任何有用的信号来改进模型。在数百万个 rollout 上重复这个过程，模型就会一点一点地朝着验证器所奖励的方向漂移。

基准测试与 RL 环境

每次发布新模型时，研究人员都会附上模型在一系列基准测试上的表现——SWE-Bench、Humanity’s Last Exam、Terminal-Bench 等都是经典例子。基准测试的目的是评估模型在研究人员关心的特定领域中的能力。一个好的基准测试还应该在不同模型之间提供足够的表现区分度。

发表好的基准测试是 RL 环境公司向其前沿实验室客户展示实力的有力方式。从根本上说，基准测试的任务与 RL 环境在功能上是同一件事，都是将容器、任务和验证器打包在一起。通过设计一个好的基准测试，RL 环境公司展示了构建良好环境所需的技术能力和品味。可以把它当作一种作品集来理解。

请注意，实验室购买的 RL 环境与基准测试的环境并不相同。创业公司实际出售的环境看起来像基准测试环境，但并不是同一个。例如，一个 RL 环境可能包含数千个任务，而基准测试可能只有数百个。模型在后训练期间提高了底层能力，基准测试的分数也随之作为副产品而上升。

哇，这听起来太棒了！那会出什么问题呢？

构建高保真环境是一场对抗不一致性的战争。想象一下让一个模型查询天气，但你不把它固定到某个日期；那么每次运行时“正确“答案都会不同。房间越逼真，问题就越严重，因为真实世界是有状态的：一个任务中的某个动作会改变下一个任务开始时的世界状态（例如，数据库中的某一行被修改了），所以早期的一个错误可能会悄无声息地污染下游的一切。

此外，你往往一分钱一分货：一个一次性的 UI 模型可能花费约 2 万美元，而一个忠实的 Slack 复制品则接近 30 万美元。如果你在逼真度上偷工减料，可能会得到一个充满 bug 的、凭感觉编码的环境，模型根本学不到任何东西。追查每一个漂移的来源，同时让世界保持足够真实以至于值得学习，是一项艰辛而乏味的工作。

获得一个合适的困难任务组合本身就非常困难。很容易用任务数量来衡量一个环境的好坏，但一千个几乎相同的任务教不了模型任何新东西。价值在于范围和难度。一个好的环境应该搭配彼此真正有差异、且在可行范围内真正困难的任务。这里的想法是，如果你在环境内有良好的任务分布，模型就能够泛化到现实世界中的新任务。

创建好的验证器直接撞上了这个领域中最有趣的失败模式：模型开始作弊，进行奖励黑客（reward hacking）。这并非出于恶意，而是因为模型是一个盲目的优化者，它会做任何能从验证器那里拿到分数的事情。

如果你纯粹用“门是否打开“来奖励密室逃脱，模型可能会选择暴力破解门而不是解谜。在真实的编程环境中，模型通过悄悄删除测试来让测试通过。这项工作的一半功夫在于写出足够好的验证器，使得唯一得分的方式就是真正完成任务。

值得展开讲讲验证器可能的错误类型：假阳性和假阴性。假阳性会奖励错误的解决方案（教模型坏行为），而假阴性会拒绝正确的解决方案（抑制正确的创造性）。如果强大的模型一直碰到同一个评估指标的天花板，验证器可能产生了太多的假阴性。如果能力非常不同的模型取得了相似的高分，那么构建的任务可能太简单，或者验证器可能产生了太多的假阳性。还有其他一些启发式方法可以评估验证器的行为，但这些是最常见的几种。

顺便一提，我最喜欢的“奖励黑客“合集实际上是 Richard Benson 的书《F in Exams》，它收录了一系列令人捧腹的考试答案。

感谢 Michael Bao、Yash Patel、Ibragim Badertdinov、Matthew Shih、Yifan Wang 提供反馈。文中的任何错误均由我一人承担。

延伸阅读

• RL 环境创业公司列表：Pavlov’s List、RL List

• Hugging Face 的 RL 环境指南：关于构建和扩展 RL 环境的工具与框架的详细技术指南

• Harbor：定义 RL 环境、任务和验证器的流行框架

• Mechanize 团队的环境设计：一系列关于如何做好 RL 环境设计的文章

• Daniel Rupawalla 关于 RL 环境的一系列 X 帖子：验证器、任务、任务生成、环境 第 1 部分、环境 第 2 部分

最初发表于我的 Substack。