RAG已死？字节面试官用grep反问，才发现检索选型关键

前些时候一个读者私信说，他去 面试 字节三面，岗位是 RAG 方向。面试官上来就问了一个热门问题：谈谈你对“RAG已死”的看法，还提到最近 Claude Code 用 grep 做检索的效果也不错。

他心里一乐，觉得这道题自己会答——网上不是都在说 RAG 快不行了吗，Claude Code 连向量数据库都不用了，直接用 grep 和文件系统工具搜代码。于是他清了清嗓子，自信回答说：“RAG 确实已经过时了，grep 又快又准，没有基础设施成本，结果完全可预期，而且 Agent 还能迭代检索……”

可他忽略了场景。面试官微微点头，接着问：“你讲的有一定道理。那换个场景：公司有 20 万份非结构化文档，现在想知道‘我们公司差旅报销政策是什么’，用 grep 怎么搜？”

他当场就卡壳了——报销政策可能叫“出差补贴规定”，也可能叫“员工外出费用管理办法”，grep 搜哪个词都不对。面试官又补了一句：“这些文档里还有产品截图、会议表格，grep 搜得到吗？”

他才明白，自己犯了错：不应该急着站队，而该想清楚“代码检索”和“知识库检索”是两个完全不同的场景。面试官要考的不是 grep 和 RAG 谁好谁坏，而是你有没有根据场景选工具的判断力。

我突然想到，网上很多争论就是这样。一看到某项技术“被替代”，就急着下结论。真正的工程能力，恰恰在于追问“这个结论在什么条件下成立”。

那么问题来了：既然 grep 又快又简单，为什么大多数 AI Agent 还是用 RAG？今天我们就来把前因后果一次讲清，让你面试时心里更有底。

1. grep 崛起

2025 年初，Claude Code 横空出世，做了一个出人意料的技术选择：不建向量数据库，直接用 grep 和文件系统工具检索代码。这也是面试官的提问起点。

“RAG 已死”的声音铺天盖地。毕竟 Anthropic 自己的编程 Agent 都不拥抱 RAG 了，难道我们花在向量数据库上的心血全白费了？

现实要复杂得多。在理解 RAG 的价值前，先得公平地承认 grep 确实有它的用武之地。

grep 强在精确匹配：当你明确知道要找什么时，它近乎无敌。比如：

• 代码库里的函数签名（processPayment()）
• 日志文件中的特定错误码（HTTP 404）
• 法律文件里的条款编号
• 配置文件中的具体参数名

这些场景有个共同点：用户脑子里有个精确字符串，文档里也恰好有它——匹配是确定性的，几乎没有歧义。

Augment 公司工程师 Colin Flaherty 在 SWE-Bench 竞赛中亲身验证了这一点：他们的编程 Agent 冲到了排行榜顶端，而尝试了各种 embedding 检索工具后发现，“对于 SWE-Bench 的任务，grep 和 find 就已经够了，embedding 检索并不是瓶颈。”

更重要的是，grep 的优势还在于：

• 零基础设施成本：不用建向量索引，不用维护 embedding 模型
• 结果完全可预期：没有“语义漂移”，搜什么就找什么
• 迭代检索极其自然：Agent 可以用上一次结果来指导下一次搜索

2. 为什么 grep 不够用？

答案其实很简单。现实中大部分数据不像代码那样结构化。就像面试官反问的，当遇到非结构化文档，grep 的优势就变成了劣势。

场景一：不知道要找什么词

用户问：“我们公司的差旅报销政策是怎样的？”这个问题不存在可以直接 grep 的关键词——政策文件里可能叫“出差补贴规定”，也可能叫“员工外出费用管理办法”。用户问题和文档表达之间存在语义距离，grep 够不到，向量检索却可以。面试官问的“差旅报销”，考察的正是这种场景。

场景二：多模态内容

LightOn 的博客一针见血：“你没法 grep 一张图表。”企业里充斥着产品手册里的插图、会议记录里的截图、设计稿中的说明。这些内容对 grep 完全透明，但语义向量检索可以将图像和文本联合建立索引。

场景三：跨语言与同义词

