最近，我们一直在和多方讨论负责任扩展政策（responsible scaling policy，RSP）。1 2 RSP 需要回答两个问题：在现有防护措施下，AI 开发者可以安全应对多高水平的系统能力？如果系统能力继续提升，在哪些情况下必须先加强防护，才能继续部署或进一步提升系统能力？

我们认为，如果许多机构采纳高质量 RSP，并且这些政策包含下文列出的关键要素，AI 带来的灾难性风险会明显低于“一切照旧”的情况。不过，自愿承诺不足以充分控制 AI 风险。RSP 最初是为重视安全的实验室设计的，是它们现在就能采取的初步措施；它不是为政策制定者量身定做的工具。无论现在还是将来，我们都不认为 RSP 能替代监管。3

本文先说明我们理解的 RSP 基本思路，再讨论两个问题：

我们为什么认为 RSP 有前景？ 简单说，有三点：

  • 能回应双方关切。 有些人认为 AI 可能极其危险，因此支持暂停 AI 开发等措施；也有人认为现在担心还太早。RSP 对双方都可能有用：是否继续提升系统能力，不靠空泛判断，而取决于具体评估和经验观察。只要评估足够准确，一旦真正出现危险能力，AI 开发就应当暂停；如果相关担忧没有成真，开发也可以继续。
  • 帮助确定防护重点。 RSP 能把“要谨慎”这类宽泛原则变成具体承诺，让 AI 开发者明确：为了继续开发和部署，哪些防护最需要优先加强，例如信息安全、拒绝有害请求、对齐研究等。
  • 推动基于评估的规则和规范。 从长期看，我们看好更广泛、基于评估的 AI 规则和规范：开发者应评估 AI 系统是否具备危险能力；如果只有通过限制使用才能控制风险，就应先限制使用，直到防护措施跟上。这可能包括行业标准、第三方审计和监管。自愿 RSP 可以更快落地，也能为未来基于评估的监管制度积累流程和技术经验。

下面说明一份好的 RSP 应包含哪些关键要素，以及各部分可以如何表述。简单说，一份好的 RSP 应包括：

  • 能力界限：观察到哪些具体危险能力时，应认为继续提升系统能力已经不安全，或很可能不安全？
  • 防护措施：哪些防护措施是控制灾难性风险所必需的？
  • 评估：通过什么流程及时捕捉危险能力正在接近界限的早期预警信号？
  • 响应：如果危险能力越过界限，而防护措施无法迅速跟上，AI 开发者是否愿意暂停继续提升系统能力，直到防护措施足够强，并能以足够谨慎的方式处理任何危险模型？
  • 问责：AI 开发者如何确保 RSP 承诺按预期执行；关键利益相关方如何核实执行情况，或在承诺没有落实时发现问题；第三方如何提出批评；RSP 本身的修改如何避免仓促或不透明？

理想情况下，开发者采纳 RSP 应当传递一个可靠而有力的信号：这家机构更有可能判断出什么时候继续提升系统能力已经太危险，也更有可能作出适当反应。

RSP 的基本思路

不同人在谈到“负责任扩展”时，可能指的是不同内容。本文主要讨论我们（ARC Evals）认为这一概念中最重要的部分。

RSP 的核心目标很简单：让防护措施始终走在 AI 系统的危险能力前面。粗略示意如下：

RSP 的目标是让防护措施领先于危险能力。

下面以两种可能出现的危险能力为例，说明按照我们目前的初步判断，要安全应对这类能力需要哪些措施。为便于说明，我们没有把所有限定条件都写出来；相关问题仍在研究中，下面的例子主要只是说明思路。

