想像一下，你問ChatGPT一個問題，它不僅要從自己的「大腦」裡找答案，還要翻遍外部知識庫，然後再給你回覆。這就是RAG（檢索增強生成）系統做的事情。但問題來了：是讓系統按照固定流程一步步走，還是讓AI自己當「專案經理」，自主決定每一步該幹什麼？
這篇論文就是要回答這個問題。研究團隊把RAG系統分成了兩大陣營：
Enhanced RAG（增強型RAG）：就像一條精心設計的流水線，有專門的「查詢改寫工」、「文件排序工」等模組，各司其職 Agentic RAG（智能體RAG）：讓大語言模型當總指揮，它自己決定要不要檢索、要不要改寫查詢，完全自主控制
目前業界對這兩種方案各有追捧，但到底哪個更好用？在什麼場景下該選哪個？成本和性能怎麼平衡？這些問題都沒有明確答案。於是研究團隊決定做一次「華山論劍」式的全面對比。
他們的核心貢獻有兩點：第一，從四個關鍵維度評估了兩種系統的實際表現；第二，詳細分析了成本和計算時間的差異，給實際應用提供了非常實用的參考。
相關工作：RAG技術的演進脈絡
RAG這個概念最早由Lewis等人在2020年提出，最初的設計非常簡單：收到查詢→檢索相關文件→把文件和查詢一起餵給模型→生成答案。但這種「裸RAG」（論文裡叫Naïve RAG）問題多多：有時候明明不需要檢索也要檢索一遍，浪費資源；有時候檢索到的文件品質不高，都是些不相關的內容；用戶問題和知識庫文件的表述方式差異太大，匹配效果差。
於是Enhanced RAG應運而生，研究者們開始往這條流水線上加各種「增強模組」：
查詢改寫模組（比如HyDE技術，把問題改寫成假想的答案段落，再去匹配） 語義路由模組（判斷這個問題到底需不需要檢索） 重排序模組（把檢索到的文件按相關性重新排序）
與此同時，隨著GPT-4這類模型的推理能力暴漲，Agentic RAG開始冒頭。這種方案的核心思想是：既然模型都這麼聰明了，為什麼不讓它自己決定工作流程？於是各種Agent框架像雨後春筍般出現：LangGraph、LlamaIndex、CrewAI等等。
但有意思的是，儘管這兩條技術路線都很火，學術界竟然還沒有人做過系統性的對比實驗。Neha和Bhati在2025年提出了一些理論上的區分，但沒有真刀真槍地測試。這篇論文就是要填補這個空白。
核心方法：四大維度的「拳拳到肉」對比
研究團隊選了四個關鍵維度來PK這兩種系統，每個維度都對應Naïve RAG的一個痛點：
1. 用戶意圖處理：該不該檢索的判斷力
問題情境：用戶問「今天天氣怎麼樣」，系統不應該去知識庫裡翻文件；但問「公司Q3銷售報告的關鍵數據是什麼」，就必須檢索。這個判斷能力很重要。
Enhanced的做法：用semantic-router框架，提前準備一堆「有效問題」和「無效問題」的例子，新問題來了就跟這些例子比相似度，判斷屬於哪一類。
Agentic的做法：讓GPT-4o自己決定，它可以选择「調用RAG工具」或者「直接回答」。
測試方法：在FIQA（金融問答）、FEVER（事實驗證）、CQADupStack（論壇問答）三個資料集上各準備500個有效查詢和500個無效查詢，看誰判斷得準。
2. 查詢改寫：讓問題和文件「說同一種語言」
問題情境：用戶問「自由職業的稅務影響是什麼？」，知識庫裡的文件可能寫的是「自由職業者需要繳納以下稅種……」，表述方式不一樣，直接匹配效果差。
Enhanced的做法：強制執行HyDE改寫——把問題改寫成一段假想的答案，比如「自由職業需要繳納特定稅種……」，然後用這段文本去匹配知識庫。
Agentic的做法：提示詞裡告訴Agent可以改寫查詢，但Agent自己決定要不要改、怎麼改。
評估指標：用NDCG@10（歸一化折損累積增益）來衡量檢索品質，這是資訊檢索領域的黃金標準。
其中：
是第個文件的相關性標籤。
3. 文件列表優化：檢索完還能再精選
問題情境：第一次檢索可能拿到20個文件，但其中有些不太相關，需要進一步篩選。
Enhanced的做法：用基於ELECTRA的重排序模型，把20個文件重新排序，選出最相關的10個。
Agentic的做法：Agent可以多次調用檢索工具，每次都能調整查詢策略，自己迭代優化。
4. 底層模型影響：換個「大腦」性能差多少
實驗設計：用Qwen3系列的四個模型（0.6B、4B、8B、32B參數）分別測試，看模型大小對兩種系統的影響是否一致。
評估方式：用Selene-70B作為「AI裁判」，評價生成答案的品質。這個模型在LLM-as-a-Judge競技場排名很高，而且在金融問答任務上跟人類評價高度一致。
實驗效果：誰更強？要看具體場景
用戶意圖處理：Enhanced在複雜場景更穩
結果很有意思：在FIQA（金融）和CQADupStack（英語語法）這種領域邊界清晰的場景，Agentic RAG表現更好，F1分數分別達到98.8和99.8。但在FEVER（事實驗證）這種開放域任務上，Agentic的召回率只有49.3%，比Enhanced低了35個百分點！
原因很明確：當任務邊界模糊時，Agent經常「過度熱情」，本不該檢索的也去檢索了。而Enhanced的基於示例的路由系統，在這種情況下反而更穩定。
查詢改寫：Agent的靈活性勝出
在所有資料集上，Agentic RAG的檢索品質平均高出Enhanced RAG 2.8個NDCG@10點。特別是在NQ（自然問題）資料集上，Agentic達到51.7，比Enhanced的43.9高了近8個點。
這說明什麼？Agent能根據具體問題靈活決定改寫策略，而Enhanced是「一刀切」的強制改寫，有時候反而畫蛇添足。
文件優化：Enhanced的重排序完勝
這個結果出人意料：Enhanced RAG透過重排序模組，在FIQA上從45.0提升到51.0（提升6個點），在CQADupStack上從46.0提升到48.0。
但Agentic RAG呢？即使允許它多次調用檢索工具，性能反而比基線還差（FIQA降到43.4，CQADupStack降到44.4）。看來Agent雖然能自主決策，但在「精挑細選文件」這件事上，還是不如專門訓練的重排序模型靠譜。
模型大小影響：兩者表現趨同
無論Enhanced還是Agentic，隨著底層模型從0.6B增大到32B，性能都穩步提升，而且提升曲線幾乎一致。這說明模型能力的影響是跨系統的，選哪種架構和選多大的模型可以獨立考慮。
成本分析：Agentic的「奢侈稅」不容忽視
這部分數據可能是最讓實際應用者關注的：
Token消耗對比（FIQA資料集）：
Agentic比Enhanced多消耗2.7倍的輸入token 輸出token多1.7倍 整體耗時增加1.5倍
在CQADupStack資料集上差距更大：
輸入token多3.9倍 輸出token多2.0倍
換算成真金白銀：如果你用OpenAI的API，Agentic RAG的成本可能是Enhanced的3-4倍。對於大規模應用，這不是小數目。
為什麼會這樣？因為Agentic需要不斷「思考」——每一步都要推理要不要調用工具、怎麼調用，這些中間步驟都要消耗token。而Enhanced是固定流程，該幹啥幹啥，不用額外「思考」。
從分佈圖可以看出，Agentic的token消耗和耗時都有明顯的「長尾」現象——有些查詢特別費勁，Agent要反覆調用工具好幾次。
論文總結：沒有銀彈，只有權衡
這篇論文最大的價值在於：打破了「新技術一定更好」的神話。
主要發現可以總結為：
窄領域任務選Agentic，開放域任務選Enhanced：在金融、語法這種邊界清晰的場景，Agent的理解力能發揮優勢；但在FEVER這種「什麼都能問」的場景，基於規則的路由反而更可靠。
查詢改寫環節Agentic占優：靈活的改寫策略確實能提升檢索品質，平均提升2.8個NDCG點，這個優勢是實打實的。
文件精選必須上重排序：Agent多次檢索的策略沒有Enhanced的專用重排序模型好用，這可能是Agentic架構的最大短板。論文建議：為什麼不在Agentic裡也加個重排序工具？
成本差異不可忽視：3-4倍的成本增加對很多應用來說是難以承受的。除非你對性能有極致要求，否則優化好的Enhanced RAG可能更實惠。
模型大小影響兩者一致：這意味著你可以先選架構，再根據預算選模型，兩個決策相對獨立。
實用建議：
如果你是企業開發者，在小規模、預算有限的場景下，Enhanced RAG可能是更明智的選擇——性能夠用，成本可控。
如果你追求極致的用戶體驗，或者應用場景特別複雜多變，那Agentic RAG的靈活性值得你為之付費。
但最理想的方案可能是「混合架構」：用Enhanced的重排序模組 + Agentic的靈活決策，取兩者之長。研究團隊也坦言，他們的Agentic實現只用了一個工具（RAG），如果給Agent配置更豐富的工具箱，結果可能完全不同。
這場對決沒有絕對的贏家，但給了我們一個清晰的參考系：選RAG系統，要看場景、看預算、看需求，盲目追新不如理性權衡。
如果你覺得這篇文章對你有幫助，別忘了點個讚、送個喜歡
>/ 作者：ChallengeHub小編
>/ 作者：歡迎轉載，標註來源即可