From PDF to RAG-Ready: Evaluating Document Conversion Frameworks for Domain-Specific Question Answering

この論文は、ドメイン固有の質問応答におけるRAGシステムの性能を決定づける最も重要な要因が変換フレームワークの選択そのものではなく、メタデータ付与や階層型チャンキングを含むデータ前処理の質であることを、ポルトガル語の行政文書を用いた大規模評価を通じて実証しています。

要約

この論文は、**「AI に専門的な質問に答えてもらうとき、最も重要なのは『AI の頭脳（モデル）』ではなく、『AI に渡す資料の準備』である」**という驚くべき発見を伝えています。

まるで、**「世界最高の料理人（AI）に最高の料理を作らせようとしても、渡す食材が腐っていたり、包丁で切れていなかったりしたら、美味しい料理は作れない」**という話に似ています。

以下に、この研究のポイントを、わかりやすい比喩を使って解説します。

---

1. 研究の背景：なぜ「PDF」は AI の天敵なのか？

現代の AI（LLM）は、人間が書いた文章を元に質問に答えることができます。しかし、多くの企業や組織は、重要な情報が**「PDF」**という形式で保存されています。

• PDF の正体： PDF は、紙の書類を「そのままの見た目」で保存するために作られたものです。AI にとっては、**「文字がバラバラに散らばった、意味のわからない絵」**のように見えます。
• 問題点： AI が PDF をそのまま読み込もうとすると、表（テーブル）が崩れたり、段落の順序が狂ったり、特殊な文字（日本語やポルトガル語の「ç」など）が誤読されたりします。
  • 例： ポルトガル語で「狩り（caça）」が「うんち（caca）」と誤読されてしまうようなミスが起きると、AI の回答は完全に意味を失ってしまいます。

2. 実験：4 つの「翻訳機」を比べた

研究者たちは、この「PDF を AI が読めるテキストに変換する」ための 4 つの異なるツール（変換フレームワーク）をテストしました。

• 比較対象：
  1. Docling（ドクリング）： 最新の、構造を詳しく分析できるツール。
  2. MinerU（マイナーU）： OCR（文字認識）に特化したツール。
  3. DeepSeek OCR： 画像として見てから文字にするツール。
  4. PDFLoader（単純な読み込み）： 何も加工せず、ただ文字を抜き取るだけの「素人」ツール。

これらを使って、ポルトガル軍の人事文書（36 冊、約 1700 ページ）を AI に読み込ませ、50 個の質問に正しく答えられるかを評価しました。

3. 驚きの結果：「食材の準備」が勝敗を決めた

結果は、「変換ツール」そのものよりも、「変換後のデータの整理方法」が圧倒的に重要であることがわかりました。

• 最悪のケース： 変換ツールを間違えたり、整理しなかった場合、正解率は**71%**まで下がりました。
• 最高のケース： 最新のツール（Docling）を使い、かつ**「文書の構造（見出しや章立て）を正しく保ちながら」データを切り分け**、画像の説明も追加した場合、正解率は**94%**まで跳ね上がりました。
• 人間の手作業： 人間が手作業で完璧に整理したデータは**97%でした。つまり、「適切な準備をすれば、AI は人間の手作業にほぼ匹敵する性能を出せる」**のです。

重要な発見：3 つの「魔法の道具」

この研究で特に効果的だったのは、ツール選びよりも以下の 3 つの工夫でした。

1. 階層的な切り分け（パンくずリスト）：
   • 比喩： 本をただバラバラに切り裂くのではなく、「第 1 章 > 第 2 節 > 3 ページ目」という**「住所」**を各ページに付箋として貼っておくようなものです。
   • AI はこの「住所」を見ることで、「今読んでいるのは、この文書のどの部分か？」を瞬時に理解し、的外れな回答を防ぎます。
2. フォントベースの整理：
   • 比喩： 文字の太さや大きさ（フォント）を見て「これは見出しだ」と判断する、**「人間の直感的な読み方」**です。
   • 最新の AI が文脈から推測するよりも、単純な「文字の太さ」で判断する方が、法律文書のような整った書類では正確でした。
3. 画像の説明：
   • 図表や写真に「これは何を示しているか」という説明文を付け加えるだけで、AI の理解度が上がりました。

4. 失敗した試み：「知識グラフ」は今回は不要だった

最近、AI に「知識グラフ（関係性を網の目のように結んだ地図）」を持たせる手法が流行っています。研究者もこれを試みました。

