Data ExtractionDocument AILLM API

2026 LLM 資料抽取指南：從 PDF 到結構化 JSON

閱讀 1 分鐘

上季，發票 pipeline 吃進了 40,000 份文件。對帳報表看起來完美無瑕——直到有人發現有 3% 的廠商欄位在默默出錯：一組發票號碼位數對調、一列稅額掛到錯誤的列、一個貨幣符號被漏掉。沒有人發現，因為抽取沒有失敗。它成功了，只是答案錯了。

這就是文件抽取特有的恐怖之處：失敗是無聲的。schema 欄位回傳空值卻通過驗證時，不會有 500 錯誤；表格欄位移動時，不會有例外。LLM 資料抽取是 2026 年價值最高的 LLM 工作負載之一——發票、合約、表單、理賠——也是最容易被基準測試誤導的領域之一，因為供應商的 benchmark 由供應商自己撰寫，用的還是會讓自家 parser 表現亮眼的文件。

這份指南從頭到尾涵蓋抽取 pipeline——解析、schema、抽取、驗證——包括誠實的基準測試問題（LLM-only vs 解析供應商 vs 開源，用你自己的文件）、防止無聲污染的 schema 設計、讓它維持合法的 PII 處理，以及每 1,000 份文件的成本模型。

文件抽取實際涉及什麼

重點：抽取是一條五階段鏈——解析、理解、建立 schema、抽取、驗證——而且任何一個階段都可能無聲失敗。

PDF → 1. Parse (layout, tables, OCR) → 2. Understand (vision or text)
        → 3. Schema (what fields, what types) → 4. Extract (LLM)
        → 5. Validate (types, required, confidence) → JSON

這條鏈的強度取決於最弱的階段，而每個階段的失敗方式不同：解析在掃描文件與多欄排版上出錯、理解在旋轉或浮水印內容上出錯、schema 在欄位遺失卻沒人發現時出錯、驗證在根本沒有實作時出錯。pipeline 的任務，就是讓每一種失敗都大聲，而不是無聲。

為什麼抽取會在正式環境失敗

重點：三類失敗——解析錯誤、schema 漂移與缺少驗證——而其中只有一種會出現在日誌裡。

  1. 解析失敗。 沒有 OCR 的掃描文件、被當成文字湯讀取的表格、被壓平成雜亂順序的多欄排版。parser 決定天花板；LLM 無法抽取 parser 已經毀掉的東西。
  2. Schema 漂移。 文件會改變——新欄位出現、廠商更換模板——而 schema 保持不動。抽取結果默默回傳缺失的欄位，而且通過驗證，因為「缺失」從來不是一條規則。
  3. 缺少驗證。 沒有型別檢查、沒有必填欄位規則、沒有信心評分。pipeline 回傳 JSON，而看起來正確、實際上不正確的 JSON 比沒有 JSON 更糟：它用看似合理的謊言餵養下游系統。

業界自己的比較——例如 pdfmux 的 2026 parser 對決——一致顯示 parser 的選擇對準確度的影響大於模型的選擇。這是第一課：在評測模型之前，先在你的文件上評測 parser。

中立測試：LLM-Only vs Parser vs 開源

重點：在你自己的語料上跑三方測試——純文字簡單文件、掃描雜亂文件與表格——因為排名會依文件類型反轉。

2026 年的版圖有三個家族：

  • LLM-only——把文件（文字或影像）直接丟給多模態模型。在乾淨的數位 PDF 上表現良好；在複雜排版上退化。
  • 解析供應商——LlamaParse、Unstructured 與同級產品，在 LLM 之前先正規化排版。複雜文件上的 benchmark 領先者，代價是逐頁計費。
  • 開源——Docling、Marker，以及像 NuExtract3 這類較新的抽取專用模型（一個開放權重的 4B vision-language 模型，專為結構化抽取打造，可自架，詳見 NuExtract 的定價結構）。掌控力與成本上限兼得，代價是維運。

一錘定音的測試：三組文件——乾淨數位、掃描、表格密集——全部跑過三個家族，以欄位級準確度（不是「看起來差不多」的比對）、每 1,000 份文件成本與失敗率來量測。誠實的預測：LLM-only 贏下乾淨組、供應商贏下掃描組、開源在大量使用下贏下成本欄——而你的語料決定哪一欄才重要。

如何組裝 Pipeline：解析 → Schema → 抽取 → 驗證

重點：schema 設計是槓桿最高的階段——一個帶驗證的嚴格 schema，能把抽取從期望變成契約。

核心迴圈，與供應商無關——跑在統一 chat endpoint上：

import json
from openai import OpenAI

client = OpenAI()  # unified endpoint

SCHEMA = {  # the contract: required fields fail loudly
    "type": "object",
    "required": ["invoice_number", "vendor", "total"],
    "properties": {
        "invoice_number": {"type": "string"},
        "vendor": {"type": "string"},
        "total": {"type": "number"},
        "currency": {"type": "string", "enum": ["USD", "EUR", "GBP"]},
    },
}

def extract(page_text: str) -> dict:
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        response_format={"type": "json_schema", "json_schema": {"name": "invoice", "schema": SCHEMA}},
        messages=[{"role": "user", "content": f"Extract the invoice data as JSON:\n{page_text}"}],
    )
    return json.loads(resp.choices[0].message.content)

def validate(doc: dict) -> tuple[bool, list[str]]:
    errors = []
    for field in SCHEMA["required"]:
        if field not in doc or doc[field] in (None, ""):
            errors.append(f"missing required field: {field}")
    if not isinstance(doc.get("total"), (int, float)):
        errors.append("total is not a number")
    return (not errors, errors)

