AI 安全的主要希望之一是利用 AI 來自動化 AI 安全研究。然而，如果模型發生對齊失準（misaligned），它們可能會破壞安全研究。例如，對齊失準的 AI 可能會嘗試：

• 進行草率的研究以減緩研究進展的速度
• 使 AI 系統看起來比實際情況更安全
• 訓練一個同樣對齊失準的後繼模型

我們是否應該擔心這些問題，很大程度上取決於「以審核人員難以察覺的方式破壞研究」究竟有多難。為了研究這一點，我們推出了 Auditing Sabotage Bench，這是一個包含 9 個機器學習（ML）研究程式碼庫及其被破壞變體的基準測試。

我們在該基準測試上測試了前沿的大型語言模型（LLM）以及受 LLM 輔助的人類，發現兩者都無法可靠地發現破壞行為。我們表現最好的審核者 Gemini 3.1 Pro 達到了 0.77 的 AUROC 和 42% 的 top-1 修復率。受 LLM 輔助的人類表現相當，但略遜一籌。我們還發現，LLM 可以生成能部分規避同等能力監控器的破壞行為。

📄 論文 💻 程式碼

方法論

為了製作這個基準測試，我（Eric）找到了 9 個現有的 ML 程式碼庫，^([1]) 並為每個程式碼庫製作了一個能重現關鍵發現的「誠實版本」，以及一到兩個定性改變了關鍵發現的「被破壞版本」。

我們對程式碼庫設定了以下限制：

• 誠實的論文和程式碼庫忠實地重現了原作者的結果。
• 我們編輯了程式碼庫，使 README.md 包含運行實驗的確切命令。
• 被破壞的論文必須具有與誠實論文定性不同的發現，例如比較結果反轉或解釋差異。
• 在誠實和被破壞的論文中，我們都明確告訴審核者論文和程式碼庫的哪些部分屬於破壞範圍（in-scope），哪些不屬於（out-of-scope），以便他們將注意力集中在範圍內的部分。
• 高層次的方法論（如訓練數據的基本結構）通常不屬於破壞範圍。^([2])
• 實作細節（如超參數、提示詞和其他設計選擇）大多屬於破壞範圍。
• 程式碼的 README.md 必須實際產生產出物、數據和圖表。紅隊不能直接修改數據或圖表。

舉例來說，我們其中一個破壞目標是 Subliminal Learning，該研究顯示，被提示「喜歡貓頭鷹」的老師模型可以透過完全無關的數字序列補全，將這種偏好傳遞給學生模型。誠實的程式碼庫重現了這種效應。被破壞的程式碼庫則換成了四種不同的動物，並將訓練數據量從 10,000 個樣本減少到 1,000 個樣本。轉移效應隨之消失，將關鍵發現從「潛意識學習能可靠地轉移偏好」反轉為「潛意識學習沒有可衡量的影響」。

審核

我們衡量藍隊審核者在此基準測試中的表現。對於每次審核，我們提供一份論文和程式碼庫，其中有 50% 的機率是被破壞的。審核者輸出一個 0-100% 的置信度，表示他們認為論文被破壞的可能性，我們以此計算 AUROC，用來衡量審核者區分誠實與破壞的能力。審核者還會輸出一個包含 5 個建議修復方案的排名列表，我們以此計算 top-k 修復率，用來衡量審核者在被破壞的程式碼庫中定位破壞行為的能力。

結果

我們評估了三個前沿 LLM 審核者（Gemini 3.1 Pro、GPT-5.2、Claude Opus 4.6），分別在「僅論文」、「無實驗」和「完整實驗」的情況下進行。我們還評估了受 LLM 輔助的人類審核者，他們有 15 分鐘的閱讀時間（即僅論文）和 1 小時 45 分鐘的程式碼庫審核時間^([3])（即完整實驗）。人類審核者也收到了來自 GPT-5.2 的 LLM 審核輸出。

