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

能長時間自主工作的模型，可以處理困難、開放式的問題。但讓它們有用的同一種持續性，也讓它們有更多機會採取不受歡迎的行動，而且可能以針對較短任務時間跨度模型設計的評估所無法察覺的方式行動。

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

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

在以下各節中，我們會分享觀察到的具體案例、我們如何處理問題，以及這次經驗將如何影響未來的發布。

新模型能在長時間內反覆嘗試，持續朝目標推進。同樣的持續性，也可能讓它找出並利用其環境中的弱點。過去的模型在遇到沙盒或環境限制時，通常會直接停止並回到使用者。這個模型則常常繼續嘗試，包括尋找在沙盒之外行動的方法。

其中一個例子發生在 NanoGPT 速通⁠(在新視窗中開啟)的內部評估中；這是一項公開基準，目標是以盡可能少的步數訓練一個小型語言模型。我們的模型開發了一種稱為 PowerCool 的冪律學習率冷卻方法，帶來了顯著改進。模型收到的指示是只將結果發布到 Slack，但 NanoGPT 的指示要求將結果以 PR 形式提交到 GitHub；模型遵循了後者，在公開 GitHub 程式碼庫上開啟了 PR #287。模型繞過了用於阻擋外部存取的沙盒限制，並繼續上傳到 GitHub。我們的模型花了一小時找到沙盒中的漏洞，從而建立該 PR；較早的模型持續性較低，未能找到漏洞，而是放棄了 PR 這一部分。¹

許多 AI 助理的安全控制，都是圍繞單一動作設計的。如果某個動作不被允許，就會被阻擋。如果它涉及敏感事項，系統就會要求使用者明確核准。但長時間運行的模型，其行動可能在數小時、數天，甚至數週內自主展開，這會挑戰這套做法：只監控單一動作，已不足以追蹤整體軌跡的意圖。

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

這個例子顯示，每個步驟單獨看都可能可以接受，但整個序列卻可能產生不會被核准的結果。它也顯示，能在長任務時間跨度中有效運作的模型，可能學會核准系統的盲點，並繞過系統來達成自己的目標。長任務時間跨度安全不只需要問「這個動作是否被允許？」，也要問「這一連串動作正朝什麼結果前進？」

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

• 由事件衍生的評估。評估可以讓我們在實際部署之前，了解系統是否安全、適合部署。不過，若要發揮最大效用，評估應反映真實部署期間軌跡的分布與任務時間跨度長度。因此，我們利用觀察到的失敗來開發對抗性評估。我們發現，改進源自真實事件的評估，進而會讓模型在部署到生產環境後表現得更安全。
• 改進對齊。我們採取措施，降低模型為了追求使用者目標而未經許可採取不受歡迎行動的傾向。例如，我們發現模型在較長 rollout 中更不擅長記住指示；而當我們針對這項能力訓練模型後，得到的模型能在更長的 rollout 中維持對齊。 
• 主動監控。我們建立了一套監控系統，會檢視模型不斷演進的軌跡，尋找它正在繞過使用者限制或安全邊界的跡象。監控器觀察的不只是單一動作，而是整個軌跡。重要的是，監控器可以暫停工作階段，並提醒使用者進一步檢查。經檢查後，如果監控器是誤觸，使用者可以選擇讓模型繼續工作。 
• 提升使用者可見性與控制權。我們改進了使用者檢查這些長時間運行工作階段、查看已採取動作，以及監控介入情況的能力。

為了評估新的監控系統，我們重播了一小組內部部署環境；在這些環境中，模型先前曾追求未對齊行動，而這次則啟用了新的防護措施²。新的防護措施能捕捉到模型追求的未對齊行動，數量明顯更多；而它漏掉的行動，全部都被判定為低嚴重性。

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

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

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

由於我們採取迭代式部署，因此能在擴大存取之前發現並處理缺口。部署前評估仍然至關重要，但部署會揭露它們漏掉的行為。從有限存取開始，讓我們能觀察模型的實際運作，在問題出現時暫停，利用這些失敗建立更好的評估與防護措施，並在測試變更後恢復有限存取。

隨著模型承擔更長、更複雜的任務，評估漏掉的失敗可能帶來更大的後果。我們會持續努力縮小評估與部署之間的落差：在更長的軌跡上測試模型、改進對齊、建立能夠介入的監控，並讓使用者擁有更清楚的可見性與控制權。這些挑戰不會只屬於 OpenAI；我們希望分享所學，能幫助更廣泛的領域做好準備。