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
3つのRAGパラダイム: 線形処理のNaive、最適化層を追加したAdvanced、モジュール組替で反復可能なModular

設計思想の変遷は「検索→生成の線形処理」から「検索と生成の反復・協調」へ。 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標準のRecursiveCharacterTextSplitterchunk_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
Advanced RAGの全体像: Pre-Retrievalで検索を最適化し、Post-Retrievalで候補を精錬してからLLMに投入

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%削減)の実装まで詳説します。

理解度チェック

問題 0 / 50%
Q1

Gao et al. (2023) のサーベイで整理された3つのRAGパラダイムとして正しい組み合わせはどれですか?

キーボード: 1〜4 で選択、Enter で回答