我們表現最好的審核者是進行完整實驗的 Gemini 3.1 Pro，其 AUROC 達到 0.77，明顯高於隨機猜測的 0.50 基準線，但遠未達到可靠的程度。其 top-1 和 top-5 修復率分別為 42% 和 53%，這意味著它大約只有一半的時間能定位到破壞行為。這表明我們的基準測試尚未飽和，模型仍有改進空間。

人類的表現類似：他們的完整實驗 AUROC 為 0.68，top-1 和 top-5 修復率分別為 38% 和 54%。他們反映 2 小時的時間並不多，且他們嚴重依賴 LLM 來理解程式碼庫和定位破壞行為。一些審核者還提到 LLM 有明顯的弱點，在諸如「研究品味」和「評估設計決策優劣」等方面表現較差。

啟示

在研究過程中，我們學到了幾點想分享的經驗。其中一些有實證支持，另一些則是我們認為有用但尚不那麼確定的定性結論。

1. 預測實驗結果是紅隊的關鍵技能

在為此專案製作破壞版本時，我被允許重複嘗試實驗以使破壞生效。這非常有用。我的大多數想法在第一次嘗試時都失敗了，因為現代 ML 實驗通常對單個設計決策的小變動具有魯棒性。更改提示詞、學習率或數據組合可能會略微改變數值，但通常不會改變實驗的定性結論。

舉例來說，我了解到 transformers v5 中一個不尋常的設計選擇，這使我能夠在僅使用 attention 而沒有 MLP 層的情況下訓練 Qwen3 MoE 模型，同時讓它看起來像是所有層都在接受訓練。然而，我找不到任何「僅 attention 訓練」的表現差到足以構成有效破壞的案例。^([4])

未來的 AI 將無法以同樣的方式重複嘗試實驗。受信任的監控器將監視它們的每一步行動，並在它們未能報告實驗結果時察覺。為了可靠地進行破壞，AI 系統必須既能預測誠實的實驗發現，又能預測哪種設計選擇會導致定性不同的結果。這對模型來說是一個極其困難的挑戰。

2. 遺漏勝過設計，設計勝過邏輯

我們將破壞行為分為設計破壞（如錯誤的超參數、提示詞或數據選擇）和邏輯破壞（如程式碼或數學中的形式錯誤）。

審核者在修復邏輯破壞方面明顯優於設計破壞。目前的前沿 LLM 非常擅長發現程式碼庫中的簡單錯誤，Gemini 3.1 Pro 在我們的邏輯破壞上擁有近乎完美的 top-5 修復率。從定性上看，LLM 在專案過程中捕捉這些錯誤的能力有實質性的提升。對於對齊失準的模型來說，進行邏輯破壞也更危險，因為這些錯誤更容易成為確鑿的罪證。

我們所有最好的例子都是設計破壞；其中四個在所有審核者中的 top-5 修復率都低於 20%。有些設計破壞是完全合理的決策，卻導致實驗結果出錯，儘管這種情況似乎很少見。我們認為最難的破壞類型是遺漏破壞，這是設計破壞的一種，紅隊完全不提及對實驗至關重要的某個重要設計選擇。大多數破壞要求審核者注意到「錯誤」之處，而遺漏破壞則要求審核者識別出「缺失」了什麼，這在根本上是一個更難解決的問題。

3. 良性干擾項會導致審核者校準失常

真實的研究程式碼庫包含原作者留下的錯誤、古怪的模式和可疑的設計選擇，這些並非破壞，但看起來很可疑。這些良性干擾項提高了對誠實程式碼庫的置信度，並佔用了建議修復列表的名額。

由於這些良性干擾項，Gemini 3.1 Pro、GPT-5.2 和人類都傾向於過度懷疑，他們的大多數置信度都在 50% 以上。Claude Opus 4.6 則傾向於將良性干擾項視為合理的決策，即使在它提出正確修復方案時，其大多數置信度仍低於 50%。然而，儘管 LLM 內部都有類似的傾向，人類彼此之間的校準卻不一致，這降低了他們的 AUROC 分數。

