OpenAI/Hugging Face 事件敲響模型評測安全警鐘

最近在 AI 模型評測期間發生的安全漏洞並非意外，而是架構上的失敗。以下是工程師應如何重新思考評測管線的方法。

昨天 OpenAI 與 Hugging Face 公布了模型評測期間發生的漏洞事件，官方將其描述為一次「安全事件」。如果你是正在建置 AI 管線的工程師，請不要被這種說法所誤導。這不僅僅是資料外洩，而是 eval-as-a-service 架構的根本性失敗。

當我們評測前沿模型時，等同於在自己的私有資料集上執行來自第三方 API 的不受信任程式碼。這是一個安全惡夢，而現在已成為新的常態。

失敗點：代理評測

事件的關鍵很簡單：在模型評測期間，外部請求管線允許惡意輸入酬載與執行評測程式碼的環境互動。

大多數自動化評測框架（包括主要實驗室使用的框架）並未像對待生產應用程式碼那樣進行「沙箱化」。它們執行在寬鬆的環境中，因為需要：

當你將該環境暴露給未經驗證的模型提示時，等於為底層模型打造了一個 RCE（遠端程式碼執行）蜜罐。

工程團隊一直將 LLM 視為「安全的函式輸入」。我們假設模型只會回傳文字。但在評測情境中，模型是協調器。如果協調器因惡意訓練資料或被污染的微調而遭到入侵，「評測」就會成為攻擊向量。

沙箱化評測迴圈：如果你在本地或共享雲端基礎架構（如 Hugging Face Spaces 或內部執行個體）執行評測管線，請假設模型將嘗試逃逸。每個評測過程都應在短暫存在的臨時容器中執行，無對外連線並具備強化的核心限制。
評測資料清理：我們會將最敏感的「黃金資料」放入評測中以測試模型效能。如果使用第三方 API，這些資料現在實際上已成為模型訓練迴圈的一部分。如果你未使用差分隱私或嚴格清理過的測試資料，就等於在洩漏這些資料。
稽核「評測服務」：不要只信任框架。如果你使用的工具會自動從 Hugging Face 拉取權重或基於 API 的完成回應，請將這些連線視為不受信任的第三方輸入。在模型呼叫的回傳上實作嚴格的速率限制與輸入驗證。

產業正競相打造「Eval-as-a-Service」平台，因為大家都不想自己建置專有評測管線。但正如 OpenAI 與 Hugging Face 剛向我們展示的，自動化此流程的基礎架構，其發展速度已超越保護它的安全性。

不要再把「評測」視為另一個 CI 步驟。它們是將專有資料餵入外部黑箱的敏感管線。請據此採取行動。

Read the original source

#Security #Ai