如何批次辨識掃描 PDF？幾萬檔案最快 OCR 方案

結論先說：幾萬份掃描 PDF 要跑完 OCR，瓶頸幾乎從來不是「選哪個 OCR 引擎」本身，而是有沒有在開工前分流、有沒有平行處理、有沒有可恢復的任務佇列。單機用 GUI 一個個轉，一萬份可能要幾週；按本文的流水線在 8～16 核 VPS 或帶 GPU 的 Worker 上跑，同樣體量通常能壓到數小時到一兩天——前提是接受「先快篩、再精 OCR、壞頁隔離」的工程取捨，而不是追求每頁都上最貴模型。

本文面向檔案數位化、法務卷宗、醫療影像報告、歷史論文庫、企業合約掃描件等場景：檔案量在 1 萬～10 萬+，多數是純掃描或混合 PDF。關鍵字：批次 OCR、掃描 PDF 辨識、ocrmypdf、PaddleOCR。若你之後要把辨識結果灌進 RAG，匯入前的類型判定與品質檢查請直接看 RAG PDF Parsing 最佳實務——OCR 只是整條鏈路的第一段。

資料核對日期：2026 年 8 月 8 日。命令與參數以 OCRmyPDF 官方文件、Tesseract 文件 與 PaddleOCR 儲存庫 目前版本為準。

為什麼「批次掃描 PDF」容易慢到無法接受

很多人第一次批次 OCR 的失敗模式很相似：把資料夾丟進某個桌面工具，發現 CPU 只佔 15%、風扇不響、一晚上只跑了 200 份。根因通常是下面幾條疊在一起：

• 序列處理：一個行程按檔案順序跑，多核機器空轉。
• 沒做預檢：30% 檔案其實已有文字層，仍走完整 OCR，白白燒時間。
• 按「檔案」平行而非按「頁」：單份 800 頁的卷宗佔滿一個 Worker，其他核閒著；小檔案又頻繁啟停行程。
• 輸出格式過重：每頁 OCR 後重新壓圖、嵌字型、做 PDF/A，IO 和 CPU 雙爆。
• 沒有斷點續跑：跑到第 9000 份當機，從頭再來。

幾萬份的規模下，流水線設計比 OCR 引擎微調重要一個數量級。下面按「最快落地」順序寫：先 10 分鐘能跑起來的方案，再講到萬級吞吐的架構。

第 0 步：預檢分流——別對不需要 OCR 的檔案動手

在跑任何 OCR 之前，用腳本批次掃一遍目錄（find + parallel 或 Python 多行程均可）：

• 用 PyMuPDF / pdfinfo 統計每頁 get_text() 字元數；連續可讀文字超過閾值（例如 80 字/頁）的標記為 text_layer，直接複製到輸出目錄，不走 OCR。
• 加密 PDF、0 頁損壞檔案寫入 quarantine/，別卡死整個佇列。
• 對混合 PDF（封面掃描 + 內文可選文字）按頁級打標籤，後續只 OCR 需要的頁——這是萬級體量省時間的大頭。

我們見過一個法務專案：庫內 4.2 萬份 PDF，預檢後發現 38% 已有合格文字層、12% 加密需人工處理，真正需要 OCR 的只有約 50%。這一步把總工時直接砍半，比換「更準的 OCR 模型」見效快得多。

最快能跑起來的方案（1 千～5 千份）

若你今天要交差、機器是一台 8 核 Linux 或雲端 VPS，推薦這條最少相依路徑：

1. 安裝 ocrmypdf + Tesseract（中文加 chi_sim / chi_tra 語言包）。
2. 用 GNU parallel 或 xargs -P 按檔案平行，並行數設為 CPU 核數 − 1（留一核給 IO）。
3. 參數建議：--skip-text（跳過已有文字層）、--optimize 0 或低最佳化等級（先求速度）、--jobs 1 在每個 ocrmypdf 行程內避免過度巢狀平行。
4. 輸出先寫到本機 SSD 暫存目錄，批次完成後再 rsync 到物件儲存——網路碟邊寫邊傳會拖垮吞吐。

cat scan_only.txt | parallel -j 8 \
                  'ocrmypdf --skip-text --optimize 0 --language chi_sim+eng \
                   {} /data/ocr_out/{/.}.pdf'

中文為主的掃描件，Tesseract 準確率往往不如 PaddleOCR，但裝套件 5 分鐘、今晚就能跑。若辨識率不夠，再對「低信心度頁」二次走 PaddleOCR，而不是全盤重跑。

萬級體量架構：佇列 + Worker + 斷點續跑

當檔案數到 1 萬～10 萬+，必須把「一次性的 shell 迴圈」升級成可觀測的任務系統：

