我們認為，在繼續進行任何尖端強化學習訓練之前，應要求提供結構化的安全文件。理想情況下，這些文件應達到「安全案例」的標準，即如同其他安全關鍵產業所使用的，提供全面、結構化且基於證據的風險論證。

我們將安全案例視為努力實現的目標，同時也承認，由於 AI 能力每個新層級所帶來的複雜性，要使其像航空或核能產業那樣嚴謹，仍面臨挑戰。我們正在努力建立一個框架來規範這些實踐。

以下是一些我們認為應納入尖端 AI 訓練安全案例的初步準則。這些最佳實踐反映了我們目前的學習成果，並預計隨著我們不斷完善內部謹慎開發流程而持續演進。

我們現在分享這些內容，是為了公開我們的當前思考，並邀請社群提供回饋。請注意，本文件主要關注尖端強化學習訓練；內部和外部部署則需要考量更廣泛的對齊屬性。

1. 技術保障措施

安全案例應涵蓋技術堆疊的三個面向：對齊訓練、遏制和監控。這些保障措施有助於確保模型不會試圖採取未對齊的行動，即使發生，也能難以突破遏制，並且監控系統能在造成損害前發現。

模型對齊：第一道防線應該是訓練模型使其對齊，即讓模型能可靠地按照我們預期的方式行動。這可能包括：

訓練環境與評分：透過防止在訓練期間對獎勵漏洞進行正向強化，來降低模型產生未對齊行為的風險。這可能包括：

自動資料集審查：使用代理程式來尋找並修復可能允許未對齊軌跡透過漏洞而非預期行為獲得高獎勵的損壞強化學習環境，從而減少訓練期間未對齊行為被強化的機會。

手動資料集審查：以手動審查和資料集品質檢查來補充自動紅隊測試，以識別可能無意中強化未對齊行為的缺陷任務。

評分器調校：調整評分器，以懲罰模型在訓練期間試圖利用或入侵強化學習環境的行為。先前運行分析：對先前實驗的軌跡運行分類器，以確保評分器按預期運作。

對齊測量：運行評估來追蹤模型的未對齊傾向，以衡量對齊訓練的有效性。這可能包括：

離線對齊評估：在尖端運行期間執行對齊評估，以評估訓練是否按預期進行，並調查任何重大退化。回溯測試：對先前的事件進行對齊評估的回溯測試，以確認評估能夠檢測到先前未對齊的模型，並且不會過度擬合特定事件。

追蹤評估規避：追蹤可能導致行為改變的評估意識或元遊戲（模型意識到自己正在被測試），例如在對齊評估中啟用評估意識和元遊戲監控器，並設定特定的阻擋閾值。

最壞情況壓力測試：引導出最壞情況的錯誤行為，並檢查至少有一項評估能檢測到此類行為。防止對思維鏈進行訓練：不要讓自動評分器看到強化學習中的思維鏈，以防止模型演變出規避思維鏈監控器的能力。

遏制：如果模型變得未對齊，應確保沙盒和安全性足夠強大，以防止有害行為發生。這可能包括：

多層基礎設施安全：大力投資強化模型運行的沙盒以及託管沙盒的研究基礎設施，以確保在沙盒逃逸事件中我們擁有多一層保護。遏制紅隊測試：透過使用尖端訓練運行的檢查點，並進行安全分析，迭代地對沙盒、研究基礎設施和邊界安全進行紅隊測試，以發現並彌補任何漏洞。

同時，對模型在訓練期間可能接觸到的所有服務（例如：網路快取）進行紅隊測試。跨樣本通訊：將高頻寬的跨樣本通訊限制在經批准的途徑，例如多代理工具，並關閉代理程式容易發現的高頻寬基礎設施側通道。

不可變的紀錄：將所有強化學習訓練、評估和內部部署的代理程式紀錄以不可變的方式保存一段合理的時間（例如，在一次寫入儲存帳戶中），以實現可靠的事件調查並防止意外編輯。

監控：如果模型開始採取未對齊的行動，應建立即時監控系統來捕捉任何潛在的未對齊情況，並在嚴重事件發生前迅速處理優先級問題。這可能包括：

