Google 推出 Agentic RAG：搜不夠就繼續搜，讓 Gemini 事實準確率提升 34%

現在大部分掛著 RAG 標籤的 AI 工具，工作方式其實相當隨緣：把你扔進來的問題拿去資料庫裡搜一趟，搜出來什麼就餵給大模型什麼，至於材料夠不夠，全憑運氣。

運氣好時答得頭頭是道，運氣不好就兩手一攤，要麼瞎編，要麼告訴你「找不到相關資訊」。現實裡的企業資料分散在各個孤島，這種「只搜一次聽天由命」的做法經常在關鍵時刻掉鏈子。

Google Research 與 Google Cloud 聯合推出了面向 Gemini 企業平臺（Gemini Enterprise Agent Platform）的新框架：Agentic RAG。它不再搞一錘子買賣，而是把檢索做成了會自我審查、缺什麼補搜什麼的多智慧體工作流。

官方測試顯示，相比標準 RAG，這套架構在事實性基準測試上的準確率直接提升了 34%，而且幾乎沒有增加額外的延遲。

像質檢員一樣盯住每一條回答

Google 這套系統的聰明之處，在於它把檢索和回答拆成了一個協同流水線，而不是讓一個大模型單打獨鬥。

整個工作流裡有協調器（Root Agent）、負責拆解任務的規劃器、把長句子改寫成檢索詞的查詢重寫器，以及負責去各個庫裡併發撈資料的 RAG Agent。

但真正拉開差距的，是系統裡的「充分上下文代理」（Sufficient Context Agent）。你可以把它理解成流水線末端的質檢員。

它不只看搜出來的文本片段，還會去審視系統根據現有材料生成的初步回答草稿。如果問題裡問了三件事，現有的材料只夠回答兩件，它不會硬著頭皮答，也不會直接放棄。

這位質檢員會明確指出「缺了哪一塊」，然後給出一個具體的理由，指揮系統發起第二輪甚至更多輪的有針對性的後續搜尋，直到資訊完整為止。

在 Google 給出的醫療案例中，醫生詢問術後用藥、飲食和過敏史。第一輪搜尋只找到了藥品和飲食，普通 RAG 這時候就草草交差了，而 Agentic RAG 會發現過敏資訊缺失，立刻回頭去臨床記錄裡專門調取，補全後再輸出最終結論。

為什麼重要

我們認為，Google 這次公開的 Agentic RAG 模式，給所有卡在企業級落地的團隊提了個醒：RAG 的上限不在於檢索演算法本身，而在於有沒有「知道自己不知道什麼」的自檢閉環。

對企業和開發者來說，多跳查詢（Multi-hop queries）一直是讓大模型進入核心業務流程的攔路虎。以往為了解決這個問題，很多人要麼堆更長的主動提示詞，要麼讓模型陷入無休止的反思迴圈導致響應奇慢。Google 證明了用專門的輕量代理做定向補搜，既能把事實準確率拉高 34%，又能把延遲控制在幾乎不增加的水平，這個工程平衡做得非常漂亮。

對行業而言，這也給其他 RAG 方案指了路。標準單步 RAG 正在迅速淪為玩具，未來的企業級檢索必然是 Agentic 的。不論你用不用 Google Cloud，這種拆分規劃、草稿審查與差異化補搜的範式，都是可以直接照抄的架構模板。

不過隱患也在這裡。多智慧體串聯在邏輯上很完美，但在生產環境裡，呼叫的容錯率和成本是乘法關係。一旦規劃代理拆錯了方向，後續的補搜就可能變成無底洞，Google 接下來需要證明這套系統在真實而混亂的企業文件堆裡，依然能像論文裡一樣剋制和高效。