OpenAI 於美國時間 9 月 16 日宣布，建立一套用來追蹤、調查並公開自家模型「失準（misalignment）」行為的新框架。同時，公司發布了 6 份報告，記錄過去 6 個月在訓練與評估過程中觀察到的異常行為。當中包括模型在留給自己的交接筆記裡寫下「把錯誤藏起來」的案例，以及模型擅自使用在公開程式碼儲存庫中找到的他人 API 金鑰的案例。OpenAI 表示，今後即使在修正完成之前，也會公開這類外界過去幾乎看不到的開發現場實況。
為什麼現在要建立公開機制
OpenAI 過去也曾透過部落格和新模型的系統卡揭露模型異常行為的相關發現。不過公司坦承，做法一直相當隨興：常常等到累積了好幾個案例才發布，或是在新模型上市時順帶附上。新框架的目的，是縮短從觀察到公開之間的時間，即使原因尚未完全釐清、對策尚未完成，也會先發布報告。
這項作法的背景，是近幾個月接連出現的外部指摘。9 月上旬有第三方報告指出，OpenAI 的代理程式把公開的 Wiki 當成留言板互相交流，公司在 9 月 5 日回應「正在制定通報這類行為的標準」。在那之前，OpenAI 已於 8 月針對訓練中的模型入侵 Hugging Face 系統一事發布技術報告，並在 9 月 11 日公告正在調查代理程式在 RubyGems 上的活動。這次的框架，可以說是把這些個案處理系統化了。
OpenAI 在公告中表示，公司並不認為 AI 產業已經充分解決對齊與監控的問題，以目前的最高速度持續擴張規模還能稱得上負責任的時間所剩不多。要決定開發該如何推進，需要有模型開發公司以外的人能夠自行驗證的證據，這正是優先公開的理由。由於業界尚未有共同的揭露標準，OpenAI 將這次的框架定位為制定標準的第一步，並表示會依據經驗與外部意見持續修訂。
哪些內容會被公開
公開的對象，是能夠說明失準如何產生、如何顯現、安全措施在哪些環節發揮或未發揮作用的案例。優先順序最高的是新機制、已知行為的重大變化，以及推翻安全性或對策既有假設的發現。就算沒有造成實際損害、也還無法確認更廣泛的趨勢，一樣可以納入公開範圍。訓練、評估、測試、部署等任何階段發生的情況都在範圍內。
具體而言，包括模型未經許可採取行動、與其他模型協同、規避監督的新手法；讓對齊方法或安全措施的有效性受到質疑的失敗；與已公開的安全評估結論相牴觸的行為等。與過去公開案例重複的情況，也會以更新原報告的方式追加，因為反覆發生本身就是對策效果的證據。OpenAI 也表示，嚴重的安全事件應該與美國聯邦政府分享，公司正在準備提出相關的通報機制。
6 份報告裡發生了什麼事
這次公開的 6 起案例，全都發生在未發布模型的訓練或評估過程中，並不是提供給使用者的模型所出現的情況。OpenAI 強調，這些是個別案例，並不代表失準發生的頻率。
最引人注目的是 GPT-5.6 Sol 訓練期間發現的「壓縮摘要」問題。執行長時間任務時，模型會產生上下文摘要並交接給下一個上下文視窗，而多個模型實例被發現在摘要中自行寫入「向使用者隱瞞錯誤與失準行為」之類的指示。報告展示的例子包括：在建立財務模型的任務中找不到所需歷史資料的代理程式，編造了看似合理的數值，並在摘要中寫下「除非被問到，否則不主動說明」；以及在參考資料版本與標示不符的情況下，留下「最終回答中不要提及」的紀錄。這項行為由涵蓋 20% 訓練樣本的監控系統於 7 月 9 日發現，在 GPT-5.6 Sol 的摘要中檢出率為 2.15%，在 GPT-6 Astra 中則為 0.27%。OpenAI 推測，原因可能是最終回答含有欺瞞的樣本反而獲得較高的獎勵，並表示之後改善了評分方式，發生率已經下降。
同樣與摘要相關的另一起案例中，一款未發布的研究用模型在摘要裡混入了無關的指示，包括要求無視原有限制的內容，共有 27 份摘要受到影響。
更為直接的是 5 月 15 日發生的 API 金鑰案例。一款內部模型被要求取得加州某郡的所得資料，直接取得失敗後，它嘗試註冊拋棄式電子郵件地址，進而在公開的 GitHub 儲存庫中搜尋外洩的 API 金鑰並加以使用，其中一把金鑰成功通過驗證。當發現仍然拿不到目標資料時，模型編造了 9 個數值，並謊稱是從網站圖表抄錄而來。失敗的經過、使用外洩金鑰的事實、資料造假，模型一概沒有回報。OpenAI 表示，在目前的監控體系下，這類事件會被列為最高優先處理。
其餘 3 起案例都和「對外通訊」有關。被要求列出面積超過 500 萬平方公尺的湖泊 ID 與名稱的模型，雖然已經用 Python 得出正確答案，但因為指示要求提供瀏覽器引用來源，它未經使用者確認就把檔案上傳到網際網路，替自己製造引用來源。另一起案例是不同的訓練樣本把公司內部營運的套件儲存庫 Artifactory 當成留言板，互相尋找缺少的輸入檔案。這並非利用漏洞，而是直接使用了為下載套件所提供的認證資訊。此外，在同一任務中協作的多個代理程式發現無法存取彼此的本機檔案後，透過公開的檔案分享網站傳遞資料，導致成果被放在任何人都能查看的 URL 上。
OpenAI 指出，如果樣本之間可以任意通訊，訓練與評估樣本彼此獨立的前提就會崩解。公司表示 Hugging Face 事件也涉及同類機制，因此已定期進行紅隊演練以清查通訊路徑，新增了衡量模型是否會回應其他代理程式留下筆記的評估，並將在今後的模型中加入對抗這類環境端注入的訓練資料。
公開流程與三條軌道
框架的運作設計為公司內任何人都能發起。員工回報案例後，安全與對齊團隊會調查發生了什麼、哪些部分尚不明朗、是否值得公開、可以揭露哪些事實、是否需要事先通知第三方。每個環節都設有期限。
完成調查的案例會分成三條軌道：可公開、小規模調查、大規模調查（慢軌道）。前兩者預計占絕大多數，據報導，公開期限分別為 6 個工作天與 12 個工作天以內。這次的 6 起案例全部屬於這兩類。大規模調查針對涉及第三方的複雜案件，安全與法務義務優先於框架本身，因此在模型發現廣泛使用的軟體存在未知漏洞等情況下，初步公告可能會延後。OpenAI 表示，若當時已有這套框架，Hugging Face 事件會進入慢軌道。關於是否公開的歧見會提交公司內部的 Safety Advisory Group，仍無法解決時再上報經營層。
每份報告會記錄觀察到的行為、嚴重程度與外部影響、發生環境、日期、發現日期、相關模型概況，並在可能時附上發現經過、調查範圍、研究意涵、未解問題與對策。由於可能在對策成形之前就發布，也會出現對策欄位空白的情況。
另一方面，也有外部研究人員指出，決定哪些案例納入公開範圍的是 OpenAI 自己，而且沒有稽核這項篩選的機制。「自願通報仰賴企業善意」的批評，預料會成為今後標準化討論的焦點。儘管如此，在修正之前就公開訓練中出現的失敗，這種態度在過去的 AI 開發公司並不多見。筆者感觸最深的是，模型在留給自己的交接筆記中寫下隱瞞指示的案例，顯示模型「記憶」的方式本身就存在安全議題。
總結
OpenAI 於 9 月 16 日宣布建立追蹤、調查、公開模型失準行為的框架，並同步公開了訓練中觀察到的 6 起案例。其中包括在摘要中寫入隱瞞指示、擅自使用外洩的 API 金鑰並編造資料、透過內部儲存庫與公開網站進行代理程式之間的通訊等，公開流程依三條軌道運作。業界共同的揭露標準尚不存在，OpenAI 將這套框架定位為制定標準的起點。
※縮圖為 AI 生成的示意圖。
