超越 OCR 的文件理解

常見的文件處理基準流程從光學字元辨識（OCR）開始：把頁面轉成文字、替文字建立索引，再讓檢索系統或大型語言模型（LLM）根據這些文字回答問題。

只要扁平文字保留了任務所需的證據，這套基準做法就可能行得通；一旦意義取決於多欄版面、表格或跨文件參照，就需要額外檢查。

實際營運中的檔案，除了句子之外還帶有結構。單一 PDF 文件包可能同時包含封面頁、按房型分類且跨越多頁的季節性房價表、取消條款、無障礙附錄，以及不適用日期（blackout dates）附表。把這些內容全部壓成一條不分層次的文字流，就會抹掉判斷哪些內容屬於同一組的結構線索：哪一行是統轄下文的標題、哪一則是圖說或註腳、哪一格是欄表頭，以及哪一筆每晚房價對應哪種房型與季節。

純文字檢索在這類檔案上可能失靈，原因之一就是結構遺失：文件是結構化的證據物件，而不是一整塊文字。還原字元只是第一步；下游系統還需要足夠的版面、表格與階層結構，才能組裝出可查核的證據。

本篇以 OCR 為基準，再逐一建立正式環境的文件智慧（document intelligence）管線真正需要的階段：版面分析（layout analysis）、閱讀順序還原、表格結構重建、邏輯文件分割、文件層級與跨文件連結，以及帶溯源（provenance）的證據擷取。貫穿全文的範例是 OptiVerse Travel 的旅行規劃 Copilot，它必須橫跨飯店合約、費率附錄、無障礙規格與預訂確認函，重建一份可供檢查的證據資料包。

為什麼純文字檢索在真實文件上失敗

假設旅遊規劃師提出以下需求：

針對合約 KYO-H12，從合約條款、費率附錄、無障礙附錄與預訂確認函中擷取所有房價與無障礙規格，並標示任何不一致之處。

純文字檢索流程乍看很合理：

1. 從每個檔案擷取純文字。

2. 將文字切分為區塊（chunk）。

3. 為區塊建立檢索索引。

4. 檢索與 KYO-H12 相關的段落。

5. 交由 LLM 摘要作答。

查詢需要的文件結構若已在純文字表示中遺失，這條流程就可能失敗。這次查詢暴露出五個這類缺口。

第一，閱讀順序經常含糊不清。把雙欄合約壓成單一文字流，可能讓左右兩欄的句子交錯混排、把註腳插進段落中間，也可能讓圖說與它所說明的表格脫鉤。

第二，文件層級隨之消失。標題統轄其下方的內容；章節邊界一旦消失，檢索就可能拉回看似相關、實際上屬於其他定價季節、附錄或免責條款章節的句子。

第三，扁平化可能讓表格儲存格與所屬列、欄的表頭脫鉤。看看這行擷取結果：

KYO-H12 Standard 18500 22000 Accessible 21000 25000

單憑這些數值，無法確定特定房型與季節的費率；仍須依靠表格結構，才知道季節、幣別、房型，以及某個數字來自基本房價欄還是含餐房價欄。

第四，一個檔案可能包含多份邏輯文件。單一上傳的 PDF 可能同時裝訂合約條款、費率附錄與無障礙附錄；系統若把整個檔案當成一個單位建立索引，檢索與答案合成就可能混淆原本應該分開的主張。

第五，跨文件比對很脆弱。合約條款可能引用 KYO-H12，費率附錄可能改用預訂參考號，無障礙附錄可能使用旅宿代碼，預訂確認函則可能把同一家飯店編碼在訂房系統欄位裡。純文字流程很少能可靠地對上這些別名。

檢索品質只是問題的一部分：表示法本身可能早已缺少這項任務所需的關係。可靠的管線會先還原結構，再檢索、正規化與比對證據。

選擇直接文字擷取、OCR 或影像解析

許多下游文件任務都需要機器可讀的內容，但獨立的 OCR 步驟只是取得內容的方法之一。原生數位 PDF 可能直接提供可靠的內嵌文字；掃描的合約與翻拍頁面則需要 OCR 或視覺式解析。Donut 這類無 OCR（OCR-free）模型直接把頁面影像對應成結構化輸出，提出它的部分動機正是避免 OCR 錯誤一路傳播（Kim 等人，2022）。

