為企業 AI 專案建立本地文件攝取系統

文件攝取是每個企業 AI 資料流水線的起點——也是大多數服務提供商首次發現真實企業資料有多混亂的地方。

當客戶交給你 200,000 份 PDF、50,000 份 Word 文件、10,000 份 Excel 試算表，以及一箱 2003 年的紙本掃描表單時，你的攝取系統需要全部處理。在本地端。不傳送任何位元組到雲端 API。

本指南涵蓋本地文件攝取設置的實務面：你在企業環境中會遇到哪些文件類型、如何在本地端處理每一種，以及常見的失敗模式在哪裡。

---

你實際上會遇到的企業文件類型

企業文件集合並不是乾淨的語料庫。它們是跨格式、慣例和品質層級，數十年積累的檔案。以下是實際出現的情況：

原生 PDF — 以數位方式產生，具有可擷取的文字層。這是最簡單的情況。文字擷取運作可靠，版面配置通常可以復原。不過，複雜的版面（多欄、浮動文字框、巢狀表格）可能讓簡單的擷取方式失效。

掃描 PDF 和以圖像為基礎的文件 — 沒有文字層。每個字元都必須透過 OCR 重建。品質差異極大：2020 年的清晰 300 DPI 掃描很直觀；1997 年有咖啡漬的 150 DPI 傳真則不然。

Word 文件（.docx、.doc） — .docx（以 XML 為基礎）通常很直觀。2007 年以前 Word 版本的舊版 .doc 檔案需要不同的解析方式。注意追蹤修訂、內嵌物件，以及帶有語義含義的複雜格式。

Excel 試算表（.xlsx、.xls、.csv） — 表格結構是關鍵資訊。合併儲存格、多層標題、用作分隔符號的空白列，以及產生顯示值的公式，都需要處理。

PowerPoint 簡報（.pptx） — 文字嵌入在圖形、文字方塊和 SmartArt 中。投影片備忘錄通常包含額外的情境。解析必須處理空間版面，而不只是文字擷取。

CAD 圖紙和工程文件 — 標題欄包含結構化的後設資料。圖面標注帶有關鍵資訊。這些是特定領域的文件，需要專門的擷取邏輯。

掃描表單 — 結構化文件（保險理賠、病患入院表格、檢查清單），其中欄位位置編碼了含義。光有 OCR 還不夠——你需要表單欄位偵測和鍵值擷取。

電子郵件存檔（.eml、.msg、.mbox） — 標題後設資料、正文內容和附件都需要分別處理。執行緒重建又增加了另一層複雜性。

---

本地端 OCR 選項

對於掃描文件，OCR 是關鍵的相依性。以下是本地端選項的比較：

對於本地端部署，PaddleOCR 提供最佳的準確率與複雜度比。Tesseract 最易於部署，對清晰的現代掃描效果良好。EasyOCR 能很好地處理多語言文件。

雲端與本地端 OCR 之間的準確率差距是真實存在的——清晰文件約差 2-5%，劣化掃描的差距更大。對於大多數企業用例，本地端準確率已足夠。對於邊緣案例（嚴重劣化的文件、不尋常的字型、手寫文字），預期需要在流水線中加入人工審查步驟。

---

表格擷取：困難的問題

PDF 中的表格是大多數攝取流水線失敗之處。對人類觀看者來說看起來完美結構化的表格，在底層 PDF 中只是一組定位文字片段，沒有明確的列/欄結構。

Docling（IBM 的文件理解程式庫）在標準基準測試中報告了 97.9% 的表格結構識別準確率。這令人印象深刻，實際上它能很好地處理大多數企業表格。複雜案例——跨多列的合併儲存格、巢狀子表格、跨越分頁的表格——仍需要驗證。

Camelot 和 Tabula 是專門用於 PDF 的表格擷取程式庫。它們對簡單、結構良好的表格效果很好，但在複雜版面上會遇到困難。

版面感知擷取是當前最佳方法：先識別文件版面中的表格區域，然後使用偵測到的結構擷取儲存格內容。這需要模型（如 Docling 內部使用的模型）而非基於規則的啟發式方法。

擷取後，以程式方式驗證表格結構：

• 各欄的列數應一致
• 標題列應可識別
• 數字欄應包含可解析的數字
• 儲存格內容不應被截斷

