驳“RAG 已死”论：上下文窗口扩展≠RAG 终结
编者按： 我们今天为大家带来的这篇文章，作者的观点是：即便在大语言模型上下文窗口不断扩大的今天，检索增强生成（RAG）技术依然具有不可替代的价值。
文章首先通过 Fiction.liveBench 基准测试结果展示了即使最先进的大模型在处理长上下文时也会遇到理解能力下降的问题，并指出：理论上下文长度 ≠ 有效上下文长度。
随后，作者从四个角度论证了 RAG 技术依然具有不可或缺的优势：1）企业私有数据体量远超任何模型的上下文窗口容量；2）模型存在“lost in the middle”问题，难以有效处理长上下文中间部分的信息；3）长上下文处理带来的时间成本和费用开销非常大；4）RAG 架构提供的组件分离设计拥有更高的系统可维护性和问题可追溯性。
最后，文章对 RAG 的发展方向进行了展望，并为正在规划或已经部署 AI 系统的企业决策者和技术团队提供了五点切实可行的战略建议。
本文系原作者观点，Baihai IDP 仅进行编译分享
作者 | Skylar Payne
编译 | 岳扬
每次新的大语言模型问世，标题党总遵循着固定套路：“百万 tokens 级别上下文窗口的新模型横空出世！”紧接着各路热评纷至沓来：“RAG 技术已死！”“检索机制可以淘汰了！”“直接把所有数据灌进模型就行！”
但如果你真正部署过解决实际业务问题的 AI 系统，就会明白事实绝非如此。甚至可以说相差十万八千里。
我曾在谷歌和领英等公司担任机器学习团队的负责人，主导过多个数据产品从零到推向国际市场的全过程，也见证过许多企业耗费数百万美元却收效甚微的 AI 项目。这些失败案例有共同点吗？都误解了上下文窗口与检索机制的关系。
接下来，请容我为您解释为何即便上下文窗口扩展到了百万 tokens，检索增强生成（RAG）技术依然不可或缺。
01 接受基准测试 Fiction.liveBench 的现实检验
在进一步深入探讨之前，我们先来看一组数据。Fiction.liveBench 是一项针对长上下文理解能力的基准测试，近期对主流大语言模型在不同上下文长度下理解复杂叙事的能力进行了评估[1]。
结果如何？ 即便是最先进的模型（包括号称具备 1000 万 token 上下文的 Llama 4），在上下文长度适中的基本理解任务（basic comprehension tasks）中也很吃力。 大多数模型的表现会在超过几千 token 后明显下降 —— 随着上下文的增加，模型输出的准确率下降至接近随机瞎猜的水平。
Fiction.liveBench 测试结果显示模型性能随上下文增长而衰减
这一发现并非孤例。它反应了从业人员日常能够观察到的现象：理论上下文长度 ≠ 有效上下文长度。问题的关键不在于模型能否“吞下”10 万 tokens，而在于它能否真正“消化”这些信息。
02 RAG 与上下文窗口的演进
让我们回顾一下历史。早期的 LLM（如 GPT-3）仅有很小的上下文窗口（约 2K token），这使得 RAG 几乎成为所有非简单应用的必备方案。随着上下文窗口扩展至 8K、32K，直至如今的数百万 token，某些场景确实可以在无需检索机制的情况下运行。
但这催生了一个危险的观点：认为增大上下文窗口大小最终将彻底消除对检索机制的需求。
这种二元对立的思维方式忽略了系统设计中一个重要的洞见：useful tradeoffs are multi-dimensional（译者注：在系统设计中，不能通过单一变量（如仅增加上下文长度）来优化整体性能，而需要在多个相互制约的维度之间进行平衡取舍。）。不应该将 RAG 与长上下文窗口视为互斥的关系，而是应该考虑两者在不同场景中如何协同互补。
03 为什么 RAG 能够持续存在（并蓬勃发展）
3.1 数据体量的现实情况
大多数企业拥有 TB 数量级的文档，包含数百万至数十亿 tokens。即使 10M token 的上下文窗口（在实践中能实现这个水平的模型极少）也无法容纳整个知识库。
以某制药公司为例：
- 50,000+篇研究论文
- 10,000+份临床试验报告
- 20 年的监管申报材料
- 数千项专利
没有任何大模型的上下文窗口能承载这些信息。检索不是可走可不走的通道，而是必由之路。
3.2 "The Lost in the Middle"问题
即便这些文档在技术上符合上下文窗口的要求，LLM 仍会陷入研究者所称的"lost in the middle"综合症。模型更关注上下文中开头和结尾的信息，常会遗漏中间位置的关键细节。前文提到的 Fiction.liveBench 基准测试结果已经表明了该问题的严重性 —— 而这还是在更理想化的“实验室环境”中，在具体问题、具体领域中，效果可能更加糟糕。
Anthropic 等实验室的研究一致表明，即便是最先进的模型也会表现出明显的 position bias（译者注：模型在注意力机制作用下，对不同位置信息的关注度权重分布不均衡。）。实际应用中这意味着：
- 位于第 10,000 位的文档对模型输出的影响力低于第 500 位的文档
- 上下文中间位置的关键信息常被忽视
- 单纯将文档塞入上下文并不能确保其被有效利用
而 RAG 系统通过检索并优先处理最相关的信息来解决这个问题，确保 LLM 减少误关注上下文中无关部分的机会。
3.3 模型推理的成本效益分析：长上下文的真实成本
每次增加上下文窗口大小，我们都在实实在在地为此付出代价。这个说法并非来自于理论推演，而是直接体现在性能指标和月度账单中。
根据 Glean 对 GPT-4 Turbo 的研究[2]，输入 token 数量与响应时间存在线性关系。其基准测试显示，每增加一个 token 会使首 token 的生成时间（TTFT）延长约 0.24 毫秒。这对上下文只有少量 token 的情况而言当然微不足道，但是会快速累积：
- 10,000 token 上下文：生成任何内容前需额外等待 +2.4 秒
- 50,000 token 上下文：+12 秒纯等待时间
- 100,000 token 上下文：获得首个模型回复前需等待 +24 秒
对于期待获得即时响应的用户而言，这些延迟不容忽视。在 Glean 的测试中，仅将 3,000 token 的上下文拆分为三个并行的 1,000 token 检索，就能改善近半秒的响应时间。
财务成本则体现得更为直接。以下列模型的定价作为参考：
- GPT-4 Turbo：0.01 美元/1K input tokens
- Claude 3 Opus：0.015 美元/1K input tokens
- Mistral Large：0.008 美元/1K input tokens
这意味着单个 100K token 上下文的查询，在生成任何输出前就可能耗费 1.00-1.50 美元。若乘以企业每天数千次的查询量，成本将呈指数级增长。
RAG 提供了一个直击痛点的解决方案：不必每次输入提示词都塞入 100K token，只需检索最相关的 2-3K token。实现 97% 的上下文规模缩减意味着：
1) token 处理时间缩减 97%
2) token 相关成本节省 97%
3) 更快的响应速度带来更佳的用户体验
没有企业愿意为处理无关 token 付费，没有用户愿意等待模型处理无用文本。RAG 不仅经济高效，更是大规模生产系统的实用方案。
3.4 组件分离的优势
在相关讨论中，有一个容易被忽视的核心工程原则：the value of separating concerns（译者注：该原则在系统设计中指将复杂系统拆分为功能独立、责任清晰的模块，每个模块专注于单一核心任务。）。RAG 架构将 AI 工作流拆分为独立的检索组件与生成组件。这种分离不仅是一种“系统架构美学”，还具有实质性的技术优势。
我在 LinkedIn 领导机器学习工程团队时，深刻认识到包含确定性与非确定性组件的混合系统更易调试、测试和进行改进。使用 RAG 架构时，若出现故障（生产环境必然会发生故障），可快速定位问题根源：
-
检索组件选择了不相关的文档
-
LLM 误解了优质文档
-
知识库中根本不存在该信息
这种模块化架构带来的问题可追溯性非常宝贵。在纯 LLM 系统中出现幻觉时，你往往只能猜测故障原因。
此外，这种分离设计还能实现对各组件的独立优化。你可以在不改动生成模块的情况下改进检索系统，无需重构检索架构就能升级大语言模型，或者直接新增内容源而无需重新训练任何组件。整个系统因此变得更模块化、更具适应性且易于维护。
在实际应用中，这意味着您能持续迭代优化系统，而非将其视为不可拆解的黑箱。任何构建过真实 AI 系统的工程领导者都会明白，这种设计理念具有无可替代的价值。
04 超越传统的 RAG：持续进化的检索增强生成
RAG 并非一成不变的技术。它正与所增强的生成模型一起不断发展。未来的方向不是抛弃检索机制，而是使其更智能、更动态，并与模型推理深度整合。
最新进展在保留 RAG 核心优势的同时，正突破其传统局限：
自省式检索（Self-reflective retrieval） ：新一代系统能动态判断何时需要补充检索，而非依赖单次检索。这样，模型就能自主识别自己的不确定性，实时获取额外的上下文。
递归优化（Recursive refinement） ：系统不再满足于一次性检索，而是基于部分信息迭代优化搜索查询 —— 正如人类研究某个课题时逐步聚焦关注范围的过程。
这些方法并非取代 RAG，而是对其进行增强。它们体现的是进化（evolution），而非彻底变革（revolution）。最重要的是，它们依然保持检索与生成的分离，只是组件间的交互接口变得更加精密。
尤为有趣的是，随着上下文窗口的扩展，这些进化版 RAG 反而更加强大。拥有 10 万 token 上下文窗口的模型可同时容纳多份检索文档，进行比对、识别矛盾，其信息整合效率远超小上下文窗口模型。
从这个意义上说，长上下文模型与先进检索技术是互补关系。二者相互赋能，而非彼此替代。
05 探讨前文技术分析对企业部署 AI 系统的战略指导意义
如果您正在构建 AI 系统，我的建议如下：
1) 不要为了追求更长的上下文而放弃 RAG。 最高效的系统会两种技术兼用，根据具体使用场景智能匹配方案。
2) 投资更好的检索系统，而不仅是更大的模型。 向量搜索（vector search）与混合检索（hybrid retrieval）技术的改进，往往比换用仅支持稍长上下文的最新模型带来更大的商业价值。
3) 为现实场景设计 AI 系统，而非为营销噱头。 在假设长上下文方案可行前，请用实际数据量和 query patterns（译者注：用户查询请求中存在的规律性特征） 测试系统。
4) 构建衡量核心指标的评估框架。 您的系统能否基于特定文档准确回答问题？这比任何基准测试分数都重要。
5) 保持灵活性。 该领域发展迅速，但核心的信息检索原则已被证明具有持久价值。
06 结论：RAG 正在进化，而非消亡
“RAG 已死”的论调反映出很多人对 AI 系统设计的误解。并不是要在检索与长上下文之间二选一，而是如何恰当地结合二者。
随着上下文窗口的扩大，确实存在更多无需 RAG 的使用场景。但在可预见的未来，检索技术仍将是 AI 工程师的核心能力。
这一论断绝非主观臆断 —— 数据不会说谎，成功案例自会印证：唯有真正融合检索与生成技术优势的系统，才能持续创造商业价值。那些一味追逐技术热点的方案，终究只是昙花一现。
About the author
Skylar Payne
AI made easy. AI executive for startups. Ex-Google. Ex-LinkedIn.
END
本期互动内容 🍻
❓有没有哪个行业/场景特别适合 RAG 技术？请分享一个您见过的应用案例。
文中链接
[1]https://fiction.live/stories/Fiction-liveBench-April-6-2025/oQdzQvKHw8JyXbN87
[2]https://www.glean.com/blog/glean-input-token-llm-latency
本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。
原文链接：