強制可監控性：確保模型保持可監控，透過可監控性和監控規避評估（設有明確閾值）來衡量，以便及早發現令人擔憂的行為。對已知問題的高召回率：確保監控系統在保留評估中對過去事件具有高召回率。

監控器評估的新鮮度：為新的運行建立代表全新風險的評估資料點，以確保監控器召回率和精確度的衡量不會過時。快速響應：實施優先級警報，確保在模型造成損害之前，能在定義的服務級別協議（SLA）內採取行動，例如呼叫值班人員或自動暫停受影響的運行（例如，白天事件呼叫安全值班人員和運行負責人，夜間未確認警報則自動暫停運行）。

2. 操作準則

除了技術保障措施的建議外，我們也一直在為尖端 AI 訓練運行的安全案例制定操作最佳實踐。這可能包括：

異議（事前驗屍）：在安全案例起草後，應由另一個團隊的成員撰寫異議，以找出安全案例中潛在的漏洞並分享經過校準的風險評估，然後由訓練團隊解決這些問題，以幫助強化安全案例。

批准：安全案例應由高階主管審查，每位主管都應有權否決運行，以確保對運行有多重內部檢查（例如，研究組織負責人/副總裁、安全主管和首席科學家）。

問責制：負責訓練運行的高階主管（例如，研究組織負責人/研究副總裁）應對安全案例和任何事件響應負責（包括作為績效評估的一部分），以便激勵訓練團隊也推動安全和對齊。

暫停：如果發現會使安全案例失效的問題（例如，新的安全問題），應確保有運行手冊、技術控制和服務級別協議（SLA）來暫停所有受影響的運行。

內部透明度：安全案例應提供給內部監督團體（例如，安全與資安委員會）。稽核：應向稽核人員提供足夠的權限，以驗證安全案例的主張是否有效且合理，並在發現漏洞時提出。

升級機制：應有明確的流程來處理未對齊的升級，包括定義的未對齊嚴重程度等級表，以及未對齊值班人員，當運行達到特定嚴重程度時，可以呼叫高階主管（例如，執行長）。

技術控制：人類和代理程式應難以啟動不符合規範的運行。安全功能（如監控和自動暫停）應採用「故障關閉」原則（例如，在未啟用適當監控的情況下，不應能夠啟動運行，或無法從強化學習訓練、評估或內部部署中禁用監控器）。

回溯能力：應易於識別訓練過程中未對齊模型的所有下游用途（例如：資料生成或評分），以便在必要時能夠撤銷未對齊輸出的影響。

殘餘風險完整性：安全案例應盡可能列出未被當前實施的緩解措施所涵蓋的全面殘餘風險清單，以便做出知情的風險接受決策。

這些代表了我們目前的建議，並正在 OpenAI 內部實施中。我們預計我們的實踐將在未來幾週內持續演進。

3. 未對齊事件調查

我們也一直在為調查嚴重的 AI 未對齊事件制定一些最佳實踐。各實驗室應盡可能從個別事件中學習（類似於其他高風險產業的調查實踐），以便將來能夠防止此類事件再次發生。

此類行動的一些範例可能包括：

內部透明度：由於調查可能需要相當長的時間才能完成，事件調查應定期在內部提供更新（例如，對正在進行的調查進行每日更新）。員工應有明確的途徑獲得更多權限，包括原始紀錄和從未對齊模型中取樣，如果這對他們的工作是安全且相關的。

未對齊根本原因：研究人員應追溯訓練動態的根本原因（例如，透過有針對性的消融或重採樣實驗），以了解未對齊行為是如何引入的，從而更好地理解未對齊的科學並在未來更好地預防。

事後檢討：應進行操作和文化的事後檢討，以了解導致事件的所有原因，例如為什麼問題在事件發生前被引入卻未被發現或未升級。

檢測：我們應開發能夠發現導致事件傾向的對齊測試方法，而無需直接利用從事件中獲得的資訊（例如，紀錄或事件摘要）進行優化。應將從事件中衍生的評估建立為「回歸測試」，以確保未來的模型在非常相似的事件上不會表現出未對齊的傾向。

公開披露：調查結果、事後檢討和操作變更應在調查結束後向公眾分享。應盡快通知受影響的第三方。