示例：如果 AI 可能增加生物武器风险，那么在开发这类模型之前，就需要足够有力的信息安全措施，防止模型权重被盗；如果要部署模型，还需要采取监控和限制措施，防止模型被用于开发生物武器。

  • 一些生物学家认为，大语言模型（LLM）可能会“消除以往生物武器开发中遇到的一些障碍”。4 目前，具备足够生物学专业知识的人可能已经能够制造危险的生物武器，并引发疫情。未来，LLM 可能降低获得这类“专业知识”的门槛，例如为潜在恐怖分子提供生物实验流程的详细指导，从而增加风险。
  • 如果某个 LLM 已经具备这类能力，开发者就需要做到：
    （a）无论是公司内部用户还是外部用户，都不能让模型协助开发生物武器。例如，可以通过限制使用、监控，或训练模型极其可靠地拒绝提供相关信息等办法来做到这一点。
    （b）信息安全足够强，开发者有信心防止恶意行为者窃取模型权重，或以其他方式绕过这些限制。
  • AI 开发者可以在 RSP 中承诺：评估系统是否具备生物武器开发能力；如果某个 AI 系统在这一领域能力很强，就落实上面的（a）和（b）。
  • 如果开发者无法确保（a），就需要避免部署这个系统，包括内部部署。如果无法确保（b），就需要尽可能保护模型权重，并在信息安全达到足够水平之前，避免继续开发具备这类能力的模型。
  • 生物武器开发能力很可能和非常有益的能力一起出现，例如医学研究能力。如果 AI 开发者能够防止有害使用，并确保模型不会被恐怖分子窃取，那么仍然可以继续部署具备这类能力的系统。

示例：如果 AI 具备“自主复制与适应”（ARA）能力，就需要很高水平的信息安全保障；从更长期看，也可能需要更可靠的对齐保障。

  • ARC Evals 研究 LLM 智能体能否获取资源、复制自身，并在现实环境中适应新挑战。我们把这些能力称为“自主复制与适应”（autonomous replication and adaptation，ARA）。这类能力也常被称为“自我复制”；白宫此前宣布，多家 AI 公司已承诺评估自己的系统是否具备相关能力。
  • 具备 ARA 能力的系统可能被用来制造前所未有、高度灵活的计算机蠕虫。这类蠕虫不仅可以利用计算机漏洞传播，也可以通过社会工程传播。流氓国家或恐怖组织等恶意行为者可能部署这类蠕虫，造成极大破坏。蠕虫可能扩散成数百万个副本，用于网络犯罪或虚假信息行动，规模远超当前恶意行为者的能力。蠕虫还可能随着时间提升自身能力和韧性。若再有少量人类支持，这类系统甚至可能变得难以关闭。随着系统能力提升，这些风险可能快速增长。
  • 未来，社会也许有办法处置并关停自主复制模型，例如大范围使用高能力 AI 系统相互制衡。但这种做法要求我们对对齐有很高的信心，否则可能导致 AI 出现意外行为。在此之前，要安全应对具备 ARA 能力的 AI，就需要很强的信息安全措施，防止模型权重外泄；外泄可能来自恶意行为者，甚至也可能来自模型本身。
  • AI 开发者可以在 RSP 中承诺定期评估系统是否具备 ARA 能力，并承诺如果这类能力在足够强的信息安全或社会层面的遏制措施到位前出现，就采取果断行动。这类行动可以包括：只允许 AI 在极高安全级别的环境中运行，或者暂停进一步 AI 开发，转而集中分析和缓解风险。

有些设想中的 AI 能力，可能需要远超当前水平的防护。 例如，如果 AI 有可能导致人类灭绝，或者能通过自动化 AI 研究迅速加速这类风险，要建立足够防护会极其困难，可能需要 AI 安全基础科学和信息安全方面的重大进展；这些进展可能需要很长时间，而且时间难以预测。RSP 可以承诺：遇到这种情况就无限期暂停，直到防护措施取得足够进展。

为什么 RSP 重要

无论对风险的估计高低，RSP 都有吸引力

