エンドツーエンドのRAGワークフロー：検索拡張生成の仕組み

検索拡張生成（RAG）は、推論時に大規模言語モデル（LLM）を外部の知識ソースに接続するAIアーキテクチャパターンであり、静的な学習データにとどまらない、正確で文脈に応じた回答の生成を可能にします。事前学習中にエンコードされた知識に依存するのではなく、RAGシステムはユーザーのクエリごとに外部データベースから関連文書を検索し、生成前にそのコンテンツをLLMのプロンプトに挿入します。その結果、基盤となる知識が変更されるたびにモデル全体を再学習させることなく、検証済みのソースに基づいた、正確でドメイン固有の回答を生成するジェネレーティブAIシステムが実現します。

LLMは、知識のカットオフ（学習データの期限）により古い回答を提供することが多く、独自の社内文書やリアルタイムの外部データソースにアクセスできません。RAGはこの制限に直接対処します。60%以上の組織がAIを活用した検索ツールを積極的に開発しており、これはモデルのメモリだけに依存するアプローチから、社内文書、製品ドキュメント、最新データを含むライブ知識ベースにAIを動的に接続するアプローチへの根本的な移行を反映しています。

このガイドでは、アーキテクチャのコンポーネントやデータのインジェストから、ハイブリッド検索、プロンプト設計、評価、デプロイにいたるまで、RAGのワークフロー全体を解説し、本番環境のRAGパイプラインを構築するチーム向けの実践的なガイダンスを提供します。

RAGアーキテクチャの主要コンポーネント

RAGシステムは主に4つのコンポーネントで構成されています。外部の知識を格納する知識ベース、各クエリに対して関連する文書を見つける情報検索コンポーネント（リトリーバー）、検索された文脈をLLMプロンプトに組み立てる統合レイヤー、そして最終的な回答を生成するジェネレーター（LLM）です。各コンポーネントは独立して最適化できます。パイプライン全体の品質は最も弱いリンクによって制限されます。高品質なLLMであっても、無関係な文書ばかりを提示するリトリーバーを補うことはできません。

リトリーバーとベクトルデータベース

リトリーバーはユーザーのクエリを受け取り、比較可能な表現に変換して、知識ベースから最も関連性の高い文書を返します。リトリーバーの品質は、RAGの出力品質を決定する最大の要因です。ベクトルデータベースは、エンベディングと呼ばれる文書チャックの数値表現を保存し、大規模で高速な類似性検索を可能にします。完全一致でマッチングを行うリレーショナルデータベースとは異なり、ベクトルデータベースは、コサイン類似度などの距離指標を使用して、意味的にクエリに最も近い文書を見つけます。

ジェネレーターとオーケストレーションレイヤー

ジェネレーターは、拡張されたプロンプト（ユーザーの元の質問と検索された文脈を組み合わせたもの）を受け取り、最終的な回答を生成するLLMです。オーケストレーションレイヤーは、すべてのコンポーネントを一貫したRAGパイプラインに接続し、プロンプトの組み立て、会話履歴、エラー処理を管理します。LangChainやLlamaIndexなどのフレームワークは一般的なオーケストレーションプリミティブを提供し、Databricksなどのプラットフォームはフルスタックのマネージドインフラストラクチャを提供します。

データソースと外部知識

RAGシステムで利用可能なデータソースの範囲は広く、リレーショナルテーブル内の構造化データ、PDFやMarkdownファイル内の非構造化テキスト、エンジニアリングのランブックやHRポリシーなどの社内文書、製品ドキュメント、外部の知識ベースなどがあります。ドメイン固有のデータ（ユーザーが尋ねる質問に直接関連するコンテンツ）は、最初にインジェストし、最も慎重に維持管理する必要があります。独自の研究や社内文書を含む内部データは、公開されているLLMが学習していない知識を表しているため、RAGの実装において最も強力な競争優位性を生み出します。

データソースを選択する際の現実的な課題は「関連性の密度」です。インデックス化された文書のうち、実際のクエリに対して実際に検索される割合はどのくらいでしょうか。関連性の高いソースは、エンベディングやインデックス作成にかかる計算コストや金銭的コストに見合いますが、関連性の低いソースは、リトリーバーがフィルタリングしなければならないノイズを増やし、検索品質を低下させます。