• 結果： 期待していたのに、**「普通の RAG（検索＋生成）の方が 12% も高かった」**という残念な結果に終わりました。
• 理由： 地図を作る作業自体が複雑で、AI が勝手に間違った関係性を結びつけてしまい、かえって混乱を招いたようです。
• 教訓： 「まずは食材をきれいに洗って切る（データ準備）こと」が先で、「特別な調理器具（知識グラフ）を使うこと」は後回しでいい、という結論になりました。

5. 結論：私たちが学ぶべきこと

この論文が私たちに教えてくれる最大のメッセージはこれです。

「AI の性能を上げたいなら、新しい AI モデルを探す前に、まずは『渡す資料（データ）』をきれいに整えなさい。」

• ゴミを入れれば、ゴミが出る（Garbage In, Garbage Out）： いくら高性能な AI でも、汚れたデータからは良い答えは出ません。
• 準備が 9 割： 検索のアルゴリズムをいじったり、AI を入れ替えたりする前に、**「PDF をどうやって AI が読みやすい形に変えるか」**という工程に時間をかけることが、最もコストパフォーマンスが良い投資です。

まとめ

この研究は、**「AI 導入の成功は、最新の技術の導入ではなく、地道な『データ掃除』と『整理整頓』にかかっている」**ことを証明しました。

まるで、**「最高のカメラ（AI）を持っていても、レンズが汚れていたり、三脚が安定していなければ、美しい写真は撮れない」**のと同じです。まずはレンズをきれいに拭き、三脚を正しくセットすること（データ準備）から始めましょう。

技術概要

論文要約：ドメイン固有の質問応答におけるドキュメント変換フレームワークの評価（PDF から RAG 対応へ）

この論文は、Retrieval-Augmented Generation（RAG） システムの性能において、ドキュメントの前処理（特に PDF から構造化テキストへの変換）がどれほど決定的な役割を果たすかを検証した研究です。既存の研究が検索アルゴリズムや LLM 自体の最適化に焦点を当てがちであるのに対し、本論文は「データ準備の質」がシステム全体の精度を支配する主要因であることを実証的に示しました。

以下に、問題定義、手法、主な貢献、結果、および意義について詳細をまとめます。

---

1. 問題定義 (Problem)

RAG システムは、外部ドキュメントから関連情報を検索し、それを LLM に提示して回答を生成するアーキテクチャです。しかし、多くの研究では、入力テキストの品質（前処理）が十分考慮されていません。

• PDF の課題: PDF は印刷や視覚的なレイアウト保存を目的としており、構造的な意味（見出し、表、段落の順序など）を機械的に抽出するのは困難です。
• 前処理の重要性: 変換プロセスで生じる誤り（表の崩壊、見出し階層の喪失、文字認識エラーなど）は、そのまま検索と生成段階に伝播し、システムの精度低下やハルシネーション（幻覚）の原因となります。
• 研究ギャップ: 既存のベンチマークは「テキストの忠実度（編集距離など）」を評価するものですが、「変換の質が実際の RAG 質問応答精度にどう影響するか」を評価した先行研究は存在しませんでした。特に、ポルトガル語のような特殊文字（例: "ç"）を含むドメイン固有の文書における評価が不足していました。

2. 手法 (Methodology)

研究者は、ポルトガル軍の人事部門から提供された 36 件の行政文書（1,706 ページ、約 49 万語）を用いた大規模な実験を行いました。

2.1 評価対象フレームワーク

以下の 4 つのオープンソース PDF 変換フレームワークを比較しました：

1. Docling: モジュール化された専用モデルを使用（レイアウト分析、表認識、OCR）。
2. MinerU: OCR ベースのツール（OpenDataLab 製）。
3. DeepSeek OCR: ビジョン・ランゲージモデル（VLM）アプローチ。
4. PDFLoader (LangChain): 単純なテキスト抽出（低基準ライン）。
   • 注: Marker はプライバシー懸念（クラウド版）およびローカル版の性能不足により除外されました。

2.2 実験設定

• パイプライン構成: 19 種類の構成で実験を行いました。変数は以下の通りです。
  • 変換フレームワーク
  • 前処理変換（HTML 表のクリーニング、LaTeX 式の変換、階層の再構築）
  • チャンキング戦略（再帰的、Markdown 再帰的、階層的再帰的）
  • メタデータ付与（パンくずリスト情報の追加など）
• 評価指標: 50 問の人手作成された質問セットを用い、LLM-as-a-Judge（LLM を裁判官として回答を評価）方式で 10 回実行し、平均精度を算出しました。
• ベースライン:
  • 下限：前処理なしの PDFLoader（86.9%）
  • 上限：人手で修正された Markdown（97.1%）
