Agentic RAG 與 Traditional RAG：兩者有什麼差異？
傳統 RAG 系統建立在一個簡單的概念上：找出最相關的資訊，將其加入提示詞，然後產生答案。對於答案可以在少量相關文件中找到的問題，這種方式運作得相當理想。
當問題不只是單純的資訊檢索時，挑戰就會出現。例如，使用者可能會問：「第三季營收成長與上一季的財測指引相比如何？」要回答這個問題，必須找出營收數字、定位先前的指引、比較兩者，並判斷現有證據是否充分。固定式的檢索流程沒有內建機制來規劃這些步驟，也無法在第一次搜尋未取得足夠資訊時進行補救。
Agentic RAG 引入一個管理檢索流程的代理程式。代理程式不再遵循固定路徑，而是能針對任務進行推理、將複雜問題拆解成較小的步驟、選擇不同的檢索策略、重試失敗的搜尋，並根據可用來源驗證最終回應。
在本指南中，我們會先回顧傳統 RAG 的運作方式，探討其限制，接著了解 Agentic RAG 如何透過加入規劃、工具使用與反覆推理來改變整體架構。
傳統 RAG 如何運作？
傳統 RAG 遵循簡單的三步驟流程：檢索、增強與產生。系統會將使用者的問題轉換成嵌入向量，並從已建立索引的知識庫中檢索最相關的段落。接著，系統會將這些段落與原始問題結合，以增強提示詞。最後，LLM 會根據檢索到的內容產生答案。
無論問題是簡單的事實查詢，還是需要從多份文件取得資訊的比較題，每個問題都會遵循相同的路徑。流程會從檢索執行到產生答案，而模型只能依賴初始檢索所提供的內容。
傳統 RAG 有哪些限制？
對於相關資訊存在於少量文件中的直接問題而言，這種單次處理方式運作得相當良好。但當問題需要多個推理步驟，或需要整合不同來源的資訊時，挑戰就會出現。
此外，當檢索結果不理想時，這種流程的補救能力也相當有限。如果檢索到的段落不完整、已過時，或只有部分相關，這些內容仍會直接傳入產生答案的步驟。系統沒有內建的規劃步驟來拆解複雜問題，也沒有推理迴圈來改善檢索，更沒有驗證步驟來確認最終答案是否符合來源資料。
什麼讓 RAG 具備「Agentic」特性？
Agentic RAG 在使用者與檢索機制之間加入由 LLM 驅動的代理程式。這個代理程式會將回答問題視為需要規劃的任務，而不是單純執行的流程。以下四項能力使其與傳統架構有所不同：
- 查詢規劃與拆解：代理程式會將「第三季營收成長與上一季的財測指引相比如何？」拆解成兩個子問題：一個關於第三季實際結果，另一個關於前一季發布的指引，並分別回答這兩個問題。
- 反覆檢索：如果第一次檢索只取得少量結果，代理程式會重新改寫查詢，或改用其他來源，而不是直接接受現有結果。
- 答案驗證：在回應之前，代理程式會根據檢索到的段落檢查草稿答案，並標示可用來源無法支持的主張。
代理程式不再遵循從檢索到產生答案的固定路徑，而是引入回饋迴圈。每次檢索後，代理程式都會評估結果，判斷資訊是否充分，或是否需要再次搜尋或改善查詢。只有在蒐集到足夠證據回答問題後，系統才會產生答案。
| 面向 | Traditional RAG | Agentic RAG |
| 查詢處理 | 直接將問題轉換成嵌入向量 | 拆解、改寫並路由 |
| 推理 | 檢索與產生答案之間沒有推理 | 代理程式會規劃、評估結果並決定下一步 |
| 錯誤復原 | 沒有復原機制；品質不佳的檢索結果會直接流入答案 | 當證據不足時，會重試、重新改寫查詢或升級處理 |
| 複雜度與成本 | 元件較少，僅需呼叫一次 LLM | 需要呼叫更多次 LLM，延遲時間較長且 Token 用量較高 |
| 最適用情境 | 在範圍明確的語料庫中進行單一事實問答 | 多跳問題、跨文件比較，以及高風險答案 |
我們的看法是：這張表可能會讓人覺得 Agentic RAG 明顯勝出，但真正的取捨並不是能力與能力之間的比較，而是能力與複雜度之間的取捨。代理程式加入的每個步驟，都代表需要額外呼叫一次 LLM、增加延遲時間，並讓系統多出更多需要維護的元件。
正確的選擇取決於使用者問題的型態。如果大多數查詢都是在結構良好的知識庫中進行簡單查找，傳統 RAG 通常更快，也更容易以較低成本維護。如果使用者經常提出需要整合多個來源資訊的多步驟問題，採用 Agentic RAG 所增加的複雜度可能就值得。
實際範例
以下面這個針對一系列已建立索引的財報所提出的比較問題為例：「第三季營收成長與上一季的財測指引相比如何？」
傳統流程會將完整句子轉換成嵌入向量，並檢索整體上與問題相似的段落。排名較前的結果可能會在相同內容中提到營收成長與指引，因此通常會找到摘要段落或分析師評論；但上一季報告中的具體指引數字可能不會出現。接著，模型會將第三季實際結果與檢索內容中出現的指引相關資訊進行比較。
Agentic 系統則會先進行規劃。它會先從第三季報告中檢索第三季營收成長，接著利用文件日期等中繼資料，針對正確來源執行第二次檢索，以找出前一季報告發布的指引。在取得兩個數字且各自對應到來源後，代理程式會整合比較結果，並驗證答案中的每項主張是否都能獲檢索到的段落支持。兩次具目標性的檢索，取代了一次廣泛搜尋。
何時使用傳統 RAG 就足夠？
如果客服中心機器人只需根據幾百份產品文件回答「我要如何重設密碼？」，就不需要查詢拆解或驗證迴圈。每個問題都能對應到單一段落，語料庫範圍明確，而使用者也重視速度。傳統流程只需呼叫模型一次即可回答，每次查詢的成本較低，也能減少需要偵錯的元件。
我們會將傳統 RAG 視為起點，而不是較次等的選項。先從線性流程開始，觀察哪些查詢會失敗，再在失敗情況集中出現在單次處理無法應付的多部分問題時，加入 Agentic 功能。
Progress Agentic RAG
Progress Agentic RAG 將這項能力視為可以逐步前進的光譜，而不是只能開啟或關閉的開關。Search 設定面板包含多項 Agentic 步驟，例如查詢改寫，會重新撰寫問題以改善檢索結果；使用者意圖路由，會根據使用者想完成的目標套用不同設定；以及語意重新排序，會在結果傳送給模型前，依照內容相關性重新排列結果。
若要使用完整的 Agentic 迴圈，平台的檢索代理程式會分析問題、將問題拆解成子問題，並決定每個部分應查詢哪些來源，包括多個 Knowledge Boxes、SQL 資料庫與網際網路搜尋。由於所有功能都是以服務形式執行，因此團隊不需要重新建置檢索流程，只要針對不同設定啟用相應功能即可。
總結
傳統 RAG 會以直線方式執行一次檢索、增強與產生答案，對單一事實問題非常有效，但面對其他類型的問題時就容易遇到困難。Agentic RAG 則將這套流程交由代理程式處理，由代理程式規劃檢索、針對品質不佳的結果反覆處理，並根據來源驗證答案，但代價是需要額外呼叫 LLM 且延遲時間較長。Progress Agentic RAG 讓我們能夠逐步在兩者之間調整，隨著需求增加，在相同的 Knowledge Box 上啟用查詢改寫、意圖路由、重新排序與檢索代理程式。這能支援需要整合多種不同資訊的複雜工作流程。
常見問題
從傳統 RAG 移轉至 Agentic RAG 時，需要重新建置知識庫嗎？
不需要。Agentic 功能位於檢索與協調層，而不是索引中。同一份已嵌入並建立索引的內容，可以同時支援這兩種方式。在 Progress Agentic RAG 中，您可以在現有的 Knowledge Box 上啟用改寫、路由或檢索代理程式，而不需要重新匯入資料。
哪些類型的問題最適合使用 Agentic RAG？
包含多個部分的問題最能受益，例如跨文件或跨時間區間的比較、答案涵蓋多個來源的問題，以及需要先改寫查詢才能成功檢索的模糊問題。在任何錯誤答案的代價都很高的情境中，答案驗證也值得投入成本，例如財務或法規遵循查詢。
如需進一步了解 Progress Agentic RAG 並開始使用，請參考以下資源：
文章來源: Agentic RAG vs Traditional RAG: What’s the Difference?
