阅读路线图：

---

引言：一个值得追问的工程决策

你可能听过这样一个说法：

“Claude Code 放弃了 RAG，改用 Grep 做代码检索。”

第一反应往往是惊讶——RAG 不是大模型应用的"标配"吗？如果连 Anthropic 自己都不用，是不是说明 RAG 不行了？

这个判断过于简化。本文要做的，不是简单地站队"RAG 好"或"RAG 坏"，而是带你拆解这个决策背后的工程逻辑，最终落到一个更实用的问题上：

在你的实际项目中，到底什么时候该建知识库、怎么建、怎么用？

---

第一章 先对齐事实：发生了什么

1.1 Claude Code 确实没用传统 RAG

Claude Code 是 Anthropic 推出的命令行 AI 编程助手。根据 Anthropic 工程师在 2025 年 5 月 Latent Space 播客中的公开分享[^1]，Claude Code 在代码检索上没有采用"向量数据库 + Embedding 检索"的标准 RAG 方案，而是让模型自己调用 grep、glob、find 等工具，实时搜索代码库。

这种做法被称为 Agentic Search（智能体式检索）——检索的主动权交给了模型本身，而不是由一条预设的检索管线驱动。

两种检索架构的对比：

核心区别：传统 RAG 的检索路径是固定的，模型只能被动接收检索结果；Agentic Search 让模型自己决定用什么工具、查几次、查完怎么用。

1.2 但这不等于"Anthropic 否定了 RAG"

这是一个常见的误读。事实上，同一时期 Anthropic 发布了多篇关于如何改进 RAG 的工程文章：

• 《Introducing Contextual Retrieval》（2024 年 9 月）[^2]：Anthropic 系统性地介绍了如何通过"上下文增强"将 RAG 的检索失败率降低 49%（配合重排序可达 67%），并明确指出 RAG 是"扩展到超大规模知识库时的典型方案"。
• 《Building Effective Agents》（2024 年 12 月）[^3]：Anthropic 在讨论 Agent 架构时提到，“对于许多应用来说，用检索和上下文示例优化单次 LLM 调用通常就够了”。

关键区分：Claude Code 放弃 RAG，是针对代码检索这个特定场景的决策，不是对 RAG 作为知识库技术的全盘否定。

理解这一点，是我们后续讨论的基石。

---

第二章 为什么代码场景不适合传统 RAG

2.1 先破除一个常见误区

很多人听到"Claude Code 放弃 RAG"，第一反应是：“是不是 Embedding 对代码不灵？代码里大量共享 Token，模型分不清？”

这个说法站不住脚。 Embedding 的设计目标就是做语义区分。get_user_by_id 和 delete_user_by_id 虽然共享大量子串，但它们的语义截然不同，现代 Embedding 模型完全可以区分。Anthropic 在 Contextual Retrieval 的实验中，测试域就包含了代码库（codebases），且取得了正向结果[^2]。

所以，问题不在 Embedding 本身。

2.2 真正的三个问题

问题一：不可诊断性

传统 RAG 的流程是：用户提问 → 系统检索相关片段 → 把片段塞进 Prompt → 模型回答。

问题在于，检索系统是模型外部的一个黑盒。当检索结果不对时，模型无法判断：

• 是检索系统出了问题（没召回正确的片段）？
• 还是数据本身就是这样（确实没有相关内容）？

模型没有能力"诊断"这条外部管线。在实践中，这意味着当结果出错时，你很难快速定位原因——是 Chunk 切分有问题？是 Embedding 质量不够？还是重排序模型偏了？

而 Grep 的失败原因只有一个：关键词没匹配上。这种确定性在工程调试中价值巨大——你一眼就能看出是搜索词写错了，还是代码里确实没有这个符号。

调试体验对比：

问题二：环节乘法效应

RAG 是一条多环节管线：文档切分 → Embedding 生成 → 向量检索 → 重排序 → 最终生成。

