K7.3 RAG vs 长上下文：2026 年的真相

一个流传甚广的预言

上下文窗口从 2020 年的几千 token，一路卷到 2026 年的百万级（上篇 8.2 节）。于是有人放话：

既然模型一次能塞进几十万字，何必费劲搞什么检索、切块、重排？把整个知识库一股脑塞给它，让它自己在里面找不就完了——「长上下文会杀死 RAG」。

听起来很有道理。是真的吗？拖动滑块算笔账，你就明白了：

🎮 动手实验

RAG vs 长上下文：直接全塞进去，不行吗？

上下文窗口越来越大，有人问：既然能塞几十万字，何必费劲搞检索，把整个知识库一股脑塞给模型不就行了？拖动滑块算笔账，看看这个想法在什么时候成立、什么时候破产。

知识库大小200 万 tok查询次数1000次

📦 长上下文全塞

每次塞整个知识库

每次 200 万 token

6000 元

1000 次查询总价

🎯 RAG 只塞几段

每次只塞检索到的 ~4k

每次 4000 token

12 元

1000 次查询总价

🔀 混合

检索缩到子集再推理

每次 5 万 token

150 元

1000 次查询总价

长上下文 / RAG 成本比

500 : 1

长上下文能装下吗

💥 超窗口

💥 知识库有 200 万 token，已经超过了旗舰模型约 100 万 token 的窗口上限（2026）——「全塞进去」这条路直接走不通，必须靠 RAG 先筛。库越大，长上下文越无能为力。

账一算，预言就破产了

玩过计算器，三件事一目了然：

其一，成本随知识库线性爆炸。 把「知识库大小」滑块往大拖，「长上下文全塞」的成本直冲云霄——因为它每一次查询都要为整个知识库付费；而 RAG 每次只塞检索到的那几段，成本几乎不随库变大。库越大，差距越夸张（几十倍、几百倍）。

其二，总会撞上窗口上限。 库超过约百万 token（2026 旗舰模型的窗口量级），「全塞进去」直接塞不下了——计算器会亮「超窗口」。知识库只会越来越大，这条路迟早走死。

其三，读越多越走神。 就算塞得下、付得起，上下文越长，模型越容易「中间迷失」——埋在中间的关键信息被忽略（回扣上篇 8.2 的「标称≠有效」和 K5.1 的 lost-in-the-middle）。塞得多，不等于用得好。

再加上第四点：知识库要实时更新（改一份文档就生效），总不能每次查询都把整个最新的库重塞一遍。

不过，计算器也诚实地告诉你一件事：把库拖小，会看到「小库是长上下文的甜区」——当知识库小到能轻松塞下时，直接全塞反而更省事（不用维护检索、也不怕漏召回）。RAG 的价值，随知识库变大才凸显。

2026 的共识：不是替代，是搭档

所以「长上下文杀死 RAG」的预言破产了。取而代之的 2026 共识是——两者混用：

用检索决定「该看哪些资料」（把知识库缩小到相关的一小撮），再用长上下文「在这一小撮上好好推理」。

RAG 从「长上下文的对手」，变成了「长上下文的最佳搭档」：检索负责在海量知识里精准定位，长上下文负责在定位出的证据集上深度理解。计算器里的「混合」方案，正是这个思路——它既避开了全塞的天价成本和窗口上限，又拿到了长上下文「一次读一大片、能综合推理」的好处。

这条边界在移动

RAG 和长上下文的权衡，随着窗口变大、token 变便宜，一直在变——今天的「甜区边界」明天就会移动。所以别记死「知识库超过多少 token 就该用 RAG」这种具体数字，而要记住那个判断框架：成本、上限、精度、更新——问自己这四个问题，答案自然浮现。这也是为什么 RAG 没有像预言的那样消失，反而活得好好的：它解决的是长上下文再大也绕不开的四个结构性问题。

小结

本节要点

「长上下文杀死 RAG」的预言，被成本账算破产了：全塞的成本随库线性爆炸、总会超窗口、读越多越走神、还没法实时更新。
2026 共识是混用：检索决定「该看哪些」、长上下文「在这一小撮上推理」——RAG 是长上下文的最佳搭档，不是对手。
小知识库是长上下文的甜区（能塞下就直接塞）；RAG 的价值随库变大才凸显。
记判断框架（成本 / 上限 / 精度 / 更新四问），别记死具体 token 数——这条边界一直在移动。

📝 动手自测0/3

1. 为什么「把整个知识库塞进长上下文」在库很大时不划算？

2. 2026 年关于「RAG vs 长上下文」的主流共识是什么？

3. 以下哪个不是「长上下文替代不了 RAG」的理由？

一个流传甚广的预言​

账一算，预言就破产了​

2026 的共识：不是替代，是搭档​

小结​

延伸阅读​

一个流传甚广的预言

账一算，预言就破产了

2026 的共识：不是替代，是搭档

小结

延伸阅读