インジェストパイプラインが各ソースを一貫したテキスト形式に正規化する限り、単一のRAGシステムで複数のデータソースを組み合わせることができます（例：製品ドキュメントのコーパスとリアルタイムの顧客データベースの組み合わせなど）。チームは、検索された文書の出所を信頼できるソースまで遡って追跡できるように、インデックス化されたすべてのソースのデータリネージを記録しておく必要があります。これにより、規制の厳しい業界における監査やコンプライアンスのワークフローが可能になります。

エンベディングモデルとベクトルストア

エンベディングモデルの選択

エンベディングモデルとは、テキストを数値表現（意味的な意味をエンコードした高次元ベクトル）に変換する、特化型の言語モデルです。ユーザーがクエリを送信すると、同じエンベディングモデルがそのユーザー入力を比較可能なベクトルに変換し、クエリと保存されているすべての文書エンベディングとの数学的な比較を可能にします。インジェスト時に使用するエンベディングモデルは、クエリ時に使用するものと同一である必要があります。

モデルの選択には、表現の品質、ベクトルの次元数、推論のレイテンシ、および金銭的コストの間のトレードオフが伴います。bge-large-enのような汎用モデルは、さまざまなドメインで機能する1,024次元のベクトルを生成します。技術的なテキストで微調整（ファインチューニング）されたドメイン固有のエンベディングモデルは、特定の検索タスクにおいて汎用モデルを上回ることがよくあります。エンベディングモデルは、生のテキストを、ベクトル類似性検索を可能にする数値表現に変換します。

エンベディングモデルは、検索対象の文書とは異なる表現で書かれたクエリを処理する能力（クロスリンガル堅牢性や言い換え堅牢性と呼ばれる特性）についても評価できます。ユーザーが会話調で質問する一方で、ドキュメントがフォーマルに書かれているようなエンタープライズ環境では、この意味的な橋渡しが極めて重要になります。本番環境でのインデックス作成を実行する前に、実際のユーザークエリの代表的なサンプルに対してエンベディングモデルをテストすることで、後からコーパス全体を再エンベディングするというコストのかかる事態を防ぐことができます。

チャンク分割戦略とインデックス作成

エンベディングモデルのコンテキストウィンドウには制限があり、またチャンクが小さいほど高精度な検索が可能になるため、大きな文書はエンベディングの前に小さなチャンクに分割する必要があります。チャンクのサイズは出力の品質に直接影響します。チャンクが小さすぎると周囲の文脈が失われ、大きすぎるとユーザーの質問に最も関連する特定の箇所が薄まってしまいます。一般的な戦略としては、トークン数による固定サイズ分割や、重要な文脈が境界で途切れるリスクを軽減するために重複部分を設けた文境界分割などがあります。

エンベディングされたベクトルは、ベクトルストアに保存され、インデックスが作成されます。HNSWなどのアルゴリズムを使用したベクトルインデックスは、大規模な近似最近傍探索を可能にするようにエンベディングを整理し、すべてのエンベディングの線形スキャンからミリ秒未満のルックアップへと検索時間を短縮します。

情報検索とハイブリッド検索

多くのRAGシステムの基盤であるセマンティック検索は、言い換えや類義語を自然に処理し、ユーザーのクエリに意味が最も近い文書を見つけます。Databricks AI Searchは、Deltaテーブルからの自動同期を備えたセマンティックベクトル検索を実装しているため、手動で再インデックスすることなく、知識ベースに新しいデータを反映できます。

純粋なセマンティック検索には、特定のエラーコード、バージョン番号、固有名詞などの完全一致クエリに対して弱いという既知の弱点があります。ハイブリッド検索は、セマンティックベクトル検索と、完全一致や希少な用語のマッチングに優れた確率的単語頻度モデルであるBM25キーワード検索を組み合わせることで、この問題に対処します。両方の検索パスを並行して実行し、相互順位融合（RRF）を使用して結果をマージすることで、より幅広いクエリ分布にわたって検索効率が向上します。

