当 grep 击败向量检索：Agent 框架如何重塑搜索这件事
你大概听过这个说法：BM25 是上古遗物，向量检索才是现代做法。在 RAG 系统里，embedding 相似度搜索已经成了默认选择，几乎所有教程都这么教。
但 Sahil Sen 和团队做了一组实验，发现事情没那么简单。在 LongMemEval 的 116 个长记忆问答任务上，grep 在大多数 Agent 框架里都打败了向量检索。更反直觉的是：换一个 Agent 框架，同一个检索方法的排名可能直接反转。
这篇论文不是"grep vs vector"的口水战。它揭示了一个被广泛忽视的事实：在 Agent 场景下，检索策略不能脱离 Agent 框架单独评估。同一个检索方法，换个框架就可能从第一名变最后一名。
实验设计：两个维度交叉
团队设计了两个实验，系统地拆解"检索策略×Agent框架"的交互效应。
实验 1：grep vs 向量检索，跨 4 个 Agent 框架
四个框架分别是：
- Chronos：团队自研的定制框架，用类别条件化提示（category-conditioned prompting）控制搜索行为
- Claude Code：Anthropic 官方 CLI
- Codex：OpenAI 官方 CLI
- Gemini CLI：Google 官方 CLI
实验 2：噪声压力测试
在实验 1 的基础上，逐步往对话历史里掺入无关会话。每个问题的"金矿会话"（包含答案的会话）始终保留，但周围的"垃圾会话"从 5 个一路加到 66 个。这模拟了 Agent 在长程对话中搜索时，上下文里堆满了无关信息的情况。
核心发现 1：grep 在多数配置下胜出
实验 1 的结果让团队自己都意外。在 Chronos 上，grep 在 Opus 和 Haiku 两个 backbone 上都打败了向量检索。在 Claude Code 上，grep 对 Opus 和 Haiku 的优势在每个配置都成立。在 Gemini CLI 上，grep 对 Opus 依然胜出。
只有 Codex/GPT-5.4 是个例外——它的 programmatic grep（文件路由）严重翻车，但 inline grep 依然有竞争力。
为什么 grep 能赢？ 论文的分析很到位：
> "Grep is deliberately narrow: it rewards the model for generating high-precision patterns, but it punishes vocabulary mismatch. Dense retrieval is deliberately broad: it can surface paraphrases and oblique mentions, but it also elevates semantically 'near' distractors."
翻译过来就是：grep 是精确打击，向量检索是区域覆盖。LongMemEval 的问题往往需要定位到具体的字面证据（"用户在第 3 次会话里提到过敏药物是什么"），这种场景下精确匹配比语义近似更有效。但如果问题需要跨会话推理（"用户这周情绪变化趋势"），向量检索的语义覆盖可能更有用。
核心发现 2：框架比检索方法更重要
真正让这篇论文与众不同的是这个发现：同一个检索方法，换个框架，排名可能反转。
最戏剧性的例子是 Gemini CLI 上的 Gemini 3.1 Pro：在 Chronos 框架下，grep 在 full 配置下达到 86.6% vs 向量 84.5%；但在 Gemini CLI 框架下，同一个模型+同一个检索方法，向量检索 89.7% vs grep 78.5%——排名直接反转。
论文的解释是，Agent 框架不是"被动的管道"：
> "Chronos's category-conditioned prompting and controlled tool surface area shape what gets searched first and how failures are repaired, whereas CLI agents inherit provider-specific tool ergonomics, sandboxing, and transcript formatting."
换句话说，"检索"在表格里是检索，在 Agent 里其实是"检索+编排"。框架决定了模型怎么生成查询、怎么处理失败、怎么整合多次检索结果。这些编排层面的差异，影响力和换一个检索方法一样大。
这对 benchmark 设计有直接启示：只报告 BM25 vs ANN 的静态 pipeline 对比，会严重低估 Agent 编排引入的方差。
核心发现 3：file-based 路由是个陷阱
实验 1 还测试了一个常被忽视的维度：工具结果怎么交付给模型。
inline 模式：工具返回结果直接塞进对话上下文 file-based 模式：工具把结果写到文件，模型需要主动去读
file-based 的动机是缓解上下文压力——向量检索的 top-k 结果可能很长，塞进上下文会挤占空间。但实验发现一个反直觉的现象：
> "Programmatic routing trades context bandwidth for compositional tool competence; gains are realized only when the agent reliably closes the loop."
翻译过来：file-based 用"省上下文空间"换来了"模型需要更多步骤才能整合信息"。如果模型能可靠地完成"读文件→提取信息→整合→回答"这个链条，file-based 是赚的。但如果模型在中间任何一步出错，整个流程就断了——便宜检索（正则匹配 JSON）端到端并不便宜。
Codex/GPT-5.4 的 programmatic grep 灾难就是这个陷阱的极端案例：检索本身很简单（grep 一个 JSON 文件），但 Codex 把每次命中都变成一个多步工作流，而 GPT-5.4 执行这个工作流不可靠。
核心发现 4：噪声压力下的非线性衰减
实验 2 揭示了更微妙的现象。常识认为：语料越大，grep 越不行（因为要扫更多无关文本），向量检索应该更稳（因为 embedding 能过滤语义噪声）。
实际结果更复杂：
- Chronos Opus：grep 在 s5（5 个会话）时 83.2-89.7%，到 s20 峰值 90.5%，s30 跌到 85.3%，full 回升到 89.7%——非单调变化
- Claude Code Opus：grep 在 s20 峰值 95.7%，full 降到 94.0%——也是非单调
- Gemini CLI Pro：向量检索始终领先 grep，差距随噪声增加而扩大
为什么这很重要
这篇论文的价值不在于"grep 更好"这个结论——那只是特定数据集上的结果。真正的贡献是揭示了一个被忽视的评估盲区：
Agent 场景下的检索评估，不能只看检索方法，必须看"检索+编排"的组合。
这和软件工程里的"编译器+操作系统"关系很像：同一个编译器在不同操作系统上性能排名可能不同，因为编译器优化和操作系统的调度策略交互。你不能脱离操作系统谈编译器优化。
对实践者的启示：
1. 别默认选向量检索。如果你的任务需要定位具体字面证据，grep 可能更好 2. 别只换检索方法。换框架可能比换检索方法影响更大 3. file-based 不是免费午餐。省了上下文空间，但增加了编排复杂度 4. benchmark 要报告编排维度。只报告"BM25 vs ANN"会掩盖框架引入的方差
局限与展望
论文的局限在于实验范围：LongMemEval 是一个特定类型的长记忆问答任务，结论能否推广到其他任务类型（代码搜索、文档问答、多跳推理）需要更多验证。四个框架虽然覆盖了主流提供商，但都是 CLI 形态，GUI Agent 和 API 调用模式可能有不同的交互效应。
更深层的问题是："检索方法"和"Agent 框架"的边界本身在模糊。Chronos 的类别条件化提示本质上是一种轻量级的检索策略增强，它和底层检索方法的交互正是这篇论文发现的核心现象。未来可能需要更精细的分解——把"编排"拆成查询生成、结果处理、失败恢复等子维度，分别评估它们和检索方法的交互。
论文没有公开代码。Chronos 框架是自研的，可能需要联系作者获取。但从方法描述看，实验设计本身（grep vs vector × 4 框架 × inline/file-based）不难复现，关键是控制变量和统计显著性。
一句话总结
在 Agent 场景下，检索策略不能脱离 Agent 框架单独评估——"grep vs 向量"的答案取决于"Chronos vs Claude Code"和"inline vs file-based"。检索不是孤立的，是编排的一部分。
---
> 论文链接：https://arxiv.org/abs/2605.15184 > > 作者：Sahil Sen, Akhil Kasturi, Elias Lumer, Anmol Gulati, Vamse Kumar Subbiah > > 机构：独立研究