使用 OCR 時，它解決的是字元還原，而不是完整的文件理解。

團隊常把兩者混為一談：除錯畫面上的擷取文字看起來通順，就很容易以為管線已經讀懂頁面。字元轉錄只是整體表示的其中一層；即使每個字都正確，閱讀順序仍可能錯亂，章節邊界可能遺失，表頭可能脫鉤，註腳也可能被併入正文。

文件系統裡反覆出現這種誤解：

只要 OCR 把字都認對了，就算讀懂文件了。

這句話不成立，道理就跟「轉錄不等於分析」一樣：費率表上的每個字元都可能轉錄正確，價格卻仍然對到錯誤的房型。

OCR 本身也有失敗模式。辨識錯誤可能一路連鎖到後續步驟，尤其當下游邏輯依賴精確的識別碼、單位或價格時。若 OCR 把 KYO-H12 誤認成 KYO-H1Z，或讓每晚房價少了一位數，而管線又沒有保留溯源與驗證訊號，檢索與比對就可能在毫無警示的情況下失敗。

因此，文件智慧屬於處理管線或架構層，不是單一的 OCR 功能。

版面和閱讀順序承載意義

字元可以還原之後，管線還得判斷頁面上的區塊如何排列、順序為何。

版面分析負責辨識有意義的區域，例如標題、內文段落、頁首、註腳、清單與表格；邊界框（bounding box）記錄每個區塊在頁面上的位置；閱讀順序則決定這些區域該依什麼先後次序解讀。

頁面幾何可能改變法律與商業上的意義。

假設一份飯店合約 PDF 包含：

• 標題頁與合約摘要

• 雙欄排版的費率表章節

• 橫跨兩欄的表格

• 說明某項費率僅適用櫻花季、且設有最低連住晚數的註腳

• 附在同一份 PDF 後面的無障礙附錄

欄位順序一旦錯亂，可能把不相干的條款接在一起；櫻花季註腳一旦脫鉤，報出的房價就可能少了季節與最低連住晚數的條件；漏判附錄邊界，則可能在不告知使用者的情況下，把無障礙規格混進主費率表。

版面感知模型把頁面位置與文字、視覺特徵一起編碼，藉此減少這些錯誤：LayoutLMv3 聯合預訓練文字、版面與影像表示；LayoutReader 論文提出的 ReadingBank 基準，則把閱讀順序偵測當成獨立任務來評測（Huang 等人，2022；Wang 等人，2021）。

經驗法則是：如果答案取決於頁面上某個區塊的上方、下方、旁邊或內部有什麼，你面對的就不是純文字問題。

表格是結構化物件，不是帶分隔符號的段落

表格是文件管線最常出錯的地方之一，值得單獨處理。

表格不只是把文字排得比較緊湊。它是結構化物件，連結了表頭儲存格、列標籤、欄群組、單位、合併儲存格，往往還有註腳；下游系統必須保有這些關係，才能正確回答量化問題。

試想一張季節性房價表跨越掃描合約附錄的兩頁：第一頁有表頭列與前幾種房型，第二頁延續各列，只重複部分表頭，並加上一則關於不適用日期與季節附加費的附註。扁平文字擷取器可能產出可讀的字串，卻破壞了網格：

• 重複的表頭可能被丟棄

• 合併儲存格可能被錯誤展開

• 幣別可能與它所修飾的數值分離

• 延續列可能被當成新的表格

• 附註可能與它所修飾的儲存格脫離

從這種破損輸出檢索扁平文字片段，等於誘使生成模型引用錯誤的季節欄、錯誤的幣別或錯誤的房型。

因此，表格擷取通常包含幾個不同的任務；PubTables-1M 把表格偵測、結構辨識與功能分析分開，明確呈現了這種切分（Smock、Pesala 與 Abraham，2022）：

• 偵測表格的位置

• 重建列與欄的結構

• 辨識哪些儲存格作為表頭

• 把附註、幣別與延續頁連回表格

把這些子任務分開，有助於團隊別把「抓到表格文字」誤當成「還原了表格結構」。

對旅行規劃 Copilot 來說，要求列出所有房價與無障礙規格，實際上就是要求結構化的表格證據。少了表頭歸屬與列欄關係，系統就無法有把握地比較數值。

一個檔案可能包含多個邏輯文件

另一個結構陷阱在頁面解析開始之前就出現了：把一個實體檔案等同於一份邏輯文件。

