7月29日、n8nが「RAG vs. Agentic RAG: Architecture, Tradeoffs, and When to Use Each」と題した記事を公開した。この記事では、従来のRAGとAgentic RAGのアーキテクチャ上の違い、トレードオフ、および使い分けの判断基準について詳しく解説されている。「新しいほうが優れている」という安易な結論を避け、それぞれの失敗パターンと適切なガードレール設計まで踏み込んでいる点が実務者にとって参考になる。
従来RAGの限界：1回の検索では足りないとき
従来のRAG（Retrieval-Augmented Generation）は、シンプルな直線パイプラインだ。クエリが来たら外部ナレッジソースから関連チャンクを1回取得し、そのままLLMに渡して回答を生成する。ステートレスで、ループしない。
このシンプルさは強みでもある。レイテンシが予測しやすく、インフラも最小限（ベクトルDB、埋め込みモデル、リトリーバー）で済む。FAQへの回答など、「1つのソースから1回の検索で答えが出る」クエリには最適解だ。
ただし、以下の3つの失敗パターンが繰り返し現れる：
- マルチホップ質問への対応不能：「SOC 2監査の後にオンボードしたベンダーは？」という質問には、監査日時を記録した文書とベンダーリストの2つが必要だが、1回の検索では一方しか取れない。
- 語彙の不一致：ユーザーが「time off（休暇）」と書いても、ドキュメントが「paid leave（有給休暇）」と表記していれば、セマンティック検索でも見逃す可能性がある。
- チャンク境界による証拠の分断：回答が2チャンクにまたがっているとき、片方しか取得できなければ、モデルは欠けた部分を「もっともらしい嘘」で埋める。
これらはいずれも「検索が1回しか走らない」という構造的制約から来ており、プロンプトの工夫やモデルの強化だけでは根本的に解消できない。
Agentic RAGの本質：検索を「制御ループ」に変える
Agentic RAGは、LLMにツール群と「どのツールをどう使うか」の決定権を与えたものだ。従来RAGが「このクエリにマッチするチャンクはどれか？」と問うのに対し、RAGエージェントは「この質問に答えるために何が必要で、どのツールで取得できるか？」を問う。
この違いが、検索を1ステップから制御ループに変える。エージェントは取得・読解・評価・次アクション決定（クエリの再構成、別ソースへの切り替え、API呼び出し、または回答）を繰り返す。これはいわゆるReActパターン（Reason → Act → Observe → Repeat）の実装だ。ReActはWei et al. (2023) の論文で提案された手法で、言語モデルに「推論と行動の交互ループ」を与えることで複雑なタスクに対処させる。
先ほどのSOC 2の例で言えば、エージェントはまず監査日時を取得し、次にベンダーリストが別ソースに必要だと判断して2回目の検索を実行し、両者を統合して回答する。
エージェントが従来RAGと本質的に異なる3つの能力がある：
- 分解とプランニング：複合的な質問をサブクエリに分割し、順次処理する。各結果が次の検索に活きる。
- 自己評価とクエリ再構成：検索結果が薄ければ、クエリを書き直して再試行する。弱いコンテキストから無理に答えを絞り出さない。
- 適応的なルーティング：価格に関する質問はSQLデータベースへ、ポリシーはベクトルストアへ、リアルタイム情報はWeb検索へ。クエリの種類に応じてソースを選ぶ。
どちらを選ぶか：判断の実際
記事は「新しい方が優れている」という議論を明確に否定する。これはアーキテクチャのトレードオフであり、世代交代ではない。
| 判断軸 | 従来RAG | Agentic RAG |
|---|---|---|
| クエリの性質 | 単一ソース、明確な質問 | 複数ソース横断、曖昧な質問 |
| レイテンシ要件 | 厳格 | 許容できる |
| 幻覚の許容度 | ある程度許容 | 許容不可（人間へのエスカレーションが必要） |
記事が示す実際的な判断基準は次の通りだ：
従来RAGを選ぶとき
- 単一ソースのルックアップ、FAQ、1チャンクで完結する参照
- レイテンシがハードな制約
- ナレッジベースが安定していて、よく整備されている
- コストとインフラの複雑さを最小限に抑えたい
Agentic RAGを選ぶとき
- ログ・ドキュメント・APIをまたぐ回答が必要
- ユーザーが曖昧なクエリを送ってくる
- 誤回答が許容されず、根拠不足なら「わかりません」と言える必要がある
- クエリの種類によってルーティング先を動的に変えたい
記事は「多くのチームが高い授業料を払ってこれを学ぶ」と指摘する。従来RAGから始めて限界にぶつかり、エージェント型フレームワークにスクラッチで移行するコストだ。最初の設計段階でユースケースを正確に見極めることが、後の移行コストを大きく左右する。
ガードレールの設計：2つのパターンで失敗箇所が異なる
両パターンはそれぞれ異なる箇所で壊れるため、ガードレールも別物になる。
従来RAG向け
- 検索スコープをユーザー権限に制限（クエリ時に強制、事後フィルタではない）
- セマンティック＋キーワードのハイブリッド検索でSKUやエラーコードの取りこぼしを防ぐ
- チャンクサイズと重複設定を一貫させ、証拠が境界で切れないようにする
ここで特に重要なのはハイブリッド検索の導入判断だ。セマンティック検索は意味の近さを捉える一方、固有名詞や型番など語彙が厳密に一致しなければならないケースではキーワード検索のほうが確実に機能する。両者の組み合わせは、従来RAGの語彙不一致問題を緩和する現実的な対策となる。
Agentic RAG向け
- ツールへのアクセスをアローリストで制限（プロンプトインジェクションで意図しないアクションが走るのを防ぐ）
- イテレーション数とトークンバジェットのハードキャップ（ループが収束しないまま課金が膨らむのを止める）
- ステップごとの実行履歴と分散トレーシングによる監査可能性の確保
Agentic RAGで見落とされがちなのは、ループが止まらないリスクだ。エージェントが「まだ情報が足りない」と判断し続けると、イテレーションが際限なく続いてトークンコストが急増する。イテレーション上限とトークンバジェットのハードキャップは、開発初期から必ず設定しておくべき設計上の要件といえる。また、複数ステップにわたる推論の追跡にはOpenTelemetryなどの分散トレーシング基盤が有効で、障害箇所の特定とデバッグを大幅に効率化できる。
詳細はRAG vs. Agentic RAG: Architecture, Tradeoffs, and When to Use Eachを参照していただきたい。
