症狀： 你的 RAG 明明接入了上千份 PDF，使用者提問時卻頻繁引用頁尾版權行、亂碼錶格或十年前的過期附錄——而監控裡 embedding 任務全是綠的。
根因： 低質量 PDF 在 PDF Parsing 階段就已經碎了，髒 chunk 照樣寫進 Vector Database，檢索置信度卻不降反升。
我們在 2026 年 7 月幫一家內部 Knowledge Base 團隊覆盤：2,400 份企業 PDF 入庫後，黃金問題集的引用準確率從 78% 跌到 51%。回滾發現，63% 的 top-3 命中塊含重複頁首或 OCR 噪聲。本文把當時落地的防汙染管線寫清楚——不是 parser 排行榜，而是入庫前就能執行的閘門與評測。口徑截至 2026-08-07。
Quick Answer：先擋髒資料，再談召回率
| 你的處境 | 最該先做的一步 | 別急著做 |
|---|---|---|
| 剛接入第一批 PDF | 抽樣 50 份做 Parsing 對照 + 文字提取率閘門 | 換更大 embedding 模型 |
| 回答裡常出現頁首/版權 | 頁首頁尾剝離 + 重複行去重 | 加更多文件進庫 |
| 表格答案胡編亂造 | 表格塊單獨解析或轉 HTML/Markdown 再分塊 | 盲目縮小 chunk size |
| 掃描件為主 | OCR 質量分 + 低分進人工佇列 | 預設 PyPDF 一把梭 |
| 庫已很大、準確率下滑 | 按 source_id 批次刪除 + 黃金問題迴歸 | 全量重嵌而不查汙染源 |
五類 PDF 汙染源：Vector Database 裡的「隱形垃圾」
向量庫不會自動知道一段文字「沒意義」——只要被 embedding，它就會參與相似度競爭。PDF 特有的版式陷阱是 Knowledge Base 髒資料的第一來源。
| 汙染型別 | 典型表現 | 對檢索的傷害 | 快速識別訊號 |
|---|---|---|---|
| 重複頁首頁尾 | 每頁相同公司名、頁碼、保密宣告 | 泛化問題誤命中「版權宣告」 | chunk 內同一短句出現 ≥3 次 |
| OCR 噪聲 | l 與 1 混淆、斷詞 | 關鍵詞檢索與語義匹配雙失準 | 非詞典字元佔比 >8% |
| 表格碎裂 | 列對齊丟失、單元格亂序 | 模型「編造」表格數值 | 解析後無分隔符的長數字串 |
| 雙欄/腳註錯亂 | 左右欄串讀、腳註插入正文 | 引用段落語義不連貫 | 行寬突變、句子主謂斷裂 |
| 過期附錄與附件 | 舊版政策、已廢止條款 | 正確但過時的答案 | 檔案 mtime 與業務版本欄位不一致 |
一個常被忽略的事實：字元越多不代表 Knowledge Base 越好。我們在對照實驗裡，用「字元數最多」的 parser 抽出的文字，黃金問題可回答率反而比版面感知方案低 11 個百分點——因為噪聲也被算進了「有效內容」。
入庫閘門：在 embedding 之前攔截
把 Vector Database 當成生產資料庫，而不是網盤。推薦最小四級閘門（可用指令碼或佇列 worker 實現）：
- 檔案級： 密碼保護、0 字提取、提取率 < 15%（頁數 > 2）→ 拒收或轉人工 OCR。
- 頁級： 空白頁、純圖片頁、重複頁（simhash 相近）→ 跳過。
- 塊級： token < 30、重複行佔比 > 40%、語言檢測置信度低 → 丟棄。
- 業務級： 無
source_id、doc_version、ingest_batch→ 禁止寫入（否則無法回滾）。
| 閘門指標 | 建議閾值（起點） | 動作 |
|---|---|---|
| 文字提取率 | < 20% 且非掃描件標註 | quarantine |
| 行級重複率 | > 35% | 剝離頁首頁尾後重算 |
| 塊內唯一 token 比 | < 0.25 | 丟棄或合併 |
| OCR 置信度（若有） | 均值 < 0.75 | 人工複核佇列 |
閘門日誌要進可觀測系統：拒收原因分佈比「今日嵌入 10 萬條」更能預警質量下滑。長上下文模型不能替代乾淨入庫——見 Kimi K3 1M 上下文與 RAG 的邊界。
PDF Parsing 工具怎麼選：比字元數，比可回答問題率
沒有萬能 parser。用 50 份分層樣本（數字原生、掃描、表格密集、雙欄論文）做對照，指標是「黃金問題能否定位到正確段落」，不是 PDF 頁數。
| 場景 | 優先方案 | 優勢 | 注意 |
|---|---|---|---|
| 數字原生 PDF、以段落為主 | PyMuPDF / pdfplumber | 快、依賴少 | 複雜表格易碎 |
| 混合版面、多欄、圖注 | Unstructured / Docling | 版面塊分類 | 算力與記憶體更高 |
| 掃描件、拍照 PDF | 雲 OCR + 版面還原 | 字元準確率更高 | 成本與隱私評審 |
| 法規/財報級表格 | 表格專用抽取 + 結構化儲存 | 數值問答更穩 | 不一定進同一向量集合 |
實測片段（2026-07，50 份企業內部 PDF）： pdfplumber 平均提取 118k 字元/份，版面感知方案 97k 字元/份，但後者在 20 題黃金集上的 hit@3 為 74%，前者僅 61%。結論：為 Knowledge Base 選型時，把 PDF Parsing 輸出給人看 10 分鐘，比看 benchmark 截圖管用。
分塊策略：別讓頁尾佔滿向量空間
分塊不是「固定 512 token 一刀切」。PDF 建議：
- 結構優先： 按標題層級（H1/H2）或 parser 輸出的 section 切，再對過長節做滑動視窗。
- 重疊要省： 頁首重複時，大 overlap 會把噪聲複製多份；先清洗再設 10–15% overlap。
- 表格獨立： 表格塊附帶
content_type=table，檢索時可加權或走結構化查詢。 - 引用錨點： 每塊儲存
page、bbox（若有），方便前端展示原文截圖。
使用者案例：某客服 Knowledge Base 把 chunk 從 512 降到 256 想「提高精度」，結果頁尾塊數量翻倍，投訴「AI 總讓我聯絡法務」。清洗頁首後，相同 chunk 尺寸準確率回升 19%。
去重與後設資料：可回滾的 Knowledge Base
Vector Database 必須能回答三個運維問題：這塊來自哪份 PDF？哪次入庫？能否單獨刪除？
| 後設資料欄位 | 用途 |
|---|---|
source_id | 邏輯文件 ID，支援版本覆蓋 |
ingest_batch | 批次回滾、對比 A/B parser |
parser_version | 重跑時只選受影響批次 |
content_hash | 近重複塊合併（simhash / minhash） |
doc_version / effective_date | 過濾過期政策 |
入庫時對 chunk 做 近重複檢測：餘弦 > 0.95 且來源不同頁面 → 保留資訊密度更高的一塊。否則 Vector Database 會被「第 3 頁頁尾」的變體淹沒。
實測：2400 份 PDF 的汙染覆盤
客戶場景：內部合規與產品文件庫，混合中英文 PDF。汙染修復前後對比如下（同一 embedding 模型與檢索引數）：
| 指標 | 修復前 | 加閘門 + 重解析後 |
|---|---|---|
| 黃金 40 題 hit@3 | 51% | 79% |
| 引用含頁首/版權行佔比 | 63% | 4% |
| 入庫 chunk 總數 | 1.28M | 0.71M（去重後） |
| 單次查詢 P95 延遲 | 1.9s | 1.4s（索引更小） |
| 拒收/隔離檔案數 | 0 | 187（需 OCR） |
關鍵動作：不是換向量庫，而是拒收 7.8% 檔案、刪除 22% 髒 chunk、對錶格文件改用結構化旁路。更少的資料，更高的可回答率——這才是 Knowledge Base 該有的形狀。
七步驗收清單：上線前與每週迴歸
- 抽樣 50 份 PDF，人工標註「可讀/不可讀」並與自動閘門對比。
- 跑兩套 PDF Parsing，用 20 條黃金問題選贏家。
- 配置頁首頁尾規則（正則 + 重複行檢測），在 staging 驗證 top 結果無版權行。
- 寫入完整後設資料，確認能按
source_id刪除單文件。 - 建立 20–50 題評測集，記錄 hit@k 與引用片段截圖。
- 監控拒收率突增——常是新批次掃描件未走 OCR。
- 每季度重跑過期文件，按
effective_date降權或下架。
需要本地批次試跑解析指令碼時，可參考 30 分鐘 AI 開發環境搭建，把 parser 與評測指令碼放在固定機器上，避免「我電腦上能跑」與生產不一致。
場景收束：算力放 Parsing，向量庫只存乾淨塊
PDF Parsing 與 OCR 往往是 CPU/記憶體密集型批任務，不適合和線上 API 搶同一檯筆記本。常見做法是：專用 worker 做解析與閘門 → 乾淨 chunk 再 embedding → Vector Database 只接收透過評測的批次。
若團隊還需要 macOS 專屬工具鏈（例如某些文件轉換或內部指令碼），用 Macstripe 雲 Mac 跑批處理、把產物同步到 Linux 上的向量服務，比每人一臺實體 Mac 更易擴縮。解析流水線與 RAG 線上服務解耦，汙染面也更可控。
常見問題
為什麼 PDF 比 Markdown 更容易汙染向量資料庫？
版式隱藏、掃描 OCR、重複頁首與表格碎裂，使無意義文字獲得與高價值段落相同的 embedding 機會；檢索按相似度排名，噪聲塊常因高頻重複而佔優。
入庫前最低限度的質量閘門是什麼？
檔案提取率、重複行、塊長度與語言檢測；無 source_id 的 chunk 禁止寫入，以便汙染時可批次回滾。
Knowledge Base 該選哪種 PDF Parsing 工具？
數字原生用 PyMuPDF/pdfplumber；複雜版面用 Unstructured/Docling；掃描件用 OCR。用黃金問題集比字元數選型。
chunk size 越小越好嗎？
不是。過小塊會複製頁首噪聲；應先清洗版式再定尺寸，表格宜獨立成塊。
向量庫髒了能否不全量重嵌？
可以，前提是有 source_id 與 ingest_batch。刪除髒批次 → 重解析 → 只重嵌受影響文件。
總結
適合立刻做防汙染管線的團隊： PDF 佔比高、已出現「答非所問但引用了某頁頁尾」、或準備擴大 Knowledge Base 規模前。
可以暫緩的情況： 語料幾乎全是結構化 Markdown/HTML，且已有文件版本與刪除策略。
記住順序：PDF Parsing 質量 → 入庫閘門 → 分塊與後設資料 → 黃金問題評測 → 再最佳化 embedding 與重排。Vector Database 不會替你過濾垃圾；髒資料進去，只會以更高的置信度出來。
延伸閱讀：長上下文與 RAG 如何分工 · 本地 AI 開發環境快速搭建
