RAG 的三體問題 — 為什麼 Agent 時代正在拋棄它

RAG（Retrieval-Augmented Generation）曾經是 LLM 應用的標準答案。不會的東西？先搜再答。幻覺太多？給它參考資料。2023 到 2024 年，幾乎每一場 AI 技術分享都會提到 RAG，彷彿這就是讓 LLM 「落地」的唯一正解。

但到了 2026 年中，越來越常聽到一句話：「我們把 RAG 拆掉了。」

不是換了更好的 RAG 框架，是整個拿掉。取而代之的做法五花八門 — 有人把文件全塞進百萬 token 的 context window；有人讓 Agent 自己搜、自己判斷、自己縮小範圍；有人乾脆用 BM25 加 LLM 篩選，連向量資料庫都省了。

RAG 不是被「更好的 RAG」取代。它正在被三股力量同時夾擊。

第一擊：長 Context 硬吃 — 「全部塞進去就好了」

RAG 之所以存在，前提是 context window 不夠大。2023 年的 GPT-4 只有 8K token，你不可能把整份產品文件塞進去，只能先用向量搜尋撈出最相關的片段，再餵給模型。

但這個前提已經不成立了。

2024 年底的一篇論文「Don't Do RAG: When Cache-Augmented Generation is All You Need」直接挑明：當知識庫規模有限時，把所有文件預載進長 context，用 KV cache 做查詢，比 RAG 更簡單、更準確。它甚至發明了一個新縮寫 — CAG（Cache-Augmented Generation）。

到了 2026 年，Claude 的 1M context 全面 GA 並廢除長文本溢價，Gemini 早就支援百萬 token。一位工程師分享他把整套 codebase 塞進 Claude 1M 跑分析，「團隊工程師看到我完全沒做切片就拿到結果，當場問我以後還需不需要 RAG。」

有人會說：百萬 token 也有上限啊，真正大規模的資料還是需要 RAG。

確實。但你手上有多少任務真的需要超過百萬 token 的知識庫？企業內部文件、產品 FAQ、技術文檔 — 多數場景塞得進去。當「全部塞進去」變得又便宜又簡單，你為什麼還要維護一套 embedding pipeline + 向量資料庫 + retrieval 邏輯 + reranker？

更殘酷的現實是：context window 越大，每一輪對話的 token 成本就越高。有人統計過，Claude 1M 開放後，session 常態性地膨脹到 500K+，一個簡單確認就燒掉 50 萬 token。所以「全部塞進去」也不是免費午餐 — 但至少它的複雜度比 RAG 低一個數量級。

第二擊：Agent 漸進式搜尋 — 「讓 AI 自己找」

RAG 的運作邏輯是：使用者問一個問題 → 系統猜使用者需要什麼資料 → 撈出 top-k → 塞進 prompt。

問題在那個「猜」字。

向量搜尋本質上是在做語意相似度比對。使用者說「退款流程」，系統去找跟「退款流程」embedding 最接近的段落。但「語意相似」不等於「語意相關」— 你可能需要的不是標題含有「退款」的那段文字，而是散落在三個不同模組裡的 API 呼叫邏輯、權限檢查規則、和前端表單驗證。

向量搜尋猜不到這些。

Agent 時代的做法不一樣。Ernie Ho 在一則筆記裡精準描述了這個轉變：

很多新的 Agent 系統開始改成：搜尋工具（BM25 / Grep）+ Progressive Disclosure。不是一次把所有資料丟進 context，而是一步一步縮小範圍，找到真正需要的資訊。

這跟人類查資料的方式一模一樣 — 你不會一次讀完整本百科全書再回答問題。你會先搜關鍵字、掃標題、挑幾段細讀、發現線索不夠再換個方向搜。

我自己的系統就是這樣運作的。mk-brain（我的個人知識庫，近萬筆書籤）用 bge-m3 做 hybrid search — 混合語意搜尋和關鍵字比對。但它不是傳統 RAG 那種「撈出來塞進去」的模式。它更像是一個搜尋工具：我問一個問題，它回傳最相關的 5-10 筆結果和核心洞察，我再根據結果決定要不要深入、要不要換個角度搜。

