Agentic RAG 與圖任務編排
一個樸素的 RAG 系統(tǒng)流程是這樣的：先由用戶提出問題，然后系統(tǒng)基于用戶提問進行召回，對召回結(jié)果進行重排序，最后拼接提示詞后送給 LLM 生成答案。
一部分簡單場景下，樸素的 RAG 已經(jīng)可以滿足用戶意圖明確的場景的要求，因為答案已經(jīng)包含在檢索出來的結(jié)果中，只要交給 LLM 即可。然而在更多的情況下用戶意圖并不明確，無法直接通過檢索找到答案，例如一些針對多文檔的總結(jié)類提問需要進行多步推理 (Reasoning) 等等。這類場景就需要引入 Agentic RAG ，也就是在問答的過程中引入任務編排機制。
Agentic RAG，顧名思義，是基于 Agent 的 RAG。Agent 與 RAG 關系緊密，兩者互為基石。Agentic RAG 和簡單 RAG 的最大區(qū)別在于 Agentic RAG 引入了 Agent 的動態(tài)編排機制，因此可以根據(jù)用戶提問的不同意圖，引入反饋和查詢改寫機制，并進行“多跳”式的知識推理，從而實現(xiàn)對復雜提問的回答。
?
下面，我們先通過兩個高級 RAG 來看看 Agentic RAG 的工作原理。首先是 Self-RAG （參考文獻[1]），它的工作流程如下：
Self-RAG 是一種引入了反思機制的 RAG。從知識庫中檢索出結(jié)果后，它會評估結(jié)果是否與用戶提問相關。如果不相關，就要改寫查詢，然后重復 RAG 流程直到相關度評分達到要求。實現(xiàn) Self-RAG 需要實現(xiàn)以下兩大組件：
- 一套基于 Graph 的任務編排系統(tǒng)。
- 在 Graph 內(nèi)執(zhí)行的必要算子：比如在 Self-RAG 中，評分算子就至關重要。在原始論文中， 是需要自己訓練一個打分模型來針對檢索結(jié)果評分；在實際實現(xiàn)中也可以采用 LLM 進行評分，這樣可以簡化系統(tǒng)開發(fā)并且減少對各類環(huán)節(jié)依賴。
Self-RAG 是相對初級的 Agentic RAG，RAGFlow 中也已提供了相關實現(xiàn)。實踐證明，Self-RAG 對于較復雜的多跳問答和多步推理可以明顯提升性能。
再來看看另一種 Agentic RAG — Adaptive RAG (參考文獻[2])。它可以根據(jù)用戶提問的不同意圖采用對應的策略：
- 開放域問答：直接通過 LLM 產(chǎn)生答案而無需依賴 RAG 檢索。
- 多跳問答：首先將多跳查詢分解為更簡單的單跳查詢，重復訪問 LLM 和 RAG 檢索器來解決這些子查詢，并合并它們的答案以形成完整答案。
- 自適應檢索：適用于需要多步邏輯推理的復雜問題。復雜的問答往往需要從多個數(shù)據(jù)源綜合信息并進行多步推理。自適應檢索通過迭代地訪問 RAG 檢索器和 LLM，逐步構(gòu)建起解決問題所需的信息鏈。
如下圖所示，Adaptive-RAG 的工作流程與 Self-RAG 類似，只是在前面增加了一個查詢分類器，就提供了更多種對話的策略選擇。
從以上兩種 Agentic RAG 例子可以看出，這類高級 RAG 系統(tǒng)都需要基于任務編排系統(tǒng)上提供以下功能：
- 復用已有的 Pipeline 或者子圖。
- 與包含 Web Search 在內(nèi)的外部工具協(xié)同工作。
- 可以規(guī)劃查詢?nèi)蝿眨绮樵円鈭D分類，查詢反饋等等。
任務編排系統(tǒng)類似的實現(xiàn)主要有 Langchain 的 ?LangGraph 和 llamaIndex；Agent 的開發(fā)框架包括 AgentKit、Databricks 最新發(fā)布的 Mosaic AI Agent Framework 等等。任務編排系統(tǒng)需要基于圖（Graph）來實現(xiàn)，圖中的節(jié)點和邊定義了應用的流程和邏輯。節(jié)點可以是任何可調(diào)用的算子，也可以是其他可運行組件（比如鏈接起來的多個算子或者 Agents），每個節(jié)點執(zhí)行特定的任務。邊定義了節(jié)點間的連接和數(shù)據(jù)流。圖需要具備節(jié)點的狀態(tài)管理功能，從而根據(jù)節(jié)點的跳轉(zhuǎn)而不斷更新狀態(tài)。需要注意的是，這種基于圖的任務編排框架并不是一個 DAG (Directed Acyclic Graph)， 而是一個需要引入循環(huán)的編排系統(tǒng)。環(huán)是提供反思機制的基礎，對于 Agentic RAG 的編排至關重要。沒有反思機制的 Agent 只能提供類似工作流這樣的任務編排而無法實現(xiàn)更高級的多跳和多步推理機制，沒法真正像人類那樣去思考性地解決問題。在吳恩達給出的四種 Agent 設計模式（參考文獻[3]）中：反思被放在頭一個，其他三個都是工作流相關，分別是工具、規(guī)劃，和多 Agent 協(xié)同。反思被單列出來是因為思考和推理都必須基于它來進行，而 Agentic RAG 正是反思機制在 RAG 的體現(xiàn)。
Agentic RAG 代表了信息處理方式的變革，為 Agent 本身引入了更多的智能。結(jié)合了工作流的 Agentic RAG 也有更廣闊的應用場景。比如：在文檔摘要中，Agentic RAG 會首先確定用戶的意圖是要求摘要還是要求對比細節(jié)。如果是前者，就通過 Agent 先獲取每塊內(nèi)容的摘要再獲取整體的摘要；如果是后者，就需要進一步路由，通過檢索提取相應數(shù)據(jù)點，再把相關數(shù)據(jù)傳遞給 LLM。在客戶服務支持中，Agentic RAG 可以理解客戶更加復雜的提問，從而可以提供更加個性化的準確回復。在文獻助手中，Agentic RAG 可以綜合更多的文獻、數(shù)據(jù)和研究結(jié)果，讓使用者具備更全面的理解；在法律和醫(yī)療助手中，Agentic RAG 可以幫助理解和解釋復雜的領域知識，提供更準確地見解；在內(nèi)容生成應用中，Agentic RAG 可以幫助生成更高質(zhì)量的、上下文相關的企業(yè)級長文檔。
RAGFlow 將從 v0.8.0 開始原生支持基于圖的任務編排系統(tǒng)，并支持以無代碼的方式進行編輯；另一方面， RAGFlow 也在不斷完善各類查詢規(guī)劃算子以簡化 Agentic RAG 以及基于 Agentic RAG 的各類 Agent 應用的開發(fā)過程，真正從端到端解決企業(yè)級 RAG 應用的各類痛點。RAGFlow 一直在快速演進，歡迎關注、star，并積極參與到我們的項目中來！
項目地址：https://github.com/infiniflow/ragflow
本文轉(zhuǎn)自 AIGC開放社區(qū) ，作者：張穎峰
