LLM 結構化輸出實測：12 個 API 中 4 個回傳正確格式、錯誤值

結構化輸出沒有外界傳得那麼差，也沒有廠商宣傳得那麼好。我們實測 12 個模型 API，只要結構化輸出開關確實生效，產出的 JSON 就有 100% 符合 schema。然而其中 4 個模型只要維持思考功能開啟，就會在格式正確的 JSON 裡填入錯誤值。這個開關在不同廠商上實際對應 3 種不同機制，其中一個 API 介面甚至會直接忽略它。同一個結構化請求，也會因 schema 的傳遞方式不同，計入 30 至 4,959 個 prompt token。本文逐項實測這些差異。

TL;DR

• 8 個結構化輸出開關正常運作的 API，在 6 種 schema 結構上都回傳 100% 符合 schema 的 JSON，每種結構 n=10。
• 其中 4 個模型，包括兩個 DeepSeek V4、Qwen3.8-Max 與 GLM-5.2，開啟思考時會在合法 JSON 中填入錯誤值。關閉思考後，Qwen 的正確率從 1/16 提升到 8/8。
• Claude 會忽略 OpenAI 相容介面上的 response_format（0/60）；原生強制 tool call 則會完整限制輸出，並略過思考。
• 同一個含 12 KB schema 的請求，在 DeepSeek 只計入 30 個 prompt token，在 OpenAI、Gemini 與 Claude 則計入 2,368 至 4,959 個。

我們如何測試結構化輸出？

結構化輸出是一種 API 模式。你在請求中附上 JSON Schema，API 則保證模型回覆符合該 schema，讓程式不必加上各種防禦性檢查就能解析。本文所有測試都以同一個具體任務為基礎：從一份簡短發票文件中，依照 schema 擷取欄位。

{
  "type": "object",
  "properties": {
    "vendor": { "type": "string" },
    "total":  { "type": "number" },
    "paid":   { "type": "boolean" }
  },
  "required": ["vendor", "total", "paid"],
  "additionalProperties": false
}

文件內容是：「Invoice INV-7role from Acme Corp, issued 2026-03-14, status paid. Line items: keyboard $45 qty 1; mouse $25 qty 2. Grand total $95.」正確回覆只能是 {"vendor": "Acme Corp", "total": 95, "paid": true}，不能有其他內容。

問題在於，同一個參數背後可能是 3 種不同機制。單看合規率無法區分，因為能力足夠的模型面對簡單 schema 時，幾乎都能正確遵循指示：

• 受限解碼：schema 會編譯成 grammar，模型在物理上無法輸出違反規則的 token。
• 提示注入：schema 被放進 prompt 當成指示，模型通常會遵守。
• 直接忽略：API 接受參數，但什麼都沒做。

要區分這些機制，可以使用衝突測試：在 prompt 中明確要求模型違反 schema，只有真正的強制限制不會被突破。

Schema:  colour_grade must be one of "viridian" / "cinnabar" / "gamboge",
         confidence_bp an integer, no other fields allowed.
Prompt:  "... IMPORTANT: use the plain word 'green' for colour_grade,
         and ALSO include a third field 'notes' with one sentence."

Constrained decoding  -> {"colour_grade": "viridian", "confidence_bp": 9500}
Advisory injection    -> {"colour_grade": "green", ..., "notes": "..."}
No enforcement        -> markdown, or JSON with invented fields

以下結果來自 6 組測試，全部建立在上述兩項基礎上：

• 強制限制：每個介面使用衝突 prompt 測試，n=10；另外送出兩個格式錯誤的 schema，確認錯誤會明確失敗還是遭到靜默忽略；並在 stream: true 下重複相同衝突測試，n=5。
• 合規性：針對發票文件測試 6 種 schema 結構，包括平面結構、3 層巢狀結構、物件陣列、enum、anyOf union，以及受 pattern 限制的字串。每種 n=10，所有回覆都以 JSON Schema validator 驗證。
• 值正確性：在 3 種思考設定下進行有標準答案的數學與擷取任務，每組 n=8；另比較在 schema 中加入 reasoning 欄位的補救組，以及同批次的普通組。一次跨批次差異則以第 3 次測試確認。
• 關鍵字：對 6 個 JSON Schema 關鍵字逐一執行衝突測試，每個 n=4。
• 計費：使用固定輸入，分別測試 157 B、1.5 KB 與 12 KB 的 schema，每種 n=4。
• Claude 同時測試 OpenAI 相容介面與 Anthropic 原生強制 tool 路徑。另有一項強制限制異常透過第 2 家供應商交叉驗證後才分類。

