RAGアーキテクチャとは？定義と詳しい実践例を徹底解説

RAG（検索拡張生成：retrieval augmented generation）とは、LLMが外部の情報を活用して出力を拡充・改善するプロセスです。RAGアーキテクチャとは、RAGを実現するコンポーネントとそれらの接続の集合を指します。

RAGにはいくつかの異なるカテゴリーがあり、それぞれが独自のアーキテクチャで動作します。本質的に、RAGシステムのアーキテクチャは、情報をどのように保存・検索し、LLMに渡すかという固有の方法を決定します。

RAGアーキテクチャとは？

RAGアーキテクチャとは、特定のRAGシステムを支えるコンポーネント（およびそれらに関連する機能）の基盤となる構成です。これらのアーキテクチャはすべて、「シンプル」RAGまたは「ナイーブ」RAGと呼ばれることの多い基本テンプレートの上に成り立っています。

基本的なRAGアーキテクチャの概要は次のとおりです。

• 情報ソース：外部の情報が保存される場所です。検索インデックス、大量の情報を表現するベクトルデータベース、あるいは未加工のドキュメントリポジトリなどが該当します。
• 検索コンポーネント：情報ソースに対してクエリを実行する仕組みです。たとえばRAGシステムでは、関連するテキストのチャンクを見つけるためにシンプルなキーワード検索を使用したり、類似度検索を行うためにより複雑なベクトルクエリを使用したりします。
• オーケストレーションコンポーネント：このレイヤーは、LLMベースのアプリケーションのうち、ユーザーのプロンプトに対してRAGパイプラインを起動する部分で、LLMと連携して、あるいは独立して動作します。また、検索した情報を拡張プロンプトにまとめる役割も担います。

RAGアーキテクチャのコンポーネントは通常、2つの経路に分けて構成されます。取り込み経路は、データを受け取り、検索可能な情報ソースとして整理します。大量のテキストをベクトル埋め込みの検索可能なリポジトリに変換するベクトルデータベースは、最も広く使われている応用例の1つです。

検索経路は、ユーザーのプロンプトを受け取り、情報ソースを検索するためのクエリを生成します。その後、オーケストレーターが検索した情報をLLMへのコンテキスト入力に追加します。エージェント型RAGやハイブリッドRAGのアーキテクチャでは、複数の検索経路が存在する場合があります。

RAGアーキテクチャの種類

RAGを完全に別個のアーキテクチャとして捉えるのは誤解を招きます。多くのエンジニアはモジュール型のアプローチを取り、特定のユースケースに合わせて個別のコンポーネントを実装します。大まかな境界線を引くことは可能ですが、アーキテクチャモデル同士には大きな重なりがある点に注意が必要です。

1. 基本RAG

基本RAGは、「ナイーブ」RAGや「シンプル」RAGとも呼ばれ、他の種類のRAGのアーキテクチャ上のテンプレートとなるものです。

基本的なプロセスは比較的シンプルです。ユーザーがプロンプトを入力すると、オーケストレーターが外部情報が必要かどうかを（単独で、またはLLMと連携して）判断し、それに応じて検索クエリを作成して送信します。

外部情報ソースとしては一般的にベクトルデータベースが使われますが、SQLデータベース、Web API、ナレッジグラフ、さらには「未加工」のドキュメントリポジトリが使われることもあります。こうして得られた追加情報が、LLMの入力コンテキストに加えられます。

SQLクエリやAPIを除くと、検索手法は大きく2種類に分けられます。

• 語彙検索（キーワード検索）：ユーザーのクエリからキーワードを抽出し、それらのキーワードを含むテキストの一節と照合する、シンプルな形式のRAGです。最新のパイプラインでは、オーケストレーターがこれを行うためにスパースベクトルクエリと呼ばれる手法を用いることがありますが、これは意味を捉えるものではありません。
• 密ベクトル検索（セマンティック検索）：密ベクトル埋め込みは意味を捉えます。オーケストレーターは、ユーザーのプロンプトとソース情報の両方の意味を捉えられる形で、密ベクトルデータベースにクエリを実行できます。

メモリの活用もRAGアーキテクチャの重要な要素です。これは、LLMが過去のチャットのコンテキストを使って検索クエリを組み立て、それによってクエリを会話（または複数の会話）のより広い文脈に根付かせる方法を指します。ほとんどのチャットボットでは会話型RAGが標準ですが、サポートチケットへの返信など一部のユースケースでは単一質問型RAGが使われることもあります。

2. ハイブリッド

ハイブリッドRAGは、2種類の異なる検索、通常はキーワード検索とセマンティック検索を組み合わせたものです。キーワード検索は一致する用語を見つけ、ベクトルベースの検索は関連する意味を持つ一節を見つけます。

ナレッジグラフの探索やSQLデータベースへのクエリなど、他の形式の検索が使われることもあります。このプロセスは多くの場合、プログラムされたルールやモデルによる質問の分類といった形のルーティングロジックによって制御されます（ただし、複数のパイプラインを同時に実行することも可能です）。