リランキング（再ランク付け）ステップでは、クロスエンコーダーモデルを適用して、クエリに対する検索された各文書のスコアを算出し、最も関連性の高い文書が最上位に表示されるように結果を並べ替えることで、結果をさらに改善できます。リランキングのような検索手法は精度を大幅に向上させ、LLMのコンテキストウィンドウによってジェネレーターに渡せる文書数が制限されている場合に特に価値があります。

類似度のしきい値は、最終的な品質ゲートを追加します。関連性スコアが最小カットオフ値を下回る文書は、低品質な文脈としてジェネレーターに渡すのではなく、完全に除外する必要があります。無関係な文脈を渡すことは、文脈を渡さないことよりも悪影響を及ぼします。コンテキストウィンドウを消費し、LLMが生成された回答の中で正しい情報と誤った情報を混同するリスクを高めるためです。保守的なしきい値を設定し、フィルター率を継続的に監視することは、アーキテクチャを変更することなく検索品質を維持するための簡単な方法です。

RAGの仕組み：インジェストから生成まで

RAGのワークフローは、ユーザーの質問を根拠のある正確な回答に変換する5つの連続したステージで構成されています。

ステージ1：外部データのインジェストと正規化

RAGパイプラインはデータのインジェストから始まります。生の文書がETLパイプラインに読み込まれ、テキストのクレンジングと正規化（定型文の削除、空白の標準化、表やコードからの構造化コンテンツの抽出など）が行われます。データレイクハウスアーキテクチャは、統一されたガバナンスのもとで構造化コンテンツと非構造化コンテンツの両方のインジェストを一元化するため、RAG知識ベースの自然な基盤となります。

ステージ2：チャンク分割、エンベディング、インデックス作成

クレンジングされたドキュメントはチャンクに分割され、各チャンクは埋め込みモデルを通過してベクトルを生成します。生成された埋め込みは、元のテキストやメタデータ（ドキュメントのタイトル、日付、ソースURL）とともにベクトルストアに書き込まれます。メタデータを使用することで、特定の日付範囲内に公開されたドキュメントや、特定のユーザーロールがアクセスできるドキュメントのみに結果を制限する、フィルタリングされた検索が可能になります。RAGでデータの関連性を維持するには、継続的な更新が必要です。本番システムでは、更新されたソースドキュメントを検出し、スケジュールまたはイベント駆動型で再埋め込みを実行する自動化パイプラインが必要になります。

ステージ 3：関連ドキュメントの検索

ユーザーがクエリを送信すると、RAGシステムは同じ埋め込みモデルを適用してユーザー入力をベクトル表現に変換し、ベクトルストアにクエリを実行します。これにより類似度検索が実行され、最も関連性の高い上位k個のドキュメントチャンクが返されます。k値（検索するチャンク数）は、検索の網羅性とコンテキストウィンドウの消費量とのトレードオフの関係にあり、対象のLLMに合わせて調整する必要があります。

ステージ 4：LLMプロンプトの拡張

検索されたドキュメントは、拡張プロンプトに組み込まれます。一般的な構造では、まずシステム指示（「提供されたコンテキストのみに基づいてユーザーの質問に答えてください。コンテキスト内に答えが見つからない場合は、その旨を伝えてください。」など）を配置し、次に検索されたテキストチャンク、最後にユーザーの元の質問を配置します。最も関連性の高いドキュメントを最初に配置すると、特に、最初と最後の近くのコンテキストが中央のコンテンツよりも注目されやすい「lost in the middle（埋もれる中央）」現象が発生しやすいモデルにおいて、フォーカスが向上する傾向があります。

ステージ 5：最終回答の生成

生成器（ジェネレーター）は拡張プロンプトを受け取り、最終的な回答を生成します。後処理では、情報元の引用を追加したり、トピックから外れた出力をフィルタリングしたり、結果を一貫した形式に構造化したりできます。LLMは、事前学習による静的なトレーニングデータのみに依存するのではなく、検索されたコンテキストにアクセスできるため、正確な回答を生成できます。

