长上下文会最终杀死 Rag 吗？

Moment
0 阅读18分钟

现在讨论 RAG，很容易被一个问题带偏：模型上下文窗口都已经到百万级了，我为什么还要做检索？

这个问题确实越来越现实。

过去我们做 RAG，很大一部分原因是模型装不下太多内容。一本产品手册、几十份合同、一个代码仓库、几百页制度文档，直接塞进 Prompt 里并不现实，所以只能切 chunk、做 embedding、向量检索、top-k 拼接，再让模型基于这些片段回答。

但今天情况已经变了。

截至 2026 年 5 月，很多主流模型已经把上下文窗口推到了 1M 级别，甚至更高。OpenAI GPT-5.5 模型页标注了 1,050,000 context window 和 128,000 max output tokens；Anthropic Claude 模型概览显示 Claude Opus 4.7、Claude Sonnet 4.6 支持 1M tokens context window；Google Gemini 3.5 Flash和Gemini 3.1 Pro Preview都标注 input token limit 为 1,048,576；xAI Grok 4 Fast发布时也提到 2M token context window；Meta Llama 4 Scout甚至宣称支持 10M context window。

所以问题来了：长上下文会最终杀死 RAG 吗？

我的判断是：不会。

长上下文会杀死一批省流版 RAG，也会让很多粗糙的 embedding + top-k 方案失去意义，但它不会杀死真正工程化的 RAG。因为长上下文解决的是能不能放进去，RAG 解决的是该放什么、从哪里来、谁能看、是否可信、如何引用、如何降成本、如何被审计。

这两个东西不是简单替代关系。更准确地说，未来不是 RAG vs Long Context，而是 RAG for Long Context。

百万级上下文确实会让老式 RAG 失去借口

如果还用 2023 年的眼光看 RAG，确实会误判。

那时候上下文窗口很小，很多系统做 RAG 的核心理由就是省 token。文档太长，模型读不下，于是我们先把文档切成很多片段，再通过向量检索找出最相关的几段，拼到 Prompt 里。

这个方案在当时很合理，因为模型窗口有限，RAG 是绕过窗口限制的工程方案。

但现在，长上下文已经不是补丁能力，而是前沿模型的基础能力。

模型或厂商当前公开标注的上下文能力说明
OpenAI GPT-5.51,050,000 context window，128,000 max output tokens面向复杂专业任务、编码和长上下文推理
Claude Opus 4.7 / Sonnet 4.61M tokens context windowAnthropic 官方模型表中标注 Opus 4.7、Sonnet 4.6 均为 1M
Gemini 3.5 Flash1,048,576 input tokens，65,536 output tokens面向多步 Agent、编码循环和长任务
Gemini 3.1 Pro Preview1,048,576 input tokens，65,536 output tokens面向复杂推理、工具调用和工程任务
Grok 4 Fast2M token context window面向搜索、工具调用和 Agent 任务
Llama 4 Scout10M context windowMeta 官方称其适合多文档总结、用户活动解析和大型代码库推理
Mistral Large 3256K context开源权重的通用多模态模型
Cohere Command A256K context windowCohere 明确把 RAG、Agent、工具调用列为核心使用场景

从这些数据看，长上下文确实已经开始吃掉一部分 RAG 场景。

比如用户只上传一份 PDF、一组合同、一个需求文档、一个代码仓库片段，然后希望模型做整体分析，这时候直接把完整材料放进长上下文模型，往往比先切片、检索、拼接更自然。

因为原文的章节结构、上下文连续性、前后约束都还在。模型看到的不是一堆被切碎的片段，而是完整材料。

这类场景里，长上下文会明显削弱传统 RAG 的必要性。

但这只能说明一件事：低质量 RAG 的生存空间变小了，不代表 RAG 本身没有价值。

RAG 从来不只是为了省 token

很多人把 RAG 理解成一种压缩上下文的方法：原文太长，塞不下，所以先检索几段再塞给模型。

这个理解只对了一半。

