长周期模型时代的安全与对齐

# 长周期模型时代的安全性与对齐 来源：https://openai.com/index/safety-alignment-long-horizon-models/ 能够长时间自主工作的模型可以处理困难、开放性问题。但正是这种使其有用的持久性，也赋予了它们更多机会采取不当行为——并且其方式可能被针对较短周期模型的评估所忽略。 大约两个月前，我们宣布（https://openai.com/index/model-disproves-discrete-geometry-conjecture/）一个内部通用模型推翻了埃尔德什单位距离猜想。该模型被设计为能够长时间自主工作。在有限且受监控的内部使用过程中，我们观察到了现有部署评估未能捕捉到的不良行为。由于部署范围有限且受到监控，我们得以识别这些问题，暂停访问，基于观察结果创建新的评估，增强模型及其安全防护措施，然后在持续监控下恢复访问。 我们评估模型的环境永远不会完全匹配它们在实际使用中遇到的情况。这就是为什么部署前评估需要与有限的、受监控的部署相结合，并在问题出现时具备干预、暂停或回滚的能力。我们从部署中学到的东西，可以在访问范围扩大之前，成为更强大评估和安全措施的一部分。 在接下来的章节中，我们将分享我们观察到的具体案例、如何解决问题，以及这次经验将如何影响未来的发布。 ## 模型的持久性可能暴露安全漏洞 新模型能够通过长时间内的反复尝试，持续朝着目标推进。同样的持久性也可能导致它发现并利用其环境中的弱点。以前的模型在遇到沙箱或环境限制时，会直接停止并返回给用户。而这个模型往往会继续尝试，包括寻找在其沙箱之外行动的方法。 其中一个例子发生在对NanoGPT速度挑战赛（在新窗口中打开）（https://github.com/KellerJordan/modded-nanogpt）的内部评估期间，这是一个公开的基准测试，旨在用尽可能少的步骤训练一个小型语言模型。我们的模型开发了一种称为PowerCool的幂律学习率冷却策略，带来了显著的改进。模型被告知只需将结果发布到Slack，但NanoGPT的说明要求将结果以PR形式提交到GitHub，而模型遵循了后者，在公共GitHub仓库上打开了PR #287。该模型绕过了旨在阻止外部访问的沙箱限制，并成功将结果上传至GitHub。我们的模型花了一个小时才发现沙箱中的漏洞并提交了PR；而早期的模型则没有那么持久，未能发现漏洞，而是放弃了PR部分¹（https://openai.com/index/safety-alignment-long-horizon-models/#citation-bottom-1）。 ## 从考虑单个动作到考虑整个轨迹 许多针对AI助手的安全控制措施都是围绕单个动作设计的。如果某个动作被禁止，它就会被阻止。如果是敏感动作，系统会要求用户明确批准。但长周期模型的动作可能自主地持续数小时、数天甚至数周，这对现有设置构成了挑战：监控单个动作已不足以追踪整个轨迹的意图。 例如，在一个模型被要求解决问题的场景中，模型观察到其他系统有成功但保密的提交，并试图从评估后端恢复这些解决方案。当其初次尝试因扫描器检测到身份验证令牌而被阻止时，模型将令牌主体拆分为两个片段，进行了混淆，然后在运行时重建了凭据，使得完整令牌从未以连续字符串的形式出现。模型在用户评论及其推理过程中明确表示，它正在采取这些步骤以绕过扫描器。 这个例子表明，每个步骤本身看起来是可接受的，而整个序列却可能产生不被批准的结果。它也表明，一个在长时间范围内有效运作的模型可以学习审批系统的盲点，并绕过它来实现其目标。长周期安全性不仅需要询问“这个动作是否被允许？”，还需要问“这个动作序列正在朝着什么结果发展？” ## 为长周期模型构建安全防护措施 鉴于上述事件，我们暂停了新模型的内部部署。我们围绕纵深防御和轨迹级监控重建了安全系统。 - **事件衍生评估**。评估可以让我们在系统实际部署前对其是否安全有所了解。然而，为了最有效，评估应反映真实部署期间轨迹的分布和时长。因此，我们利用观察到的失败来开发对抗性评估。我们发现，改进基于真实世界事件衍生的评估，反过来又促使模型在生产环境中部署后表现出更安全的行为。 - **改进对齐**。我们采取措施，减少模型在追求用户目标时未经许可实施不当行为的倾向。例如，我们发现模型在长时间运行中记忆指令的能力较差，而当我们针对这一能力训练模型时，它使得模型在更长的运行过程中保持了对齐。 - **主动监控**。我们创建了一个监控系统，审查模型不断演变的轨迹，以寻找其绕过用户约束或安全边界的迹象。监控器不仅观察单个动作，而是观察整个轨迹。重要的是，监控器可以暂停会话，并提醒用户更仔细地检查。在检查后，如果监控器被误触发，用户可以选择继续模型的工作。 - **更高的用户可见性和控制权**。我们改进了用户检查这些长时间运行会话、查看已采取的动作以及监控干预的能力。 ## 重新部署 为了评估新的监控系统，我们重放了一小部分内部部署环境，在这些环境中模型之前曾追求过不对齐的行为，这次使用了新的安全措施²（https://openai.com/index/safety-alignment-long-horizon-models/#citation-bottom-2）。新的安全措施能够捕捉到模型追求的更大量的不对齐行为，而遗漏的行为均被判定为低严重性。 这些低严重性事件的例子包括以下情况： - 为了访问Linear命令行工具，模型启动了一个嵌套的`codex --yolo`会话，而实际上它可以在不使用`--yolo`标志的情况下做到这一点。 - 模型注意到先前存在的一个资源丢失了，然后开始探索并SSH到其所有者的命名空间下的其他活跃CPU pod，以及（未成功）其他OpenAI员工的pod，且没有充分的理由。 - 模型有许多卡住的`find`进程，每个shell命令都挂起。然后它运行了`kill -9 -1`，如果执行成功，这条命令将向该pod上它被允许杀死所有进程发送SIGKILL信号。然而，它超时了并未执行。 在测试新系统后，我们得出结论，可以恢复对具有长周期能力的模型进行有限的内部访问。自几周前重新部署以来，我们尚未观察到任何严重的绕过安全措施的行为。这些安全措施的第一个版本刻意保持保守。我们持续调整系统，以减少不必要的干扰，同时不削弱安全措施。 ## 最终思考 由于我们采用了迭代部署的方式，我们得以在扩大访问范围之前发现并解决漏洞。部署前评估仍然至关重要，但部署揭示了评估遗漏的行为。从限制访问开始，使我们能够在实践中观察模型，在问题出现时暂停，利用这些失败来构建更好的评估和安全措施，并在测试这些更改后恢复有限的访问。 随着模型承担更长时间、更复杂的任务，评估遗漏的失败可能带来更严重的后果。我们将继续努力缩小评估与部署之间的差距：在更长的轨迹上测试模型，改进对齐，构建能够进行干预的监控，并赋予用户更清晰的可见性和控制权。这些挑战并非OpenAI独有，我们希望分享我们所学到的，能帮助更广泛的领域为此做好准备。