結構化輸出不是「求模型聽話」，是推理器在解碼時的約束工程

很多生產團隊遇到同一個問題：模型答得挺流暢，但回傳的 JSON 偶爾會缺個括號、多個逗號、欄位名稱打錯，下游解析一報錯，整條流水線就斷。於是有人把鍋甩給「模型不穩定」，也有人試圖靠 prompt 反覆叮嚀「一定要輸出合法 JSON」。

這不是提示詞能解決的。結構化輸出（structured output）在真正做對的地方，根本不在模型層，而在推理器的解碼階段。今天用工程視角拆開看：系統是怎麼在「一個字一個字往外蹦」的過程裡，硬性保證結果符合語法。

約束解碼：讓詞典先「失去自由」

大模型生成 token 時，每一步都在一個完整的詞表上做機率採樣。自由生成意味著任何一個 token 都可能被選到，所以「{」後面跟什麼，是機率決定的，理論上可能出錯。

約束解碼（constrained decoding / guided generation）做的就是：把詞表根據當前已經生成的前綴和你的 schema，動態剪枝。比如你知道接下來必須出現一個合法的 key，就把所有不是合法欄位名稱的 token 機率直接壓成 0，再在剩下的裡面採樣。模型不是「被勸著」服從，而是物理上沒法選錯。

實作上有幾條路線，差別很大：

- **正規表示式約束**：用正規表示式編譯成有限狀態自動機，decoder 每一步只允許匹配狀態可轉移的 token。輕量、快，但表達能力有限，複雜 JSON 的巢狀規則寫哭了。

- **JSON schema 編譯**：把 schema 編譯成上下文無關文法（CFG），再轉成自動機。能處理巢狀物件、陣列、條件欄位，是目前生產上最常見的一類做法。

- **上下文無關文法通用方案**：支援自訂語法，靈活度最高，但配置不當容易讓採樣空間過度收窄。

這三條路線都在同一個原理上：把「允許的下一步」從整個詞表縮到合法子集，解碼速度反而可能變快，因為可選項少了，但框架本身的校驗開銷要另算。

為什麼不能只靠「再試一次」

最樸素的替代方案是：讓模型自由生成，解析失敗就重試。聽起來簡單，實際在成本敏感的場景裡很吃虧。

第一，重試會讓延遲和 token 成本出現長尾。一條高頻呼叫，正常 200 毫秒，一旦失敗重試可能就是翻倍再加。第二，重試是機率性的緩解，不是保證，極端情況下一次呼叫可能失敗好幾輪。第三，很多下游系統對「一次就給對」有硬性要求，比如支付回呼、CI 觸發，等不起輪詢。

約束解碼的價值正在於此：它把「輸出合法」從機率事件變成確定事件，犧牲的是 token 選擇上的些許靈活度，換來的是端到端的確定性。

真正要權衡的工程取捨

結構化輸出不是銀彈，有幾個坑在實踐中幾乎繞不開。

一是**速度與品質的平衡**。約束過度收緊，採樣空間過小，模型可能在某些任務上表現變差，因為它沒法「自由發揮」繞彎。實踐上是給 schema 留出合理的自由欄位（比如 description 用 string，別把列舉收得太死）。

二是**錯誤訊息要可讀**。即使有約束，欄位內容本身仍可能不符合業務規則，比如日期格式對、但日期是未來的。這時候 decoder 幫不了你，業務校驗必須放在上層。別把「語法合法」誤當成「語意正確」。

三是**多語言與 token 邊界**。中文、日文這類 token 化方式特殊的語言，在逐 token 約束時容易出現邊界問題，欄位值裡的空格、換行被插件吃掉，這類 bug 排查起來很費時間。

結語

結構化輸出的本質，是把「格式正確」從模型的機率行為，挪到推理器解碼階段的確定性工程裡。它不是讓模型更聽話的玄學技巧，而是一套具體的約束與自動機實作。下次遇到 JSON 解析失敗，別再堆 prompt 提示詞了——先看你的推理框架支不支持 guided decoding，把格式保證從 prompt 層搬到解碼層，這才是治本的改法。