取得拡張生成 (RAG) は、独自のコンテンツを基に応答を基づけることによって LLM の機能を拡張するパターンです。 概念的には単純ですが、RAG 実装は大きな課題に直面しています。
RAG の課題
| 課題 | Description |
|---|---|
| クエリの理解 | 現代のユーザーは、想定されたコンテキストで複雑、会話的、あいまいな質問をします。 クエリがドキュメントの用語と一致しない場合、従来のキーワード検索は失敗します。 RAG の場合、情報取得システムは単語に一致するだけでなく、意図を理解する必要があります。 |
| マルチソース データ アクセス | エンタープライズ コンテンツは、SharePoint、データベース、BLOB ストレージ、およびその他のプラットフォームにまたがっています。 データ操作を中断せずに統合検索コーパスを作成することは不可欠です。 |
| トークン制約 | LLM は、限られたトークン入力を受け入れます。 取得システムは、完全なドキュメント ダンプではなく、関連性の高い簡潔な結果を返す必要があります。 |
| 応答時間の期待値 | ユーザーは、数分ではなく、数秒で AI を利用した回答を期待します。 検索システムは、徹底と速度のバランスを取る必要があります。 |
| セキュリティとガバナンスの | プライベート コンテンツを LLM に開くには、詳細なアクセス制御が必要です。 ユーザーとエージェントは、承認されたコンテンツのみを取得する必要があります。 |
Azure AI Search が RAG の課題を満たすしくみ
Azure AI Search には、これらの RAG の課題に特化して設計された 2 つのアプローチが用意されています。
エージェント検索 (プレビュー): LLM 支援クエリ計画、マルチソース アクセス、およびエージェントの使用に最適化された構造化応答を備えた完全な RAG パイプライン。
従来の RAG パターン: ハイブリッド検索とセマンティック ランク付けを使用した実証済みのアプローチ。より単純な要件や、一般公開 (GA) 機能が必要な場合に最適です。
以下のセクションでは、各アプローチで特定の RAG の課題がどのように解決されるかについて説明します。
クエリ理解の課題の解決
問題を： ユーザーは「2023 年以降に採用されたリモート ワーカー向けの PTO ポリシーとは」と尋ねますが、ドキュメントには "休暇"、"通信中"、"最近の採用者" と表示されます。
エージェント検索ソリューション:
- LLM は質問を分析し、複数の対象サブクエリを生成します
- 複雑な質問を焦点を絞った検索に分解する
- 会話履歴を使用してコンテキストを理解する
- 知識ソース間での並列実行
従来の RAG ソリューション:
- ハイブリッド クエリでは、キーワードとベクター検索を組み合わせて再現率を向上
- セマンティック ランク付けでは、キーワードだけでなく、意味に基づいて結果を再スコア付けする
- ベクトル類似性検索は、正確な用語ではなく概念の類似性を見つけます
マルチソース データの課題の解決
問題を： SharePoint の人事ポリシー、データベースの利点、Web ページ上の会社のニュースなど、コピーを作成すると、ガバナンスと日常的なデータ操作が中断されます。
エージェント検索ソリューション:
- ナレッジ ベースで複数のナレッジ ソースを統合する
- インデックス コンテンツを補完するために、リモート SharePoint と Bing (インデックス作成は必要ありません) に対する直接クエリ
- 取得手順は、LLM を適切なデータ ソースに導く
- Azure BLOB、OneLake、取り込まれた SharePoint コンテンツ、取り込まれたその他の外部コンテンツのインデックス作成パイプラインの自動生成
- すべてのソースにわたる単一のクエリ インターフェイスとクエリ プラン
従来の RAG ソリューション:
- インデクサーは、10 を超える Azure データ ソースからプルします
- チャンク化、ベクトル化、画像の言語化、及び分析のためのスキル開発パイプライン
- 増分インデックス作成でコンテンツを最新の状態に保つ
- インデックスの作成内容と方法を制御する
トークン制約の課題の解決
問題を： GPT-4 は最大 128,000 個のトークンを受け入れますが、ドキュメントは 10,000 ページあります。 すべてを送信するとトークンが無駄になり、品質が低下します。
エージェント検索ソリューション:
- 最も関連性の高いチャンクのみを含む構造化された応答を返します
- 組み込みの引用文献の追跡は、実証を示しています
- クエリ アクティビティ ログに、検索された内容が説明されています
- オプションの応答合成により、トークンの使用量がさらに削減されます
従来の RAG ソリューション:
- セマンティック ランク付けでは、最も関連性の高い上位 50 件の結果が識別されます
- 構成可能な結果の制限 (ベクトルの場合は top-k、テキストの場合は top-n) と最小しきい値
- スコアリング プロファイルによって重要なコンテンツが強化される
- Select ステートメントは、返されるフィールドを制御します
応答時間の課題の解決
問題を： ユーザーは 3 ~ 5 秒で回答を求めますが、複雑な処理で複数のソースに対してクエリを実行しています。
エージェント検索ソリューション:
- 並列サブクエリの実行 (シーケンシャルではない)
- 調整可能な推論作業 (最小/低/中)
- 事前構築されたセマンティック ランク付け (追加オーケストレーションなし)
従来の RAG ソリューション:
- ミリ秒クエリ応答時間
- 単一ショット クエリによって複雑さが軽減される
- タイムアウトと再試行ロジックを制御する
- 障害点が少ないシンプルなアーキテクチャ
セキュリティの課題の解決
問題を： 財務データには、エグゼクティブがチャットボットに問い合わせたときでも、財務チームのみがアクセスできるようにする必要があります。
エージェント検索ソリューション:
- ナレッジ ソース レベルのアクセス制御
- リモート SharePoint に対するクエリの SharePoint アクセス許可を継承します
- インデックス付きコンテンツの Microsoft Entra ID アクセス許可メタデータを Azure Storage から継承します
- 他のデータ ソースのクエリ時のフィルターベースのセキュリティ
- プライベート エンドポイントによるネットワーク分離
従来の RAG ソリューション:
- ドキュメントレベルのセキュリティ トリミング
- インデックス付きコンテンツの Microsoft Entra ID アクセス許可メタデータを Azure Storage から継承します
- 他のデータ ソースのクエリ時のフィルターベースのセキュリティ
- プライベート エンドポイントによるネットワーク分離
エージェンティックリトリーバルを使用した最新の RAG
Azure AI Search は、 RAG ワークロード向けの実証済みのソリューションです。 これで 、エージェント検索が提供されるようになりました。これは、RAG パターン専用に設計された特殊なパイプラインです。 このアプローチでは、LLM を使用して、複雑なユーザー クエリをインテリジェントにフォーカスされたサブクエリに分割し、並列で実行し、チャット完了モデル用に最適化された構造化された応答を返します。
エージェント検索は、従来の単一クエリ RAG パターンからマルチクエリ インテリジェント取得への進化を表し、次の機能を提供します。
- 会話履歴を使用したコンテキスト対応クエリの計画
- 複数のフォーカスされたサブクエリの並列実行
- グラウンド データ、引用、実行メタデータを使用した構造化された応答
- 最適な関連性のための組み込みのセマンティック ランク付け
- クエリ応答で LLM で定式化された回答を使用するオプションの回答合成。
このパイプラインには、1 つ以上のナレッジ ソース、ナレッジ ベース、アプリケーション コードから呼び出す取得アクション (AI エージェントで動作するツールなど) の新しいオブジェクトが必要です。
新しい RAG 実装の場合は、 エージェント検索から開始することをお勧めします。 既存のソリューションの場合は、精度とコンテキストの理解を向上させるために移行を検討してください。
Azure AI Search のクラシック RAG パターン
クラシック RAG は、アプリケーションが 1 つのクエリを Azure AI Search に送信し、LLM へのハンドオフを個別に調整する 元のクエリ実行アーキテクチャ を使用します。 デプロイされた LLM は、クエリからフラット化された結果セットを使用して回答を作成します。 この方法は、クエリ計画に LLM が関与しないため、コンポーネントの数が少なくなり、高速になります。
クラシック RAG の実装の詳細については、 azure-search-classic-rag リポジトリを参照してください。
RAG のコンテンツ準備
RAG の品質は、取得するコンテンツの準備方法によって異なります。 Azure AI Search では、次の機能がサポートされます。
| コンテンツチャレンジ | Azure AI Search が役立つしくみ |
|---|---|
| 大きなドキュメント | 自動チャンク化 (組み込み機能またはスキル経由) |
| 複数の言語 | テキスト、多言語ベクター用の 50 以上の言語アナライザー |
| 画像と PDF | OCR、画像分析、画像言語化、ドキュメント抽出スキル |
| 類似性検索の必要性 | 統合ベクター化 (Azure OpenAI、Azure AI Vision、カスタム) |
| 用語の不一致 | シノニム マップ、セマンティック ランク付け |
エージェント検索の場合: チャンクとベクター化パイプラインを自動生成する ナレッジ ソース を使用します。
クラシック RAG の場合:インデクサーとスキルセットを使用してカスタム パイプラインを構築するか、プッシュ API を使用して前処理されたコンテンツをプッシュします。
関連性と再現性を最大化する
LLM 回答の定式化に最適な接地データを提供するにはどうすればよいですか? これは、適切なコンテンツ、スマート クエリ、クエリ ロジックを組み合わせたものであり、質問に答えるのに最適なチャンクを識別できます。
インデックス作成中は、チャンクを使用して大きなドキュメントを分割し、部分を個別に照合できるようにします。 ベクター クエリに使用される埋め込みを作成するベクター化手順を含めます。
クエリ側で、RAG 実装に最も関連性の高い結果を確保するには、次のようにします。
キーワード (nonvector) とベクター検索を組み合わせて最大再現率を求めるハイブリッド クエリを使用します。 ハイブリッド クエリでは、同じ入力を 2 倍にした場合、テキスト文字列とそのベクトルに相当する入力により、キーワードと類似性検索に対して並列クエリが生成され、統合された結果セット内の各クエリの種類から最も関連性の高い一致が返されます。
従来の RAG の場合はオプションで、エージェント検索に組み込まれたセマンティック ランク付けを使用します。
スコアリング プロファイルを適用 して、特定のフィールドまたは条件をブーストします。
ハイブリッド検索とセマンティック ランク付けの詳細について説明します。
エージェント検索とクラシック RAG の選択
エージェント検索は、次の場合に使用します。
- クライアントがエージェントまたはチャットボットである
- 可能な限り高い関連性と精度が必要です
- クエリが複雑または会話型である
- 引用文献とクエリの詳細を含む構造化された応答が必要です
- 新しい RAG 実装を構築する
クラシック RAG は次の場合に使用します。
- 一般公開 (GA) 機能のみが必要です
- シンプルさとスピードは、高度な関連性よりも優先されます
- 保持する既存のオーケストレーション コードがある
- クエリ パイプラインをきめ細かく制御する必要がある
エージェントと Azure AI Search を含む RAG ソリューションは、グランド データを提供するナレッジ レイヤーへのエージェントの単一エンドポイントとして Foundry IQ の恩恵を受けることができます。 Foundry IQ ではエージェント検索が使用されます。
クラシック検索、エージェント検索、およびそれらの比較の詳細について説明します。
ファースト ステップ
コードファーストのソリューションやデモなど、さまざまな方法で作業を開始できます。