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

検索拡張生成（RAG）は、推論時に大規模言語モデルを外部知識ソースに接続するAIアーキテクチャパターンであり、静的トレーニングデータを超えた正確でコンテキストを認識した応答を生成できるようにします。RAGシステムは、事前トレーニング中にエンコードされた知識に依存する代わりに、ユーザークエリごとに外部データベースから関連ドキュメントを取得し、そのコンテンツを生成前のLLMプロンプトに注入します。その結果、検証済みソースに基づいた正確でドメイン固有の回答を生成する生成AIシステムが実現し、基礎となる知識が変化するたびにモデル全体を再トレーニングする必要がなくなります。

LLMは知識のカットオフにより時代遅れの回答を提供することが多く、専有の内部ドキュメントやリアルタイムの外部データソースにアクセスできません。RAGはこの制限に直接対処します。60％以上の組織がAIを活用した検索ツールを積極的に開発しており、これはモデルメモリのみに依存するから、内部ドキュメント、製品ドキュメント、最新データを含むライブ知識ベースにAIを動的に接続するへの根本的なシフトを反映しています。

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

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

RAGシステムは、外部知識を保存する知識ベース、クエリごとに関連ドキュメントを見つける情報検索コンポーネント（レトリーバー）、取得したコンテキストをLLMプロンプトに組み立てる統合層、および最終応答を生成するジェネレーター（LLM）の4つの主要コンポーネントで構成されます。各コンポーネントは独立して最適化でき、パイプライン全体の品質は最も弱いリンクによって制限されます。高品質のLLMは、一貫して無関係なドキュメントを表面化するレトリーバーを補償できません。

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

レトリーバーはユーザークエリを受け取り、それを比較可能な表現に変換し、知識ベースから最も関連性の高いドキュメントを返します。レトリーバーの品質は、RAG出力品質の単一最大の決定要因です。ベクターデータベースは、ドキュメントチャンクの数値表現（埋め込み）を保存し、大規模な高速類似性検索を可能にします。正確な値でマッチングするリレーショナルデータベースとは異なり、ベクターデータベースはコサイン類似性などの距離メトリックを使用して、クエリにセマンティックに最も近いドキュメントを見つけます。

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

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

データソースと外部知識

RAGシステムで有効なデータソースの範囲は広いです：リレーショナルテーブルの構造化データ、PDFやMarkdownファイルの非構造化テキスト、エンジニアリングランブックやHRポリシーなどの内部ドキュメント、製品ドキュメント、外部知識ベース。ドメイン固有データ（ユーザーが尋ねる質問に直接関連するコンテンツ）を最初に取り込み、最も注意深く維持する必要があります。専有研究や内部ドキュメントを含む内部データは、RAG実装において最も防御可能な利点を生み出します。これは、その知識が公開LLMによってトレーニングされていないためです。

データソースを選択する際の実用的な問題は、関連性密度です。つまり、実際のクエリに応答してインデックス化されたドキュメントのうち、実際に取得される割合です。関連性の高いソースは、埋め込みとインデックスの計算コストと財務コストを正当化します。関連性の低いソースは、レトリーバーがフィルタリングしなければならないノイズを増加させることで、検索品質を低下させます。

複数のデータソースを1つのRAGシステムに組み合わせることができます。例えば、製品ドキュメントコーパスとリアルタイム顧客データベースを組み合わせる場合、インジェストパイプラインが各ソースを一貫したテキスト形式に正規化する限り可能です。チームは、インデックス化されたすべてのソースのデータ系統を文書化し、取得されたドキュメントの起源をその権威あるソースまで追跡できるようにする必要があります。これにより、規制産業における監査とコンプライアンスワークフローが可能になります。

埋め込みモデルとベクターストア

埋め込みモデルの選択

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

モデル選択には、表現品質、ベクトル次元、推論レイテンシ、財務コストの間のトレードオフが伴います。bge-large-enなどの汎用モデルは1024次元のベクトルを生成し、多様なドメインで機能します。技術テキストにファインチューニングされたドメイン固有の埋め込みモデルは、狭い検索タスクで汎用モデルを上回ることがよくあります。埋め込みモデルは、ベクトル類似性検索を可能にする数値表現に生テキストを変換します。

埋め込みモデルはまた、検索する必要があるドキュメントとは異なる表現でフレーズ化されたクエリを処理する能力（言い換えロバスト性と呼ばれる）についても評価できます。ユーザーが会話的に質問し、ドキュメントが正式に書かれているエンタープライズ設定では、このセマンティックブリッジングが重要です。本番インデックス実行にコミットする前に、実際のユーザークエリの代表的なサンプルに対して埋め込みモデルをテストすることで、後でコーパス全体を再埋め込みするコストのかかる作業を防ぐことができます。

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