讓它達到正式環境等級的四條規則：

  1. Schema 是一份契約。 必填欄位、enum 與型別——由你模型的 structured-output 模式強制執行（本系列記錄的這個模式）——讓「缺失」變成錯誤，而不是一個缺席的 key。
  2. 先解析再寫 prompt。 數位 PDF 直接進 LLM；掃描文件先過 OCR 或多模態模型。模型目錄告訴你哪些模型接受影像；決策規則就是「parser 看得到文字嗎？」
  3. 信心分數與佇列。 每一次抽取都附帶信心分數；低信心的資料列進人工審查佇列，而不是資料庫。正是這個佇列讓「無聲失敗」變大聲——可重試的失敗則對應error codes參考文件。
  4. 兩端都處理 PII。 抽取前盡可能先遮蔽，抽取後再掃描——個人資料處理是合規要求，不是 pipeline 的加分項目，標準的資料隱私檢查清單原封不動地適用。

如何擴展並降低成本

重點：每 1,000 份文件的成本是一個設計數字——依文件複雜度分層、依數量批次處理，通常能砍掉一半以上。

成本模型：每 1,000 份文件成本 = 解析成本（如果有） + 模型 token × 模型費率。槓桿如下：

  1. 依文件複雜度分層。 乾淨的數位文件跑在預算級模型上；掃描或表格密集的文件走昂貴路徑。大多數 pipeline 有 70-80% 是乾淨文件，代表 70-80% 的數量付的是預算級費率——自訂路由讓逐份文件的決策變成機械化操作。
  2. 批次處理積壓。 歷史文件的大量匯入是完美的批次工作負載——容許延遲、數量龐大，而且本系列的批次折扣模式原封不動地套用 50% 折扣。
  3. 快取模板。 同一家廠商、同一個模板 = 同一個 prompt prefix。穩定的 prefix 命中快取定價，而這在抽取上比其他幾乎所有事情都重要，因為模板會重複數千次。
  4. 自建還是購買 parser。 供應商逐頁計費；開源按 GPU 小時計費。本系列的TCO 分析展示了形狀：數量門檻以下管理式勝出、門檻以上開源勝出，而門檻取決於你的維運胃口。

會默默污染資料的常見錯誤

重點：四種無聲污染模式——每一種都會產出看似合理的錯誤資料。

  1. 沒有驗證的 schema。 schema 是描述，不是關卡。沒有型別檢查與必填欄位規則，「綁定 schema」的抽取仍然會回傳空欄位，而這些空欄位會被當成資料通過。
  2. 掃描文件跳過 OCR。 文字湯進去、垃圾 JSON 出來——parser 的失敗在模型上游，沒有任何模型 prompt 能修好它。
  3. 沒有模型版本追蹤。 模型升級會改變抽取行為；沒有固定版本與回歸語料，「模型變好了」就會默默變成「欄位移位了」。請把 model 字串與 schema 一起做版本管理。
  4. 一律用前沿模型、不分場合。 用旗艦模型處理乾淨文件，是最昂貴的「不提升準確度」方式——依複雜度分層，把省下來的錢花在審查佇列上。

常見問題

只用 LLM 就能從 PDF 抽取嗎？

乾淨的數位 PDF，可以。掃描文件與複雜排版需要先過 OCR 或多模態模型——parser 決定天花板，LLM 在裡面抽取。

如何誠實地量測抽取準確度？

對照人工標註的樣本做欄位級比對（欄位、型別、值都要完全一致），逐文件類型進行——再把型別與必填欄位驗證錯誤當成獨立的指標。「看起來差不多」的比對，會產出這份指南要防止的 3% 無聲錯誤問題。

每 1,000 份文件的抽取成本是多少？

解析成本（如果有）加上你所在層級的模型 token——乾淨文件用預算級模型的成本，遠低於掃描文件用旗艦模型。依複雜度分層，平均值就會崩跌；批次處理積壓，再砍一半。

我該怎麼設計 schema？

必填欄位、enum 與型別——透過 structured output 強制執行，缺少必填欄位視為錯誤。schema 是文件與你的資料庫之間的契約，它值得享有與兩者同等的審查。

我需要解析供應商，還是開源就夠了？

在你的語料上跑三方測試。供應商在複雜排版上領先；開源（Docling、Marker、像 NuExtract3 這類抽取專用模型）在大量使用下於成本與掌控力勝出。TCO 門檻是真實且可量測的。

抽取時如何處理 PII？

抽取前盡可能先遮蔽、抽取後掃描輸出，並把留存時間降到最低——標準的資料隱私要求，對抽取出來的資料與對來源文件一樣適用。

總結

LLM 資料抽取是一門 pipeline 紀律，不是模型屬性：刻意地解析、把 schema 定義成契約、在契約內抽取、並驗證一切，讓失敗大聲。在評測模型之前先在你的文件上評測 parser、依文件複雜度分層、批次處理積壓，並把審查佇列當成一個功能。做得對，抽取是 LLM 技術棧中最可靠的高數量工作負載；做錯了，就是看似合理的錯誤資料灌進你的資料庫。

在跟 benchmark 爭論之前，先讓 100 頁跑過你的 pipeline。立即取得你的 TokSpan API Key——$5 免費額度夠你跑樣本（快速上手）——然後在你自己的發票上親眼看看每份文件的成本。