会話履歴の管理は、複数ターンのRAGアプリケーションにおける生成レイヤーの重要な課題です。RAGシステムがセッション内の以前のやり取りを記憶する必要がある場合（ユーザーが以前の回答を参照するフォローアップの質問をできるようにするため）、会話履歴を拡張プロンプトに組み込む必要があります。これにより、実質的なプロンプトの長さが増加し、新しく検索されたドキュメントに使用できるコンテキストウィンドウが減少します。開発チームは、履歴、検索されたコンテキスト、および現在のユーザークエリの間でトークンを割り当てる、明示的なコンテキストバジェット管理を実装する必要があります。

生成AI、LLMプロンプトデザイン、およびオーケストレーション

再利用可能なLLMプロンプトテンプレートは、静的な指示（システムの役割、動作の制約、出力形式）と、実行時に挿入される動的なコンテンツ（検索されたコンテキストとユーザーのクエリ）を分離します。「提供されたコンテキストからのみ」回答するという指示は、RAGシステムにおいて特に重要です。これがないと、生成AIモデルは検索されたコンテンツを記憶しているトレーニングデータで補完してしまい、検証済みの情報と、誤っている可能性のあるモデルの知識が混ざり合った回答を生成してしまいます。

引用の挿入（生成された各回答にソースドキュメントのメタデータを追加すること）により、人間のレビュー担当者は、回答が実際に検索されたデータに基づいていることを検証できます。企業での導入において、正確な回答を得るためには、引用のサポートや、トピックの範囲、回答の長さ、エスカレーション動作を制限するシステム指示が本番環境の要件となります。

ファインチューニング、ドメイン知識、および代替案

ファインチューニングは、厳選されたデータセットでモデルの重みを変更することにより、事前学習済みモデルを特定のドメインに適応させます。RAGとは異なり、ファインチューニングは推論時にコンテキストを注入するのではなく、モデル自体の動作（語彙、トーン、暗黙のドメイン知識など）を変更します。ファインチューニングは、ベースモデルがドメイン固有の用語を常に誤解する場合や、必要な回答スタイルをプロンプトエンジニアリングだけでは実現できない場合に適しています。

最新の情報へのアクセスが目的である場合、ファインチューニングはRAGの有効な代替手段にはなりません。新しいデータでLLMをファインチューニングすると、多大な計算コストと金銭的コストが発生し、絶えず変化するナレッジベースに追従できません。ほとんどの本番システムでは、ファインチューニングされたモデルがドメインのトーンや用語を処理し、RAGワークフローがナレッジへのアクセスを提供するというように、両方を組み合わせています。ナレッジへのアクセスをファインチューニングだけに頼ることは、よくあるコストのかかる間違いです。

プロンプトエンジニアリング（モデルの動作をガイドするためのシステム指示やFew-shot例の設計）は、あらゆるLLMカスタマイズの基本的な出発点です。追加のインフラストラクチャを必要とせず、すぐに結果を得ることができます。RAGシステムにおいて、プロンプトエンジニアリングは、検索されたコンテキストをモデルにどのように提示するか、また、検索されたドキュメントがユーザーの質問に十分に答えていない場合にモデルが不確実性をどのように示すかを制御します。拡張プロンプトの組み立て自体がプロンプトデザインの一種であるため、定義上、すべてのRAGシステムにプロンプトエンジニアリングが組み込まれています。

RAGの評価と検索テスト

検索品質の測定

RAGの評価では、情報検索コンポーネントと生成コンポーネントを個別に評価する必要があります。検索の評価にはprecision@kを使用します。これは、特定のクエリに対して検索されたk個のドキュメントのうち、実際にどれだけの割合が関連しているかを示す指標です。グラウンドトゥルース（正解データ）評価データセット（クエリと、既知の正しいドキュメントおよび回答のペア）が不可欠な前提条件となります。このデータセットの構築には手間がかかりますが、不可欠です。これがないと、開発チームは真のRAG評価の改善とランダムな変動を区別できません。

生成の忠実性の測定