• GraphRAG の探索: 基本的な RAG に加え、LangChain の LLMGraphTransformer を用いて知識グラフ（Neo4j）を構築し、GraphRAG としての性能も検証しました。

3. 主な結果 (Key Results)

3.1 変換フレームワークと前処理の影響

• 最高精度: Docling を使用し、階層的なスプリッティング（Hierarchical Recursive）と画像の説明（VLM による）を付加した構成が、94.1% の精度を達成しました。これは人手修正ベースライン（97.1%）に極めて近い結果です。
• 最低精度: DeepSeek OCR は 71.2%、MinerU の一部設定は 74.7% と、PDFLoader ベースライン（86.9%）を下回る結果となりました。
• 変換ツールの差よりも重要: 変換ツール自体の選択よりも、**「階層を意識したチャンキング」と「メタデータ付与」**が精度に与える影響が大きいことが判明しました。
  • Docling で単純な再帰的スプリット（89.4%）から、階層的スプリット＋メタデータ付与（93.2%）に変更するだけで 3.8 ポイント向上しました。
  • 一方、変換ツール間の差（Docling vs PDFLoader）は同条件では 2.5 ポイント程度でした。

3.2 階層再構築手法の比較

• フォントベース vs LLM ベース: 文書の見出し階層を再構築する際、LLM による推論（HR-LLM）よりも、PDF メタデータに基づく**フォントベースの分析（HR-F）**の方が一貫して高い精度を示しました（3.5〜4.6 ポイントの差）。行政文書のような構造化されたドキュメントでは、決定論的なアプローチが優れていることが示されました。

3.3 GraphRAG の結果

• 知識グラフを構築した GraphRAG の精度は 82% にとどまり、基本的なベクトル検索 RAG（94.1%）を大きく下回りました。
• 実体（Entity）の重複除去を行っても精度は向上せず、むしろ 81% に低下しました。
• 原因: 専門的なオントロジー（ドメイン知識）なしに LLM で自動抽出したグラフは、ノイズが多く、疎で浅い構造になりがちであり、コミュニティ検出アルゴリズムなどの恩恵を受けられなかったと考えられます。

3.4 言語特有の課題

• ポルトガル語の特殊文字（例: "ç"）の認識誤りは、検索結果を著しく損なうことが確認されました（例: "caça" が "caca" と誤認識され、意味が完全に変わる）。Docling はこの点で優れており、MinerU の VLM 版は誤認識が多発しました。

4. 主な貢献 (Key Contributions)

1. データ準備の支配的役割の実証: RAG システムの性能向上において、検索アルゴリズムや LLM の選定よりも、**「ドキュメント前処理パイプラインの質」**が最も重要な要因であることを定量的に示しました。
2. ドメイン固有の評価ベンチマーク: 英語中心の既存ベンチマークとは異なり、ポルトガル語の行政文書（表、特殊文字、複雑なレイアウトを含む）を対象とした、RAG 応答精度に直結する評価を行いました。
3. 実践的な知見の提供:
   • 変換ツールの選択よりも、構造化されたチャンキングとメタデータ付与が重要である。
   • 構造化ドキュメントでは、LLM による階層推論よりフォントベースの解析が有効である。
   • 適切なオントロジー設計なしの GraphRAG は、高品質なベクトル RAG よりも劣る可能性が高い。
4. モジュラーなパイプラインの提案: 変換フレームワークや前処理ステップを容易に切り替え可能な ETL パイプラインアーキテクチャを設計し、再現性のある実験を可能にしました。

5. 意義と結論 (Significance & Conclusion)

本研究は、RAG システム開発者に対して重要なメッセージを送っています。

• 「Garbage In, Garbage Out」の再確認: 入力データの質が LLM の出力を決定づけます。高度な検索技術や大規模な LLM を導入する前に、まずはドキュメントの構造化とクリーニングに投資すべきです。
• GraphRAG への慎重なアプローチ: 知識グラフは万能ではなく、ドメイン固有のオントロジー設計やグラフの密化（densification）がなければ、単純なベクトル検索に劣る可能性があります。
• 非英語ドキュメントへの配慮: 特殊文字や言語固有の文脈を考慮した OCR/変換ツールの選定が、精度に直結します。

結論として、**「高品質なデータ準備（変換＋構造化＋メタデータ付与）こそが、RAG システムの成功の鍵である」**という知見が得られました。今後は、より大規模なコーパスでの検証や、ドメイン固有のオントロジーを用いた GraphRAG の再評価、および異なる LLM での評価が予定されています。