表格抽取（Table Extraction）

3 秒看懂

表格抽取是讓 AI 從文件（掃描件、PDF、網頁等）中自動定位表格區域、還原行列結構、並逐單元格提取內容的技術。它是 Document AI（文件智慧）管線中最核心、也最具商業價值的子任務之一——金融、醫療、保險、供應鏈中的結構化資料遷移，幾乎都繞不開這一步。

3 分鐘產業解釋

為什麼表格抽取是一門好生意？

企業數字化轉型中，80% 以上的企業資料以非結構化或半結構化文件形式存在（行業廣泛引用的定性判斷，具體比例因統計口徑而異）。其中，表格是最具資訊密度的結構——財務報表、發票、保單、檢驗報告……核心資訊幾乎都以表格承載。

傳統的做法是人工錄表：一個熟練錄入員處理一張複雜表格可能需要 5-15 分鐘，錯誤率在 1%-5% 之間（因文件質量而異）。當金融機構每年需要處理數百萬份財報/公告時，這個成本和準確率瓶頸就變得不可接受。

表格抽取的價值公式：

降本：自動化替代人工錄入，單頁處理成本從數元降至極低
提速：從分鐘級降至秒級甚至毫秒級
提質：在標準文件上，AI 提取準確率可以接近甚至超過人工（具體取決於文件複雜度和系統成熟度）
規模化：支援海量文件併發處理，這是人力根本無法做到的

誰在買單？

行業	典型場景	痛點
金融	年報/季報財務表提取、IPO 招股書解析	海量 PDF，表格巢狀、跨頁、合併單元格
保險	保單、理賠單據結構化	表格格式五花八門
醫療	檢驗報告、病歷表格	手寫+印刷混排、低掃描質量
政務/法務	判決書、招標檔案、合同附表	掃描件質量參差不齊
供應鏈	裝箱單、發票、報關單	多語言、多模板

15 分鐘專家深入

技術全景：表格抽取不只是 OCR

很多人的第一反應是”表格抽取 = OCR + 正則”。這是十年前的認知。現代表格抽取是一個多階段管線（pipeline），每一階段都有獨立的技術挑戰：

┌─────────────────────────────────────────────────────────┐
│                   表格抽取完整管線                        │
│                                                         │
│  輸入文件（掃描件/PDF/圖片）                               │
│        │                                                │
│        ▼                                                │
│  [階段1] 頁面預處理 ─── 去噪、傾斜校正、解析度歸一化       │
│        │                                                │
│        ▼                                                │
│  [階段2] 表格檢測 (Table Detection)                      │
│        │    目標定位頁內所有表格的邊界框                     │
│        │    困難點：表格與周圍文本的分界、巢狀表格            │
│        ▼                                                │
│  [階段3] 表格結構識別 (Table Structure Recognition)       │
│        │    還原行列邏輯：誰是表頭？合併單元格邊界？          │
│        │    這是技術最硬的骨頭                              │
│        ▼                                                │
│  [階段4] 單元格內容提取 (Cell Content Extraction)          │
│        │    對每個單元格區域做 OCR + 文本後處理              │
│        ▼                                                │
│  [階段5] 結構化輸出                                      │
│        │    HTML / JSON / CSV / DataFrame / 知識圖譜三元組  │
│        └─────────────────────────────────────────────────┘

關鍵區分：

表格檢測（Table Detection）：回答”表格在哪”——本質上是目標檢測問題
表格結構識別（Table Structure Recognition, TSR）：回答”表格長什麼樣”——行/列/表頭/合併單元格的邏輯結構
端到端方法：同時完成檢測 + 結構識別 + 內容提取，用一個模型搞定

這三個概念經常被混淆，但在技術選型和評估時必須區分。

核心技術流派

1. 基於規則與啟發式的方法（~2015年以前主流）

依賴線條檢測（Hough 變換）、文本塊對齊分析、投影直方圖
優點：可解釋、在格式規整的文件上效果尚可
致命缺陷：對無線表（borderless tables）、掃描件噪聲、傾斜/摺疊極其脆弱
今天仍在部分傳統 OCR 廠商的老系統中執行

2. 基於 CNN 目標檢測的方法（~2018-2021 主流）

