第2章 — インテリジェント文書パース

LLM Primer III: RAGで強化するエンタープライズAI を章ごとに紹介していくウォークスルー、第2回です。検索システムは入力の質を継承します — そして、入力層は、期待外れな RAG 品質のいちばん多い原因がそっと棲んでいる場所でもあります。

この章がなぜあるのか

RAG パイプラインの最初のバージョンは、たいてい手近にあった PDF→テキストユーティリティを使います。それらしいテキストが出てきて、インデックスが埋まり、モデルはそれらしい回答を返します。数ヶ月してチームは気づきます — 表は静かに散文に潰されていた、多段組の論文は1行ずつ交互に並んでいた、脚注は本文の段落に紛れ込んでいた、図のキャプションは丸ごと消えていた。検索品質の天井は、検索の設定をするより前に、ここで決まっていたのです。この章は、入力層を真面目に扱う話です。パーサーが捨てたものを、下流のどんな工夫も取り戻せないからです。

2.1 PDF を平らに潰すと何が失われるのか

PDF は、座標つきグリフのリストを、宣言された寸法のページに描画する形式です。人間が見ている視覚的構造 — 段組、表、キャプション、サイドバー — は意味形式ではどこにも保存されていません。レンダリングされた像のなかにあります。だから「PDF からテキストを抽出する」は、見た目より難しい。素朴な抽出器はマークが書かれた順にグリフ列を読みますが、2段組のページではこれが段を1行ずつ交互に拾うことになります。出てくるのは、文法的におかしく意味的に壊れた、けれど本物の単語からなるテキスト — スポットチェックでは見つけにくい失敗です。

表はもっと厄介です。3行4列目の 1,427 の意味は、2024年Q3 と 北東地域 の交点であることにあります。素朴な抽出器にとってこれは、両方の文字列とは関係を持たない数字です — 文字列はページ上の別の場所に描かれていたからです。表は空白で区切られた数字の列に溶け、「Q3の北東売上」を問うクエリは何も見つけません — 1,427 を含むチャンクには、埋め込み上でそれらを結びつけられるほど近くに「北東」が出てきません。フォームも類似の失敗をします。ラベルと値が分離した文字列として吐き出され、インデックスにはフィールド名なしの値が並びます。スキャン文書の OCR は、専門用語や固有名詞といった、検索が綴りに最も敏感な場所で文字単位のエラーを足してきます。

2.2 レイアウト認識パース — 信号を戻す

これへの応答が、文書をグリフ列ではなく2次元の対象として扱うツール群です。ページを画像にレンダリングし、レイアウト検出モデルが領域(段落、表、図、ヘッダ)に分け、レイアウトのヒューリスティクスで読み順を再構成し、表は行列構造を HTML、Markdown、JSON として復元する専用モデルを通す。出力はもはや平らな文字列ではなく、階層を保ち、図とキャプションを紐づけ、下流のチャンカーが分割の手がかりにできるメタデータを露出した構造化表現です。

代償は計算量で、素朴な抽出のミリ秒に対して、ページあたり数秒〜十数秒というオーダーになります。100万ページのコーパスでは効いてきます。失敗モードも変わります — 素朴な抽出器は少なくともテキストを出します。レイアウト認識パーサーは領域を誤認すると、構造化された自信のある出力で間違える — 図を表と誤認したり、ヘッダを本文と検出したり。スケールの前に、代表的に複雑なページをチームでスポットチェックしておくのが安全です。

2.3 現在のツール風景

この領域は、知っておきたい6つほどのツールに収斂してきました。LlamaParse は LlamaIndex のホスト型パーサーで、表とフォームに強く、すでに LlamaIndex 圏にいてマネージドが許される環境ならよい既定値です。Docling は IBM のオープンソースのレイアウト認識パーサーで、複雑な表構造を TableFormer モデルで扱い、データを外に出せないオンプレミス用途の自然な選択肢です。Unstructured は幅で勝負します — 多くの入力形式、型付き要素のパーティショニングモデル、一貫した下流インターフェース — 異種混在のエンタープライズコーパスに対する最初の選択として安全です。Marker-PDF は一点突破型で、PDF から見出し・箇条書き・コードブロックに気を配ったきれいな Markdown を出します。Firecrawl はウェブ側の入力問題を扱います — URL を入れると、定型部を剥がしたきれいな Markdown が出る。DeepSeek-OCR は2025年末に出た最新で、ページを少数のビジョントークンに符号化することでメモリと計算を大きく落とし、スループットが予算を支配する場面で本気の候補になります。

実務的な評価は、こんな形になります。コーパスの難度の範囲をまたぐ代表的な文書を50本選び、各ツールに通し、自分のコーパスにとって重要な軸 — 表の忠実度、多段組の読み順、スキャンの OCR 精度、図の扱い、スループット — で目視で比較する。勝者は、すべての軸で最良であることは稀です。自分のコーパスにとってもっとも重要な軸で最良であり、予算が吸収できるコストにおさまっている。それが勝者です。

2.4 マルチモーダルという別の道

並行する別の系統は、この枠組み自体を拒否します。視覚言語モデルがページを十分読めるなら、わざわざテキストに変換する必要はあるのか。ColPali や ColQwen2 のような遅延相互作用のマルチモーダル検索器は、ColBERT のアイデアを画像に拡張します — ページのパッチごとに埋め込みを作り、クエリトークンに対して最大類似度の集約でスコアリングする。テキスト変換では崩れていたであろう箇所 — 表、図、レイアウト自体 — に関連情報が宿っているとき、テキストだけでは引かなかったページが浮上します。あとは視覚言語モデルがページを直接読みます。

代償は相当で、具体に当たる価値があります。標準的なテキストチャンクの埋め込みは ~1,024 次元1個 — 数キロバイト。ColPali でエンコードされたページは ~128 次元 × およそ千パッチ — ページあたり半メガバイト。100万ページのインデックスサイズはギガバイトから数百ギガバイトへ、スコアリングは高くつき、生成には視覚言語モデルが要ります。表と図が密に詰まったコーパスでは、アップグレードに見合うだけのものがあります。文章中心で予算がきついコーパスでは、丁寧にパースしたテキスト検索のほうがコスト面で現実的です。ハイブリッド構成 — 検索は ColPali、生成はテキスト変換、あるいはその逆 — がおそらく今後1年のマルチモーダル RAG の本番形になるでしょう。

第2章を踏まえて

きれいでレイアウト認識のあるパースは、高品質な RAG にとって必要で、それだけでは十分ではありません。パースされた文書は、まだ文書のままです — 埋め込めるくらい小さく、意味を保つくらい大きい単位に分割される必要があります。パーサーの構造ヒントを無視するチャンカーは、パーサーが守ろうとしたものを捨てます。この2層は一緒に設計するべきで、第3章ではチャンキングのスペクトラムと、フロンティアでそれを書き換えた手法群を歩きます。

次回 — 第3章: アドバンスト・チャンキングのフレームワーク。 固定長から構造認識まで、チャンキングのスペクトラム、オーバーラップの神話、コンテキストの崖、そしてコンテクスチュアル・リトリーバルとレイトチャンキング。