/tags/retrieval/ Recent content in retrieval on Hugo -- gohugo.io en Sat, 06 Jun 2026 13:00:00 +0800 /reading/venturebeat/agents-need-a-terminal-not-vector-database/ Sat, 06 Jun 2026 13:00:00 +0800 /reading/venturebeat/agents-need-a-terminal-not-vector-database/ 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、重建索引」的滞后。