表格檢測借用經典目標檢測架構（Faster R-CNN、Cascade R-CNN、RetinaNet 等變體）
表格結構識別開始引入圖神經網路（GNN）和注意力機制
代表工作：Cascade TabNet、GTE（Graph-based Table Extraction）等
引擎：以 PyTorch、TensorFlow 為基礎架構

3. 基於 Transformer / Vision Transformer 的方法（~2021至今主流）

TableFormer（IBM 發表）：用 Transformer encoder-decoder 架構直接預測表格結構序列，用空間注意力處理單元格座標
TSRFormer：針對表格結構識別的專用 Transformer 變體
Donut（Naver Clova）：將文件理解建模為純序列到序列問題（影像→文本序列），無需 OCR 引擎，代表了 OCR-free 範式
Pix2Struct（Google）：將網頁/文件截圖解析為結構化輸出，表格是核心任務之一
核心創新點：將表格結構預測建模為序列生成問題，而非傳統的檢測框 + 後處理拼接

4. 多模態大型模型方法（2023至今，正在快速演進）

GPT-4V / GPT-4o、Claude 3.x、Gemini 等多模態 LLM 可直接處理文件影像，輸出結構化表格
優勢：零樣本/少樣本能力強，對複雜、非標表格有驚人的泛化能力
侷限：
- 幻覺問題：可能”編造”表格中不存在的資料，這在金融/醫療場景是致命的
- 精度不夠：在細粒度單元格級別，專用模型仍優於通用 LLM（至少截至當前階段）
- 成本與延遲：大型模型推論成本遠高於專用模型
- 合併單元格仍然是公認的難點——大型模型也容易在這裡出錯
定性判斷：專用管線（pipeline）在生產環境中仍是主流，但 LLM 正在作為”兜底”或”增強”角色被整合進來

結構識別為什麼是最難的一步？

表格檢測本質上就是目標檢測，用成熟架構基本可解。但表格結構識別的難度完全不同：

合併單元格（spanning cells）：一個單元格橫跨多列或多行，需要準確識別其邊界和歸屬
跨頁表格：一個表格被分頁截斷，表頭在上一頁，資料在下一頁
巢狀表格：表格中套表格，常見於複雜報表和招標檔案
無線表格（borderless tables）：沒有線條，僅靠文本對齊表達表格結構——這是人類靠視覺慣性可以理解，但演算法極難的場景
手寫 + 印刷混排：醫療和某些法律場景
多層表頭：財務報表中常見的多級列標題

技術原理（深入機制層）

表格結構識別的兩種主流建模範式

範式一：基於目標檢測的自底向上（Bottom-Up）

思路：先檢測每個單元格 → 再推斷行列歸屬

步驟：
1. 使用檢測網路（如 Cascade R-CNN 變體）檢測所有單元格的邊界框
2. 對檢測到的單元格做空間聚類：
   - y 座標相近的單元格 → 歸為同一行
   - x 座標相近的單元格 → 歸為同一列
3. 合併單元格檢測：若某單元格的 x/y 範圍覆蓋多個列/行位置 → 標記為 spanning cell
4. 表頭識別：基於位置（通常在頂部）+ 語義特徵

優點：直觀，容易除錯
缺點：錯誤累積——單元格檢測的誤差會傳播到行列推斷

範式二：基於序列生成的自頂向下（Top-Down，Transformer 系主流）

思路：將表格結建置模為 token 序列，直接生成 HTML/結構標籤序列

核心思路（以 TableFormer 類方法為例）：
1. 影像編碼器（通常是 CNN backbone 或 ViT）提取文件影像的視覺特徵
2. Transformer decoder 自迴歸地生成結構標記序列，例如：

         Year      ← 合併單元格用 rowspan/colspan 表示
         Revenue

         Q1
         Q2

      ...

3. 同時預測每個 token 對應的空間座標（用於將單元格內容與 OCR 結果對齊）

優點：端到端、避免錯誤累積、天然處理合併單元格
缺點：長序列生成可能自迴歸出錯、需要大量標註資料訓練

OCR-Free 範式（Donut 類）

思路：不做顯式 OCR，直接將文件影像對映為結構化文本

