用户问“海水煮开后能喝吗”，一篇讲盐水蒸发的文档可能有助于回答这个问题：加热时水蒸发，盐会留下。文档没有直接谈海水能否饮用，但只要想到煮沸是否除盐，就能看出它与问题的关系。

Reasoning-intensive retrieval（RIR，推理密集型检索）关注这类需要推断才能判断相关性的检索任务。它的困难在于，系统还没找到有用的文档，就要对解题所需的知识有所判断。如果在固定候选的流程里，把推理全部留给最后的回答模型，检索阶段遗漏的证据就无法参与解题。

RIR 的任务定义

海水问题与盐水蒸发的文档，不是同一个意思的两种说法。一个问能否饮用，一个解释物理过程。把它们联系起来，需要识别问题中的限制条件，再判断文档里的原理能否用于这个情境。换同义词、补几个同主题词语，不一定能补出这层联系。

类似的关系也出现在代码和数学检索中。报错描述与函数文档的联系，可能要分析代码原本想完成的操作才能看出来。两道题的题面不同，却可能使用同一种算法或定理。这里的相关性取决于知识的用途，主题相近只是线索，不能代替适用性判断。

图中上半部分把这种联系展开了：从海水能否饮用，想到溶解盐在煮沸后是否留下，再寻找盐水受热的原理。只找到一篇文档，也可能需要这样的推断。RIR 因而不以检索轮数或思维链长度来定义，模型最后是否写出推理过程，也不是判断这类任务的依据。

这也解释了它与 RAG 中答案推理的区别。模型读到证据后能否解题，与它能否找到证据，是两个可以分别考察的能力。下文主要使用的 BRIGHT 基准给出问题、文档库和相关文档标注，要求返回排序后的文档，不要求生成最终答案。它的相关材料包括真实问答中的参考网页、代码所需的语法文档、共享算法的例题和适用定理。

候选召回与相关性判断

如果把问题和文档一起交给 LLM，让它分析原理是否适用、代码能否完成所需操作，就可以得到比词面匹配更充分的相关性判断。推理重排器走的就是这条路线。困难是，文档库很大时，逐篇做这种分析代价太高。

常见系统因此先做向量检索，取出少量候选，再交给重排器细读。查询和文档分别编码，能高效地搜索全库，但两者之间复杂的适用关系需要体现在向量相似度中。有用的文档如果在这一轮被遗漏，后面的重排器就没有机会判断它。

系统需要在细读之前选出候选，但细读又可能改变它对所需知识的判断。只增强重排器的推理能力，并不会自动扩大它能看到的候选集。要让这些判断影响候选选择，就需要改动编码、匹配文本或搜索过程。

下面几项工作可以按它们改变的对象放在一起看：

这些改动可以组合。查询扩展仍需要检索器理解扩展后的文字，搜索过程也依赖模型对已读材料的判断。它们不构成一套必须依次执行的流程。

合成数据与表示学习

ReasonIR 从训练数据入手，用 LLM 构造问题与适用文档的配对样本，再训练检索编码器。LLM 负责生成数据，训练出来的检索器仍然输出向量。

例如，给定一篇介绍昼夜节律的文档，直接生成“什么是昼夜节律”，靠词语匹配就容易找到原文。ReasonIR 生成的问题则是：夜班人员白天难以入睡，工作时又感到疲劳，主要原因可能是什么？

图的最下方就是这个例子。昼夜节律文档能解释查询中的现象，被用作正例。右下角的负例也谈夜班、体温和白天睡眠，却没有提供所需的解释。训练要求编码器给昼夜节律文档更高的相似度，即使负例重复了更多题面词语。

这类数据称为 HQ（hard query，难查询）。LLM 从真实文档出发，考虑其中的知识可以用于哪些情境，编写一个脱离原文也能读懂的问题，再另行生成一个看似相关、实际无助于解题的难负例。正例保留真实文档，合成的是查询和负例。

另一类 VL（varied-length，不同长度数据）在图的中间，查询和正例文档都由 LLM 生成，负例另行生成。这类数据覆盖更长、信息更多的查询。复杂问题常常带有背景和条件，经过 LLM 改写后还会变长，VL 让编码器在训练时见到这类输入。

两类数据与已有公共检索数据混合，用于对比训练：提高查询与正例的向量相似度，降低与负例的相似度。训练完成后，ReasonIR 仍是双编码器，查询和文档分别编码，可以直接做向量检索，并不需要每次先生成一段推理文字。

查询改写是可选的另一个步骤。下表分别使用原查询和 GPT-4 改写后的查询，在相同起始模型、相同训练步数下比较训练数据组合。指标是 BRIGHT 的 nDCG@10，分数越高，表示前十条结果的排序质量越好。

两类数据一起使用时，两列分数都最高。只加 HQ 对原查询有帮助，对改写查询则没有带来提升。VL 带来的变化也不限于长度，样本内容随之改变，不能把表中的增益都归因于长查询训练。