RAG 的核心并不是单纯省 token，而是让模型接入外部知识。经典论文 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks 提出的就是把预训练模型的 parametric memory 和外部索引里的 non-parametric memory 结合起来，让生成过程可以访问外部知识，而不是只依赖模型参数里已经记住的内容。

翻译成工程语言就是：模型不是唯一的知识容器，系统可以在模型外部维护一套可更新、可追溯、可替换、可权限控制的知识层。

这才是 RAG 真正的价值。

它不只是帮我们少传一点 token，而是解决这些问题：

  • 外部知识可以随时更新，不必等模型重新训练
  • 知识来源可以被记录、引用和审计
  • 不同用户、团队、租户可以看到不同材料
  • 可以把文档、数据库、工单、CRM、代码仓库、知识库统一接入
  • 可以在生成前做权限过滤、来源过滤、时间过滤和可信度排序
  • 可以在回答后追踪模型到底引用了哪些证据
  • 可以对召回、重排、引用和答案质量做评估

这些能力不是上下文窗口变大就会自动出现的。

长上下文让模型能读更多东西，但它不会自动帮你判断哪些东西该读、哪些东西不能读、哪些东西已经过期、哪些东西来自高可信来源、哪些东西对当前用户不可见。

所以，长上下文解决的是容量问题，RAG 解决的是上下文治理问题。

真正危险的是省流版 RAG

长上下文最先淘汰的，不是 RAG，而是那些没有工程含量的 RAG。

第一类是纯粹为了绕过上下文限制的 RAG。

以前模型只有 8K、16K、32K，上下文塞不下一本文档，只能切 chunk 做检索。现在模型能接收几十万甚至上百万 token，这类方案的必要性会明显下降。

第二类是简单 embedding + top-k RAG。

它通常只有三步：

  • 把文档切成 chunk
  • 用 embedding 做向量检索
  • 取 top-k 拼进 Prompt

这种方案看起来像 RAG，但很多时候只是把材料切碎后随机捞几段。它没有 query rewrite、没有 hybrid search、没有 rerank、没有权限过滤、没有证据聚类、没有冲突检测、没有引用校验，也没有评估闭环。

在长上下文模型面前，这类 RAG 很容易变成负优化。

原文可能有完整章节结构、上下文铺垫、定义边界和前后约束，结果被 chunk 切碎以后，模型只看到了几段片段。更糟的是，top-k 召回可能漏掉关键段落，让模型基于不完整证据回答。

此时，粗糙 RAG 反而不如直接把原文交给长上下文模型。

第三类是只把 RAG 当省钱工具的系统。

它的目标不是提高事实质量，而是少传 token。这类系统通常不会关心召回率、证据覆盖率、引用准确率、回答可追溯性，也不会关心检索失败时该如何降级。

长上下文一出现，这些系统就会显得很尴尬。因为它们没有真正解决知识治理问题，只是在上下文不够长的时代做了一层临时补丁。

能放进去，不等于模型真的能用好

长上下文最大的问题是：窗口长度不是注意力质量。

模型能接收 1M token，不代表它一定能稳定找到最关键的 300 token，也不代表它能在海量上下文中可靠完成证据比较、冲突判断和跨文档推理。

Lost in the Middle 这篇论文专门研究模型如何使用长上下文。它发现，相关信息在上下文中的位置会显著影响模型表现。模型通常更擅长使用开头和结尾的信息，当关键信息位于中间时，性能会明显下降，即使是明确支持长上下文的模型也会遇到这个问题。

NoLiMa 进一步指出，很多 Needle in a Haystack 类长上下文评测其实存在字面匹配优势，模型可以靠关键词重合找到答案。NoLiMa 刻意减少问题和证据之间的字面重叠，让模型必须通过语义关联定位信息，结果显示不少长上下文模型在上下文变长后性能明显下降。

这对工程落地非常关键。

很多长上下文 Demo 看起来很强，是因为问题和答案之间存在非常明显的关键词匹配。比如问某个名字、编号、日期、变量名，模型能在长文本里找到它。