每个环节哪怕做到 90% 的成功率，五个环节串联下来：$0.9^5\approx 59\%$，整体成功率不到 60%。

环节越多，整体可靠性衰减越快：

更麻烦的是，出错时你很难隔离是哪个环节的问题。这在生产环境中是调试灾难。相比之下，Grep 是单步操作，要么匹配到、要么没匹配到，没有中间状态的歧义。

问题三：索引时效性

代码仓库变化极快——上午建的索引，下午一个 PR 合并后可能就过时了。

这带来一个两难：

• 频繁重建索引：计算开销大，尤其对大型代码库；
• 容忍过期索引：检索结果与实际代码产生"漂移"，模型基于过时信息给出错误答案。

Grep 每次实时搜索，拿到的永远是当前磁盘上的最新状态，不存在同步问题。对于代码这种高频变更的资产，这是一个结构性优势。

2.3 代码场景的特殊性：精确匹配天然占主导

还有一个场景层面的原因。代码检索的大部分需求是精确匹配：

• 查找函数名、变量名、类名
• 定位错误码、异常日志中的关键字
• 追踪某个 API 的调用点

这些场景中，符号本身就是最好的检索关键词。grep -rn "PaymentService" 比任何语义检索都更直接、更准确。

小结：Claude Code 放弃 RAG，不是因为 RAG 技术本身不行，而是因为代码场景的三个特性——需要可诊断性、环节要少、数据要实时——恰好与传统 RAG 的架构假设冲突。

---

第三章 场景分界：什么时候该用什么

理解了"为什么不用"，更重要的是知道"什么时候该用"。这里有一条清晰的分界线。

3.1 适合精确检索（Grep / 终端命令）的场景

特征	例子
有明确的标识符	函数名、变量名、错误码、配置项
需要精确匹配	“找到所有调用 processRefund 的地方”
数据高频变更	代码仓库、配置文件
需要可追溯性	必须知道确切位置和上下文

3.2 适合语义检索（知识库 / 向量检索）的场景

特征	例子
意图模糊，无法用精确关键词表达	“我们的权限校验是怎么做的？”
知识分散在多份文档中	员工手册、技术规范、架构决策记录
概念性探索	“系统中有哪些地方涉及支付风控？”
数据相对稳定	规章制度、产品文档、历史案例

3.3 核心判断标准：一个简单的决策树

记住：这不是非此即彼的选择。很多真实项目同时需要两种能力，关键在于让模型自己判断该用哪种——这正是下一章的主题。

---

第四章 核心思想转变：让模型驱动检索

4.1 传统 RAG 的问题：把模型当"傻子"

传统 RAG 的流程是固定的：

这条管线在模型回答之前就决定了模型能看到什么。模型没有选择权——它只能基于检索系统喂给它的片段来回答。如果检索结果不好，模型也无能为力。

这本质上是把大模型当成一个"只负责最后一步生成"的被动组件，没有利用模型自身的判断力。

4.2 更好的做法：Agentic Search

Anthropic 在《Building Effective Agents》中明确区分了两种架构[^3]：

维度	Workflow（工作流）	Agent（智能体）
流程控制	预定义代码路径	模型动态决定
灵活性	低，路径固定	高，按需调整
适用场景	步骤可预测的任务	开放式探索任务
检索方式	固定管线检索	模型自主选择工具

Agentic Search 的核心思路是：把检索的主动权交给模型。

模型自己判断：

• 需要查什么？（生成搜索查询）
• 什么时候查？（决定何时调用工具）
• 查完之后怎么用？（评估结果，决定是否需要再查）
• 用什么工具查？（Grep？向量库？API？）

知识库可以挂在那里，但不是在模型外面预设一条固定的检索管线，而是让模型按需调用。

4.3 一个类比

把传统 RAG 想象成：你给一个新员工一本厚厚的手册，告诉他"每次遇到问题，先翻到第 X 页，照着做"。

Agentic Search 则是：你给这个员工一个工具箱（里面有搜索引擎、文件浏览器、命令行），告诉他"你自己判断需要用什么工具、什么时候用"。

