核心結論
仍要驗證。Structured Outputs 可確保輸出符合指定資料結構，但官方文件明確指出欄位值仍可能出錯。系統應另外檢查來源證據、跨欄位關係、主檔存在性與業務限制，高影響動作再加人工核准。
執行摘要
核心觀察：結構化輸出能大幅減少格式錯誤，但不能保證欄位值符合真實情境。一項 2026 年原始研究測試 2,400 次餐飲訂單代理呼叫，最強模型在兩種模式都達到 100% Schema 有效，語意成功率卻只有 83.0% 與 81.3%。[3] 行動建議：企業應把 AI 輸出依序通過格式、業務規則與動作授權三道關卡，高影響結果未通過時轉人工，不讓『可以解析』被誤當成『可以執行』。
能讀進系統，不等於能做對事情
結構化輸出解決的是介面問題。AI 回傳固定欄位、型別與列舉值後，系統不必再從自然語言猜測資料位置，也能減少解析失敗。OpenAI 的評測顯示，Structured Outputs 在特定模型與測試中可把複雜 Schema 符合率提高到 100%。[1] Microsoft 也明確區分了有效 JSON 與嚴格符合指定 Schema 的差別。[2]
但 Schema 只能知道 amount 是數字、currency 是字串，不能知道 12,500 元是否抄錯、幣別是否與合約一致，或供應商編號是否真實存在。OpenAI 的限制說明也指出，模型仍可能在 JSON 欄位值內出錯。[1] 因此，格式通過應是進入下一階段的條件，不是整筆資料的完成證明。
建立三道驗證關卡
第一道是格式關卡，檢查 JSON、必填欄位、型別、列舉與 Schema 版本。第二道是語意與業務關卡，檢查金額加總、日期順序、單位、主檔編號、合約上限與跨欄位關係。第三道是動作關卡，確認操作者權限、人工核准、冪等鍵、影響範圍與失敗後如何回復。
OrderBench 的 2,400 次呼叫顯示，即使 Schema 有效達到 100%，語意成功率仍可能只有約八成；較弱模型甚至會產生 Schema 有效但不安全的接受結果。[3] 這是餐飲訂單基準，不代表每家企業的實際錯誤率，但直接說明：可解析與可執行是兩個不同驗收問題。
把規則、證據與人工覆核接起來
企業可先從一個高頻流程建立欄位規則表。每個欄位記錄來源、資料型別、允許範圍、跨欄位規則、失敗狀態與人工負責人。高影響欄位還要保存原始文字、頁碼或資料列，讓覆核者不用重新找整份文件。
ACRA 的 CLAIR 是清楚的官方案例：AI 先依選定準則篩查財報中的潛在揭露缺口，再由人員評估與驗證，之後才可能發出建議函。[6] 醫療資訊擷取研究也把 Schema 約束、決定式後處理與第二輪稽核分開，最佳組合的 F1 為 80.36%。[5] 兩者都沒有把第一輪結構化輸出當成流程終點。
驗收要量語意錯誤，不只量格式成功
Schema 會改版，模型與提示詞也會更新。ACL 研究在 1,200 組評估中觀察到 39% 至 54% 的輸出至少含一項語意幻覺，並指出不同模型有不同錯誤型態。[4] 所以每次換模型、改欄位或調整流程，都應用固定案例重新測試內容正確率與錯誤類型。
穹境建議 Lead Measure 追蹤具決定式規則的關鍵欄位比例、高影響寫入經授權的比例、欄位來源證據完整率與跨欄位測試覆蓋率；Lag Measure 追蹤 Schema 通過但語意錯誤率、人工修正率、錯誤放行事件與每筆可接受資料成本。真正要改善的是被業務規則驗證後的正確動作，而不是漂亮的 JSON。
關鍵要點
有效 JSON 只是第一關：先檢查能否解析、必填欄位、資料型別與允許值，不能把這一步稱為內容正確。
業務規則要能程式化：金額加總、日期先後、單位幣別、編號存在性與跨欄位關係，應由決定式規則再驗證。
保留來源與欄位證據：每個重要欄位應能回到原文件、資料列或使用者指令，方便人工覆核與追責。
修正後必須重驗：模型可提出修正版，但不能自己宣布通過；任何修正都要重新走相同驗證關卡。
放行與格式分開：付款、寄送、刪除與正式資料寫入，仍需權限、核准、冪等與可回復設計。
參考來源
Introducing Structured Outputs in the API
OpenAI · 2024-08-06
https://openai.com/index/introducing-structured-outputs-in-the-api/Structured outputs
Microsoft Foundry · 2026-08-24
https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/structured-outputsWhen JSON Is Not Enough: Semantic Reliability of Schema-Constrained LLM Ordering Agents
arXiv 原始研究 · 2026-05-16
https://arxiv.org/abs/2607.18261StructHallu-Drift: Benchmarking Structured Hallucinations Under Schema Evolution in LLMs
ACL Anthology 原始研究 · 2026-07
https://aclanthology.org/2026.surgellm-1.22/Retrieval-Augmented Large Language Models for Schema-Constrained Clinical Information Extraction
arXiv 原始研究 · 2026-05-14
https://arxiv.org/abs/2605.15467AI-assisted Disclosure Advisory Initiative
新加坡會計與企業管理局 · 2026-09-01
https://www.acra.gov.sg/regulations/accounting-standards-financial-reporting-surveillance/ai-assisted-disclosure-advisory-initiative/常見問題
Q：用了 Structured Outputs，就不用再驗證 AI 結果嗎？
A：仍要驗證。Structured Outputs 可確保輸出符合指定資料結構，但官方文件明確指出欄位值仍可能出錯。系統應另外檢查來源證據、跨欄位關係、主檔存在性與業務限制，高影響動作再加人工核准。
Q：JSON Schema 可以驗證哪些內容？
A：它適合驗證必填欄位、資料型別、列舉、長度、數值範圍與物件結構。它通常無法單獨判斷金額是否抄對、日期是否符合實際合約、客戶編號是否存在，或這筆交易是否應該被授權。
Q：中小企業要怎麼建立業務驗證？
A：先選一個高頻流程，把最常出錯且影響最大的 5 到 10 個欄位列出來。為每欄設定來源、格式、允許範圍、跨欄位關係與失敗去向，再用真實歷史案例建立通過、需覆核與拒絕三類測試。
Q：可以讓另一個 AI 負責驗證第一個 AI 嗎？
A：可以作為額外訊號，但不能取代可重複的決定式規則。金額加總、日期順序、編號查詢與權限檢查應由程式或主資料驗證；第二個 AI 適合協助找矛盾與整理證據，結果仍需通過相同關卡。
Q：哪些 AI 結果不能只靠 Schema 自動放行？
A：涉及付款、合約、個資、刪除、對外寄送、法規申報或正式系統寫入時，不應只靠 Schema。這些流程至少要檢查業務規則、權限與核准，並保留來源、版本、驗證結果與實際執行紀錄。
由穹境科技 AI 情報系統生成 · 2026-09-16 · 資料來源見上方參考列表