オーケストレーターは結果を統合し、LLMに渡す前に再ランク付けを行うこともあります。再ランク付けとは、検索されたチャンクに関連性スコアを割り当て、LLMが最も適切な情報を優先できるようにするプロセスです。

3. アダプティブRAG

アダプティブRAGでは、ルーティングコンポーネントがユーザーのプロンプトの要件に基づいて検索戦略を選択し、オーケストレーターが選択されたワークフローを実行します。

元のフレームワーク（Adaptive-RAG）では、より小規模なモデルが分類器として機能し、検索なし、単一ステップ検索、複数ステップ検索のいずれかを選択していました。現在では、代わりに生成モデルやルールベースのヒューリスティックを使用するアーキテクチャもあります。

プロンプトの複雑さや要件に応じて処理能力を割り当て、シンプルなプロンプトでは不要な検索ステップを減らせるため、人気のあるアーキテクチャです。複数の種類の質問に対応するアシスタントでよく使われています。

4. 修正型RAG（CRAG）

修正型RAGは、検索した情報をLLMのコンテキスト入力に追加する前に評価します。検索評価器が、検索した情報に関連性があり有用かどうかを判定します。このアーキテクチャの特徴は、回答生成の前に明示的な「評価と修正」の段階がある点です。

情報が不完全である、またはプロンプトに適さないと判断された場合は、追加のリクエストがトリガーされます。これには、Web検索やナレッジグラフの探索など、元のリクエストとは異なる検索手法が含まれることがあります。

修正型RAGは、医療や法律など正確性が重視される分野でよく使われます。ただし、最初に検索した一節を補完できる追加の情報ソースが必要になります。

5. Self-RAG

Self-RAGでは、モデルが最初のコンテキスト入力を受け取った後に、自らリクエストを開始できます。生成された回答はリフレクショントークンを用いて検索された根拠と照らし合わせて評価され、必要に応じてオーケストレーター経由でさらにリクエストが送信されます。逆に、LLMが検索はまったく不要だと判断することもあります。

修正型RAGとの違いは、LLMが自らの出力を判断し、検索が必要かどうか、検索したテキストが有用かどうかを判断し、自らの回答を監視して必要に応じて修正する点です。一方、修正型RAGは生成の前に検索した情報の品質を評価します。

このアーキテクチャは、深い研究型の複雑なプロンプトに特に有用です。（検索した情報の）関連性の評価を回答生成に組み込むため、根拠に基づく回答が求められるプロンプトに適した選択肢です。

6. エージェント型RAG

エージェント型RAGとは、エージェント型プラットフォーム上で実行されるあらゆる形式のRAGを指します。モデルは推論能力を使って必要な情報の種類を判断し、利用可能な検索オプションから選択します。

検索は必要に応じて何度でもトリガーでき、モデルはより複雑なクエリに対してエージェントを割り当てることもできます。たとえばLLMは、データベース検索をリクエストしてサプライヤーを特定し、ドキュメント検索をトリガーして関連する契約書を見つけ、最後にWeb検索で公開情報を使って連絡先の詳細を確認する、といった処理を行えます。

エージェント型RAGは、Perplexity、ChatGPT、Claudeなどの主要なチャットボットにおける主なアーキテクチャ実装です。これらのプラットフォームはコアモデルに複数のツールやRAGパイプラインへのアクセスを提供しているため、モデルはプロンプトに最も適した検索形式を選択できます。

7. マルチモーダルRAG

マルチモーダルRAGは、さまざまな種類のメディアにわたってコンテキストを検索します。グラフや音声録音など、本来ならアクセスできない情報をLLMが利用できるようにするため、重要な形式のRAGです。

基盤となるアーキテクチャは他のシステムと同じです。たとえば、インデックス作成パイプラインは画像を直接埋め込みに変換して検索用に準備できます。その後、エージェント型RAGシステムがこれらの画像を意味的に関連するテキストとあわせて検索し、視覚言語モデルに渡して両方を処理させることができます。

8. GraphRAG

GraphRAGは、ベクトル検索とあわせてナレッジグラフを使用し、エンティティに関する情報を検索します。通常、オーケストレーターはキーワード抽出、場合によっては予備的なベクトル検索を使って、ノードとも呼ばれる関連する起点エンティティを見つけます。その後、グラフリトリーバーがナレッジグラフを探索して、より広いコンテキストを構築します。

たとえば、ある製品カテゴリーの詳細な内訳を求めるリクエストに対し、LLMはベクトル検索をトリガーして特定のエンティティ（製品）を特定します。その後、オーケストレーターがナレッジグラフ検索をトリガーし、サプライヤー、販売店舗、レビューなどの関連エンティティを見つけます。

9. 分岐型RAG

ハイブリッドRAGアーキテクチャが異なる検索手法を使用できるのに対し、分岐型RAGは、ブランチと呼ばれる複数のクエリを同時に実行するプロセスを指します。各ブランチが別々の情報ソースにクエリを実行することも、異なるクエリやフィルターを使って同じソースに並行してクエリを実行することもできます。エージェント型RAGのアーキテクチャでは、分岐型RAGがよく使われます。

