如何批次檢測 10 萬份 PDF 是否需要 OCR？自動化方案詳解

一句話導讀： 企業檔案室、律所、金融機構手裡往往躺著幾萬到幾十萬份 PDF——其中既有 Word 匯出的「真文字」，也有 2005 年掃描器打出來的「假 PDF」（整頁大圖、無法複製）。若對 10 萬份檔案全量跑 OCR，不僅燒錢，還會把本來可搜尋的文件重複處理一遍。正確做法是：先批次檢測哪些 PDF 真的需要 OCR，再按類型分流到本地或雲端識別引擎。

先定義：什麼叫「需要 OCR」？

在工程語境裡，「需要 OCR」不等於「檔案裡有圖」，而是指：

關鍵判斷： 檢測階段的目標不是「識別內容」，而是低成本地把 10 萬份檔案分成「跳過 / 部分處理 / 全量 OCR」三桶。這一步應在任何付費 API 或重型 OCR 引擎之前完成。

三層檢測流水線

面對 10 萬級體量，單層 pdftotext 不夠——誤報和漏報都會放大。推薦三層串聯：

L1：文字層快速探測（< 50ms/檔）

用 PyMuPDF（fitz） 或 poppler pdftotext 提取全文，統計可列印字元數。avg_chars >= 80 標記 SKIP；avg_chars < 20 標記 OCR_REQUIRED；中間地帶進入 L2。

L2：頁面影像占比分析

對 L1 灰區檔案，統計每頁影像面積 / 頁面面積。影像占比 > 85% 且 L1 字元少 → OCR_REQUIRED；影像占比 < 30% 且 L1 字元中等 → SKIP；其餘 → L3 抽樣。

L3：渲染抽樣 + 快速 OCR 探針

對仍不確定的檔案，只渲染第 1、中間、最後各 1 頁（共 3 頁），用 macOS Vision 或 Tesseract 做輕量識別。L3 只處理約 5–8% 的灰區檔案。

10 萬份並行架構

單機不夠時，用清單驅動 + 訊息佇列水平擴展：S3/MinIO 桶 → manifest.jsonl → Redis/RabbitMQ → N × Worker → SQLite/Parquet 結果表。

吞吐參考（ZavCloud Cloud Mac mini M4，24GB）：

檢測結果三級路由

務必用 SHA-256 去重： 同一份掃描件被不同系統重複上傳很常見，檢測結果快取 90 天可再省 20–40% 算力。

工具選型

純 PDF 場景：PyMuPDF + pdftotext 雙檢，兩者都判 SKIP 才跳過。混合 Word/PPT/PDF 統一入口可用 Apache Tika，但 JVM 啟動開銷在 10 萬級體量下不划算。

常見坑

1. 加密 PDF：用 qpdf --decrypt 解密副本再檢測
2. CID 字型亂碼：L3 抽樣看 Unicode 可列印比例
3. 雙層 PDF：用 pdffonts 檢查是否已有劣質 OCR 層
4. 損壞檔案：單獨入 CORRUPT 桶，別阻塞主佇列
5. NAS 隨機 I/O：先 rsync 到本地 NVMe 再跑

為什麼用 Cloud Mac

• tmux 7×24：筆電合蓋會中斷佇列
• Apple Silicon 統一記憶體：PyMuPDF 解析比同價位 x86 VPS 快 20–40%
• 檢測 → OCR 同機：省掉跨機傳輸 10 萬份檔案的頻寬
• 隔離合規：律所、金融客戶常要求文件不出境

7 步落地清單

1. 從物件儲存匯出 manifest.jsonl
2. Cloud Mac 上安裝 poppler、qpdf、PyMuPDF
3. 跑 L1 全量檢測，輸出 Parquet
4. 人工抽查 PARTIAL 桶 200 份，校準閾值
5. OCR_REQUIRED 接 ocrmypdf；PARTIAL 接按頁 OCR
6. 結果寫入側車 JSON，供 RAG / ES 索引
7. 每日增量檢測，別重複全量掃

結論： 10 萬份 PDF 的 OCR 成本，至少一半花在「根本不需要 OCR 的檔案」上。用三層檢測流水線先把桶分好，再決定本地 Vision 還是雲端 Document AI——這才是 2026 年文件數位化的正確打開方式。