Google Research 在 6 月 8 日向 Gemini Enterprise Agent Platform 添加了一個 Sufficient Context Agent,將其作為名為 Cross-Corpus Retrieval 的 public-preview 功能 ship。該框架是多代理 RAG,其獨特貢獻是 pipeline 中一個特定的 agent,其唯一工作是決定到目前為止 retrieved 的 evidence 是否真正足以回答問題。標準 RAG retrieve 一次並回答。該框架運行五個階段:一個 Root Agent 解析請求並委派,一個 RAG Agent 跨多個 data sources fan-out 並行 queries,Sufficient Context Agent 根據原始 prompt 檢查 retrieved snippets,如果發現 gaps,一個 Query Rewriter 生成新的定向搜索,一個最終的合成步驟在模型被允許生成之前確認完整性。Google 發布的數字:在 FramesQA(2,676 個 PDF 文檔上的 824 個 queries)上,系統在從四個來源選擇正確資料庫時達到 90.1% accuracy,比 vanilla RAG baseline 提供高達 34% 的 factuality 改進(該 baseline 本身使用 advanced retrieval engine 加 LLM parser 加 re-ranker),並將延遲保持在 single-corpus 和 cross-corpus 模式之間的 3% 以內。

值得檢查的機制是 Sufficient Context Agent 做了什麼使它區別於標準的 relevance 或 confidence 檢查。典型的 RAG quality gate 產生一個二進制或一個 score:relevant 或不,confident 或不,當它失敗時它要麼仍然回答,要麼返回「insufficient context」並停止。Sufficient Context Agent 做一些更具體的事:當 evidence 不完整時,它寫一個 Reason and Feedback log,命名 gap。不是「insufficient」而是「在 corpus A 中找到了 server ID 但沒有 hardware specs,它們應該在第二個資料庫中」。那個命名的 gap 是 Query Rewriter 消費以生成下一次搜索的東西。因此 loop 不是用相同 query retrieve-score-retry,而是 retrieve、診斷具體缺失的部分、rewrite query 以針對那個部分、再次 retrieve。它針對的三個 failure modes 是具體的,對任何 ship 過 RAG 的人都熟悉:partial answers(你在一個來源中找到了一半答案並停止),premature not-found(第一次搜索返回空所以系統放棄),和 hallucination(context 不完整所以模型 guess 來填補空洞)。命名 gap 是將一個死胡同「我不知道」轉換為一個定向的下一次搜索的東西。

生態系統解讀是這是我們一直追蹤的相同 state-externalization 模式,現在應用於 knowing-what-you-don't-know 問題,並 ship 進一個 enterprise runtime 而不是作為 paper 發布。Harness-1 將 retrieval bookkeeping 外部化到環境。Memory OS 將 agent 記憶體外部化到六個類型化的層。Sufficient Context Agent 將 sufficiency 判斷外部化到一個帶有書面 log 的專用 agent,而不是將其留作生成器 confidence 的隱式屬性。戰略背景是這落在 Gemini Enterprise Agent Platform 內,與 Antigravity 2.0 的 Managed Agents 居住的相同 enterprise tier,這意味著 Google 正在一次一個外部化 capability 地組裝 enterprise agent 堆疊:orchestration、retrieval、sufficiency-checking、query-rewriting,每一個都是你租用的 runtime 中的一個命名 component,而不是你編寫的 prompt。那是 agentic-RAG 研究方向的 productization,34% 的 factuality 數字是他們向在第一波中被 RAG-自信地幻覺燒傷的 enterprise buyers 提出的論證。

週一早上,如果你在生產中運行 RAG,你的 failure mode 是在 multi-hop queries 上自信的錯誤答案:Sufficient Context 模式是要研究的架構,關鍵的設計 move 是讓 sufficiency check 命名具體的 gap 而不是發出一個二進制,因為命名的 gap 是使 re-search 定向而不是重複的東西。你可以自己構建這個模式而不需要 Gemini 平台,components 是一個 orchestrator、一個並行 retriever、一個被 prompt 來寫 gap log 的 sufficiency-checker、一個 query rewriter 和一個 synthesizer。如果你是 Gemini Enterprise Agent Platform 上的 enterprise:Cross-Corpus Retrieval 現在處於 public preview,FramesQA 數字值得根據你自己的文檔 corpus 驗證,特別是 cross-corpus database-selection accuracy,因為那是標準 RAG 處理最差的 multi-source 情況。如果你為 agentic RAG 評估 buy-versus-build:這個 release 是 buy 選項具體地變得更好,問題是 3% 的延遲開銷和平台 lock-in 是否值得不必自己構建和維護五個 agent 的 loop。如果你追蹤 agent-runtime 整合線索,注意它 ship 在哪裡:不是作為 open framework 或 research artifact,而是作為 enterprise runtime 內的租用 capability,那正是主要 vendors 競相擁有的層。