前言

前面的文章我們介紹了各項RAG的架構，以及可以用來優化RAG的方法，但實務上基本的RAG，其實是會遇到許多瓶頸的! 例如檢索僅有單輪、複雜問題需要推理、或是背後資料量過大過複雜，有許多不同情境。

而隨著LLM越來越聰明，AI Agents技術越來越成熟，Agentic RAG這個架構就出現來協助突破傳統RAG的瓶頸了! 透過引入 AI Agents，使整個流程從靜態線性管道進化為 動態、具推理能力的自主系統，能分解複雜問題、執行多步驟檢索，並靈活使用工具，成為真正能解決問題的智能助手! 接下來我們就進一步了解一下到底什麼是Agentic RAG吧!

圖片來源:weaviate

🤖Agentic RAG 的核心原則

Agentic RAG 將AI Agent 嵌入到 RAG 管線中，使其能夠超越傳統RAG的靜態限制，並且能執行複雜的任務和多步驟推理，基本定義筆者整理如下幾點:

1. 由AI Agent驅動的 RAG 實作

• Agentic RAG 本質上是一種以 AI Agent為基礎的 RAG 實作
• 相當於一個配備了檢索能力的AI Agent

2. 目的與優勢
系統透過在 RAG 管線中添加 AI Agent來提高適應性與準確性，因此能克服傳統 RAG 固有的限制(後面我們會再仔細列出幾點)

3. 功能轉變
Agentic RAG 將 RAG 從一個固定的管線轉變為一個互動式、推理驅動的過程。

Agentic RAG 的關鍵在於 Agents 的能力，它們不只是檢索與生成，而是能自主規劃、判斷與行動。

組成元件

參考前面Weaviate上的Agentic RAG架構圖，大致上我們可以把組成分成:

• Retrieval Agent:
  • LLM (Reasoning Engine)：推理核心，解析查詢並決定行動，會搭配Agent flow去設計。
  • 記憶體 (Memory)：短期記錄上下文，長期累積知識與經驗。
  • 規劃 (Planning)：將複雜任務拆解成可執行的子任務。
• 工具 (Tools)：外部能力，例如向量資料庫檢索、網頁搜尋 API、計算工具、MCP等。
• LLM:最後用來提供最終回覆。

設計模式

• Reflection：自我反思與修正輸出。
• Planning：自動拆解並規劃任務。
• Tool Use：動態選擇工具來解決問題。
• Multi-Agent Collaboration：多代理人合作(較為進階)。

🏗️Agentic RAG 的架構類型

不同任務場景需要不同的架構，以下是常見設計：

1. 單代理架構（Router Model）

   • 一個核心代理負責決定使用哪個工具。
   • 適合客服助理或簡單查詢。

2. 多代理架構（Multi-Agent Architecture）

   • 任務由協調代理分派給不同專長代理。
   • 適合金融研究、跨領域分析。

3. 層級架構（Hierarchical Architecture）

   • 高層代理進行策略規劃，低層代理執行細節任務。
   • 適合高風險場景，如金融決策或醫療應用。

4. 自我修正架構（Corrective & Adaptive RAG）

   • 系統能檢查檢索結果，若不正確可重寫查詢。
   • 適合問題多樣、品質參差的場景。

5. 圖結構架構（Graph-Based Architecture）

   • 結合知識圖譜，支援多跳推理。
   • 適合科研、法律等強結構化領域。

🔍 傳統RAG與Agentic RAG概念性比較

我們快速整理一下傳統RAG與Agentic RAG的比較如下表:

🚀 深入比較 Agentic RAG的優勢

傳統 RAG 的限制（為何需要 Agentic RAG）

• 單一步驟檢索（Single Retrieval Step）
  傳統 RAG 常只做一次檢索並將結果直接送入 LLM，若首輪檢索不佳，後續輸出受限。

• 有限的多步推理能力（Limited Multi-Step Reasoning）
  即便有 re-rank，仍然是單輪檢索→排序→生成，無法像人一樣拆解多階段問題並逐步補查證據。

• 單一知識來源（Single Knowledge Source）
  多為靜態向量庫，缺乏即時資料或多來源整合能力（例如 API、網路搜尋、結構化 DB）。

• 缺乏驗證與修正機制（No Self-Validation）
  傳統流程通常不會自動檢查檢索結果的相關性或對生成結果進行事實性驗證。

• 查詢—文件不匹配（Query-Document Mismatch）
  使用者問題與文檔語氣/格式不同，會導致難以直接匹配到最佳片段。

Agentic RAG 的關鍵優勢（如何補足上述問題）

• 迭代檢索（Iterative Retrieval）與查詢精煉（Query Refinement）
  代理人會根據中間結果重寫或細化查詢，重複檢索直至找到更高質量的上下文。

• 任務規劃（Planning）與多步推理
  代理人能拆解複雜任務成子任務（例如：檢索 → 驗證 → 計算 → 彙整），並按步驟執行。

• 動態工具呼叫（Dynamic Tool Use）
  可根據任務需求即時呼叫不同工具（向量庫、網頁搜尋、計算工具、SQL、知識圖譜等）。

• 反思與自我修正（Reflection / Corrective Loops）
  代理人能用評估模組（grader / relevance evaluator）檢查中間結果並決定是否重試或改變策略。

• 多代理協作（Multi-Agent）與編排（Orchestration）
  藉由 Coordinator 與 Worker 模式分派專責任務，可並行處理並彙整結果，提高吞吐與可靠性。

🔄代價與挑戰（Agentic RAG 的 trade-offs）

• 延遲與成本提升：多次 LLM 呼叫與工具互動會增加延遲與運算成本（尤其在每一步都需高品質 LLM 时）。
• 錯誤傳播風險：若某一子任務出錯，錯誤可能會被放大，並影響最終決策（需強化驗證流程）。
• 協調複雜度：多代理系統需解決同步、任務分配、失敗重試與資源分配等工程問題。
• 安全與合規：代理能呼叫外部資源時需嚴格控管授權與敏感資訊暴露風險。

🎯實務建議：何時採用哪一種？

• 選傳統 RAG（Naïve / Advanced / Modular）：

  • 任務屬於單步事實查詢或 FAQ 型問題。
  • 資源有限且需要低延遲、低成本的解法。
  • 系統設計偏向簡潔、易維運的場景。

• 選 Agentic RAG ：

  • 需求為多跳推理、跨資料來源整合或流程自動化，甚至有需要除了查詢以外的功能(例如計算)。
  • 需要系統具備「策略性決策」和「自我修正」能力(問題推理)。
  • 可以接受較高延遲與成本來換取更高準確度與靈活性。

📌小結

• 傳統 RAG 是打基礎且成本低的解法，適合許多常見問答任務；但在面對複雜、多步、即時整合任務時會顯露瓶頸。
• Agentic RAG 透過「代理人」這個設計概念，將 RAG 轉為動態、可迭代且具工具呼叫能力的系統，能處理更複雜的任務，但同時帶來更高的工程與運營成本。
• 在實務上，常見的作法是 漸進式採用：先用傳統 RAG 快速驗證，再在需要時逐步引入 Agentic 元素（例如：先加reranker，最後搭配Agent flow做自我驗證機制）。

明天我們將介紹Agent flow的相關選擇和概念!

✨參考資料

Agentic RAG(lagegraph)
Agentic RAG(huggingface)
What is Agentic RAG(weaviate)
What is agentic RAG?(IBM)
Agentic RAG With LangGraph and Qdrant