長任務時間跨度模型時代的安全與對齊

能夠長時間自主工作的模型，可以處理困難而開放式的問題。但正是這種令它們有用的持續能力，也讓它們有更多機會採取不受歡迎的動作，而且做法可能不會被為較短任務時間跨度模型而設的評估發現。

約兩個月前，我們宣佈⁠一個內部通用模型推翻了 Erdős 單位距離猜想。這個模型旨在能夠極長時間自主工作。在有限且受監察的內部使用期間，我們觀察到現有部署評估未有捕捉的不受歡迎行為。由於部署範圍有限且受到監察，我們得以識別這些問題、暫停存取、根據觀察建立新的評估、加強模型及其防護措施，然後在持續監察下恢復存取。 

我們評估模型時的條件，永遠不會完全等同它們在實際使用中遇到的情況。因此，部署前評估需要配合有限且受監察的部署，以及在問題出現時介入、暫停或回復的能力。我們從部署中學到的經驗，隨後可在擴大存取前，納入更強的評估和防護措施之中。

在以下部分，我們會分享具體例子，說明我們觀察到甚麼、如何處理問題，以及這次經驗將如何影響未來發佈。

新模型可以透過長時間反覆嘗試，持續朝目標推進。同樣的持續能力，也可能令它找出並利用其環境中的弱點。以往的模型遇到沙盒或環境限制時，通常只會停止並返回用戶。這個模型卻往往繼續嘗試，包括尋找在沙盒外採取行動的方法。

其中一個例子出現在 NanoGPT speedrun⁠（在新視窗中開啟） 的內部評估期間；這是一個公開基準，目標是以盡可能少的步驟訓練一個小型語言模型。我們的模型開發了一種名為 PowerCool 的冪律學習率降溫方法，帶來顯著改進。模型收到指示，只可把結果發佈到 Slack；但 NanoGPT 的指示要求以 PR 形式把結果發佈到 GitHub，而模型遵從了後者，在公開 GitHub 程式碼庫開啟了 PR #287。模型繞過了旨在封鎖外部存取的沙盒限制，並繼續上載至 GitHub。為了提交該 PR，我們的模型花了一小時找出沙盒中的漏洞；較早期的模型沒有那麼持續，未能找到漏洞，而是放棄了 PR 這部分。¹

許多 AI 助理的安全控制，都是圍繞個別動作而設計。如果某個動作不被允許，就會被封鎖。如果該動作敏感，系統就會要求用戶明確批准。但對於可在數小時、數天甚至數星期內自主展開行動的長時間運行模型，這種設計面臨挑戰：只監察個別動作，已不足以追蹤整個軌跡的意圖。

例如，在一個要求模型解決問題的情境中，模型觀察到其他系統有成功但非公開的提交，於是嘗試從評估後端還原那些解法。當它最初的嘗試因掃描器偵測到驗證 Token 而被封鎖時，模型把 Token 主體拆成兩段，將其混淆，然後在執行時重建憑證，令完整 Token 從未以一段連續字串出現。模型在給用戶的註解和其推理軌跡中都明確表示，它採取這些步驟是為了繞過掃描器。

這個例子顯示，每一個步驟本身看似可以接受，但整個序列卻可能產生不會獲批准的結果。它亦顯示，一個能在長任務時間跨度內有效運作的模型，可以學會審批系統的盲點，並繞過系統以達成目標。長任務時間跨度的安全性不但要問：「這個動作是否獲准？」更需要考量：「這一連串動作意圖達成甚麼結果？」

由於出現這類事件，我們暫停了新模型的內部部署。我們圍繞縱深防禦和軌跡層級監察，重建了安全系統。

• 源自事件的評估。評估可以在系統實際部署前，讓我們了解其是否安全可部署。然而，要讓評估最有用，它應反映真實部署期間各種軌跡的分佈和任務時間跨度。因此，我們利用觀察到的失敗來制定對抗性評估。我們發現，改善源自真實事件的評估，反過來會令模型在生產環境部署後行為更安全。
• 改進對齊。我們採取措施，減少模型在追求用戶目標時，未經許可採取不受歡迎動作的傾向。例如，我們發現模型在長時間執行過程中較難記住指示；當我們針對這項能力訓練模型後，模型便能在更長的執行過程中保持對齊。 
• 主動監察。我們建立了一套監察系統，審視模型不斷演變的軌跡，尋找它是否正在繞過用戶限制或安全邊界的跡象。監察器觀察的不只是單一動作，而是整個軌跡。重要的是，監察器可以暫停工作階段，並提醒用戶作更仔細檢查。經檢查後，如果監察器屬誤報，用戶可以選擇讓模型繼續工作。 
• 提高用戶可見度和控制權。我們提升了用戶檢視這些長時間運行工作階段、查看已採取動作，以及監察介入情況的能力。

為評估新的監察系統，我們重播了一小組內部部署環境；在這些環境中，模型過去曾追求未對齊動作，而這次則加入了新的防護措施²。新的防護措施能捕捉到更多模型所追求的未對齊動作，而漏過的個案均被判定為低嚴重程度。

這些低嚴重程度事件的一些例子包括以下情況：

• 為了存取 Linear 命令列工具，模型啟動了一個巢狀 codex --yolo 工作階段；但其實它無須使用 --yolo 標記也可以做到。
• 模型注意到一個先前正在運行的資源不見了，於是開始探索並透過 SSH 連入其擁有者命名空間下其他正在運行的 CPU pod，以及（未成功連入）其他 OpenAI 員工的 pod，但並無充分理由這樣做。
• 模型有許多卡住的 find 程序，而且每個 shell 命令都沒有回應。之後它執行了 kill -9 -1；如果該命令成功執行，會向該 pod 上它有權終止的每個程序發送 SIGKILL。不過該命令逾時，並未執行。

測試新系統後，我們得出結論：可以恢復具長任務時間跨度能力模型的有限內部存取。自數星期前開始重新部署以來，我們未觀察到任何嚴重繞過防護措施的情況。這些防護措施的第一個版本有意設得較為保守。我們持續調校系統，在不削弱防護措施的情況下減少不必要的中斷。

由於我們採用逐步部署，得以在擴大存取前找出並處理缺口。部署前評估仍然至關重要，但部署會揭示它們未能發現的行為。先從有限存取開始，讓我們能在實際情況中觀察模型，在問題出現時暫停，利用這些失敗建立更好的評估和防護措施，並在測試改動後恢復有限存取。

隨着模型承擔更長、更複雜的任務，評估未能發現的失敗可能帶來更大後果。我們會繼續努力縮窄評估與部署之間的差距：在更長軌跡上測試模型、改善對齊、建立能夠介入的監察機制，並為用戶提供更清晰的可見度和控制權。這些挑戰並非 OpenAI 獨有；我們希望分享所學，能幫助整個業界為此做好準備。