Structured Outputs
3 秒看懂
Structured Outputs（結構化輸出） 是一項讓大語言模型（LLM）生成嚴格符合預定義格式/模式文本的技術，如 JSON、SQL、特定業務表單、甚至受語法約束的自由文本。它不是簡單的提示詞引導，而是通過解碼時對模型詞彙表施加約束，從根上杜絕格式非法。在 Agent 與工具呼叫、資料自動錄入、合規報告等場景，結構輸出是決定系統可靠與否的關鍵生產級能力。
3 分鐘產業解釋
在 LLM 應用大規模落地的今天，模型生成的文本能否被下游程式直接、確定性解析，已經成為瓶頸。結構輸出技術旨在將“自然語言理解”的輸出接入“結構化系統”，消除格式錯誤、欄位缺失、非法令牌帶來的解析失敗。
- 輕量方案：提示工程 + 後處理正則修復（成本低，魯棒性差）。
- 工程化方案：通過約束解碼（constrained decoding），在每一步生成時動態遮蔽不符合語法/模式的 token，保證輸出 100% 符合目標結構。
- 產業位置：處在模型推論與下游應用之間，屬於 LLM 工具層/中介軟體。上游對接模型服務商（OpenAI、Anthropic、Meta 等）的推論引擎，下游服務企業軟體開發商、自動化平台。
當前，結構化生成已從“錦上添花”變成企業級 LLM 應用的剛性需求，尤其在金融合規填報、醫療單據、程式碼生成與 API 呼叫等領域。未來這一能力會內化成模型服務的預設功能，類似資料庫的“約束”機制。
15 分鐘專家深入
結構化輸出並非單一技術，而是一條從無約束文本對映到強制格式的技術譜系，按約束強度可分為：
- 提示約束（Prompt-level）：用 few-shot、角色說明、格式指令引導模型。有一定成功率，但存在幻覺，無法保證 100% 合規。
- 後處理修復：接收原始輸出後進行正則匹配、JSON 修復、重取樣。易實現，但修復失敗或丟掉語義的風險高，且額外增加延遲。
- 約束取樣（Constrained Sampling/Decoding）：在自迴歸生成時，每一步對 logits 施加掩碼，遮蔽掉與目標格式不相容的 token，保證生成的序列被自動機或語法接受。
- 端到端訓練：在模型微調階段即加入格式約束資料，或使用結構化損失函式。成本高，但可減少推論時的約束開銷，提升生成質量。
目前最具工程價值的是約束解碼，它能以較低推論開銷實現嚴格格式保證，常作為推論引擎外掛（如 vLLM guided decoding、Hugging Face Transformers 通過 constraints 引數及 DisjunctiveConstraint 等支援約束生成）或獨立庫（Outlines、Guidance、LMQL）存在。OpenAI 在 ChatGPT/API 中提供的“JSON 模式”即為一種受限的約束解碼實現（只能保證 JSON 語法正確，不保證 schema 完整），而 GPT‑4 Turbo 的 Structured Outputs 功能（2024 年釋出）則更進一步，可繫結 JSON Schema，實現欄位型別、列舉值的強制匹配。
技術原理（最深）
約束解碼的核心思想是：將目標文本格式描述為一個有限狀態自動機，然後在每一步生成時，僅允許能繼續合法路徑的 token 進入候選。深度展開其工作機制如下：
1. 格式轉為狀態機
給定 JSON Schema、正規表示式、或上下文無關文法（CFG），先編譯成一個確定/非確定的有限自動機或下推自動機。以 JSON 生成為例：
- 狀態包括：
start,key,colon,value,string,number,comma,end等。 - 每個狀態下合法字元集明確，如
key狀態只能生成雙引號開始；string內部不能出現未轉義的雙引號。
將字元級自動機對映到 Token 級約束 是難點，因為 tokenizer 會切割字串。一種做法是建置一個基於詞表字首的狀態圖，使每個 token 都能對應一條或多條狀態轉移路徑。
2. 每一步的約束過程（虛擬碼表達）
for each generation step:
logits = model.forward(prefix) # 獲得所有 token 的得分
mask = build_token_mask(prefix, fsm)
logits[~mask] = -inf # 遮蔽非法 token
next_token = sample(logits) # 從合法集合取樣
prefix += next_token掩碼建置 build_token_mask 負責維護已生成序列對狀態機的推進，返回當前可用的 token id 集合。一種高效實現是預先編譯整個詞表到自動機狀態的對映表（從每個狀態可到哪些 token），如同 Outlines 庫所為。
3. 多模式支援
- 正則約束：將正規表示式編譯為確定有限自動機（DFA），再與詞表進行交集運算生成令牌級狀態轉移表。
- JSON Schema 約束：先展開為規範化的 JSON 語法，然後編譯成自動機。過程中需處理可選欄位、
anyOf/oneOf、遞迴引用。某些實現通過惰性建置（lazy building）避免狀態爆炸。 - CFG 約束：適用於程式語言等複雜語法。使用 Earley 解析器或 GLR 解析器線上性化步驟即時過濾 token。但計算開銷高於正則/JSON，通常需做效能裁剪。
4. 與取樣策略的相容
約束解碼可以與溫度、Top‑k、Top‑p 取樣無縫結合：先施加格式掩碼，再在合法 set 上應用溫度縮放和截斷。不過，當合法 token 過少時，取樣分佈可能極度集中，影響多樣性。工程中會通過加回一個保底的低機率噪聲 token 或動態調整溫度介入。
5. 效能考量
約束解碼帶來的額外延遲主要體現在：
- 狀態追蹤更新：O(1) 至 O(N) 不等，精心最佳化的雜湊表可實現每次解碼<1ms 的增量。
- 掩碼計算：通常需在 GPU 端完成 softmax 前將非法 logits 置
-inf，需傳遞 mask 張量。對於大 vocab (128k+) 來說記憶體和資料搬運有成本，但多數系統已做到吞吐幾乎無感知。
使用者輸入 JSON Schema
│
▼
Schema 編譯為 Indexed FSM
│
▼
Token 詞表 → T令牌-狀態轉移矩陣
│
▼
LLM 逐步解碼 → 每一 logit 與掩碼互動 → 取樣合法 token
│
▼
100% 合法 JSON 字串技術演進史
- 2016‑2019 預 LLM 時代：序列生成約束以自定義 RNN/Transformer 的小規模實驗為主，如用 CFG 約束神經網路詩歌生成（學術 demo），產業應用未見。
- 2020‑2022 提示工程為主：GPT‑3 出現後，“格式指令 + 後處理” 成主流。LangChain 推出
OutputParser封裝了部分修復邏輯。但格式錯誤率長期在 5‑15% 波動，企業級部署受阻。 - 2023 約束解碼爆發：微軟推出 Guidance（基於 Handlebars 模板+受限生成），隨後 NVIDIA NeMo Guardrails、LMQL、Outlines 等出現。OpenAI 引入 JSON mode，但只保證 JSON 語法，不保證 schema。Meta Llama 生態中，llama.cpp 和 Hugging Face Transformers 逐步整合語法約束功能。
- 2024 功能內化為 API：OpenAI 在 GPT‑4 Turbo 中提供原生 Structured Outputs（schema 強約束），Anthropic 通過擴充套件提示中的“function calling”定義實現工具呼叫結構化。vLLM 及 SGLang 等推論引擎將約束解碼作為標配，以低延遲支援複雜 schema。業界開始視其為模型服務的基線能力，不再是 add‑on。
技術路線對比（量化表）
（以下對比基於行業公開技術特性，非精確 benchmark 資料，僅供參考）
| 路線 | 格式合規率 | 語義保真度 | 推論額外開銷 | schema 支援 | 實施複雜度 |
|---|---|---|---|---|---|
| 提示工程 + 後處理修復 | ~90‑98%（場景依賴） | 較高 | 極低 | 簡單 JSON | 低 |
| 約束解碼（正則/JSON 語法） | 100% 語法合法 | 中等（可能丟失欄位） | 低‑中（<5% latency） | 支援正則、基礎 JSON | 中 |
| 約束解碼（全 schema） | 100% 欄位/型別合規（理論上） | 保守（嚴格遮蔽可能降低流暢度） | 中（<10% latency） | 遞迴 schema, anyOf 等 | 高 |
| 端到端微調+解碼約束 | 近 100% | 高（模型習得格式節奏） | 低（解碼約束弱化） | 依賴訓練資料 | 極高（訓練成本） |
- 合規率：約束解碼類在實現正確時可達確定性的 100% 結構正確，但語義正確性仍依賴模型。
- 延遲開銷：為經驗估算，具體取決於詞表大小、狀態空間大小。輕量 JSON 約束在主流引擎上可做到吞吐下降 <2%。
上下游
上游
- LLM 提供商/推論引擎：OpenAI、Anthropic、Google（Gemini 的 controlled generation）、Meta（通過 Llama 生態）、Mistral 等。這些廠商在推論管線中實現或面臨整合結構化輸出需求。
- 約束引擎架構：Outlines（dottxt）、Guidance、LMQL、SGLang、vLLM、TensorRT-LLM 的 guided decoding 外掛。
- 標準格式定義組織：JSON Schema 規範、Apollo GraphQL、OpenAPI 等，間接影響約束表達力。
下游
- Agent 與工具呼叫：當 LLM 需要生成精確函式呼叫引數時，結構化輸出是必備件，如 LangChain、AutoGPT、AWS Bedrock Agents。
- 垂直應用軟體：智慧表單、合同生成、醫療資訊抽取、金融合規報告自動填報等。
- 資料工程與 ETL：用 LLM 將非結構化文本轉化為表結構（如GPT Crawler 到資料庫），可靠的結構輸出決定資料管道的穩定性。
關鍵指標
- 格式正確率（Format Accuracy）：輸出字串是否可通過目標編譯器的解析，對 JSON 而言即
JSON.parse不拋異常。高成熟度系統可達 >99.99%（僅受實現 bug 影響）。 - Schema 合規率：在所有欄位、型別、列舉值上完全符合給定 schema 的比例。這是更強指標，即便 JSON 合法仍可能缺少欄位。
- 解碼吞吐量（Tokens per second）：與無約束推論對比的吞吐下降百分比，是生產部署的主要關注點。典型值：<5%‑10%（估算，來源：社群分享）。
- 首 token 延遲（TTFT）：約束會輕微增加編譯和狀態初始化時間，但通常 <50ms。
- 語義保真度：不易量化，通常以人工評估或下游任務指標衡量。過度約束可能導致模型用尷尬的措辭填充，可在弱約束（只驗格式）與強約束間做權衡。
供需與市場資料
由於結構化輸出屬於 LLM 工具層的細分領域，暫無獨立第三方市場規模報告。但從幾個側面可見其爆發性需求：
- API 內化趨勢：OpenAI 在 2024 年 8 月全面開放 Structured Outputs 功能，並免去此前 JSON mode 的額外費用，將其定位為 API 的基礎功能。此舉實質將大量第三方的解析/約束庫市場空間壓縮。
- 開源生態熱度：Outlines（GitHub star 超 8k，截至 2024 底）、 Guidance（Microsoft 出品，star >17k），表明開發者對低層控制的結構約束有剛性需要，尤其當所用模型沒有原廠 API 時。
- 企業付費意願：據多份行業調研提及（無具體公開資料），落地 LLM 應用的企業最核心的痛點中，“不可靠輸出格式”排在前三。能夠解決此問題的中介軟體或服務因此擁有強議價能力，部分創業公司圍繞“可靠的結構化提取”建置付費產品（如 V7 Go’s structured extraction）。市場處在早期快速增長階段，但 API 層的“標準件”可能令獨立中介軟體賽道集中化。
代表公司與資本對映
（以下為產業公開資訊，部分公司的具體估值/營收未揭露，故用定性描述）
- OpenAI：已將結構化輸出內化為 ChatGPT 與 API 的內建特性，與函式呼叫深度繫結。其在資本層面的影響是抬高了 LLM 基礎設施的准入標準，讓後來者必須有此功能才能競爭。
- Anthropic：通過 tool_use 功能及系統 prompt 中的結構定義提供近似能力，走“長時間上下文+強遵循指令”路線，約束解碼的透明度低但實戰效果好。在安全性要求高的行業（如法律、政府）有差異化優勢。
- Meta (Llama)：開源模型並無內建服務，但其開放權重使得社群能夠自由施加約束解碼。Meta 間接通過 vLLM 等社群專案獲得此能力，在私有化部署市場佔據龐大生態位。
- dottxt (Outlines 商業實體)：專注結構化生成的初創公司，提供高效能約束推論產品。定位為“企業級結構化輸出基礎設施”，獲風投支援，與自託管模型市場深度繫結。
- Guidance (Microsoft)：微軟研究院孵化的語言控制架構，與 Azure AI Studio 有整合潛力，代表傳統雲端廠商通過工具鏈佔領結構化應用程式建置。
- SGLang (斯坦福/社群驅動)：高效的 LLM 服務架構，內建 RadixAttention 與結構輸出，開源生態活躍。反映學術界向推論級最佳化的滲透。
資本對映邏輯：結構化輸出賽道並不大可能誕生百億市值的獨立公司，但它決定 LLM 平台競爭中的粘性與效率護城河。研究中可把這一能力對 LLM API 提供商市場份額的影響，以及其對 Agent/自動化平台公司的賦能價值作為觀察變數。
投資邏輯
- 整合商優先受益：最早將結構化輸出做進 API 的平台（如 OpenAI）能吸引大量對可靠格式敏感的企業客戶，推動其推論營收增長。這類改進會拉開與第二梯隊的體驗差距。
- Agent 落地催化劑：可靠的工具呼叫和互聯是 Agent 的前提。結構輸出技術成熟度直接決定 Agent 在金融交易、供應鏈管理等嚴肅場景的滲透節奏。應密切關注能提供“100% 可靠輸出的 Agent 基礎設施”的標的。
- 私有化部署提供視窗：在資料隱私要求高的行業（金融、醫療），企業傾向自部署模型。能夠為開源模型提供高效能結構約束的中介軟體廠商（如 dottxt）存在成長空間，但需面對雲端廠商的擠壓。
- 收益與風險：錯誤的結構約束引入可能導致生成質量下降（死迴圈、拒答），過度依賴單一廠商的格式實現會造成鎖定。評估相關公司時需考量其約束引擎的靈活性和模型無關性。
- 估值邏輯：不應單獨評估“結構輸出”技術本身，而應將其視為 LLM 平台/AI 基礎設施產品力的一部分。擁有卓越結構生成能力的平台公司應獲得更高的 ARPU（每使用者平均營收）和更低的流失率，從而在估值上有溢價。
常見誤讀糾偏
- 誤讀1：“JSON mode 就是完全的結構化輸出。”
糾正：JSON mode 僅保證輸出為合法 JSON，不保證符合預期的欄位、型別、或是完整的 Schema。例如一個 JSON mode 可能輸出
{"name": 123}，雖為合法 JSON，但name欄位型別錯了。完全的結構化輸出應將 Schema 約束下推至每一次 token 選擇，確保欄位存在且型別正確。 - 誤讀2：“結構輸出犧牲了太多創造力，只能用於格式化任務。”
糾正：約束只定義輸出外殼，內容本身仍由模型自由生成。例如強制輸出一個評論列表
{"reviews": ["...", "..."]}，每條評論的內容仍可天馬行空。創造力損失更多發生在模型對齊階段，而非格式約束。事實上，精細的約束還能防止模型說“廢話”，反而提升有用性。 - 誤讀3：“約束解碼慢，不適合生產環境。” 糾正：現代實現（如 Outlines 的索引、vLLM 的 Guided Decoding）已將開銷壓縮到極低，多數場景下近乎零感知。對延遲敏感的應用，還可通過預編譯快取部分狀態圖進一步降低。一些 benchmark（社群測試）顯示 JSON Schema 約束可比無約束推論吞吐降低約 2‑7%，這在多數生產系統的接受範圍內。
學習路徑
- 基礎理解：閱讀 OpenAI 的
Structured Outputs文件 和 Anthropic 的 Tool use 指南，理解產品側的能力邊界。 - 學術/原理深度：讀論文 “Outlines: A simple way to generate structured text from LLMs”（Willard & Louf, 2024），以及 “Grammar‑constrained decoding for structured NLP tasks” 系列文章，瞭解 FSM 與詞表對映。
- 動手實踐：
- 使用 Outlines 配合 Hugging Face 模型，實現一個帶 Enum、遞迴的 JSON Schema 生成。
- 用 vLLM 的
guided_decoding引數部署一個 API，對比開/關約束下的格式正確率和延遲。
- 跟進前沿：關注 SGLang 的
constrained decoding發展、Apache TVM 社群的討論（討論將約束下沉到計算圖編譯），以及 llama.cpp 的 grammar 支援更新。 - 產業視角：追蹤各大 LLM 廠商的 API 更新日誌，哪些約束型別是差異化功能？如何影響定價？這有助於理解競爭格局的變化。
一句話總結
Structured Outputs 將 LLM 從“會說人話的創造者”轉變為“會格式化資料的堅實 API 端點”，是 AI 從對話玩具走向生產系統必須打通的“最後二十米”。
延伸閱讀與來源
- OpenAI. Introducing Structured Outputs in the API (2024). [Blog post]
- Anthropic. Tool use (function calling) documentation (2024). [Docs]
- Willard, T., & Louf, A. “Outlines: Simple structured generation from large language models.” arXiv preprint (2024).
- Microsoft. Guidance: A guidance language for controlling large language models. GitHub repository (2023). [github.com/guidance-ai/guidance]
- SGLang. Efficient LLM serving with structured generation. Project documentation (2024). [sglang.ai]
- vLLM. Guided Decoding proposal and implementation. GitHub discussions (2024).
- 行業媒體分析：The Sequence, “Why Structured Outputs Are the Next Big Thing for LLMs”; SemiAnalysis 等評述。
（由於本次檢索失效，以上資訊基於公開資料與行業知識總結，未標註具體商業資料來源，僅供參考。）