RAG vs 長上下文 long-context:百萬 token 視窗會讓 RAG 消失嗎?
百萬 token 視窗一出,「RAG 該退休了」的說法就沒停過。但我們在生產現場看到的完全相反:長上下文不會取代 RAG,它只是讓你不必再把 chunk 切那麼碎。用成本、延遲、召回率三軸拆開,你會發現真正該問的不是二選一,而是這次查詢值得花多少錢、等多久、容忍多少漏檢。
作者
Tenten AI 研究團隊
AI 基礎設施
發佈日期
2026年1月3日
閱讀時間
5 分鐘
上週有個做法遵循(compliance)的客戶,拿著一份 Gemini 的規格表來問我們:「既然模型能吃一百萬 token,我把整套內部法規全塞進去不就好了?RAG 是不是可以退休了?」
這是我們最近最常被問的問題。也是我認為業界誤解最深的一題。
先把結論放在最前面,方便你直接引用:長上下文(long-context)不會讓 RAG 消失,它會改變你切 chunk 的策略。 兩者不是替代關係,而是在成本、延遲、召回率這三軸上,各自佔據不同的甜蜜點。你真正要選的,不是「RAG 還是長上下文」,而是「這一次查詢,值得為它花多少錢、等多久、容忍多少漏檢」。
RAG vs 長上下文:先搞清楚兩者到底在解什麼問題
RAG(檢索增強生成)的本質是「先找、再答」:把知識庫切成片段、建索引,查詢時只撈出最相關的幾段餵給模型。長上下文則是「全都給、自己讀」:仰賴模型自身的超大視窗,一次把大量原文塞進 prompt。
一個是圖書館員先幫你抽出三本書的相關章節;一個是把整個書庫搬到你桌上,叫你自己翻。聽起來後者更保險,但魔鬼藏在三個地方。
用成本、延遲、召回率三軸拆開看
| 維度 | RAG(檢索式) | 長上下文(全量塞入) |
|---|---|---|
| 每次查詢成本 | 只送 top-k 片段,input token 少,通常低一到兩個數量級 | 每次都送完整文件,百萬 token 的 input 費用會讓帳單很難看 |
| 延遲 | 檢索增加幾十到幾百毫秒,但生成快 | prefill 整個視窗,首 token 延遲可能到數秒甚至十秒以上 |
| 召回率 | 取決於切塊與檢索品質,爛的 chunk 會漏關鍵段落 | 理論上全召回,但長文中段的「lost in the middle」會讓中間資訊被忽略 |
| 更新成本 | 改一份文件只需重建局部索引 | 內容一變,整包 context 要重送,無法快取複用 |
| 可追溯性 | 天然帶出處,能標到是哪一段 | 模型讀完全文,較難精準定位引用來源 |
看懂這張表,你就會發現:兩邊都有硬傷。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 這種聽起來很土的細節,往往才是上線與沒上線的分水嶺。
