如何批量檢測 PDF 是否需要 OCR？企業知識庫最佳實踐

企業知識庫项目最常见的預算黑洞，不是向量資料庫，而是對全部 PDF 無腦 OCR。法務部上傳的三千份合約裡，可能有一半是 Word 匯出的原生 PDF——文字層完整、可直接切塊進 RAG；另一半才是掃描件，必須走 Batch OCR。若不做 PDF OCR Detection 就全量 OCR，你不仅在浪费 GPU 算力，还會在檢索侧引入大量亂碼塊，拉低 Enterprise Knowledge Base 的召回品質。

本文面向正在搭建或運維企業知識庫的技術負責人與平台工程師，给出一套可落地的三層檢測流水線：先用元資料與文字層快篩，再用圖像覆蓋率與字元密度打分，最後對灰區做抽樣 OCR 校驗。配合 Batch OCR 佇列設計與治理規範，幫你在上線前回答一個關鍵問題：這份 PDF，到底要不要 OCR？

核心結論：「檢測 → 分流 → 按需 OCR」比「全量 OCR」通常可節省 40%–70% 的處理成本，同時讓知識庫檢索準確率更穩定。下面從原理、腳本到 Enterprise Knowledge Base 最佳實踐完整展開。

1. 為什麼「全量 OCR」是知識庫最貴的錯誤

很多團隊把「PDF 入庫」等同於「OCR 一遍」。这在 2018 年或許合理——當時掃描件占大多數；但 2026 年的 Enterprise Knowledge Base 裡，原生 PDF 占比往往超過一半：ERP 報表匯出、Confluence/Notion 列印、代码審查 PDF、電子簽章合約。这些檔案已有高品質文字層，再 OCR 只會：

• 重複勞動：Tesseract 或雲 OCR 按頁計費，原生 PDF 白白燒錢；
• 引入噪聲：OCR 誤識別會覆蓋原本正確的文字層，embedding 後檢索命中亂碼；
• 拖慢 SLA：百萬頁全量 OCR 可能要跑數天，阻塞知識庫上線。

更隱蔽的問題是雙層 PDF：上層有劣質 OCR 文字層，下層才是真掃描图。簡單呼叫 page.get_text() 可能返回看似有字、實則不通順的內容。这就是為什麼需要系統的 PDF OCR Detection，而不是「文字為空才 OCR」的單行判斷。

與 RAG 記憶層的關係：若你已部署向量檢索 + Agent 記憶（可參考本站TencentDB Agent Memory 快速入门：10 分钟搭建 AI 长期记忆），髒 OCR 會污染長期記憶提取——L1 原子事實裡塞進錯誤字元，比「沒索引這篇 PDF」更難排查。檢測分層是知識庫資料品質的第一道閘。

2. PDF OCR Detection 三層檢測模型

我們把每份 PDF 分為三檔：SKIP（無需 OCR）、OCR_REQUIRED（必須 OCR）、REVIEW（灰區，需人工或抽樣 OCR）。檢測分三層，由快到慢，逐層過濾。

2.1 Layer 1：元資料與結構快篩（< 10 ms/檔案）

用 Apache Tika 或 pdfinfo 讀取：頁數、是否加密、Producer/Creator（部分掃描仪會寫入特征字元串）、是否有 XMP 標記。规則示例：

• 加密且無法解密 → 標記 REVIEW，不要靜默失敗；
• 頁數为 0 或損壞 → 隔離到 quarantine 桶；
• Creator 含 "Scanner"、"FineReader" 且無字體嵌入 → 傾向 OCR_REQUIRED。

2.2 Layer 2：文字層品質評分（< 200 ms/頁，可並行）

用 PyMuPDF (fitz) 或 pdfplumber 提取每頁文字，計算：

• chars_per_page：可列印字元數 / 頁數；
• word_ratio：詞典命中率或語言模型困惑度；
• image_coverage：頁面圖像像素占頁面面積比例；
• font_count：有嵌入字體通常意味著原生文字。

2.3 Layer 3：灰區抽樣 OCR 校驗

對 REVIEW 檔隨機抽 1–2 頁，用快速 OCR（Tesseract --psm 6 或轻量雲端 API）與 Layer 2 文字層對比 字元相似度（Levenshtein / Jaccard）。相似度 < 0.3 → 判定必須 OCR；> 0.8 → 可 SKIP。中間地帶進入人工佇列或按業務優先級預設 OCR。

Apache Tika 的 PDFParserConfig 可配置是否提取內嵌 OCR 層；企業場景建議顯式關閉「信任內嵌文字」，改用自己的品質評分，避免被歷史劣質 OCR 誤導。

3. Batch OCR 流水線架构

檢測與 OCR 應解耦为非同步流水線，典型組件：

1. Ingest：物件儲存（S3/MinIO）+ 訊息佇列（Kafka/RabbitMQ/SQS）；
2. Detector Worker：無狀態水平擴展，輸出 {file_id, tier, scores, hash}；
3. Router：按 tier 寫入 text_extract、ocr_queue、human_review 三條通道；
4. OCR Worker：可用 OCRmyPDF（基於 Tesseract，輸出可搜尋 PDF）或雲廠商 Document AI；
5. Indexer：切塊、embedding、寫入向量庫與全文檢索（OpenSearch/Elasticsearch）。

Batch OCR 的關鍵工程細節：

