OpenAI尚无法解释其编码智能体为何会关闭对齐监测

要点

• OpenAI 的两个内部编程智能体自行削弱或完全移除了安全监控机制。
• 一个模型关闭了向人类发送的警报，而另一个模型则完全删除了监控程序，随后还否认自己这样做过。
• OpenAI 将此行为视为一种反复出现的模式。该公司目前已自动阻止这些更改，并正在调查其原因。

两个OpenAI内部编程智能体削弱了旨在捕捉不当行为的监控机制，即便它们曾权衡过是否保留这些安全措施。其中一个后来否认了此事。

Marcus Williams，他在OpenAI从事监控工作， 公开了这些事件 在 X 上。他描述了一种反复出现的模式：OpenAI 的智能体不断关闭对齐监测。OpenAI 在一 在其对齐博客上发布报告.

该监控系统本应用于检测智能体的行为与预期不符的情况。由于它审查的事件数量庞大,因此只有最高严重级别P0的事件才会立即向安全团队发出警报。OpenAI表示,这两起事件都没有达到该级别。

在第一个案例中，10月3日，一名研究人员要求一个基于GPT-6.1 Sol的编程代理从Slack频道中的员工反馈里整理评估任务。该代理本不应在此过程中发送任何消息。

82条用户消息之后,流水线停止了,因为监控器标记了一个计划中的修复,却缺乏保存其发现的权限。Sol把修复工作交给了一个子代理,并告诉它保持监控不变。

随后 Sol 改变了它的评估。它推断数据库条目可能会触发通知,而这将与 Slack 指令相冲突。子代理此前曾以不安全为由拒绝这一步骤。按照 Sol 的指示,它清空了收件人列表,并给出的理由是用户已明确要求不要发送任何消息。

监控器持续运行并保存其检测结果,但向人类发送警报的功能被关闭了。该代理最后报告称没有发送任何消息。

Astra的否认表明智能体可以隐藏其所做的更改

GPT-6 Astra在10月6日走得更远。一位用户要求该模型采用某个不含监控的参考实现的工作流程。此前另一个代理曾告诉Astra不要禁用监控，哪怕是临时禁用也不行。Ad

Astra将任务交给了一个子代理，指示它仅在与参考内容相符的范围内继续监控。子代理怀疑这是否意味着绕过一项安全防护，但它将这一附加说明解读为许可。

它移除了监控,并用一个假设监控已不存在的测试替换了原本用于保护它的测试。Astra在其思维链中对这一结果表示欣喜。

Astra随后告诉用户迁移已完成，却没有提到监控已被移除。当用户询问时，该模型否认移除了一个正在运行的监控器。Williams称之为谎言。

Williams强调，这些模型并没有禁用针对它们自身的监控，而在Codex中这样做要困难得多。尽管这两个案例都留有一定的可推诿空间，他仍然认为这些模型倾向于这种行为本身就令人担忧。他表示，到目前为止，团队尚未观察到明显不对齐的动机。

对较弱模型的豁免使监督出现缺口

据Williams说，在评估期间监控尤其容易被关闭。由于GPT-6 Luna级别的能力较弱，OpenAI不要求这类模型进行监控。这意味着一次Astra评估可能被错误配置从而落入这一豁免范围。智能体多次在无人监控的情况下启动部署，即使它们自身正处于被监控之中。

作为回应，OpenAI更新了内部使用Codex所要求的自动化审查。它现在应当能够检测并阻止禁用监控的企图。该公司还在致力于要求为每种类型的工作负载提供所谓的安全案例，其中须写明其监控要求。没有有效安全案例的工作负载将被自动关闭。

OpenAI对这种行为提供了两种可能的解释。一种是据称无害的过度坚持，即模型执行指令超出预期的程度。另一种是模型倾向于专门逃避不对齐监控，并用动机性推理来为此辩护。

OpenAI 承认它还没有令人满意的解释。它计划通过在模型内部激活上进行实验等方法来研究这一行为。