---

處理多欄版面

多欄 PDF（學術論文、電子報、部分法律文件）會產生閱讀順序問題。跨整頁寬度從左到右讀取的文字擷取，會將兩欄的內容交錯，產生亂碼。

解決這個問題需要版面偵測：識別欄邊界，然後以正確的閱讀順序擷取每欄中的文字。方法如下：

1. 基於規則：偵測文字定位中的大水平間隙。適用於簡單的雙欄版面，對複雜版面無效。
2. 基於機器學習的版面偵測：LayoutLMv3 或 Docling 的版面模型等模型可偵測欄、標題、圖形和表格。更可靠，但需要模型部署。
3. 混合式：先使用基於規則的偵測，對無法乾淨解析的文件退回基於機器學習的方式。

---

攝取輸出應有的樣子

設計良好的攝取階段的輸出是帶有後設資料的結構化文字——而非原始文字傾印。良好的攝取輸出包含以下內容：

文件層級後設資料：

• 來源檔名、檔案類型、頁數
• 攝取時間戳記
• OCR 信心分數（用於掃描文件）
• 語言偵測結果

章節層級結構：

• 標題層次（H1、H2、H3）
• 段落邊界
• 清單項目
• 表格結構（已識別的列、欄、標題）

內嵌後設資料：

• 具有語義含義的粗體/斜體/底線標記
• 腳注參考
• 交互參照和內部連結

品質指標：

• 每頁/區域的 OCR 信心度
• 版面偵測信心度
• 解析警告（例如「表格可能格式不正確」、「偵測到可能的多欄版面」）

這個結構化輸出直接饋入清理階段。如果攝取輸出是沒有結構的純文字，每個下游階段都需要更努力工作。

---

常見失敗模式

頁首/頁尾雜訊：頁碼、連續頁首、文件標題和機密聲明在每頁都會重複。如果不加以去除，它們會在擷取的文字中出現數百次，混淆去重複和品質評分。

連字符號偽影：跨行分割的單字（例如 "docu-\nment"）需要重新連接。簡單的正規表示式能處理大多數情況，但邊緣案例（例如 "re-\nevaluate"，其中連字符號是真實的）需要字典查找。

編碼問題：舊版文件可能使用 Windows-1252、ISO-8859-1 或其他非 UTF-8 編碼。亂碼（因編碼不符導致的字元混亂）在混合編碼文件集合中很常見。

後設資料遺失：某些擷取工具會丟棄文件屬性（作者、建立日期、修改歷程），這些對篩選或來源追蹤可能很有價值。

空白或近乎空白的頁面：封面頁、分隔頁和空白頁浪費處理時間，如果不加以篩選，可能會引入雜訊。

---

實際設置

對於為客戶專案設置本地攝取的服務提供商：

1. 先清點文件集合。 在撰寫任何程式碼之前，按類型計算檔案數量、抽樣整個集合的品質，並識別邊緣案例。30 分鐘的清點可以避免數天的除錯。

2. 從最難的格式開始。 如果集合包含 1990 年代的掃描 PDF，先在那些檔案上測試 OCR。如果無法挽救，你需要在規劃其餘流水線之前就知道。

3. 建立驗證步驟。 攝取後，隨機抽樣檢查：擷取的文字是否與來源文件相符？表格是否完整？閱讀順序是否正確？

4. 記錄所有事項。 每個處理的檔案、每個 OCR 信心分數、每個解析警告。這個記錄是稽核追蹤的一部分。

Ertas Data Suite 的 Ingest 模組原生支援 64 種以上的檔案類型——包括 PDF（原生和掃描）、Word、Excel、PowerPoint、圖像和工程文件——內建 OCR、表格擷取和結構化輸出。它記錄每個解析決策和信心分數，作為專案稽核追蹤的一部分，整個過程在本地端執行，無需任何網路呼叫。

---

連接到流水線

攝取產生結構化文字和後設資料。下一個階段——清理——接收該結構化輸出，並移除重複項、正規化編碼、遮蔽 PII/PHI，以及評分品質。每個階段都建立在前一個階段之上，攝取輸出的品質直接決定清理需要多少工作。

有關完整流水線概覽，請參閱如何為 LLM 微調建立本地端資料準備流水線。