Agentic RAG：讓 Agent 自己決定「怎麼搜」的實作課
前言：一次檢索為什麼不夠
2023 年的 RAG 是條單行道：把使用者的問題丟進向量資料庫，取回 top-k 段落，塞進 prompt，生成答案。流程簡單，但有三種問題會讓它默默失敗：
- 多跳問題（multi-hop）：答案散在多份文件裡，一次向量查詢永遠湊不齊證據；
- 含糊提問：使用者寫的文字和語料庫的措辭差太多，直接搜尋的召回率慘淡；
- 靜默壞檢索：取回的段落看似相關實則無用，模型照樣拿它來生成——幻覺就是這樣長出來的。
Agentic RAG 的答案，是把「檢索」從管線裡的一個固定步驟，變成 Agent 手上的一支工具：Agent 可以在一輪對話裡呼叫檢索 0 到 N 次、改寫查詢、切換資料源、對草稿做事實查核，證據不夠就回去再搜。代價是更多 token、更高延遲，換來的是多跳與含糊問題上更高的答案可信度（faithfulness）。
核心觀念：檢索是一個決策，不是一個步驟
經典 RAG 的控制流是線性的 DAG：input → retrieve → generate。Agentic RAG 則是帶迴路的狀態圖：檢索完先「打分數」，分數好才生成，生成完再做「事實查核」，沒通過就重寫查詢回去再搜。如圖一所示，左側是經典單行道，右側是 Agent 主導的檢索迴路。這種循環拓樸，正是 LangGraph 這類框架存在的理由——線性的 chain 表達不了「條件式重試」。
三種成名模式：Self-RAG、CRAG、Adaptive RAG
研究與實務沉澱出三種可以直接套用的模式（架構對比如圖二）：
- Self-RAG（Asai et al., 2023）：讓模型自己輸出反思標記（reflection tokens）——該不該檢索？取回的段落相不相關？生成的答案有沒有被證據支持？這種自我批判迴路大幅降低幻覺，特別適合法律、醫療、金融等受監管場景。
- CRAG（Corrective RAG, Yan et al., 2024）：檢索後加一個獨立的「文件評分員」，逐份評估取回文件的品質；證據太弱就換路徑——例如改走網路搜尋，而不是死守向量資料庫。實務上常和知識圖譜查詢混搭。
- Adaptive RAG：在管線最前面放一個便宜的查詢分類器，按難度分流：簡單事實題直接跳過檢索或只做一次單跳搜尋，複雜多步問題才進完整的 agent 迴路。生產環境裡 60–70% 的查詢是簡單題，這一步是省成本的關鍵。
2026 生產級堆疊：五個積木
實務上，一個 agentic RAG 系統通常組合 3–4 個子模式，很少五個全上：
- Query rewrite / decomposition：使用者的原話很少是檢索器想要的查詢；先改寫成檢索友善的形式，多跳問題再拆成子問題各自檢索；
- Hybrid retrieval：BM25（關鍵字）＋向量（語意）並行，用 RRF（Reciprocal Rank Fusion）融合。純向量檢索在生產環境據稱有約四成失敗率，混合檢索能補回大半差距——BM25 擅長稀有詞、程式識別符、精確名稱，向量擅長改寫與概念匹配；
- Reranker：用 cross-encoder 對候選段落逐一重打分，貴但槓桿率高，是實務上 precision 提升最多的單一步驟；
- Iterative / multi-hop retrieval：Agent 讀完結果再搜，直到證據足夠——迴圈一定要設上限；
- Self-check（faithfulness judge）：對草稿做 groundedness 檢查，發現無證據支撐的主張就退回重搜。
索引端也不能偷懶：Contextual Retrieval
檢索迴路再聰明，也救不了切壞的 chunk。Anthropic 的 Contextual Retrieval 指出：chunk 被切離原文後會失去上下文（例如「費用可免」到底指哪一種帳戶？），做法是在索引時用 LLM 為每個 chunk 寫一段定位說明、再一起做 embedding。他們自家的評估顯示：只加上下文，top-20 檢索失敗率降 35%（5.7% → 3.7%）；加上 Contextual BM25 降 49%（→ 2.9%）；再加 rerank 降 67%（→ 1.9%）。索引端的功夫和運行時的 agent 迴路是乘法關係。
實作要點：一個最小的修正迴路
下面是一個 CRAG 風格的最小骨架（Python 概念碼）：grader 先打分，證據不足就改寫查詢、必要時切換資料源，最多重試兩次：
MAX_RETRIES = 2
def agentic_retrieve(question, retriever, web_search, grader, rewriter):
query, retries = question, 0
while True:
docs = retriever.search(query) # 混合檢索 + rerank
kept = [d for d in docs if grader.is_relevant(question, d)]
if kept or retries >= MAX_RETRIES:
return kept or web_search(query) # 兜底：換資料源
query = rewriter.rewrite(question, docs) # 改寫後再搜
retries += 1
落地時的三個實務提醒：第一，迴圈一定要有上限與「證據充分就停」的停止條件，否則 token 帳單會失控；第二，簡單查詢走 Adaptive 分流，不要讓 80% 的簡單題去付深層管線的延遲；第三，用 LangGraph 的 checkpointing 把每一步留痕——可追蹤、可暫停、可重播，這是合規與除錯的剛需。
評測：沒有 eval 的 RAG 都是 demo
上線前至少鎖三個指標：faithfulness（答案是否被證據支持，目標 ≥ 0.9）、context precision（取回段落的精準度，≥ 0.8）、answer relevancy（≥ 0.85）。RAGAS 這類自動化評測框架可以直接跑進 CI；再配上 Arize Phoenix 或 Langfuse 做線上可觀測性，追蹤每一次檢索迴路的停止原因（證據足夠／重試耗盡／分類器分流），才知道迴路到底有沒有在做事。
結論：什麼時候該讓 Agent 自己搜
三個訊號出現任一個，就值得從經典 RAG 升級到 agentic RAG：問題是多跳的、提問是含糊的、正確率比延遲重要（法務、醫療、合規場景）。反之，高流量的 FAQ、單文件查詢，經典單次 RAG 更快更便宜，agentic 的開銷純屬浪費。記住 2026 年的共識：純向量檢索是架構失誤，混合檢索＋rerank 是底線；agent 迴路則是把「搜尋品質」從索引工程問題，變成「運行時決策問題」——讓模型自己決定怎麼搜、搜幾次、何時停。
來源
- FutureAGI, Agentic RAG 2026: Patterns, Code, Observability — https://futureagi.com/blog/agentic-rag-systems-2025/
- FutureAGI, RAG Architecture in 2026: Patterns + Eval — https://futureagi.com/blog/rag-architecture-llm-2025/
- GitHub：Agentic RAG with LangGraph（CRAG, Self-RAG, Adaptive RAG）— https://github.com/s-samarth/datasciencepreparation/blob/HEAD/AgenticAI/docs/rag/advanced-rag.md
- GitHub：Agentic RAG patterns — https://github.com/mhhamdan/agentic-ai-engineer/blob/HEAD/patterns/08-agentic-rag.md
- Towards AI, RAG vs Long Context in 2026 — https://pub.towardsai.net/rag-vs-long-context-in-2026-when-retrieval-still-wins-e6ebad9a4096?gi=a86f2d81f482
- Neomeric, RAG Chunking: 7 Steps to Better Retrieval — https://neomeric.com/blog/rag-chunking-retrieval-tuning/
- Anthropic, Contextual Retrieval — https://www.anthropic.com/engineering/contextual-retrieval