這個假設往往不成立。

單一 PDF 可能把飯店主合約與季節費率表接在一起；內部訂房文件包可能把封面頁、航班行程、保險條款與無障礙增補文件綁成一份；廠商的掃描檔可能把附函、報價表與發票合併在一起。檔案容器與邏輯文件邊界不一定一一對應。

文件分割（document splitting）負責找出這些邏輯邊界。實務上可以使用頁面分類、章節轉換偵測、中繼資料線索，或用工作流程規則檢查標題、重複出現的頁首或附件標記。

在本篇的案例中，一份上傳的 PDF 可能同時裝著四份不同的文件：

• 飯店 KYO-H12 的合約條款

• 載有季節性定價表的費率附錄

• 載明客房與設施規格的無障礙附錄

• 附有手寫批註的單頁掃描增補文件

這四份文件若一直合在一起，下游好幾個環節都會變差：

• 檢索範圍充滿雜訊

• 溯源更難解釋

• 答案合成可能把無法相比的證據湊在一起

• 比對邏輯可能沒發現，不同文件角色描述的其實是同一間旅宿

純文字 RAG 在這裡容易表現不佳，因為文字檢索假設區塊已經是合理的語意單元；文件智慧往往得先把這些單元切出來。

文件內部結構與跨文件關係

即使還原了頁面、區塊與表格，仍有兩種不同的關係結構要釐清。

在單一邏輯文件內，下列這類階層連結界定了解讀範圍：

• 標題對應章節

• 章節對應子章節

• 段落對應清單

• 章節對應表格

• 圖片對應圖說

• 註腳對應被引用的正文

局部範圍能避免錯誤的等同：Peak Season Rates（旺季房價）章節底下的每晚房價，不等於描述促銷優惠或團體折扣的附錄裡表面上相似的數值。

跨越不同邏輯文件時，下列這類關係構成的是圖，而不是嚴格的樹：

• 合約條款對應費率附錄

• 合約對應無障礙附錄

• 預訂確認函對應行程匯出檔

• 主條款對應附屬明細表

證據往往以多檔案文件包的形式送達，而不是單一的權威紀錄，因此管線必須釐清：哪些檔案屬於同一份協議、哪些引用跨文件指向彼此，以及哪些識別碼別名對應到同一間旅宿或同一筆預訂。

這正是證據資料包（evidence packet）成為實用設計模式的地方。與其把一大堆原始文字丟給生成模型，管線會先組裝出結構化的主張、費率、規格與引用，並附上明確的來源連結，再讓答案模型根據這份資料包作答。如此一來，擷取品質、實體比對與答案品質就能分別評估，不會全擠進一個不透明的生成步驟。

量測每個重建階段

解析成功率反映的是營運健康度，不能證明擷取出的事實正確。請替後果嚴重的文件類別建立有標註的標準答案，並用各自適用的指標評估每一次轉換。

文字辨識階段可採用正規化編輯距離，計算可重現的字元錯誤率（CER）或詞錯誤率（WER）：

CER 或 WER = (替換 + 刪除 + 插入) / 參考單位數

美國國家標準暨技術研究院（NIST）的 TRAIT 評測定義了文字辨識的字元層級與詞層級正規化編輯距離（NIST IR 8199）。即使整份語料的 CER 很低，仍可能藏著損壞的合約 ID 或價格錯誤，因此關鍵識別碼與金額的完全一致率，要和整體 CER／WER 分開報告。

評分前先宣告文字正規化與切分規則：例如 CER 以 Unicode 碼位（code point）為單位，WER 使用指定的斷詞器，因為英文以空白切詞的做法無法定義繁體中文的詞。插入錯誤可能讓 CER 或 WER 超過 1.0，空的參考字串也需要明確的處理慣例。關鍵 ID 與金額仍須和來源精確比對，空白或低信心的擷取結果絕不能硬轉成數值零。

表格方面，GriTS 直接以網格形式評分預測表格，並分成拓撲、內容與位置三種變體（Smock、Pesala 與 Abraham，2023）；TEDS 則以預測與參考 HTML 表格樹之間的正規化樹編輯距離換算相似度分數（Zhong、ShafieiBavani 與 Jimeno Yepes，2020）。請讓指標配合解析器的輸出表示，報告表格分數時也要寫明指標與變體。

