Claude 没有用 RAG？为什么 Anthropic 选择了另一条路

🤔 Claude 没有用 RAG？为什么 Anthropic 选择了另一条路

先说结论：Claude 没有在内部给自己搭一套 RAG 系统来"记住东西"。它处理长文档、维持上下文的方式，是把所有内容直接塞进上下文窗口。这个选择不是技术落后，而是一个有意为之的架构决策——背后是一场 2026 年 AI 工程界最核心的争论：长上下文窗口 vs RAG，到底谁更好？

📖 一个让很多人困惑的问题

如果你做过 AI 应用开发，肯定知道 RAG（检索增强生成）——把文档切块，向量化，存到向量数据库，用户问问题时检索最相关的片段，喂给模型。

大多数人理所当然地认为，Claude 处理长文档时也是类似的机制：在后台有一个向量检索系统，从海量内容里捞出相关的段落。

但实际上完全不是这样。

你上传一份 100 页的 PDF，Claude 是把那 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

序列长度翻倍 → 计算量翻四倍。

用数字说话：

日处理 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 client=Anthropic()# 第一次请求：完整处理，建立缓存response=client.messages.create(model="claude-opus-4-7",max_tokens=1024,system=[{"type":"text","text":"你是代码审查专家",},{"type":"text","text":open("entire_codebase.txt").read(),# 整个代码库"cache_control":{"type":"ephemeral"},# 标记为可缓存}],messages=[{"role":"user","content":"检查安全漏洞"}])# 首次：全价处理 200K token# 第二次请求：缓存命中，只处理新的问题response2=client.messages.create(model="claude-opus-4-7",max_tokens=1024,system=[...],# 同样的 system（从缓存读）messages=[{"role":"user","content":"检查性能瓶颈"}])# 后续：缓存部分约降价 90%，只有新内容按全价计算

对于同一份文档要问多个问题的场景，Prompt Cache 让长上下文的成本接近 RAG 的成本，同时保留了全局推理的优势。

⚖️ 真正的决策框架：什么时候用哪个

理解了两种方案的优劣，现在给出一个可以直接用的决策框架：

你的知识库有多大？ │ ├─ 能装进 200K token（约 150 万字）以内 │ │ │ ├─ 需要全局推理（整体逻辑、跨章节关系）→ 长上下文 │ └─ 只需要精确问答（找特定信息）→ RAG 或长上下文均可 │ └─ 超出 200K token（企业级文档库、代码仓库等） │ ├─ 知识更新频繁 → RAG（每次更新只需重建部分索引） ├─ 需要来源追溯 → RAG（能返回"来自第 X 文件第 Y 行"） ├─ 高并发、成本敏感 → RAG（每次只处理少量相关片段） └─ 需要跨文档全局推理 → RAG + 长上下文组合

长上下文明显更优的场景

RAG 明显更优的场景

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 负责筛选，长上下文负责推理，两者各司其职。

🎁 总结速查

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）