Advanced RAGの全体像
ナイーブなチャンク分割+類似検索だけでは解けない問題があります。 「この報告書群の主要テーマは?」といったグローバル質問、複数チャンクに跨るMulti-hop推論、 知識ベースにない情報への対応、低品質検索結果への自己修正 — これらに答えるのがAdvanced RAGです。
graph LR A[Naive RAG] --> B[Structural Patterns\n Parent-Child\n Sentence-Window\n Auto-Merging] B --> C[Knowledge Graph RAG\n GraphRAG\n LightRAG] C --> D[Self-reflective RAG\n Self-RAG\n CRAG] D --> E[Agentic RAG\n LangGraph\n MCP連携] style A fill:#3b82f6,stroke:#1d4ed8,color:#fff style B fill:#8b5cf6,stroke:#6d28d9,color:#fff style C fill:#f97316,stroke:#ea580c,color:#fff style D fill:#ec4899,stroke:#be185d,color:#fff style E fill:#14b8a6,stroke:#0d9488,color:#fff
構造パターン — Parent-Child / Sentence-Window / Auto-Merging
最も実装コストが低く、効果も大きいのが構造パターン群です。共通のアイデアは「小さいチャンクで検索し、大きいチャンクで生成する」。 埋め込みは短文で精度を出しやすく、LLMには周辺文脈込みで渡した方が回答品質が上がる、という非対称性を活用します。
| パターン | 仕組み | 解決する問題 |
|---|---|---|
| Parent-Child | 小chunk(128-256)で検索→ヒット時に親chunk(1024-2048)をLLMへ | 埋め込み精度と文脈豊富さを両立 |
| Sentence-Window | 文単位で検索→前後N文を窓として付加 | ピンポイント検索+文脈保持 |
| Auto-Merging | 階層ノード(2048→512→128)の葉を検索、同一親下の葉が閾値超えで親に自動マージ | 断片化chunkの動的統合 |
# LlamaIndexでのAuto-Merging例
from llama_index.core.node_parser import HierarchicalNodeParser
from llama_index.core.retrievers import AutoMergingRetriever
parser = HierarchicalNodeParser.from_defaults(chunk_sizes=[2048, 512, 128])
nodes = parser.get_nodes_from_documents(docs)
# 葉chunkで検索 → 同一親下で複数ヒットしたら親にマージ
base_retriever = index.as_retriever(similarity_top_k=12)
retriever = AutoMergingRetriever(base_retriever, storage_context, verbose=True)
results = retriever.retrieve("HNSWのefパラメータについて教えて") Microsoft GraphRAG — グローバル質問の本命
GraphRAG(Microsoft Research, 2024年2月) は、従来RAGでは答えられなかった「この文書群の主要テーマは?」といったグローバル・センスメイキング質問を解くために設計された手法です。
6段階パイプライン
- Chunking: 固定長(例: 600 token)で分割
- エンティティ・関係抽出: 各chunkをLLMに投入し
(entity, type, description)と(source, target, relation)を抽出 - 要素サマライゼーション: 同一エンティティ・関係のdescriptionをLLMで統合要約
- Knowledge Graph構築: NetworkX等でグラフ化
- Leidenコミュニティ検出: 階層的にコミュニティ分割(Level 0=全体、Level 1/2/3 と細分化)
- コミュニティ要約事前生成: 各コミュニティのエンティティ・関係をLLMに渡してレポート生成
3つの検索モード
| 検索モード | 用途 | 仕組み |
|---|---|---|
| Global Search | マクロ質問(主要テーマは?) | 全コミュニティレポートをmap-reduceでLLMに投入 |
| Local Search | 特定事実型QA | エンティティ検索→近傍サブグラフ→元テキスト集約 |
| DRIFT Search (2024/10追加) | ハイブリッド推論 | Local精度 + Global広さ、dynamic query expansion |
LightRAG — 6000倍のトークン効率化
LightRAG(HKU, EMNLP 2025) はGraphRAGの重量級コストを解決する改善版として登場しました。
| 項目 | GraphRAG | LightRAG |
|---|---|---|
| クエリ時API call | 数百 | 1 |
| Retrieval tokens (Legal実測) | 約610,000 | < 100(約6000倍効率) |
| Incremental update | 約14M tokens(ほぼ全体再構築) | 差分のみ |
| 検索粒度 | Global/Local/DRIFTの排他選択 | Dual-level (low+high)を併用 |
| レイテンシ | 数秒〜数十秒 | ~80ms(retrieval部分) |
LightRAGはDual-Level Retrievalが核心で、LLMに2種類のキーワードを同時生成させます:
- Low-level keyword: 特定エンティティ・属性ベース
- High-level keyword: テーマ・概念ベース
それぞれをベクトルDBで検索し、該当するnode/edgeと近傍サブグラフをmergeします。 GraphRAG的な恩恵を残しつつ、運用コストを劇的に下げた設計です。
軽量実装エコシステム
| 実装 | 特徴 | 用途 |
|---|---|---|
| microsoft/graphrag | 公式、NetworkX、Parquet中心 | 本番向け重量級 |
| nano-graphrag | 約1,100行、NetworkX/Neo4j切替可 | 研究・検証・カスタマイズ |
| graphrag-local-ollama | 公式をOllama対応にフォーク | 完全ローカル運用 |
| GraphRAG-Local-UI | WebUI(indexing/chat)付き | オフライン実験環境 |
| LightRAG | HKU公式、プロダクション志向 | 本番・低コスト |
Self-RAG / CRAG — 検索要否と品質を自己判断
Self-RAG(Asai et al., UW/AllenAI, 2023年10月) は、LLMに反射トークン(reflection tokens)を学習させ、 「いま検索すべきか?」「検索結果は役に立つか?」「生成文は根拠に忠実か?」を自律判定させる手法です。
Corrective RAG(CRAG, 2024年1月) は、検索結果の品質をLLMで評価し、低品質ならWeb再検索やクエリ書換でフォールバックする補正機構です。 「検索が失敗したときの回復」を明示的にパイプラインに組み込みます。
graph TD
Q[クエリ] --> D1{検索が必要?\n Self-RAG}
D1 -->|不要| Gen1[直接生成]
D1 -->|必要| R[検索実行]
R --> D2{結果は良質?\n CRAG}
D2 -->|良質| Gen2[根拠付き生成]
D2 -->|不十分| QR[クエリ書換]
D2 -->|無関係| WS[Web検索]
QR --> R
WS --> Gen2
Gen2 --> D3{回答は根拠に忠実?\n Self-RAG}
D3 -->|忠実| A[最終回答]
D3 -->|怪しい| R
style D1 fill:#f97316,stroke:#ea580c,color:#fff
style D2 fill:#ec4899,stroke:#be185d,color:#fff
style D3 fill:#14b8a6,stroke:#0d9488,color:#fffAgentic RAG — エージェントが動的にツールを組み立てる
2026年のRAGの本命はAgentic RAGです。従来の静的パイプラインではなく、 LLMエージェントが「どのツール(検索、計算、Web取得、KG辿り)を、いつ、どう使うか」を動的に判断します。
実装基盤としてLangGraphが主流で、ステートフルなマルチステップ推論を有向グラフで記述できます。
# LangGraphでのAgentic RAG骨格
from langgraph.graph import StateGraph, END
from langchain_openai import ChatOpenAI
def retrieve(state):
docs = hybrid_search(state["query"])
return {"contexts": docs}
def grade(state):
# 検索結果の品質をLLMでスコアリング
quality = llm.invoke(grading_prompt(state))
return {"quality": quality}
def rewrite(state):
# 品質低なら書き換え
new_q = llm.invoke(rewrite_prompt(state["query"]))
return {"query": new_q}
def generate(state):
return {"answer": llm.invoke(gen_prompt(state))}
graph = StateGraph(RAGState)
graph.add_node("retrieve", retrieve)
graph.add_node("grade", grade)
graph.add_node("rewrite", rewrite)
graph.add_node("generate", generate)
graph.add_conditional_edges(
"grade",
lambda s: "rewrite" if s["quality"] < 0.7 else "generate",
)
graph.add_edge("rewrite", "retrieve")
app = graph.compile() MCP連携 — RAGがツールになる時代
2025年に標準化が進んだModel Context Protocol (MCP)により、 RAGシステム自体がLLMエージェントから呼び出せるツール(MCPサーバ)として公開される時代になりました。
これにより、Claude Desktop・ChatGPT Desktop・Cursor・Claude Code等から、 社内の知識ベースや専門DBをMCP経由でツール利用できます。 「RAGを組み込む」から「RAGをMCPサーバとして公開し、クライアントがエージェントとして使う」への転換が起きています。
どの高度パターンを採用すべきか
| 要件 | 推奨パターン | 理由 |
|---|---|---|
| 単純FAQ・数千ドキュメント | Naive + Hybrid | 過剰設計を避ける |
| 埋め込み精度と文脈を両立 | Parent-Child / Auto-Merging | 低コストで効果大 |
| Multi-hop QA | GraphRAG / LightRAG | 関係性を明示的に辿れる |
| グローバル質問(主要テーマ) | GraphRAG Global Search | コミュニティ要約が真価 |
| 検索失敗への耐性 | CRAG | Web fallback・書換 |
| 動的ツール選択・マルチステップ推論 | Agentic RAG (LangGraph) | 柔軟性最大 |
| コスト制約厳しい・高頻度更新 | LightRAG | トークン効率6000倍 |
| AI Agent統合 | MCP Server化 | エージェント時代の本流 |
次章への導線
最終章となる次章では、ここまで学んだ技術を実際のプロダクトとしてまとめ上げる本番運用の推奨スタック、 PerplexityやMorgan Stanley、Harveyなどの最新事例、 そして2026年以降の未来像(Multimodal RAG、Long-context論争、学習ロードマップ)を総括します。
理解度チェック
Microsoft GraphRAGで使われるコミュニティ検出アルゴリズムとして正しいものはどれですか?
キーボード: 1〜4 で選択、Enter で回答