ReasonIR 改变了向量分数所学习的相关关系，却没有要求在线逐篇推理。表中改写查询后还有提升，也说明学习这种关系与补充查询信息并不冲突。

索引增强与查询扩展

不重新训练检索编码器，也可以先把隐含的联系写出来，再交给它匹配。这个做法有两个方向：从文档出发，说明它能用于什么问题，或者从当前问题出发，推断需要寻找什么知识。SPIKE 和 DIVER-QExpand 分别处理这两端。

场景索引

SPIKE 不改检索编码器，而是在索引中为文档补充使用场景。一段代码除了按原文检索，还可以通过它能满足的需求被找到。

图的下半部分给了一个 pandas 的例子。用户想合并多个 DataFrame，也就是表格数据对象，却遇到传入 list 的报错。右边文档里有 pd.concat 的代码及输出，中间补充的场景将用途写了出来：一次拼接多个 DataFrame，以及按列名对齐。

用户不知道 pd.concat，也可以用合并多个表的需求匹配这些描述，再找到原文。场景生成因此要多考虑一步：什么样的问题会用到这段代码？仅概括代码写了什么，未必能得到这样的描述。

生成时，模型先识别文档主主题 M，提取不同方面 K，据此提出可能的信息需求 I，再写出文档如何满足需求的解释 E。每条解释与主主题组合成 M+E，分别编码存入索引。原文向量也会保留，一篇文档可以对应多个场景向量。

检索时，系统计算查询与原文、各个场景的相似度。场景分数取最高值，再与原文分数加权，因此只需有一种用途符合当前问题，就可能提高文档的排名。

SPIKE 也用了合成数据，但训练对象与 ReasonIR 不同。它先用 GPT-4o 为一批文档写场景，再用这些样本训练较小的 Llama-3.2-3B-Instruct 场景生成器，随后为语料库生成场景。检索编码器不需要重新训练，在线查询也不必重新生成场景。

实际实验为控制打分成本，先按原文向量取前 1000 篇，再计算这些文档的场景分数。因此，场景增强能调整这批候选的排序，但无法找回排在这批候选之外的文档。

反馈式查询扩展

SPIKE 生成场景时还不知道用户会问什么，描述需要提前准备。查询扩展则可以围绕眼前的问题补充概念，或者草拟一段答案作为搜索输入。不过，模型只看问题也可能想错方向。DIVER 系统的查询扩展模块 DIVER-QExpand 会让模型读检索到的文档，用其中的信息修改扩展内容。实验先做两轮带文档反馈的扩展，之后再做最终检索：

1. 用原查询检索，取排名靠前的五篇文档。LLM 从中识别有帮助的信息，结合自身知识写出一段回答式扩展。
2. 用扩展继续检索，排除已经取过的文档。LLM 阅读原问题、新材料和上一轮扩展，修订已有内容。
3. 用原查询加最后一轮扩展完成最终检索，不拼接全部中间版本。

扩展中的“答案”只是供检索使用的草稿，还要根据后续材料修订。提示中也提醒模型，检索到的文档多数可能不相关，不能直接照搬。

DIVER 将这个模块与另一种反馈式查询扩展方法 ThinkQE 比较。在这组对照里，搭配 BM25 时 ThinkQE 略好，换成 ReasonIR 后则是 DIVER-QExpand 更好。扩展文本最终仍是检索器的输入，增加了哪些信息、检索器是否会利用这些信息，要放在一起看。写出一段完整解释，与得到一个有效的搜索请求，并不是同一件事。

推理引导的迭代搜索

DIVER-QExpand 读完文档后修改搜索请求，下一批候选仍由检索器按新请求选出。另一种办法是让模型直接影响候选来源：既然已经判断某篇材料或某个主题有帮助，就继续查看它附近的文档或对应的目录。

这样，重排就不必等到候选全部取完后才开始。它可以与搜索交替进行，读到一部分材料，判断哪些有用，再决定把后续计算花在哪里。RGS 和 LATTICE 都采用这种交互，只是给模型提供的搜索入口不同。

文档近邻图搜索

Reranker-Guided Search（RGS）利用重排结果选择下一轮搜索的起点，从排名靠前的文档访问其他候选。

RGS 先按文档向量建立近邻图，每个节点是一篇文档，边连接向量相近的文档。查询到来后，先通过向量检索找到起始候选，再交给 LLM 重排。之后从排名最高、尚未扩展的文档出发，访问它的邻居，将新文档加入候选并重新排序。

图里的问题以吉他振幅为背景，实际需要求一个极限。初始候选 D1 介绍正弦函数，C1 介绍简谐运动和振幅，都与题面相近。需要的 D3 是洛必达法则，却不在这批候选中，单靠重排无法找到。

右侧的重排器认为 C1 没有提供所需的数学关系，优先沿 D1 的邻居找到 D2。D2 与题面的词语重合不多，却包含有用的求解方法，于是再从它的邻居中找到 D3。

