昨天把 hybrid search、RRF 融合、查詢改寫串成一條靜態檢索管線,問題進去、文件出來、答案生成,整條路是一次性、單向、寫死的。今天要把這條管線的控制權交給模型自己:Agentic RAG(檢索代理)讓 LLM 在推理過程中自己決定「要不要檢索、檢索什麼、檢索夠了沒、要不要換個查法再來一輪」。這不是把檢索器換成更強的版本,而是把「檢索」從一個固定步驟變成模型可以反覆呼叫的工具。
📖 學
傳統 RAG 的致命結構是「一次檢索、一次生成」。使用者問「這款藥和我正在吃的降血壓藥會不會衝突」,單次檢索只會撈到最相似的一批片段,但這題其實要先查藥 A 的交互作用清單、再查藥 B 的成分、最後交叉比對——三個子問題,三次不同的檢索,靜態管線一次都做不到。Agentic RAG 的核心轉變,是把檢索器包成一個 tool,讓 LLM 在 ReAct 式的迴圈裡「思考 → 決定要不要查 → 查 → 讀結果 → 再思考」,直到自己判斷資訊足夠才收尾。決策權從管線設計者手上,移到了執行時的模型身上。
最小可用的形態叫 self-routing 或 adaptive retrieval:在生成前先讓模型判斷「這題需要外部知識嗎」。像「把這段話翻成日文」根本不需要檢索,強行塞進去的文件片段只會稀釋 context、增加延遲。Self-RAG 這篇把這件事做成訓練目標,讓模型輸出特殊的 reflection token,自己標記「此刻需要檢索(Retrieve)」以及「這段檢索結果和問題相關嗎(IsRel)、生成內容有沒有被檢索支撐(IsSup)」。實務上你不一定要重訓模型,用一個便宜的分類提示先做 gate 就有感:假設你的流量有 30% 是不需檢索的閒聊或改寫類請求,把這些擋在檢索之外,等於直接省下 30% 的向量庫查詢與 rerank 成本,延遲的 p50 也會明顯下降。
再上一層是 iterative / multi-hop retrieval,也就是前面藥物交互那種需要拆解的題目。代理先把大問題分解成子查詢,逐個檢索,把中間結果累積進 working context,再決定下一步查什麼。這裡最需要盯的數字是「檢索輪數上限」與「單輪召回品質」的權衡。多跳檢索有個殘酷的乘法效應:如果每一跳的檢索正確率是 85%,一個需要三跳才能答對的問題,端到端正確率理論上限只有 0.85 的三次方,約等於 61%。這解釋了為什麼很多 Agentic RAG 專案「單跳測起來很好、上線後複雜問題全崩」——不是代理笨,是誤差在每一跳被連乘放大。對策是每一跳都要有 grounding 檢查與 retry:某一跳召回品質不足時,讓代理改寫查詢重試,而不是硬著頭皮往下走。
要不要上代理,取決於你的問題分佈。綜述文獻通常把推理策略分成兩類:一類是預先寫死的、規則式的流程(ReAct 這種靠 prompt 交錯推理與工具呼叫的模式),另一類是用強化學習訓練模型「何時、如何呼叫工具」的策略。對大多數團隊,從第一類的 ReAct + 工具化檢索起步就夠了,不必一開始就碰 RL。有一個實用的判斷線:如果你抽樣 100 題真實流量,發現超過三成需要「拆成多個子問題分別查」才能答對,那昨天那條單次 hybrid 管線就是你的天花板,該上代理了;如果九成問題單次檢索就搞定,加代理只會換來更高延遲和更貴的 token 帳單,不如把力氣花在 rerank 和查詢改寫上。
延遲與成本是代理化最大的代價,要事先算清楚。每多一輪「思考 + 檢索 + 讀結果」就多一次 LLM 呼叫,通常也是最貴的那種(長 context + 推理)。粗估:單次 RAG 假設 1 次生成呼叫、延遲 2 秒;一個平均跑三輪的代理,就是 34 次呼叫、延遲逼近 68 秒,token 用量也接近三倍。所以務必設「輪數硬上限」(常見設 3~5 輪)與「早停條件」(模型自認資訊足夠即收尾),否則遇到查不到的問題,代理會陷入無止境的自我懷疑迴圈,把你的 token 預算燒光。
🧠 記
- Agentic RAG 的本質:把「檢索」從固定管線步驟,變成 LLM 在推理迴圈中可反覆呼叫的工具,決策權移到執行時。
- 三個層次:self-routing(要不要查)→ iterative/multi-hop(拆子問題逐步查)→ 訓練式策略(RL 學何時查)。多數團隊從 ReAct + 工具化檢索起步即可。
- 多跳的乘法陷阱:每跳 85% 正確率,三跳端到端理論上限僅約 61%。每跳都要 grounding 檢查與失敗重試。
- 上代理的判斷線:抽樣真實流量,超過三成需拆多子問題才上;九成單次可解就別上,先優化 rerank 與查詢改寫。
- 代價是延遲與成本:三輪代理約等於三倍呼叫與 token,必設輪數硬上限(3~5)與早停條件。
✍️ 實踐
今天在昨天那條 hybrid 管線外面,加一層最便宜的 self-routing gate 就好,不用碰多跳。步驟:第一,抽 50 題你手上真實或模擬的使用者問題,人工標記每題「需不需要外部檢索」。第二,寫一個分類提示,只做二元判斷「NEEDS_RETRIEVAL / NO_RETRIEVAL」,用便宜的小模型跑。第三,把這個 gate 接在檢索前:判為 NO_RETRIEVAL 的直接進生成、跳過向量查詢。第四,量三個數字——gate 的分類準確率、被擋掉的請求比例、以及這批請求省下的平均延遲。如果準確率超過 90% 且擋掉了兩成以上流量,這層 gate 就值得留著,也為之後升級到多跳代理打好了「先判斷再行動」的基礎。
🔗 延伸學習
- Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG (arXiv 2501.09136) — 系統整理 Agentic RAG 的設計模式與架構分類,適合建立全景圖。
- Reasoning RAG via System 1 or System 2: A Survey (arXiv 2506.10408) — 從「快思考 / 慢思考」角度切入推理式檢索,對照產業落地挑戰。
- Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection (arXiv 2310.11511) — self-routing 與反思式檢索的奠基論文,reflection token 的原始出處。
- AgenticRAG-Survey (GitHub) — 綜述配套的資源清單,持續更新的論文與實作連結。
💬 問 AI
我有一條靜態 RAG 管線:hybrid search(BM25 + 向量)+ RRF 融合 + 單次生成。
我想加一層 self-routing gate,在檢索前先判斷「這題需不需要外部檢索」。
請幫我:
1. 設計一個二元分類提示(NEEDS_RETRIEVAL / NO_RETRIEVAL),
要能正確擋掉純翻譯、格式改寫、閒聊這類不需檢索的請求。
2. 給我一組 12 題的測試集(涵蓋需檢索、不需檢索、模稜兩可三類),
標好正確答案,讓我量分類準確率。
3. 說明什麼樣的錯誤方向(把該檢索的判成不用查)最危險,
以及我該把 gate 的閾值往哪邊調來控制這種錯誤。