后者显然更灵活——前提是这个员工足够聪明。今天的强模型已经具备了这个能力。

---

第五章 落到实处：实际项目中如何合理创建知识库

前面四章是"为什么"，这一章是"怎么做"。以下建议综合了 Anthropic 官方工程实践[^2][3] 和业界经验，面向的是"你决定要建知识库"的场景。

整体建设路线图：

5.1 第一步：先问自己——真的需要知识库吗？

在动手建向量数据库之前，先回答三个问题：

① 你的知识库有多大？

Anthropic 在 Contextual Retrieval 文章中给出了一个实用的基准[^2]：

如果你的知识库小于 200,000 Token（约 500 页材料），你可以直接把整个知识库放进 Prompt，不需要 RAG。

随着上下文窗口的增大（当前模型已支持 100 万+ Token）和 Prompt 缓存技术（可降低 90% 成本、2 倍以上延迟改善），"直接塞进 Prompt"在很多场景下是更简单、更可靠的选择。

② 你的数据是结构化的还是非结构化的？

• 如果是结构化数据（如产品目录、用户信息），用 SQL 或 API 查询比向量检索更准确。
• 如果是半结构化文档，先考虑全文搜索（如 Elasticsearch、BM25），它对精确匹配更可靠。

③ 你的检索需求能被关键词满足吗？

回到第三章的决策树。如果大部分需求是精确匹配，你不需要向量库。

原则：用最简单的方案解决问题。Anthropic 反复强调[^3]：“先找到最简单的解决方案，只在需要时才增加复杂度。”

5.2 第二步：如果确实需要知识库，怎么建？

当你确认需要语义检索能力时，以下是经过验证的实践要点。

要点一：Chunk 切分是成败关键

传统 RAG 把文档切成小块（通常几百 Token），然后分别 Embedding。问题在于：切分后的小块往往丢失了上下文。

Anthropic 给了一个经典例子[^2]：

一个 Chunk 内容是"The company’s revenue grew by 3% over the previous quarter."
但这个 Chunk 没有说明是哪家公司、哪个季度。检索时无法正确匹配。

Anthropic 的解法——Contextual Retrieval：在 Embedding 之前，先用 LLM 为每个 Chunk 生成一段简短的上下文说明（50-100 Token），前置到 Chunk 中。

原始 Chunk: "The company's revenue grew by 3% over the previous quarter."

增强后 Chunk: "本片段来自 ACME 公司 2023 年 Q2 的 SEC 文件；上一季度营收为 3.14 亿美元。
The company's revenue grew by 3% over the previous quarter."

这个方法将检索失败率降低了 35%[^2]。

启发：切分不是简单的"按字数截断"。要考虑语义边界（段落、章节），并为每个 Chunk 保留足够的上下文信息。

要点二：Embedding + BM25 混合检索

纯向量检索会漏掉精确匹配。Anthropic 的实验表明[^2]：

Embedding 擅长语义匹配，但会漏掉精确的关键词匹配。BM25（一种基于词频的全文检索算法）恰好互补。

推荐做法：同时使用 Embedding 和 BM25 检索，然后合并去重结果。这在 Anthropic 的测试中将检索失败率降低了 49%[^2]。

启发：不要只依赖向量检索。混合检索（向量 + 关键词）是当前最佳实践。

要点三：重排序（Reranking）值得加

初始检索会返回大量候选片段（可能上百个），但质量参差不齐。重排序模型可以对候选片段按相关性重新打分，只保留最相关的 Top-K。

Anthropic 的数据显示[^2]：Contextual Embedding + Contextual BM25 + Reranking，将检索失败率降低了 67%（从 5.7% 降到 1.9%）。

各技术组合的检索失败率改善效果（Anthropic 官方数据[^2]）：

启发：重排序是"花小钱办大事"的环节。它增加了一点延迟，但显著提升了送入模型的内容质量。

