はじめに
RAGの精度を上げるのはとても難しいです。
その理由の一つに、RAGでは1回しかナレッジベースを検索できない、というものがあります。なのでプロンプトの改善やチャンク解析戦略の改善でどうにかするしかないのですが、それも試すのが難しい。
ということで、AgentにRAGを組み込ませる考え方が最近主流です。
AgenticRAGとは？
AI AgentのtoolとしてRAGを用意し、agentにRAGを「使わせる」設計です。
これにより、情報が不足していれば、検索方法を変えながら何度もナレッジベースを探索することができるようになります。
通常のRAG：
Agentic RAG：
開発方法
通常のAgent開発SDKに、RAGを組み込めば良いです。
例えばLangGraphでAgentを作るならこんな感じ。ナレッジベースだけでなくweb検索なども組み合わせられるのが良いですね。
root Agentic RAG (LangGraph Architecture)
│
├── 📂 State (グラフ内で共有されるデータ構造)
│ ├── 📝 input (ユーザーからの初期質問)
│ ├── 📝 chat_history (過去のやり取りの文脈)
│ ├── 📝 documents (検索されたチャンクのリスト)
│ ├── 📝 rewrite_query (再検索用に最適化されたクエリ)
│ └── 📝 grading_result (検索結果の適合性判定: Yes/No)
│
├── ⚙️ Nodes (各ステップの処理担当)
│ ├── 🔍 Question Rewriter (質問を検索に適した形に変換)
│ ├── 📥 Retriever (ベクトルDBから関連情報を取得)
│ ├── ⚖️ Doc Grader (取得した情報が「役に立つか」を検閲)
│ ├── ✍️ Generator (最終的な回答文を作成)
│ └── 🌐 Web Searcher (DBに情報がない場合の予備手段)
│
├── 🛣️ Edges & Routing (進行方向の制御)
│ ├── ➡ Normal Edge (次の処理へ直進)
│ └── 🔁 Conditional Edge (条件分岐)
│ ├── ❓ 有益な情報があるか？ → YESなら「回答生成」へ
│ └── ❓ 有益な情報がないか？ → NOなら「クエリ書き換え」へ戻る
│
└── 🛠️ Tools (外部リソースとの接続)
├── 📚 Vector Store (織田信長などの歴史ナレッジ)
└── 🔌 LLM API
arXiv
Agentic RAGのサーベイ論文
Knowledge GraphとAgentic RAGを組み合わせる論文