无检索器RAG命中率65.4%，然后卡在谁写目录上

标准RAG的瓶颈不在生成，在检索那一下。文档切块、转成embedding、存进向量索引；查询来了也转embedding，取top-k，再用reranker重排，最后把最好的几段塞给LLM。问题在于，相似度搜索先决定了LLM能看到什么。正确段落没进top-k，后面再强的reranker也捞不回来。

Cornell和ASAPP的新论文换了个思路：保留文档和LLM，把相似度搜索换成导航。文档被组织成树，像目录。一个决策模型从顶层往下走，逐层问是/否问题。这个模型不生成文本，它读同一份上下文，对每个是/否问题返回概率，每个阶段一次前向。

流程大概是：先看顶层文档，模型把查询和每个候选文档放在一起，问“相关吗”，留下最好的几个；再打开这些文档，对里面的段落问同样的问题；可选一步，用一个多选题重排前20个段落。被丢掉的文档不会打开，里面的段落也不会被打分。

论文在Natural Questions上测试，语料是268万条Wikipedia段落。它的top-1结果有65.4%的时候包含答案。embedding搜索加8B reranker是48.0%，GPT-5 reranking是60.8%。

这里有个反常识的细节：增益来自排序，不是覆盖。embedding搜索的top-100里包含答案的比例是98.4%，导航后的短名单是94.0%。也就是说，向量检索更容易把答案留在池子里，但导航更擅长把答案放到第一。

论文自己也列了限制。它需要一套合理的层级；早期被剪掉的文档就彻底没了；只在查询时跳过embedding搜索，因为Wikipedia那棵树是离线用embeddings建好的。中位检索时间低于2秒，但每种方法在不同环境里计时，不能当成受控的速度对比。

评论区的几个问题比摘要更接近工程现场。有人问，Wikipedia有现成结构，共享盘没有，目录谁写。有人说，树走错和top-k漏掉是同一种失败，只是换了个位置，根节点附近走错一支，正确段落一样消失。还有人问语料每天变怎么办：树离线构建，新文档归错分支，在下次重建前可能每次查询都在顶层被剪掉。更稳的做法也被提出来了：embedding负责召回，决策模型负责排序，这样至少不会在模型看到之前就把东西扔掉。

Jev作为reranker的独立benchmark也值得看。在SciFact、NFCorpus、FiQA三个BEIR数据集上，BM25取top-30，Jev batch的nDCG@10均值是0.501，Voyage rerank-3是0.504，Cohere rerank-v3.5是0.486，Mixedbread v3.1-listwise是0.511。价格上，Jev约0.54美元每千次查询，Voyage约0.50，Cohere约2.00。延迟中位数223毫秒，p95接近1.4秒，尾部比专用reranker差。它多给的是一个校准过的概率，可以直接拿来剪枝：SciFact上，Jev打分高于0.9的文档有76%被判断为相关，低于0.1的文档只有0.5%。

如果正在搭RAG，这件事更实际的态度不是二选一。先把无检索器RAG当成一个排序器来benchmark，和现有向量检索加reranker的链路对比。树能不能建、剪枝错一次代价多大、语料更新频率多高，这些比65.4%更能决定它能不能上线。论文链接：https://arxiv.org/abs/2610.35868 。Jev reranker的测试在：https://hevmind.com/writing/jev-as-a-reranker/ 。