RAG PDF：pdf-inspector 與 OCR 怎麼選？（2026）

檔案明明可以複製文字，匯入 RAG 後卻出現亂序段落、空白頁或引用不到原始頁碼。

最快的解法不是在 pdf-inspector 與 OCR 之間二選一：先用 pdf-inspector 判斷 PDF 類型並嘗試原生文字解析，只有掃描頁、混合頁或低品質隱藏文字層才進入 OCR 分支；小型原型可以簡化，持續攝取與高並發管道則應建立分級路由。

這篇適合三類讀者：正在從零搭建 RAG 攝取鏈路、需要決定第一版方案的開發者；已有 OCR 流程但處理緩慢或結果不穩定的團隊；以及準備租用遠端算力做批量回歸、需要先定義測試指標的技術負責人。

最後更新於 2026 年 8 月 10 日；資料核實自 pdf-inspector 最新 README、其變更內容與官方 OCR 文件，正式上線前仍應以固定版本和自有樣本重新驗證。(github.com)

先分清楚：檢測器、解析器與 OCR 並不是同一層

RAG PDF 預處理通常包含四個不同工作：

1. 判斷頁面是否有可用的原生文字。
2. 從 PDF 內容流提取文字、座標、字型與頁面關係。
3. 對沒有可用文字的頁面進行渲染與 OCR。
4. 將結果清理、切分、嵌入，並保留可追溯的頁碼資訊。

pdf-inspector 官方定位是 PDF 分類與文字提取工具。它可將檔案判斷為文字型、掃描型、圖片型或混合型，也能回傳需要 OCR 的頁面清單；這使它適合放在攝取入口，而不是被當成完整的文件理解模型。其 README 也列出位置感知文字提取、多欄閱讀順序、表格與 Markdown 轉換等能力，但具體 RAG 品質仍須由專案樣本驗收。(github.com)

直接 OCR 則是另一種取捨：它把頁面視為影像，重新辨識字元。以 Tesseract 官方文件 為例，OCR 引擎可以從影像辨識文字，並透過不同輸出模式產生文字、hOCR 或可搜尋 PDF；OCRmyPDF 官方文件 則專注於替掃描 PDF 加上可搜尋的文字層。這些工具能處理「沒有文字」的頁面，卻不代表它們會自動理解企業文件的章節階層、表格語意或 RAG 引用規則。(tesseract-ocr.github.io)

RAG 導入 PDF 是否必須先做 OCR？
不必。若頁面已有品質足夠的原生文字，先 OCR 反而會引入額外渲染、辨識與錯字風險。真正需要的是先檢測，再依頁面結果決定解析路徑。

品質指標要看結構，不是只看「有沒有文字」

文字版 PDF 也可能存在低品質隱藏文字層，例如掃描影像上疊了一層錯誤 OCR，或字型編碼讓複製結果變成無意義符號。若只用 text length > 0 判斷，這類檔案會被錯誤送進原生解析流程。

建議至少比較以下五項：

• 文字可讀性：抽取結果是否保留詞間空格、標點、特殊符號與中英文混排。
• 段落完整性：換頁、頁首、頁尾與欄位是否被錯誤拼接。
• 標題層級：章節標題能否與正文分離，而不是全部變成同一層純文字。
• 表格重建：欄列關係、合併儲存格、續頁表格是否仍能被檢索。
• 引用可追溯性：每個 chunk 是否保留來源檔案、頁碼、區塊座標或頁面標記。

pdf-inspector README 所列的 Markdown 轉換包含標題、清單、程式碼區塊、表格與頁面分隔等處理，但這些是工具能力描述，不是所有企業 PDF 都能達成的保證。尤其是複雜財務表、公式與不規則欄位，必須用人工標註樣本驗證。(github.com)

pdf-inspector 能否取代 OCR？
它可以取代「對原生文字 PDF 盲目 OCR」這一步，但不能取代影像辨識。若分類結果顯示某些頁面沒有文字，或文字編碼檢查失敗，正確做法是將這些頁面送往 OCR，再把結果合併回同一份文件索引。

效率取決於是否避免無效 OCR

全量 OCR 的問題不只是單次處理變慢，而是每個文件都被迫走過渲染、暫存影像、文字辨識、結果合併與品質檢查等階段。對持續增量攝取而言，這會讓 CPU、記憶體、硬碟暫存空間與工作佇列同時承受壓力。

pdf-inspector 官方 README 提供的專案基準測試，是在 OCR 關閉的條件下，以 200 份 PDF 比較多個本地解析器；當時列出的 pdf-inspector 整體分數為 0.875、閱讀順序分數為 0.915、表格分數為 0.814，完整處理時間為 0.470 秒。測試於 2026 年 7 月 31 日 在 Apple M4 Pro 上完成，版本與執行方式也有明確列出，因此這些數字只能作為該語料、版本與硬體下的參考，不能直接當成所有環境的固定速度。(github.com)

這個基準對架構的意義是：原生文字檔案可以先用低成本解析器處理，將 OCR 資源留給真正需要的頁面。至於 OCR 分支的延遲，應由團隊以相同語言模型、影像解析度、頁面尺寸和並發數實測，不應引用脫離環境的固定秒數。

複雜版面需要採用逐頁路由

