RAG曾是LLM应用的标准答案。文档切成小块，向量化，检索，注入上下文——这套流程在上下文窗口只有4K tokens时是唯一选择。但时代变了。

Claude Opus 4.6的上下文窗口达到100万tokens，约75万单词、3000页，足以装下一整个代码库加文档。GPT-3到今天，context容量增长了500倍。这是架构级别的跃迁，不是增量优化。

与此同时，错误来源也变了。超过70%的LLM应用错误现在来自糟糕的上下文设计——信息不完整、不相关、或结构混乱——而不是模型本身能力不足。瓶颈从「模型不够聪明」转移到了「上下文不够好」。

RAG的适用范围正在急剧收缩

当上下文窗口从稀缺变成充裕，「把所有文档塞进context」就成了更简单的方案。无需chunking，无需embedding drift，无需处理分块边界问题。简单架构，少了更多失败模式。

对于bounded document sets——特定的代码库、合同包、产品文档库——可以直接跳过整个RAG pipeline。Claude Code正是这样运作的：直接读文件，需要时做agentic search，通过compaction管理context，而不是靠向量搜索做代码导航。

实际操作中有明确阈值：文档总量在50万tokens（约37.5万单词）以下时，long context几乎总是优于RAG。这个判断基于：RAG的50-200倍token压缩节省，在小文档场景下抵不上检索精度损失。

RAG没有死，只是重新定位

三种场景RAG仍有结构性优势：

规模超出窗口。企业wiki、法律档案、医学文献——这些永远不会塞进一个context窗口，RAG是必然选择。

成本敏感的批量查询。设计良好的RAG每次检索只返回2000-10000个tokens，50-200倍的输入token减少在规模化时是真实的成本差异。

高频更新的知识库。RAG索引新文档只需秒级，long context需要重新上传全量内容。对于每小时都有知识更新的场景，RAG的增量索引是结构性优势。

访问控制。RAG管道可以在检索前按用户权限过滤文档，long context没有内置的文档级访问控制机制。

实用建议：大多数团队应该两者结合——用RAG做初步筛选，然后把相关子集全文加载，而不是进一步chunking。

"Lost in the Middle"：没人警告的隐藏陷阱

即使模型宣称支持100万tokens上下文，也存在不等Attention问题。Stanford在2023年的研究记录了这种现象：模型对上下文开头和结尾过度关注，对中间区域严重忽视。

在100万token的窗口下，「中间」可以覆盖数十万tokens。Anthropic自己的MRCR v2基准显示，从256K token扩展到1M，有15-17个百分点的性能下降。即使在专门设计来测试精确检索的合成基准上，四分之一的多跳检索也会失败。

Anthropic称之为「context rot」。GitHub上有人直接指出：「100万上下文窗口」和实际可靠的「约20-25万有效上下文」之间存在差距，应该被定性为缺陷。

实用阈值：可靠性能在50-70万token范围。如果有必须模型使用的重要信息，放在开头或结尾，中间位置是赌博。

Context Engineering的四个支柱

上下文工程不是一种技巧，是 discipline——设计AI运行环境整体信息环境的实践。四个支柱：

Knowledge Retrieval。如何找到并筛选正确信息。方法可以是RAG、agentic search、直接读文件、或MCP server查询。方法不重要，重要的是结果：搞到高信号、低噪音的上下文。

Memory Management。如何在多轮对话和session之间持久化信息。CLAUDE.md文件、auto-memory、skill文档、compaction摘要。没有记忆管理，每个长session都会淹死在陈旧上下文里。

Context Orchestration。如何在窗口内结构化和排序信息。文档位置优先级、token预算。目标：「找到最小可能的高信号token集合，最大化达成期望结果的概率」。

Quality Monitoring。如何衡量上下文是否有效。检索准确率、幻觉率、任务完成率、token效率。大多数团队完全跳过这一项——然后在输出质量下降时怪罪模型。

Prompt engineering优化单个查询。Context Engineering管理整个系统。产出质量差异不是增量级的，是结构性的。