RSP 试图同时回应两种观点：一种认为 AI 可能极其危险，因此支持暂停 AI 开发等措施；另一种认为，现在就担心具有灾难性潜力的能力还为时过早，我们需要继续开发更先进的系统，才能理解相关威胁模型。

对这两种观点来说，RSP 都可能有价值。是否继续提升系统能力，取决于具体评估和经验性观察；如果评估足够准确，那么一旦真正出现危险能力，AI 开发就应当暂停；如果事实证明这些担忧被高估，开发也可以继续。

RSP 能帮助 AI 开发者规划并落实降低风险的措施

要采纳 RSP，AI 开发者就必须把宽泛的谨慎原则转化为具体承诺，并明确回答：

  • 具体哪些危险能力会超出当前防护措施可安全应对的范围。
  • 为了安全应对这些能力，需要做出哪些调整和改进。
  • 随着系统能力继续提升，哪些测试最关键，哪些防护措施最需要尽早改进并提前规划。

本文所说的 RSP 还要求开发者建立清晰流程，确保危险能力评估可靠开展，并在需要响应时能够及时行动、控制风险。

RSP 不能替代信息安全、检测并阻止有害 AI 交互的能力、透明度与问责、对齐研究等防护措施。恰恰相反：如果开发者想继续推进 AI 能力，使其达到在缺乏这些措施时本会过于危险的水平，RSP 就要求开发者先把这些防护措施真正做到位。

RSP 能帮助社会为范围更广的评估型规则和规范积累经验

我们认为，基于评估的 AI 规则和规范前景广阔：开发者应评估 AI 系统是否具备危险能力；如果只有通过限制使用才能控制风险，就应限制使用。长期来看，这类规则和规范应包括行业标准、第三方审计、州和国家层面的监管，以及各种国际执行机制等。5

要建立有效的、基于评估的规则和规范，需要大量工作并反复迭代。许多细节仍有待摸索：应开展哪些评估、如何开展、多久开展一次、针对不同危险能力分别需要采取哪些防护措施，等等。

不同参与方可以快速、灵活地设计、试验和迭代 RSP。因此，RSP 可能有助于推动社会逐步形成更广泛的、基于评估的规则和规范。

具体来说，我们可以期待：

  • 在未来几个月内，不止一家 AI 开发机构会起草并采用一份较为有力的初版 RSP。
  • 此后，第三方会比较不同 AI 开发者的 RSP，提出批评并开展压力测试，推动 RSP 改进。同时，AI 开发者也会积累执行自身 RSP 的经验，例如开展测试、随着能力进展改进防护措施，并解决大量细节和执行层面的难题。
  • 到某个阶段，不止一家 AI 开发机构会形成有力、可执行、并经过实践检验的 RSP。届时，这些开发者积累的实践经验，以及实际参与执行这些做法的人才，将成为制定更广泛的、基于评估的规则和规范的重要资源。这并不是说标准或监管应该简单照搬 RSP；例如，外部人士很可能会要求比开发者自我约束更高的安全标准。但如果监管能以丰富的既有实践和相关人才为起点，就更可能取得更好效果：更聚焦关键风险、更有效，也更切合实际。

如果采用 RSP 的公司放慢脚步，而其他公司继续全速推进，怎么办？

RSP 有一种可能的失败情形：谨慎的 AI 开发者为了避免风险而放慢脚步，不够谨慎的开发者却继续尽可能快地推进。这样一来，风险未必下降，甚至可能上升。

开发者可以在 RSP 中保留一定灵活性，以降低这一风险：

  • 如果采纳 RSP 的开发者认为，其他参与者继续提升系统能力带来的风险已经高到不可接受，并且已经尝试并用尽其他办法来遏制这些风险，包括大力推动监管行动，那么某些情况下，这些开发者可以继续提升自己系统的能力。同时，这些开发者仍应与政府或其他主管机构合作，推动立即采取措施，限制所有 AI 开发者（包括自身）继续提升系统能力。
  • 这时，开发者应当明确告知员工、董事会和政府部门：自己正在援引这一条款，而且继续提升系统能力已经不再安全。开发者应清楚说明，AI 系统带来的灾难性风险已经迫在眼前，而不是未来假设中的风险；其中也包括自己的系统。开发者还应对继续推进的决定接受问责。

