実際のユースケースとアーキテクチャに基づく9つのRAGの例

RAGは、一般消費者向けとエンタープライズ向けの両方のコンテキストで広く使用されています。RAGの現実世界の日常的な例としては、ウェブ検索、カスタマーサポート、AIを活用したショッピングなどが挙げられます。社内ナレッジへのアクセスやコーディング支援は、ビジネスにおける最も顕著な例の一部です。

RAGのアーキテクチャも、ユースケースによって異なります。最も一般的な実装の2つは、従来のキーワードマッチングとベクトル検索またはナレッジグラフ検索を組み合わせたハイブリッドRAGと、LLMが検索プロセスを直接制御するエージェント型RAGです。

検索拡張生成（RAG）とは？

RAG（検索拡張生成）を使用すると、AIアプリケーションは外部システムに保存されている情報にアクセスして、LLMが生成した回答を補完できます。

これが強力な技術である理由は、生成AIにおける3つの大きな問題、すなわちハルシネーション（幻覚）、情報の陳腐化、そして入力コンテキストに含まれないデータへのアクセス性の欠如に対処するためです。

基本的なRAGプロセスの流れは次のとおりです。

1. ユーザーが自然言語でプロンプトを入力します。
2. AIアプリケーションは、（時にはLLMを関与させて）グラウンディングが必要かどうかを判断します。
3. データベースなどの外部情報ソースにリクエストが送信されます。
4. 取得した情報がLLMの入力コンテキストに追加されます。
5. LLMが拡張されたプロンプトに基づいて回答を生成します。

具体的な実装方法には違いがあるものの、これらのステップは一般的なRAGワークフローを表しています。さまざまなタイプのアーキテクチャ間の違いは、クライアントアプリケーションによってリクエストがどのように処理されるかや、取得される情報の性質を中心にする傾向があります。

RAGアーキテクチャの概要

「検索拡張生成（retrieval-augmented generation）」という用語は、Meta AI（当時のFacebook AI Research）の研究者と、ユニバーシティ・カレッジ・ロンドンおよびニューヨーク大学の協力者によって発表された、2020年の論文『Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks』で初めて登場しました。

「ナイーブRAG」と総称される初期の「検索してから生成する（retrieve-then-generate）」アプローチは、その後、さまざまな種類のアーキテクチャへと発展し、その多くが重複しています。

ナイーブRAG

ナイーブRAGは、シンプルな「検索して生成する」パイプラインを使用します。これは、多くの基本的なリクエストにおいて現在でも適切です。ナイーブRAGの最も一般的な例は、クエリをベクトル埋め込み（または単にベクトル）と呼ばれる順序付けられた数値のリストに変換することです。次に、クエリのベクトル埋め込みが、データベースまたはインデックス（セマンティックインデックスと呼ばれる）内のコンテンツのチャンク（部分）を表す他のベクトルと照合されます。

高度なRAG

高度なRAGは、検索の前後の段階を最適化します。テクニックには、クエリの拡張、メタデータフィルタリング、コンテキスト圧縮などが含まれます。これらは本質的に、取得される情報の関連性と、LLMの入力コンテキストに追加される前にそれがどのように修正されるかを改善します。

エージェント型RAG

エージェント型RAGとは、LLMベースのエージェントによってRAGパイプラインが実行されることです。エージェントは、特定のプロンプトに対してどのツールが最適かを「判断」し、関連する回答を生成するために（時にはループ内で）検索を指示します。

グラフRAG

グラフRAGは、エンティティ（オブジェクト、概念、イベントなど）とそれらの間の関係を表すナレッジグラフから情報を取得します。これは、プロンプトへの回答に、LLMが個別のエンティティに関する情報を組み合わせる必要がある場合に役立ちます。

マルチモーダルRAG

マルチモーダルRAGは、クエリと検索の両方のプロセスにおいて、画像や音声などのコンテンツへと検索を拡張します。これらのRAGパイプラインは、特殊なエンコーダーを使用して、テキスト、画像、または音声をベクトル埋め込みに変換します。

ハイブリッドRAG

ハイブリッドRAGは、キーワード検索（または語彙検索）とベクトル検索またはナレッジグラフを組み合わせて、結果を統合します。これは、特定のコンテキストにおいて、キーワードマッチングが（他の方法よりも）非常に高精度になる場合があるため便利です。

修正RAG

