情境
正式應用中的結構化資料擷取
作業流程從電子郵件帳單提取供應商、帳單號碼、幣別、總額、稅額與到期日。 Gemini 2.5 Flash 接收 OCR 文字與版面提示，須回傳單一含版本的 JSON 物件。
缺少的欄位維持 null。 總額不明確時，列出候選值與原文範圍。 流程接受紀錄前驗證型別與計算；失敗就修復或送審。
正式環境場景
結構化資料擷取用 LLM API
作業流程從電子郵件帳單提取供應商、帳單號碼、幣別、總額、稅額與到期日。 Gemini 2.5 Flash 接收 OCR 文字與版面提示，須回傳單一含版本的 JSON 物件。
正式環境實作
API、主要模型與備援設定
| 正式環境選擇 | 建議 | 原因 |
|---|---|---|
| API | POST /v1/chat/completions | OpenAI 相容伺服器端請求 |
| 主要模型 | gemini-2.5-flash | 目前目錄的高吞吐量提取，優先使用 Gemini 2.5 Flash。 |
| 備援模型 | gpt-5.6-terra | 特定文件類型用 Terra 表現更好時，就改用 Terra。 長篇或版面複雜的文件，升級至 Gemini 2.5 Pro。 |
| 升級模型 | gemini-2.5-pro | 只在主要路徑未達品質或複雜度門檻時使用 |
| 輸出規則 | 通過驗證的 JSON | 嚴格的 invoice.v3 JSON：欄位有型別、缺資料用 null、每個值附原文範圍。 |
架構
結構化資料擷取流程如何運作
- 執行 OCR 並保留原文範圍。
- 隨文件傳送結構版本。
- 要求嚴格 JSON，缺少資料用 null。
- 驗證結構、幣別、總額、日期與證據範圍。
- 接受、修復一次，或交人工審查。
API 請求
透過 LLMFly AI 呼叫 gemini-2.5-flash
從伺服器送出請求，將範例內容與預留工具格式換成應用的資料與工具。
curl https://app.llmfly.ai/v1/chat/completions \
-H "Authorization: Bearer $LLMFLY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gemini-2.5-flash",
"messages": [
{"role": "system", "content": "Extract one invoice into the supplied JSON schema. Use null for absent fields. Include a source span for every non-null value. Never guess."},
{"role": "user", "content": "Extract this invoice using schema invoice.v3."}
],
"response_format": {"type": "json_object"}
}'模型選擇
為什麼以 gemini-2.5-flash 為主要模型
目前目錄的高吞吐量提取，優先使用 Gemini 2.5 Flash。
特定文件類型用 Terra 表現更好時，就改用 Terra。 長篇或版面複雜的文件，升級至 Gemini 2.5 Pro。
驗收
結構化資料擷取驗收檢查
| 指標 | 通過條件 |
|---|---|
| 結構有效回覆率 | 無須修復即可通過版本化結構驗證 |
| 各欄位精確率與召回率 | 每個重要欄位達到分別設定的精確率與召回率目標 |
| 無據數值比例 | 每個值都有原文證據或明確的衍生值規則 |
| 每筆接受紀錄的成本 | 生成、驗證、修復與審查符合處理預算 |
失敗處理
部署前要處理的失敗
- 把有效 JSON 當成正確資料
- 猜測缺失欄位
- 改結構卻不更新版本
- 用平均值掩蓋重大錯誤
輸出
回傳輸出與執行紀錄
嚴格的 invoice.v3 JSON：欄位有型別、缺資料用 null、每個值附原文範圍。
每次正式執行記錄模型 ID、請求 ID、token 用量、重試、驗證結果與最終處理。
常見問題
有效 JSON 就夠了嗎？
不是。 驗證結構後，再將每個提取值與原文證據比對。
缺少的值應如何表示？
先定義規格，例如缺資料用 null，不明確則另設狀態。
哪個指標最重要？
報告每個欄位的精確率與召回率，尤其是會觸發操作的欄位。
用自己的輸入測試設定
以相同請求、工具與驗證規則比較主要和備援模型。