原论文："Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction"
AI 搜索产品背后的标准配方，大家已经默认为：把用户问题转成向量，在向量库里找最相似的文档片段，把排在前面的几条喂给模型生成答案。
Perplexity 这么做，ChatGPT 联网模式这么做，几乎所有带"AI 搜索"标签的产品都这么做。
一篇刚被 ICLR 2026 接收的论文提出了新观点：当 AI 模型本身已经足够聪明，这套"检索-增强-生成"的流水线反而成了瓶颈。
一场不公平的对决，落后的赢了
论文作者用 BrowseComp-Plus（专门测 AI 深度搜索能力的基准，题目需要跨文档拼凑线索）做了一个实验。
他们给 Claude Sonnet 4.6 装了两套搜索系统：
A 套（行业标配）：Qwen3-Embedding-8B 做向量检索，返回 top-k 文档片段。
B 套（DCI，Direct Corpus Interaction 直接语料交互）：不给任何检索器和索引。
只给终端工具——grep、bash、文件读取、find、轻量级脚本。
让 AI 直接在原始语料库里自己找。
结果：B 套准确率 80.0%，A 套 69.0%。
不仅高了 11 个百分点，成本还从 1440 美元降到 1016 美元，省了 29%。
一个没有向量索引、没有嵌入模型、没有检索 API 的系统，靠几个 Unix 命令行工具，全面碾压了精心调优的检索管线。
在更复杂的多跳问答上，差距更加触目惊心：
模型 | NQ | TriviaQA | Bamboogle | HotpotQA | 2Wiki | MuSiQue | 平均 |
|---|---|---|---|---|---|---|---|
ASearcher-Local-14B（最强检索基线） | 56 | 58 | 62 | 58 | 56 | 24 | 52.3 |
DCI-Agent-Lite (GPT-5.4 nano) | 72 | 84 | 72 | 72 | 68 | 40 | 68.0 |
DCI-Agent-CC (Sonnet 4.6) | 78 | 96 | 80 | 88 | 82 | 74 | 83.0 |
DCI 在六个数据集上全胜。
最极端的 MuSiQue（需要真·多步推理，不能走捷径），DCI 拿到了 74% 而传统基线只有 24%，简直是降维打击。
为什么 grep 比向量搜索更准
David S. H. Rosenthal 在他 2025 年的文章里已经预警过这个问题。
传统检索器的设计逻辑是"一个查询，一个排名列表"。这在十年前完全合理。
但 AI Agent 的搜索行为和传统搜索完全不同。
它会搜一个关键词，发现一条线索，用这个线索去搜另一个词，在某个文件里定位关键段落，提取出一个人名或日期，再用这个人名去搜其他文件。
每一步都很小，但每一步都必须精准。
向量检索在这个场景下暴露了致命缺陷。
你搜"2024 年第三季度营收"，它可能返回一堆语义上相似但完全无关的内容。
而 grep "Q3 2024.*revenue" 返回的只有精确匹配。
论文把这个问题定义为"检索界面分辨率"（retrieval interface resolution）。
分辨率越高，AI 能看到的信息颗粒越细。
向量检索给的是"整篇文档"级别的大块信息，grep + bash 可以定位到具体某一行。
论文用一个比喻把这件事说清楚了：DCI 的搜索方式，就是人类研究员在图书馆里找资料的方式。
一个历史系博士生做研究的时候，不会把选题交给图书馆管理员说"帮我找 10 本书"。
他一定自己进书架、翻目录、找索引、看到有用的段落读上下文、标注、换一本书继续。
DCI 给 AI 的就是这种"自己翻"的自由。
但 grep 也有一个致命短板
论文没有美化自己的方案。
当语料库从 10 万篇扩到 20 万篇，DCI 的工具调用次数从 38.5 次飙升到 86.9 次，延迟翻倍，成本翻倍，准确率掉了 13.6 个百分点。
扩到 40 万篇时，准确率跌到 37.5%，20 道题直接超时。
DCI 目前只适合中小规模的本地语料库。
大规模网页搜索，向量检索仍是唯一可行的方案。
但换个角度看，这个结论揭示了一个规律：DCI 的强项是"深挖"而不是"广撒网"。
论文的轨迹分析佐证了这一点。
DCI 的文档覆盖率（coverage）比传统检索更低，只找到了 28% 的黄金文档，传统检索找到了 56.7%。
但 DCI 的"定位精度"（localization）是传统检索的两倍多。
也就是说，DCI 的成功路径是：找到一个靠谱的入口，钻进去深挖。
grep 搜一个关键词，找到一行匹配，用 head、tail、sed 看周围内容，发现新实体，再用新实体去搜。
这种"线索驱动"的策略，和人类做研究时的搜索行为几乎一模一样。
这张图很关键。
它说明 DCI 的胜出不是因为传统检索"没搜到"。
在 DCI 赢下的 176 题中，142 题传统检索其实已经找到了至少一篇相关文档。
东西搜到了，但用不上。
这就是"检索界面分辨率"的实锤：传统检索把证据以"整篇文档"的粒度丢给 AI，AI 面对满篇文字找不到那个关键数字。而 DCI 让 AI 自己用 grep 定位到那个数字，再用 bash 去算、去验证。
联想国内 36 氪之前报道过的现象：很多企业花大价钱上了向量数据库，但实际检索效果并不好。
问题可能不在于数据库本身，而在于他们把"匹配"当成了"理解"，把"相似性"当成了"相关性"。
够用就好：只留 grep 和读文件
论文还做了一个更出格的实验。
他们把 DCI Agent 的工具箱砍到只剩两个：read（读文件）和 grep（关键词搜索），连 bash 都没给。
这种极简配置下，准确率 61%，已经比传统检索的 45% 高出 16 个百分点。
加上 bash 后涨到 73%，代价是工具调用量大幅增加。
这个结果传递了一个清晰的信号：DCI 的大部分收益，来自"能直接搜索原始文本"这个核心能力。
grep + 阅读，两个最朴素的工具，已经够突破传统检索的瓶颈了。
复杂的编程工具是锦上添花，不是本质。
这也意味着，即使未来 AI 的能力继续增强，grep 级别的文本搜索工具也不会过时。
它和 AI 的推理能力是互补关系：AI 擅长理解，grep 擅长定位。两者配合效果最好。
开发者该从哪里重新思考
这篇论文不是让你现在就去拆掉向量数据库。
BM25 和 dense retrieval（密集检索） 在大规模、静态语料库上仍然是最好的选择。
但它提出了一个被行业长期忽视的问题：检索不只是"哪个模型效果更好"，它是"AI 和知识之间用什么界面交互"的问题。
界面的粒度，直接决定了 AI 能看到什么、验证什么、对什么做出反应。
说一个国内开发者每天都会遇到的场景。
代码库里搜"登录逻辑"，如果用向量搜索，返回的代码片段会混着注册、密码重置、OAuth 等各种东西。
如果直接 grep "def login"，返回的就是精确的函数定义。
省掉的不是几秒钟，而是一整轮"找到了但不对，再搜一次"的试错。
论文通信作者在致谢中特意提到，这项研究受到了 Claude Code 和 SWE-agent 的启发。
在编程任务里，终端工具早已被证明是 AI 获取信息最高效的方式。
这篇论文本质上是在追问：为什么搜索类任务不能走同样的路？
答案可能比我们想象的简单：可以，而且效果更好。
DCI 不是一个要取代向量搜索的方案。
它是一块拼图，补上了传统 RAG 架构里缺失的一环：当 AI 已经足够聪明，给它足够细的触角就够了，不需要替它预处理那些它自己本来能发现的东西。
对于小规模、本地化、动态变化的语料库，DCI 不仅更准，还更省钱。
对于大规模场景，未来更大的上下文窗口和更聪明的上下文管理策略，可能继续扩大 DCI 的适用范围。
这篇论文最触动我的地方，是它用最简单的东西打出了最好的效果。
没有炫技的模型架构，没有复杂的索引工程。就把"搜索"这件事的粒度做细。
有时候，技术进步的答案不是"做得更多"，是"拦得更少"。