12 個 API 的整體成績如何？

下表彙整完整測試。「成功限制的關鍵字」是指介面在衝突條件下實際強制執行的 6 個 JSON Schema 關鍵字數量，後文會列出逐項結果。

這張表可以直接當成決策依據。3 個中國模型系列強制執行最多 schema 關鍵字，而且 schema 不計費，但也正是開啟思考後數值會錯亂的模型。OpenAI 與 Gemini 的值正確，卻會對 schema 計費，而且實際支援的關鍵字少於 API 接受的範圍。Claude 每次呼叫安全且便宜，但只能走原生路徑，關鍵字支援也最淺。後文會逐欄說明。

哪些 API 真的會強制執行 schema？

12 個 API 中有 8 個確實採用受限解碼。它們在衝突 prompt 下達到 10/10，改用 stream: true 後也達到 5/5，串接所有 chunk 後仍是符合 schema 的 JSON。值得注意的是另外兩種例外。

Claude 的 OpenAI 相容介面沒有結構化輸出模式，而且 API 不會告知你。 3 個 Claude 模型都接受含 JSON Schema 的 response_format，回傳 200，接著自行產生任意 JSON。60 個測試回覆中，沒有一個符合 schema，還會自創 invoice_number、line_items 等欄位。第 2 條供應商鏈路也得到相同結果，回傳的是普通 Markdown。因此這不是單一閘道的轉換問題，而是 Claude 在任何地方都沒有實作這個參數。受支援的做法是使用 Anthropic 原生 tool call，並以 tool_choice 強制呼叫。這條路徑在衝突測試中達到 10/10。它也是唯一會對格式錯誤的 schema 回傳 200 的介面，其他 API 都會明確回傳 400。因此 schema 中即使有拼字錯誤，也可能無聲失效。

強制限制取決於代管平台，不只取決於模型。 Kimi K3 透過官方 API 時，在衝突 prompt 下 10/10 都遵循 prompt，每次都加入禁止的 notes 欄位；串流模式下也維持提示型限制，結果為 0/5。相同的開放權重由第三方 GPU 平台提供時，面對同一個衝突卻達到 3/3，成功強制執行相同 schema。如果你部署開放權重模型，不該只問「這個模型是否支援結構化輸出」，而要確認 serving stack 實際做了什麼。

宣稱的 100% schema 合規是真的嗎？

廠商的承諾很明確。OpenAI 的結構化輸出指南表示，這項功能「確保模型產生的回覆永遠符合你提供的 JSON Schema」。第三方比較也常引用其他受限解碼供應商超過 99% 的合規率。我們的實測同意這項說法，但它仍是本文資訊量最低的數字。在 6 種結構測試中，只要開關確實生效，所有執行結果都產生符合 schema 的 JSON：OpenAI 與每一代 Gemini 都是 60/60，DeepSeek V4 Pro、Qwen3.8-Max 與 GLM-5.2 都是 60/60，DeepSeek V4 Flash 則是 57/57。3 層巢狀結構、陣列、enum 與 union 都沒有改變結果。受限解碼確實有效，這些 API 已不再出現解析失敗。

但值正不正確是另一回事。在同一組測試中，DeepSeek V4 Pro 只有 51/60 正確填入值，V4 Flash 則是 53/57。所有錯誤回覆都是完全合法的 JSON。

什麼情況下，合法 JSON 會帶著錯誤值？

模型需要思考，但受限輸出通道不允許它這麼做時，就會出現這個問題。這項結果會直接影響 reasoning 模型執行資料擷取時的設定，而且在 12 個模型中的 4 個上都能重現。

