作者简介：Aviv’s Substack：Shie Mannor is with Technion and Nvidia Research; Aviv Tamar is with Technion; this writeup represents our own opinions.
强化学习 (RL) 已展现出巨大潜力，但目前充满了过度炒作和白日梦。我们指出了当前研究的一些困难，我们认为这些困难是社区所采取的方向所特有的。对我们来说，当前的方向不太可能导致“可部署的”RL：在实践中有效并且可以在实际情况下工作但在经济上仍然可行的 RL。我们还针对该领域的一些困难提出了一个潜在的解决方案。
Introduction
自从 DeepMind 将深度强化学习应用于 Atari 游戏的突破性成果（2015 年）以来，RL 在 AI 社区中受到称赞，其承诺从“通向 AGI 的道路”到“自动驾驶汽车的关键”，直至“解决问题” 所有规划问题'。虽然已经取得了明确且有价值的进展，但目前的氛围是，除了解决游戏问题外，RL 没有达到我们的期望。我们认为，原因是五种流行的研究实践，它们与 2015 年相关，但目前使该领域停滞不前。
由于我们的使命不是责怪任何人（我们肯定犯过错误），我们将保留自己的例子和参考。我们的观点是，目前对 RL 实践和理论的炒作在很大程度上是不符合事实的，并且该学科需要成熟。
【1】Overfitting to specific benchmarks
Atari 最先进方法与 Mujoco（或其他基准）的最先进方法截然不同。几乎每篇论文都需要为其中一个流行的基准展示一些区别（在某些指标下）。然而，这两个基准都是虚构的，使该领域远离可能适用于非 Atari 游戏/机器人运动的实际问题的算法。因此，关于最有可能仅适用于特定基准测试的调整的研究非常丰富。此外，尚不清楚基准的进展如何与现实世界的价值相关。与广泛适用于现实世界应用的预训练 ImageNet 特征或 BERT 句子嵌入相比，解决 RL 基准测试目前不会产生有形价值。
【2】Wrong focus
大多数研究都关注给定基准的样本复杂性。这在实践中几乎不是这样——相对于工程工作，计算可能更便宜，获取带标签的演示可以显着加快学习速度，开发过程必须考虑诸如整体系统稳定性、可测试性、易于调试、可解释性、与其他组件集成等问题 /智能体等。当前的基准测试完全忽略了定位（RL 驱动）智能体的可部署特性，专注于算法而不是系统/工程视图。这在流行的 OpenAI Gym API 中得到了最清楚的体现，它抽象出所有“系统设计”问题，以便在样本复杂性方面快速取得进展。虽然最初是个好主意，但这会阻碍进展，因为在许多实际问题中，仅仅弄清楚什么是有用的状态、动作和奖励是开发过程的关键组成部分。
【3】Detached Theory
理论在现代 RL 研究中应该扮演什么角色？没有具有小的有限状态和动作空间的真实系统。理想情况下，理论应该有助于理解实践中观察到的现象，并提出算法思想。虽然“没有什么比好的理论更实用”（Lewin，1952 年），但有用的理论似乎很少见。一些原因是：后悔最小化过于悲观；理论中没有考虑到很多先验知识（在算法设计、参数选择等方面）；对于许多感兴趣的问题，有限状态和动作不是一个好的模型；并关注没有人关心的不重要的数量。
【4】Uneven Playing Grounds
在基准上衡量算法的性能会受到实施者可用资源的混淆，例如超参数调整的熟练程度、训练的神经网络的大小或关于问题/解决方案的先验知识。不同研究人员（例如，学术界与工业界）所能承受的实验和软件工程规模的差异，以及目前顶级会议更喜欢大规模实验而不是概念新颖性的趋势，可能会阻碍长期进步。
【5】Lack of Experimental Rigor
令人印象深刻的单一实验有时会给人一种错误的进步感。虽然是不错的 PR 点击诱饵，但这些可能只会令人失望，因为它们排除了对实际上远未解决的“已解决”问题的研究。
例如，简单的 2D ProcGen Maze 基准测试仍未解决。我们需要对难度和成功进行更严格的评估。此外，对于采用一种方法的行业来说，令人印象深刻的结果是不够的——稳定性、开发时间和成本、可测试性和生命周期问题至关重要。目前，发布标准是几乎从不报告故障案例，无法判断稳定性，甚至不讨论软件设计问题。
Generalist Agents vs. Deployable RL Systems
关于如何在解决现实世界的决策问题方面取得进展，RL 社区有两个主要dogmas。第一种，我们在这里称为“通才智能体（generalist agent）”观点（有时称为“RL First”），未来的进展将通过关注解决不同问题的智能体的大规模训练来取得，希望 在此过程中，通才智能体将发展，并将成为各种现实世界问题的有用组成部分。第二种观点，我们称之为“可部署的 RL”，采用更务实的观点，寻求设计 RL 算法来解决具体的现实世界问题（有时这种观点被称为“RL second”）。上述五个问题与这两种方法都相关。然而，在我们提出的修复中，我们关注第二种观点。原因是根据该领域的当前知识，我们认为可部署 RL 可以获得具体的好处，而通才代理前景仍处于早期开发阶段。
Principles of Deployable RL Research
重要的是要了解，目前部署 RL 是不经济的。改变这一点既需要研究如何有效地部署 RL，也需要更好地理解 RL 解决方案可能带来的收益，这最终将使其值得追求。我们提出了一个 RL 研究的建设性模型，我们认为它与我们在该领域的当前知识状态相关，并将推动在现实世界中部署基于 RL 的解决方案的进展。
在下文中，我们概述了三个一般原则。我们希望研究人员在他们的项目中采用其中一些原则，反过来，出版标准将适当地重视这些原则。
【1】Challenges instead of benchmarks
挑战是由学术界/工业界的一组研究人员发起的（真实的或虚假的）问题。与基准测试不同，挑战的目的不是比较算法，而是简单地解决问题。也就是说，无论用于解决挑战的 RL（或其他）算法如何，在挑战中取得进展都具有现实世界的价值。Credit for contributing challenges对挑战的严格介绍应被视为重要贡献（在引用、影响等方面）。贡献不仅仅是对应用程序的具体描述，而是围绕它的社区，以及支持平台（代码、记分牌等）。我们设想了一种特殊类型的论文：“贡献的挑战”。评估挑战的一个基本标准将是一个可量化的衡量标准，以衡量在挑战上取得真正的、广为接受的进展。也就是说——不再最大化虚构的奖励，而是朝着现实世界进步的指标努力。Measurable progress is the main criterion for publication 每份通过提出新算法、正面或负面结果在挑战上取得进展的出版物都应解释所提出的新算法的局限性和问题，以及它如何具体解决进展。发表作品的主要标准是以可量化的方式取得的进展。Weight class开发期间可用的计算将贡献者区分为“重量级”，这也应该报告。用于研究的计算总量对于评估结果的重要性很重要。
【2】Theory papers should address specific challenges
当理论论文提出模型、算法或解决方案时，问题应该清楚，并以真实的挑战为基础。我们并不反对研究小型有限模型的理论，但研究的目标应该在其对现实世界问题的潜在影响方面得到充分证明。理论论文还应该考虑与系统生命周期有关的问题，重点关注数据采集、调试、可测试性和性能下降等问题。
【3】Design-Patterns Oriented Research
软件设计基于插入多个设计模式(plugging multiple design patterns)、组合它们并重新打包软件系统。软件工程中的设计模式是针对特定问题的解决方案的框架，可以在许多实例中重复使用。类似地，现实世界中基于 RL 的系统应该具有解决可测试性、可调试性和其他系统生命周期问题等问题的概念性解决方案。解决基于应用程序的问题的生命周期管理方法是 RL 研究的一个受欢迎的补充。重要的是，我们预见到在挑战上取得重大进展的一种方法是为其开发新颖的设计模式。
Actionable Next Steps
社区越早开始关注可部署的 RL，看到大规模现实世界影响的机会就越大。对我们来说，可部署的 RL 意味着 RL 可以大规模工作，在经济上可行，并且最终可以投入实地。
如果与上述几点有关，那么可以执行以下操作。
【1】Contribute challenges.
贡献挑战需要对应用程序领域有深刻的理解。一些工业研究实验室已经做好准备开始处理这项任务。RL 可以对许多科学和工程学科产生影响，例如自然科学、医学和制造。挑战对它所来自的学科应该很重要，因此虽然 RL 专家可能不具备领域知识，但他们在挑战中的目标是向领域专家解释什么是可能可行的，什么是不可行的。与工业界或其他学术界联手将带来更好的框架和更现实的挑战。
【2】Frame your own research.
在撰写论文和进行研究以专注于解决重要的实际问题并在可部署的 RL 原则范围内构建研究工作时，可能需要改变重点。
【3】Criticize others' research
影响 RL 研究社区的变化可能需要研究人员、审稿人和高级领域主席的协调努力。如果您正在审查 RL 论文，请从常见的基准驱动评估换档，并询问论文如何使该领域更接近现实世界的影响。如果您是高级审稿人或区域主席 - 考虑指示您的审稿人以不同方式判断论文。
