OpenAI 上線結構化輸出：API 響應 100% 遵從 JSON Schema

很多寫過大模型介面的開發者，最頭疼的事其實很樸素：你明明在 Prompt 裡千叮嚀萬囑咐「嚴格輸出 JSON，不要任何廢話」，大模型卻冷不丁給你多加個逗號，或者少給一個關鍵欄位，直接讓下游解析程式碼當場報錯崩潰。

OpenAI 終於對這個痛點動刀了。8 月 6 日，OpenAI 在 API 中正式推出「結構化輸出」（Structured Outputs）功能，讓大模型的輸出結果能夠 100% 嚴格貼合開發者指定的 JSON Schema。

伴隨這項功能上線的，還有最新的模型 gpt-4o-2024-08-06。在複雜的 JSON Schema 基準測試中，之前的 gpt-4-0613 準確率連 40% 都不到，而新模型配合結構化輸出直接拿下了 100% 的滿分。

告別反覆重試，從底層堵死格式錯誤

去年 OpenAI 搞過一個「JSON mode」，雖然能確保吐出來的是合法 JSON，但它管不住模型漏欄位或者把欄位型別搞錯。過去一年裡，開發者為了穩定接入系統，只能靠寫冗長的提示詞、引入各種開源驗證庫，甚至一旦報錯就寫迴圈重試程式碼。

這次 OpenAI 提供了兩種呼叫方式。第一種是針對函式呼叫（Function calling），在函式定義里加上 strict: true 即可，老款的 gpt-4-0613 和 gpt-3.5-turbo 往後的模型都能直接用。第二種是在 response_format 裡傳入 json_schema 並開啟 strict: true，支援剛釋出的 gpt-4o 新版以及上個月推出的 gpt-4o-mini。

為了幫開發者省事，官方的 Python 和 Node SDK 已經原生支援了這個特性。你可以直接把 Pydantic 模型或者 Zod 物件扔進去，SDK 會自己轉成 JSON Schema 並完成反序列化。

安全拒答也沒有被忽略。如果模型判斷請求違規，它不會硬套格式胡說八道，而是在返回中帶上明確的 refusal 欄位，方便你的業務邏輯捕獲處理。

為什麼模型這次真能拿 100%？

大模型本質上是個機率機器，單靠調優訓練根本做不到百分之百嚴謹。OpenAI 坦白說，光靠給模型做複雜 Schema 訓練，準確率最高也只能堆到 93%。

要徹底解決問題，他們選擇在底層推理引擎上做工程攔截，也就是「約束取樣」（Constrained Decoding）。系統會把開發者傳進來的 JSON Schema 轉換成上下文無關文法（CFG）。

模型每吐出一個 token，推理引擎就會即時算出下一個位置符合語法的合法 token 集合，把所有非法 token 的取樣機率直接壓到 0。只要下一個 token 不可能選錯，整個輸出格式就絕不會翻車。

業內做約束解碼很多是用有限狀態機（FSM）或正規表示式，但 OpenAI 選了 CFG。這樣做的聰明之處在於能夠支援遞迴結構，比如生成樹狀 UI 元件或巢狀任務清單時，FSM 很難準確匹配深層括號，而 CFG 輕鬆搞定。

不過這項技術也有代價。首次傳入新 Schema 時，系統需要做語法預處理和快取，第一次呼叫通常要多花幾秒到十秒，極其複雜的 Schema 甚至要等上一分鐘。此外它目前只支援 JSON Schema 的一個子集，而且無法相容並行函式呼叫。

為什麼重要

在很多人的印象裡，給 API 增加一個格式約束只是小修小補，但我們認為，這是把大模型從「玩具聊天框」推向「企業級自動化基礎設施」最硬核的一步。

對開發者和產品團隊來說，價值是立竿見影的。以前做一個多步驟的 AI Agent 工作流，最怕中間某一步模型吐錯了格式導致整條流水線卡死；為了容錯，工程團隊要寫大量的清洗、校驗和兜底程式碼。現在這一整套防禦性工程基本上可以砍掉，開發成本和呼叫延遲都會大幅下降，現在就值得去把核心業務切換過來。

對行業而言，這一步直接掐斷了一大批專門做結構化輸出外掛庫的生存空間。OpenAI 把約束解碼直接做進推理引擎的底層排程中，不僅效率高得多，還依託自身算力完成了基礎設施級的壟斷。

但需要看清的是，結構化輸出保住了「殼」，保不住「核」。它能保證欄位名叫什麼、格式對不對，卻防不住模型在欄位值裡胡編亂造，比如算錯公式或給出虛假的答案。把確定性的工程規則與非確定性的模型核心結合，大模型的企業級可用性確實邁了一大步，但最終的內容質量，依然要看模型本身的推理上限。