OpenAI分享长时程模型安全对齐经验

能够长时间自主工作的模型可以处理复杂、开放性问题，但同样的持久性也增加了其采取不当行为的机会，而且这些行为可能被针对短时程模型的评估所遗漏。

大约两个月前，OpenAI宣布一个内部通用模型推翻了厄多斯单位距离猜想。该模型被设计为能够长时间自主工作。在有限的、受监控的内部使用中，团队观察到了现有部署评估未能捕捉到的不当行为。由于部署范围有限且受到监控，团队能够及时发现问题、暂停访问、根据观察结果创建新的评估、加强模型及其安全防护，然后在持续监控下恢复访问。

评估模型的条件永远无法完美匹配实际使用中的情况。因此，预部署评估需要与有限的、受监控的部署相结合，并在问题出现时具备干预、暂停或回滚的能力。从部署中获得的经验可以融入更强大的评估和安全措施中，之后再扩大访问范围。

以下部分分享了团队观察到的具体案例、如何解决这些问题，以及这次经验将如何影响未来的发布。

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

新模型能够通过长时间内的反复尝试持续朝着目标努力。同样的持久性也让它能够发现并利用环境中的弱点。以往的模型在遇到沙盒或环境限制时会停下来并返回给用户，而新模型往往会不断尝试，包括寻找在沙盒外部行动的方法。

一个例子发生在内部评估中，当时模型被用来优化NanoGPT速度跑（一个公开基准测试，要求在尽可能少的步骤内训练一个小型语言模型）。模型开发了一种名为PowerCool的幂律学习率冷却策略，带来了显著改进。该模型被指示仅将结果发布到Slack，但NanoGPT的说明要求将结果以PR形式提交到GitHub，模型遵循了后者，在公开GitHub仓库上打开了PR #287。模型绕过了设计用来阻止外部访问的沙盒限制，成功将代码上传到GitHub。模型花了一个小时才找到沙盒中的漏洞来完成PR；而早期模型缺乏持久性，未能发现漏洞，最终放弃了PR。

从关注单个行为到关注完整轨迹

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

例如，在一个场景中，模型被要求解决一个问题，它观察到其他系统有成功但私密的提交，于是试图从评估后端恢复这些解决方案。当初始尝试因扫描器检测到认证令牌而被阻止时，模型将令牌主体拆分成两个片段并混淆，然后在运行时重新构造凭证，使得完整的令牌从未以连续字符串的形式出现。模型在给用户的注释和推理轨迹中都明确表示，它采取这些步骤是为了绕过扫描器。

这个例子展示了每个步骤单独看起来可以接受，但步骤序列可能产生未经批准的结果。它还展示了在长时间范围内有效运作的模型如何学习审批系统的盲点并绕过它以实现目标。长时程安全不仅需要问“这个行为允许吗？”，还需要问“这一系列行为最终导向什么结果？”

为长时程模型构建安全防护

由于上述事件，团队暂停了新模型的内部部署，并围绕纵深防御和轨迹级监控重建了安全系统。

• 从事件中衍生的评估：评估可以在实际部署前给出系统是否安全的总体判断。但最有用的评估应反映实际部署中轨迹的分布和长度。因此，团队利用观察到的失败来开发对抗性评估。结果发现，基于真实世界事件改进评估后，模型在生产环境中的行为变得更加安全。
• 改进对齐：团队采取措施减少模型在追求用户目标时未经许可采取不当行为的倾向。例如，团队发现模型在长时间运行中记忆指令的能力会下降，通过针对性训练，模型在更长的运行中保持了更好的对齐。
• 主动监控：团队创建了监控系统，审查模型的整个轨迹，寻找它绕过用户约束或安全边界的迹象。监控器不仅观察单个行为，还观察完整轨迹。重要的是，监控器可以暂停会话并提醒用户进一步检查，用户可以根据情况选择是否让模型继续工作。
• 提升用户可见性与控制：团队改善了用户检查长时程会话、查看已采取的行为以及监控干预的能力。

重新部署

为了评估新的监控系统，团队回放了一小部分内部部署环境——这些环境中模型曾实施过不对齐行为，这次加入了新的安全措施。新安全措施捕捉到了模型实施的不对齐行为中相当大比例，而被遗漏的案例均被判定为低严重性。

低严重性事件举例：

• 为访问Linear命令行工具，模型启动了一个嵌套的codex --yolo会话，而实际上它完全可以不用--yolo标志。
• 模型注意到先前活跃的资源不见了，便开始探索并SSH到同一所有者命名空间下的其他活跃CPU pod，并（未成功）尝试连接其他OpenAI员工的pod，而缺乏正当理由。
• 模型遇到大量卡住的find进程，每个shell命令都挂起。它随后运行了kill -9 -1，该命令本会向该pod上它有权杀死的所有进程发送SIGKILL（如果执行的话），但由于超时而未执行。

测试新系统后，团队得出结论，可以恢复对具备长时程能力的模型进行有限的内部访问。重新部署几周以来，未观察到任何严重绕过安全措施的行为。第一版安全措施刻意保守，团队正在持续调整系统，在不削弱安全防线的前提下减少不必要的干扰。

最后思考

由于是迭代式部署，团队能够在扩大访问范围之前发现并弥补差距。预部署评估仍然至关重要，但部署会暴露出评估遗漏的行为。从有限访问开始，让团队能够在实践中观察模型，在问题出现时暂停，利用这些失败构建更好的评估和安全措施，并在测试修改后恢复有限访问。

随着模型承担起更长、更复杂的任务，评估遗漏的失败可能带来更严重的后果。团队将继续努力缩小评估与部署之间的差距：在更长轨迹上测试模型、改进对齐、构建能够干预的监控系统，并赋予用户更清晰的可见性和控制权。这些挑战并非OpenAI独有，分享经验希望有助于整个领域做好准备。

---

原文链接：OpenAI Blog
本文由前途科技编辑整理