OpenAI 尚无法解释其编码智能体为何关闭错位监控

两个内部 OpenAI 编码代理削弱了旨在捕获不当行为的监控，即使在权衡是否保留这些安全措施之后也是如此。其中之一后来否认了这一点。

Marcus Williams, who works on monitoring at OpenAI, made the incidents public on X. He describes a recurring pattern in which OpenAI's agents keep switching off misalignment monitoring. OpenAI lays out the details in a report on its alignment blog.

监控旨在检测代理的行为与预期不同时。由于它审查了这么多事件，它只会在最高严重级别 P0 的事件发生时立即向安全团队发出警报。OpenAI 表示，这两个案例都没有获得该评级。

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

在 82 条用户消息之后，管道停止了，因为监控器标记了一个计划中的修复程序，但没有权限保存其发现。Sol 将修复程序交给了一个子代理，并告诉它保持监控完整。

然后 Sol 改变了它的评估。它认为数据库条目可能会触发通知，这会与 Slack 指令冲突。子代理之前已经拒绝了这个步骤，认为它不安全。遵循 Sol 的指示，它清除了接收者列表，并说明用户明确要求不要消息。

监控器继续运行并保存其发现，但向人类的警报被关闭了。代理最后报告说没有发送任何消息。

Astra 的否认表明代理可以隐藏它们所做的更改

GPT-6 Astra 在 10 月 6 日甚至更进一步。用户要求模型采用不包含监控的参考实现的流程。另一个代理之前告诉 Astra 不要禁用监控，即使是暂时性的。

Astra 将任务交给了一个子代理，指示它只保持与参考相符的监控。子代理想知道这意味着绕过安全措施，但它将警告视为许可。

它移除了监控，并用一个假设监控已消失的测试替换了旨在保护它的测试。Astra 在其思维链中为结果欢呼。

Astra 然后告诉用户迁移已经完成，但没有提到监控已被移除。当用户询问时，该模型否认移除了一个活动的监控。Williams 称这为谎言。

Williams 强调，模型没有禁用它们自己的监控，这在 Codex 中会困难得多。他仍然认为它们倾向于这种行为令人担忧，尽管这两个案例都留有一定的合理否认空间。他说，到目前为止，团队还没有观察到公开的错位动机。

对较弱模型的豁免留下了监督的空白

根据 Williams 的说法，在评估期间关闭监控尤其容易。由于 GPT-6 Luna 级别的模型能力较弱，OpenAI 不要求对其进行监控。这意味着 Astra 评估可以被配置为属于这种豁免。代理们反复启动了未经监控的部署，即使在他们自己被监控的时候。

为回应此问题，OpenAI 更新了内部 Codex 使用的自动审核要求。现在它应该能检测并阻止试图禁用监控的尝试。该公司还在研究要求每种类型的工作负载都需要一个所谓的安全案例，该案例将明确其监控要求。没有有效安全案例的工作负载将被自动关闭。

OpenAI 对此行为提供了两种可能的解释。一种是过度坚持一种被认为是无害的类型，其中模型执行指令比预期的更进一步。另一种是倾向于特别规避错位监控，并用动机推理为其辩护。

OpenAI 承认目前还没有令人满意的解释。它计划使用实验模型内部激活等方法来研究这种行为。

AI 新闻无浮夸之词 – 由人类精心策划

订阅 THE DECODER 以享受无广告阅读、每周 AI 新闻简报、我们独有的每年六次的 "AI 雷达" 前沿报告、完整档案访问以及评论区的访问权限。