模型架構：
  Swin Transformer（影像編碼器）
        ↓
  BART Decoder（文本序列解碼器）
        ↓
  輸出：直接是結構化序列（HTML/JSON）

訓練：使用  格式的標註
推論：輸入影像 → 輸出結構化表格文本

關鍵點：模型隱式學習了 OCR 能力 + 結構理解能力，但精度
        在低解析度或複雜文件上可能不如顯式 OCR 管線

評估指標（為什麼準確率數字要小心看）

表格抽取的評估指標非常碎片化，不同論文、不同資料集用的指標可能完全不同，直接對比數字是危險的：

指標	評估什麼	常見問題
IoU（Intersection over Union）	表格檢測框的準確度	閾值選擇影響大（0.5? 0.75? 0.9?）
mAP（mean Average Precision）	檢測任務綜合表現	COCO-style vs. VOC-style 演算法不同
Tree-Edit-Distance (TED)	表格結構樹的編輯距離	越低越好，但對合並單元格敏感
Ancestors / Precision / Recall	單元格歸屬關係的準確度	PubTables-1M 等資料集用
片段級 F1	文本內容提取的匹配度	對 OCR 誤差敏感

⚠️ 常見誤導：某論文聲稱”在 XX 資料集上達到 98% 準確率”——你需要追問：是檢測準確率還是結構準確率？是簡單表格還是複雜表格？是 clean PDF 還是掃描件？合併單元格的召回率多少？這些細節決定了指標的實際意義。

技術演進史

階段	時間	代表技術	核心突破	侷限
規則時代	~2000-2015	線條檢測 + 投影分析 + 啟發式規則	可工程化落地	只能處理有線、格式固定的表格
深度學習早期	2015-2018	CNN 檢測表格區域 + 傳統後處理	自動定位表格	結構識別仍依賴規則
端到端檢測	2018-2020	Faster R-CNN / Cascade R-CNN 變體用於表格檢測；GNN 開始用於結構識別	檢測精度大幅提升	檢測與結構識別仍是分開的模型
Transformer 革命	2020-2023	TableFormer、Pix2Struct、Donut、TSRFormer 等	端到端建模、OCR-free 成為可能	需要大量標註資料；合併單元格仍是硬傷
大型模型時代	2023-至今	GPT-4V/4o、Gemini、Qwen-VL、InternVL 等多模態 LLM 做零樣本表格提取	無需針對特定格式訓練	幻覺風險、精度未超越專用模型、成本高

標註資料的里程碑事件：

PubTabNet（2019，IBM）：~50 萬表格影像 + HTML 標註（來自 PubMed）
FinTabNet（2021，IBM）：~11 萬金融年報表格，覆蓋複雜合併單元格
PubTables-1M（2021，Microsoft）：~100 萬表格，提供單元格級別邊界框標註 + 結構標註，顯著推動了 TSR 研究
這些公開資料集的出現是推動技術從”可演示”走向”可落地”的關鍵基礎設施

技術路線對比

維度	規則/啟發式	CNN 目標檢測	Transformer/序列生成	多模態 LLM
無線表格處理	差	中	良	優（零樣本泛化強）
合併單元格	差	中	良（顯式 rowspan/colspan 建模）	中（仍易出錯）
跨頁表格	差	差（單頁模型）	需額外邏輯	中（取決於 context window）
推論速度	極快	快	中（自迴歸解碼較慢）	慢（大型模型推論成本高）
部署複雜度	低	中	高	極高（需 GPU 叢集或 API 呼叫）
泛化能力	極差	中（需同分布訓練資料）	良	優
標註資料需求	無	大量	大量（結構級標註成本高）	少/零樣本
可解釋性	高	中	低	低
生產環境主導度（當前）	遺留系統	仍有相當部署	當前主流技術選型	開始試點，尚未規模化

上下游

上游（表格抽取依賴什麼）

層級	要素	說明
模型層	目標檢測 / Transformer 架構	PyTorch / TensorFlow / ONNX Runtime
OCR 引擎	文字識別	Tesseract、PaddleOCR、商業 OCR（ABBYY 等）——除非走 OCR-free 路線
GPU/算力	推論和訓練	訓練需要 GPU 叢集；推論可用 GPU 或最佳化後的 CPU/邊緣部署
標註資料	訓練樣本	表格影像 + HTML/JSON 結構標註，標註成本高昂（需專業標註員理解表格語義）
文件預處理	影像質量	掃描件去噪、傾斜校正、解析度增強（超解析度模型可輔助）

