Agentic AI 為何開始跳過 RAG

Agentic AI 團隊正把 RAG 換成預先編譯的知識層，因為這樣可以少做重複讀資料的工作。

講白了，RAG 一直在重算同一筆帳。每次請求都要抓文件、切 chunk、排順序，再塞進上下文。這些事做一次還行，做十次就很煩。

對 agent 來說更明顯。它會規劃、呼叫工具、跑多步流程。只要上下文一直重建，token 就一直燒。這不是模型不夠強，是架構把錢花在錯的地方。

為什麼 RAG 在 agent 工作流會卡住

先講清楚，RAG 不是壞東西。它解過一個真問題。LLM 需要新資料，也需要領域知識。RAG 讓模型不用重訓，就能拿到外部資訊。這在單次問答很夠用。

問題出在 agent。Agent 不是只回答一句話。它要看政策、比文件、做摘要，還要根據結果採取動作。每一步都可能再抓一次同樣的資料。這時候，RAG 的成本就開始很刺眼。

因為它的流程通常是固定的。先切段，再檢索，再排序，再塞上下文。模型最後還得自己猜結構。這很像叫工程師每次都從零整理 Excel。能做，但很浪費。

• 每次請求都會重新檢索。
• chunking 和 rerank 會重做。
• agent 常會回頭看同一批資料。
• 流程越長，token 浪費越明顯。

如果知識庫夠穩定，這些工作就不該放在推理時做。它們比較像資料工程，不像即時推理。講白了，能先做的事，就別拖到 runtime 才做。

這也是很多團隊開始改架構的原因。不是因為 RAG 沒用，而是因為 agent 工作流把它的缺點放大了。原本可接受的成本，到了多步驟流程就變得很難看。

預編譯知識層到底改了什麼

預編譯知識層的概念很直白。先把文件吃進去，先做解析，再把知識整理成更好用的格式。像是實體抽取、關係圖、術語標準化、事件時間線，這些都可以先離線做。

這種做法很像把原始資料先做 ETL。RAG 是把文件當現成答案來源。預編譯知識層是把文件當原料，先加工一次，再給 agent 用。前者省事，後者省 token。

這裡的差異不是學術名詞，而是成本結構。你把工作往前移，推理時就少做很多重工。對大量重複查詢、重複摘要、重複決策的系統，這差很多。

“The real power of LLMs comes from how much they can do with text, not from replacing the need to structure knowledge,” said Andrej Karpathy in a 2023 talk at Y Combinator.

這句話很對味。LLM 擅長處理文字，但不代表每次都該叫它自己整理資料。說真的，讓模型一邊找資料一邊想結構，常常是在燒 token。

所以很多團隊現在把精力放到知識建模、schema 設計、離線 enrichment。這些工作沒那麼炫，但很務實。你會先看到延遲降下來，再看到成本變穩。

跟傳統 RAG 的差別在哪

如果只是做臨時問答，RAG 還是很好用。你今天要查一份產品規格，明天要看一份法規摘要，RAG 都能快速上場。它的優點是快，缺點是每次都要重做一遍整理。

一旦進到 agent 工作流，情況就變了。Agent 會反覆檢查上下文，還會跨步驟引用資料。這時候，單純的檢索就不夠了。你需要的是可重用的知識結構。

我把兩者差異整理成下面這樣。這樣看最直接，也最像工程現場會遇到的選擇。

• 傳統 RAG：適合單次問答和臨時查詢。
• 預編譯知識層：適合重複推理和固定知識。
• Agent loop：需要更乾淨的上下文。
• 成本結構：從 runtime 移到 preprocessing。

這個差別也會反映在延遲上。當模型不用每次都從 chunk 重新猜結構，回應通常更穩。不是每個場景都會快很多，但至少不會一直被同一批資料拖住。

還有一個很實際的點。預編譯知識層通常比較好除錯。你可以直接看中介產物，像是實體表、關係圖、摘要索引。RAG 的黑盒感比較重，很多問題要追到檢索和排序才看得出來。

競品和數字怎麼看

現在市場上，大家其實都在往「少在推理時做事」這方向走。差別只在名字。有人叫 knowledge layer，有人叫 memory layer，有人直接做 graph-based retrieval。名字很多，核心邏輯差不多。

LangChain 和 LlamaIndex 這類工具，早期幫大家把 RAG 做起來。現在更多團隊開始往 Anthropic、OpenAI、Cursor 這種 agent 工作流思路靠攏，重點變成上下文管理和工具協作。

如果你看成本，差距會更有感。RAG 的成本常跟查詢次數一起漲。agent 一旦進入多步驟模式，檢索、摘要、重排都會重複出現。這不是 1 次的問題，是 5 次、10 次的問題。

• 單次問答：RAG 通常夠用。
• 多步驟代理：預編譯層更省 token。
• 穩定文件：離線整理更划算。
• 高變動資料：即時檢索還是必要。

我覺得最實際的做法不是二選一，而是混搭。穩定政策先編譯，變動新聞再檢索。固定 FAQ 先結構化，臨時資料再抓即時來源。這樣比較像真的在做系統，不是在玩名詞。

如果你是工程團隊，最好直接量三個東西。每步 token、每次延遲、同一份資料被重用幾次。只要這三個數字一拉出來，哪個層該前移，答案通常很明顯。

這波變化的背景是什麼

這件事其實跟 LLM 產品成熟有關。早期大家先求能用，所以 RAG 很自然。只要能把外部資料接上模型，很多 demo 就能跑起來。那時候重點是有沒有答案，不是成本漂不漂亮。

但 agent 不是 demo。Agent 會進到客服、內部知識管理、法務摘要、研究輔助這些場景。這些地方資料很多，而且流程會反覆跑。你很快就會發現，runtime 的每一個多餘步驟都在燒錢。

所以現在的趨勢很合理。先把穩定知識整理好，再把即時變化留給檢索。這樣做比較像資料平台思維，也比較像台灣工程團隊熟悉的做法。先把底層整理乾淨，後面才不會一直補洞。

另一個背景是上下文窗口雖然變大，但不是萬能。上下文越大，不代表你就該把所有東西都塞進去。很多時候，整理得好比塞得多更重要。這點做過系統的人都懂。

接下來該怎麼做

如果你現在在做 agent，我會先看一件事：哪些知識其實很少變。像政策、產品規格、內部 SOP、客服話術，這些東西通常很適合先編譯。不要每次都讓模型重讀一次。

第二步是把 workflow 拆開。哪些步驟是查資料，哪些步驟是推理，哪些步驟只是格式整理。只要你把這三種事分清楚，就比較知道哪一段該放到離線處理。

最後，別再把 RAG 當萬用解法。它很方便，但不是所有知識問題都該靠即時檢索。真正該問的是：這份知識，現在要不要每次都重新算一次？

我的判斷很直接。接下來一年，做得好的 agent 團隊，會越來越少把 runtime 當資料整理場。誰能先把知識層整理好，誰就比較不會被 token 成本和上下文混亂拖死。