完整範例：重建證據資料包

假設 OptiVerse Travel 的旅遊規劃師要求列出合約 KYO-H12 所有已載明的房價與無障礙規格，範圍橫跨主合約、費率附錄、無障礙增補文件，以及行程 JPN-2026-0417 的預訂確認函，並標出任何不一致之處。

針對這項請求，一條文件智慧管線可以分成八個可檢查的階段：

1. 檢查每個上傳檔案。

判斷每個檔案是原生數位 PDF、掃描檔、以圖像為主的頁面集，還是包含多份邏輯文件的合併文件包。

1. 以合適的基準解析文字。

頁面是影像時用 OCR；PDF 含可靠的內嵌文字時直接擷取文字；若架構符合營運限制，也可選用無 OCR 解析器。

1. 還原頁面結構。

辨識頁面區域、閱讀順序、標題、清單、註腳、表格，以及可能的文件邊界。

1. 重建表格。

偵測表格區域、保留表頭結構，並在適當時把延續頁合併成一張邏輯表格。

1. 分割邏輯文件。

合約條款與費率附錄、無障礙附錄裝訂在同一個檔案時，把它們分開。

1. 跨文件比對實體。

在證據顯示指向同一家飯店或同一筆行程時，連結 KYO-H12、預訂參考號、旅宿代碼與訂房系統 ID。

1. 建立結構化證據資料包。

儲存擷取出的數值、幣別、限定條件、信心訊號，以及頁面層級或儲存格層級的溯源。

1. 比對與合成。

證據資料包建立之後，才讓下游模型整理不一致之處，或產生給使用者看的說明。

這條管線的環節比 OCR 加 RAG 多，因為它解決的是另一個問題：不是從鄰近區塊生成看似合理的答案，而是忠實重建證據，讓跨文件的不一致浮上檯面、可供檢查。

輸出不是一段單薄的摘要，而是一份可檢查的證據資料包，內容大致如下：

• JPY 22,000 標準房旺季房價，源自合約條款第 4 頁、Clause 4.3，費率表 Standard 列、Peak 欄

• JPY 25,000 無障礙房旺季房價，源自 rate-appendix-scan.pdf 檔內第 2 頁（文件包第 6 頁）Accessible 列、Peak 欄，且已驗證表頭歸屬

• wheelchair-accessible roll-in shower（輪椅可進出的無門檻淋浴間）規格，由 accessibility-addendum.jpg 影像第 1 頁（文件包第 7 頁）Accessible Room Features 章節載明；這是文件的說法，不是解析器自行查驗的結果

• 透過行程 ID JPN-2026-0417 串連的預訂確認紀錄，附帶時間戳記與已預訂房型欄位

• 在破壞版本中，一則警示：原始金額可讀，但房型／季節歸屬尚未驗證；保留原始觀測值，在附錄延續頁的表頭釐清之前，不交付解讀後的房價

由於擷取的證據與生成的說明彼此分開，規劃師與審查者可以把每一筆房價對回確切的頁面、列與欄來查核。

實作練習：重建混合文件包

請準備四份測試輸入檔：

1. contract-kyo-h12.pdf：原生數位雙欄 PDF，共四頁；

2. rate-appendix-scan.pdf：兩頁掃描檔（對應文件包第 5–6 頁），同一張房價表跨兩頁延續；

3. accessibility-addendum.jpg：單頁翻拍照片，內含旅宿代碼 KYO-012；

4. booking-jpn-2026-0417.pdf：原生數位預訂確認函，以行程 ID 而非合約 ID 識別。

接著明確定義標準答案表格：每個附錄頁的 Room 表頭皆縱跨兩列，Nightly rate (JPY) 則橫跨 Shoulder 與 Peak 兩個季節欄；第一頁列出 Standard 列，第二頁重複表頭並列有 Accessible 列：

註腳載明這些房價是測試合約下的每房每晚價格；註腳中的不適用日期排除與入住人數上限，必須和表格保持綁定。不同房型的價格不算衝突：房型、季節、幣別、包含項目與合約版本都對齊後仍不一致，才是真正的費率差異。

在實體對應上，主合約明文將 KYO-H12 對應至 KYO-012；費率附錄標示 KYO-H12；翻拍的增補文件標示 KYO-012；預訂確認函則同時列出 KYO-012 與 JPN-2026-0417。請根據這些明確的識別碼對應，還原三條標準答案連結（合約→費率附錄、合約→無障礙增補文件、合約→預訂確認函），不要仰賴飯店名稱的模糊相似度。