生成の評価では、モデルの回答が検索されたコンテキストに忠実であるかどうか、つまり、生成された回答に、検索されたソースからではなく、モデルのトレーニングデータから引き出された誤った情報や捏造された情報が含まれていないかどうかを測定します。別のLLMが各回答の忠実性をスコアリングする「LLM-as-a-judge（評価者としてのLLM）」評価により、大規模なテストセット全体でスケーラブルなカバレッジが提供されます。MLflowを使用したLLM評価は、検索と生成のメトリクスを統合された実験追跡フレームワークに統合します。RAGは生成AIモデルにおけるハルシネーションを減少させますが、生成された回答におけるすべてのAIハルシネーションを排除することはできません。

監視、ガバナンス、およびセキュリティ

RAGシステムは、そのデータソースのガバナンス要件を継承します。ユーザーは、アクセスを許可されているドキュメントのみを検索できるようにする必要があります。Unity Catalogは、RAGナレッジベース（ベクトルインデックス、Deltaテーブル、モデルエンドポイントなど）全体にわたって、完全なデータリネージ追跡を備えた共通のアクセス制御モデルの下で管理されるきめ細かなガバナンスを提供します。プロベナンス（来歴）タグ付け（生成された各回答を、それを生成した特定のドキュメントチャンクに関連付けること）により、人間のレビュー担当者は引用されたソースを検証し、AIが生成したコンテンツを監査できます。規制の厳しい業界では、プロベナンスがコンプライアンス要件となることがよくあります。

監視では、ナレッジベースの鮮度（ソースドキュメントが最後に更新された日時と、RAGインデックスが最後に更新された日時のギャップ）も追跡する必要があります。古いドキュメントを常に返すナレッジベースは、運用上、トレーニングデータのカットオフが古いLLMと同等です。どちらも、ある時点では正確であったものの、もはや最新の情報を反映していない回答を生成します。ソースドキュメントが定義されたSLA内に再インデックスされていない場合にトリガーされる自動鮮度アラートにより、時間の経過とともに回答の正確性が密かに低下するのを防ぐことができます。

ベクトルストアは保存時に暗号化され、埋め込みおよびLLM推論エンドポイントは安全なネットワーク境界内にデプロイされる必要があります。また、異常なアクセスを検出するために、監査ログですべてのクエリと検索イベントを記録する必要があります。

検索レイヤーでのロールベースのアクセス制御は、異なるユーザーやチームが許可されたデータドメインからのみドキュメントを検索する必要がある、マルチテナントのRAGデプロイメントにおいて特に重要です。検索レイヤーのアクセス制御がないと、ユーザーのクエリによって無関係なビジネスユニットの機密ドキュメントが表面化する可能性があります。これは、生成された回答には表示されませんが、基礎となる検索ログには存在するデータガバナンスの失敗です。RAGアーキテクチャの設計当初からアクセス制御を組み込んでおくことは、データがインデックスされた後に後付けするよりもはるかに簡単です。

運用のスケーリングとデプロイのベストプラクティス

大規模なナレッジベースの最初の取り込みには、大規模なバッチ埋め込みが必要です。初回ロードの後は、増分取り込みによって新規または更新されたドキュメントのみが再埋め込みされます。システムは、初回ロード時には埋め込みコンピューティングを自動スケーリングし、継続的な増分更新時にはスケールダウンする必要があります。バッチ埋め込みは、リアルタイム埋め込みよりもドキュメントあたりのコストが大幅に安くなります。本番システムでは、取り込みワークロードにバッチ処理を使用し、リアルタイム埋め込みはユーザーのクエリ処理用に予約しておく必要があります。

通常、LLMの推論がRAGの運用コストの大部分を占めます。検索されたドキュメントをより多くLLMに渡すと、クエリあたりの推論コストが比例して増加します。開発チームは、コストを制限するために、検索される最大ドキュメント数とプロンプトの長さに関する明示的なポリシーを設定する必要があります。埋め込み推論、ベクトルストア、オーケストレーションサービス、LLMエンドポイントなどの各コンポーネントは、再試行ロジックやフェイルオーバー用のサーキットブレーカーパターンを備えた再現可能なデプロイのためにコンテナ化される必要があります。

