Agentic RAG
Naive RAG 固定走「檢索一次 → 生成」。Agentic RAG 讓模型（或一個小狀態機）在過程中做判斷：這個問題要不要查庫？查到的塊夠不夠相關？要不要改寫再查？要不要改走網搜或另一個資料源？
為什麼 Naive RAG 不夠
- 簡單寒暄不必檢索，硬查會把無關段落塞進提示。
- 檢索品質差時，模型仍會根據垃圾上下文編答案。
- 比較、多步驟問題需要多次檢索，一次 top-k 裝不下。
LlamaIndex 共同創辦人 Jerry Liu 把這些層次講成 routing、query planning、tool use、agentic loop，見 Adding Agentic Layers to RAG。
常見模式
Routing（路由）
先分類問題：產品手冊、人事規章、還是閒聊。再送到對應的索引或直接給 LLM。LangChain Part 10 專門講這段。
Corrective RAG（CRAG）
檢索後用評分器看塊是否相關。不夠就改寫查詢或改走網搜，再生成。核心是「允許檢索失敗並補救」，而不是假設 top-k 一定有用。
Adaptive RAG
依問題難度選策略：簡單題走 Naive RAG，複雜題走分解或多步 agent。LangChain 用 LangGraph 實作的示範見 Building adaptive RAG from scratch。
Tool-calling agent
把「搜尋文件」當成工具之一，與計算機、API 並列。模型決定何時呼叫。這已接近一般 agent，RAG 只是其中一個工具。DeepLearning.AI Building Agentic RAG with LlamaIndex 從 router 一路做到多文件研究助手。
成本與可控性
每多一輪 LLM 呼叫，延遲與費用都上去，也更難除錯。上線前要：
- 限制迴圈次數，避免改寫→檢索→再改寫無限轉。
- 留下每一步的 trace（查了什麼、丟掉哪些塊）。
- 用評估集分別量「路由準不準」與「最終答案準不準」。
多數產品先把 Naive RAG 的切塊與混合搜尋做好，再對失敗案例加 agent。不是每個問答機器人都需要完整 agent loop。