但真实业务问题往往不是这样。

用户问的是：

  • 这份合同里有没有隐藏的付款风险？
  • 这家公司适不适合合作？
  • 这段代码为什么会在并发下出问题？
  • 这几份制度之间有没有冲突？
  • 最近的客户投诉说明产品哪里出了问题？

这些问题不是在长文本里找一个词，而是要理解、比较、归因、判断和引用。

上下文越长，噪音越多。模型越需要一个干净、有结构、有优先级的证据包。

这正是 RAG 还会继续存在的原因。

研究结论也不是长上下文单方面胜出

现在关于 Long Context 和 RAG 的研究，并不是单边倒向某一边。

Long Context vs. RAG for LLMs 这篇评估论文指出，在一些问答基准里，Long Context 通常优于 RAG，尤其是 Wikipedia 类问题；总结式检索可以接近 Long Context，而普通 chunk-based RAG 表现更弱。但论文也指出，RAG 在对话型和一般查询场景中仍有优势。

In Defense of RAG in the Era of Long-Context Language Models 则强调，极长上下文会带来注意力稀释和答案质量下降风险。论文提出的 OP-RAG 机制显示，检索片段数量增加时，答案质量并不是线性变好，而是可能出现先上升后下降的倒 U 型曲线，也就是存在一个证据数量的甜点区间。

LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs 的结论更像工程现实：RAG 和 Long Context 没有谁是银弹，效果取决于上下文长度、任务类型、模型能力、检索质量和路由策略。

把这些研究放在一起看，结论其实很清楚：

  • 如果材料规模不大，任务需要整体理解，Long Context 很强
  • 如果材料很大、经常变化、权限复杂，RAG 更稳
  • 如果 RAG 只是 chunk top-k，长上下文可能更好
  • 如果 RAG 做了检索、重排、过滤、聚类、引用和评估，它仍然很有价值
  • 最好的方案往往不是二选一，而是先用 RAG 选证据，再用长上下文推理

所以问题不应该是长上下文会不会杀死 RAG，而应该是：我们还需不需要一个上下文治理层？

答案是需要，而且会越来越需要。

企业场景里，RAG 更像权限系统和证据系统

个人使用 AI 时，很容易觉得直接塞全文就够了。

比如我上传一份 PDF，让模型总结，这种场景确实不一定需要复杂 RAG。文件数量有限，权限也简单，用户自己上传的材料就是当前任务的上下文。

但企业系统不是这样。

企业知识通常有几个特点：

  • 数据来源很多，不只是一份文档
  • 内容持续变化，不是静态文件
  • 权限边界复杂，不同角色能看的内容不同
  • 输出需要可追溯，不能只给一个自然语言结论
  • 成本和延迟要可控，不能每次请求都塞全部资料
  • 高风险任务需要审计、复盘和人工确认
  • 历史版本、过期文档、草稿文档和正式文档不能混在一起

比如做一个法律 AI 产品，用户问某个合同条款是否有风险。系统不能直接把整个知识库塞给模型。它至少要先判断：

  • 当前用户属于哪个 workspace
  • 用户有没有权限查看这份合同
  • 合同是不是正式版本
  • 是否存在更新后的补充协议
  • 相关法规、判例、公司模板是否过期
  • 哪些证据可以进入模型上下文
  • 哪些内容需要脱敏
  • 最终答案引用了哪些段落
  • 高风险判断是否需要人工确认

这些不是模型上下文窗口能解决的问题，而是系统工程问题。

长上下文解决的是读得多，RAG 解决的是读得对。

更好的架构是让 RAG 成为长上下文的前置治理层

未来更好的架构不是把 RAG 和 Long Context 对立起来，而是让 RAG 给长上下文提供更干净的材料。

也就是说，RAG 不再只是 top-k chunk 拼接器，而是 Context Engineering 的一部分。它负责在模型推理前完成证据选择、权限过滤、冲突识别、上下文打包和可追溯记录。