要点四：让模型决定何时查、查什么

这是最核心的理念转变。不要把知识库检索写死成一条固定管线，而是把知识库暴露为模型可以调用的工具。

具体做法：

• 将知识库检索封装为一个 Tool（函数），模型可以按需调用；
• 在系统提示中告诉模型：“你可以使用知识库搜索工具来查找相关信息”；
• 让模型自己判断：这个问题需要查知识库吗？用什么关键词查？查到的结果够不够？要不要换个角度再查？

这比"每次提问都先检索 Top-K 片段塞进 Prompt"灵活得多，也更符合 Agentic Search 的理念。

要点五：保持索引与数据同步

如果你的知识库会更新（比如内部文档会修订），需要建立同步机制：

• 增量更新：只对变更的文档重新生成 Embedding，而不是全量重建；
• 版本管理：记录每个 Chunk 的来源文档版本，便于追溯；
• 定期评估：用一组标准测试问题定期检查检索质量，发现退化及时处理。

5.3 第三步：评估你的知识库效果

建好知识库不等于万事大吉。你需要持续评估它的效果。

Anthropic 的建议[^4]：

• 从小规模开始：20 个有代表性的测试问题就能发现大部分问题。早期改动效果显著（比如从 30% 提升到 80%），不需要几百个测试用例。
• 用 LLM 做评审：让一个 LLM 按照评分标准（事实准确性、引用准确性、完整性、来源质量、工具效率）给检索结果打分。
• 人工测试不可少：自动化评估会漏掉边缘情况，比如模型倾向于选择 SEO 优化的内容农场而非权威来源[^4]。

启发：评估不是一次性工作，而是持续迭代的闭环。先跑起来，再优化。

5.4 一张总结表：知识库建设检查清单

阶段	关键问题	推荐做法	复杂度
决策	真的需要知识库吗？	小于 20 万 Token 直接塞 Prompt；精确匹配用全文搜索	🟢 低
切分	Chunk 丢失上下文怎么办？	用 LLM 为每个 Chunk 生成上下文说明（Contextual Retrieval）	🟡 中
检索	纯向量检索漏精确匹配？	Embedding + BM25 混合检索	🟡 中
排序	候选片段太多质量参差？	加 Reranking 步骤，只保留 Top-K	🟡 中
调用	检索写死还是模型驱动？	封装为 Tool，让模型按需调用	🔴 高
同步	数据更新了怎么办？	增量更新 + 版本管理 + 定期评估	🟡 中
评估	怎么知道效果好不好？	20 个测试问题起步 + LLM 评审 + 人工抽查	🟢 低

实施建议：从左到右逐步推进，每完成一个阶段都做一次效果验证。不要试图一步到位——先跑起来，再迭代优化。

---

第六章 架构哲学：把复杂性交给模型，而非管线

6.1 “Everything is the Model”

Anthropic 内部有一个工程原则：尽量让模型本身驱动决策，而不是在模型外面搭一套复杂的工程管线。

这不是教条，而是一个成本权衡：

• 管线复杂度：每多一个环节，就多一个可能的故障点、多一份运维负担。索引卡住、缓存损坏、数据过时——这些问题全部落在工程团队身上。
• 模型能力：随着模型变强，很多原来需要工程管线做的事（比如判断该检索什么），模型自己就能做好。

把复杂性从管线转移到模型，本质上是用模型的智能换工程的简单性。

6.2 无状态设计的价值

Grep 之所以在代码场景中胜出，一个被低估的优势是无状态：

维度	传统 RAG	Grep / Agentic Search
配置	需要部署索引服务	零配置，Clone 即用
运维	需监控、重启、扩容	零运维
数据安全	代码需发送到 Embedding 服务	本地执行，零泄露风险
状态依赖	索引状态需与数据同步	无状态，实时读取

对于知识库场景，虽然无法完全无状态（需要维护索引），但可以尽量减少状态依赖：用模型驱动检索而非固定管线，就是一种减少状态复杂度的方式。

