最近，我们一直在和多方讨论负责任扩展政策（responsible scaling policy，RSP）。1 2 RSP 需要回答两个问题：在现有防护措施下，AI 开发者可以安全应对多高水平的系统能力？如果系统能力继续提升，在哪些情况下必须先加强防护，才能继续部署或进一步提升系统能力？
我们认为，如果许多机构采纳高质量 RSP，且这些 RSP 包含下文列出的关键要素，AI 带来的灾难性风险会明显低于未采纳 RSP 的情况。不过，公司做出的自愿承诺并不足以充分控制 AI 风险。RSP 最初是专为重视安全的 AI 实验室自行采用而设计的初步举措，而非为政策制定者量身定做的工具。无论现在还是将来，我们都不认为 RSP 能替代监管。3
本文将先说明我们所理解的 RSP 的基本思路，再讨论以下两个问题：
我们为什么认为 RSP 有前景？ 简单来说，有三点：
- 能回应双方关切。 有些人认为 AI 可能极其危险，因此支持暂停 AI 开发的措施；也有人认为现在担心 AI 的危险还太早。RSP 或许对双方都有用，因为它将是否继续提升系统能力的问题与具体评估和经验观察挂钩，而不再依靠空泛判断来决定是否继续发展 AI。只要评估足够准确，一旦真正出现危险能力，AI 开发就应当暂停。如果相关担忧没有成真，开发可以继续。
- 帮助确定防护重点。 RSP 能把“要谨慎”这类宽泛的原则变成具体的承诺，让 AI 开发者明确：为了继续开发和部署，哪些防护最需要优先加强。这些防护包括信息安全、拒绝有害请求、对齐研究等。
- 推动基于评估的规则和规范。 从长期看，我们看好更广泛的、基于评估的 AI 规则和规范：开发者应评估 AI 系统是否具备危险能力；如果只有通过限制使用才能控制风险，就应先限制使用，直到防护措施跟上。这可能包括行业标准、第三方审计和监管。公司主导的自愿 RSP 可以更快落地，也能在未来为基于评估的监管制度积累流程和技术经验。
下文重点阐述一份有效的 RSP 应包含哪些关键要素，其中的各部分可以如何表述。简而言之，一份有效的 RSP 应包括：
- 能力界限：当观察到哪些具体危险能力时，我们应当判断继续提升系统能力已经不安全，或很可能不安全？
- 防护措施：哪些防护措施是控制灾难性风险所必需的？
- 评估：通过什么流程能够及时捕捉到预示危险能力正在接近界限的早期信号？
- 响应：如果危险能力越过界限，而防护措施无法迅速跟上，AI 开发者是否愿意暂停提升系统能力，直到防护措施足够强，并能以足够谨慎的方式处理任何危险模型？
- 问责：AI 开发者如何确保 RSP 承诺按预期执行？关键利益相关方如何核实执行情况，或在承诺没有落实时发现问题？第三方如何进行评议？RSP 本身的修改如何避免仓促或不透明的情况？
理想情况下，AI 系统开发者采纳 RSP 应当传递一个可靠而有力的信号：这家机构更有可能判断出什么时候继续提升系统能力已经太危险，也更有可能作出相应的合理反应。
不同人在谈到“负责任扩展”时，可能指的是不同内容。本文主要讨论我们（ARC Evals）认为这一概念中最重要的部分。
RSP 的核心目标很简单：让防护措施始终走在 AI 系统的危险能力前面。
下面以两种可能出现的危险能力为例，说明按照我们目前的初步判断，要安全应对这类能力需要哪些措施。为便于说明，我们没有把所有限定条件都写出来；相关问题仍在研究中，下面的例子主要用于阐明思路。
示例：如果 AI 可能增加生物武器风险，那么在开发这类模型之前，就需要采取足够有力的信息安全措施以防止模型权重被盗；如果要部署 AI 模型，还需要额外采取监控和限制措施，防止模型被用于开发生物武器。
- 一些生物学家认为，大语言模型（LLM）可能会“消除以往生物武器开发中遇到的一些障碍”。4 目前，具备足够生物学专业知识的人或许已经能够制造危险的生物武器，并引发疫情。未来，LLM 可能继续降低获得这类“专业知识”的门槛，例如为潜在恐怖分子提供生物实验流程的详细指导，从而增加 AI 被滥用的风险。
- 如果某个 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 系统相互制衡。但这种做法要求我们对对齐有很高的信心，否则可能导致 AI 出现意外行为。在此之前，要安全应对具备 ARA 能力的 AI，就需要很强的信息安全措施，防止模型权重外泄；外泄可能来自恶意行为者，甚至也可能来自模型本身。
- AI 开发者可以在 RSP 中承诺定期评估系统是否具备 ARA 能力，并承诺在强有力的信息安全和社会层面的遏制措施到位之前，如果这类能力出现，开发者将果断采取行动。相关行动可以包括：只允许 AI 在极高安全级别的环境中运行，或者暂停进一步 AI 开发，转而集中分析和缓解风险。
有些设想中的 AI 能力可能需要远超当前水平的防护。 例如，如果 AI 有可能导致人类灭绝，或者能通过自动化 AI 的开发研究迅速加速这类风险，要建立足够的防护将会极其困难，可能需要 AI 安全基础科学和信息安全方面的重大进展；这些进展的耗时难以预测，可能需要很长时间进行开发。与此同时，RSP 可以承诺：遇到这种情况就无限期暂停，直到防护措施取得足够进展。
RSP 的重要性
无论对风险的估计高低，RSP 都具有吸引力
RSP 旨在兼顾两种观点：一种认为 AI 可能极其危险，因此支持暂停 AI 开发等措施；另一种认为，现在就担心具有灾难性潜力的能力还为时过早，我们需要继续开发更先进的系统，才能理解相关威胁模型。
无论持哪种观点，RSP 都是一项有前景的干预措施，因为其承诺了以具体评估和实证观察为 AI 能力的扩展设定限制。如果评估足够准确，那么一旦真正出现危险能力，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 的公司因此开发进度放缓，而其他公司却加速冒进，怎么办？
一种 RSP 可能导致的失败情形是：谨慎的 AI 开发者为了避免风险而放慢脚步，不够谨慎的开发者却继续尽可能快地推进。这样一来，风险未必下降，甚至可能上升。
开发者可以在 RSP 中保留一定灵活性，以降低这一风险：
- 如果采纳 RSP 的开发者认为其他参与者继续提升系统能力带来的风险已经高到不可接受，并且已经尝试并用尽其他办法来遏制这些风险（包括大力推动监管行动），那么在特定情况下，这些开发者可以继续提升自己系统的能力。同时，这些开发者仍应与政府或其他主管机构合作，采取即时行动以限制所有 AI 开发者（包括自身）继续提升系统能力。
- 在此情况下，开发者应当明确告知员工、董事会和政府部门自己正在援引这一条款，而且继续提升系统能力已经不再安全。开发者应清楚说明，AI 系统（包括自己的系统）带来的灾难性风险已经迫在眉睫，而并非存在于假设中的未来。开发者还应对继续推进 AI 开发的决策负责。
即便留有这种灵活性，RSP 仍然要求严格测试 AI 的危险能力，优先改进防护措施，尽量避免开发者被迫明确推进危险的 AI 开发研究；也仍然是迈向更严格的、基于评估的规则和规范的第一步。
RSP 的其他弊端
好的 RSP 需要相应的评估机制，能够可靠地发现关键风险的早期预警信号，同时也不能频繁误报。针对灾难性 AI 风险的评估目前仍处于起步阶段，我们还不能确保成功建立一个既能可靠发现早期预警信号，又不会频繁误报的指标。
尽管总体上我们认为 RSP 相对于现状是明显的改进，但我们也担心两类问题：一是评估不够完善，二是在传达 RSP 充分防范风险所需行动时，沟通失真所带来的问题。
一份好的 RSP 应包含哪些关键要素？
请参见本页，了解我们认为一份好的 RSP 应包含哪些关键要素，以及各部分可如何表述。
简而言之，我们认为一份好的 RSP 应包含以下全部内容：
- 能力界限：观察到哪些具体的危险能力时，应认为继续提升系统能力已经不安全，或很可能不安全？
- 防护措施：要控制灾难性风险，需要哪些防护措施？
- 评估：通过哪些流程能及时捕捉 AI 的危险能力正在接近界限的早期预警信号？
- 响应：如果危险能力越过界限，而防护措施无法迅速跟上，AI 开发者是否愿意暂停继续提升系统能力，直到防护措施足够强，并能以足够谨慎的方式处理任何危险的模型？
- 问责：AI 开发者如何确保 RSP 承诺按预期落实；关键利益相关方如何核实执行情况，或在承诺未落实时发现问题；第三方如何提出批评；如何避免对 RSP 本身作出仓促或不透明的修改？
我们的关键要素清单主要面向希望开发前沿模型的大型 AI 开发者。对于不推进 AI 能力前沿的开发者，清单也提供了一些较为简化的 RSP 建议。
我们由衷感谢曾就与 RSP 类似的想法开展工作、为我们的思考提供贡献以及对本篇文章给予反馈的广大人士。我们尤其感谢 Paul Christiano：他对 RSP 的核心思想与设计做出了大量贡献。我们也感谢 Holden Karnofsky 和 Chris Painter 帮助改进本文的框架和表述。
本文于 2023 年 10 月 26 日根据读者反馈修订。原始版本可在此处查看。