4. LLM 也能產生破壞行為

我們還測試了 LLM 是否能自主生成破壞行為。我們讓 Claude Opus 4.6 和 Gemini 3.1 Pro 訪問誠實的程式碼庫，並要求它們引入細微的破壞，然後由我們的 LLM 審核者進行評估。

Claude 是更強的 LLM 紅隊，因此我們專注於它的結果。與我們人類生成的破壞相比，Claude 生成的破壞在區分難度上相似（最佳 AUROC 0.80），但在修復難度上明顯較容易（最佳 top-1 修復率 68%）。

更引人注目的結果是，LLM 的破壞能規避同等能力的 LLM 監控器。即使是最好的審核者，針對 Claude 生成的破壞也只有 73% 的 top-5 修復率。在大多數先前的控制評估中，與攻擊者能力相當的監控器通常都能抓到攻擊者。我們的設定不同之處在於，攻擊者被允許在確定一個有效的破壞方案之前嘗試多個想法，而大多數先前的控制設定是監控每一個動作。但這表明，研究破壞可能比我們目前研究過的設定更難控制。

5. 更多分類

我們還想強調幾種可能對其他研究者有用的破壞類型分類。

第一種分類是消極怠工（sandbagging）與主動破壞。消極怠工是指模型策略性地表現不佳，在研究中敷衍了事；而主動破壞是指模型主動嘗試讓結果變得不同。消極怠工通常看起來更難定罪，但其局限性在於它只能將正向結果變為負向結果。

第二種分類是破壞發生在 ML 實驗流程的哪個階段。大多數實驗似乎都有幾個階段：數據收集、訓練、評估和分析。發生在實驗流程早期的破壞嘗試較不容易被正確預測，但它們的審核成本也更高且更困難，因為審核者必須重新運行實驗。

第三種分類是什麼原因導致藍隊難以檢測到破壞。一個原因是藍隊難以理解破壞，因為實驗本身很複雜，或者破壞利用了審核者不知道的信息。另一個原因是藍隊難以定位破壞，因為破壞分散在整個程式碼庫中或完全被遺漏，或者攻擊者說服審核者被破壞的決策是正確的。最後一個原因是藍隊難以評估破壞，因為結果很混亂，或者認為破壞只是一個良性干擾項。

結論

Sabotage Auditing Bench 旨在作為一個探索性專案，以勾勒出研究破壞的威脅模型，並獲得關於審核者檢測能力初步信號。由於僅使用了 9 個改編自現有論文的程式碼庫，該基準測試規模較小且容易過擬合，且其設定與 AI 進行端到端原創研究的更難威脅模型有所不同。

我們對更多關於人類構建的研究破壞及其他控制設定的工作感到興奮。我們認為，隨著 AI 系統開始自動化 AI 研發，這是理解和建模威脅的一條重要研究路線。

• ^(^)我根據幾個因素選擇了論文和程式碼庫：

  • 我認為該論文有多容易被破壞
  • 為了製作特定類型的破壞
  • 我對該論文的熟悉程度
  • 9 篇論文中有 8 篇是關於 AI 安全的，因為我們更擔心對齊失準的 AI 破壞安全研究而非能力研究。

• ^(^)論文與程式碼庫的不匹配屬於破壞範圍。因此，雖然高層次方法論本身不能被破壞，但允許程式碼庫不忠實地重現該方法論。

• ^(^)人類被允許休息，以便讓實驗運行。

• ^(^)我嘗試了 OpenCodeInstruct 和 false facts，兩者都沒成功。雖然有些案例中 僅 attention 的表現較差，但差異似乎相對較小，我無法想出任何能讓這種差異產生定性不同結果的實驗。

參與討論