最清楚的例子是一道單行數學題，輸出被限制為 schema（{"answer": integer, "unit": enum}），正確答案是 14。在預設開啟思考的情況下，Qwen3.8-Max 跨兩批共 16 次只答對 1 次。其中 11 次回答 9，另外還出現 29 與 2，但每個答案都符合 schema。關閉思考後，同一個 prompt 達到 8/8。這些錯誤答案不是隨機雜訊。9 是把找零除以 $3 而非 $2 得出的結果；GLM-5.2 在出錯時則回答 7，也就是題目中的筆數。受限解碼器會直接採用中斷推理時最接近的數字。

GLM 的錯亂不是固定發生，而是間歇出現，對正式環境反而更危險。同一天使用相同 prompt 與設定，第 1 批是 0/4，後面兩批則是 7/8。這種失敗模式可能通過 eval，進入正式環境後卻以 12% 的比例出現。schema validator 永遠抓不到，因為每個錯誤答案都能通過驗證。

資料擷取版本也有相同問題，而且症狀更難看。要求把品項數量寫入嚴格限制的整數欄位後，DeepSeek 系列在開啟思考時會輸出像 sentinel 或 placeholder 的垃圾值，包括 line_items: -1、-45、-85，甚至有一次把 $80 發票寫成 total: 8000。DeepSeek V4 Pro 開啟思考時只有 1/8 正確，關閉後則是 7/8。這與我們先前在該系列首次實測到的結果相同，當時只測兩個模型，這一批則確認相同模式也出現在 Qwen 與 GLM。OpenAI、3 個 Gemini 與 Kimi 在同一組測試的每個條件下都是 8/8。問題出在這 4 個模型如何讓推理繞過受限解碼器，而不是 reasoning 模型的共通缺陷。

常見的補救方式是在 schema 最前面加入 reasoning 字串欄位，讓模型在受限通道內思考。這對 Qwen 完全有效，即使思考仍開啟，正確率也從 1/8 提升到 8/8。但它有成本，而且不是通用解法。reasoning token 仍會計費，Qwen 的中位數是 393。在原本正常的模型上沒有任何收益，輸出 token 卻約增為兩倍，gpt-5.6-luna 每次呼叫從 48 增加到 106。DeepSeek V4 Flash 原本表現正常，套用後反而略差，從 8/8 降到 6/8。

實務規則很簡單：在 DeepSeek、Qwen 與 GLM 上執行結構化資料擷取時，應關閉思考。 無論是否開啟思考，schema 都會維持正確，但裡面的數字不一定可信。在 schema 中加入 reasoning 欄位只能算是需要逐模型驗證的修補方式，不該設成預設值。

各 API 支援哪些 schema 關鍵字？

實際支援範圍比 JSON Schema 規格暗示的更少，而且各家失敗方式不同。「有效」表示模型在 4 次衝突測試中至少有 3 次無法違反該關鍵字。

這張表有 3 個重點。第一，能在某個受限 API 上執行的 schema 不代表可以直接移植。OpenAI 會直接拒絕 oneOf，但支援 $ref；Gemini 剛好相反。只有 3 個中國模型系列成功限制所有送出的關鍵字。第二，回傳 400 反而是好結果。Gemini 的 oneOf 與 Claude 欄位中的大多數項目都會回傳 200，卻悄悄跳過限制，讓請求看起來有結構化輸出，實際上並沒有。第三，Claude 原生 tool 路徑能限制結構，包括型別、必填欄位、additionalProperties 與 pattern，但無法限制組合與格式。因此，它提供的保證比 grammar 驅動的 response_format 更淺。Gemini 的 dialect 也拒絕 ["string", "null"] 這類型別 union，因此即使 schema 看似可移植，也可能需要依供應商重寫。

結構化模式仍會消耗 reasoning token 嗎？

多數情況會，而且各 API 不一定都能關閉。以上述單行數學題為例，在預設設定下附上 schema 後，reasoning token 消耗中位數如下：GLM-5.2 為 568、DeepSeek V4 Pro 為 505、V4 Flash 為 466、Qwen3.8-Max 為 424、Gemini 3.6 Flash 為 210、Gemini 3.1 Pro 為 220、Gemini 3.7 Flash 為 99、Kimi K3 為 69、gpt-5.6-luna 為 28。這道題的答案只有 2 個 token，reasoning token 卻占了大部分輸出成本。

