在前面幾天，我們探討了Prompt的邊界設定，以及如何透過Context Engineering（Write、Select、Compress、Isolate）精準調配模型的輸入

當輸入端的工程做好後，系統工程師馬上會撞到下一個致命痛點：輸出端的不可控性。

在傳統軟體工程中，模組與模組之間的溝通依賴嚴格的API契約（API Contracts）與型別系統（Type Systems）。然而，LLM天生是個自由文字生成器。如果你對模型說「請以 JSON 輸出」，它可能在今天回傳標準 JSON，明天卻在外面包了一層 json ... ，後天甚至漏掉某個關鍵欄位

只要輸出格式一破裂，下游的Python程式碼就會直接噴出 JSONDecodeError 或 KeyError，整個自動化工作流隨之崩潰

這正是為什麼我們需要 Structured Output Engineering（結構化輸出工程）
今天我們就來拆解它的底層原理與演進歷程

一、結構化輸出的本質：為機率輸出套上「型別安全（Type Safety）」枷鎖

在軟體架構中，Structured Output Engineering的核心定義是：

透過確定性約束機制，強制 LLM 產生的 Token 序列嚴格遵循預先定義的資料結構（如 JSON Schema 或 Pydantic Model），確保輸出 100% 可被下游程式碼安全反序列化。

傳統「提示詞要求」為何無法保證 100% 穩定？

早期工程師常用的方式是在Prompt裡寫：「請輸出JSON，不要加多餘文字」。這種方法的致命缺陷在於：

1. 機率性失效：模型在面對邊界條件（Edge Cases）或超長輸入時，依然可能夾帶前言或結尾閒聊。
2. 型別模糊：布林值可能變成字串 "true"、空值可能變成 "None" 而非 null、數字可能帶有單位（如 "100元"）。
3. 巢狀結構破裂：深層巢狀物件極容易出現括號未閉合的情況。

二、技術演進史：從「文字修補」到「底層語法約束」

為了讓LLM穩定輸出結構化資料，社群與模型供應商經歷了三個階段的演進：

階段 1: Prompt + Regex / Output Parsers (重試與修補)
   │
   ▼
階段 2: Function / Tool Calling 模式 (參數引導)
   │
   ▼
階段 3: Constrained Decoding & JSON Schema Enforcement (底層語法引導生成)

1. 輸出解析器與自動修補（Output Parsers & Retry）

• 原理：LLM輸出純文字，外層程式碼利用正規表達式（Regex）提取JSON區塊，若解析失敗則將錯誤訊息組裝回 Prompt 要求模型重新修復重試
• 缺點：消耗雙倍以上Token與延遲，且極端情況下重試依然可能失敗

2. 利用 Tool / Function Calling 生成

• 原理：將目標資料結構定義成一個假想的Function Schema，強迫模型調用該工具，藉此取得結構化參數
• 缺點：雖然穩定度提升，但在某些模型上仍偶有參數型別偏差或漏填欄位的情況。

3. 約束解碼（Constrained Decoding / Grammars）

• 原理：現代結構化輸出的終極型態（如 OpenAI 的 json_schema 嚴格模式、Outlines、Instructor、SGLang）
• 機制：在模型逐字預測Token時，直接在 Logits 層遮罩（Masking）不合法的 Token。例如此時語法規定只能出現逗號 , 或右大括號 }，模型就絕對不可能生成英文字母。這在數學與邏輯上保證了輸出 100% 符合 JSON Schema

三、現代結構化輸出的核心要素

一個健全的結構化輸出定義，通常由以下三層資訊構成：

from pydantic import BaseModel, Field
from typing import Literal, Optional

class CustomerIntentOutput(BaseModel):
    # 1. 欄位型別與枚舉限制 (Enums)
    intent: Literal["REFUND", "EXCHANGE", "TRACKING", "OTHER"] = Field(
        description="用戶的核心業務意圖"
    )
    
    # 2. 邊界約束與預設值
    confidence_score: float = Field(
        ge=0.0, le=1.0, 
        description="模型對此分類判定的置信度 (0.0 到 1.0 之間)"
    )
    
    # 3. 可選欄位與詳細定義
    order_id: Optional[str] = Field(
        default=None, 
        description="提取出的訂單編號，若對話未提及則為 null"
    )

1. 嚴格型別註解（Strict Typing）：明確宣告 str、int、float、bool。
2. 枚舉（Literal / Enum）：將分類標籤限制在預設的合法字串池內，防止模型自創標籤。
3. 欄位語意描述（Field Descriptions）：透過 Field(description=...) 指引模型該欄位的提取邏輯，兼具 Prompt 的導引效果。

四、非結構化輸出 vs. 結構化輸出的架構對比

小結與下集預告

Structured Output Engineering是將LLM從「聊天助理」轉化為「標準微服務節點」的關鍵轉換器
它抹平了生成式AI的隨機性，賦予輸出與傳統程式碼無縫相容的確定性

理解了結構化輸出的本質與底層機制後，在實戰中我們該如何使用Pydantic與主流LLM SDK（OpenAI, LangChain, Instructor）寫出零容錯的解析管線？

明天 【Day 7】怎麼應用 Structured Output Engineering，我們將進入實戰篇，透過具體程式碼展示如何使用 Pydantic 定義資料契約、處理驗證失敗回退機制，並將 LLM 輸出無縫寫入資料庫！