論文選定理由
RAGの最新動向を知るにあたり、まずは今迄のRAGの進化の流れを理解したかったため。
1. 概要
Overviewまとめ
- ハルシネーション・古い知識・不透明な推論プロセスといったLLMが直面している課題に対してRAG（Retrieval-Augmented Generation）が登場した。
- RAGは外部データベースの知識を取り込むことで、生成の精度と信頼性を高めることを可能にし、特に知識集約型タスクにおいて効果を発揮した。
- 本レビュー論ではNaive RAGからAdvanced RAG、Modular RAGに至るまでのRAGパラダイムの進化を検証している。
- RAGフレームワークの基盤をなす検索、生成、拡張の三つの要素について最新技術を深く掘り下げている。
- 最終的に、RAGシステムの現状の課題を指摘し、今後の研究開発の展望を示している。
論文構成
| 主要な構成要素/テーマ | 内容のまとめ | 関連するRAGの概念 |
|---|---|---|
| RAGの概要 | Naive RAG、Advanced RAG、Modular RAGといったRAGパラダイムの進行を検証 | Naive RAG、Advanced RAG、Modular RAG |
| RAGフレームワークの要素 | RAGフレームワークを構成する三つの要素、検索（retrieval）、生成（generation）、拡張（augmentation）技術について精査 | 検索、生成、拡張 |
| 評価フレームワークとベンチマーク | 最新の評価フレームワークとベンチマークを紹介 | 評価、ベンチマーク |
| 課題と将来の展望 | 現在直面している課題を明確に示し、研究開発のための将来的な展望 | 課題、将来的な展望 |
2. RAGの概要
RAGは主に3つのステップで構成される。
- インデックス作成
ドキュメントはチャンクに分割され、ベクトルにエンコードされ、ベクトルデータベースに保存される。 - 検索
意味的類似性に基づいて、質問に最も関連性の高い上位k個のチャンクを取得。 - 生成
元の質問と取得したチャンクをLLMに入力して、最終的な回答を生成。
図:質問応答に適用されたRAGプロセス例
RAGのパラダイムは進化しているが、（論文執筆時点では）ナイーブRAG、アドバンストRAG、モジュラーRAGの3段階に分類できる 。
RAG手法は費用対効果が高く、ネイティブLLMの性能を上回っているが、いくつかの限界も存在する。
アドバンスドAGとモジュラーRAGの開発は、ナイーブRAGのこれらの特定の欠点に対応するものとなる。
図：RAGのパラダイム比較
2-1.ナイーブRAG
構造の特徴
インデックス化・検索・生成の３ステップで構成されており、"Retrieve-Read"フレームワークとして特徴づけられる
欠点
- 検索の課題: 検索の精度や再現率が低く、無関係なチャンクが選択されたり、重要な情報が見落とされたりする。
- 生成の困難性: 取得したコンテキストに裏付けられていないコンテンツを生成する「ハルシネーション」の問題や、出力の無関係性、有害性、バイアスなどの問題に直面し、回答の質や信頼性を損なう。
- 拡張のハードル: 取得した情報とタスクの統合が難しく、一貫性のない出力になったり、複数のソースから類似した情報が取得された場合に冗長性が生じる。また、拡張した情報に生成モデルが過度に依存し、洞察を加えずにたんに検索結果を繰り返すことがある。
2-2.アドバンスドRAG
構造の特徴
Naive RAGの限界を克服するために特定の改善を導入し、主に検索品質の強化に焦点を当てている。Naive RAGと同様にチェーン状の構造を踏襲しつつ、検索前後の戦略を通じて最適化を図っている。
検索前のプロセスに対する戦略
- インデックス構造の最適化（データの細分化強化・インデックス構造の最適化・メタデータの追加・アラインメント最適化・混合検索など）
- 検索クエリの最適化（クエリの書き換え・クエリ変換・クエリ展開など）
検索後のプロセスに対する戦略
- チャンクのリランキング（最も関連性の高いコンテンツをプロンプトの端に配置する）
- コンテキスト圧縮（重要な情報の選定・重要な部分の強調・処理すべき文脈の短縮）
2-3.モジュラーRAG
構造の特徴
大きく書き２点に対応することで従来のRAGよりも適用性を高めている。
- 従来のRAGの各モジュールの追加・置き換え
- 非連鎖的な構造（逐次処理だけではない再帰的な処理プロセスを含む）
新しいモジュール
モジュール一覧
| モジュール名 | 目的と機能 |
|---|---|
| Search（検索） | 検索エンジン、データベース、ナレッジグラフなどの多様なデータソースにわたる直接検索を可能にし、LLMが生成したコードやクエリ言語を使用する。 |
| RAG-Fusion | ユーザーのクエリを多様な視点に拡張するマルチクエリ戦略を採用し、並列ベクトル検索とインテリジェントな再ランキングを利用して、従来の検索の制限に対処する。 |
| Memory（メモリ） | LLMのメモリを活用して検索を導き、無制限のメモリプールを作成し、反復的な自己強化を通じてテキストをデータ分布にさらに密接に整合させる。 |
| Routing（ルーティング） | 多様なデータソース間をナビゲートし、クエリに最適な経路を選択する（要約、特定のデータベース検索、または異なる情報ストリームの統合など）。 |
| Predict（予測） | LLMを介してコンテキストを直接生成することで、冗長性とノイズの削減を目指し、関連性と正確性を確保する。 |
| Task Adapter（タスクアダプター） | RAGをさまざまな下流タスクに合わせて調整し、ゼロショット入力のプロンプト検索を自動化したり、フューショットクエリ生成を通じてタスク固有のリトリーバーを作成する。 |
新しい（処理）パターン
処理パターン一覧
| パターン名 | 概要/機能 |
|---|---|
| Rewrite-Retrieve-Read (RRR) | LLMの能力を活用し、書き換えモジュールとLMフィードバックメカニズムを通じて検索クエリを洗練させることで、タスクのパフォーマンスを向上させる。 |
| Generate-Read | 従来の検索プロセスを、LLMによって直接生成されたコンテンツに置き換える。 |
| Recite-Read | モデルの重みからの検索（retrieval from model weights）に焦点を当て、知識集約的なタスクを処理するモデルの能力を強化する。 |
| ハイブリッド検索 | キーワード検索・セマンティック検索・ベクトル検索を統合して多様なクエリに対応 |
| Hypothetical Document Embeddings(HyDE） | サブクエリと仮想文書を埋め込み、検索のア関連性を向上する |
| Demonstrate-Search-Predict (DSP) /ITER-RETGEN | モジュールの配置と相互作用を調整するフレームワークの一例。 |
| FLARE/Self-RAG | 様々なシナリオに基づいて検索の必要性を評価 |
RAGとファインチューニング
RAG は、正確な情報検索タスクに最適。対照的に、ファインチューニングは、特定の構造、スタイル、形式の複製が必要なシナリオに適している。
3. 検索
検索元
RAGは外部の知識に依存してLLMを強化するが、検索源の種類や検索ユニットの粒度は最終生成結果に影響を与える。
データ構造はテキストから半構造化データ（PDF）、構造化データ（ナレッジグラフ）へと拡大・拡張されてきている。
LLMの内部知識を活用した検索強化も研究されている
検索粒度が粗いと、問題に対してより関連性の高い情報を提供できるが冗長なコンテンツを含み、
下流のタスクにおける検索器や言語モデルの処理を阻害する可能性がある。
一方、検索粒度を細かくすると検索の負担が増大し、意味的整合性や必要な知識の充足が保証されない。
インデックス最適化
インデックス化フェーズでは、文書が処理・分割され、ベクターデータベースに保存される埋め込みデータに変換される。
インデックス構築の質は、検索段階で正しい文脈が得られるかどうかを決定する。
チャンキング戦略・メタデータを添付したファイルなどが手法として挙げられる。
文章の階層構造を持たせることも効果的。
クエリ最適化
Naive RAGの課題の一つとして、検索の元がユーザーのクエリに依存していることにある。
質問の言葉遣いが整理されていなかったり、専門的な語彙や複数の意味を持つ曖昧な略語を扱う場合に検索がうまくいかないことがある。
クエリ拡張（マルチクエリ/サブクエリ）により単一クエリを拡張することで、特定のニュアンスが欠けているとき、それを補うためのさらなる文脈が得られる。
クエリ変換によりユーザーの元のクエリではなく、変換されたクエリに基づいてチャンクを取得する。手法としてはLLMを用いたり、小規模な言語モデル（RRRなど）を活用する方法がある。
様々なクエリに基づいて、それぞれに適したRAGパイプラインへのルーティングを行うクエリルーティングの手法もある。
埋め込み
RAGでは、検索は質問とドキュメントチャンクの埋め込み間の類似度(例:コサイン類似度)を計算することで実現され、埋め込みモデルの意味表現能力が重要な役割を果たす。
モデルを組み合わせる、混合/ハイブリッド検索や、専門用語などの多い分野については、独自ドメインデータセットにより追加学習したファインチューニング埋め込みモデルの使用も必要となる。
アダプタ
モデルのファインチューニングは、APIを通じた機能統合や限られたローカル計算資源による制約の解決など、課題を伴う場合がある。そのため、アライメントを助けるために外部アダプターを組み込む方法もある。
生成
検索結果をすべて直接LLMに入力するのは良い方法ではない。よって、コンテキスト調整とLLMの調整の２つの観点の調整方法が紹介されている。
コンテキスト調整
- リランキング:文章チャンクを重要順に並び変える。（MRRなどの指標に基づいたルールベース,SpanBERTの様な専門モデル,GPTの様な大規模モデルを使う方法がある）
- コンテキスト選択/圧縮：SLMを用いて不要なトークンを検出・削除する、SLMとLLMを用いて文書数を減らすFilter-Rerankerなどがある。最終回答を生成する前にLLMが取得した内容を評価するというChatlawという手法もある。
LLMの調整
LLMに特定のドメインのデータが不足している場合、ファインチューニングによってLLMに追加の知識を提供できる。
ファインチューニングのもう一つの利点は、モデルの入力と出力を調整できる点にある。
例えば、LLMが特定のデータ形式に適応して、指示に従って特定のスタイルで応答を生成することが可能になる。
拡張
RAGにおいて1回の検索/生成のステップしか実行しないことは、限られた情報しか与えられないので数ステップの推論を必要とする複雑な問題には不十分な場合がある。
論文中では3種類の検索プロセスについて述べられていた。
図：検索プロセスの最適化例
反復検索
反復検索では、検索と生成を交互に行うことで、各ステップで知識ベースからより豊富で的を絞ったコンテキストを取得できる。
再帰検索
再帰検索では、ユーザークエリを徐々に絞り込み、問題をサブ問題に分解し、検索と生成を通じて複雑な問題を継続的に解決できる。
適応型検索
適応検索では、RAGシステムが外部知識検索が必要かどうか、また検索と生成をいつ停止するかを自律的に判断できるようにすることに重点を置いている。
タスクと評価
タスク
メインとしては質問応答タスク（QA）があるが、情報抽出（IE）、対話生成、コード検索など、複数の下流タスクへと継続的に拡張されている。
## 評価
主な評価対象は
- 検索品質（ヒット率、MRR、NDCGなどの指標）
- 生成品質（ラベルなしコンテンツの場合：生成された回答の忠実性、関連性、および無害性が評価の対象となる。一方、ラベル付きコンテンツの場合、モデルによって生成された情報の正確性に焦点が当てられる）
品質スコア
| 評価項目 | 品質対象 | 定義と目的 |
|---|---|---|
| コンテキストの関連性 (Context Relevance) | 検索の品質 | 取得されたコンテキストの精度と特異性を評価し、無関係なコンテンツに関連する処理コストを最小限に抑える。 |
| 回答の忠実性 (Answer Faithfulness) | 生成の品質 | 生成された回答が、取得されたコンテキストに忠実であり続け、一貫性を保ち、矛盾を避けることを保証する。 |
| 回答の関連性 (Answer Relevance) | 生成の品質 | 生成された回答が、提示された質問に直接関連していおり、コアの質問に効果的に対処していることを確認する。 |
必要な能力
| 評価項目 | 品質対象 | 定義と目的 |
|---|---|---|
| ノイズロバスト性 (Noise Robustness) | 検索の品質 | 質問に関連しているものの実質的な情報を含まないノイズ文書を管理するモデルの能力を評価する。 |
| ネガティブ拒否 (Negative Rejection) | 生成の品質 | 取得された文書が質問に回答するために必要な知識を含んでいない場合に、応答を控えるモデルの識別力を評価する。 |
| 情報統合 (Information Integration) | 生成の品質 | 複数の文書から情報を合成し、複雑な質問に対処するモデルの熟練度を評価する。 |
| 反事実ロバスト性 (Counterfactual Robustness) | 生成の品質 | 文書内の既知の**不正確さ（誤情報）**を認識し、無視するモデルの能力をテストする。 |
### 評価のベンチマークとツール
| 評価フレームワーク | 種別 | 評価ターゲット | 主要な評価側面 |
|---|---|---|---|
| RGB | ベンチマーク | 検索品質、生成品質 | ノイズロバスト性、ネガティブ拒否、情報統合、反事実ロバスト性 |
| RECALL | ベンチマーク | 生成品質 | 反事実ロバスト性 |
| CRUD | ベンチマーク | 検索品質、生成品質 | 創造的生成、知識集約型QA、エラー訂正、要約 |
| RAGAS | ツール | 検索品質、生成品質 | コンテキストの関連性、忠実性、回答の関連性 |
| ARES | ツール | 検索品質、生成品質 | コンテキストの関連性、忠実性、回答の関連性 |
| TruLens | ツール | 検索品質、生成品質 | コンテキストの関連性、忠実性、回答の関連性 |
議論と将来の展望
RAG vs ロングコンテキスト
ロングコンテキストが飛躍的に伸びている中で、RAGの必要性が問われている。しかし、ロングコンテキストは推論速度に時間がかかり、RAGの場合は提供情報のトレーサビリティが得られるため依然として不可欠な技術である。
RAGのロバスト性
検索プロセスにノイズ文書や矛盾した情報が含まれると、出力品質が著しく低下するため、敵対的または反事実的な入力に対する耐性向上が主要な課題である。ただ、ノイズ文書を入れたことで精度向上が見られた事例もあり、さらなる研究が必要。
ハイブリッドアプローチ
RAGとファインチューニング（FT）を組み合わせる戦略が主流となってきており、逐次的、交代的、またはエンドツーエンドの結合訓練などの最適な統合方法が研究されている。
特定の機能を持つ小型言語モデル（SLM）をRAGシステムに組み込み、出力を基にFTを行う傾向も見られる。
RAGのスケーリング法則
LLMとは異なり、RAGモデルにおけるスケーリング法則の適用可能性は未確立。モデルサイズと性能の関係に関する調査が必要。
実運用に備えたRAG:
実運用環境では、検索効率の向上、大規模知識ベースにおける文書再現率の改善が求められる。
データセキュリティの確保も重要であり、LLMによるソースやメタデータの意図しない開示を防ぐエンジニアリング課題が残されている。
LangChainやLLamaIndexなどのツール、WeaviateのVerbaやAmazonのKendraの様なRAGサービスも存在する。
RAG技術の開発においては、以下の要素が必要となる。
- カスタマイズ - 特定の要件に合わせてRAGをカスタマイズする。
- 簡素化 - RAGを使いやすくすることで、初期の学習曲線を短縮する。
- 特化 - RAGを最適化し、本番環境により適したサービスを提供する
図：RAGエコシステム概要
マルチモーダルRAG
RAGはテキストの枠を超え、**画像、音声と動画、コードなど多様なモーダルデータを外部知識として取り込む方向へ進化している。
これにより、革新的なマルチモーダルモデルの創出が期待される。
最後に
最後のRAGエコシステムに関するところで、記事執筆時点の2025/11だとRAG構築のツールとしてはGoogleのFile Search ToolやLangGraphを活用したAgentic RAGなどが新規に参画しているイメージ。
ただ、必要な技術要素や全体像の理解や評価の観点については本論文の内容が助けとなった。
リンク