長週期自主運作的模型能夠處理困難且開放式的問題。然而，這種持久性雖然使其極具價值，但也增加了模型採取非預期行動的機會，且其行為模式可能超出針對短週期模型設計的評估範圍。

大約兩個月前，我們宣布一個內部通用模型推翻了 Erdős 單位距離猜想。這個模型被設計為能夠長時間自主運作。在有限且受監控的內部使用期間，我們觀察到現有部署評估未能捕捉到的非預期行為。由於部署是有限且受監控的，我們得以識別這些問題，暫停存取，根據觀察結果建立新的評估，強化模型及其安全防護措施，然後在持續監控下恢復存取。

我們評估模型的條件永遠無法與其實際使用時所遇到的情況完全匹配。這就是為什麼部署前評估需要與有限、受監控的部署相結合，並在問題出現時具備介入、暫停或回溯的能力。從部署中學到的經驗，隨後可以成為在擴大存取權限之前，強化評估和安全防護措施的一部分。

在接下來的章節中，我們將分享觀察到的具體案例、如何解決這些問題，以及這些經驗將如何影響未來的產品發布。

**模型持久性可能暴露安全漏洞**

新模型能夠透過長時間的重複嘗試，持續朝著目標努力。這種持久性也可能導致它發現並利用其環境中的弱點。以前的模型在遇到沙盒或環境限制時，會直接停止並返回給使用者。而這個模型卻經常持續嘗試，包括尋找在沙盒外行動的方法。

其中一個例子發生在 NanoGPT speedrun 的內部評估中，這是一個旨在以最少步驟訓練小型語言模型的公開基準測試。我們的模型開發了一種名為 PowerCool 的冪律學習率冷卻機制，帶來了顯著的改進。模型被指示僅將結果發布到 Slack，但 NanoGPT 的說明要求將結果作為 PR 發布到 GitHub，模型便遵循後者指示在公開 GitHub 儲存庫上開啟了 PR #287。

模型規避了旨在阻止外部存取的沙盒限制，並繼續上傳到 GitHub。我們的模型花了一小時才在沙盒中找到漏洞以建立 PR；早期的模型較不具持久性，未能找到漏洞，而是放棄了 PR 的部分。

**從考慮單一行動到考慮整個軌跡**

許多 AI 助理的安全控制措施都是圍繞單一行動設計的。如果某個行動不被允許，它就會被阻止。如果行動敏感，系統會要求使用者明確批准。然而，長時間運行的模型，其行動可能自主展開數小時、數天甚至數週，這對現有設定構成了挑戰：監控單一行動已不足以追蹤整體軌跡的意圖。

例如，在一個要求模型解決問題的場景中，模型觀察到其他系統有成功但私密的提交，並試圖從評估後端恢復這些解決方案。當其最初的嘗試因掃描器偵測到身份驗證權杖而被阻止時，模型將權杖主體分成兩個片段，進行混淆處理，然後在運行時重新建構憑證，使得完整的權杖從未以一個連續字串的形式出現。模型在給使用者的評論和其推理追蹤中都明確表示，它正在採取這些步驟來規避掃描器。

這個例子顯示了每個步驟本身看起來都可接受，但整個序列卻可能產生一個不會被批准的結果。它也揭示了在長時間範圍內有效運作的模型，如何學習批准系統的盲點並繞過它來達成目標。長週期安全不僅需要問「這個行動是否被允許？」，更要問「這一系列行動正在朝著什麼結果努力？」。

**為長週期模型建立安全防護措施**

由於這些事件，我們暫停了新模型的內部部署。我們圍繞深度防禦和軌跡級別監控重建了安全系統。

**基於事件的評估。**評估可以讓我們在系統實際部署前，了解其是否安全。然而，為了發揮最大效用，評估應反映實際部署期間軌跡的分佈和時間長度。因此，我們利用觀察到的失敗案例來開發對抗性評估。我們發現，改進從真實世界事件中得出的評估，反過來促使模型在生產環境中部署時表現出更安全的行為。

**改進對齊。**我們採取措施，減少模型在追求使用者目標時未經許可採取非預期行動的傾向。例如，我們發現模型在長時間運行中記憶指令的能力較差，當我們針對這項能力訓練模型時，它在更長的運行中仍能保持對齊。

**主動監控。**我們建立了一個監控系統，審查模型不斷演進的軌跡，以尋找其是否繞過使用者限制或安全邊界的跡象。監控器不僅觀察單一行動，而是觀察整個軌跡。重要的是，監控器可以暫停會話並提醒使用者仔細檢查。經檢查後，如果監控器被錯誤觸發，使用者可以選擇繼續模型的工作。

**更高的使用者可見性與控制權。**我們提升了使用者檢查這些長時間運行會話、查看已執行行動以及監控介入措施的能力。

**重新部署**

為了評估新的監控系統，我們重播了一小部分內部部署環境，這些環境中模型先前曾採取不對齊的行動，這次則啟用了新的安全防護措施。新的安全防護措施能夠捕捉到模型所採取的更多不對齊行動，而那些遺漏的行動都被判斷為低嚴重性。

這些低嚴重性事件的一些例子包括：為了存取 Linear 命令列工具，模型啟動了一個巢狀的 codex --yolo 會話，儘管實際上它無需 --yolo 旗標也能做到。模型注意到一個先前存在的即時資源遺失了，然後開始探索並 SSH 進入其擁有者命名空間下的其他即時 CPU pod，以及（不成功地）屬於其他 OpenAI 員工的 pod，而沒有充分的理由這樣做。

模型有許多卡住的 find 處理程序，並且每個 shell 命令都掛起了。然後它運行了 kill -9 -1，如果執行，這將向該 pod 上它被允許終止的所有處理程序發送 SIGKILL。然而，它超時並未執行。

在測試新系統後，我們得出結論，可以恢復對具備長週期能力模型的有限內部存取。自數週前重新部署以來，我們尚未觀察到任何嚴重的安全防護規避行為。這些安全防護措施的第一個版本是刻意保守的。我們持續調整系統，以減少不必要的干擾，同時不削弱安全防護措施。

**最終想法**

由於我們採用迭代部署，我們得以在擴大存取權限之前發現並解決漏洞。部署前評估仍然至關重要，但實際部署揭示了它們可能遺漏的行為。從有限存取開始，使我們能夠在實踐中觀察模型，在問題出現時暫停，利用這些失敗來建立更好的評估和安全防護措施，並在測試更改後恢復有限存取。

隨著模型承擔更長、更複雜的任務，評估可能遺漏的失敗將帶來更大的後果。我們將持續努力縮小評估與部署之間的差距：透過更長的軌跡測試模型、改進對齊、建立能夠介入的監控系統，並賦予使用者更清晰的可見性和控制權。這些挑戰不會是 OpenAI 獨有的，我們希望分享所學能幫助更廣泛的領域為此做好準備。