• 任務佇列：Redis + RQ、Celery、或雲端廠商的 Batch / Step Functions。每條任務 = 一個 PDF 或一個「頁範圍」（大檔案切片）。
• 狀態表：SQLite / Postgres 記錄 file_hash、狀態（pending / running / done / failed）、重試次數、OCR 引擎版本。當機後只重跑 failed。
• Worker 水平擴展：單機 8 Worker 不夠就起第二台 VPS；OCR 是 CPU 密集，多台中配機器通常比一台巨型機划算。
• 頁級平行（大卷宗）：單 PDF > 200 頁時，先 pdftoppm 拆頁圖，頁圖丟進佇列，OCR 完再合併文字層——避免一個巨檔霸占 Worker 三小時。
• GPU 分支：PaddleOCR、Surya、部分商用 API 在 GPU 上頁吞吐可翻數倍；建議單獨 GPU Worker 池，與 Tesseract CPU 池分流，按語言/版式路由。

編排層不必一開始就用 Kubernetes。很多團隊在 2～4 台 VPS Worker 上跑 Docker Compose + Redis 就夠用：一台放佇列與中繼資料，其餘純 OCR。等日處理量穩定超過單機上限再加機器，比過早上 K8s 省事。

工具怎麼選：速度、中文、可搜尋 PDF

最快不等於最省：商用 API 往往「上線最快、帳單最大」；自架 PaddleOCR 前期搭環境慢，但 10 萬頁攤下來常更便宜。團隊應拿 200 份代表性樣本做準確率 × 單頁耗時 × 單價三角評測，而不是看行銷文案裡的「99% 準確率」。

再摳 30%～50% 速度的實操技巧

• 降 DPI 再 OCR：掃描存檔若是 600 DPI，先試 300 DPI 渲染再辨識——很多合約/報告 300 已夠，頁渲染時間幾乎減半。
• 灰階 / 二值化前處理：乾淨黑白掃描用 OpenCV 去噪+自適應閾值，可減少 Tesseract 誤辨識重試。
• 語言包最小化：只載入 chi_sim+eng，別預設載入十幾種語言。
• 跳過低價值頁：空白頁、純印章頁用像素變異數偵測後直接標記 skip。
• 輸出策略：若下游只要全文檢索，可額外匯出 .txt / .jsonl（按頁），不必每份都產生重量級 PDF/A；需要歸檔的再走慢路徑。
• 本機 NVMe 暫存碟：雲主機系統碟若是網路碟，把 TMPDIR 掛到本機 SSD 磁區，IO 等待會明顯下降。

速度與品質怎麼同時兜住

批次跑完後，別直接宣布成功。建議自動化品檢抽樣：

• 隨機抽 0.5% 檔案人工對讀，或對比原圖與 OCR 文字的字元錯誤率（CER）。
• 對數字密集頁（發票號、案號、日期）做正則驗證，異常率超閾值整批標記 review。
• 記錄每頁平均信心度（Tesseract tsv、Paddle 分數），低分頁進二次 OCR 佇列。

這與 RAG 場景的「黃金樣本集」是同一思路：OCR 是一次性成本，壞資料進庫後的檢索修復成本更高。檔案場景則要留稽核日誌——誰、何時、用什麼引擎版本處理了哪份檔案。

粗算：幾萬份要多少機器和時間

假設預檢後需 OCR 的共 5 萬頁，單核 Tesseract 約 3～8 秒/頁（視 DPI 與語言而定），取中值 5 秒：

• 單核序列：約 69 小時。
• 8 核滿載平行（8 路檔案）：約 8～12 小時（含 IO 損耗）。
• 2 台 8 核 Worker：約 4～6 小時。
• 單張 T4 GPU + PaddleOCR：常見可到 1～3 秒/頁量級，5 萬頁約 14～42 小時單卡——多卡線性擴展。

以上是量級估算，不是承諾 SLA。真正排程請用你自己的 100 頁樣本實測 pages_per_hour，再乘剩餘頁數。並行不是越高越好：磁碟、記憶體和暫存檔案控制代碼會先成為瓶頸，一般在每核 1 個 OCR 行程附近收益最大。

可抄作業的批次 OCR 清單

1. 遞迴清單 + SHA256 去重，寫 manifest。
2. 預檢分流：text_layer / scan / mixed / encrypted。
3. 佇列入隊（優先小檔案或按 OCR 頁數均衡）。
4. Worker 平行 OCR，--skip-text 或頁級路由。
5. 輸出可搜尋 PDF 或 sidecar 文字 + 中繼資料 JSON。
6. 抽樣品檢 + 低信心度二次處理。
7. 歸檔到物件儲存，manifest 標記 ocr_engine_version 便於日後重跑。

若 OCR 結果下一步要進向量庫，請把「解析版本號」和「頁級類型」一併寫入中繼資料——日後換引擎重跑時不用猜哪些 chunk 已過期。長文件問答成本還可結合 Context Caching 成本估算 控制推理帳單。

最後一句

幾萬份掃描 PDF 沒有銀彈，但有可複製的最快路徑：預檢砍掉一半無效 OCR → 佇列保證可恢復 → 多 Worker 吃滿 CPU/GPU → 品檢攔住壞頁。先讓流水線跑通、再調引擎參數；反過來會在第一週就耗盡耐心。