这条路径是搜索过程中逐步选出来的。图中的边只表示向量相近，不保证邻居对解题有用，所以每次加入新文档后还需要重新判断相关性。向量在这里承担了不同的工作：即使查询与目标文档不够接近，文档之间的近邻关系仍可能提供一条通路，由重排器判断往哪里走。

RGS 将“扩展邻居、加入候选、重新排序”反复执行，达到访问的不同文档数上限后返回当前最佳结果。实验用 BGE-Large 编码查询与文档，用 Gemini-2.0-Flash 重排。与先取定候选再重排相比，BRIGHT 上的 nDCG@10 如下。

这里限制的是接触多少篇不同文档，同一篇仍可能被重复重排，所以不是等 token 或等延迟比较。平均分有所提高，但 LeetCode 代码题子集存在退步。在 Biology 生物学子集上，也有正例已经被访问、最终却没被选中的情况。

层次索引搜索

LATTICE 用目录树组织语料，搜索时先选可能相关的文档组，再逐步找到具体文档。树的根节点代表全库，中间节点代表不同文档组，叶节点是原始文档。它与 RGS 的区别在于，模型可以先读一组文档的描述，决定要不要进入这个分支，而不必从某篇文档的近邻开始。

目录是在查询到来之前建好的。模型先为每篇文档生成从粗到细的多级摘要，再根据摘要分组。接近根部时使用简短主题，在较小的组里使用更具体的摘要，继续细分。这样，负责分组的 LLM 每次只需要处理合适粒度的描述，不必一次读完全部原文。大语料也可以先用向量聚类形成粗分组，再交给 LLM 处理。

图从左到右展示三轮搜索。第一轮比较根节点下面的几个目录，第二轮展开两个高分分支，第三轮到达部分文档。深绿色节点表示本轮优先展开的候选，黄色圈标出目标文档。

系统用一个待展开队列保留各条分支，每轮取出优先级较高的分支，将其子节点描述交给 LLM 评分。新的文档组回到队列，与其他分支一起等待选择，不必沿一条路径走到底。到达文档时，就将它加入结果集合。预设轮数结束后，从中返回排名靠前的文档。

队列里的分数来自不同批次，未必能直接比较。同一份材料，和较弱候选放在一起时可能得高分，和较强候选一起出现时又可能得低分，这会影响下一轮的分支选择。

LATTICE 会在不同批次中放入重复的参照节点。图里的虚线圆圈就是这些参照，跨分支箭头表示把已评分的节点放进另一批比较。系统利用共同参照和历次评分，估计每批整体偏高或偏低了多少，再校准节点分数。

节点的搜索优先级由路径分数决定：当前节点的校准分数与父节点的路径分数加权。这样计算时，上层目录得到的评分也会影响其下文档的搜索顺序。

目录描述也可能过时。LATTICE 的一些评测任务会按查询排除文档，但建目录时这些文档还在语料里。摘要中描述的材料后来不能访问，模型便可能沿着过时的描述进入没有可用证据的分支。

在四个 BRIGHT 子集上，LATTICE 还与强检索器加滑窗重排作了比较。滑窗重排每次读取一组候选，相邻组有重叠，逐步调整整个列表。两种方法使用同一 LLM 和评分提示。在这些对照中，低 token 预算时先召回再重排更好，预算增加后，目录搜索才逐渐体现继续探索的收益。

小结

ReasonIR 尝试让向量直接表示适用关系，SPIKE 和 DIVER-QExpand 把匹配所需的信息补进文本，RGS 则保留向量近邻，用更细致的相关性判断引导访问。相似度仍然有用，只是不必独自完成从理解问题到找到证据的全部工作。

RGS 的对照尤其能说明这个区别。编码器和重排器都没换，改变候选的获取方式，就提高了这组实验的平均分。相同的判断能力用在不同候选上，得到的检索结果也会不同。Biology 子集中已经访问正例却没选中的情况，又说明搜索覆盖改善后，相关性判断仍可能成为限制。

沿着这个分工，后续可以研究怎样按检索中的实际需要分配计算。已经找到足够证据的查询，未必还需要更多搜索。只找到同主题材料的查询，则可能值得继续改写或探索。困难在于，系统得判断当前证据是否足够，以及继续搜索可能补上什么。RGS 的不同文档数预算和 LATTICE 的固定搜索轮数，都还没有直接回答这一问题。

参考资料

海水示例与首图来自 A Survey of Reasoning-Intensive Retrieval: Progress and Challenges。方法与实验对照以下原始论文，链接对应本文使用的版本。

问题与评测： BRIGHT 。

训练与索引： ReasonIR 、 SPIKE 。

查询扩展与搜索： DIVER 、 Reranker-Guided Search 、 LATTICE 。

其余配图依次来自 ReasonIR 的训练数据图、SPIKE 的场景示例、RGS 的定理搜索示例和 LATTICE 的在线树搜索图。