症状： RAG に数千の PDF を入れたのに、回答がフッターの著作権表示や壊れた表、古い付録を引用する——embedding ジョブはすべて成功しているのに。
根本原因： 低品質 PDF は PDF Parsing の段階で壊れ、汚れたチャンクがそのまま Vector Database に入り、検索の信頼度は下がらず上がることさえある。
2026年7月、社内 Knowledge Base チームの 2,400 件の PDF を監査したところ、ゴールデン質問の引用精度は 78% から 51% に低下。top-3 ヒットの 63% に繰り返しヘッダーや OCR ノイズが含まれていた。本文はその防汚染パイプラインをまとめたもの——パーサーランキングではなく、埋め込み前に実行できるゲートと評価。数値は 2026-08-07 時点。
Quick Answer：リコールより先に汚データを止める
| 状況 | 最初にやること | 急がないこと |
|---|---|---|
| 初めて PDF を投入 | 50 件サンプルで Parsing 比較 + 抽出率ゲート | より大きい embedding モデルへ変更 |
| 回答にヘッダー/著作権 | ヘッダー・フッター除去 + 重複行 dedup | さらに文書を増やす |
| 表の回答が幻覚 | 表を別解析または HTML/Markdown 化 | 盲目的に chunk を小さくする |
| スキャン PDF が中心 | OCR 品質スコア + 低スコアは人手キュー | すべて PyPDF に任せる |
| 大規模化で精度低下 | source_id バッチ削除 + ゴールデン回帰 | 原因調査なしの全再埋め込み |
Vector Database を汚す 5 つの PDF パターン
ベクトルストアはテキストが無意味かどうかを知らない——embedding されれば類似度で競合する。PDF 特有のレイアウト罠が Knowledge Base 汚染の最大要因。
| パターン | 症状 | 検索への影響 | 検出シグナル |
|---|---|---|---|
| 繰り返しヘッダー/フッター | 毎ページ同じ社名・ページ番号 | 汎用クエリが著作権にヒット | チャンク内同一短文 ≥3 回 |
| OCR ノイズ | l と 1 の混同 | キーワード・意味の両方がずれる | 非辞書文字 >8% |
| 壊れた表 | 列崩れ・セル順序乱れ | 数値の幻覚 | 区切りなし長数字列 |
| 2 段組/脚注の混線 | 段が交差 | 引用が不連続 | 行幅の急変 |
| 古い付録 | 廃止済みポリシー | 正しいが古い回答 | mtime と業務バージョン不一致 |
文字数が多い ≠ 良い Knowledge Base。 最高文字数のパーサーは、レイアウト対応より 11 ポイント低い 回答可能率——ノイズも「内容」に数えられていた。
インジェストゲート：embedding の前に遮断
Vector Database をファイル置き場ではなく本番 DB として扱う。最小 4 段階のゲート：
- ファイル： パスワード保護、0 文字、抽出率 <15% → 拒否または OCR キュー。
- ページ： 空白・画像のみ・近複製 → スキップ。
- チャンク： token <30、重複行 >40% → 破棄。
- 業務：
source_idなし → 書き込み禁止。
長コンテキストはクリーンな ingest の代替にならない——Kimi K3 1M コンテキストと RAG の境界 を参照。
PDF Parsing：文字数ではなく回答可能率で選ぶ
| シナリオ | 推奨 | 長所 | 注意 |
|---|---|---|---|
| デジタル PDF・本文中心 | PyMuPDF / pdfplumber | 高速 | 表が壊れやすい |
| 複雑レイアウト | Unstructured / Docling | ブロック分類 | CPU/RAM 増 |
| スキャン | クラウド OCR | 精度高 | コスト・プライバシー |
実測（2026-07、50 PDF）： hit@3 はレイアウト対応 74%、pdfplumber 61%。出力を 10 分読むのが正解。
チャンク分割：フッターを増幅させない
- 見出し・section 単位で分割し、長い節だけスライディングウィンドウ。
- ヘッダー重複時は overlap を抑え、10–15% に。
- 表は
content_type=tableで独立。
メタデータでロールバック可能な Knowledge Base に
source_id、ingest_batch、parser_version、content_hash、effective_date を必須に。近複製（cosine >0.95）は密度の高い方を残す。
事例：2,400 PDF のロールバック
| 指標 | 修正前 | ゲート + 再解析後 |
|---|---|---|
| 40 問 hit@3 | 51% | 79% |
| ヘッダー/著作権引用 | 63% | 4% |
| チャンク総数 | 1.28M | 0.71M |
7 ステップチェックリスト
- 50 PDF をサンプルし、自動ゲートと人手ラベルを比較。
- 2 つの PDF Parsing を 20 問で比較。
- ヘッダー/フッター規則を staging で検証。
- メタデータ完備と
source_id削除の確認。 - 20–50 問の評価セットを維持。
- 拒否率の急増を監視。
- 四半期ごとに期限切れ文書を整理。
ローカル試行は 30 分 AI 開発環境 を参照。
パースはワーカー、Vector Database はクリーンな塊だけ
PDF Parsing はバッチ CPU ジョブ。Macstripe クラウド Mac で macOS 専用変換を回し、Linux 側のベクトルサービスへ同期する構成も有効。
FAQ
PDF はなぜ Markdown より Vector DB を汚しやすい？
レイアウト非表示、OCR、繰り返しヘッダー、壊れた表がそのまま embedding され、繰り返しでランクが上がるため。
embedding 前の最低ゲートは？
抽出率、重複行、長さ、言語検出。source_id なしは書き込み禁止。
どの PDF Parsing？
デジタルは PyMuPDF/pdfplumber、複雑版面は Unstructured/Docling、スキャンは OCR。ゴールデン質問で選ぶ。
汚染を全再埋め込みなしで直せる？
source_id と ingest_batch があれば、該当バッチだけ削除→再解析→再埋め込み。
まとめ
順序：PDF Parsing 品質 → ゲート → チャンク + メタデータ → ゴールデン評価 → embedding 調整。Vector Database はゴミを高信頼で返す。
関連：長コンテキストと RAG · ローカル AI 環境