用户用英文提问，文档是中文的；或者用户说“涨价”，文档里写的是“价格调整”。这些情况下，grep 一无所获，而 RAG 的语义理解能力正是为此而生。

场景四：大规模非结构化数据

InfiniFlow 的研究给出了直接结论：面对企业级多模态、非结构化或半结构化数据时——如产品手册、会议记录、带表格和图像的报告——grep 方案将完全失效。

3. RAG 在技术层面到底解决了什么？

RAG（检索增强生成）的核心思路是：先检索出相关信息，再用这些信息驱动生成。大致流程是：

1. 把文档切分成块（chunks）
2. 用 Embedding 模型将每个块转换为向量
3. 存入向量数据库
4. 用户提问时，将问题也向量化，找出最相似的 Top-K 个块
5. 把这些块塞进 LLM 的上下文，让它生成答案

这套流程解决的核心问题是：即使措辞不同，只要意思相近，也能被找出来。

而 Agentic RAG 更进一步，让 Agent 能够：

• 多步检索：第一次检索后，根据结果决定下一步怎么找
• 整合多个数据源：既查向量库，又调 API，还搜网页
• 自我纠错：发现检索结果不理想时，主动换策略重新搜索

Jason Liu 在分析 Augment 团队的经验时，给出了一个务实的三路对比：

方案	质量	速度	成本	可扩展性	自我纠错
传统 RAG	良好	快	低	高	❌
Agent + grep	优秀	慢	高	低	✅
Agent + embedding	最优	慢	高	低	✅

关键的结论是：不要抛弃现有的检索系统，而是把它们作为工具暴露给 Agent。回头再看面试官的问题——真正想听到的其实就是这个：RAG 和 grep 不是二选一，而是同一把瑞士军刀上的不同工具。

4. “RAG 已死”是真的吗？

肯定不是。外面铺天盖地还在招 RAG 工程师呢。

MindStudio 的分析说得很明白：“RAG 没有死，它被更精确地使用了。”“RAG 已死”的论断，主要针对的是代码导航这个特定场景——在这里，文件系统搜索和 AST 解析的确比向量检索更精准。

但对于文档问答、知识管理、大量非结构化文本的自然语言检索，RAG 仍然是标准方案，并且在持续进步（更好的分块策略、重排序、混合检索）。Cursor 的做法就是最好的例子：同时使用向量搜索和 grep，两者结合，取各自所长。

最新的一篇 arXiv 论文（2025 年 5 月）也通过系统性实验证实：在端到端 Agentic 工作流中，检索策略的选择与 Agent 架构之间存在复杂的交互关系——没有一种策略能在所有场景下都最优。换言之，那位读者的面试官问了个真正的好问题。

5. 与场景挂钩

基于以上分析，一个简单的决策框架就出来了。

适合 grep / 文件系统检索的场景：

• 数据是结构化代码
• 明确知道确切关键词或标识符
• 规模较小，无需构建和维护索引
• Agent 可以迭代重试，时间不是瓶颈

适合 RAG / 语义检索的场景：

• 数据是非结构化自然语言文档
• 用户问题措辞与文档表达可能不一致
• 需要跨语言、跨表达方式的理解
• 数据规模大，需要高效预索引
• 包含图像、表格等多模态内容

两者结合（混合检索）的场景：

• 代码库与技术文档混杂的环境
• 用精确匹配作为语义搜索的补充过滤条件

如果那位读者早看到这个决策框架，面试时或许就不会被问住了。

6. 结论

grep 和 RAG 的争论，本质上是一个关于数据特征与场景匹配的工程问题，而不是谁更先进的哲学争论。

Claude Code 用 grep 检索代码很成功，不代表企业知识库也该抛弃向量数据库；反过来，给代码搜索强加一堆 embedding 基础设施，也可能是过度工程化的浪费。

最成熟的 Agent 系统，往往是那些能根据数据类型和任务特征，智能选择检索工具的系统。

技术选型从来没有捷径——理解原理，匹配场景，才是正道。如果你也在面试中遇到过类似的技术选型问题，欢迎到云栈社区分享你的见解。

你遇到过类似的情况吗？