升級成 Agentic RAG

先想起我們為什麼會走到這一步。一般的 RAG,是查一次、生成一次,一條直線走完。簡單問題,像「這個規格怎麼看」,它又快又便宜,完全夠。但有些問題要好幾步。舉個例子:有人問「這台設備一直跳某個警報,要怎麼排除」——這一句話裡其實藏了好幾層:先要查這個警報代碼是什麼意思、再查它可能對應哪些原因、每個原因又對應哪些處置,可能還分散在不同幾本手冊。一般 RAG 只查一次、撈固定幾段,通常只撈到其中一塊,剩下的它看不到,答案就殘缺。問題越複雜,它越接不住。Agentic,就是來補這個洞的。

這張循序圖把 agentic 畫清楚了。使用者把問題交給一顆控制器 LLM。然後進到中間那個 loop 框 —— 這就是關鍵:控制器會自己決定還要查什麼,叫檢索器去查、拿回片段,再判斷「夠了嗎」;不夠,就再繞一圈,換個問法再查。直到它覺得資訊湊齊了,才跳出迴圈,生成一個有根據的答案。跟一般 RAG 最大的不同,就是中間多了這個會反覆決策的迴圈。

第一個差異,架構。這裡最重要的一句話:一般 RAG 跟 agentic,切塊、向量庫、檢索、生成,這些通通一樣。唯一多出來的,就是剛剛那顆會反覆決策的控制器,加上它的迴圈。換句話說,你不是把系統打掉重做,而是在原本的檢索「上面」,多加一顆腦。所以升級 agentic 是加法,不是重寫 —— 這個認知能幫你省下大量無謂的擔心。

第二個差異,資源 —— 這是很多人忽略、然後被帳單或延遲嚇到的地方。一般 RAG,回答一個問題,大概就一次 LLM 呼叫。但 agentic 一個多跳問題,要改寫查詢、判斷夠不夠、再查一輪、最後生成 —— 很容易變成三次、五次以上的 LLM 呼叫。這代表 token 花得多、而且延遲是相乘上去的。如果你跑的是地端的大模型,本來就慢,這個差異會更有感。

正因為 agentic 貴,你不該每個問題都用它。現場的問題,大概八成是單跳的 —— 查個規格、查個代碼,一般 RAG 一次就答完,又快又便宜。只有那大概兩成的多跳排障,才真的值得開那顆會迭代的腦。所以最好的設計,是讓控制器自己判斷:這題簡單,就走一般 RAG;這題複雜,才開迴圈。別為了潮,把每一題都丟給 agentic。

第三個差異,寫法 —— 也是最讓人放心的部分。你原本切塊、算向量、檢索那些核心函式,一行都不用動。你只要在外面加兩塊:一塊叫 decide,讓 LLM 看目前查到的東西,決定「還要再查、還是夠了」;再加一個迴圈,反覆呼叫 decide,它說要查就去檢索,說夠了就跳出來生成。大概三十行,包在原本的檢索外面。這就是「加法不是重寫」的實際樣子。

加這個迴圈,有三個護欄一定要放。第一,設一個最大次數的硬上限,防止它無限查下去 —— 尤其地端慢模型,失控的迴圈會把機器卡死。第二,讀控制器的決策要容錯,因為比較小的模型偶爾會吐出壞掉的格式。第三,萬一決策壞了,就自動退化成一般的查一次、答一次 —— agentic 出問題,至少還能給個答案,不要整個掛掉。

最後補一個很實際的特例:斷網的環境,比如進到不能連外網的廠區。這時候那顆控制器,不能借外面的 agent —— 因為外網根本連不到。解法是把一顆本地的 LLM,直接焊進你的服務裡,讓它在裡面自己跑那個迴圈。我把這叫「外面訓練、裡面跑」:模型跟資料在外面準備好,打包搬進去,斷了網,它照樣自己會查、會判斷、會生成。那顆控制器,就從借來的,變成你自己養的。

這集,也是這個系列,帶走一句話:Agentic RAG 不是更聰明的檢索,而是在你原本的 RAG 上面,多一顆會決定「要不要再查、查夠沒」的腦。架構上,它只多一顆控制器;資源上,它很貴,所以只給真正需要的問題用;寫法上,它是在外面包一層,核心一行不動。先把簡單版做好,再把這顆腦加上去 —— 這句話,幾乎適用你做的每一個系統。