• 冪等：以 content_hash + ocr_engine_version 為鍵，避免重複 OCR；
• 優先級：法務/合規檔案可設高優先級佇列，歷史歸檔走低優夜間批；
• 死信與重試：OCR 逾時（大圖、傾斜）進 DLQ，人工旋轉/分片後重跑；
• 可觀測：按 tier 統計比例，若 REVIEW 長期 > 25%，說明 Layer 2 閾值需调優。

4. 實戰：Python 批量檢測腳本

以下腳本演示 Layer 2 核心邏輯，依賴 pymupdf，可批量掃描目錄並輸出 CSV 報告：

#!/usr/bin/env python3
"""Batch PDF OCR Detection — tier: SKIP | OCR_REQUIRED | REVIEW"""
import csv, sys
from pathlib import Path
import fitz  # PyMuPDF

def score_page(page):
    text = page.get_text("text") or ""
    chars = sum(1 for c in text if c.isprintable())
    blocks = page.get_text("dict")["blocks"]
    img_area = sum(
        (b["width"] * b["height"])
        for b in blocks if b["type"] == 1
    )
    page_area = page.rect.width * page.rect.height or 1
    return chars, img_area / page_area

def classify_pdf(path: Path) -> dict:
    doc = fitz.open(path)
    total_chars, coverages = 0, []
    for page in doc:
        c, cov = score_page(page)
        total_chars += c
        coverages.append(cov)
    n = max(len(doc), 1)
    cpp = total_chars / n
    avg_cov = sum(coverages) / n
    if cpp > 400 and avg_cov < 0.08:
        tier = "SKIP"
    elif cpp < 30 and avg_cov > 0.75:
        tier = "OCR_REQUIRED"
    else:
        tier = "REVIEW"
    return {"file": path.name, "pages": n, "chars_per_page": round(cpp, 1),
            "image_coverage": round(avg_cov, 3), "tier": tier}

if __name__ == "__main__":
    rows = [classify_pdf(Path(p)) for p in sys.argv[1:]]
    w = csv.DictWriter(sys.stdout, fieldnames=rows[0].keys())
    w.writeheader(); w.writerows(rows)

用法：python pdf_ocr_detect.py /data/kb/inbox/*.pdf > report.csv。生產環境建議：

• 將閾值寫入設定檔，按部門（財務 vs 市場）使用不同 profile；
• Layer 1 先用 qpdf --check 過濾損壞檔案；
• 結果寫入元資料表，Indexer 只消費 tier != OCR_PENDING 的已完成 OCR 記錄。

5. Enterprise Knowledge Base 最佳實踐

檢測與 Batch OCR 只是數据面；Enterprise Knowledge Base 要長期可維護，還需治理面：

5.1 入庫規範（Upstream）

• 上傳入口強制選擇檔案类型：「原生電子檔 / 掃描件 / 混合」——用戶自聲明可降低 15% 灰區；
• 禁止重複上傳：用 SHA-256 去重，保留最新版本指標；
• 单檔案頁數上限（如 500 頁）與自動分片，避免 OCR Worker OOM。

5.2 品質門禁（Quality Gate）

• SKIP 檔：直接文字提取 → 語言檢測 → 切塊，抽樣 1% 人工可讀性檢查；
• OCR_REQUIRED：OCR 後計算 CER（字元錯誤率）抽樣，CER > 8% 進人工校正；
• 檢索侧：對低置信塊打 low_ocr_confidence 標籤，Rerank 時降權。

5.3 安全與合規

Batch OCR 常在離線路徑處理敏感 PDF。建議：檢測與 OCR 在內網 VPC 完成；云 OCR API 出網前做 DLP 掃描；OCR 結果與源檔案同權限域儲存，避免「源檔案受限、文字層公開」的權限穿透。

5.4 運維節奏

6. 常见問題 FAQ

扫描版 PDF 和原生 PDF 在检测上有什么区别？

原生 PDF 通常含可提取文本层（font embedding + ToUnicode），检测时 chars_per_page 高、image_coverage 低；扫描版本质是嵌在 PDF 里的位图，文本层为空或乱码，image_coverage 接近整页。两者混合的「双层 PDF」需要同时看文本质量与图像占比。

Batch OCR 应该用 CPU 还是 GPU？

日处理量 < 5 万页、以 Tesseract 为主时，多核 CPU + 队列并行往往够用；日处理量 > 20 万页或需要深度学习 OCR（PaddleOCR、TrOCR）时，再引入 GPU 节点。先用检测分层把 60% 原生 PDF 跳过，比盲目加 GPU 更省钱。

检测脚本需要多久跑一次？

建议入库时实时跑 Layer 1–2（毫秒级），全库 Layer 3 抽样每周一次；知识库大版本迁移或合库后做全量重扫。变更检测用文件 hash + 页数，避免重复 OCR。

7. 總結與下一步

企業知識庫不是「把 PDF 扔進向量庫」这么簡單。PDF OCR Detection 三層流水線幫你把原生 PDF、掃描件與灰區分开；Batch OCR 佇列讓算力花在刀刃上；Enterprise Knowledge Base 治理規範則保證三個月後仍可運維。建議落地順序：

• Week 1：在 staging 跑檢測腳本，統計三檔比例，校準閾值；
• Week 2：接通 OCR 佇列與冪等索引，選 1000 份代表性 PDF 端到端驗證；
• Week 3：上線品質門禁與監控大盤，再全量匯入歷史库。

檢測做好，RAG 召回率與成本曲線會同時好看——這比事後清洗十萬條髒 chunk 便宜一個數量级。