Databricks MLflowは、RAGスタック全体と統合された実験追跡、モデルレジストリ、評価ツールを提供し、開発チームが埋め込みモデルのバージョン管理、検索実験の追跡、本番RAGパイプラインのライフサイクル管理を行えるようにします。

よくある質問

RAGワークフローはLLMのファインチューニングとどのように異なりますか？

RAGワークフローは、推論時に関連するドキュメントを検索してLLMプロンプトに注入します。一方、ファインチューニングは、デプロイ前に新しいデータでトレーニングを行うことでモデルの重みを変更します。RAGはモデルを再トレーニングすることなく、最新の情報への動的なアクセスを提供するため、頻繁に変更される知識に対してより費用対効果が高くなります。ファインチューニングは、回答スタイル、ドメイン用語、または特定のタスクへの適応に適しています。多くの本番システムでは、ドメインのトーンに合わせたファインチューニング済みモデルと、知識アクセスのためのRAGワークフローを組み合わせて両方を活用しています。

RAGシステムで最も一般的な失敗モードは何ですか？

検索品質の低さは、RAGで最も一般的な失敗モードです。情報検索コンポーネントが無関係なドキュメントを返すと、LLMは自信ありげに見えても正確な情報に基づかない回答を生成します。これは、明らかなハルシネーションよりも検出が困難な失敗です。検索の失敗は、不適切なチャンク分割、埋め込みモデルのセマンティック空間とクエリ分布の不一致、ハイブリッド検索のカバー範囲不足、あるいは単にユーザーが求めている情報がナレッジベースに欠けていることなどに起因します。この種の失敗を診断するには、生成の忠実性（faithfulness）とは別に、検索精度（precision）を個別に評価することが不可欠です。

RAGはどのようにしてAIのハルシネーションを軽減しますか？

RAGは、LLMに記憶から回答させるのではなく、各クエリに対して検証済みの具体的なコンテキストを提供することで、生成AIモデルにおけるハルシネーションを軽減します。プロンプトで「検索されたコンテキストのみに基づいて回答する」よう明示的に指示すると、モデルが情報を捏造する余地が少なくなります。ハルシネーションの軽減は検索品質に比例します。検索されたドキュメントの関連性と網羅性が高いほど、モデルが推測に頼る必要は少なくなります。モデルが検索されたコンテキストを誤って解釈することがあるため、RAGでAIのハルシネーションを完全に排除することはできませんが、検索を行わずに生成する場合と比較して、その発生頻度を大幅に抑えることができます。

RAGにはどのような外部データソースが最適ですか？

製品ドキュメント、技術ナレッジベース、社内規定ドキュメント、整理された社内リポジトリなど、情報の密度が高く、ドメインに特化したソースが最も優れた検索結果をもたらします。フォーマットが一貫しており、段落の区切りが明確なソースは、構造が緩いコンテンツよりも、チャンク分割や埋め込みをより確実に行うことができます。サードパーティプロバイダーが提供する外部の知識ソース（規制当局への提出書類、業界標準、学術文献など）を利用することで、自社固有のコンテンツを超えてカバー範囲を広げることができます。RAGシステムは外部データソースの品質に依存するため、ソースドキュメントが不正確であったりフォーマットが一貫していなかったりすると、検索アーキテクチャの品質に関わらず、不正確な回答が生成される原因になります。

RAGアーキテクチャの主要なコンポーネントは何ですか？

RAGアーキテクチャは、主に4つのコンポーネントで構成されています。ナレッジベース（インデックス化された外部データストア）、リトリーバー（関連するドキュメントを検出する情報検索コンポーネント）、統合レイヤー（コンテキストをLLMプロンプトに組み立てるオーケストレーションロジック）、そしてジェネレーター（最終的な回答を生成する大規模言語モデル）です。ベクトルデータベースはナレッジベースの重要なインフラ要素であり、ドキュメントチャンクの数値表現を保存し、高速なセマンティック類似性検索を可能にします。RAGアーキテクチャパターンの詳細については、Databricksの用語集ページの検索拡張生成（RAG）をご覧ください。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事