VentureBeat 这篇文章（发在 Orchestration 板块）讲的其实是一篇论文的工程含义：来自多所高校的研究者提出 Direct Corpus Interaction（DCI，直接语料交互）——让 agent 绕开 embedding 模型和向量索引，直接用命令行工具去搜原始语料。核心论断比较反直觉：在 agent 越来越强的当下，检索质量不再只取决于 embedding 训得好不好，而取决于模型与语料库交互的那个接口的 interface resolution（接口分辨率，可以理解为「这扇窗能看多细、能看几次」）。而 top-k 向量检索，恰恰是一个 resolution 很低、且不可逆的接口。

传统 RAG 的瓶颈：top-k 是一道不可逆的闸门#

经典 RAG 的链路是离线的：文档被切块（chunk）、过 embedding 变成向量、灌进向量库建索引。查询来的时候，retriever 在整个库里打分，返回一个排好序的 top-k 片段列表。所有证据都必须先过这道打分闸门，下游推理才能开始。

文章（和论文）点出的问题是：无论 lexical（BM25）还是 semantic（dense retriever），都把「访问语料库」这件事压缩成了推理之前的单步 top-k。对一次性问答这够用，但对 agentic 任务就成了硬伤——

  • 需要精确匹配：确切的字符串、数字、版本号、错误码、文件路径；
  • 需要稀疏线索的组合（sparse clue conjunction）：好几个弱信号凑在一起才指向答案；
  • 需要局部上下文核对：看一眼命中位置前后几行；
  • 需要多步假设修正：先发现中间实体、再根据部分证据改计划。

最值得注意的一条：被 top-k 早早筛掉的证据，再强的下游推理也捞不回来。 闸门关上就是关上了。agentic 任务偏偏要反复试探、回头修正，这种「单步压缩」的接口和它根本不匹配。

DCI 是什么：把语料库当文件系统，用终端工具直接搜#

DCI 的做法简单到有点反常规：不要 embedding、不要向量索引、不要 retrieval API，把 agent 放进一个类终端环境里，它的「观测」就是工具的原始输出——文件路径、命中的文本片段、命中处的上下文行。

agent 用的全是标准命令行工具：

  • 导航 / 定位文件：find、glob 遍历目录结构；
  • 精确匹配：grep、rg 找关键词、正则、确切字符串；
  • 局部查看：head、tail、sed、cat，以及临时写的轻量 Python 脚本，去读命中点周围的上下文或某段文件。

这样一来，检索不再是「推理前的一步」，而变成 agent 推理循环里可以反复调用、随时改主意的动作：grep 一下没中就换个 pattern，发现新实体就顺着再搜一层。论文把这叫「提高了交互接口的 resolution」。附带的两个工程好处也很实在：不需要离线建索引，以及天然适配会变的本地语料——语料更新了，下一次 grep 直接就是最新的，没有「重新 embedding、重建索引」的滞后。

它到底强在哪：benchmark 结果#

论文标题是《Beyond Semantic Similarity: Rethinking Retrieval for Agentic Search via Direct Corpus Interaction》（arXiv:2605.05242），作者里有 Yejin Choi、James Zou、Jiawei Han、Wenhu Chen、Jimmy Lin 等。它在两类任务上做了评测：

  • 传统 IR benchmark：BRIGHT（5 个数据集）、BEIR（6 个数据集）。DCI 在多个数据集上明显超过 sparse、dense、reranking 这几类强基线（对比对象包括 ColBERT-v2、BGE-M3 等），且不依赖任何传统语义检索器。
  • 端到端 agentic 检索：BrowseComp-Plus、multi-hop QA，同样拿到很强的准确率。

论文的官方摘要用的是定性措辞（「substantially outperforms」）。社区的发布摘要给出的几个亮眼数字是：BrowseComp-Plus 上约 +11%、多跳 QA 上约 +30%、BRIGHT 上最高约 12% 的绝对提升——具体数字以论文表格为准，但量级足以说明问题：在「需要拼线索、要多跳」的任务上，DCI 的优势最大，而这正是向量库最不擅长的地方。作者还放了一个轻量实现仓库（DCI-Agent/DCI-Agent-Lite）；另有后续工作 GrepSeek（arXiv:2605.29307）专门去训练擅长 DCI 的搜索 agent。

落地：不是替换向量库，而是混合#

文章特意强调 DCI 不是要强制替换现有向量基础设施，而是互补。对编排工程师和数据架构师，近期最实用的落地形态是混合（hybrid）：

  • 用向量检索做宽口径的候选召回——大语料、低延迟、高吞吐，先把范围筛小；
  • 用 DCI 做精确过滤和多步推理——在候选集上让 agent grep 式地迭代细化、组合复杂查询；
  • 按任务和语料特性动态切换。

什么时候该用 DCI：代码库、日志、结构化数据这类「精确匹配和可组合性很关键」的场景，以及频繁变动、不值得反复建索引的动态语料。 什么时候别用：大规模非结构化语料、追求低延迟高吞吐、固定 top-k 就够用、或者 token 成本敏感的场景——这时向量检索依然更划算。

