ストーリー
田
田中VPoE
RAGの基本概念を理解したところで、次はRAGアーキテクチャの進化を見ていこう。RAGも登場から数年で大きく進化している
あなた
最初のRAGと今のRAGでは、何が違うんですか？
あ
田
田中VPoE
一言でいえば「検索精度の追求」だ。単純に検索して渡すだけのNaive RAGから、検索前後に最適化プロセスを挟むAdvanced RAG、そしてモジュール単位で組み替えられるModular RAGへと進化している
あなた
どの段階のRAGを使えばいいんでしょうか？
あ
田
田中VPoE
ユースケース次第だ。社内FAQならNaive RAGで十分な場合もあるし、高精度な技術文書検索にはAdvanced RAGが必要だ。まず全体像を掴もう
Naive RAG
基本構成
最もシンプルなRAGアーキテクチャです。多くのRAGチュートリアルがこの形式を採用しています。
Naive RAGのアーキテクチャ:
[Indexing Phase]
ドキュメント → チャンキング → Embedding → ベクトルDB格納
[Query Phase]
ユーザーの質問 → Embedding → ベクトル検索 → Top-K取得 → プロンプト構築 → LLM → 回答Naive RAGの課題
| 課題 | 詳細 | 影響 |
|---|---|---|
| 検索精度の限界 | クエリとドキュメントの表現が異なると検索にヒットしない | 関連ドキュメントを見逃す |
| チャンクの品質 | 固定長分割ではコンテキストが途切れる | 不完全な情報でLLMが回答する |
| 冗長な検索結果 | Top-Kに重複・無関係な結果が含まれる | プロンプトのトークン浪費 |
| ハルシネーション | 検索結果が不十分だとLLMが推測で補完する | 誤った回答が生成される |
Advanced RAG
Pre-Retrieval最適化
検索前にクエリや入力を最適化するアプローチです。
Advanced RAG（Pre-Retrieval）:
ユーザーの質問
↓
[Pre-Retrieval]
├── Query Rewriting（クエリ書き換え）
├── Query Expansion（クエリ拡張）
├── HyDE（仮説的ドキュメント生成）
└── Step-back Prompting（抽象化クエリ）
↓
ベクトル検索
↓
LLM → 回答| 手法 | 概要 | 効果 |
|---|---|---|
| Query Rewriting | LLMがクエリを検索に適した形に書き換える | 検索ヒット率の向上 |
| Query Expansion | 同義語や関連語でクエリを拡張する | Recallの向上 |
| HyDE | LLMで仮の回答を生成し、それをクエリとして検索 | セマンティックギャップの解消 |
| Multi-Query | 複数の異なるクエリを生成して並列検索 | 多角的な検索結果の取得 |
Post-Retrieval最適化
検索後に結果を最適化するアプローチです。
Advanced RAG（Post-Retrieval）:
ベクトル検索結果（Top-K）
↓
[Post-Retrieval]
├── Reranking（再順位付け）
├── Compression（圧縮）
├── Filtering（フィルタリング）
└── Fusion（複数検索結果の統合）
↓
最適化されたコンテキスト
↓
LLM → 回答| 手法 | 概要 | 効果 |
|---|---|---|
| Reranking | Cross-Encoderで検索結果を再スコアリング | Precisionの大幅向上 |
| Compression | 検索結果から関連部分のみを抽出 | トークン効率の向上 |
| Reciprocal Rank Fusion | 複数検索手法の結果を統合 | 検索の多様性確保 |
| Contextual Compression | LLMでコンテキストを要約 | ノイズ除去 |
Modular RAG
コンセプト
RAGの各処理をモジュール化し、ユースケースに応じて自由に組み合わせるアーキテクチャです。
Modular RAGの構成要素:
[Indexing Modules]
├── Document Loader
├── Chunker（複数戦略から選択）
├── Embedder（モデル選択可能）
└── Index Builder
[Routing Modules]
├── Query Router（ドメイン別にルーティング）
├── Intent Classifier（意図分類）
└── Complexity Estimator（複雑度判定）
[Retrieval Modules]
├── Vector Search
├── Keyword Search（BM25）
├── Knowledge Graph Search
└── SQL Search
[Post-Processing Modules]
├── Reranker
├── Filter
├── Compressor
└── Validator
[Generation Modules]
├── Prompt Builder
├── LLM Selector
├── Output Parser
└── Citation Generator3つのアーキテクチャの比較
| 観点 | Naive RAG | Advanced RAG | Modular RAG |
|---|---|---|---|
| 実装難易度 | 低 | 中 | 高 |
| 検索精度 | 基本的 | 高い | 最も高い |
| カスタマイズ性 | 低い | 中程度 | 非常に高い |
| 開発コスト | 低 | 中 | 高 |
| 運用コスト | 低 | 中 | 高（モジュール数に比例） |
| 適するケース | PoC、シンプルなFAQ | 本番システム | 大規模・高精度要件 |
| レイテンシ | 低 | 中（前後処理追加） | 可変（パイプライン構成次第） |
RAGアーキテクチャの選定基準
| 要件 | 推奨アーキテクチャ | 理由 |
|---|---|---|
| PoCで素早く検証したい | Naive RAG | 最小構成で動作確認可能 |
| 社内FAQ（精度要件: 中） | Naive RAG + Reranking | コスト効率とのバランス |
| 技術文書検索（精度要件: 高） | Advanced RAG | Pre/Post最適化で精度向上 |
| マルチドメイン対応 | Modular RAG | ドメイン別のルーティングが必要 |
| 規制対応（金融・医療） | Advanced/Modular RAG | 高精度 + 根拠の追跡が必要 |
「最初からModular RAGを目指す必要はない。Naive RAGで始めて、ボトルネックが見えたらAdvanced RAGに進化させる。段階的に成長させるのがプロの仕事だ」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|---|
| Naive RAG | シンプルな検索+生成。PoCや低精度要件向け |
| Advanced RAG | Pre/Post-Retrieval最適化で精度向上。本番システム向け |
| Modular RAG | モジュール化により高いカスタマイズ性。大規模・高精度要件向け |
| 選定基準 | 精度要件、コスト、開発リソースのバランスで判断 |
チェックリスト
- Naive RAGの基本構成と課題を理解した
- Advanced RAGのPre/Post-Retrieval最適化手法を説明できる
- Modular RAGのモジュール構成を理解した
- 要件に応じたアーキテクチャ選定基準を理解した
次のステップへ
次は「Embeddingの基礎」を学びます。テキストをベクトルに変換する仕組みと、Embeddingモデルの選び方を理解しましょう。
推定読了時間: 30分