RAG（検索拡張生成）（アールエージー（ケンサクカクチョウセイセイ））
RAG（Retrieval-Augmented Generation）は、外部知識ソースから関連情報を検索し、その結果をコンテキストとしてLLMに与えることで、事実に基づいた高精度な回答を生成するアーキテクチャパターンである。
RAGとは何か
RAG（Retrieval-Augmented Generation／検索拡張生成）は、大規模言語モデル（LLM）が持つパラメトリック知識だけに頼らず、外部のデータソースからリアルタイムに関連情報を取得し、その情報をプロンプトのコンテキストとして注入することで、正確かつ最新の応答を生成する手法である。2020年にMeta AI（旧Facebook AI Research）の Patrick Lewis らが発表した論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」で体系化され、以降LLMアプリケーション開発の標準的なアーキテクチャとして広く採用されている。
LLMは学習データのカットオフ日以降の情報を持たず、また学習時に記憶した事実を誤って出力する「ハルシネーション（幻覚）」の問題を抱えている。RAGはこれらの課題に対する実用的な解決策であり、モデル自体を再学習させることなく、外部知識を動的に参照できる点が最大の利点である。
RAGの基本アーキテクチャ
RAGシステムは大きく3つのフェーズで構成される。
| フェーズ | 処理内容 | 主要コンポーネント |
|---|---|---|
| Ingestion（取り込み） | ドキュメントの分割・埋め込み・インデックス化 | チャンカー、Embeddingモデル、ベクトルDB |
| Retrieval（検索） | ユーザークエリに関連するチャンクの取得 | クエリエンコーダ、類似度検索、リランカー |
| Generation（生成） | 取得した情報を基にLLMが回答を生成 | LLM、プロンプトテンプレート、後処理 |
Ingestionフェーズでは、PDF・Webページ・社内Wiki・データベースなどの非構造化データをテキストチャンクに分割し、各チャンクをEmbeddingモデル（BGE-M3、Voyage-3、OpenAI text-embedding-3-largeなど）でベクトル化してベクトルデータベースに格納する。
Retrievalフェーズでは、ユーザーの質問を同じEmbeddingモデルでベクトル化し、ベクトルDB内で最も類似度の高いチャンクをTop-K件取得する。さらにCross-Encoderなどのリランカーで精度を高めることが一般的である。
Generationフェーズでは、取得したチャンクをシステムプロンプトまたはユーザープロンプトに埋め込み、LLMに回答を生成させる。この際、「以下のコンテキストのみに基づいて回答してください」といった指示を加えることで、ハルシネーションを大幅に抑制できる。
RAGが解決する3つの課題
RAGは以下の3つの主要な課題を解決するために設計されている。
1. ハルシネーション（幻覚）の低減: LLM単体では、学習データに含まれない事実について「もっともらしいが誤った」回答を生成することがある。RAGは外部の信頼できるソースから事実を取得するため、回答の事実正確性が大幅に向上する。Meta AIの実験では、RAGの導入によりNatural Questions ベンチマークでの正解率が約15%向上したと報告されている。
2. 知識の鮮度: LLMの学習データにはカットオフ日が存在するため、最新の製品情報・法改正・技術動向などに対応できない。RAGは検索対象のデータベースを更新するだけで最新情報を反映できるため、モデルの再学習が不要である。
3. ドメイン特化知識の統合: 社内文書・医療記録・法律判例など、LLMの汎用学習データに含まれない専門領域の知識を、ファインチューニングなしで活用できる。これにより、企業固有のナレッジベースを活かした社内AIアシスタントなどの構築が容易になる。
RAGの進化形態
RAGの基本形（Naive RAG）から、より高度なアーキテクチャへと進化が続いている。
| 世代 | 特徴 | 代表的手法 |
|---|---|---|
| Naive RAG | 単純な検索→生成パイプライン | 基本的なベクトル検索 + LLM生成 |
| Advanced RAG | 前処理・後処理の最適化 | HyDE、Self-RAG、CRAG |
| Modular RAG | モジュール化・動的構成 | LangGraph、DSPy |
| Graph RAG | グラフ構造による関係性活用 | Microsoft GraphRAG、LightRAG |
Advanced RAGでは、クエリの書き換え（Query Rewriting）、仮説ドキュメント生成（HyDE）、検索結果の自己評価（Self-RAG）など、パイプラインの各段階を最適化する技術が導入されている。Graph RAGは、テキストからエンティティと関係性を抽出してナレッジグラフを構築し、グラフ検索とベクトル検索を組み合わせることで、複雑な推論を要する質問にも対応できる。
RAG vs ファインチューニング
| 比較項目 | RAG | ファインチューニング |
|---|---|---|
| 知識の更新 | データソース更新のみで即時反映 | 再学習が必要 |
| コスト | 推論時のトークン増加 | 学習コスト（GPU時間） |
| 出典の追跡 | チャンク単位で引用可能 | 不可能 |
| ドメイン適応 | 外部知識を注入するだけ | モデルの振る舞い自体を変更 |
| 幻覚リスク | 低い（ソースに基づく） | 中程度（学習データ依存） |
| レイテンシ | 検索ステップ分の遅延あり | 追加遅延なし |
実務では、RAGとファインチューニングは排他的ではなく、併用することが多い。ファインチューニングでモデルの出力スタイルや推論パターンを調整し、RAGで事実情報を補完するハイブリッドアプローチが最も効果的とされる。
よくある質問（FAQ）
Q: RAGはどのようなユースケースに最適ですか？ A: 社内ナレッジベース検索、カスタマーサポートBot、法律・医療などの専門分野QA、最新ニュースに基づく回答生成、技術ドキュメント検索など、正確性と最新性が求められるユースケースに最適である。逆に、創作・要約・翻訳など外部知識の参照が不要なタスクではRAGの恩恵は限定的である。
Q: RAGのコンテキストウィンドウの制約はどう対処しますか？ A: 取得チャンク数が多すぎるとコンテキストウィンドウを圧迫する。対策として、リランキングによるTop-K削減、チャンクの要約圧縮（LLMLingua等）、Long Contextモデル（Gemini 1.5 Proの100万トークン等）の活用がある。ただしLong Contextでも検索精度はRAGが優位であるという研究結果が報告されている。
Q: RAGの評価にはどのメトリクスを使いますか？ A: 主要な評価フレームワークとして RAGAS（Retrieval-Augmented Generation Assessment）がある。Faithfulness（忠実性）、Answer Relevancy（回答関連性）、Context Precision（コンテキスト精度）、Context Recall（コンテキスト再現率）の4指標で評価する。また、TruLensやDeepEvalも評価ツールとして広く使われている。