修正RAGは、返された情報またはデータがクエリに関連しているかどうかを評価します。取得したパッセージを洗練または補足したり、別のリクエストを実行して完全に置き換えたりすることがあります。

ユースケースおよび業界のアプリケーション別のRAGの例

一般消費者向けおよびビジネス向けの双方において、RAGの例は多数存在します。これは主に、RAGパイプラインがほとんどのメインストリームツールに統合されているためです。さらに、多くのベンダーがカスタマーサービス用チャットボット向けなどのすぐに使える統合機能を提供しており、それが導入を促進しています。

1. ウェブ検索

ウェブ検索は、RAGの最も普及している例の1つです。毎日、何百万人もの人々がAIツールを使用して、ウェブから取得した情報に基づいた回答を生成しています。

仕組み：AIアプリケーションは、キーワードベースおよびセマンティック検索を使用して、Google検索インデックスなどのウェブインデックスを検索します。関連するページのコンテンツが、ユーザーの質問とともにLLMの入力に含まれます。その後、LLM通常はソースの引用とともに回答を生成します。

実際の例：ユーザーがPerplexityのチャットインターフェースに「シカゴの天気は？」などの簡単なクエリを入力すると、LLMは最新情報を取得するためにウェブ検索を実行します。Perplexityは、独自のウェブインデックスをパートナーの検索APIと組み合わせて使用しています。

拡大

2. カスタマーサポート

アプリ内およびウェブサイト上のチャットボットは、RAGの主要なエンタープライズ向けユースケースとして台頭してきました。これらのシステムは通常、従来のルーティングパスと結合され、カスタマー担当者の介入の必要性を減らします。

仕組み：顧客が質問すると、アプリケーションは（多くの場合ハイブリッドパイプラインを使用して）会社のナレッジベースを検索します。取得されたパッセージがLLMに提供され、LLMが回答を生成します。また、回答を検証し、必要な場合に担当者へルーティングするために、通常は修正プロセスや引き継ぎプロセスも関与します。

実際の例：Zendesk（以下画像）やIntercomなどのさまざまなカスタマーサービスプラットフォームは、既存のドキュメントやカスタマーサポート基盤と統合する、すぐに使えるカスタマーサポート向けチャットボットを提供しています。

拡大

3. パーソナルアシスタント

パーソナルアシスタントは、エージェント型RAGを使用して、ユーザーのメール、ファイル、カレンダーにアクセスします。これらのアシスタントは通常、複数のRAGパイプラインを実行できます。

仕組み：パーソナルアシスタントは多くの場合複数の情報ソースへのアクセスを必要とするため、API、キーワード検索、ベクトル検索、ナレッジグラフを組み合わせて使用します。アプリケーションからさまざまなツールの説明がLLMに送信され、LLMが最適なツールを選択します。

実際の例：Google Geminiは、汎用および個人のAIアシスタントとして機能できるアプリの好例です（近年のほとんどのアシスタントがそうであるように）。Gmail、ドキュメント、フォト、カレンダーなどのツールエコシステムと統合されています。

拡大

4. Enterpriseナレッジ管理

Enterpriseナレッジ管理により、従業員は、方針、レポート、プロジェクトドキュメント、法的テキスト、さらには社内のディスカッションなど、幅広い社内情報に横断的に質問できるようになります。

仕組み：アプリケーションは、ソースドキュメントの変更に伴って更新されるベクトルインデックスを使用して、関連コンテンツを取得します。インデックスには、テキストや関連するメタデータへのリンクを持つ、ドキュメントのチャンクを表すベクトル埋め込みが含まれています。

実際の例：Microsoft 365 Copilotは、データソース向けにさまざまなAPIを公開しているMicrosoft Graphを介して組織情報にアクセスし、語彙インデックスおよびセマンティックインデックスを使用して関連コンテンツを取得します。

拡大

5. コーディングアシスタント

コーディングアシスタントは、コードベースにRAGを適用します。基盤となるRAGプロセスは同じ（通常はエージェント型RAG）ですが、違いはコードのコンテキストを専門的に処理する点にあります。

仕組み：コーディングアシスタントは、ローカルのプロジェクトファイルをインデックス化し、プロンプトの入力時に複数の検索パスを実行して関連するコードスニペットを見つけます。また、これらのアシスタントは通常、企業向けのナレッジベースなどへのアクセスを拡張するための専用のコネクタを備えています。

実際の例：GitHub Copilotは、開発プロジェクトと直接統合するコーディングアシスタントのよく知られた例です。また、回答の精度を高めるために、公開されているGitHubリポジトリを参照することもできます。

