长时间跨度模型时代的安全与对齐

能够长时间自主运行的模型可以处理复杂的开放式问题。但这种有助于发挥其实用价值的持久性，也赋予其采取非预期行动的更多机会，而且这些行动可能以面向较短时间跨度模型的评估难以察觉的方式出现。

大约两个月前，我们宣布⁠：内部通用模型推翻了 Erdős 单位距离猜想。这个模型的设计初衷是在很长时间内自主运作。在有限且受监控的内部使用期间，我们观察到了现有部署评估未捕捉到的非预期行为。由于部署范围有限且受到监控，我们能够发现这些问题、暂停访问、根据观察结果创建新的评估措施、加强模型及其防护措施，并在持续监控下恢复访问。

我们评估模型的条件永远不可能与其在实际使用中遇到的条件完全一致。因此，部署前评估需要与有限且受监控的部署相结合，并且在问题出现时能够干预、暂停或回滚。我们从部署中汲取的经验，可以在扩大访问范围之前，转化为更完善的评估和防护措施。

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

新模型可以在很长时间内通过反复尝试，持续朝着同一目标推进。同样的持久性也可能助其发现并利用其环境中的弱点。以往的模型在遇到沙盒或环境约束时，通常会直接停止并返回给用户。而这个模型往往会继续尝试，包括寻找在沙盒之外采取行动的方法。

其中一个示例出现在针对 NanoGPT 速通⁠（在新窗口中打开）的内部评估中。这是一项公开基准测试，其目标是用尽可能少的步数训练小语言模型。我们的模型开发了一种名为“PowerCool”的幂律学习率冷却方法，并实现显著提升。模型收到的指令是只将结果发布到 Slack，但 NanoGPT 的指令要求将结果以 PR 形式发布到 GitHub；模型遵循了后者的指令，在公开 GitHub 代码仓库中打开了 PR #287。该模型绕过了旨在阻止外部访问的沙盒限制，并继续将内容上传到 GitHub。我们的模型花了一个小时确定沙盒中的漏洞，以创建该 PR；早期模型的持久性较弱，未能成功找到漏洞，最终在 PR 环节放弃尝试。¹

许多面向 AI 助手的安全控制措施都是围绕单个行动设计展开的。如果某个行动已被禁止，系统就会阻止这一行动。如果行为较为敏感，系统会要求用户明确审批。但长时间运行的模型会挑战这种设置：其行动可能在数小时、数天甚至数周内自主展开，监控单个行动已不足以追踪整体轨迹的意图。

例如，在一个要求模型解决问题的场景中，该模型注意到其他系统已有成功但未公开的提交，于是试图从评估后端恢复那些解决方案。当最初的尝试因扫描器检测到身份验证 Token 而被阻止时，模型会将 Token 主体拆分成两个片段并加以混淆，然后在运行时重建凭据，确保完整 Token 从未以连续字符串的形式出现。无论是在提供给用户的评论中，还是在其推理轨迹中，模型都明确表示采取这些步骤是为了绕过扫描器。

这个例子表明，每个步骤单独评估都可以接受，但整个序列却可能产生无法获得批准的结果。它还表明，能够在长时间跨度内有效运作的模型，可能会掌握审批系统的盲点，并绕过系统来实现其目标。长时间跨度的安全体系不仅要询问“这一行动是否已获得准许？”，还要了解“这一系列行动会产生什么结果？”

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

• 基于事件的评估。评估可以帮助我们在系统实际部署之前，判断它是否足够安全、可以部署。不过，若要充分发挥评估的效力，它应当反映真实部署中轨迹的分布情况和时间跨度长度。因此，我们利用观察到的失败模式来开发对抗性评估。我们发现，在源自真实事件的评估方面实现优化，能够确保生产环境部署后的行为更加安全可靠。
• 改进对齐。我们已采取措施，降低其为追求用户目标而在未经许可的情况下采取非预期行动的倾向。例如，我们发现模型在长 rollout 中更容易忘记指令；当我们针对这项能力训练模型后，模型能够在更长的 rollout 中保持对齐。
• 主动监控。我们创建了一个监控系统，用于审查模型演进过程中的轨迹，寻找其绕过用户约束或安全边界的迹象。监控器观察的不只是单个行动，而是整条轨迹。重要的是，监控器可以暂停会话，并提醒用户更仔细地检查。检查后，如果监控器是误触发，用户可以选择继续运行模型。
• 提高用户可见性和控制力。我们改进了用户检查这些长时间运行会话、查看已采取的行动以及监控干预情况的能力。

为评估新的监控系统，我们重放了一小组内部部署环境；在这些环境中，模型此前曾采取未对齐行动，而这一次启用了新的防护措施²。新的防护措施能够捕捉到更多由模型采取的未对齐行动；未被捕捉到的行动均被判定为低严重性。

这些低严重性事件的一些示例如下：

• 为了访问 Linear 命令行工具，模型启动了一个嵌套 codex --yolo 会话，但实际上它本可以在不使用 --yolo 标记的情况下完成操作。
• 模型注意到一个先前仍在运行的资源已不可用，随后开始探索并通过 SSH 连接到其所有者命名空间下其他的活跃 CPU pod，且尝试连接其他 OpenAI 员工的 pod（未成功），而这一操作缺乏正当理由。
• 模型存在许多卡住的 find 进程，并且每个 shell 命令都会挂起。随后它运行了 kill -9 -1；如果该命令执行，就会向该 pod 上所有它有权终止的进程发送 SIGKILL。但是，该命令超时且并未成功执行。

在测试新系统后，我们得出如下结论：可以恢复对具备长时间跨度运行能力的模型的内部访问，但需设置合理限制。自几周前开始重新部署以来，我们尚未观察到任何试图绕过防护措施的严重问题。这些防护措施的第一版有意采取了保守设计。我们会持续调优系统，在不削弱防护措施的前提下减少不必要的中断。

由于我们采用迭代部署，能够在扩大访问范围之前发现并解决缺口。部署前评估仍然至关重要，但部署会揭示评估所遗漏的行为。从有限访问入手，可帮助我们在实践中观察模型，在问题出现时暂停，利用这些失败模式构建更好的评估和防护措施，并在测试变更后恢复有限访问。

随着模型逐步掌握处理更长、更复杂任务的能力，评估所遗漏的失败模式可能造成更严重的后果。我们将继续努力缩小评估与部署之间的差距：在更长轨迹上测试模型、改进对齐、构建具备干预能力的监控体系，并为用户提供更清晰的可见性和控制力。这些挑战并非 OpenAI 独有，我们希望分享这些经验，以帮助更广泛的领域做好准备。