下游（表格抽取餵給誰）

應用	說明
RPA / 流程自動化	提取的結構化資料直接填入 ERP / 財務系統
知識圖譜建置	表格 = 結構化實體關係，直接轉化為三元組
RAG（檢索增強生成）	表格資料作為 LLM 的高質量結構化知識源
資料分析 / BI	非結構化報表 → DataFrame → 分析儀表盤
合規 / 審計	自動比對不同文件中的表格資料一致性
搜尋 / 問答	讓使用者直接對文件中的表格進行語義搜尋和問答

關鍵指標

技術指標

指標	定義	行業基準範圍（估算，因資料集/文件型別差異大）
表格檢測 mAP	表格區域定位的平均精度	高質量 PDF：行業報道常在 90%+ 範圍；掃描件：顯著下降 [因文件質量差異大]
結構識別 TED	樹編輯距離，越低越好	簡單表格：可接近 0；複雜合併單元格表格：仍有顯著差距
單元格內容準確率	逐單元格文本提取的精確度	依賴 OCR 質量 + 結構識別質量，乘法關係
端到端 F1	從原始文件到最終結構化輸出的綜合得分	最具實際意義但最不可比較（評估標準未統一）
處理延遲	單頁/單表處理時間	專用模型：數百毫秒至數秒；LLM：數秒至數十秒
吞吐量	批次處理能力	取決於併發 GPU 數量和管線最佳化程度

業務指標

指標	說明
人工複核率	提取結果需要人工校正的比例——這才是企業真正關心的
欄位級準確率	關鍵業務欄位（金額、日期、程式碼）的提取準確率
零模板覆蓋	能否處理從未見過的新格式表格——衡量泛化能力

供需與市場資料

市場規模（定性）

文件 AI / 智慧文件處理（IDP）是 AI 應用層增長最快的賽道之一
表格抽取作為 IDP 的核心能力，市場隨 IDP 整體增長
各大諮詢機構對 IDP 市場規模的估算口徑不同，但趨勢一致：快速增長
具體數字：各報告口徑差異較大，本文不引用具體金額以避免誤導——如需精確數字建議參考 Gartner、IDC、MarketsandMarkets 等機構的原始報告並注意其定義範圍

供需格局

供給側	需求側
雲端廠商整合（Microsoft、Google、AWS、阿里雲端、百度智慧雲端）	企業數字化轉型驅動海量文件處理需求
專業 IDP 廠商（ABBYY、Rossum、Instabase 等）	金融/保險/醫療/政務的合規剛需
開源方案（PaddleOCR/PP-Structure、DocTR 等）	從人力外包轉向 AI 自動化
垂直行業 SaaS	端到端業務流程自動化需求

供需痛點

供給端：複雜表格（跨頁、巢狀、手寫、非標格式）仍是技術瓶頸；高質量標註資料稀缺且昂貴
需求端：客戶期望”一鍵搞定所有格式”，但實際上不同文件型別需要不同的處理策略和模型調優

代表公司與資本對映

全球主要玩家

公司	定位	產品/技術	備註
Microsoft	雲端 + Document AI	Azure AI Document Intelligence（原 Form Recognizer）	內建表格提取能力；發表了 PubTables-1M 資料集
Google	雲端 + Document AI	Document AI - 表格解析處理器	Pix2Struct 等研究輸出
AWS	雲端 AI 服務	Amazon Textract	自動檢測和提取表格
IBM	研究 + 產品	IBM DataCap + Research（TableFormer 等）	表格抽取領域的重要研究貢獻者
ABBYY	專業 IDP 廠商	ABBYY Vantage / FlexiCapture	老牌 OCR/文件處理廠商，表格提取是核心能力
Naver Clova	AI 研究 + 產品	Donut（OCR-free 模型）	開源，OCR-free 範式代表
Instabase	AI 原生 IDP 平台	自動化文件處理平台	融資階段的 AI 初創公司
Rossum	專注發票/單據	AI 資料採集平台	專注財務單據表格提取