可以把链路理解成这样：

flowchart LR
  A[用户问题] --> B[意图识别]
  B --> C[权限过滤]
  C --> D[多路召回]
  D --> E[重排与去重]
  E --> F[证据聚类与冲突标记]
  F --> G[上下文打包]
  G --> H[长上下文模型推理]
  H --> I[带引用的答案]
  I --> J[日志、评估、回归]

  style A fill:#FDECC8,stroke:#7A5C2E,color:#2B2118
  style B fill:#DDEBFF,stroke:#3B5F9A,color:#172033
  style C fill:#FFE0E0,stroke:#B45454,color:#331717
  style D fill:#E4F7DE,stroke:#5D8A4B,color:#173316
  style E fill:#E9E3FF,stroke:#6E5BA8,color:#201833
  style F fill:#FFF1B8,stroke:#A98218,color:#33260A
  style G fill:#DDF7F4,stroke:#4B8A83,color:#153331
  style H fill:#F1E1FF,stroke:#8A5AB5,color:#241333
  style I fill:#EAF4FF,stroke:#4E78A8,color:#132433
  style J fill:#EFEFEF,stroke:#777777,color:#222222

这条链路的重点不是多画几个节点，而是把责任拆开。

RAG 负责把外部世界变成可用证据，长上下文模型负责在证据包里完成更复杂的推理和生成。

这和早期 RAG 的区别很大。早期 RAG 像一个检索插件，只管取几段文本。新的 RAG 更像上下文编排层，它要决定什么内容进入上下文、以什么顺序进入、带着什么元数据进入、哪些冲突要提示模型、哪些内容不能进入。

什么时候应该优先用长上下文

不是所有场景都需要复杂 RAG。

如果资料总量能放进上下文，而且任务需要全文理解，可以优先使用长上下文。

典型场景包括：

  • 单篇 PDF 总结
  • 一份合同审查
  • 几份合同对比
  • 一篇论文阅读
  • 一个产品需求文档分析
  • 一组代码文件的整体理解
  • 一次性尽调材料梳理

这些场景的核心不是从海量知识库里找材料，而是对已知材料做整体理解。此时，直接让模型看到完整上下文，往往比先切 chunk 再召回更稳定。

但这里也有一个前提：不要乱塞。

更好的做法是先做结构化整理：

  • 给文档加目录
  • 保留章节顺序
  • 给关键段落编号
  • 标注文档来源和版本
  • 把任务目标放在上下文前面
  • 把关键约束和输出格式放在靠近模型回答的位置
  • 对超长材料做分层摘要，而不是无脑拼接

长上下文不是让我们停止做上下文工程，而是让上下文工程有了更大的操作空间。

什么时候必须保留 RAG

如果资料规模很大、经常变化、权限复杂、需要引用和审计，就应该保留 RAG。

典型场景包括：

  • 企业知识库问答
  • 客服知识库
  • 法律法规检索
  • 投研资料库
  • 产品文档中心
  • 内部制度问答
  • 工单和 CRM 分析
  • 多租户 SaaS 产品
  • 带权限隔离的 AI 助手

这些场景里，真正的问题不是模型读不下，而是系统不能乱读。

用户问一个问题，系统需要先知道哪些材料和这个问题有关，哪些材料对当前用户可见，哪些材料已经过期，哪些材料是正式版本，哪些材料只是草稿，哪些材料来自可信来源。

如果没有 RAG 或类似的检索治理层，长上下文反而会放大风险。

因为模型能吃进去的东西越多，系统越要控制它吃进去的是什么。

RAG 的工程重点要从召回变成治理

接下来 RAG 真正需要升级的地方，不是再写一个更复杂的 Prompt，而是把上下文治理做扎实。

第一，检索不能只靠向量相似度。

真实业务里，关键词、时间、来源、权限、文档类型、版本状态都很重要。很多问题不是语义相似就足够，而是要找到最新、正式、可信、可访问的证据。