代价也写得很清楚：DCI 把检索变成多步 LLM 交互，延迟更高、token 消耗更多、算力更重（Milvus 一方的反驳就是「LLM 驱动的 grep 循环会在规模上推高成本」）。它省掉了离线索引，但要求 agent 有实时的文件系统访问——而文章几乎没谈这背后的安全问题：直接给 agent 文件系统读权限意味着权限边界、数据泄漏面都需要单独的威胁建模，这块基本是空白，得自己补。

几点笔记（个人观点）#

  1. 这篇最有价值的一句话是 interface resolution，说人话就是：agent 是『隔着窗口要资料』，还是『自己走进库房翻』。 过去我们默认「检索质量 = embedding 训得好不好 + reranker 排得准不准」，DCI 换了个角度：检索质量取决于 agent 能多『细』、多『多次』地碰到语料本身。

    举个例子。假设要在一大堆日志和代码里查清楚错误码 ERR_2048 是怎么来的：

    • 向量检索像隔着柜台问管理员：你说「帮我找跟这个报错有关的资料」，他凭语义相似度搬来最像的 5 段（top-k）。可 ERR_2048 这种确切字符串,embedding 根本不敏感——真正定义它的那行如果没进前 5,就永远拿不到了，而且你只能问这一次，问完推理就得在这 5 段上硬做。
    • DCI 像直接把 agent 放进库房：它 grep -r "ERR_2048" 找到所有出现位置，发现是某个 enum 里定义的，于是顺着 grep 那个 enum 名、再 grep 抛出它的函数、sed 看一眼上下文……没命中就换关键词，发现新线索就再翻一层。访问语料的 resolution 高得多，而且能反复来。

    一旦模型够强、会自己规划这串动作，瓶颈就从「召回算法准不准」挪到了「你给 agent 开的那扇窗有多大」。向量检索那扇窗是「一次、top-k、只认语义相似」，resolution 天然受限；终端那扇窗是「任意次、精确匹配、可顺藤摸瓜」。这是个值得记很久的 reframing。

  2. 其实你天天在用的 Claude Code，就是「代码库上的 DCI」。 很多人下意识以为「AI 编程工具 = 先把整个 repo 灌进向量库，再语义搜索」。但 Claude Code 根本不建索引，它就是直接 grep/glob/读文件，在推理循环里一遍遍搜——和这篇论文描述的做法一模一样。换句话说，这套打法早就在生产里被验证好用了，论文只是事后补了个「为什么好用」的解释。 这也印证了 读 Affirm 那篇里那句体感：「CLI 在很多场景比 MCP 更可靠」。想细看可以翻 Claude Code 的 harness。

  3. 它不是说「向量库没用了」，而是说「别一上来就默认套 RAG」。 怎么判断该用哪个？看你的问题长什么样：

    • 「关于 X 大概有哪些资料？」 —— 答案模糊、语料又大，向量检索一把召回最划算。我之前那两个 RAG（pgvector 数学辅导、Spring AI 今日运势）就是这类，向量库是主场。
    • 「ERR_2048 到底是谁、在哪定义、被谁触发？」 —— 要精确命中、要顺着线索翻好几跳、语料还天天在变，这时候先别急着建索引，让 agent 直接 grep 往往又快又准。

    所以更实用的判据不是「RAG 香不香」，而是「这是一次就能召回，还是要边搜边改主意」。

  4. 在混合架构里，向量库的角色正在从「主角」退成「门口的粗筛」。 打个比方：向量库像门口的接待，先按相似度把一大堆资料粗粗筛成一小摞；DCI 像进门后的侦探，在这一小摞里精确比对、顺藤摸瓜。 它跟另一条趋势（「Agents 让向量检索更难做对，而不是被取代」）并不矛盾——向量库不会消失，只是从「检索的终点」变成了「DCI 的入口」。落地上的提醒就一句：早点把「粗筛」和「精查」这两层拆开，别糊在一起。

  5. 真要上之前，先算两笔账：钱 + 安全。

    • 钱（和速度）：grep 循环里每多翻一层，就是多一次 LLM 调用——token 和延迟会随语料规模、随翻的跳数往上涨，规模一大就肉疼。向量检索一次召回就结束，这点上反而便宜。
    • 安全：让 agent 直接读文件系统，等于给它开了一扇能翻任意文件的门——它可能 grep 到本不该看的密钥、隐私、别的项目的代码。这是一个容易被忽略的攻击面，文章基本没谈，得自己补权限边界和威胁建模。

    对金融这类强约束场景，护栏（guardrail）要和提速同步上，不能只图快——这跟 Affirm 把 validation 列为最大投入是同一种谨慎。

我的取舍：把 DCI 当成工具箱里多出来的一把锤子，而不是「向量库已死」的宣言。 目前最能直接参考的，是那条选型直觉——问题越像「侦探破案」（要拼线索、要回头改计划），越该把检索交给会用终端的 agent；越像「图书馆问个路」（一次召回就够），越该留给向量库。

参考资料#