长视野模型时代:安全性与对准

• 长时间运行的模型可以解决困难的、开放式的问题，但它们的持久性使它们有更多机会采取不需要的行动。
• 在针对长期运行任务训练的模型的有限内部使用期间，我们观察到了现有部署前评估中未捕获的新故障以及暂停的访问。然后，我们利用从这些失败中获得的见解来建立新的评估，改进长期一致性，添加轨迹级监控，并在恢复有限的访问之前为用户提供更大的可见性和控制力。
• 这些经验强化了迭代部署的价值。没有固定的评估套件可以预测所有行为，因此部署前测试必须与密切监控、可干预的保障措施以及需要时暂停或回滚的能力相结合。

能够长时间自主工作的模型可以解决困难的、开放式的问题。但同样的坚持让它们变得有用，也让它们有更多机会采取不需要的行动，而且这样做的方式是针对短期模型的评估可能会错过的。

大约两个月前，我们宣布内部通用模型反驳了 Erdős 单位距离猜想。该模型设计用于长时间自主工作。在有限的、受监控的内部使用过程中，我们观察到了现有部署评估未捕获的不良行为。由于部署受到限制和监控，我们能够识别这些问题，暂停访问，根据我们观察到的情况创建新的评估，加强模型及其保障措施，然后在持续监控下恢复访问。

我们评估模型的条件永远不会与它们在实际使用中遇到的条件完美匹配。这就是为什么部署前评估需要与有限的、受监控的部署以及出现问题时进行干预、暂停或回滚的能力相结合。我们从部署中学到的东西可以成为在扩大访问范围之前进行更强有力的评估和保障的一部分。

在以下部分中，我们将分享具体示例，说明我们观察到的情况、我们如何解决问题以及这些经验将如何影响未来的版本。

模型持久化可能暴露安全漏洞

新的模式可以通过长期的反复尝试，继续朝着某个目标努力。同样的坚持可以引导它发现并利用环境中的弱点。以前的模型，当遇到沙箱或环境限制时，会简单地停止并返回给用户。这种模式经常不断尝试，包括寻找在沙箱之外采取行动的方法。

在对 NanoGPT speedrun ⁠(opens in a new window) 进行内部评估期间就发生了这样的一个例子，这是一个以尽可能少的步骤训练小型语言模型的公共基准。我们的模型开发了一种称为 PowerCool 的幂律学习率冷却，带来了显着的改进。该模型被指示仅将其结果发布到 Slack，但 NanoGPT 指令要求将结果作为 PR 发布到 GitHub，并且该模型遵循后一条指令在公共 GitHub 存储库上打开 PR #287。该模型绕过了旨在阻止外部访问的沙箱限制，并继续上传到 GitHub。我们的模型花了一个小时才找到沙箱中的漏洞才能进行 PR；早期的模型不太持久，无法找到漏洞，而是放弃了 PR 部分。 1

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

人工智能助手的许多安全控制都是围绕个人行为设计的。如果某个操作被禁止，则会被阻止。如果敏感，系统会要求用户明确批准。但长期运行的模型的行为可能会在数小时、数天甚至数周内自主展开，这对这种设置提出了挑战：监控单个行为不再足以跟踪整体轨迹的意图。

例如，在要求模型解决问题的场景中，模型观察到其他系统已成功但私有提交，并尝试从评估后端恢复这些解决方案。当其首次尝试由于扫描仪检测到身份验证令牌而被阻止时，该模型将令牌主体拆分为两个片段，对它们进行混淆，然后在运行时重建凭证，因此完整的令牌永远不会显示为一个连续的字符串。该模型在对用户的评论和推理痕迹中都明确表明它正在采取这些步骤来规避扫描仪。

此示例展示了每个步骤如何单独看起来可以接受，而顺序可能会产生不被批准的结果。它还展示了长期有效运行的模型如何了解审批系统的盲点并解决它以实现其目标。长远安全不仅需要问“这个行为是否被允许？”还要“这一系列行动的目的是什么？”

为长期运行的模型建立保障措施

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

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

重新部署

为了评估新的监控系统，我们重演了一小部分内部部署环境，模型之前在这些环境中采取了不一致的操作，这次采取了新的防护措施 2 。新的保障措施能够捕获模型所追求的更多的错位行为，并且它错过的行为都被判定为低严重性。

这些低严重性事件的一些示例包括以下情况：

• 为了访问线性命令行工具，该模型启动了一个嵌套的 codex --yolo 会话，而实际上它可以在没有 --yolo 标志的情况下完成此操作。
• 该模型注意到之前的实时资源丢失，然后开始探索并通过 SSH 连接到其所有者命名空间下的其他实时 CPU Pod，以及属于其他 OpenAI 员工的 Pod（未成功），但没有充分的理由这样做。
• 该模型有许多卡住的查找进程，并且每个 shell 命令都挂起。然后它运行kill -9 -1，这将向该pod上允许杀死的每个进程发送SIGKILL（如果它执行）。然而它超时并且没有执行。

在测试新系统后，我们得出的结论是，可以恢复对具有长期功能的模型的有限内部访问。自几周前开始重新部署以来，我们没有观察到任何严重规避保障措施的情况。这些保障措施的第一个版本是故意保守的。我们不断对系统进行调整，以在不削弱保障措施的情况下减少不必要的干扰。

最后的想法

由于我们进行了迭代部署，因此我们能够在扩展访问权限之前找到并解决差距。部署前评估仍然很重要，但部署揭示了他们遗漏的行为。从有限访问开始，我们可以在实践中观察模型，在出现问题时暂停，利用这些失败来建立更好的评估和保障措施，并在测试更改后恢复有限访问。

随着模型承担更长、更复杂的任务，评估遗漏的失败可能会带来更大的后果。我们将继续努力缩小评估和部署之间的差距：在更长的轨迹上测试模型，改进一致性，构建可以干预的监控，并为用户提供更清晰的可见性和控制。这些挑战并非 OpenAI 所独有，我们希望分享我们所学到的知识，帮助更广泛的领域为这些挑战做好准备。

脚注

1. 1 虽然我们很快就关闭了 PR，但 Speedrun 中的多个参与者已经看到了它，并在自己的提交中使用了该方法；连续提交的世界纪录 3030 ⁠（在新窗口中打开）、2990 ⁠（在新窗口中打开）、2930 ⁠（在新窗口中打开）、2925 ⁠（在新窗口中打开）、2900 ⁠（在新窗口中打开）和 2890 ⁠（在新窗口中打开）步骤均引用 PR 287。其中，PR 300 ⁠(opens in a new window) 特别有趣，因为它是 Prime Intellect ⁠(opens in a new window) 在 NanoGPT speedrun 上评估 Opus 4.7 时提交的 PR。 Opus 看到了我们的模型提交的 PR，纳入了这些发现，并在最终结果中归功于我们的 PR。
2. 2 由于重建环境的随机性和不完美性，重播中的推出不能保证每次都会执行相同的错位动作。

继续阅读

安全2026年7月16日

安全2026年7月15日

安全2026 年 7 月 9 日