文字版和掃描版 PDF 如何進入不同解析器？
可以用「文件級初判、頁面級回退」的方式處理：

1. 收到檔案後先記錄雜湊值、來源、頁數與版本。
2. 用 pdf-inspector 執行分類，保留文件類型、信心資訊與需要 OCR 的頁面。
3. 對文字型頁面執行原生文字提取，保留座標與頁碼。
4. 對掃描型或混合型頁面進行渲染，再交給 OCR 引擎。
5. 將兩條路徑的輸出標記為 native 或 ocr，避免後續無法追查來源。
6. 對多欄、表格、公式與圖片文字分別設定驗收規則。
7. 只有通過品質門檻的內容才進入切分、嵌入與向量儲存。

多欄文件不一定需要 OCR；若原生文字層完整，應優先檢查閱讀順序。表格也不能只看 OCR 是否辨識出每個字元，還要檢查欄位關係是否可供檢索。公式、手寫註記、低解析度影像與逐頁混合文件，則可能需要另一個版面分析或人工回退流程。

注意： 分類能力不等於完整文件理解能力。Mixed 只表示同一份 PDF 內存在不同頁面型態，並不代表工具已經判斷哪一段是表格標題、哪一段是註腳，或哪個欄位具有業務語意。

成本評估要把每個階段拆開

RAG PDF 的成本不應只用「OCR 每頁多少錢」估算，至少要拆成：

• 檢測成本：讀取 PDF、掃描內容流與產生分類結果。
• 渲染成本：把指定頁面轉成影像所需的 CPU、暫存空間與硬碟 I/O。
• OCR 成本：模型或引擎執行時間、語言包、並發工作數與失敗重試。
• 解析與切分成本：文字清理、表格重建、chunk 生成與 metadata 保存。
• 嵌入成本：向量模型推論、批次大小與重建索引。
• 儲存成本：原始 PDF、渲染影像、中間檔、純文字、Markdown 與向量資料。

團隊可以用以下公式建立自己的估算表：

總成本 = 任務量 × 平均處理時間 × 單位算力成本 + 暫存與儲存成本 + 失敗重試成本

若是一次性的原型，直接 OCR 可能較容易部署；若是每週或每日新增文件，分級路由通常更值得優先驗證。高峰批次與平時增量攝取也不應共用同一個固定環境：前者重視短期吞吐與可平行化，後者重視穩定待機、版本固定與可觀測性。需要比較遠端 Mac、Mac VPS 或 VDI 型工作環境時，可先參考 Mac 遠端工作環境的選擇說明 與 Mac VPS 方案整理。

上線前用可勾選條件決定是否放行

以下清單適合放入 CI/CD 或批次攝取的驗收流程。沒有通過的項目，不應直接把結果送入正式知識庫。

• [ ] 樣本同時包含原生文字、純掃描、低品質隱藏文字層與逐頁混合 PDF。
• [ ] 每類樣本都有人工作為基準，至少標註段落、標題、表格、頁碼與關鍵專有名詞。
• [ ] 原生解析與 OCR 結果分別保存，並能追溯到原始頁面。
• [ ] OCR 只對指定頁面執行，不以「整份文件」作為唯一路由粒度。
• [ ] 表格、公式、圖片文字與多欄版面各有獨立的失敗判定。
• [ ] 解析失敗、編碼錯誤、空頁與密碼保護檔案都有回退或隔離狀態。
• [ ] pdf-inspector、OCR 引擎與語言包版本已固定，升級前後會重跑同一批回歸樣本。
• [ ] 日誌記錄檔案雜湊、頁面路由、處理時間、錯誤類型與重試次數。
• [ ] chunk metadata 至少包含來源檔案識別、頁碼與解析路徑。
• [ ] 在正式導入前，已比較原生解析、直接 OCR 與混合路由的檢索命中率。

不同規模的方案評分與建議

下表不是替任何團隊預填價格，而是將選型條件放在同一個決策面上。評分採 5 分制，分數代表在該場景的相對適配度，不是官方效能保證。

如果團隊只是驗證 RAG 概念，先建一條簡化流程即可；若資料會持續增加，應在第一版就保存路由、版本和頁面級 metadata，否則日後很難判斷錯誤來自 OCR、切分還是嵌入。

目前若使用固定本地電腦或臨時雲端伺服器直接跑全量 OCR，常見缺點是閒置時仍要維持環境、批次高峰會爭用 CPU 與硬碟 I/O、套件版本容易漂移，而且團隊未必能快速複製同一套測試條件。相較之下，若需求是短期回歸、批量 PDF 預處理或需要隔離的 Mac 算力環境，租用 Zilmac 的 Mac 方案可以把測試週期、遠端連線與環境交付分開管理；但長期固定重負載、需要特殊實體介面，或已有穩定自有機房的團隊，仍應先比較自購設備與既有雲端環境。可先查看 Zilmac 的雲端 Mac 租用方式，再按檔案規模、處理週期與回歸頻率安排測試環境。

最穩妥的架構結論很明確：pdf-inspector 負責入口檢測與原生文字解析，OCR 負責掃描頁與低品質頁面的條件分支；RAG PDF 預處理的核心不是選一個工具，而是建立可驗收、可回退、可重跑的路由。