RAG vs 长上下文

在最近这两年时间里，大模型的技术发展非常迅猛。像 Gemini、Claude 以及一些国产大模型，它们的上下文窗口已经飙升到了 100 万甚至 200 万个 Token。这意味着，它们可以一次性读完几十本长篇小说，或者一家公司十年的财务报表。

很多准备做开发的小伙伴自然会产生一个疑问：“既然现在的大模型记忆力这么强，能一次性把几百万字的资料全吃下去，那我们是不是就没必要费劲去切分文档、搞词向量、建向量数据库了？RAG 技术是不是要被淘汰了？”

答案是：绝对不会。在真实的商业落地中，长上下文和 RAG 并不是 “谁替代谁” 的关系，而是各自解决不同的痛点。

RAG 与长上下文之间的区别是什么？

为了让小伙伴们能够更加直观理解，我们来看这样一个场景：假设你要在一本 10 万字的《员工手册》里，查找 “出差打车报销标准”。

• 如果使用 “长上下文模式”：相当于把整本 10 万字的《员工手册》直接扔给大模型，让它从头到尾通读一遍，然后回答你的问题。
• 如果使用 “RAG 模式”：相当于先使用系统的 “目录检索” 功能，精准翻到 “交通费报销” 这一页，然后只把这几百字的内容提取出来递给大模型，让它总结出答案。

长上下文为什么不能完全替代 RAG？

虽然长上下文模式用起来非常简单，只需要把所有内容全部扔进去，也不需要写什么复杂的底层代码。但在企业级应用中，它有着 3 个方面的严重缺陷。

1. 极高的 Token 成本

我们在 “Token 计算与计费” 那一节算过账，大模型的输入是按字数收费的。如果使用长上下文模式，我们每次问它一个简单的问题，它都必须把那 10 万字的背景资料重新阅读并计算一遍（没错，是重写算一遍）。

哪怕 API 单价再便宜，如果是一个面向超过 10000 名员工的内部系统，每个人提问一次都要消耗 10 万 Token，那么每天的账单绝对是个天文数字，估计老板都要哭晕在厕所里了……

2. 严重的响应延迟

大模型阅读几百万字是非常耗费算力和时间的。在长上下文模式下，用户输入问题后，可能需要盯着屏幕上的 “加载中” 等待十几秒甚至一两分钟，这种用户体验是非常差的。

而 RAG 模式由于提前在数据库找好了范围，每次只发送几百个字的参考资料，大模型几乎可以做到秒回。

3. 容易 “迷失在中间”

在 “上下文窗口” 一节中我们提到过，大模型有一个 “迷失在中间（Lost in the Middle）” 的严重缺陷。

当一次性塞入的文档过长时，大模型往往只记住开头和结尾，而很容易漏掉隐藏在文档中部的关键细节。其检索精准度远不如 RAG 可靠。

长上下文的优势在哪？

既然长上下文又贵又慢，那科技巨头（OpenAI、Google 等）为什么还要拼命研发它呢？主要原因在于：在处理某些特定任务时，RAG 会彻底瘫痪，只能靠长上下文来解决，比如：全局宏观分析。

假如你的提问不是查询具体的规定，而是：

请帮我对比这 10 份年度财报，总结出公司这几年在人工智能战略上的演变过程。

此时 RAG 会彻底失效。因为 RAG 的底层逻辑是 “找局部相似的文字碎片”，它无法站在上帝视角去宏观把握几十万字的整体脉络。

而这正是长上下文的主场。大模型可以凭借它庞大的脑容量，一口气吞下所有财报，进行 “跨文档” 的深度逻辑归纳和全局分析。

RAG 与长上下文，应该怎么选？

一位优秀的产品经理或开发工程师，在进行技术选型时绝不会非黑即白，而是懂得根据具体的业务场景来选择：

• 必须使用 RAG 的场景：公司的知识库非常庞大（包含几万份文档）、用户提问频率极高、每次提问只涉及局部知识点（比如智能客服机器人、规章制度问答）。此时，RAG 是降本增效的唯一真理。
• 必须使用长上下文的场景：文档是用户临时一次性传进来的、需要理解全局逻辑、需要跨章节深度总结的场景（比如让 AI 帮你总结一本新出的行业报告）。
• 未来的终极形态：混合使用：遇到庞大的海量文档群时，可以先使用 RAG 过滤掉 90% 完全不相干的垃圾文档，捞出最相关的几万字，然后再利用长上下文模型 “一口吞” 的超强能力，对这几万字进行深度的交叉推理。这也是目前大厂的主要玩法！