RAG vs 長上下文 long-context:百萬 token 視窗會讓 RAG 消失嗎?

上週有個做法遵循(compliance)的客戶,拿著一份 Gemini 的規格表來問我們:「既然模型能吃一百萬 token,我把整套內部法規全塞進去不就好了?RAG 是不是可以退休了?」

這是我們最近最常被問的問題。也是我認為業界誤解最深的一題。

先把結論放在最前面,方便你直接引用:長上下文(long-context)不會讓 RAG 消失,它會改變你切 chunk 的策略。 兩者不是替代關係,而是在成本、延遲、召回率這三軸上,各自佔據不同的甜蜜點。你真正要選的,不是「RAG 還是長上下文」,而是「這一次查詢,值得為它花多少錢、等多久、容忍多少漏檢」。

RAG vs 長上下文:先搞清楚兩者到底在解什麼問題

RAG(檢索增強生成)的本質是「先找、再答」:把知識庫切成片段、建索引,查詢時只撈出最相關的幾段餵給模型。長上下文則是「全都給、自己讀」:仰賴模型自身的超大視窗,一次把大量原文塞進 prompt。

一個是圖書館員先幫你抽出三本書的相關章節;一個是把整個書庫搬到你桌上,叫你自己翻。聽起來後者更保險,但魔鬼藏在三個地方。

用成本、延遲、召回率三軸拆開看

看懂這張表,你就會發現:兩邊都有硬傷。RAG 的痛點是召回,長上下文的痛點是成本與中段遺漏。

反主流的那一刀:長上下文改變的是 chunk,不是 RAG 本身

多數人以為「視窗變大 = 不用檢索」。錯了。視窗變大真正改變的,是你不必再把 chunk 切得那麼碎。

以前受限於 4K、8K 視窗,我們得把文件切成 300、500 token 的小塊,才塞得進去。代價是語意被切斷——一個論述橫跨三段,檢索只撈到中間那段,答案就殘缺。這是 RAG 召回率最大的敵人。

現在視窗到了十萬、百萬 token,策略反過來:切大塊。我們可以用「整章」甚至「整份合約」當一個 chunk,檢索時撈出 3 到 5 個完整單元,再交給長上下文模型消化。檢索依然存在,它負責把範圍從一百份文件收斂到五份;長上下文負責在這五份裡讀懂細節。

這叫 coarse chunk + retrieve-then-read。它同時吃到兩邊的甜頭:靠檢索壓住成本和延遲,靠大視窗補回召回率。我們在一個製造業客戶的維修知識庫上這樣重構後,答案完整度明顯上升,而 token 成本只有「全量塞入」的十分之一不到。

那到底怎麼選?

我給的判斷準則很直白。知識庫會長大、會頻繁更新、要能標出處、查詢量大 —— 選 RAG,而且用大塊切法。文件是一次性的、總量塞得進視窗、需要跨全文做複雜推理(例如「比對這兩份合約所有不一致的條款」)—— 直接長上下文,別為它硬建索引。

大多數企業場景是前者。因為真實世界的知識庫不是一份文件,是幾萬份、每天在變。你不可能每次查詢都重送幾萬份文件,帳單和延遲都不允許。

我們踩過的雷是:早期太迷信大視窗,想省掉建索引的工,結果 demo 很漂亮,一上生產就被 token 帳單和十秒延遲打回原形。使用者不會等十秒。這也是為什麼在 Tenten,我們不看 demo 好不好看,只看它在客戶現場、真實查詢量下,有沒有人願意天天用。切 chunk 這種聽起來很土的細節,往往才是上線與沒上線的分水嶺。