在閱讀順序上，將合約目標頁標記為 C0–C5（標題、左欄內文、左欄註腳、右欄標題、右欄內文、頁尾），附錄標記為 R0–R5（首頁群組表頭、季節標籤、Standard 列、次頁重複表頭、Accessible 列、註腳），增補文件標記為 A0–A1（旅宿代碼、淋浴設施說明），確認函標記為 B0–B1（行程 ID、旅宿參照）。這四組序列共產生 12 組相鄰順序限制。把每欄註腳緊接在該欄內文之後，是本測試資料的慣例，不是通用的頁面閱讀規則。

請同時記錄從 1 起算的檔內頁碼 page 與文件包總頁碼 packet_page（合約為 1–4、附錄為 5–6、增補文件為 7、確認函為 8）。下方 JSON 僅展示未經破壞的測試資料中通過驗證的單一欄位範例，而非完整輸出：

{
  "packet_id": "EP-KYO-H12-v1",
  "logical_documents": ["contract", "rate_appendix", "accessibility_addendum", "booking_confirmation"],
  "entities": {
    "contract_id": "KYO-H12",
    "property_code": "KYO-012",
    "itinerary_id": "JPN-2026-0417"
  },
  "critical_fields": [
    {
      "name": "accessible_room_peak_rate",
      "value": 25000,
      "currency": "JPY",
      "source": {"file": "rate-appendix-scan.pdf", "page": 2, "packet_page": 6, "table": "seasonal_rates", "row": "Accessible", "column": "Peak"}
    }
  ],
  "warnings": []
}

檢查已宣告的閱讀順序限制，並與 OCR 文字品質分開評估：

const sequences = [
  ["C0", "C1", "C2", "C3", "C4", "C5"],
  ["R0", "R1", "R2", "R3", "R4", "R5"],
  ["A0", "A1"], ["B0", "B1"],
];
const constraints = sequences.flatMap(s => s.slice(1).map((id, i) => [s[i], id]));
function orderScore(predicted) {
  if (new Set(predicted).size !== predicted.length) throw new Error("duplicate block ID");
  const positions = new Map(predicted.map((id, i) => [id, i]));
  const passed = constraints.filter(([a, b]) => positions.has(a) && positions.has(b)
    && positions.get(a) < positions.get(b)).length;
  return { passed, total: constraints.length };
}
const intact = orderScore(sequences.flat());
if (intact.passed !== 12 || intact.total !== 12) throw new Error("intact order");
const broken = sequences.flat();
[broken[7], broken[8]] = [broken[8], broken[7]];
if (orderScore(broken).passed !== 11) throw new Error("shifted reading order");
console.log({ intact, broken: orderScore(broken) });

把管線拆成看得見的階段來執行：檢查檔案類型、還原文字、偵測區塊、推導閱讀順序、重建跨兩頁的表格、分割邏輯文件、連結識別碼、輸出附溯源的證據，最後計算計分卡。保留每個中間表示，失敗時才能定位問題出在哪個階段。

刻意破壞案例

移除附錄檔內第 2 頁（文件包第 6 頁）重複的 Peak 表頭，並把第二頁的欄位向左移一格。扁平解析器仍會抓到每個數字，卻把 JPY 25,000 掛到錯誤的房型與季節。

管線至少要透過一條明確的不變量抓到這個錯誤：

• 延續欄位必須依標籤、位置與限定條件，對應到附錄檔內第 1 頁（文件包第 5 頁）的表頭；若其他連續性線索明確，僅缺少重複表頭並不代表出錯；

• 每個費率儲存格都必須能上溯到唯一的房型列、季節欄與幣別；

• 儲存格內容或欄位指派分數必須能偵測錯誤的欄位對應，因為數值在同一網格內移位時，只看拓撲的分數可能不變；

• 欄位歸屬不明確的關鍵值，必須暫不交付並送交審查。

接著把 OCR 輸出的 KYO-H12 改成 KYO-H1Z。實體連結不能默默對關鍵識別碼做模糊比對，而應揭露合約、旅宿與行程紀錄之間的衝突。

完成標準

符合以下條件時，測試資料才算通過：