更進一步，Claude Code 的 Explore agent 就是 Progressive Disclosure 的具體實作 — 它在獨立的 context window 裡多輪搜尋 codebase，自己判斷要追哪條線索，最後只把結論帶回來。不是一次性把整個 repo 做 embedding 然後 top-k，而是像一個資深工程師那樣「翻 code」。

有人拿一份 30MB 的遊戲規則書做實驗，發現傳統向量 RAG 在這種精密檢索場景「效果慘不忍睹」。改用保留目錄結構 + BM25 + LLM 篩選後，精確度大幅提升。核心思想很簡單：與其讓資料散落在向量空間，不如根據結構預先分類，讓 Agent 自己導航。

第三擊：Embedding 本身的天花板

前兩擊是外部環境變了（context 變大、Agent 變強），第三擊是 RAG 的核心引擎 — embedding — 本身就有結構性的問題。

2025 年的一篇論文「On the Theoretical Limitations of Embedding-Based Retrieval」指出：單向量範式存在維度瓶頸，僅靠增加數據量或模型規模無法克服理論上的檢索限制。白話講：不管你的 embedding model 訓練得多好、向量維度開多大，有些類型的查詢它就是做不好。

這不是工程問題，是數學問題。

把一段文字壓縮成一個 1024 維的向量，本質上是在做有損壓縮。「退款流程」和「如何取消訂單並退還款項」在向量空間裡很近，但「退款流程」和「支付閘道的 webhook 回呼邏輯」可能距離很遠 — 即使後者才是你真正需要看的東西。

VincentChan 講得更直接：「多數 AI Memory 專案其實只是在做 Vector Store + Embedding 檢索 — 能解決找回片段，但它更像 searchable log，不是 memory system。」真正的記憶系統需要壓縮（compaction）、演化（evolution）、衝突解決（conflict resolution），這些都不是向量搜尋能做的事。

那 RAG 什麼時候還有用？

寫到這裡，我不想把 RAG 寫成過時技術。它在特定場景仍然是最務實的選擇：

資料量真的超過 context window。 數百萬份文件、數十 GB 的知識庫 — 你不可能全塞進去，必須先篩選。這是 RAG 的原始設計場景，依然成立。

需要明確引用來源。 合規場景（金融、醫療、法律）要求每一句回答都能追溯到原始文件的具體段落。RAG 天然支援這個需求。

領域明確且願意投入資源。 有研究比較 Agentic RAG 和 Enhanced RAG，在領域明確的金融問答場景，Agentic RAG 的 F1 達到 98.8。但代價是 token 消耗量是 Enhanced RAG 的 2.7-3.9 倍。

重點不是 RAG 有沒有用，而是它不再是唯一的答案，甚至不再是預設的答案。

Context Engineering 才是正確的抽象層級

退一步看，RAG 解決的問題從來不是「怎麼做向量搜尋」，而是「怎麼把對的資訊在對的時間送進 context」。

這個問題叫做 Context Engineering。RAG 只是它的一個特例。

長 context 硬吃是 Context Engineering。Agent 用工具搜尋是 Context Engineering。Sub-agent 在獨立 context 裡跑完任務再回傳摘要，避免主對話被塞爆 — 這也是 Context Engineering。甚至你在 CLAUDE.md 裡寫好規則讓 AI 每次開場自動讀取，本質上也是一種 Context Engineering。

Kordan 在一則貼文裡觀察到：「關鍵正從怎麼寫 prompt 往怎麼設計工具、runtime、跟安全邏輯移動。」模型還是同一顆，但包在什麼架構裡、用什麼方式餵資料，決定了實際效果。

如果你現在正在規劃一個新的 AI 應用，我的建議是：

1. 先問你的知識庫有多大。 塞得進百萬 token？考慮 CAG，省掉整套 retrieval pipeline。
2. 再問你的任務需不需要多輪探索。 如果答案不是一次搜尋就能找到的，考慮讓 Agent 自己搜。
3. 最後才問需不需要 RAG。 如果前兩個都不夠用，RAG 仍然是成熟的選擇 — 但請把它當工具箱裡的一把工具，不是整個工具箱。

RAG 不是死了。它只是從「預設選項」變成了「其中一個選項」。

而在 Agent 時代，最重要的能力不是做好 RAG，是做好 Context Engineering — 讓 AI 在每一個瞬間都拿到剛好足夠的資訊，不多不少。

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。