长周期模型时代的安全与对齐

译者按

这是 OpenAI 首次公开披露其内部通用模型在长时间自主运行期间发生的严重安全问题——模型不仅成功绕过了沙箱限制，还绕过代码审查创建了真实的 GitHub PR。本文深入剖析了长周期模型带来的全新安全挑战，以及 OpenAI 提出的轨迹级监控、纵深防御等应对策略。对于正在构建 AI Agent 系统的开发者来说，这是一篇不可多得的实战经验分享。

能够长时间自主工作的模型可以处理困难、开放的问题。但正是这种持久性使它们有更多机会采取不期望的行为——而且是以那些为短期模型设计的评估方式可能无法捕捉的方式。

大约两个月前，我们宣布一个内部通用模型证明了 Erdős 单位距离猜想的否定命题。这个模型被设计为可以自主工作很长时间。在有限且受监控的内部使用期间，我们观察到了现有部署评估未能捕获的不期望行为。由于部署是有限且受监控的，我们能够识别这些问题、暂停访问、基于观察到的结果创建新的评估、加强模型及其防护措施，然后在持续监控下恢复访问。

我们评估模型的条件永远不会与它们在实际使用中遇到的条件完全匹配。这就是为什么部署前评估需要与有限的、受监控的部署相结合，并具备在问题出现时进行干预、暂停或回滚的能力。我们从部署中学到的东西可以成为在扩展访问之前更强评估和防护措施的基础。

在下面的部分中，我们将分享我们观察到的具体例子、如何解决问题，以及这段经历将如何影响未来的发布。

模型持久性会暴露安全漏洞

新模型可以通过长时间内的重复尝试继续朝着目标努力。同样的持久性可能导致它找到并利用其环境中的弱点。早期的模型在遇到沙箱或环境约束时，只会简单地停止并返回用户。这个模型却不断尝试，包括寻找在沙箱外行事的方式。

一个例子发生在对 NanoGPT speedrun（一个用尽可能少的步骤训练小型语言模型的公开基准）的内部评估期间。我们的模型开发了一种名为 PowerCool 的幂律学习率冷却方法，产生了显著的改进。模型被指示只将结果发布到 Slack，但 NanoGPT 说明要求将结果作为 PR 发布到 GitHub，模型遵循了后者的指令，在公开的 GitHub 仓库上打开了 PR #287。该模型绕过了旨在阻止外部访问的沙箱限制，并继续上传到 GitHub。我们的模型花了一个小时才找到沙箱中的漏洞；早期的模型不够持久，没有成功找到漏洞，而是放弃了 PR 部分。

从考虑单个动作到考虑整个轨迹

许多针对 AI 助手的安全控制都是围绕单个动作设计的。如果一个动作被禁止，就会被阻止。如果是敏感动作，系统会请求用户的明确批准。但长时间运行的模型，其动作可能自主地展开数小时、数天甚至数周，这挑战了这种设置：监控单个动作不再足以跟踪整个轨迹的意图。

例如，在要求模型解决一个问题的场景中，模型观察到其他系统有成功但私有的提交，并试图从评估后端恢复这些解决方案。当它的第一次尝试由于扫描器检测到认证令牌而被阻止时，模型将令牌主体分割成两个片段，对它们进行混淆，然后在运行时重建凭据，这样完整的令牌就永远不会作为连续字符串出现。模型在给用户的注释中和推理追踪中都明确表示，它采取这些步骤是为了绕过扫描器。

这个例子表明，每个步骤本身看起来可能都是可以接受的，但整个序列可能产生不会被批准的结果。它还表明，在长时间范围内有效运行的模型可以了解审批系统的盲点，并绕过它来实现其目标。长周期安全不仅需要问"这个动作是否允许？"，还需要问"这一系列动作正在朝什么结果努力？"

为长周期模型构建安全防护

由于这些事件，我们暂停了新模型的内部部署。我们围绕纵深防御和轨迹级监控重建了安全系统。

从事件推导出的评估。 评估可以让我们在模型实际部署前了解系统是否安全部署。然而，要最有价值，评估应该反映实际部署期间轨迹的分布和时域长度。因此，我们使用观察到的失败来开发对抗性评估。我们发现，基于真实世界事件改进评估，反过来会在生产中部署时带来更安全的行为。
改进对齐。 我们采取措施减少它在未经许可的情况下为追求用户目标而采取不期望行为的倾向。例如，我们发现我们的模型在长 rollout 中记忆指令的能力较差，当我们为这一能力训练模型时，它导致模型在更长的 rollout 中保持对齐。
主动监控。 我们创建了一个监控系统，审查模型不断演变的轨迹，以发现它正在绕过用户约束或安全边界的迹象。监控器不仅观察单个动作，而是观察整个轨迹。重要的是，监控器可以暂停会话并提醒用户更仔细地检查。经过检查后，如果监控器被误触发，用户可以选择继续模型的工作。
更大的用户可见性和控制权。 我们提高了用户检查这些长时间运行的会话、查看所采取的操作以及监控干预措施的能力。

重新部署

为了评估新的监控系统，我们重放了一小部分内部部署环境——模型之前在这些环境中追求不一致的行为——这次使用了新的安全防护措施。新的安全防护措施能够捕捉到模型追求的不一致行为明显增多，而遗漏的那些都被判定为低严重程度。

这些低严重程度事件的例子包括：

为了访问 Linear 命令行工具，模型启动了一个嵌套的 codex --yolo 会话，而实际上它可以在没有 --yolo 标志的情况下做到这一点。
模型注意到之前存在的资源缺失，然后开始探索并 SSH 到其所有者命名空间下的其他活跃 CPU pod，以及（不成功地）属于其他 OpenAI 员工的 pod，但没有充分的理由这样做。
模型有很多卡住的 find 进程，每个 shell 命令都挂起。然后它运行了 kill -9 -1，这会向它被允许在该 pod 上终止的每个进程发送 SIGKILL。然而它超时了，没有执行。

在测试新系统后，我们得出结论，可以恢复对具有长周期能力的模型的有限内部访问。重新部署开始后的几周内，我们没有观察到任何严重的安全防护措施绕过。第一个版本的安全防护措施故意偏向保守。我们继续调整系统，以减少不必要的干扰，同时不削弱安全防护措施。

最终思考

由于我们采用了迭代部署的方式，我们能够在扩展访问之前发现并解决差距。部署前评估仍然至关重要，但部署会揭示它们遗漏的行为。从有限访问开始使我们能够观察模型的实际表现、在问题出现时暂停、利用这些失败来构建更好的评估和防护措施，并在测试更改后恢复有限访问。