【ITニュース解説】How to build a unified ingestion layer for your RAG pipeline from scratch

RAGパイプラインとは、AI（人工知能）モデルが、与えられた質問に対して、事前に用意された大量のデータの中から関連性の高い情報を探し出し、それに基づいてより正確で適切な回答を生成するための仕組みである。このパイプラインの重要な初期段階に「コンテンツの取り込み（インジェスチョン）」がある。これは、ウェブサイトのURL、PDFファイル、Word文書（DOCX）など、さまざまな形式で存在する情報を、AIモデルが理解し、利用できる形に変換する工程だ。

しかし、多くのRAGパイプラインが失敗する原因は、実はこのコンテンツ取り込みの段階にあることが多い。人々はよく、データを探し出す「検索」の仕組みや、データを保存する「ベクトルストア」に問題があると考えるが、実際には、モデルに渡される前のデータの質が悪いために、全体がうまく機能しないケースが非常に多いのだ。例えるなら、ゴミのような情報を取り込んでしまっているのに、その情報から作られた「埋め込み（エンベディング）」、つまりAIがデータを数値化したものが、ただのゴミの埋め込みになってしまう。その結果、いくら検索のロジックを磨いても、結局は質の悪い情報しか見つけられないことになる。問題の根源は、データがシステムに最初に取り込まれる時点にある。

ウェブページからコンテンツを取り込む場合、初期には「requests」ライブラリでページを取得し、「BeautifulSoup」でHTMLを解析する方法が一般的だ。しかし、現代のウェブサイトの多くは「React」や「Next.js」といった技術で作られており、ページが読み込まれた後にJavaScriptを使ってコンテンツが動的に追加される。このような場合、通常のツールではコンテンツを取得できない。そこで、「Playwright」や「Puppeteer」のような、実際にウェブブラウザを動かすツールが必要になる。これらを使うと、ブラウザの起動や停止、ページの読み込み完了の判断、タイムアウト処理といった複雑な管理作業が発生する。さらに、自動化されたブラウザ（「ヘッドレスブラウザ」）を検知して異なるコンテンツを表示するサイトへの対策も必要になる。また、ウェブページから本当に必要な本文だけを抽出し、ナビゲーションメニュー、クッキーバナー、フッターなどの余分な部分（「構造的な飾り」）を削除するためのロジックも開発しなければならない。この抽出ロジックは、テキストの密度や要素の位置、テキストとリンクの比率などを基にした推測的なものであり、全てのサイトに完璧に適用できるわけではない。

PDFファイルの場合も同様に複雑だ。「pdfplumber」のようなライブラリが多くのケースに対応できるが、例えば学術論文のような2段組のレイアウトだと、左右の列を同時に読み取ってしまい、意味の通らない文章になってしまうことがある。また、スキャンされたPDFでテキスト情報が含まれていない場合は、「OCR（光学文字認識）」という追加の工程で画像から文字を認識させる必要がある。さらに、PDF内のテーブル（表）が、単なる配置されたテキストとして扱われてしまい、行や列の関連性が失われることもある。「PyMuPDF」のような高速なライブラリもあるが、それぞれに特有のレイアウト処理の課題があるため、両方を使い分ける必要が出てくるかもしれない。

Word文書（DOCX）も例外ではない。「python-docx」を使えば、文書のXML構造にアクセスできるが、そのままではきれいなテキストにはならない。段落やテーブルのセルを個別に処理する必要があり、変更履歴、改訂履歴、埋め込み画像、コメントなど、XMLには存在するがコンテンツとしては不要な要素を取り除く作業が必要になる。文書のオブジェクトモデルから、人間が読めるようなテキスト形式に変換するための、独自の「シリアライザー（直列化ツール）」を開発することも求められる。

これらの異なるライブラリは、それぞれ異なる形式で結果を出力する。そのため、AIモデルにデータを渡す前に、これら全ての出力を統一された形式に変換する「正規化コード」を記述しなければならない。さらに、エラー処理、再試行ロジック、タイムアウト管理、ログ記録といった機能も追加する必要がある。そして、これら全てを実装しても、まだ見ぬ「エッジケース（特殊な状況）」が次々と現れるのが現実だ。これは、数週間から数ヶ月に及ぶ大規模な開発作業であり、ウェブサイトの変更やライブラリのアップデートがあるたびに、継続的なメンテナンスが必要となる。

では、「統一された取り込み層」とは具体的に何を意味するのか。これは、単一のライブラリを使うことではない。重要なのは、入力がウェブページであれ、PDFであれ、Word文書であれ、最終的に一貫した「出力スキーマ」、つまり統一された形式と構造でデータを出力することだ。AIモデルが扱いやすいきれいな出力形式とは、具体的には「Markdown（マークダウン）」のような構造化されたテキスト形式が理想的だ。見出しは適切なマークダウン記法（例えば「## 見出し」）で表現され、テーブルはGitHub Flavored Markdown（GFM）形式で、コードブロックにはプログラミング言語の種類が明記される。そして何よりも、出力されるのは純粋なコンテンツであり、元の形式が持っていたナビゲーションやフッターなどの「構造的な飾り」が一切含まれないことが重要である。