10. HyDE（Hypothetical Document Embeddings：仮説的文書埋め込み）

HyDEは革新的な形式のRAGで、LLMが最適な回答がどのようなものになるかを想定した仮説的なテキスト文書を作成します。この「仮説的文書」を使ってクエリを作成し、より正確な検索を行います。関連する知識がLLMのパラメーターに含まれていなくても、回答のような一節のほうが、短い質問や曖昧なプロンプトよりも関連文書にうまく一致する可能性がある、というのがその根拠です。

シンプルなRAGアーキテクチャの例：ベクトルデータベース

基本RAGは、より複雑な種類のアーキテクチャの基盤となります。ベクトルデータベースを使用するシンプルなRAGシステムの場合、ソースドキュメントは小さな断片（チャンク）に分割され、密な埋め込みに変換されます。ユーザーがプロンプトを入力すると、オーケストレーターはクエリを生成してエンコードし、データベースにクエリを実行して関連する一節を見つけます。

プロセスの手順は次のとおりです。

1. 自動化された取り込みパイプラインと、BERTなどの埋め込みモデルを使って、大量のテキストをベクトルに変換します。
2. データベースアプリケーションがベクトルを整理・インデックス化・保存し、高速な検索を可能にします。
3. ユーザーがチャットボット（Perplexityなど）にプロンプトを入力します。
4. アプリケーションのオーケストレーターが（埋め込みモデルを使って）プロンプトをエンコードし、ベクトルデータベースから関連情報を検索します。
5. ベクトルデータベースが関連するチャンクを返し、オーケストレーターがそれらを入力コンテキスト（「大きなプロンプト」）に追加してLLMに渡します。
6. LLMは追加のコンテキストと、（パラメトリックな重みに保存された）内部知識を使って回答を生成します。

拡大

高度なRAGアーキテクチャの例：エージェント型RAG

エージェント型RAGとは、エージェント型プラットフォーム内のRAGシステムの基盤となるアーキテクチャを指します。AIエージェントはプロンプトの性質に応じてさまざまなツールやパイプラインを呼び出し、必要に応じて複数のエージェントを展開できるため、エージェント型RAGのフローは複雑になる傾向があります。

プロセスの実例は次のとおりです。

1. ユーザーが、あるトピックについて深い研究を必要とする複雑な質問を入力します。この例では、プロンプトを「主要な地政学的動向を踏まえて、今後6か月間の企業収益の予測を提示してください」とします。
2. LLMは、異なるコンテンツタイプにまたがる複数のRAGクエリの組み合わせが必要だと推論します。
3. (a) ベクトル検索、(b) Webグラウンディング、(c) 画像（マルチモーダル）検索のために、3つの異なるエージェントが展開されます。
4. エージェントは、利用可能な検索ツールを使い、オーケストレーター経由でニュース記事や社内の財務データなどの関連情報を検索します。
5. LLMは、検索結果を各エージェントの調査課題と照らし合わせ、関連性の高い順にランク付けします。
6. LLMは情報を評価し、情報が不足している箇所については個々のエージェントを通じて追加の検索をトリガーします。
7. 十分な情報が検索されると、LLMは（社内ドキュメントから検索した）既存の財務数値に基づいてシナリオ別の予測を生成し、計算ツールを呼び出してそれぞれの収益を予測します。
8. LLMは、検索した情報と計算結果を使って最終的な回答を生成し、必要に応じて出典を示します。

拡大

RAGの今後は？

現在のイノベーションは、既存のRAGアーキテクチャに深さとスピードをもたらすこと、マルチメディア検索の精度を高めること、そして最新の情報に対応できるよう設計されたシステムを構築することに重点が置かれています。

現在、研究の方向性を形づくっている3つのトレンドを紹介します。

• 複数のソースにまたがる深い研究：検索を計画し、異なるソースにまたがって複数のブランチを実行し、検索した根拠を評価し、生成した回答を自己最適化できるRAGアーキテクチャです。これらのタスクをすべて実行できるエージェント型RAGは、ますます高速かつ低コストになっています。
• マルチモーダルアプリケーション：検索パイプラインは、画像や動画をますます的確に扱えるようになっています。長尺動画や高度な図表など、複雑なマルチモーダルデータの中から特定の種類の情報をピンポイントで見つけられるようになりつつあります。
• 絶えず変化する情報に基づいた回答：LLMベースのアプリケーションは、（映像フィードやセンサーなどの）ライブ情報ソースを活用して入力コンテキストを提供できます。また、GraphRAGのように多面的な情報のネットワークを生成し、こうしたデータを解釈することも可能です。

RAGは、LLMベースのアプリケーションが機能する仕組みの根幹をなすものです。日常的な消費者から専門分野で事業を行う企業まで、さまざまなユーザーが、ハルシネーション、不完全な学習データ、専門的な社内知識へのアクセス不足といった課題を克服できるようにします。

だからこそ、RAGシステムとその基盤となるアーキテクチャは、AI研究の中でも最も進展が速く、最もエキサイティングな分野の1つとなっているのです。