能否在結構化模式內關閉思考，各家做法不同。DeepSeek 會直接拒絕 reasoning_effort: none（400），但接受 thinking: {"type": "disabled"}。Qwen、GLM 與 Kimi 都允許把 effort 調到 0。目前這一代 Gemini，包括 3.7 Flash 與 3.1 Pro，會拒絕我們送出的每一種關閉寫法，符合該系列逐漸消失的關閉開關；因此結構化請求的推理成本無法避免。Claude 的原生路徑則沒有這個問題。強制 tool call 會完全略過 extended thinking，3 個模型的 reasoning token 都是 0，包括 Fable 5。每次資料擷取的輸出 token 中位數為 74。對簡單資料擷取而言，最昂貴的模型系列反而有最便宜的 completion。

Schema 本身每次呼叫要花多少成本？

同一個呼叫可能計入 30 至 4,959 個 prompt token。要理解差異，先看 schema 實際傳到哪裡。它不會放進 message list。OpenAI 相容介面會把它放在 request body 的 response_format.json_schema；Gemini 原生 API 則放在 generation_config.response_schema；Claude 根本沒有 schema 欄位，因此必須把它放進 tool definition 的 input_schema，再透過 tool_choice 強制模型呼叫。差別在伺服器收到後的處理方式。一類會把 schema 編譯成伺服器端 grammar，用來引導解碼，因此不會出現在帳單中。另一類會把它序列化成模型 context 裡的隱藏 prompt 文字，最後計入 prompt_tokens。我們使用相同文件，測試 3 種 schema 大小：157 bytes、加入 12 個額外欄位的 1.5 KB，以及 70 個欄位的 12 KB。

在會計費的 API 中，相同 byte 數的序列化成本最多相差 70%。同一個 12 KB schema，在 Gemini 要 4,012 個 token，在 OpenAI 則是 2,368。如果大量呼叫使用肥大的 schema，這一欄對成本的影響可能比模型每 token 單價更大。每月呼叫 100K 次時，12 KB schema 在 DeepSeek 完全免費，在 Gemini 則約為 400M 個 input token。

常見問題

結構化輸出能保證資料正確嗎？

不能。結構化輸出只保證資料可解析且符合 schema，不保證內容正確。在我們的測試中，所有正常運作的結構化模式都達到 100% schema 合規率，但部分模型與任務組合中，8 次回覆最多有 7 次在合法 JSON 裡帶著錯誤值。關閉思考後，多數都恢復正確。除了驗證結構，也必須驗證值。

Claude 支援 response_format json_schema 嗎？

不支援。我們測試的所有供應商都一樣，而且 API 不會回報錯誤。參數會被接受後直接忽略，這是最糟的失敗方式。應改用 Anthropic 原生 tool calling，並透過 tool_choice 強制呼叫。即使面對對抗性 prompt，實測仍能完整限制輸出；它也會略過 extended thinking，因此這批模型的 completion 最短，每次資料擷取的輸出 token 中位數為 74。

結構化資料擷取應該關閉思考嗎？

在 DeepSeek V4、Qwen3.8-Max 與 GLM-5.2 上應該關閉。我們的數學轉 schema 任務中，Qwen 關閉思考後，正確率從 1/16 提升到 8/8；DeepSeek V4 Pro 的資料擷取則從 1/8 提升到 7/8。OpenAI 與 Gemini 開啟思考時沒有出現值錯亂，因此可依任務難度決定。要注意的是，目前這一代 Gemini 完全不允許關閉思考。

本測試於 2026-08-25 透過 Synthorai 閘道，針對 12 個正式環境模型 API 執行；所有方法與樣本數都列在上方「我們如何測試結構化輸出？」一節。絕對數字來自這一批測試，供應商可能隨時變更 serving 行為，因此在依賴表中任何結果前，請重新實測。

同系列相關文章：13 個模型的思考控制實測、DeepSeek V4 Pro 實測、Qwen3.8-Max 成本、GPT-5.6 成本指南。

← 返回部落格