不是每次都該 RAG：真正成熟的 AI 系統，先判斷自己知不知道

如果你正在做 AI 產品，我很推薦先把這個問題想清楚：模型到底什麼時候該查資料，什麼時候不該？

這聽起來像小細節，但我認為它其實是下一代 AI 系統成熟與否的分水嶺。因為真正的問題從來不是「要不要接檢索器」，而是「什麼條件下該啟動檢索」。如果這個判斷永遠靠人手寫死，系統再大也只是固定管線；只有當模型能先評估自己知不知道，檢索才會從外掛工具，變成系統內部的一部分。

為什麼不是每一題都該開啟檢索？

很多團隊在做 RAG 時，會把 retrieval 當成預設開關：只要收到問題，就先查資料再說。這樣做的直覺很簡單，因為大家都怕模型胡說八道。

但這種做法有三個明顯代價。第一，延遲會增加；第二，token 成本會上升；第三，外部文件本身可能引入新的干擾。也就是說，檢索不是純收益，它是一種要付成本的決策。

《When to Retrieve》這篇論文的核心貢獻，就在於把這個問題明確化：對於問答任務，最佳策略並不總是去外部檢索，很多時候更好的做法反而是直接使用模型的 parametric memory；只有在模型真的不知道答案時，才應該查詢外部資訊 [1]。

真正成熟的系統，為什麼要先判斷自己知不知道？

這個想法本質上很像人類工作。你不會每次被問問題都先去翻文件；你通常會先判斷自己知不知道、記不記得、需不需要查證。只有在不確定、知識過時、或細節要求很高時，才會打開搜尋。

模型其實也應該這樣。論文提出的做法，是訓練 LLM 在不知道答案時產生一個特殊 token：<RET>，把它當成「我需要檢索」的系統訊號 [1]。這個設計非常優雅，因為它不是在外面硬包一層 heuristic，而是把檢索決策直接納入模型輸出的一部分。

這篇研究真正厲害的，不只是加了檢索，而是加了 policy

我覺得這篇文章最值得重視的地方，不在於它又做出一個新的 retrieval baseline，而在於它把 retrieval 從功能問題提升成 policy 問題。

功能問題問的是：檢索器能不能找回相關文件？

policy 問的是：在什麼情境下值得花代價去找？

這兩者差很多。前者偏工具，後者偏治理。當你開始用 policy 的視角看檢索，系統設計會立刻變得更成熟：你會關心信心分數、失敗成本、查詢延遲、外部知識的新鮮度，還有不同任務類型該如何設定不同的觸發條件。

固定開檢索，為什麼反而可能讓答案更差？

這件事很反直覺，但在實務上其實很常見。當系統對所有問題一律檢索，模型不只會收到更多噪音，也更容易受到檢索結果排序的影響。尤其在熱門知識、常識問題、或模型本來就很熟的領域，外部文件未必比內在記憶更乾淨。

論文提到，先前研究在 PopQA 類場景就已經觀察到一種現象：熱門問題往往可以直接靠 parametric memory 解決，而較冷門的問題才更需要檢索 [1]。這意味著檢索並不是一把萬能鑰匙，而是一種應該被條件化啟動的資源。

這和記憶系統設計有什麼關係？

我認為這篇文章其實不是只在談 retrieval，而是在談記憶架構。因為一旦你接受「不是每次都該查」，你就等於承認 AI 系統至少存在三種不同資源：

• 模型的參數記憶
• 外部可檢索知識
• 做出切換判斷的控制邏輯

很多團隊只設計了前兩者，卻忽略第三者。結果就是：系統看起來接了 RAG，但本質上沒有真正的記憶政策。它不是智能地選擇資源，而只是機械地把外部知識塞進 prompt。

這也是我為什麼越來越相信，下一代 AI 系統的核心能力，不只是擁有記憶，而是擁有記憶路由能力。知道何時依靠自己、何時請求外部知識、何時保持保留，這才是可靠性的基礎。

未來真正值得做的，是 retrieval routing 而不是 retrieval maximalism

這幾年很多產品都在追求更多資料源、更大 context、更密集的檢索管線，但我認為下一步不會是無限制擴張，而是更精細的 routing。這個方向其實也和後來不少自我反思或 self-RAG 類工作相呼應：模型不只負責回答，也必須負責判斷證據需求與修正策略 [2]。

對產品團隊來說，這代表設計重點要開始從「怎麼把檢索接上去」轉向「怎麼定義檢索觸發條件」。對 agent 系統來說，這更重要，因為多步工作流的成本會被每一次不必要的查詢放大。真正成熟的系統，不是每次都查，而是知道什麼時候不查。

延伸閱讀：When to Retrieve、Corrective Retrieval Augmented Generation

我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。