• 關鍵 ID KYO-H12、KYO-012 與 JPN-2026-0417 皆完全一致；

• 找回四份邏輯文件與三條跨文件連結；

• 12 項已標註的閱讀順序限制全部通過；

• 表格保留預期的列、欄、合併表頭、延續連結、幣別與儲存格溯源；

• accessible_room_peak_rate = JPY 25,000 指向檔內第 2 頁、文件包第 6 頁、Accessible 列與 Peak 欄；

• 溯源覆蓋率為 具有效來源的已交付關鍵欄位 / 已交付關鍵欄位 = 1.0；完整測試資料另外要求必要欄位完整率 已還原必要欄位 / 全部必要欄位 = 1.0，因此全部不交付也無法過關；

• 移位表格與損壞 ID 兩個案例都暫不交付，而不是用猜的；

• 已記錄解析器版本、OCR／模型版本、來源總和檢查碼（checksum）、各階段延遲與計分卡。

這些閘門只適用於本測試資料。正式環境的門檻要依文件類別與後果來訂：費率表和行銷手冊的容錯程度不會一樣。

本文不涵蓋的內容

文件智慧只要結合了文字、頁面影像與版面，本身就已經是多模態。本篇替文件重建劃出實務邊界：版面還原、表格結構、文件分割與證據組裝。第 9 篇把照片、圖表、平面圖與跨模態檢索當成一級證據，檢索策略則留在第 7 篇。

導致糟糕系統設計的誤解

以文件為主的 AI 專案裡，有五個誤解反覆出現。

第一，團隊以為不論任務需要什麼，單靠 OCR 文字就夠了。忠實的文字或結構化表示，可以保留任務所需的表格、版面與跨文件關係；但這些關係一旦遺失，只對剩下的文字做檢索，無法自行把它們補回來。

第二，團隊以為表格的儲存格數值本身就保留了意義。合併表頭、延續列、幣別與表格外的附註，都可能決定數值之間的關係。扁平化時若沒有保留這些關係，就可能破壞表格的意義；明確保留這些關係的序列化表示則不一定會。

第三，團隊把一份上傳的 PDF 當成一份邏輯文件。碰到合約套組、附錄與補充文件，這個假設就會失效，而這些在旅行營運與企業工作流程中都很常見。

第四，團隊以為無 OCR 的文件模型就不需要處理結構與驗證。即使 OCR 不再是獨立階段，系統仍然需要還原文件關係、保留溯源，並評估擷取品質。

第五，團隊把文件智慧當成多模態的暖身練習。結構、層級與擷取品質讓文件智慧自成一個系統層；早在圖片與照片成為重點之前，它們就已經很重要。

正式環境中的常見失敗模式

正式環境中後果最嚴重的失敗，通常是結構性的。

錯誤的閱讀順序可能讓多欄文字交錯，或讓側欄脫離周圍的條款；章節標題也可能和它統轄的段落分家。跨頁拆開的表格可能被重建錯誤，遺失的表頭列可能讓解析器把房價指派到錯誤的欄。裝訂在同一檔案裡的附錄可能一直沒和主協議分開，實體連結器則可能過度比對相似的識別碼，或漏掉明確的交叉引用。擷取出的數字也可能沒有頁面或儲存格溯源就流向下游，讓 OCR 錯誤悄悄擴散到檢索、正規化與答案生成。

這些失敗之所以危險，是因為產出的答案往往看起來很合理。規劃師可能收到一份乾淨的摘要，卻完全看不出底層的房價表被誤讀，或某筆房價其實來自附錄而不是主合約。在高風險工作流程中，主要風險是無聲的錯誤歸因，而不是顯而易見的解析崩潰。

實務設計指引

把文件智慧當成專屬的架構層，而不是隨手接在檢索前面的前處理程式。

從檔案檢查開始。建立索引或檢索之前，先分類送進來的檔案、區分原生數位文字與掃描檔，並檢查單一上傳檔是否綁了多份邏輯文件。

切分區塊之前先保留結構。先還原頁面區域、閱讀順序與表格邊界；一開始就把頁面扁平化，可能會破壞可靠擷取所需的空間線索。

明確表示表格：保留列與欄的層級、表頭、幣別與頁面座標。只有在任務層級的評估顯示結構損失可以接受時，才把表格簡化成純文字。

