現有的單步驟檢索增強生成（RAG）系統並非為現代商業工作流程中多來源、多跳躍的查詢而設計。舉例來說，如果查詢是「Project X 使用的伺服器規格是什麼？」，系統可能會找到關於 Project X 的文件，但這些文件可能只提到伺服器 ID。

它不會知道要使用該 ID 在另一個資料庫中執行第二次搜尋以找到規格。結果就是部分答案或「未找到」的回應，因為資訊分散在不同的「資料孤島」中，需要更深入的探索才能找到事實。

「代理式 RAG」應運而生，它能規劃、推理並迭代地與資料來源互動，從而處理複雜查詢，提高可靠性和準確性。

今天，我們很高興推出 Google Gemini Enterprise Agent Platform 上託管的跨語料庫檢索（Cross-Corpus Retrieval）版本，其由代理式 RAG 提供支援。與其他多代理 RAG 框架一樣，我們的框架採用多個代理協同工作，以可靠地回答複雜查詢。

與其他多代理框架不同的是，我們的框架納入了足夠的上下文來確認是否有足夠的資訊來提供準確的答案。與標準 RAG 相比，我們的框架在事實性資料集上的準確性提高了高達 34%。我們還使用專有的內部資料集評估了我們的系統，發現我們在多個特定領域任務上實現了更好的基礎和改進的推理準確性。

多代理架構如何運作：規劃、重寫和路由

將多代理 RAG 想像成一個有組織的研究部門，而不是單一的搜尋引擎，會有所幫助。在「單一」或「傳統」（Vanilla）RAG 系統中，檢索組件只會查看您的問題，並嘗試在大型語言模型（LLM）生成回應之前找到匹配的文件。

在多代理框架中，系統將任務分解為專業角色：

協調器（Orchestrator）評估您的複雜請求，並判斷「這不是一步就能完成的工作」，然後將工作委派給代理。

規劃代理（Planner Agent）規劃資訊路徑。例如，如果您詢問一個專案的預算和時間表，規劃代理會決定：「首先，我們需要檢查財務資料庫，然後我們需要檢查專案管理日誌。」

查詢重寫器（Query Rewriter）將您的請求轉換為多個搜尋查詢。它將「Project X 怎麼了？」轉換為「Project X 第三季狀態報告」和「Project X 團隊的主要阻礙」。

搜尋扇出代理（Search Fanout Agent）將這些精煉的查詢發送到各種檢索來源，以收集資訊片段。

最後，LLM 匯總所有上下文以提供最終回應。

我們的代理式 RAG 與眾不同之處

我們新的代理式 RAG 框架的關鍵區別在於「持久性」（persistence）。與其他 RAG 解決方案相比，我們的框架之所以有效，是因為它知道何時缺少資訊，並會持續搜尋直到上下文完整。這可以防止 AI 在第一次搜尋無結果時「猜測」，或者只是簡單地說「我沒有足夠的資訊」。雖然在某些情況下這是一個適當的回應，但有時資訊就在那裡，我們只是需要找到它。

例如，想像一位醫生詢問患者的藥物、飲食和過敏情況：「John Doe 膝蓋手術後的出院藥物和飲食限制是什麼？他在住院期間是否有任何過敏反應？請勿包含僅在住院或急診期間給予的藥物，肝素靜脈滴注或 Tenecteplase 除外。」

作為回應，我們的框架啟動了許多專業代理。我們在下圖中概述了我們的解決方案，然後再詳細描述。

階段 1：協調

根代理（Root Agent）解析醫生的請求，並將任務委派給子代理。規劃代理（Planner Agent）識別出它需要檢查三個不同的領域：藥房、營養和臨床記錄。查詢重寫器（Query Rewriter）將長請求分解為簡單、可搜尋的問題，以便檢索器能更準確地找到相關內容。

階段 2：搜尋（標準步驟）

RAG 代理同時搜尋患者記錄中的所有查詢扇出。它找到了藥物和飲食資訊，但在最明顯的文件中找不到任何關於過敏的提及。在標準或「傳統」（Vanilla）RAG 系統中，這個過程可能會在這裡結束，得到一個不完整的答案。

階段 3：足夠上下文代理（新的研究創新）

將足夠上下文代理（Sufficient Context Agent）想像成站在生產線末端的品管檢驗員。它在允許生成回應之前檢查三個具體發現：

1. 檢索到的片段：足夠上下文代理評估由 RAG 代理從資料庫中提取的實際文本塊。在醫生的例子中，這些可能是「出院摘要」和「營養記錄」中找到的特定段落。它閱讀這些內容，以查看回答查詢所需的資訊是否存在於這些句子中。

2. 中間草稿：系統還會創建一個「粗略草稿」回應。足夠上下文代理隨後審查提示詞、草稿和檢索到的片段，以評估模型是否擁有提供全面且有根據的答案所需的一切。如果提示詞要求三件事（藥物、飲食、過敏），但片段只包含兩件事的資訊，足夠上下文代理就會將其標記為「上下文不足」。