第二，chunk 不能随便切。

合同、制度、代码、论文、客服工单都有自己的结构。切片策略应该尊重标题、章节、表格、代码块、条款编号和上下文边界。否则检索出来的片段可能语义不完整。

第三，进入长上下文前要重排和聚类。

不要把相似内容重复塞进去，也不要把互相冲突的材料混在一起不提示模型。更好的做法是把证据按主题聚类，把冲突点显式标出来，让模型知道哪里一致、哪里不一致。

第四，答案必须带引用。

只要是知识库问答、法律分析、投研分析、合规判断，就不能只输出一个自然语言结论。系统要告诉用户：这个判断来自哪些文档、哪些段落、哪个版本、什么时间。

第五，要有评估闭环。

RAG 不是接上 embedding 就完事了。我们需要评估召回率、引用准确率、答案一致性、拒答质量、事实冲突处理、延迟和成本。没有评估，RAG 的质量只能靠感觉。

长上下文真正改变的是 RAG 的形态

以前的 RAG 是这样的：

用户问题 -> 向量检索 -> top-k chunk -> 拼进 Prompt -> 模型回答

这种形态会越来越弱。

未来的 RAG 更应该是这样：

用户问题 -> 意图识别 -> 权限过滤 -> 多路召回 -> 重排去重 -> 证据聚类 -> 冲突检测 -> 上下文打包 -> 长上下文推理 -> 引用输出 -> 日志评估

大家好 👋，我是 Moment，目前正在使用 Next.js、NestJS、Tiptap 和 LangGraph 开发 DocFlow。

DocFlow 是一个面向 AI 全栈场景的协同文档平台，主要围绕富文本编辑、实时协作和 AI 工作流展开。

如果你对 AI 全栈开发、Tiptap、LangGraph 或协同文档感兴趣，欢迎添加我的微信 yunmz777 一起交流。觉得项目还不错的话，也欢迎给 DocFlow 点个 star ⭐

eb44cd75f896ed5cf3ba3aad76fb3fdb.png

这时候，RAG 不再是为了弥补模型上下文短，而是为了让模型上下文更干净、更可信、更有结构。

长上下文越强，越需要好的上下文治理。因为模型能吃进去的东西越多，系统就越要控制它吃进去的是什么。

否则，1M 上下文不会带来 1M 的有效信息，只会带来 1M 的噪音、权限风险和调试困难。

我会怎么选型

如果是个人工具、单文档分析、小规模资料整理，我会优先考虑长上下文。

因为这种场景里，文档数量有限，权限简单，任务目标明确，直接让模型读完整材料反而更自然。

如果是企业知识库、法务系统、投研系统、客服系统、内部助手，我会优先考虑 RAG + 长上下文的混合架构。

因为企业场景里，质量问题往往不是上下文不够长，而是证据不够准、权限不够稳、引用不够清楚、版本不够可控、审计链路不够完整。

如果是高风险任务，比如法律、金融、医疗、合规，我不会只依赖长上下文。

这类系统必须保留证据引用、冲突提示、置信度、人工确认和可回放日志。否则模型读得越多，越可能把过期材料、噪声材料和不该看的材料一起带入判断。

总结

长上下文不会杀死 RAG，但会杀死低质量 RAG。

如果一个 RAG 系统只是为了省 token，只做 embedding + top-k，没有权限、没有重排、没有引用、没有评估、没有冲突处理，那么它确实会被长上下文模型快速替代。

但真正的 RAG 不会消失。它会从检索插件升级成上下文治理层，负责证据选择、权限过滤、版本控制、引用追踪、成本控制和质量评估。

未来更稳的方案不是在 Long Context 和 RAG 之间二选一，而是把它们组合起来：先用 RAG 找到高质量、可访问、可追溯的证据，再交给长上下文模型做跨文档推理和生成。

所以，长上下文不是 RAG 的终点，而是 RAG 变得更工程化的起点。

avatar
文章
阅读
粉丝