埋め込みモデルのコンテキストウィンドウが有限であり、小さなチャンクの方がより正確な検索が可能になるため、大きなドキュメントは埋め込み前に小さなチャンクに分割する必要があります。チャンクサイズは出力品質に直接影響します。チャンクが小さすぎると周囲のコンテキストが失われ、大きすぎるとユーザーの質問に最も関連する特定のパッセージが薄まります。一般的な戦略には、トークン数による固定サイズ分割と、主要なコンテキストが境界に落ちるリスクを減らすためにオーバーラップ境界を持つ文境界分割が含まれます。

埋め込み後、ベクトルはベクターストアに保存されインデックスが作成されます。HNSWなどのアルゴリズムを使用するベクターインデックスは、埋め込みを整理して大規模な近似最近傍探索を可能にし、すべての埋め込みの線形スキャンからサブミリ秒のルックアップに検索を削減します。

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

セマンティック検索（ほとんどのRAGシステムのバックボーン）は、ユーザークエリに最も意味が近いドキュメントを見つけ、言い換えや同義語を自然に処理します。Databricks AI Searchは、Deltaテーブルからの自動同期でセマンティックベクトル検索を実装し、手動での再インデックスなしで知識ベースが新しいデータを反映できるようにします。

純粋なセマンティック検索には、正確なマッチクエリ（特定のエラーコード、バージョン番号、名前付きエンティティなど）に関して既知の弱点があります。ハイブリッド検索は、セマンティックベクトル検索とBM25キーワード検索（正確で珍しい用語のマッチングに優れた確率的な用語頻度モデル）を組み合わせることでこの問題に対処します。両方の検索パスを並行して実行し、逆数ランク融合を使用して結果をマージすることで、より広いクエリ分布にわたって検索効率を向上させます。

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

類似性しきい値は、最終的な品質ゲートを追加します。関連性スコアが最小カットオフを下回るドキュメントは、低品質のコンテキストとしてジェネレーターに渡す代わりに完全にフィルタリングする必要があります。無関係なコンテキストを渡すことは、コンテキストを渡さないよりも悪いです。コンテキストウィンドウを消費し、LLMが生成応答で正しい情報と誤った情報を混在させるリスクを高めます。控えめなしきい値を設定し、時間の経過とともにフィルター率を監視することは、アーキテクチャを変更せずに検索品質を維持する簡単な方法です。

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

RAGワークフローは、ユーザーの質問を事実に基づいた正確な応答に変換する5つの連続した段階に従います。

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

RAGパイプラインはデータインジェストから始まります。生のドキュメントは、テキストをクリーニングして正規化するETLパイプラインにロードされます。これには、定型文の削除、空白の標準化、テーブルやコードからの構造化コンテンツの抽出が含まれます。データレイクハウスアーキテクチャは、統一ガバナンスの下で構造化および非構造化コンテンツの両方のインジェストを集中管理し、RAG知識ベースの自然な基盤となります。

段階2：チャンク、埋め込み、インデックス作成

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

段階3：関連ドキュメントの検索

ユーザーがクエリを送信すると、RAGシステムは同じ埋め込みモデルを適用してユーザー入力をベクトル表現に変換し、ベクターストアをクエリして類似性検索を実行し、最も関連性の高いtop-kのドキュメントチャンクを返します。k値（取得するチャンク数）は、検索カバレッジとコンテキストウィンドウ消費のトレードオフであり、ターゲットLLMに合わせて調整する必要があります。

段階4：LLMプロンプトの拡張

取得されたドキュメントは、拡張されたプロンプトに組み立てられます。典型的な構造では、最初にシステム命令（「提供されたコンテキストのみに基づいてユーザーの質問に答えてください。コンテキストに答えが見つからない場合は、そのように言ってください。」）を配置し、次に取得されたテキストチャンク、最後にユーザーの元の質問を配置します。最も関連性の高いドキュメントを最初に配置すると、特に「中間喪失」現象（最初と最後の近くのコンテキストが中央のコンテンツよりも注意を引きやすい）に陥りやすいモデルに対して、焦点を改善する傾向があります。

段階5：最終応答の生成

ジェネレーターは拡張されたプロンプトを受け取り、最終応答を生成します。後処理により、フォーマットや引用符の追加など、出力をさらに最適化できます。本番RAGシステムには、ユーザーからの応答評価を収集して検索と生成の品質を継続的に改善するフィードバックループも含める必要があります。

このエンドツーエンドワークフローに従うことで、組織は正確で説明可能で信頼性が高く、簡単に更新できるAIシステムを構築し、モデルを継続的に再トレーニングする負担なしにリアルタイム知識の力を最大限に活用できます。