3. 缺失部分分析：這是最關鍵的部分。足夠上下文代理精確識別出缺少什麼。它不僅僅輸出「這是不夠的」；它會生成一個具體的「原因」和「回饋」日誌。例如：發現：「我們有藥物清單和低鈉飲食說明。」差距：「我們缺少來源文件中關於住院期間過敏反應或不良事件的資訊。」

足夠上下文代理將找到的內容與原始請求進行比較，並詢問：「我們回答了過敏問題嗎？」如果沒有，它就會發出「上下文不足」訊號，並提供具體回饋：「你找到了藥物和飲食，但你遺漏了過敏。回去專門搜尋『皮疹』或『不良事件』。」在多來源情況下，它還可以請求更多資訊或決定該來源與查詢不相關。

階段 4：迭代

由於足夠上下文代理的回饋，查詢重寫器創建了一個新的「皮疹」搜尋。然後，RAG 代理更深入地探查它第一次忽略的文件，並找到了缺失的資訊。

階段 5：綜合（最終答案）

足夠上下文代理最後一次檢查資料。現在它擁有了藥物、飲食和過敏資訊，它判斷我們可以停止搜尋。最後，綜合代理（Synthesis Agent）為醫生撰寫了一份清晰、準確的摘要。

實驗與結果

我們在 FramesQA 上評估了代理式 RAG，該資料集基於 FRAMES 論文。一個多跳躍問題的例子是：「截至 2024 年 6 月，收視率最高的兩部電視劇季終集，哪一部播放時間最長，長多少？」

RAG 系統需要執行多個步驟才能得出正確答案。首先，它必須識別出收視率最高的兩部季終集來自 M*A*S*H 和 Cheers。然後，它必須找到它們的播放時間，並計算時間差。在許多 RAG 設定中（傳統 RAG 或沒有足夠上下文的代理式 RAG），我們可能會遇到模型說出這樣的話：「儘管經過多次掃描，我沒有找到 M*A*S*H 或 Cheers 的明確運行時間。文件提供了收視率數據，但沒有以分鐘或小時為單位的持續時間。」這並沒有回答問題。

幸運的是，我們的代理式 RAG 可以透過首先搜尋電視劇，然後使用查詢重寫器和足夠上下文代理來針對 M*A*S*H 或 Cheers 的運行時間進行目標搜尋來解決這個問題。然後，Gemini 可以輕鬆確定哪部季終集播放時間最長，長多少：「M*A*S*H 季終集播放了 150 分鐘，是兩部中播放時間最長的。它比 Cheers 季終集長 52 分鐘，後者播放了約 98 分鐘。」

我們進行了一項實驗，以大規模測試這種能力（FramesQA 包含 824 個查詢以及一個包含 2,676 份 PDF 文件的語料庫）。在「傳統」（Vanilla）RAG 設定中，我們使用 Google 的 RAG Engine（它具有先進的檢索引擎、LLM 解析器和重排序器）。

我們將其與我們的代理式 RAG 在兩種設定下進行了比較。在單一語料庫設定中，我們從 FramesQA 文件中檢索。在跨語料庫設定中，我們還包含了三個其他干擾資料集，規劃代理必須決定從何處檢索。這種跨語料庫設定模擬了公司擁有由不同團隊管理的資料庫的用例。

我們透過使用 LLM 作為評審來比較系統回應與資料集中的真實答案，從而計算準確性。在跨語料庫設定中，我們的系統幾乎與其單一語料庫的準確性相匹配。即使規劃代理必須從 4 種可能性中選擇正確的語料庫，我們也成功地路由了搜尋查詢並正確回答了 90.1% 的問題。

此外，單一語料庫和跨語料庫版本的延遲大致相同（平均在 3% 以內）。這表明我們的代理式 RAG 系統可以對多個不相關的資料來源進行推理，這為更靈活的檢索場景開闢了可能性。

結論

透過結合先進的查詢規劃、路由和足夠的上下文，我們的代理式 RAG 系統確保 AI 生成的回應是可審計、可追溯且有根據的。我們期待看到機器學習社群如何利用這些新的代理能力來構建下一代可靠的 AI 系統。這項新功能現已在 Gemini Enterprise Agent Platform 中作為公開預覽版提供。

致謝

這個專案是與 Bo Li、Zhongjie Mao、Tiger Jin、Yuhong Kan、Mohd Abdullah (Obito)、Chun-Sung Ferng、Pooneh Mortazavi、Roger (Peng) Yu、Eran Lewis 和 Ivan Kuznetsov 共同完成的。

我們感謝 Kimberly Schwede 設計圖形，以及 Mark Simborg 提供寫作協助。我們也感謝我們的主要企業合作夥伴提供關鍵的使用者回饋、資料和見解。