3つのRAGパラダイム — Gao et al.サーベイの整理
RAGを体系的に理解するには、 Gao et al. (2023) のサーベイ論文 で提示された「Naive / Advanced / Modular」の3パラダイム分類を押さえるのが最短です。 これはRAG設計者の共通言語として広く使われています。
| パラダイム | 構成 | 思想 | 限界 |
|---|---|---|---|
| Naive RAG | Indexing → Retrieve → Generate の直列 | とりあえず検索して投入する単純パイプライン | Low Precision/Recall、冗長・矛盾、Lost-in-the-middle |
| Advanced RAG | Pre-retrieval + Post-retrieval最適化を追加 | 検索の前後に最適化層を差し込む | パイプライン固定で柔軟性に欠ける |
| Modular RAG | Search/Memory/Fusion/Routing/Predict をLEGO的組替 | パターン(Rewrite-Retrieve-Read、DSP、RAG-Fusion等)を柔軟構成 | 設計複雑度・運用コストが上がる |
graph LR
subgraph Naive[Naive RAG]
N1[Indexing] --> N2[Retrieve] --> N3[Generate]
end
subgraph Advanced[Advanced RAG]
A1[Indexing] --> A2[Pre-Retrieval\n Query変換]
A2 --> A3[Retrieve]
A3 --> A4[Post-Retrieval\n Rerank・圧縮]
A4 --> A5[Generate]
end
subgraph Modular[Modular RAG]
M1[Router]
M2[Search Module]
M3[Memory Module]
M4[Fusion Module]
M5[Predict Module]
M1 --> M2
M2 --> M4
M3 --> M4
M4 --> M5
M5 -.-> M1
end
style N3 fill:#8b5cf6,stroke:#6d28d9,color:#fff
style A5 fill:#f97316,stroke:#ea580c,color:#fff
style M5 fill:#14b8a6,stroke:#0d9488,color:#fff設計思想の変遷は「検索→生成の線形処理」から「検索と生成の反復・協調」へ。 2024年以降のSelf-RAG、CRAG、Agentic RAGはこの延長線上にあり、LLM自身が検索の必要性や品質を判断するModular以降の進化形です(第9章で詳説)。
Chunking戦略 — RAG品質の7割を決める工程
文書をベクトル化する前のChunking(分割)は、RAG品質に最も大きな影響を与える工程です。 「RAGで精度が出ない」の相談の半分以上はChunking設計の問題です。
| 戦略 | 手法 | 長所 | 短所 | 適合ケース |
|---|---|---|---|---|
| Fixed-size | 固定トークン数で分割 | 実装最速・予測可能 | 文や意味を分断 | 均質テキスト、試作 |
| Recursive | 段落→文→句で再帰分割 | 自然な境界、バランス◎ | 意味境界は拾えない | 汎用・デフォルト推奨 |
| Semantic | 文埋め込みの類似度で境界検出 | 意味単位、精度最大+70% | 閾値チューニング必要 | 長文・多トピック |
| Structure-aware | Markdown見出し・HTML/AST | 構造情報を保持 | 非構造化では機能しない | 技術文書・API docs |
| Contextual | LLMで文脈プレフィックスを付与 | 失敗率最大49%削減 | LLMコスト(キャッシュで緩和) | 企業ナレッジ・法務 |
| Late Chunking | 長文脈モデルで全体埋め込み→後分割 | 文脈情報を保持 | 長文脈モデル必須 | 論文・長文技術書 |
Recursiveから始めるのが鉄板
PoCや汎用システムなら、LangChain標準のRecursiveCharacterTextSplitterでchunk_size=512, overlap=50〜100が出発点として最強です。
2026年のChunking戦略ベンチマーク(PremAI)でも、Recursive 512 tokens が精度69%と最高スコアでした。
from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=100,
length_function=len,
# 日本語向けに区切り文字を調整
separators=["\n## ", "\n### ", "\n\n", "\n", "。", "、", " ", ""],
)
chunks = splitter.split_documents(docs) 日本語Chunkingの特殊事情
日本語は分かち書きなしなので、単純な文字数スライスでは意味の途中でチャンクが切れます。 形態素解析器(MeCab / Sudachi)を使って語境界を尊重する前処理が必須です。 特にSudachiは3分割単位(A/B/C)に対応し、固有名詞や最新語に強いため、日本語RAGで第一候補となります。
Query変換 — 曖昧なクエリを検索に最適化する
ユーザーが入力するクエリは曖昧・口語的・語彙ミスマッチが多く、そのままでは文書チャンクの表現と一致しません。 これを埋めるQuery変換が、Advanced RAGの中核技術です。
HyDE — 仮想の答えを埋め込む
HyDE(Hypothetical Document Embeddings)は、クエリからLLMで「仮想的な答え」を生成し、 その答えを埋め込んで検索する手法です。質問と回答の表現分布のギャップ(Query-Document asymmetry)を埋め、 ゼロショット性能を大きく引き上げます。
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
# クエリから仮想回答を生成
prompt = ChatPromptTemplate.from_template(
"次の質問に対する仮想的な回答を簡潔に書いて。\n質問: {query}"
)
llm = ChatOpenAI(model="gpt-4o-mini")
hypo_answer = (prompt | llm).invoke({"query": "RAGのChunk sizeはいくつが良い?"})
# 仮想回答を埋め込んで検索
hypo_embedding = embed_model.embed_query(hypo_answer.content)
results = vectorstore.similarity_search_by_vector(hypo_embedding, k=4) Multi-query — 複数視点への書き換え
1つのクエリから複数の言い換えをLLMで生成し、それぞれ検索して結果をRRF(Reciprocal Rank Fusion)で融合します。 Recallが向上し、語彙多様性に強くなります。検索回数がN倍になるコストと引き換えです。
Step-back Prompting — 抽象化して検索
Google DeepMindが提唱した手法で、具体的な質問を抽象化・上位概念化した「ステップバック質問」を生成し、 前提知識を先に取得してから元のクエリを解く手法です。推論誤りを21.6%削減した実績があります。
Query Decomposition — 多段質問を分解
「X社の2023年売上と2024年売上の差は?」のようなMulti-hop質問を、独立サブクエリ(「X社の2023年売上」「X社の2024年売上」)に分解して逐次/並列解決します。 LangGraphやHaystackに実装例があります。
Pre-retrievalとPost-retrieval最適化の全体像
graph TD Q[ユーザークエリ] --> PreR[Pre-Retrieval最適化] PreR --> QR[Query Rewriting] PreR --> HyDE[HyDE] PreR --> MQ[Multi-query] PreR --> SB[Step-back] QR --> R[Retrieval\n Hybrid検索] HyDE --> R MQ --> R SB --> R R --> PostR[Post-Retrieval最適化] PostR --> Rerank[Cross-encoder Rerank] PostR --> Compress[Context Compression] PostR --> Filter[Metadata Filter] Rerank --> Gen[LLM Generation] Compress --> Gen Filter --> Gen style R fill:#8b5cf6,stroke:#6d28d9,color:#fff style Gen fill:#14b8a6,stroke:#0d9488,color:#fff
Modular RAG — モジュール組替で反復可能に
Modular RAGは、従来の直列パイプラインをばらして「Search / Memory / Fusion / Routing / Predict」といったモジュールに分解し、 タスクに応じてLEGO的に組み合わせる設計思想です。 2024年以降に普及したLangGraphはこのModular RAGの実装基盤として広く使われています。
代表的なパターンとして:
- Rewrite-Retrieve-Read: クエリ書換 → 検索 → 読解(RRR)
- RAG-Fusion: Multi-query → 複数検索 → RRF融合 → 生成
- DSP (Demonstrate-Search-Predict): Few-shotデモンストレーション → 検索 → 予測
- Agentic RAG: エージェントが動的にツール選択・反復検索(第9章で詳説)
フレームワーク選定 — LlamaIndex vs LangChain vs Haystack
| フレームワーク | 得意 | 本番化期間 | オーバーヘッド |
|---|---|---|---|
| LlamaIndex | 純粋RAG、データ取込・インデックス | 2-3日 | ~6ms/query |
| LangChain | エージェント・ツール連携、統合豊富 | 2-3週間 | ~10ms/query |
| LangGraph | ステートフル・マルチステップ | 中 | ~14ms/query |
| Haystack | 本番NLPパイプライン、ハイブリッド検索 | 1週間 | ~5.9ms/query(最速級) |
| DSPy | プロンプト最適化、研究系 | 短 | ~3.5ms/query |
| Vercel AI SDK | Web/Next.js統合 | 即日 | - |
次章への導線
ここまでで、RAGパイプラインの基本骨格を押さえました。 次章では、精度を極限まで引き上げる2つの強力な技術 — ハイブリッド検索とRerank — を掘り下げます。 BM25とDenseの融合(RRF)、Cross-encoderによる再ランク、そしてAnthropicのContextual Retrieval(失敗率67%削減)の実装まで詳説します。
理解度チェック
Gao et al. (2023) のサーベイで整理された3つのRAGパラダイムとして正しい組み合わせはどれですか?
キーボード: 1〜4 で選択、Enter で回答