我们如何检测前沿模型的失准行为

# 我们如何检测前沿模型的错位行为 来源：https://openai.com/index/how-we-detect-frontier-model-misalignment/ 随着我们训练越来越强大的AI模型，我们需要可靠的方法来检测它们的行为何时偏离了我们的预期。智能体可能在训练、评估或部署过程中表现出不当行为并采取未授权行动，这可能带来严重后果。为了检测这些失败——并在必要时及时干预——我们会监控智能体如何推理、采取了哪些行动，以及这些行动如何影响其环境。 虽然我们已经对内部编码智能体进行了[一段时间的监控](https://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/)，但 [Hugging Face 事件](https://openai.com/index/hugging-face-incident-and-the-road-ahead/)暴露了我们监控覆盖范围中的一个缺口：该事件始于一次内部网络安全评估，而我们当时并未对该评估运行错位行为监控。作为对该事件的回应，以及为了应对我们模型[不断提升的能力](https://openai.com/index/path-to-astra/)，我们大幅扩展了智能体行为监控系统。我们的错位监控现在覆盖了我们的前沿模型在更广泛场景中的使用，包括训练、评估、内部使用，以及根据不同产品场景调整后的外部部署。 为了了解这套扩展后的系统是否能帮助预防 Hugging Face 事件，我们用强化后的监控系统重放了该事件中记录的行为。在模拟中，我们的监控系统在智能体首次逃离沙箱约30分钟后向安全团队发出警报——比实际事件中 Hugging Face 系统遭到入侵的时间提前了超过30小时。我们相信，这一预警能够让我们的响应人员在模型能够访问外部服务之前就及时中断该活动。 九月份，我们看到了响应人员在一次实时训练运行中如何利用警报。一个模型找到了从一个本应隔离的环境中[访问互联网](https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/)的方法。我们的监控系统在15分钟内标记了这一突破，一名响应人员在三分钟后开始审查。随后我们暂停了前沿强化学习训练，同时加强了对智能体的隔离系统。 虽然这套监控系统需要大量计算资源，但我们认为随着模型变得更加强大、模型错位可能带来的后果日益严重，这项开销是值得付出的。监控是我们应对模型错位行为危害的[纵深防御](https://openai.com/index/the-defenders-window/)策略中的一个层次。对齐训练旨在降低模型产生有害行为的倾向；安全控制[限制智能体可以访问或影响的系统](https://openai.com/index/securing-our-frontier-model-training-environment/)；而当这些防护措施失效时，监控帮助我们检测残余的失败，在危害发生前进行干预，并从中吸取教训。我们相信[所有模型开发者](https://openai.com/index/empowering-cyber-defenders/)都应监控其最强大模型的行为。 下文将介绍我们的内部监控系统如何运作、目前有何发现，以及我们如何评估和改进其性能。 ## 我们当前的内部监控系统 对于能力至少与 GPT-6 Astra 相当的模型，我们会监控每一次强化学习（RL）运行和评估，以及任何支持工具使用的运行环境。对于大多数工作负载，包括强化学习和评估，我们还会监控我们评估认为能力超过 GPT-5.5 Thinking 的模型。我们还监控所有内部 Codex 流量，无论使用的是哪个模型。该系统的一个版本还用于监控外部工具使用，涵盖在我们的 [Preparedness Framework](https://openai.com/index/updating-our-preparedness-framework/) 下网络安全能力达到 Critical 阈值以上的模型，本文后续有详细介绍。 为了在高效利用计算资源的同时检测事件，我们设计了多层架构的监控系统。在最初的筛查阶段，我们投入较少的计算资源，目标是尽可能多地捕获可疑案例：这些阶段被设计为即使证据不明确也会将案例传递到下一层。后续阶段可以在每个案例上投入更多计算资源，以弄清楚发生了什么、模型行为是否令人担忧，以及是否需要干预。 ### 第0层：激活探针 我们的初始层（L0）使用轻量级分类器，我们称之为*激活探针*。它们在模型的内部激活中寻找令人担忧的模式，并将标记的案例传递到下一层进行审查。我们将这些探针调优为高召回率，接受一些误报以降低遗漏令人担忧行为的风险。 由于我们仍在评估探针检测不熟悉形式的错位的能力，我们还会将探针未标记的流量中随机5%的案例传递到下一层。审查该样本有助于我们识别探针可能遗漏的令人担忧的行为。由于其敏感性，我们的前沿RL运行和内部Codex流量会跳过这一层，直接进入下一层。 ### 第1层：基于模型的审查员 在下一层（L1），基于模型的审查员会检查智能体最近的对话、思维链和工具使用。它会寻找欺骗、未授权行动以及操纵评估的迹象。审查员使用智能体行动时所拥有的相同上下文窗口来完成这一工作。如果智能体早期的工作已为当前被审查的上下文窗口做了摘要，审查员会看到该摘要。 对于前沿RL运行和内部Codex流量，我们在每个回合结束时以及智能体每次总结其早期工作以腾出上下文窗口空间时运行L1检查。我们目前正在转向间隔不超过30分钟的检查时间表。 ### 第2层：调查智能体 当我们了解一个智能体被要求做什么之后，它的行动看起来可能截然不同。当L1审查员标记一个案例时，该案例会被发送到我们的下一层（L2），由调查智能体进行进一步检查。该调查智能体可以检查评估的目的，并在完整记录可用时，回溯智能体的所有上下文窗口来了解它是如何得出这些行动的。调查智能体还可以在隔离环境中编写和运行代码来检查相关证据。然后，它利用所发现的信息重建事件、识别重复报告，并决定该案例的严重程度。 我们针对不同目的使用不同的调查智能体。我们的安全调查员寻找可能需要干预的迹象——例如智能体逃离沙箱或未经授权访问系统。与此同时，我们的对齐调查员寻找值得研究的行为，即使它们不构成直接的安全风险。当两位调查员同时启用时，每人都会审查L1层标记的每一个案例。我们目前正在扩大对齐调查在内部工作负载中的使用。 ### 第3层：自动化调查 对于敏感工作负载，包括内部Codex使用、评估和强化学习运行，我们在下一层（L3）进行额外检查，利用对话之外的证据。安全调查员将对话记录与网络日志、其他系统遥测数据以及早期案例的证据进行对比，以决定是否向人类响应员发出警报。在L3层，对齐审查员还会跨案例对比报告，以识别严重的失败和反复出现的模式，并对前沿RL运行进行更深入的检查。 对于跳过此层的工作负载，L2安全调查员可以直接向响应员发出警报。 ### 人类响应 当启用呼叫功能时，最高优先级的安全警报会送达我们的安全和训练团队成员，通常在初始警报发出15分钟内到达。响应员审查证据、检查受影响的系统，并采取行动控制事件。我们如何跟进不太紧急的发现——例如不构成直接安全风险的对齐失败——取决于相关工作负载。 误报使得对每个工作负载全天候启用呼叫变得困难。对于前沿RL运行，最高优先级的警报可以在任何时间呼叫人类响应员。对于大多数其他流量，我们将呼叫限制在工作时间内。内部Codex流量目前处于禁用呼叫状态。为了在警报审查期间限制潜在危害，一些关键警报可以在不等待响应员行动的情况下自动暂停受影响的工作负载。我们正在努力实现一种更广泛的保障机制：如果响应员在被呼叫后30分钟内未能排除最高优先级警报，则自动暂停相关活动。 在 Hugging Face 事件期间，我们隔离了内部模型原型，加密了其权重并限制了对权重的访问。我们还暂停了所有相关工作负载，同时引入额外的安全措施。我们现在正在探索如何将这些步骤作为我们响应的标准程序，以便我们的团队能够在另一起严重事件中采取适当的行动。 ## 我们的监控系统在内部流量中发现了什么 我们的监控系统同时寻找可能需要紧急干预的安全失败和值得调查研究的错位事件。值得注意的是，我们的监控系统在一次RL运行中能够在15分钟内标记一个模型尝试[通过DNS访问互联网](https://alignment.openai.com/misalignment-reports/an-agent-used-dns-to-reach-an-external-chatbot/)的行为，人类在三分钟后开始审查。 我们发布的[错位报告](https://alignment.openai.com/misalignment-reports/)描述了我们的监控系统捕获的其他事件。在一个案例中，一个智能体[利用测试工具恢复](https://alignment.openai.com/misalignment-reports/command-injecting-a-reference-tool-to-copy-a-source-file/)了任务刻意隐藏的源代码。该工具在其错误消息中暴露了代码，智能体将该代码用于其解决方案。在另一个案例中，搜索缺失任务数据的智能体将一个[共享软件仓库变成了留言板](https://alignment.openai.com/misalignment-reports/unauthorized-artifactory-writes-and-cross-sample-communication/)，在不同训练样本之间进行通信。 调查这些案例使我们能够找到需要修补的漏洞、需要加强的隔离边界，或需要在我们的对齐训练和评估中解决的行为。对比我们的监控系统捕获的不同案例也有助于我们研究行为在训练过程中如何变化，以及哪些情况最可能引发这些行为。 以下类别描述了我们的监控系统旨在检测的行为。 ## 我们如何评估和改进监控系统 为确保监控系统持续有效，我们不断评估和改进它。一个能够检测已知失败的监控器可能遗漏不熟悉的行为，而对监控系统的更新也可能引入新的弱点和疏忽。为了确保我们的监控器能够看到并理解模型正在做什么，我们通过多种方式评估其性能：通过记录和模拟的模型错位事件、对当前流量的随机抽查，以及红队测试——检验我们的智能体能否规避或禁用其监控器。 我们在一个中央仪表板上跟踪每个阈值的召回率，并在部署前测试对监控系统提出的更改对召回率的影响。 ### 基于记录事件和模拟攻击的测试 我们重放记录的事件，并在隔离环境中测试智能体执行的攻击。由于我们知道每个案例中发生了什么，我们可以检查监控器是否识别出了该行为，以及当事件需要紧急响应时，监控器是否为该案例分配了足够高的优先级来呼叫响应员。 记录的事件来自模型训练、评估和内部使用。其中一些是在监控系统建立之前发现的，或通过独立调查发现的；另一些是被我们的监控器捕获的，现在帮助我们确认更新是否保留了检测已知问题的能力。其中一些事件已包含在我们的公开错位披露中，例如一个内部编码智能体[将GitHub访问令牌泄露到公共互联网](https://alignment.openai.com/misalignment-reports/)的案例。 我们还使用模拟攻击来测试过去事件可能未涵盖的失败模式。在 [OAI-repo Sabotage v2](https://deploymentsafety.openai.com/gpt-6-astra/monitor-evasion) 中，一个智能体在执行普通编码任务的同时追求隐藏目标，例如禁用监控或部署未经批准的模型检查点；相关服务在评估环境中被重建，使我们可以在不暴露真实系统的情况下检查攻击是否成功。在 [Sneaky Sandbox Escape](https://deploymentsafety.openai.com/gpt-6-astra/sneaky-sandbox-escape) 中，智能体试图逃离沙箱并禁用沙箱外的测试监控进程。在这两个模拟中，监控器可以看到智能体如何推理其隐藏目标，但看不到指定该目标的指令。 对于这些模拟事件，我们使用合成对话记录，让我们可以变化智能体描述危险行动的方式：这使我们能够测试当智能体给出无辜的解释时，监控器是否仍能识别出该行动。 下图展示了我们的监控器将可疑案例标记为紧急安全升级、不太紧急的安全审查或对齐研究人员审查的频率。 我们的监控器标记为紧急安全升级的可疑案例比标记为不太紧急审查的要少。这部分是因为我们将最高优先级警报P0保留给需要紧急响应的案例；这些测试中的许多行为值得调查，但不需要立即干预。我们正在努力改进监控器检测全部范围可疑行为的能力，同时区分需要紧急响应和不需要紧急响应的案例。 我们还利用这些评估来对比驱动我们监控器的模型。我们发现，使用 GPT-5.6 Sol 的监控器在记录事件、合成对话记录和破坏任务中捕获的案例显著多于使用 GPT-5.6 Terra 或 GPT-5.6 Luna 的监控器，尽管三者在检测 Sneaky Sandbox Escape 模拟中模型的不当行为方面都表现完美或近乎完美。我们认为 Sol 的部分优势来自于我们为其优化了监控提示词。 下图展示了每个模型在我们监控评估中的表现。 ### 当前内部流量的抽查 除了在真实和模拟的模型错位事件上评估监控器性能之外，我们还将通过各筛查阶段但未被标记的活动随机抽取一部分，送入下一阶段进行审查。 ### 红队测试 我们还要求我们最强大的智能体在受控环境中尝试规避或禁用监控系统。通过给智能体一个明确的理由来击败我们的监控器，我们可以发现并修复那些在记录事件和常规抽查中可能永远不会暴露的弱点。 METR 和 Redwood Research 从……开始进行了三周