この「一貫性」が鍵となる。例えば、ウェブページから抽出した見出しが「## インストール」というマークダウン形式で出力されるのに、PDFからは「インストール」というただのテキストとして出力された場合、その後の「チャンキング（文章を意味のある塊に分割する処理）」の戦略に問題が生じる。もしチャンキングがマークダウンの見出しを区切りとして設計されていると、PDFからの入力はサイレントに（静かに）チャンキングの境界を壊してしまうことになる。そうなると、期待通りのデータの塊がAIモデルに渡らず、結果として検索品質が低下する。統一された取り込み層があれば、その後のチャンキングロジック、データをAIが理解できる数値表現に変換する「埋め込みパイプライン」、そして最終的な「検索層」といった全てのプロセスが、ただ一つの統一されたフォーマットに対して機能するようになる。元の入力がどの形式であったかという情報は、取り込み層の内部的な実装の詳細となり、パイプラインの他の部分で条件分岐を考える必要がなくなるのだ。

このような統一された取り込み層を自分たちで構築する場合、各形式に対して具体的に何が必要になるかを見ていこう。ウェブサイトの抽出には、リダイレクト処理やタイムアウト管理を含む「フェッチ層」、JavaScriptを多用するページのためにヘッドレスブラウザでレンダリングする「レンダリング層」、そしてメインコンテンツを特定し余計な要素を取り除く「コンテンツ抽出層」、そして最終的に一貫したマークダウンを生成する「変換層」が必要だ。特にコンテンツ抽出は推測的な処理が多く、全てのサイトに完全に適用できるわけではない。PDFの抽出には、テキスト情報を持つPDFのための「テキスト抽出層」、スキャンされた文書のための「OCR層」、テーブルの検出と再構築ロジック、2段組などの多段レイアウトの処理、そして見た目の大きさから見出しを推測する「見出し推論」の仕組みが必要だ。PDFはWord文書のように明確な「見出し」の構造情報を持っていないため、フォントの大きさなどから推測するしかない。DOCXの抽出には、段落の順序通りに抽出する処理、テーブルのセルを正しく行と列の関連性を保って抽出する処理、スタイル名から見出しレベルを推測する処理、そして変更履歴、コメント、埋め込みオブジェクトの参照などをフィルタリングする処理が必要だ。

これらの異なる形式全てにおいて、共通のスキーマへの「形式正規化」、失敗を明示的に伝えるエラー処理（空の文字列を返すのではなく）、そして入力元に関わらず同じ見出し構文、テーブル形式、コードブロック規則を持つ一貫したマークダウン出力が必要となる。これら全ての要素を実装することは不可能ではないが、維持管理しなければならない領域（「サーフェスエリア」）は非常に広く、ウェブサイトのマークアップ変更やライブラリの破壊的変更があるたびに、その負担は増大する。

そこで、外部のAPIサービスを利用するという選択肢が考えられる。例えば、記事で触れられているEnConvertのようなサービスでは、URL、PDF、DOCXといった入力形式ごとに、それぞれ一つの「POSTリクエスト」を送るだけでよい。そして、どの入力形式に対しても、APIからの応答（レスポンス）は全く同じ形式の統一されたスキーマで提供される。つまり、あなたのシステムでは、入力タイプによって処理を分岐させる必要がなくなるのだ。チャンキングロジック、埋め込み処理、検索層といったダウンストリームのコードを一度書けば、全ての入力に対応できるようになる。エラー処理も一貫しており、問題が発生した際に返されるエラーの形式も統一されているため、非常に管理がしやすい。

APIを利用する際のトレードオフとして、解析の内部的な処理に対する制御権を失うこと、そして特定のソースタイプに合わせて抽出を細かく調整する能力がなくなることが挙げられる。これらは確かにコストとなりうる。しかし、ほとんどのチームにとって、これら3つの異なる形式のパーサー（解析器）とそれに伴う無数のエッジケースを自社で所有し、維持管理するコストと比較すれば、API利用のメリットの方がはるかに大きい場合が多い。

最後に、いつ自社で構築すべきで、なぜそうするのか、あるいはAPIを利用すべきなのか、その判断基準を明確にしておこう。もしコンテンツの取り込み品質が、あなたの製品にとっての「核となる差別化要因」であるならば、つまり、抽出品質そのものが顧客に提供する価値であるような「文書インテリジェンス」製品を開発している場合、自社で構築すべきだ。このようなケースでは、エッジケースへの対応能力こそが製品の価値そのものであり、その制御権は手放すべきではない。しかし、コンテンツ取り込みが製品の「基盤（インフラストラクチャ）」に過ぎない場合は、計算が異なる。独自のPDFテーブル抽出器を開発したところで、それが競争上の優位性をもたらすわけではない。それは、あなたが作ろうとしている製品の特有の問題ではない部分に、貴重なエンジニアリング時間を費やしていることになるからだ。この判断のテストは簡単だ。顧客は、あなたがWord文書の抽出をどのように処理しているかという理由で、競合他社ではなくあなたの製品を選ぶだろうか。もし「はい」であれば、自社で構築するべきだ。しかし、もし顧客が「ちゃんと動くのであれば、やり方には関心がないし、気にしないだろう」というのであれば、それはインフラストラクチャの一部である。そのように扱い、外部サービスを利用するなどして効率化を図るべきである。特に初期段階のチームは、この点について正直になる必要がある。堅牢な取り込み層を構築するために費やした数週間は、製品の真の差別化部分の開発に費やせなかった数週間となる。リソースは有限であり、最も価値を生み出す部分に集中すべきだ。