面试解析:Claude为何不用RAG 面试被问“Claude Code为什么不用RAG”怎么答?这道题表面考选型,实际考Agent工程落地。本期深度解析Anthropic选择Agentic Search的核心原因:代码更需精确匹配而非语义相似,且能避开向量库的维护与安全成本。内附高分回答模板,助你掌握大模型工程直觉! #大模型面试 #Claude #RAG技术 #Agent开发 #AI编程
✅ 已完成任务ID: 1855
30秒速读
核心摘要
可执行建议
- 面试作答该题可直接套用提供的高分模板,覆盖选型原因、方案短板与兜底策略
- 大模型工程落地优先选确定性强的成熟工具,勿盲目上线高维护成本的复杂系统
高价值评论洞察
- 大量技术用户对视频将RAG等同于向量检索的表述存在争议,明确指出广义RAG是检索增强生成的思路,grep等精确检索也属于RAG范畴
- 不少面试者反馈该类大模型技术面试题出现频率极高,部分用户疑惑无相关项目经历也会被面试官提问
- 现有解析存在逻辑漏洞,未覆盖Cursor等同类代码产品选择向量检索的反例,容易让面试者遇到延伸提问时卡壳
用户关注点
- RAG的边界定义、代码场景下不同检索方案的选型优劣对比
- 大模型高频面试题的完整作答逻辑,尤其是反例类追问的应对方法
- 大模型工程落地中检索方案选型的实操经验
可复用选题/回应建议
- 补充RAG定义溯源内容,厘清广义RAG和向量检索RAG的区别,回应用户争议
- 新增Cursor等同类代码产品检索选型的对比解析,完善原面试题的作答框架,补全反例应对思路
- 整理大模型开发岗高频面试题合集,附带不同项目背景候选人的适配版回答模板
代表性评论
- 用户质疑“rag不是思想吗,怎么又成向量数据库专属了?rag是检索增强生成,grep就不是检索增强生成了?”,价值是点出视频内容的认知偏差,反映技术圈对RAG定义的普遍争议
- 用户提问“你这么回答人家问 cursor 为什么用向量你不是炸了?”,价值是指出原有解析的逻辑盲区,对应面试中高频出现的延伸追问场景
标签与备注
标签
备注
暂无备注
转录文本
面试官突然问你一句,你天天用的Cloud Code背后,为什么不给你的代码库做向量检索?也就是为什么不用RAG?你会怎么回答?很多人会当场愣住,因为外面到处都在讲Embedding、向量库、RAG,结果Anthropic自己做代码工具反而不走这条路。这题一开口就能筛掉一批只会背概念的人。先点赞收藏加关注,我们马上开始,想系统学习Agent开发的同学可以查看橱窗哦。 先搞清楚面试官表面在问什么,真正想考什么。表面看他是在问一个产品选型,为什么不用RAG?RAG叫检索增强生成,大概意思是先把资料切块向量化存起来,提问的时候再按语义相似度,找出最相关的几段喂给模型。但他真正考的不是你会不会解释RAG,而是你有没有把一个Agent真正落到生产环境里,知不知道在代码这个场景下,什么方案更稳定,维护成本更低,也更不容易出安全问题。这考的是工程落地,不是名词解释。 一句话给出总答案,Anthropic早期版本确实尝试过RAG加本地向量库,但很快发现让模型像人一样使用grep这类命令行工具去翻代码,也就是所谓的Agentic Search,主体式检索,效果反而更好,而且更简单,在安全、隐私、时效性和可靠性上,也避开了向量库那一堆麻烦。 那为什么RAG放到代码场景里反而不占便宜?核心就一句话,代码更需要精确引用,而不是语义相似。你要找一个函数名,它存在就是存在,不存在就是不存在。Grep这种精确匹配一下就能定下来,而向量检索的模糊相似度,反而可能捞出一堆看起来相关实际没用的片段,对写代码来说是一种干扰。第二,代码每天都在变。你刚建好的索引,开发者一改文件就可能过期。为了保持新鲜,就得不停切块,重新Embedding,重新同步,这本身就是持续维护负担。第三,建索引等于额外养一套系统,要存储,要同步,要管权限,还要担心代码泄露。因为做Embedding往往意味着源码可能离开本地,直接读文件,这些问题基本都省掉了。 那Agentic Search具体是怎么做的?其实就是把人平时查代码的动作交给模型自己完成,而且按成本从低到高分层执行:先用glob按文件名模式快速列出候选文件,几乎不消耗算力,再用grep、ripgrep这种高速文本搜索工具,按关键词或正则在文件内容里找匹配行,等模型确认相关性以后,才用read把整个文件读进上下文,这一步最贵,模型就这样不断想一下,搜一下,看结果,再缩小范围,一轮一轮逼近目标,和你自己在项目里翻代码的方式非常像。再加上现在上下文窗口已经做到百万Token,前缀缓存又能让重复提示的成本大幅下降,这套迭代式搜索放到大代码库里经济上也能扛住。亚马逊的一篇研究也验证过,单靠关键词搜索加迭代细化就能达到RAG九成以上的效果,而且不用维护向量库。 好的点在于,但面试的时候千万别把它吹成万能,把坑也讲出来才像真的做过。第一个坑是Token容易爆。你在一个React大项目里搜useTest,可能命中几百处,模型要么硬看,要么反复细化,又慢又贵。第二个坑是语义盲区。如果有人把一个函数从createDex重构,改名成别的,grep按旧名字就完全搜不到,而向量检索反而可能靠语义把它找回来。第三是延迟问题。每次工具调用一两秒,跑二十轮就是大半分钟,怎么兜底?一是多关键词三角定位,直接搜名字搜不到就换一组相关词,比如os、session、token中间件,从几个方向夹出目标模块。二是社区也会把语义检索做成MCP插件挂上去,遇到概念级搜索,或者面对超大陌生代码库的时候再补一层。 所以,到2026年更合理的共识,不是二选一,而是Agentic Search做主干,向量检索按需补充,形成混合架构。给你一个可以直接背的面试回答模板,你可以这样说:Cloud Code没有默认用RAG,是因为代码场景更看重精确引用,而不是语义相似,向量索引还会带来时效、同步、安全和维护成本这些工程问题,它采用的是Agentic Search,让模型分层调用glob、grep、读文件,迭代缩小范围,再配合大上下文和前缀缓存,就能跑得又准又省。我也知道它的短板,比如重构改名可能搜不到,热门符号会消耗大量Token,所以生产力一般会用多关键词兜底,并且在需要概念检索的大代码库上补一层语义索引,做成混合方案。这样一答,概念原因、落地短板和兜底方案就全都有了。 嗯,说到底,这道题考的是一个很朴素的工程直觉:能用现成的确定性强的工具解决问题,就不要急着上一套需要长期维护,还可能漏数据的复杂系统,简单可靠、贴近真实文件,往往比看起来更高级的方案更能在生产环境里跑下去。如果你也在准备大模型工程岗,想把这类题目讲到能打动面试官,可以关注我,咱们下期继续拆。