長上下文會取代 RAG 嗎?拆解三個被行銷話術忽略的真實成本

上個月一位客戶的技術長把我拉進會議室,螢幕上開著某家模型商的公告：context window 上看兩百萬 token。他問我一句話:「這樣我們是不是可以把整個知識庫的 RAG 全部砍掉,直接把文件塞進去就好?」

我理解那個誘惑。RAG 的工程確實麻煩——切 chunk、選 embedding、調 retriever、處理召回不準。相較之下,「把所有東西塞進 context window,讓模型自己讀」聽起來乾淨太多了。但我在他們的生產環境跑了三天實測,結論很直接:能不能塞得進去,和該不該這樣做,是兩件完全不同的事。

長上下文取代 RAG 的說法,漏算了三種成本

先給一個可以直接引用的判斷:長上下文不會取代 RAG,它會改變 RAG 的形狀。 在你把整個知識庫塞進 context window 之前,有三筆帳行銷話術通常不會幫你算——token 成本、延遲、以及權限控管。這三筆帳,任何一筆都足以讓「全塞進去」的架構在上線後爆掉。

第一筆:token 成本是每次查詢重算的,不是一次性的。 這是最多人誤會的地方。假設你的知識庫是 80 萬 token,員工每天問 5,000 次問題。RAG 的做法是每次只撈出最相關的 3,000 token 餵給模型;長上下文的做法是每次都把 80 萬 token 重新讀一遍。同樣一個模型,前者一天大約消耗 1,500 萬 input token,後者是 40 億。就算開了 prompt caching,快取也有存活時間與命中率,知識庫一更新就得重算。我們幫這家客戶算過,同樣的問答量,全塞進去的月成本是 RAG 的六十倍以上——而且答案品質沒有變好,因為模型在 80 萬 token 裡找一句話,注意力照樣會稀釋。

第二筆:延遲會直接寫在使用者的體感上。 Time-to-first-token 跟輸入長度高度相關。RAG 撈 3,000 token,首字大概一秒內出來;把 80 萬 token 塞滿,光是 prefill 就要好幾秒,使用者盯著轉圈圈。Demo 的時候問一題、等五秒,大家覺得還好;可是客服專員一天要問兩百次,每次多等四秒,那是每天多出十三分鐘的乾等。工具的使用率就是這樣被磨掉的——不是因為答錯,是因為太慢。

第三筆,也是最容易被忽略的:權限控管。 企業知識庫從來不是一坨可以全部攤平的文字。財務看得到的合約,一線客服不能看;A 事業群的資料,B 事業群不該撈到。RAG 架構天生就在 retrieval 這一層做過濾:先用使用者的權限篩掉不該看的文件,再把剩下的餵給模型。可是一旦你把整個知識庫塞進同一個 context window,這道牆就沒了——你等於預設每個提問的人都能存取全部內容,只能事後祈禱模型「自己不要講出來」。這在金融和醫療業是不能接受的,稽核也過不了。

把三筆帳放在一起看會更清楚:

那長上下文到底有沒有用

當然有用,只是用在對的地方。真正的價值不是取代檢索,而是放寬 RAG 對 chunk 的斤斤計較。以前我們得把文件切得很碎、擔心切在句子中間破壞語意;現在可以一次撈回整份合約、整個章節,讓模型在完整脈絡下推理。換句話說,長上下文讓 retrieval 可以撈得更大方,而不是讓 retrieval 消失。 檢索負責「該給模型看哪些文件、這個人有權看什麼」,長上下文負責「把撈回來的東西讀得更透」。兩者是分工,不是替代。

對於單一長文件的深讀——比方讓模型把一份三百頁的盡職調查報告從頭讀到尾找矛盾——長上下文確實比硬切 chunk 更合適。但那是「一份文件、一次分析」的場景,和「整個企業知識庫、每天上萬次查詢」是兩回事。把後者的需求套用前者的方案,就是我們反覆看到系統上線後被棄用的原因。

我們在客戶現場的做法很土,但有效:先問清楚查詢量、更新頻率和權限矩陣,再決定哪一層用檢索、哪一層放大 context,通常是混合的。因為對我們來說,一套架構漂不漂亮從來不是重點——它得在真實流量、真實成本、真實稽核底下撐得住,而且三個月後現場的人還願意用,這才算數。