你团队花了三个月搭建了最复杂的RAG管道：分块、嵌入、向量库、相似度检索、后处理过滤……一切看起来都很“专业”。可当Claude Opus 4.6在2026年3月13日以1M token（75万字、3000页、整套代码库+文档）正式GA且无价格倍率后，同一套任务的错误率反而上升了。你起初也和大多数AI工程师一样，把问题归咎于“向量漂移”或“chunk边界问题”，继续在RAG上堆更多工程。后来我把@nyk_builderz（Builderz联合创始人）2026年4月6日这篇长帖完整读完，并用Claude Code本地复现了1M上下文 vs RAG的对比实验，才发现：真正的瓶颈根本不是检索，而是我们还在用“稀缺时代”的思维应对“丰裕时代”的上下文。

RAG曾经是天才 workaround——上下文窗口太小，只能切块嵌入再检索注入。现在上下文窗口500x暴增，70%的LLM错误来源已从“模型不够聪明”彻底转向“上下文 curation 不够好”。默认“任何项目都要RAG”的认知，已经成了新的技术债。

上下文爆炸不是 incremental，而是架构级跃迁

GPT-3时代只有4K token，RAG是唯一解。现在Claude Opus 4.6 1M、Gemini 3 Pro 2M，三年增长500倍。这不再是“窗口变大”，而是整个应用架构的底层假设被重写：从“如何把知识塞进来”变成“如何把正确知识排好序、去掉噪声、放在正确位置”。

70%以上的生产错误来自不完整、无关或结构糟糕的上下文，而非模型本身。模型已经足够聪明，问题是它们“看到”的东西不对。

长上下文直接取代RAG的场景：500K token以下的确定性知识库

对于有界文档集——单个代码库、合同包、产品文档库——你可以彻底跳过RAG全流程：不分块、不嵌入、不向量库、不相似搜索，直接加载原文件提问。

Claude Code就是活例子：它不依赖向量搜索做代码导航，而是直接读文件，需要时再agentic search，最后靠compaction管理上下文。结果更快、更简单、更准确。

实践阈值很清晰：文档总量低于500K token（约37.5万字）时，长上下文几乎总是优于RAG。架构更简、失败模式更少、无嵌入漂移、无chunk边界 artifact。

RAG依然不可替代的四大场景：规模、成本、新鲜度、权限

RAG没有死，只是被重新定位了。

1. 超窗口规模：企业Wiki、法律档案、医学文献动辄百万文档，永远塞不进窗口。
2. 海量查询成本：优秀RAG每次只拉5-20个chunk（2K-10K token），比全量上下文省50-200倍token，规模化后一年省几十万美金。
3. 高频更新：新文档秒级索引，长上下文需要重传全部。
4. 访问控制：RAG可在检索前按用户权限过滤，长上下文目前无原生文档级权限机制。

最务实的做法是混合：先RAG缩小范围，再把精选子集完整塞进窗口，而不是继续碎成chunk。

没人警告你的“上下文腐烂”：Lost in the Middle在1M时代被放大10倍

Claude在1M token上检索准确率号称90%，听起来很强——直到你意识到1/10的查询会直接答错。更致命的是模型注意力分布极不均匀：强烈偏好开头和结尾，中间几百K token基本被“忽视”。

斯坦福2023年就发现的“Lost in the Middle”现象，在1M窗口里成了灾难：中间区涵盖几十万token。Anthropic自己的MRCR v2基准显示，256K到1M之间准确率直接掉15-17个百分点。1M满窗口时，1/4的多needle检索任务失败。

Anthropic内部把这叫“context rot”。GitHub上甚至有人给Claude Code提issue，认为“1M上下文窗口”和实际可靠200-256K的有效上下文之间的差距已经构成缺陷。Princeton HELMET基准也证实，大多数模型在总结任务上超过32K就开始显著退化。

实战 takeaway：1M是理论上限，可靠区间在500-700K。关键信息必须放在开头或结尾，中间位置纯属赌博。

我把四根支柱用Mermaid重绘成生产级上下文工程框架（直接复制到Mermaid Live即可）：

长上下文 vs RAG 真实权衡矩阵（2026年生产视角）

上下文工程的本质：从单Query Prompt到全系统信息环境设计

Prompt工程只优化单次查询，上下文工程则是设计AI运行的整个信息环境。四根支柱缺一不可，大多数团队只做了第一根就喊“模型不行”。

在生产环境切换到上下文工程前，你必须先做的三件事

1. 盘点当前知识库总token，低于500K的直接切换长上下文，删除RAG管道。
2. 把关键信息强制放在系统Prompt最前或最后一条消息，避开中间区。
3. 建立质量监控闭环：每次任务后记录检索准确率、幻觉率、token效率，形成可迭代的上下文rubric。

上下文窗口的爆炸，把AI应用从“检索工程”时代推到了“上下文工程”时代。懂的人已经把系统复杂度砍掉70%，准确率却在上升；还在默认RAG的团队，却在为过时的管道持续烧钱。

你在构建AI应用时，是继续默认“任何项目都要RAG”，还是已经开始根据文档规模和更新频率做架构决策？欢迎在评论区分享你目前最大的上下文工程挑战——是检索质量、context rot，还是token成本？我们一起把AI系统从“复杂但正确率低”真正推向“极简且可靠”。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。