Claude 没有用 RAG为什么 Anthropic 选择了另一条路文章目录 Claude 没有用 RAG为什么 Anthropic 选择了另一条路 一个让很多人困惑的问题 先搞清楚Claude 的上下文窗口是什么❓ 那为什么大家还在用 RAG硬伤一「Lost in the Middle」——中间的信息会被忽视硬伤二成本和延迟随 token 数量飙升硬伤三海量知识根本装不进去✅ 那 Claude 为什么选择直接用上下文原因一长上下文的优势是 RAG 根本做不到的原因二透明度和可控性——CLAUDE.md 的哲学原因三Prompt Cache 让长上下文的成本大幅下降⚖️ 真正的决策框架什么时候用哪个长上下文明显更优的场景RAG 明显更优的场景2026 年的最佳实践两者结合 未来长上下文会干掉 RAG 吗 总结速查 最后先说结论Claude 没有在内部给自己搭一套 RAG 系统来记住东西。它处理长文档、维持上下文的方式是把所有内容直接塞进上下文窗口。这个选择不是技术落后而是一个有意为之的架构决策——背后是一场 2026 年 AI 工程界最核心的争论长上下文窗口 vs RAG到底谁更好 一个让很多人困惑的问题如果你做过 AI 应用开发肯定知道 RAG检索增强生成——把文档切块向量化存到向量数据库用户问问题时检索最相关的片段喂给模型。大多数人理所当然地认为Claude 处理长文档时也是类似的机制在后台有一个向量检索系统从海量内容里捞出相关的段落。但实际上完全不是这样。你上传一份 100 页的 PDFClaude 是把那 100 页全部读进去的。你把一个代码仓库扔给 Claude Code它是把文件列表和关键文件内容直接加载进上下文的。没有向量库没有检索步骤就是全部装进去。这就引出了本文要讨论的核心问题为什么这样做有什么优缺点什么时候该用 RAG什么时候该用长上下文 先搞清楚Claude 的上下文窗口是什么要理解这个选择先要搞清楚 Transformer 模型的工作方式。Claude 每次处理请求看到的是一个平铺的 token 序列[System Prompt] [你上传的文档] [对话历史] [你的问题] ↑ ↑ ↑ ↑ 系统指令 文档内容 历史消息 当前输入 ↓↓↓ 全部进入同一个注意力计算 ↓↓↓模型对这个序列里的每一个 token都能直接计算注意力attention——也就是我现在生成这个词应该关注上下文里的哪些位置。没有检索步骤没有中间层所有信息都是第一公民。Opus 4.6/4.7 的上下文窗口是200K token约等于 150 万字够装下大多数长文档。Sonnet 4.6 是1M token。❓ 那为什么大家还在用 RAG如果长上下文这么强RAG 不就没用了吗不是的。长上下文有三个硬伤硬伤一「Lost in the Middle」——中间的信息会被忽视这是 2023 年斯坦福大学的研究发现后来在每个主流模型上反复被验证模型对上下文的关注度呈 U 形分布。关注度 ↑ 高 |████ ████ | ███ ███ 低 | ███████████████████████ -----------------------------------→ 开头 中间被忽视 结尾实际测试数据一个 48K token 的精准检索结果在标准 Benchmark 上的表现比直接丢 117K token 的完整文档高出 13 个 F1 值。信息量翻了一倍多但性能反而下降了——因为相关信息被淹没在了中间。对于 Claude 处理 PDF如果关键信息恰好在第 40 页中间位置它捕捉到的概率确实低于开头和结尾。硬伤二成本和延迟随 token 数量飙升Transformer 的注意力机制计算复杂度是O ( n 2 ) O(n^2)O(n2)Attention ( Q , K , V ) softmax ⁣ ( Q K T d k ) V \text{Attention}(Q, K, V) \text{softmax}\!\left(\frac{QK^T}{\sqrt{d_k}}\right)VAttention(Q,K,V)softmax(dk​​QKT​)V序列长度翻倍 → 计算量翻四倍。用数字说话方案每次请求 token 数延迟每次费用估算RAG精准检索~5K1–2 秒$0.05长上下文200K200K15–30 秒$1.00长上下文1M1M60–120 秒$5.00日处理 10,000 次查询的企业选长上下文方案一年光这一个用例就要多花几百万。硬伤三海量知识根本装不进去一个中型企业的内部文档库可能有几百 GB 的 Word、PDF、邮件、Slack 消息。就算是 1M token 的上下文窗口也只能装下这个库的不到 0.01%。RAG 存在的根本原因把无界的知识映射到有界的上下文窗口。✅ 那 Claude 为什么选择直接用上下文说完了长上下文的缺陷再说为什么 Claude 在很多场景下仍然选择不用 RAG。原因一长上下文的优势是 RAG 根本做不到的RAG 的工作方式是切块检索——把文档切成 chunk搜索最相关的几个。但有一类任务答案不在任何单个 chunk 里而在文档的整体结构里❌ RAG 做不好的任务 - 这份合同里有没有对乙方不利的隐含条款 → 需要理解整份合同的逻辑单个 chunk 没有意义 - 这段代码里有没有架构级的安全问题 → 漏洞可能是 A 文件的函数调用了 B 文件的参数跨 chunk 不可见 - 这本书的第二章和第九章的论点有矛盾吗 → 跨 chunk 的关系RAG 看不到这些任务只有把全文装进上下文模型才能做全局推理。一篇权威技术文章对此的总结非常精辟“RAG 做的是找长上下文做的是想。”原因二透明度和可控性——CLAUDE.md 的哲学Claude Code 里有一个非常典型的设计CLAUDE.md 文件。它的工作方式是用户把项目规范、代码风格、历史决策写在一个 Markdown 文件里Claude Code 每次启动时自动把这个文件的内容加载进上下文。这不是 RAG。这就是一个文本文件直接注入没有向量检索没有黑盒。# CLAUDE.md 示例 项目电商后端 API 技术栈Python FastAPI PostgreSQL Redis 代码风格Google docstring类型注解必须 已知问题订单状态机有竞争条件暂时用 Redis 分布式锁绕过 禁止直接写 SQL必须通过 ORM每次打开 Claude Code它直接知道这些——不需要检索因为全文只有几千 token直接装进去完全没问题。Anthropic 的设计哲学透明、可控、用户能看到和编辑模型知道什么而不是一个黑盒向量库在后台默默检索。一篇技术分析文章准确描述了这两种方式的本质差异Claude 的方式是让用户自己维护记忆文件模型读取它。缺少魔法但你能看到接缝。RAG 的方式是自动提取、存储、检索。更智能但当它出错时你不知道为什么。原因三Prompt Cache 让长上下文的成本大幅下降长上下文贵的一个重要原因是每次请求都要重新处理相同的内容。Claude 的Prompt Cache机制解决了这个问题fromanthropicimportAnthropic clientAnthropic()# 第一次请求完整处理建立缓存responseclient.messages.create(modelclaude-opus-4-7,max_tokens1024,system[{type:text,text:你是代码审查专家,},{type:text,text:open(entire_codebase.txt).read(),# 整个代码库cache_control:{type:ephemeral},# 标记为可缓存}],messages[{role:user,content:检查安全漏洞}])# 首次全价处理 200K token# 第二次请求缓存命中只处理新的问题response2client.messages.create(modelclaude-opus-4-7,max_tokens1024,system[...],# 同样的 system从缓存读messages[{role:user,content:检查性能瓶颈}])# 后续缓存部分约降价 90%只有新内容按全价计算对于同一份文档要问多个问题的场景Prompt Cache 让长上下文的成本接近 RAG 的成本同时保留了全局推理的优势。⚖️ 真正的决策框架什么时候用哪个理解了两种方案的优劣现在给出一个可以直接用的决策框架你的知识库有多大 │ ├─ 能装进 200K token约 150 万字以内 │ │ │ ├─ 需要全局推理整体逻辑、跨章节关系→ 长上下文 │ └─ 只需要精确问答找特定信息→ RAG 或长上下文均可 │ └─ 超出 200K token企业级文档库、代码仓库等 │ ├─ 知识更新频繁 → RAG每次更新只需重建部分索引 ├─ 需要来源追溯 → RAG能返回来自第 X 文件第 Y 行 ├─ 高并发、成本敏感 → RAG每次只处理少量相关片段 └─ 需要跨文档全局推理 → RAG 长上下文组合长上下文明显更优的场景场景原因整份合同/法律文书审查需要理解完整逻辑和隐含条款单个代码文件/小型仓库的全面审查跨函数、跨文件的依赖关系学术论文深度分析方法论→实验→结论的完整链路一次性大文档问答不需要重复查询无缓存必要RAG 明显更优的场景场景原因企业内部知识库问答文档量远超上下文窗口实时更新的数据RAG 可以增量更新无需重建上下文精确信息检索“这个 API 的参数是什么”RAG 检索精准比淹没在 200K 里更可靠需要引用来源RAG 天然支持来自文档 X 第 Y 段高并发低成本RAG 每次 token 消耗少 10-50 倍2026 年的最佳实践两者结合现在生产环境里最流行的方案其实是混合架构用户问题 ↓ RAG 层从海量知识库里精准检索 Top-K 最相关文档 ↓ 长上下文层把检索到的 K 个文档 用户问题 一起放进 Claude 的大上下文窗口做深度推理 ↓ 高质量答案RAG 做找长上下文做想。 未来长上下文会干掉 RAG 吗这是 AI 工程界争论最激烈的问题之一。悲观 RAG 派的论据上下文窗口越来越大Gemini 已经 1M成本在持续下降Lost in the Middle问题也在随模型改进而缓解。等成本再降 10 倍、窗口再大 10 倍RAG 的价值优势会越来越小。乐观 RAG 派的论据企业级知识库是无界的几百 GB、几 TB没有任何上下文窗口能装得下。检索层提供的精准信号永远优于把所有噪声都喂给模型。而且 RAG 还提供了 LLM 本身做不到的能力引用来源、权限控制、增量更新。最可能的未来不是零和博弈而是越来越深度的融合——RAG 负责筛选长上下文负责推理两者各司其职。 总结速查维度长上下文RAG核心优势全局推理看到完整信息精准检索处理海量知识致命弱点Lost in Middle成本高知识库超限切块损失语义跨 chunk 关系丢失适合规模 200K token约 150 万字任意大小尤其 200K成本高但 Prompt Cache 可缓解低更新方便性差重新加载整个文档好增量更新透明度高直接看上下文低黑盒检索2026 最优解两者结合RAG 找长上下文想← 同左Claude 没有用 RAG 来处理上下文不是因为 RAG 不好而是因为直接加载信息更透明、更适合全局推理、在 200K 范围内更可控。这是一个有意识的架构哲学而不是技术缺陷。 最后如果这篇让你搞清楚了长上下文和 RAG 的根本区别点赞让更多人看到这个常被忽视的技术细节⭐收藏决策框架随时查阅评论说说你的实际场景一起讨论怎么选关注持续更新 AI 实战内容一个正在学 AI 的大学生 ‍相关阅读《LangGraph 实战一个 Coordinator 带着 5 个专家 Agent 干活》《Agent 可观测性用 LangSmith 追踪每一步》参考资料Liu et al. (2023).Lost in the Middle: How Language Models Use Long Contexts. TACL 2024.Yu et al. (2025).Long Context vs. RAG for LLMs: An Evaluation and Revisits. arXiv:2501.01880.AkitaOnRails (2026).Is RAG Dead? Long Context, Grep, and the End of the Mandatory Vector DB.MindStudio (2026).Does a 1M Token Context Window Replace RAG?Anthropic Claude Code 官方文档code.claude.com