拡大

6. テクニカルなトラブルシューティング

テクニカルなトラブルシューティングでは、ナレッジ管理RAGパイプラインと診断ループが統合されます。エージェントは結果を評価し、必要に応じてトラブルシューティングの推奨事項をさらに洗練させることができます。

仕組み：アプリケーションは、ユーザーから技術的な問題の症状を収集するか、自動化された監視アラートを受信します。エラーメッセージ、テクニカルログ、パフォーマンスメトリクスの検索をトリガーして症状を照合します。その後、内部ナレッジベースから関連情報を取得し、LLMに渡します。診断ループは、ユーザーまたは診断ツールからの、試行された修正の結果がLLMにフィードバックされるときに発生します。

実際の例：オブザーバビリティプラットフォームのDatadog（以下画像）は、システムのすべてのレイヤーからデータを収集し、問題が発生したときにフラグを立てます。これらは、潜在的な修正をトラブルシューティングするために、Bits AIと呼ばれる特殊なAIエージェントにフィードバックされます。

拡大

7. エージェント型コマース

エージェント型コマースは、通常RAGを伴う、より広範なユースケースです。ショッピングエージェントは、製品仕様、レビュー、価格、在庫状況などの詳細を取得してオプションを比較し、おすすめを説明します。その後、ユーザーがインターフェースを離れることなく、自動的に購入を実行できます。

仕組み：エージェント型コマースは、特定のクエリが異なる形式の検索を必要とすることが多く、それをモデルが指示するため、真のエージェント型RAGとなります。エージェントは、小売業者のAPIを通じてテキストのみの製品データを取得する場合もあれば、マルチモーダルRAGを使用して、ユーザーの写真に基づきセマンティックインデックス内の製品と照合する場合もあります。

実際の例：Perplexityのような汎用エージェントは、プロンプトに基づいて複数の画像と詳細な製品仕様を取得できます。「インスタント購入」チェックアウト機能により、ユーザーは製品を選んだ後で購入を完了できます。

拡大

8. 特殊な知識ドメイン

特殊なドメイン知識を取得するAIツールは、複雑なコンテンツ形式に対処する必要があります。さらに、ハルシネーションや情報のギャップを最小限に抑えることが多くの場合優先されます。

仕組み：汎用RAGアーキテクチャと特殊なRAGアーキテクチャの主な違いは、ソース資料と検索設定に関連しています。通常、信頼性の高いインデックスのみがクエリされ、検索を絞り込むために特定のエージェント用語や専門用語を含めるようにリクエストが設定されます。

実際の例：学術研究ツールのSciteは、出版社との契約やオープンアクセスソースを通じて構築された、学術論文と引用データの大きなインデックスにアクセスします。また、完全な回答を生成する前に、ソースの検証などの検索後チェックも適用します。

拡大

9. データ分析

データ分析向けRAGは、幅広い専門家、特にデータサイエンスのトレーニングを受けていない人が自然言語を使用してデータセットにクエリを実行できるようにするため、非常に強力なエンタープライズ向けユースケースとなっています。これにより、レポートの作成や非常に具体的な質問をすることが容易になります。

仕組み：「前四半期の売上が落ち込んだのはなぜか？」といった質問に対して、アプリケーションは売上記録にクエリを実行し、在庫不足や価格変更に関するメモを取得する場合があります。LLMは、分析を生成する前に、取得したデータに対して適切な計算（通常は計算ツールに委任される）を選択します。

実際の例：Googleアナリティクスは、ウェブアナリティクスデータにアクセスし、ユーザーからの非常に具体的でニュアンスのある質問に答えることができるAI「Ask Advisor」チャットボットを提供しています。これは、エンタープライズグレードのクローズドシステム型RAGの現実における最良の例の1つです。

拡大

RAGの進化の次なる展開とは？

RAGは、最初に導入された当時は重要な進歩でした。単体型のLLMに固有の多くの問題に対処するのに役立ちました。

しかし、これは静的な技術とは程遠いものです。現在の研究は、より深いマルチモーダル検索や、正確性と正しさのための取得されたコンテキストのより厳格な処理に焦点を当てています。さらに、マルチツールエージェントへのRAGの統合が進むことが予想されます。

非常に大規模なコンテキストウィンドウが存在する現在でも、個人的および専門的なコンテキストの両方でRAGの重要なユースケースがあり、今後も多くのイノベーションが控えています。