即便留有这种灵活性，RSP 仍然要求严格测试危险能力；仍然要求优先改进防护措施，尽量避免开发者陷入“明知有危险却仍必须继续推进 AI 研发”的局面；也仍然是迈向更严格、基于评估的规则和规范的第一步。

RSP 的其他缺点

好的 RSP 需要相应的评估机制，能够可靠地发现关键风险的早期预警信号，同时也不能频繁误报。针对灾难性 AI 风险的评估仍是一门很新的科学，我们还不能保证一定能建立这样的指标：既能可靠发现早期预警信号，又不会频繁误报。

总体上，我们认为 RSP 明显优于现状。但我们仍担心两类问题：一是评估质量不够高；二是外界可能未能准确理解，一份 RSP 需要达到什么标准，才足以充分降低风险。

一份好的 RSP 应包含哪些关键要素

请参见本页，了解我们认为一份好的 RSP 应包含哪些关键要素，以及各部分可如何表述。

简而言之，我们认为一份好的 RSP 应包含以下全部内容：

  • 能力界限：观察到哪些具体的危险能力时，应认为继续提升系统能力已经不安全，或很可能不安全？
  • 防护措施：要控制灾难性风险，需要哪些防护措施？
  • 评估：通过哪些流程及时捕捉危险能力正在接近界限的早期预警信号？
  • 响应：如果危险能力越过界限，而防护措施无法迅速跟上，AI 开发者是否愿意暂停继续提升系统能力，直到防护措施足够强，并能以足够谨慎的方式处理任何危险模型？
  • 问责：AI 开发者如何确保 RSP 承诺按预期落实；关键利益相关方如何核实执行情况，或在承诺未落实时发现问题；第三方如何提出批评；如何避免对 RSP 本身作出仓促或不透明的修改？

我们的关键要素清单主要面向希望推进 AI 能力前沿的大型 AI 开发者。对于不推进能力前沿的 AI 开发者，清单也提供了一些较为简化的 RSP 建议。

许多人曾研究与 RSP 相近的想法，影响了我们的思考，也为本文提供了反馈。我们对此深表感谢。我们尤其感谢 Paul Christiano：在我们所理解的 RSP 中，许多核心思想和设计都源自他的工作。也感谢 Holden Karnofsky 和 Chris Painter 帮助我们改进框架和表述。

本文于 2023 年 10 月 26 日根据读者反馈修订。原始版本可在此处查看。



  1. 关于负责任扩展的讨论，可参见加州州参议员的一则新闻稿、英国科学、创新与技术大臣 Michelle Donelan 的一次演讲及相关推文，以及 Anthropic 的一篇博客文章。 ↩

  2. 这里的“扩展”（scaling）含义较广，指“将 AI 系统的能力提升到此前从未达到的水平”。“负责任扩展”还包括改进插件和工具、提示和能力引出（elicitation）、微调方法和数据集等。 ↩

  3. 这一段已根据读者反馈于 2023 年 10 月 26 日修订。有读者担心，我们的表述可能会被理解为：RSP 可以替代监管，或有条件的扩展暂停可以替代立即暂停，即使当时本可以在全球范围内可靠地实施暂停。ARC Evals 内部对监管和扩展暂停有不同看法；可参见 Paul Christiano 此处和 Beth Barnes 此处的部分观点。 ↩

  4. 例如参见 Sandbrink 2023 和 Esvelt et al. 2023。 ↩

  5. 这些机制可以包括条约、有条件制裁、“软实力”（要求各国自我监管；为了保持良好关系，各国可能愿意配合）等。 ↩