# 面试官：为什么 Claude Code 放弃了 RAG？ - Source: https://www.bilibili.com/video/BV1pzjy6GEkC (哔哩哔哩) - Creator: 丁师兄大模型 - Published: 2026-06-23T10:00:00.000Z - Transcribed by Memora: 2026-07-05T01:48:04.546Z - Canonical page: https://media-pilot-nine.vercel.app/bilibili/16 > Transcript and summary produced by Memora from the publicly available > video linked above. The original video belongs to its creator. ## Summary 该视频拆解了面试中关于“Claude Code为何放弃RAG而改用grep做代码检索”的问题，从背景、技术缺陷、架构哲学和辩证思考四层展开。首先，Claude Code早期尝试过本地向量数据库加embedding检索的RAG方案，但效果不佳，转而采用agentic search，即让模型通过grep、find等Linux命令实时搜索代码，工程师Boris称其效果远超其他方法。 核心原因有三：一是embedding对代码标识符的语义理解失效，例如getUserById和deleteUserById在向量空间距离很近，但功能完全相反，精确匹配天然更可靠；二是RAG链路各环节（切分、embedding、检索、重排序、生成）存在乘法效应，即便每步90%准确率，整体也不足60%，且调试困难，而grep失败仅因关键词未匹配，确定性高；三是索引时效性问题，代码仓库变化快，索引易过时，grep实时搜索则始终获取最新状态。 在架构哲学上，Claude Code遵循无状态设计，无需构建索引，实现零配置、零运维，并贯彻“Everything is the Model”理念，让模型能力提升直接驱动系统优化，同时grep本地执行也杜绝了embedding存储带来的信息泄露风险。 辩证看待，该方案也有代价：每次搜索需多轮工具调用，Token消耗巨大；对概念级跨文件搜索（如查找所有权限校验逻辑）覆盖不足。因此，业界趋向混合方案，将精确grep用于标识符查找，语义检索用于概念探索。面试回答需层层递进，既讲清RAG在代码场景的缺陷，也承认Claude Code方案的局限，展现深度与边界感。 ## Key points - [object Object] - [object Object] - [object Object] - [object Object] - [object Object] - [object Object] - [object Object] - [object Object] ## Chapters - [0:00](https://media-pilot-nine.vercel.app/bilibili/16?t=0) 背景介绍 - [0:59](https://media-pilot-nine.vercel.app/bilibili/16?t=59) RAG的根本性缺陷 - [2:24](https://media-pilot-nine.vercel.app/bilibili/16?t=144) 架构哲学 - [3:22](https://media-pilot-nine.vercel.app/bilibili/16?t=202) 辩证思考 - [4:05](https://media-pilot-nine.vercel.app/bilibili/16?t=245) 总结与面试建议 ## Transcript **[0:00]** Claude Code不用RAG **[0:04]** 全靠grep做代码检索 **[0:05]** 这在技术圈争议很大 **[0:07]** 我一个学员上个月面大厂AI岗就碰上了 **[0:09]** 面试官问 **[0:10]** Claude Code为什么放弃RAG **[0:11]** 你觉得合不合理 **[0:12]** 这题考的就是你对RAG链路的理解深度 **[0:15]** 加上你自己的工程判断 **[0:17]** 接下来我来拆解下这道面试题 **[0:19]** 1.先把背景交代清楚 **[0:20]** 回答的时候 **[0:21]** 第一步先把事情的来龙去脉讲清楚 **[0:23]** 让面试官知道你是真的跟踪过这个话题 **[0:26]** Anthropic的工程师Boris在2025年5月 **[0:28]** The Latent Space 播客里明确说过 **[0:31]** Claude Code早期确实试过RAG **[0:33]** 用的就是标准方案 **[0:34]** 本地向量数据库加embedding检索 **[0:36]** 但他们很快发现效果不行 **[0:37]** 最终切换到了他们叫agentic search的方式 **[0:40]** 说白了就是让模型自己 **[0:42]** 要用grep、glob **[0:43]** find这些Linux命令去 **[0:44]** 实时搜索代码 **[0:45]** Boris原话是 **[0:46]** It outperformed everything by a lot **[0:48]** 而且被追问是什么benchmark的时候 **[0:50]** 他说Mostly vibes主要靠体感 **[0:52]** 这个回答本身就很有意思 **[0:53]** 我们一会儿再说 **[0:54]** 面试的时候你先把这个事实陈述清楚 **[0:56]** 让面试官知道你是用心细研的 **[0:58]** 不是在瞎编 **[0:59]** 二 核心原因 **[1:00]** 代码场景下RAG的根本性缺陷 **[1:02]** 好 接下来我们讲为什么放弃 **[1:04]** 很多人会笼统地说 **[1:05]** RAG效果不好 **[1:06]** 那面试里你得说清楚到底哪里不好 **[1:08]** 第一个问题也是最致命的 **[1:10]** 就是embedding对代码标识符的语义理解 **[1:12]** 几乎是失效的 **[1:13]** 你想getUserById和deleteUserById **[1:16]** 这两个函数名 **[1:17]** 在向量空间里的距离非常近 **[1:19]** 因为它们共享了大量的token **[1:20]** 但它们的功能完全相反 **[1:22]** 一个是查询 一个是删除 **[1:23]** 代码不是自然语言 **[1:24]** 它是结构化的精确标识符 **[1:26]** 函数名 类名 变量名 **[1:28]** 本身就是最好的检索关键词 **[1:30]** 在这种场景下 **[1:31]** 精确匹配天然比语义匹配更可靠 **[1:33]** GRAPSO Process Payment **[1:35]** 就只精确命中，不存在一票否决的问题 **[1:37]** 第二个问题是RAG管线的准确率 **[1:39]** 有一个乘法效应 **[1:40]** 你想想整个链路 **[1:42]** 文档切分 **[1:43]** embedding生成 **[1:44]** 向量检索 **[1:44]** 重排序 **[1:45]** 最终生成 **[1:46]** 每个环节哪怕做到90%的准确率 **[1:48]** 五个环节乘下来就只剩不到60% **[1:51]** 而且这些环节出错的时候 **[1:52]** 调试是噩梦级别的 **[1:54]** 你根本不知道是chunk切得不好 **[1:55]** 还是embedding质量有问题 **[1:57]** 还是re-rank模型偏了 **[1:58]** 但GRAPSO失败的原因只有一个 **[2:00]** 关键词没匹配上 **[2:01]** 这种确定性在工程上的价值是巨大的 **[2:04]** 第三个问题是索引的时效性 **[2:06]** 代码仓库变化极快 **[2:07]** 你上午建的索引下午可能就过时了 **[2:09]** 有人新提交了代码 **[2:10]** 重构了文件结构 **[2:12]** 索引就跟实际代码产生了漂移 **[2:14]** 你要么频繁重建 **[2:15]** 因此付出巨大的计算开销 **[2:17]** 要么忍受过时 **[2:17]** 索引带来的错误次数 **[2:19]** GRAPSO每次都是实时搜索 **[2:20]** 拿到的永远是当前最新的代码状态 **[2:23]** 根本不存在同步问题 **[2:24]** 四、更深一层架构哲学上的考量 **[2:27]** 讲完技术细节之后 **[2:28]** 你可以再拔高一层 **[2:29]** 聊聊架构哲学 **[2:30]** 这会让面试官觉得你有depth **[2:32]** Claude Code的设计遵循的 **[2:34]** 其实是一个非常经典的原则 **[2:36]** 无状态设计 **[2:37]** 这条线从Unix管道到Rest API到Serverless **[2:40]** 在计算机科学里反复验证过 **[2:42]** 不建索引意味着零配置 **[2:44]** 用户clone完代码就能直接用 **[2:45]** 不需要等几分钟构建embedding **[2:47]** 不维护状态意味着零运维负担 **[2:49]** 没有索引卡住了缓存 **[2:51]** 损坏了这种问题 **[2:52]** 而且Anthropic内部有一个原则 **[2:53]** 叫Everything is the Model **[2:55]** 尽量让模型本身去驱动决策 **[2:57]** 而不是在模型外面搭一套 **[2:58]** 复杂的工程管线 **[3:00]** 模型每变强一分 **[3:01]** 整个系统就自动变好一分 **[3:02]** 这其实就是Rich Sutton说的 **[3:04]** Bitter Lesson在工程上的体现 **[3:06]** 还有一个容易被忽略的点是安全性 **[3:08]** RAG方案需要把代码做embedding **[3:10]** 存到某个地方 **[3:11]** 不管是本地还是云端 **[3:12]** 这个向量表示 **[3:13]** 本身就是一种信息泄露的风险 **[3:15]** 学术上已经有研究证明 **[3:17]** 可以从embedding反推原始内容 **[3:19]** 而grep完全在本地执行 **[3:20]** 从架构上就杜绝了这个问题 **[3:22]** 4.辩证思考 **[3:24]** 这不是简单 **[3:24]** 最后面试的时候 **[3:25]** 一定要展现辩证思维 **[3:27]** 不要把话说死 **[3:28]** Claude Code的方案也有明显的代价 **[3:30]** 最大的就是Token消耗 **[3:31]** 每次搜索都是实时执行 **[3:33]** 模型要列目录 **[3:34]** 读文件 **[3:34]** 做多轮探索 **[3:35]** Token用量远高于一次性的向量检索 **[3:38]** Mufus团队就公开批评过这一点 **[3:40]** 说这是在烧Token **[3:41]** 而且对于超大型代码库 **[3:43]** 纯grep的方式 **[3:44]** 在概念级搜索上确实有短板 **[3:46]** 比如你想找 **[3:47]** 所有跟权限校验相关的逻辑 **[3:48]** grep不一定能覆盖所有变体写法 **[3:51]** 所以业界目前的共识 **[3:52]** 其实是在走向混合方案 **[3:53]** 精确搜索处理标识符级别的查找 **[3:56]** 语义检索处理概念级别的探索 **[3:58]** 两者互补 **[3:59]** Claude Code选择了极简的那一段 **[4:01]** Cursor选择了向量索引的那一段 **[4:03]** 未来大概率会在终端侧各个自主联网 **[4:05]** 最后简单总结一下 **[4:07]** 你把这些讲清楚 **[4:08]** 这道题基本就拿满分了 **[4:09]** 核心就是三层 **[4:10]** 技术实施层 **[4:12]** 讲清楚embedding **[4:13]** 对代码的实现和管线复杂度 **[4:15]** 架构选择层 **[4:16]** 讲清楚无状态设计 **[4:17]** 和everything is the model的理念 **[4:19]** 最后辩证层 **[4:20]** 承认Token成本和向量搜索的局限 **[4:22]** 有理有据 **[4:23]** 有深度有边界 **[4:24]** 面试官想不给高分都难 **[4:26]** 以上就是对这道面试问题的分析和拆解 **[4:29]** 这里是丁师兄大模型 **[4:30]** 持续分享大模型面试干货 **[4:33]** 需要大模型一对一面试辅导的同学 **[4:35]** 请见评论区置顶介绍 **[4:37]** 大家面试加油