不建向量库，让模型自己翻文档

检索这套东西十几年没变过骨架：先向量化，再算相似度。10 月 26 日的一篇论文换了个思路——不用任何检索器，让语言模型自己决定往哪翻，结果反而更快更准。

一、发生了什么

论文开头点破了一个尴尬：语言模型这两年强了一大截，检索却还停在词面匹配和固定向量空间里。由此产生一条能力断层——检索器没找到的东西，再强的生成模型也救不回来。

研究者提出的方案叫 DecisionRAG，出自康奈尔学者所在的团队。做法是让模型像人逛图书馆：从大类目下钻到小段落，每一层把几个候选分支放进同一段上下文里一起判断，一次前向就能比出哪个值得继续看，中间不生成一个字。判断在共享上下文里做，相关性高下立刻可比，这是它比逐条打分的重排器省时的地方——后者要给每个候选单独过一遍模型，开销按候选数累加。整套流程更像查字典：先翻大类，再翻小节，最后定位到那一段，而不是把整本书每页都读一遍。

补一点背景，这是背景，不是论文结论：稠密检索的主流地位来自工程惯性——索引建一次，单次查询便宜，生态工具齐全。它的结构性弱点是训练语料覆盖不到的领域，向量空间里根本没有合适的邻居，查不到就是查不到。这也是论文说「能力断层」的由来。

成绩单：不做任何任务定向训练、也没有第一阶段粗筛的前提下，在一个多文档对话基准上比带 80 亿参数重排器的稠密检索高出 13.8 个召回点，在一个问答基准上高出 17.4 个命中点。四个基准里包括一个 268 万段维基文本的语料，单次查询只要 0.7 到 1.8 秒。

边界同样直白：数字来自论文所选基准，你的语料结构、查询分布不同，收益要自己量。

二、跟你有什么关系

给企业知识库选型的：如果你的文档天然有目录、章节这类层级，这套「顺着结构下钻」的玩法可能比重新调向量参数划算。

维护向量库的：冷启动、切分粒度、更新延迟这三大痛点，这里都不存在，值得做个对照实验再决定去留。

做 agent 长文档任务的：检索质量直接封顶回答质量，这条能力断层补上了，下游才谈得上扩展。

三、怎么用

1. 把语料先按结构分层：目录、标题、段落，每层是一组候选分支。
2. 每层把候选放进同一上下文让模型挑，只留值得下钻的，砍掉其余。
3. 拿你现有的向量检索做基线，各跑五十条真实查询，比命中率和耗时，再决定要不要迁。结构化强的语料优先试，纯扁平文本收益会打折。

四、三个别信的说法

检索必须先建向量库。 论文证明了没有粗筛、没有定向训练也能跑通，向量库是选项，不是前提。

让大模型逐层判断一定很慢。 每次查询不到两秒，因为判断不生成文本，成本比想象低得多。

重排器叠得越多越准。 基线可是带大参数重排器的稠密方案，照样被超过，堆件的思路该重新算账。

五、一句话结论

检索的瓶颈从来不是算相似度，是决定往哪看。

信息来源

• 用决策模型在文档里导航的检索新方案（arXiv 摘要），2026 年 10 月 26 日提交

功能与价格以官方公告为准。本文写于 2026 年 10 月 28 日。