把擷取與合成分開。先組裝出經過驗證的證據資料包，再把這份結構化資料包交給下游模型比較或說明，讓每個階段都能除錯、也能稽核。

把溯源當成一級概念：盡可能記錄頁面座標，表格則記錄到儲存格座標。審查者若無法直接跳到來源位置，就沒辦法裁定互相衝突的數字。

實體連結要保守。合約 ID、預訂參考號與旅宿代碼，要透過明確的規則或經過校準、附帶驗證的評分來比對，不要只憑隨意的字串相似度。

分別評估每項文件任務。除了最終答案品質，也要量測表格重建、文件分割、識別碼連結與溯源覆蓋率，免得流暢的文字掩蓋了壞掉的解析器。

把 OCR 當成基準，而不是教條。有些工作流程會基於實際考量維持以 OCR 為主，有些則可能在特定文件類別改用無 OCR 解析器。重點在於管線是否保留了任務需要的結構。

為什麼這會自然走向多模態證據系統

團隊一旦接受「文件不是文字塊」，下一步的架構方向就很明顯了。

旅行合約裡許多重要的主張，不只存在於段落或表格，也存在於平面圖、旅宿照片、無障礙示意圖、圖說、圖例，以及它們彼此的關係中。能重建頁面版面、表格結構與文件層級的系統，已經走出純文字檢索，朝更完整的證據模型前進。

這就是通往多模態系統的橋梁。

第 9 篇從這裡接續。圖片、圖表與影像一旦和文字、表格一樣成為一級證據，文件智慧就會擴展成多模態證據錨定：在不失去溯源的前提下，把視覺內容連結到圖說、周圍文字與跨文件主張。

來源附註

本文參考以下主要與實務來源：

• Smith, R. "An Overview of the Tesseract OCR Engine." *ICDAR 2007.* 說明 OCR 是字元辨識、而非完整文件理解的參考。research.google/pubs/an-overview-of-the-tesseract-ocr-engine

• Xu, Y., Li, M., Cui, L., et al. "LayoutLM: Pre-training of Text and Layout for Document Image Understanding." *KDD 2020.* 支持「版面與樣式資訊對文件理解很重要」這項主張的參考。arxiv.org/abs/1912.13318

• Huang, Y., Lv, T., Cui, L., et al. "LayoutLMv3: Pre-training for Document AI with Unified Text and Image Masking." *ACM Multimedia 2022.* 聯合文字、影像與版面的文件表示，以及下游文件任務的實證。arXiv:2204.08387

• Wang, Z., Xu, Y., Cui, L., Shang, J., and Wei, F. "LayoutReader: Pre-training of Text and Layout for Reading Order Detection." *EMNLP 2021.* ReadingBank，以及把閱讀順序當成可獨立評估的任務。ReadingBank

• Li, M., Xu, Y., Cui, L., et al. "DocBank: A Benchmark Dataset for Document Layout Analysis." *COLING 2020.* 把細部版面分析當成獨立任務的參考。arxiv.org/abs/2006.01038

• Smock, B., Pesala, R., and Abraham, R. "PubTables-1M: Towards Comprehensive Table Extraction From Unstructured Documents." *CVPR 2022.* 表格偵測、結構辨識與功能分析可分開評估的參考。arxiv.org/abs/2110.00061

• Zhong, X., ShafieiBavani, E., and Jimeno Yepes, A. "Image-based Table Recognition: Data, Model, and Evaluation." *ECCV 2020.* TEDS 作為表格結構與內容指標的主要來源。arXiv:1911.10683

• Kim, G., Hong, T., Yim, M., et al. "OCR-free Document Understanding Transformer." *ECCV 2022.* 無 OCR 文件理解方法與 OCR 錯誤傳播風險的參考。arxiv.org/abs/2111.15664

• National Institute of Standards and Technology. "Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile." NIST AI 600-1，2024 年 7 月。高風險擷取流程中溯源、可追溯性與審查用語的參考。nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

• National Institute of Standards and Technology. "The Text Recognition Algorithm Independent Evaluation (TRAIT)." NISTIR 8199，2017 年 12 月。文字辨識的字元層級與詞層級正規化編輯距離量測。NIST IR 8199

• Smock, B., Pesala, R., and Abraham, R. "GriTS: Grid Table Similarity Metric for Table Structure Recognition." *ICDAR 2023.* 以網格為基礎的表格評估及其變體。arXiv:2203.12555