中國主要玩家

公司	產品/技術	特點
百度	PaddleOCR / PP-Structure	開源，社群活躍，表格結構識別能力持續迭代
阿里雲端	智慧文件處理 IDP	阿里雲端 AI 服務的一部分
合合資訊	TextIn 系列	文件智慧領域專注公司，涵蓋表格提取
科大訊飛	文件智慧產品線	OCR + 文件理解能力
達觀資料	智慧文件處理	專注 NLP + 文件處理

資本對映邏輯

雲端巨頭：表格抽取是 Document AI 雲端服務的差異化能力，直接影響企業客戶選擇哪家雲端
IDP 專業廠商：受益於企業 IDP 採購預算從”自建”轉向”買服務”
開源社群：PaddleOCR、Donut 等降低了技術門檻，但商業化需要上層應用包裝

投資邏輯

看多邏輯

需求剛性且增長：企業數字化 = 更多文件數字化 = 更多表格需要自動提取，這是結構性需求而非週期性需求
付費意願強：金融/保險/醫療等行業的人工錄表成本高，ROI 計算清晰——能算清賬的 AI 應用最容易賣出去
大型模型賦能天花板提升：多模態 LLM 讓表格抽取的泛化能力大幅提升，過去”每個客戶模板都要調”的困局正在被打破
與 RAG / Agent 結合：企業 RAG 系統需要高質量結構化知識，表格抽取是”喂資料”的關鍵環節——這是 AI 應用基礎設施級別的能力
行業資料壁壘：不同行業的表格格式差異巨大，先積累垂直行業資料和 know-how 的公司有護城河

看空/風險

開源衝擊：PaddleOCR、Donut 等開源方案不斷逼近商用質量，純做”模型 API 呼叫”的公司缺乏壁壘
大型模型吞噬：通用多模態 LLM（GPT-4o、Gemini 等）的表格提取能力持續提升，專用管線可能被”一步到位”的大型模型替代
標註資料瓶頸：高質量表格標註仍依賴人工，成本高、速度慢，制約模型迭代速度
準確率瓶頸：複雜表格（合併單元格、跨頁、手寫）的準確率仍未達到”無需人工複核”的水平，客戶滿意度天花板明顯
同質化競爭：技術方案趨同，價格戰風險

關鍵觀察指標

專用模型 vs. 通用大型模型在複雜表格上的精度差距變化趨勢
企業 IDP 採購預算增速（反映需求端健康度）
行業頭部客戶的”人工複核率”下降曲線（反映技術實際落地效果）
開源模型效能追趕速度

常見誤讀糾偏

❌ 誤讀一：“表格抽取就是 OCR 加個框”

糾偏：OCR 只解決”單元格里寫了什麼字”的問題。表格抽取的核心難點是結構識別——弄清楚哪些單元格屬於同一行、哪些屬於同一列、表頭在哪裡、合併單元格的邊界是什麼。一個 OCR 精度 99% 的引擎，如果結構識別搞錯了行列歸屬，輸出的表格照樣是”垃圾資料”。很多人高估了 OCR 的重要性，低估了結構理解的難度。

❌ 誤讀二：“大型模型可以直接替代所有表格抽取管線”

糾偏：多模態 LLM 在零樣本場景下確實展現了令人印象深刻的能力，但在生產環境中存在致命缺陷：

幻覺風險：大型模型可能生成表格中並不存在的資料。在財務/醫療場景，一個”幻覺”出來的數字可能導致嚴重後果
精度天花板：在精細的單元格級別，特別是複雜合併單元格場景，專用模型（在有標註資料的情況下）仍然優於零樣本大型模型
成本與延遲：對每頁文件呼叫一次大型模型 API 的成本遠高於專用小模型推論
可控性：專用管線可以做逐環節審計和除錯；端到端大型模型出錯時很難定位原因

實際趨勢：不是”替代”而是”增強”——大型模型作為兜底或後處理驗證角色嵌入專用管線中。

❌ 誤讀三：“在 PubTabNet 上 F1 達到 99% 就說明表格抽取問題已解決”

