什麼是 Agentic RAG?當檢索式知識庫遇上代理式推理

Agentic RAG 是一種讓 AI Agent 主導檢索流程的知識系統架構:它不是「收到問題就查一次資料庫、把結果塞進提示詞」,而是由一個具備推理與規劃能力的代理,自行決定要查什麼、查幾次、要不要換關鍵字、要不要呼叫外部工具,再把多輪檢索的結果交叉驗證後才回答。一句話:傳統 RAG 是「查了就答」,Agentic RAG 是「想清楚再查,查不夠再查,查對了才答」。

這個差別聽起來抽象,但在真實案子裡差很多。我們先從傳統 RAG 卡在哪講起。

傳統 RAG 的天花板在哪

傳統 RAG(Retrieval-Augmented Generation)的流程幾乎是固定的:使用者問題進來,系統把問題轉成向量,去知識庫撈出最相似的幾段文件,連同問題一起丟給大語言模型生成答案。這套流程對「單跳問題」很有效,例如「請假規定是幾天前要申請」,答案就躺在某一份文件裡,撈出來即可。

問題出在只要問題需要「拆解」,它就露餡。舉個我們實際遇過的例子:客戶的法遵人員問「這個客戶的交易模式,跟去年被裁罰的那三個案例比,有沒有類似風險」。傳統 RAG 會拿整句話去做一次相似度檢索,結果撈回一堆語意上沾邊、但邏輯上不對的段落——因為這句話其實包含三個子任務:先找出這個客戶的交易特徵、再調出去年三個裁罰案例的細節、最後做比對。一次向量檢索不可能同時完成這三件事。模型拿到一鍋雜訊,只能硬掰,答案看起來通順、實則不可信。

傳統 RAG 的三個結構性限制,大致可以這樣看:

• 它只檢索一次,沒有「查了發現不夠、再查一輪」的能力。
• 它無法把一個複雜問題拆成子問題分別處理,再彙整。
• 它只會讀文件,不會呼叫工具——算不了數、查不了即時資料、跑不了 SQL。

Agentic RAG 怎麼補上這一塊

Agentic RAG 的核心，是在檢索與生成之間放進一個會思考的代理。這個 Agent 拿到問題後，第一件事不是急著查，而是規劃：這題要拆成幾步?每一步需要什麼資訊?查回來的東西夠不夠支撐結論?

延續上面的法遵例子，Agentic RAG 的處理會變成:先檢索該客戶近半年交易紀錄並歸納出模式,再分三次分別調出去年三個裁罰案例,接著呼叫一個計算工具去比對交易金額分布的相似度,發現某一項證據不足時自己再補一次檢索,最後才生成一份帶著推理過程與引用來源的答覆。這整串動作不是工程師寫死的 if-else,而是 Agent 依當下情境自行決定的。

讓它成立的三個能力是:多步推理(把大問題拆成可執行的子步驟)、工具呼叫(能觸發搜尋、計算、資料庫查詢、API)、以及自我修正(判斷檢索品質不佳時重新檢索或換策略)。這也是為什麼 Agentic RAG 特別適合金融法遵、醫療臨床、製造品質分析這類「答錯有代價、答案需要交代來源」的場景。

一張表看懂差別

它不是免費的午餐

要誠實講:Agentic RAG 不是所有場景的正解。它會多跑好幾輪檢索與模型呼叫,延遲更高、Token 成本更貴,而且 Agent 自主決策一多,行為就更難完全預測——測試與監控的工程量比傳統 RAG 重得多。如果你的問題八成都是單跳事實查詢,硬上 Agentic 架構是在浪費錢。

我們的實務判斷通常是混合式:用一個輕量的分流層,先判斷問題複雜度,單跳問題走傳統 RAG 直接答,需要拆解與比對的才交給 Agent。這樣既壓住成本,又保住難題的準確率。

真正難的從來不是把 Agentic RAG 的 Demo 跑起來——那反而是最容易的部分。難的是讓它在你的真實資料、真實流程、真實使用者手上穩定跑上一整季，還被人願意天天用。我們做 RAG 知識系統時，多數時間其實花在切分策略、檢索評測、工具權限邊界、以及把它接進客戶既有系統這些沒人拍照的地方。Demo 很美不算數，上線且有人在用，才算把這件事做完。