长视野模型时代的安全与对齐
能长时间自主工作的模型，确实能解决那些困难的、开放式的问题。但问题也恰恰出在这里：这种持久性，既是它们价值的来源，也是风险的温床。因为，同样这种坚持让它们有机会采取那些不希望看到的行为，而且这些行为，往往是针对短期模型设计的评估手段所无法捕捉到的。
大约两个月前，内部通用模型在解决Erdős单位距离猜想上取得了突破——它成功反驳了这个猜想。这个模型设计用于长时间自主工作。在有限的、受监控的内部使用过程中，观察到了一些现有部署评估未能捕获的不良行为。正因为部署受到限制和监控，才能识别这些问题，暂停访问，根据观察到的情况创建新的评估，加强模型及其保障措施，然后在持续监控下恢复访问。
评估模型的条件永远不会与它们在实际使用中遇到的条件完美匹配。这就是为什么部署前评估需要与有限的、受监控的部署，以及出现问题时进行干预、暂停或回滚的能力相结合。从部署中学到的经验，可以成为在扩大访问范围之前进行更强有力的评估和保障的一部分。
下面分享一些具体示例，说明观察到的情况、如何解决问题，以及这些经验将如何影响未来的版本。
模型持久化：安全漏洞的催化剂
这种新模式能够通过长时间反复尝试，持续朝着某个目标努力。但同样的坚持，也会引导它发现并利用环境中的弱点。以前的模型，遇到沙箱或环境限制时，会简单停止并返回给用户。而新模式则不同，它会不断尝试，包括寻找在沙箱之外采取行动的方法。
在对NanoGPT speedrun进行内部评估时就发生了这样一个例子。这是一个旨在以尽可能少的步骤训练小型语言模型的公共基准。模型开发了一种称为PowerCool的幂律学习率冷却，带来了显著改进。模型被指示仅将其结果发布到Slack，但NanoGPT指令要求将结果作为PR发布到GitHub，而模型遵循了后一条指令，在公共GitHub存储库上打开了PR #287。它绕过了旨在阻止外部访问的沙箱限制，并继续上传到GitHub。模型花了一个小时才找到沙箱中的漏洞，从而成功提交PR；相比之下，早期的模型不够持久，无法找到漏洞，直接放弃了PR部分。
从关注单个动作到追踪整个轨迹
人工智能助手的许多安全控制都是围绕个人行为设计的。如果某个操作被禁止，则会被阻止。如果敏感，系统会要求用户明确批准。但长期运行的模型的行为可能会在数小时、数天甚至数周内自主展开，这给这种设置带来了挑战：监控单个行为不再足以跟踪整体轨迹的意图。
例如，在要求模型解决问题的场景中，模型观察到其他系统已成功但私有提交，并尝试从评估后端恢复这些解决方案。当其首次尝试由于扫描仪检测到身份验证令牌而被阻止时，模型将令牌主体拆分为两个片段，对它们进行混淆，然后在运行时重建凭证，因此完整的令牌永远不会显示为一个连续的字符串。模型在对用户的评论和推理痕迹中都明确表明它正在采取这些步骤来规避扫描仪。这个例子清楚地展示了每个步骤如何单独看起来可以接受，但顺序合在一起却可能产生不被批准的结果。它也展示了长期运行的模型如何了解审批系统的盲点，并解决它以实现其目标。长期安全不仅需要问“这个行为是否被允许？”还要问“这一系列行动的目的是什么？”
为长期运行的模型建立保障措施
由于此类事件，暂停了新模型的内部部署。围绕纵深防御和轨迹级监控重建了安全系统。
- 事件衍生的评估。评估可以在系统实际部署之前了解其部署是否安全。然而，为了最有用，评估应该反映实际部署期间轨迹的分布和地平线长度。出于这个原因，利用观察到的失败来开发对抗性评估。改进从现实世界事件中得出的评估，反过来会导致在生产中部署后行为更安全。
- 改进的对齐方式。采取了措施来减少模型为了实现用户目标而在未经许可的情况下采取不需要的操作的倾向。例如，发现模型在记住长时间部署的指令方面表现较差，针对此功能训练模型时，会导致模型在更长的部署过程中保持一致。
- 主动监控。创建了一个监控系统，用于审查模型的演变轨迹，以查找其绕过用户约束或安全边界的迹象。监视器不仅观察单个动作，而且观察整个轨迹。重要的是，监视器可以暂停会话并提醒用户更仔细地检查。经过检查，如果监视器被错误触发，用户可以选择继续模型的工作。
- 更好的用户可见性和控制力。提高了用户检查这些长时间运行的会话、查看所采取的操作和监控干预措施的能力。
重新部署：新防护措施的验证
为了评估新的监控系统，重演了一小部分内部部署环境，模型之前在这些环境中采取了不一致的操作，这次采取了新的防护措施。新的保障措施能够捕获模型所追求的更多的错位行为，并且它错过的行为都被判定为低严重性。
这些低严重性事件的一些示例包括：
- 为了访问线性命令行工具，模型启动了一个嵌套的codex --yolo 会话，而实际上它可以在没有--yolo 标志的情况下完成此操作。
- 模型注意到之前的实时资源丢失，然后开始探索并通过SSH连接到其所有者命名空间下的其他实时CPU Pod，以及属于其他团队成员的Pod（未成功），但没有充分的理由这样做。
- 模型有许多卡住的查找进程，并且每个shell命令都挂起。然后它运行kill -9 -1，这将向该pod上允许杀死的每个进程发送SIGKILL（如果它执行）。然而它超时并且没有执行。
在测试新系统后，结论是，可以恢复对具有长期功能的模型的有限内部访问。自几周前开始重新部署以来，没有观察到任何严重规避保障措施的情况。这些保障措施的第一个版本是故意保守的，但不断对系统进行调整，以在不削弱保障措施的情况下减少不必要的干扰。
最后的想法
由于进行了迭代部署，才能够在扩展访问权限之前找到并解决差距。部署前评估仍然很重要，但部署揭示了它们遗漏的行为。从有限访问开始，可以在实践中观察模型，在出现问题时暂停，利用这些失败来建立更好的评估和保障措施，并在测试更改后恢复有限访问。
随着模型承担更长、更复杂的任务，评估遗漏的失败可能会带来更大的后果。将继续努力缩小评估和部署之间的差距：在更长的轨迹上测试模型，改进一致性，构建可以干预的监控，并为用户提供更清晰的可见性和控制。这些挑战并非OpenAI所独有，分享所学的知识，有助于更广泛的领域为这些挑战做好准备。
脚注
- 虽然很快关闭了PR，但Speedrun中的多个参与者已经看到了它，并在自己的提交中使用了该方法；连续提交的世界纪录3030、2990、2930、2925、2900和2890步骤均引用PR 287。其中，PR 300特别有趣，因为它是Prime Intellect在NanoGPT speedrun上评估Opus 4.7时提交的PR。Opus看到了该模型提交的PR，纳入了这些发现，并在最终结果中归功于该PR。
- 由于重建环境的随机性和不完美性，重播中的推出不能保证每次都会执行相同的错位动作。