糾偏：公開基準資料集的表格大多來自學術論文 PDF——格式規整、掃描質量高、合併單元格少。現實世界的文件（手寫發票、三十年前掃描的保單、摺疊過的裝箱單、多層表頭的財報）要複雜得多。公開 benchmark 的成績與實際生產環境的效果之間存在顯著差距。評估表格抽取系統時，一定要看它在你的實際文件型別上的表現，而非通用 benchmark 分數。

❌ 誤讀四：“開源方案已經夠用了，不需要商業產品”

糾偏：開源方案（PaddleOCR PP-Structure、Donut 等）在標準場景下確實表現不錯，但企業生產環境的需求遠不止”跑個模型”：合規審計、資料安全、SLA 保障、多語言支援、API 穩定性、大併發處理、私有化部署……這些工程化和合規需求是開源方案無法直接滿足的，也是商業 IDP 產品定價的基礎。

學習路徑

入門（2-4 周）

理解任務定義：閱讀 Microsoft PubTables-1M 論文（Smock et al., 2021），理解表格檢測與結構識別的區別
動手體驗：
- 使用 PaddleOCR 的 PP-Structure 模組跑幾張表格圖片，觀察輸出
- 試試 Google Document AI 或 Azure AI Document Intelligence 的線上 demo
認知邊界：在不同型別的文件上測試——乾淨 PDF、掃描件、無線表格、有合併單元格的表格——感受技術的真實能力邊界

進階（1-2 月）

讀核心論文：
- TableFormer（Prasad et al., 2022, IBM）——Transformer 做表格結構識別的代表作
- Donut（Kim et al., 2022, Naver）——OCR-free 範式
- Pix2Struct（Lee et al., 2023, Google）——網頁/文件截圖解析
理解評估體系：深入理解 TED（Tree-Edit-Distance）等結構級評估指標
實操：在 PubTabNet / FinTabNet / PubTables-1M 上微調一個模型

專家（持續）

追蹤最新進展：關注多模態 LLM 在文件理解任務上的進展（GPT-4V/4o、Gemini 1.5 Pro 的 Document Understanding 能力）
關注行業落地：瞭解金融、醫療等垂直行業的真實需求和合規約束
思考架構演進：專用管線 → 大型模型增強管線 → 端到端大型模型，這個演進路徑的時間表和條件是什麼

一句話總結

表格抽取是 Document AI 中技術密度最高、商業價值最明確的核心能力；當前 Transformer 序列生成方法是主流技術路線，多模態 LLM 正在作為增強力量介入，但複雜表格的”最後一公里”（合併單元格、跨頁、非標格式）仍未完全解決——這既是技術挑戰，也是創業機會的視窗。

延伸閱讀與來源

學術論文（按重要性排序）

PubTables-1M（Smock et al., 2021, Microsoft Research）——推動 TSR 研究的里程碑資料集
TableFormer（Prasad et al., 2022, IBM Research）——Transformer 表格結構識別的代表工作
Donut: OCR-free Document Understanding Transformer（Kim et al., 2022, Naver Clova）——OCR-free 範式
Pix2Struct（Lee et al., 2023, Google）——截圖到結構化輸出
CascadeTabNet（2020）——基於 Cascade R-CNN 的表格檢測
FinTabNet（Zheng et al., 2021, IBM）——金融文件表格資料集

產業報告

Gartner — Magic Quadrant for Cloud AI Developer Services（關注 Document AI 相關能力評估）
IDC — Intelligent Document Processing 市場追蹤
各雲端廠商產品文件：Azure AI Document Intelligence、Google Document AI、Amazon Textract

開源專案

PaddleOCR / PP-Structure（百度）：https://github.com/PaddlePaddle/PaddleOCR
Donut（Naver Clova）：https://github.com/clovaai/donut
TableTransformer（Microsoft）：https://github.com/microsoft/table-transformer
DocTR（Mindee）：https://github.com/mindee/doctr

⚠️ 宣告：本頁內容中，具體模型效能指標、市場資料等均標註為定性判斷或行業估算，未引用具體數字以免誤導。如需精確資料，請查閱原始論文和行業報告。技術趨勢判斷基於截至編寫時的公開資訊，AI 領域技術迭代速度極快，請結合最新動態使用。