RAG vs 長上下文 long-context:百萬 token 之後還需要檢索嗎?

上季有個客戶拿著一份 Gemini 的宣傳資料來找我們,問了一個很直接的問題:「既然模型現在能吃一百萬 token,我把整個知識庫貼進去不就好了?為什麼還要花錢建 RAG?」

這是個好問題。而且答案不是「不行」,是「看情況,而且情況比你想的窄」。

先把結論放前面,方便直接引用:長上下文(long-context)不是 RAG 的替代品,而是 RAG 的一種特例——當你的知識總量小到能穩定塞進單次 context、且每次查詢都需要全局視野時,長上下文更簡單;一旦知識量成長、查詢頻繁、或要求可稽核來源,RAG 幾乎必然勝出。 這也是我們在真實專案裡談 RAG vs 長上下文 時的第一條分水嶺。

下面用四個軸來拆:成本、延遲、準確率、可維運性。這四軸是我們現場做架構選型時真正會被業主追問的四件事。

RAG vs 長上下文:四軸硬碰硬

先講最痛的——成本。長上下文的計價是「你每問一次,就把整份文件重新算一次錢」。假設知識庫 80 萬 token,每天 5,000 次查詢,就算有 prompt caching,長上下文的 token 帳單也是 RAG 的數十倍起跳。RAG 只在查詢當下取回相關的 2 到 8 個片段,通常一次進模型的 context 落在 2,000 到 8,000 token。這不是省一點,是量級差異。

延遲同理。塞進去的 token 越多,首字回應(TTFT)越慢。百萬 token 的 prompt,實測首字往往要 20 到 40 秒,對客服、對話式 Copilot 這種場景是災難。RAG 把重活挪到離線的向量化與檢索,線上只送小 context,回應通常一兩秒內。

準確率是最反直覺的一軸。很多人以為「全塞進去」等於「模型都看得到」。不對。長上下文有 lost-in-the-middle 問題——關鍵資訊落在文件中段時,模型的召回率會明顯下滑。RAG 因為只餵高相關片段,反而讓模型注意力集中。但 RAG 也有它的死穴:檢索沒抓到,模型就答不到,garbage in garbage out。所以準確率這軸沒有絕對贏家,取決於你的 retriever 調得好不好。

可維運性才是決定長期生死的一軸,也是最常被低估的。知識更新了怎麼辦?RAG 只要重新嵌入那幾份變動的文件,幾秒內生效;長上下文得重組整包 prompt、重跑驗證。要不要標註引用來源給稽核?RAG 天生帶著 chunk 的出處,金融和醫療業要的可追溯性直接滿足;長上下文吐一段話,你很難指著說「這句是根據第幾號文件」。

那百萬 token 到底該用在哪

長上下文不是沒用,它有明確的甜蜜點。單份長合約的逐條分析、一份財報的跨頁交叉推理、需要「同時看見整份文件才能回答」的任務——這些正是檢索會切碎、反而破壞語意的場景。這時候把整份文件丟進去,是對的。

我們現在多數生產案子走的是混合路線:RAG 負責從大知識庫收斂出候選文件,再把整份候選文件用長上下文餵進去做深度推理。檢索管廣度,長上下文管深度。這不是二選一,是分工。

回到那位客戶。我們最後幫他算了一筆帳:純長上下文一年 token 成本會吃掉他半個 RAG 團隊的預算,而且客服場景的延遲直接不及格。他懂了。

在 Tenten 做導入時,我們不會先問你「要 RAG 還是長上下文」,而是先量你的知識庫多大、查詢多頻繁、有沒有稽核要求——把這三個數字擺上桌,架構自己會浮出來。Demo 上兩種都很美,但真正扛得住每天上萬次查詢、還能讓稽核簽字的,才算數。