許多文件處理流程把「收到 PDF」和「呼叫 OCR」綁在一起——結果一年裡 60%–80% 的頁面根本不必 OCR：它們自帶可選文字層、向量表格或可複製文字。先做 PDF 預檢（pre-flight），再決定走文字抽取還是 OCR，是 OCR Cost 優化裡投資報酬率最高的一步。本文用可複現的口徑說明為什麼、怎麼檢、以及團隊如何落地 OCR Optimization。
1. 為什麼 OCR 前必須先檢測 PDF
「PDF OCR」在採購清單裡往往按頁計費：AWS Textract、Google Document AI、Azure Document Intelligence、ABBYY、PaddleOCR 託管版……單價從 $0.0015/頁到 $0.05+/頁 不等。問題在於：PDF 不是單一格式。同一份「發票.pdf」可能是：
- ERP 匯出的原生文字 PDF（
pdftotext一秒出全文）； - Word 轉 PDF 的嵌入字型文字；
- 掃描器產生的純點陣圖 PDF（必須 OCR）；
- 前幾頁是封面掃描、後面是可選文字的混合型。
不做預檢就全量 OCR，等於對已有文字層再「看圖識字」——不僅浪費錢，還會引入 OCR 錯字、表格錯位，下游 RAG 檢索品質反而下降。財務、法務、保險理賠等批次場景裡，預檢 + 按頁路由 通常能把雲端 OCR 呼叫量砍掉一半以上；在原生文字佔比高的產業（銀行對帳單、電子合約、政府公開資料），年省 70%–80% OCR Cost 並不誇張。
2. OCR 帳單從哪來：一頁多少錢
優化前先統一計量口徑。雲端廠商常見計費維度：
| 計費項目 | 典型單價（2026） | 備註 |
|---|---|---|
| 基礎 OCR（純文字） | $0.0015–0.003/頁 | 僅辨識字元，無表格/表單 |
| 表格 / 表單 OCR | $0.01–0.05/頁 | Document AI「結構化」方案 |
| 手寫 / 低品質掃描 | 溢價 1.5–3× | 需專用模型或人工覆核佇列 |
| 自架 GPU（攤提） | ≈$0.0003–0.001/頁 | 視 QPS 與 GPU 利用率 |
假設月均 200 萬頁、混合價 $0.008/頁，年 OCR 帳單約 $192,000。若預檢發現 75% 頁可走文字抽取（成本接近零），僅 25% 走 OCR，則 OCR 側年支出約 $48,000——節省 約 75%；加上誤辨識帶來的返工減少，業務端常體感接近「省 80%」。
API 單價還會隨區域、Batch、承諾用量變動；選型時可對照 Google Document AI 定價 與 AWS Textract 定價 做敏感性分析。若你已在用多模型路由省 LLM 費用，文件側也應同樣做分層——可參考站內 OmniRoute 遷移驗收清單 的分層思路。
3. 三類 PDF：誰該 OCR、誰該直接抽文字
| 類型 | 特徵 | 建議路徑 | 相對成本 |
|---|---|---|---|
| A. 原生文字 | pdffonts 有字型；pdftotext 字元數 > 閾值 | 直接文字抽取 + 編碼正規化 | ≈0 |
| B. 混合型 | 部分頁有文字層，部分頁為掃描圖 | 按頁預檢後分流 | 中 |
| C. 純掃描 | 無字型、無文字物件；整頁大圖 | OCR（必要時預處理：去噪、糾偏） | 高 |
判斷 B 類時最容易翻車：不要用「整份文件一個結論」。一份 200 頁的併購資料包，可能只有附錄掃描件需要 OCR。按頁檢測是 PDF OCR 優化與按文件檢測的分水嶺。
Adobe 在 PDF 字型與文字層 文件中說明了嵌入字型與掃描層的差異——預檢邏輯應對齊「頁級是否有 text operator」，而不是只看副檔名。
4. 預檢流水線：五步決策
- 結構探測：頁數、是否加密、是否損壞；損壞檔案進修復佇列，別送進按頁計費 OCR。
- 文字層探測：每頁擷取字元數、字型物件數；超過閾值（如 ≥ 30 可列印字元且亂碼率 < 5%）標記為
TEXT_OK。 - 影像佔比：單頁最大點陣圖面積 / 頁面面積 > 85% 且文字層為空 →
SCAN。 - 品質評分：對
SCAN頁算 DPI、對比度、傾斜角；過低品質先走影像增強再 OCR，避免「辨識失敗 → 重試 → 雙倍計費」。 - 路由：
TEXT_OK→ 本地抽取；SCAN→ OCR 佇列（可按語言/版式選引擎）；HYBRID→ 拆頁並行。
把以上五步寫成可觀測的指標：preflight_text_ratio、ocr_pages_ratio、ocr_retry_rate。每月檢視一次，比單純砍 OCR 單價更有效。
5. 工具比較：開源 vs 雲端 API
| 環節 | 開源 / 本地 | 雲端 API |
|---|---|---|
| 預檢 / 抽文字 | PyMuPDF、poppler pdftotext、qpdf | 一般不需要雲端 |
| OCR 引擎 | Tesseract、PaddleOCR、Surya | Document AI、Textract、Azure DI |
| 表格還原 | pdfplumber、camelot（原生 PDF） | 雲端「表單/表格」模式 |
| 適合 | 大批量、合規要求資料不出境 | 複雜版式、多語言手寫、SLA |
OCR Optimization 的常見組合：本地預檢 + 雲端 OCR 只處理 SCAN 頁。這樣既保留雲端廠商在難例上的準確率，又把呼叫量壓到真正需要的子集。
6. 實作範例：Python 預檢 + 路由
# pip install pymupdf
import fitz # PyMuPDF
MIN_CHARS = 30
MAX_GARBAGE_RATIO = 0.05
def page_classify(page) -> str:
text = page.get_text("text").strip()
if len(text) >= MIN_CHARS:
import re
garbage = len(re.findall(r"[^\w\s\u4e00-\u9fff.,;:%/-]", text, re.U))
if garbage / max(len(text), 1) <= MAX_GARBAGE_RATIO:
return "TEXT_OK"
imgs = page.get_images(full=True)
if imgs and len(text) < MIN_CHARS:
return "SCAN"
return "HYBRID"
def route_pdf(path: str) -> dict:
doc = fitz.open(path)
stats = {"TEXT_OK": 0, "SCAN": 0, "HYBRID": 0}
ocr_pages = []
for i, page in enumerate(doc):
kind = page_classify(page)
stats[kind] += 1
if kind != "TEXT_OK":
ocr_pages.append(i)
return {"stats": stats, "ocr_pages": ocr_pages}
正式環境請加上：逾時、並行限制、加密 PDF 密碼回呼、以及把結果寫入物件儲存中繼資料，供下游檢索服務讀取。預檢本身應跑在穩定、可水平擴展的 worker 上——批次任務與 CI 類 workload 類似，與其擠在共享 VPS 上，不如用固定算力節點（見文末雲端 Mac 方案）。
7. 案例：一年節省約 80% OCR 成本
某跨境物流 SaaS，日均入庫 8,000 份 提單/報關 PDF（平均 4 頁，約 3.2 萬頁/日）。改造前：全量 Document AI 基礎 OCR，約 $0.006/頁，月費約 $5,760。
| 階段 | 動作 | OCR 頁佔比 | 月 OCR 費用（估） |
|---|---|---|---|
| 改造前 | 全量雲端 OCR | 100% | ~$5,760 |
| 改造後 | 頁級預檢 + 本地抽文字 | 22% | ~$1,270 |
| 節省 | — | — | ~78%（含預檢算力仍 <$200/月） |
額外收益：原生文字欄位準確率從 OCR 的 96% 提升到接近 100%；客服工單裡「單號辨識錯誤」下降 40%+。這就是 OCR Cost 優化裡常被忽略的隱性收益。
8. OCR Optimization 檢查清單
- ☐ 指標儀表板：文字抽取頁 / OCR 頁 / 重試頁 三元組
- ☐ 按頁路由，禁止「整檔一種策略」
- ☐ 掃描頁先品檢（DPI、傾斜）再 OCR，控制重試
- ☐ 原生 PDF 表格走 pdfplumber/camelot，別用拍照式 OCR 辨表格
- ☐ 多語言文件按語種選引擎（中日韓與拉丁系分開評測）
- ☐ 抽樣人工對齊：預檢標為 TEXT_OK 的頁，每週抽檢 0.1%
- ☐ 帳單告警：OCR 呼叫日環比 +30% 自動通知（與 API 成本分層 同一套 FinOps 紀律）
9. 常見問題
預檢會不會比 OCR 還慢？
單頁文字探測通常是毫秒級，遠低於雲端 OCR 的網路 RTT + 推理時間。瓶頸在批次 IO 時，用並行 worker 與本地 SSD 快取即可。
文字層是「假文字」怎麼辦？
有些掃描 PDF 會疊一層劣質 OCR 文字。用亂碼率、與影像區塊重疊檢測、以及抽樣人工校驗識別；可疑頁降級為 SCAN 重新 OCR。
加密 PDF 如何處理？
在預檢階段解析權限位元；需要密碼的進解密佇列。切勿把解密失敗檔案反覆送進計費 OCR。
80% 節省是否適用於所有產業？
取決於原生文字佔比。純掃描檔案庫可能只能省 10%–20%；電子發票、合約、報表類可達 70%–85%。先用 1% 樣本做預檢統計再立項。
自架 Tesseract 能否取代雲端 OCR？
簡單版式、大批量場景可以；複雜表格、手寫、多欄雜誌式排版仍建議雲端 API 或專用模型。最佳實踐是預檢本地做、難例上雲。
和 LLM「讀 PDF」有什麼關係？
多模態模型按 token 計費讀 PDF 更貴。應先把 PDF 變成乾淨文字/JSON，再餵給 LLM；這與 OCR 前預檢是同一套 FinOps 邏輯。
批次預檢與 OCR worker，需要穩定算力
文件預檢、影像增強與自架 OCR 都是長時間 CPU/GPU 任務：共享 VPS 上容易因鄰居干擾導致逾時重試，反而推高 OCR Cost。Apple Silicon 統一記憶體適合並行跑 PyMuPDF 預處理 + 本地推理，macOS 上 Python 工具鏈開箱即用，Gatekeeper 與權限模型也便於企業合規部署。
若你在搭建 PDF OCR 流水線或 RAG 文件入庫服務，Nuvcloud 雲端 Mac mini M4 提供獨享算力與固定出口 IP，適合作為預檢與 OCR worker 節點——查看方案，讓 OCR Optimization 算在穩定硬體上。