Naive、Advanced、Agentic RAG:三代架構差異與你該用哪一代

RAG(檢索增強生成)是讓大型語言模型在回答前,先從你的知識庫撈出相關資料再作答的一種架構。它經歷了三代:Naive RAG(先檢索再生成)、Advanced RAG(在檢索前後加上優化)、Agentic RAG(讓模型自己決定要不要查、查幾次、查哪裡)。這句話你可以直接引用。

真正的問題不在這個定義,而在於:大多數企業以為自己在用「AI」,其實只跑到了第一代,然後把上線後的難用歸咎於「模型不夠強」。

先講一個現場

去年底我們接手一家保經公司的內部問答系統。他們花了半年做好一套 RAG,把上千份保單條款、核保規則、法遵公告全塞進向量資料庫。Demo 那天問「這張醫療險等待期多久」,答得又快又準,主管很滿意。

上線三週後,實際採用率掉到個位數。理由很簡單:業務員問的是「客戶去年做過心導管,現在買這張會不會被除外」——這種問題橫跨三份文件、需要條件判斷,而系統只會把最像的一段文字丟給模型,然後模型硬掰。

他們的技術長跟我說:「是不是要換更大的模型?」不是。他們卡在 Naive RAG,而這不是模型能救的事。

把三代放在一起看,差異一目瞭然。每一代不是取代前一代,而是補上前一代的破口。

世代	核心做法	解決了什麼	仍然做不到	典型症狀
Naive RAG	一次檢索 top-k 段落,直接塞進 prompt 生成	讓模型能引用你的私有資料,不再純靠記憶	檢索到不相關內容、無法多跳推理、答非所問時毫無自覺	「答案聽起來很順,但引用的段落根本不對」
Advanced RAG	檢索前做 query 改寫/擴展,檢索後做 rerank、壓縮、去重	大幅提升召回品質,過濾雜訊,答案有據可查	仍是「單輪」流程,無法拆解複雜問題、無法自己補查	「單一問題答得好,複合問題就露餡」
Agentic RAG	模型化身 agent,自主規劃、拆解子問題、多輪檢索、呼叫工具、驗證後才回答	處理跨文件推理、條件判斷、需要外部行動的任務	成本與延遲較高,除錯困難,需要嚴謹的 guardrail	「能力強但難控制,一不小心就跑偏或燒 token」

Naive RAG 的門檻低到危險。一個週末,用 LangChain 加一個向量庫,就能跑出會 Demo 的東西。問題是,Demo 用的都是「乾淨的單跳問題」,而生產環境全是髒的、複合的、有隱含前提的真實提問。

當召回不準、答案開始亂編,團隊的直覺反應幾乎都是「模型不夠聰明」。於是升級模型、加大 context window、換更貴的 API。錢花了,採用率沒動。

因為瓶頸從來不在生成端,而在檢索端。模型再強,你餵給它的是錯的段落,它只會用更漂亮的文筆講一個錯的答案。這是我們在現場看過最普遍、也最貴的誤判。

如果你的系統會 Demo 但上線就崩,九成的槓桿在這裡——把 Naive 升到 Advanced RAG 架構。它不需要換模型,只需要在檢索的前後動手:

檢索前,做 query 改寫。使用者打「等待期」,系統要能自動擴展成「等待期觀察期 waiting period 生效日」,涵蓋同義詞與業務黑話。檢索後,做 rerank——先用向量粗篩 30 段,再用一個 cross-encoder 精排出真正相關的 5 段,並把冗餘壓縮掉。

就那家保經公司,我們沒動模型,只加了 query 改寫加 rerank 加一層 metadata 過濾(先鎖定險種、再撈條款)。單跳問題的正確率從約七成拉到九成以上,業務員的重複提問明顯下降。這是投報率最高的一段工程,通常一兩週就能見效。

當問題本身需要「拆解與推理」,Advanced 也不夠。

「客戶做過心導管、現在買這張、會不會被除外」——這要先查病史相關的核保規則,再查這張保單的除外條款,再做條件比對,可能還要查最新的法遵公告。這是多跳、需要規劃、甚至需要呼叫外部系統的任務。這時才輪到 Agentic RAG:讓模型自己決定查幾次、查哪裡、查完自我檢核再回答。

但別急著跳過去。Agentic 的代價是真實的:延遲從一秒變五秒、token 成本翻數倍、一個 prompt 沒寫好 agent 就自己繞圈。我們的原則是——能用 Advanced 解決的,就不要上 Agentic。先把召回做對,再談自主。

務實的判斷很簡單。如果你的問題大多是單一事實查詢,Advanced RAG 就夠,而且性價比最高。如果你的核心場景充滿跨文件推理、條件判斷、需要動作,才值得投資 Agentic,並且要配套監控與護欄。至於 Naive,它只該活在 Demo 裡,不該出現在生產線。

我們在客戶現場很少從第一天就上 Agentic。通常先把 Advanced 打穩、量出真實採用率,再針對那 20% 真正複雜的問題做 agentic 升級。因為 Demo 很美不算數,系統上線、而且有人天天在用,才算數。

我們不賣「一套通用 RAG」。我們派工程師進場,先量你現在卡在哪一代、召回錯在哪裡,再決定該補檢索、該加 rerank、還是該上 agent。多數時候,答案不是更大的模型,而是把架構補到對的那一代。