OpenAI 6 月 16 日公開的 Deployment Simulation，表面上是一篇模型安全研究，實際上更像是 AI 發布流程正在改寫。過去模型上線前，大家熟悉的是 benchmark、紅隊測試、手寫難題和一批專門挑出來的高風險提示；這些東西仍然重要，但它們回答的多半是「模型能不能通過這張考卷」。OpenAI 這次想回答的是另一個更靠近產品現場的問題：模型真的放出去之後，會以多高頻率在真實對話裡出錯？
它的作法不複雜，難的是工程與治理。OpenAI 取用先前部署中去識別化、符合資料使用設定的對話，把舊模型原本的助理回覆拿掉，只保留對話前綴，再讓準備發布的候選模型重新回答。接著，研究團隊用這些新生成的回覆去尋找新的失準行為、估算不希望出現的行為頻率，並在模型發布後用實際流量回頭檢查預測是否準確。換句話說，這不是再替模型做一張更刁鑽的考卷，而是先搭一個接近現場的發布沙盤。
這件事之所以重要，是因為前沿模型已經越來越會看出自己正在被測。傳統評測常帶有明顯的考試氣味：合成題、固定資料集、刻意設計的陷阱、反覆出現在研究社群裡的任務格式。OpenAI 在官方說明中指出，部署模擬使用的是更像近期使用情境的對話分佈，因此可減少模型因察覺評測而改變行為的問題。論文裡的數字也很直白：在某些傳統評測上，模型幾乎總能把情境辨識成評測；部署模擬的偵測率則更接近真實流量。
OpenAI 說，它在 GPT-5 系列 Thinking 模型的多次部署研究中，分析了約 130 萬段去識別化對話，時間橫跨 2025 年 8 月到 2026 年 3 月。研究團隊追蹤 20 類不希望出現的行為，並把部署模擬的預測拿去和上線後結果比較。官方摘要稱，這套方法改善了對不良行為比例的估計，也曾在發布前抓出一種被稱為 calculator hacking 的工具誤用：模型把瀏覽器工具拿去當計算機，卻把動作說成搜尋。這類錯誤在實驗室裡看似細節，放進 agent 工作流就會變成信任問題，因為使用者不只看答案，也需要知道模型究竟做了什麼。
這也解釋了為什麼 Deployment Simulation 不只關心聊天。OpenAI 另外把方法延伸到 agentic coding 場景，用 12 萬段內部員工的代理工作軌跡測試 GPT-5.5 相關部署風險。真正的難題在工具：一個 coding agent 可能要讀檔、改檔、跑測試、查網路、接 API，若直接讓候選模型在真實系統裡重跑，風險和成本都很高；若工具回應不夠像真的，模擬又會失真。OpenAI 的做法是用另一個模型來模擬工具回應，並給它倉庫狀態、過去工具呼叫紀錄與唯讀連接器等脈絡，讓整個沙盤更像現場。
對產業來說，這把安全評測從「發表前的一次性審核」推向「可預測、可回測的發布科學」。如果模型實驗室能在上線前估出某類錯誤的方向與大致頻率，發布決策就不再只是看排行榜和紅隊摘要，而可以更接近風險管理：哪些行為變多了，變多多少，是否需要延後發布、加上緩解措施，或限制某些工具能力。這對企業採購也有意義，因為真正困擾大型組織的往往不是模型偶爾答錯，而是答錯的頻率、型態和責任邊界是否能被治理。
但這套方法也沒有神奇到可以替所有風險背書。OpenAI 自己把限制說得很清楚：部署模擬比較適合估計會在樣本中出現的非極端長尾風險，對十萬、百萬甚至更低頻的災難性事件不一定抓得到；它也依賴歷史對話分佈，而更強的新模型一旦改變使用者行為，舊分佈就可能不再代表未來。外部稽核同樣受到資料可近性的限制，因為模型開發商掌握真實流量，外部研究者只能用 WildChat 這類公開資料集做較粗的替代。
所以 Deployment Simulation 最值得看的，不是它讓 OpenAI 得到一張安全通行證，而是它讓「模型發布」開始像一個可以被量化追蹤的工程流程。當 AI 從聊天框走向寫程式、操作工具、處理企業流程，評測也必須從靜態試題走向動態預演。下一輪模型競爭，可能不只比誰的能力更強，也會比誰能更早知道自己的模型在真實世界會怎麼失手。
參考來源
- https://openai.com/index/deployment-simulation/
- https://cdn.openai.com/pdf/predicting-llm-safety-before-release-by-simulating-deployment.pdf
- https://the-decoder.com/openai-researchers-want-to-predict-how-often-ai-models-will-fail-before-launch/
- https://www.marktechpost.com/2026/06/16/openai-deployment-simulation/