这两年只要模型上下文一变长，市场上就会周期性出现一种说法：RAG 要死了。现在上下文都到 1M 甚至更高了，文档直接全塞进去不就行了吗？这个说法听起来很顺，但工程上其实站不住。我的判断是：超长上下文会改变知识接入层的设计，但不会替代 RAG，它真正改变的是“接入成本曲线”而不是“信息检索的基本规律”。
这不是抬杠，而是很多团队正在真实面对的架构问题。Anthropic 在 2026 年 2 月发布 Opus 4.6 时，把 1M token context 拉进了 beta；更早之前，Google 也已经把 2M context 作为 Gemini 路线的一部分推进。上下文窗口继续变长几乎是确定趋势，但把“窗口更长”直接翻译成“RAG 没价值了”，会让不少团队在系统设计上走弯路。
为什么“全塞进去”这个想法总是很诱人
因为它看起来特别省事。你不需要做切片，不需要做 embedding，不需要搭检索层，也不用处理召回不准、重排序、索引更新这些麻烦事。知识库、代码库、会议记录、产品文档，直接一股脑交给模型，产品 Demo 往往还能跑得挺顺。
对于很多早期产品，这种做法也确实有现实价值。尤其是数据规模不大、更新频率不高、任务更偏分析和总结的时候，长上下文可以显著降低你搭第一版系统的复杂度。以前要做一整套检索和索引管线，现在可能先把几十万 token 的资料打包进去，就能完成一次像样的问答、总结或者代码分析。
所以这里不是要唱反调说长上下文没用。恰恰相反，它非常有用，而且会改变很多产品的起步方式。问题只在于：它改变的是你什么时候必须引入检索层，而不是让检索层永久消失。
RAG 没被消灭，因为“信息多”从来不是唯一问题
RAG 的价值，常常被粗暴理解成“因为模型装不下全部信息，所以要先检索”。这只说对了一半。更关键的一半是：即便模型装得下，也未必应该全部喂进去。因为实际系统还要考虑成本、延迟、噪声、权限和结果稳定性。
先说成本。上下文窗口不是白送的。能放 1M token，不等于每次都该真塞 1M token。哪怕模型价格持续下降，大上下文调用依然会明显放大推理成本，尤其是在高频查询、批量任务或者多人团队场景里。对个人开发者来说，这一点尤其致命。很多看起来体验很顺的“全量输入”方案，一旦进入真实使用频率，成本会立刻从 Demo 预算变成业务问题。
再说噪声。更多上下文不自动等于更好答案。上下文越大，模型越容易被无关信息干扰，也越考验提示结构和文档组织质量。很多团队以为自己是输给了模型能力，其实是输给了信息装载方式。把一堆历史文档、旧策略、过期讨论、重复内容一起喂进去，模型不迷糊才奇怪。
还有权限问题。现实里的知识库很少是完全开放的。不同用户、部门、角色能看到的数据并不一样。RAG 层除了做检索，本质上也是一个权限过滤层。长上下文并不能自动帮你解决“哪些内容这个用户此刻可以看”这个问题。你要是不做，最后很容易把“模型上下文管理”变成“权限事故制造机”。
真正会变化的，是知识接入层的分工
以前做知识系统，很多团队一开始就得上 RAG，因为不这么做根本跑不起来。现在不一样了。上下文足够长之后，系统可以有一个新的演化路径：先用长上下文做原型和小规模场景验证，再在规模、成本或权限压力出现时，把检索、缓存、摘要、索引这些模块逐步补上。
这其实是件好事，因为它降低了产品冷启动门槛。你不必一开始就设计一套过重的架构，也不用在需求还没验证前先陷进 embedding 选型、chunk 策略和召回指标的细节泥潭。很多个人开发者过去做不了知识产品，不是没有想法，而是第一版基础设施太重。长上下文把这条起跑线往前挪了。
但一旦产品进入长期使用，接入层还是会重新长出来，只是形式会更灵活。未来更常见的架构，不一定是“纯 RAG”或者“纯长上下文”，而是分层混合：热点信息和当前任务相关材料直接放进上下文，冷数据靠检索召回，超长历史通过摘要压缩，结构化数据走 SQL 或 API，敏感数据走严格权限过滤。真正成熟的系统会同时用这几种手段，而不是押宝某一种纯路线。
对代码场景尤其如此
很多人喜欢拿代码库举例，说上下文长了以后，整个 repo 都能扔进去，Agent 自然就更懂项目。这个方向确实有进展，但也别高估。代码理解从来不只是“看见全部文件”这么简单，还包括依赖关系、变更历史、运行时行为、测试覆盖、权限和提交边界。把整个仓库塞进去，能提升理解起点，不代表能替代检索、索引和工具调用。
特别是在大型仓库里，真正有价值的不是让模型把所有代码都读一遍，而是让它在正确的时候看到正确的那部分代码，并且能根据符号、引用、调用链、最近改动和测试结果持续更新判断。这里依然需要检索层、代码图谱或工具层配合。上下文更长，只是让第一步更顺，不会让后面的工程问题自动消失。
个人开发者现在最该利用的，不是“替代 RAG”，而是“推迟复杂度”
这是我觉得最关键的一点。很多个人开发者一看到新技术，就忍不住问“它会不会替代旧架构”。这个问题很容易把人带偏。更现实的问题是：它能不能让你在前 30 天里少做一些重基础设施，把时间先花在验证用户需求上？从这个角度看，长上下文非常值得用。
你完全可以先用长上下文做一个垂直知识产品 MVP，先服务几十个用户，先看他们到底在问什么、哪些内容最常用、哪些问题需要实时信息、哪些地方会碰到权限边界。等这些信号出来，再决定哪里上检索、哪里做缓存、哪里需要结构化索引。这样做不够“架构优雅”，但非常符合独立开发的生存逻辑。
结论：长上下文很重要，但它更像架构缓冲器，不是架构终结者
我的结论很明确：1M 级上下文会实打实改变知识产品和代码产品的设计方式，尤其会降低原型开发和小规模部署的门槛。但它不是 RAG 杀手，更不是“以后都不用做检索了”的通行证。
真正发生的变化是，知识接入层开始从“必须先搭好”变成“可以按压力逐步长出来”。这对开发者是好消息，对个人开发者尤其是好消息。你可以更快开始，更晚背上复杂度；但当产品真的跑起来以后，检索、权限、缓存、摘要、结构化访问这些老问题，还是会一个不少地回来。区别只是，你终于可以在更接近业务现实的时候，再去解决它们。