6.3 代价是真实的

需要诚实地说明 Agentic Search 的代价：

Token 消耗对比（Anthropic 官方数据[^4]）：

• Token 消耗大：模型自己探索需要多轮工具调用，Token 用量远高于一次向量检索。Anthropic 的数据显示，Agent 模式比 Chat 模式消耗约 4 倍 Token，多 Agent 系统约 15 倍[^4]。
• 延迟更高：多轮探索意味着更长的等待时间。
• 概念覆盖短板：对于超大型代码库的概念级搜索（比如"找出所有权限校验的变体写法"），Grep 存在盲区——这也是为什么知识库在概念探索场景中仍有价值。

两种方案的权衡对比：

结论：没有银弹。Agentic Search 用 Token 换灵活性和可诊断性，RAG 用工程复杂度换成本效率。选择取决于你的场景约束。

---

第七章 总结与行动建议

7.1 三个层次的认知

层次	核心观点
技术层	RAG 在代码场景的问题不是 Embedding 失效，而是不可诊断性、环节乘法效应和索引时效性
场景层	精确匹配走 Grep / 全文搜索，概念探索走向量检索，两者不是对立而是互补
架构层	让模型驱动检索（Agentic Search），而非让检索管线驱动模型

7.2 给你的行动建议

1. 审视你当前的知识库需求：用第五章的检查清单走一遍，确认是否真的需要向量检索。
2. 小数据量优先用 Prompt：如果你的知识库不到 20 万 Token，直接放进 Prompt + Prompt 缓存，比任何 RAG 方案都简单可靠。
3. 如果建知识库，用混合检索：Embedding + BM25 + Reranking，这是当前经过验证的最佳组合。
4. 把检索能力交给模型：不要写死检索管线，把知识库封装为模型可调用的工具。
5. 从 20 个测试问题开始评估：先跑起来，再迭代优化。

7.3 一句话总结

不是 RAG 被淘汰了，而是场景分开了。知识库可以建，但怎么用——让模型自己决定。

---

思考题

💡 以下问题没有标准答案，目的是引导你将本文的理念与自己的项目结合。建议带着这些问题回到工作中实践。

1. 📊 场景盘点
你的项目中，有哪些数据适合精确检索，哪些适合语义检索？试着列一张表，看看比例如何。

数据类型	检索方式	理由
示例：代码仓库	Grep	高频变更，精确匹配为主
示例：技术规范文档	语义检索	概念性查询，数据稳定

2. 🛣️ 路由设计
如果你的业务既需要精确匹配又需要语义搜索，你会怎么设计检索路由？提示：考虑让模型自己选择工具，而不是用规则引擎做路由。

3. 📏 规模评估
你的知识库有多大？如果小于 20 万 Token，你是否真的需要 RAG？尝试直接放进 Prompt 对比效果。

4. ✂️ 切分审查
Contextual Retrieval 的思路——“为每个 Chunk 补充上下文说明”——能否应用到你的文档切分中？你的 Chunk 切分是否丢失了上下文？

---

参考资料

📚 以下资料均为 Anthropic 官方一手来源，本文中的数据引用均可追溯。

#	来源	时间	核心内容
[^1]	Latent Space Podcast	2025.05	Claude Code 的检索策略，Agentic Search
[^2]	Introducing Contextual Retrieval	2024.09	检索失败率降低 49%-67%，混合检索最佳实践
[^3]	Building Effective Agents	2024.12	Workflow vs Agent 架构，“从最简单方案开始”
[^4]	Multi-Agent Research System	2025.06	Token 消耗数据（4x/15x），评估方法论
[^5]	Claude Code Best Practices	持续更新	CLAUDE.md、Skills、Subagents 上下文管理

---

📝 文档版本：v2.0 | 最后更新：2026年6月 | 字数：约 6000 字

本文档基于 Anthropic 官方工程博客和公开分享整理，所有数据引用均标注来源。如需深入某个主题，建议阅读对应的原始资料。