图中先从大范围语料找候选，再对问题与候选逐对评分，重排不会凭空补出遗漏资料。
搜索结果主题都对，却把真正能回答问题的段落排在后面，这时可以考虑 Rerank。但它不是一个放在检索后面就能自动修复所有错误的按钮。理解它，先要区分两个任务：从大量文档中找出候选，以及在已有候选里做更细的比较。
召回和重排处理的规模不同
假设语料有很多段落，先用适合大规模查找的方式取出一小批候选。后面只对这批候选重新评分，把更能支持问题的内容提前。整个流程是一种分阶段分配计算预算的设计，不要求每次都采用同一种召回器。
双编码器常把问题和文档分别编码，文档向量可以预先计算并建立索引。查询时比较这些表示，便于从大范围中快速搜索。它将两边独立压缩成向量，细粒度的词与词关系不一定都能保留下来。
交叉编码器则把问题与文档一起输入，让它们在模型内部发生交互，再产生相应的相关性分数。这种计算通常要为每个问题与候选对执行，不能直接复用一个与问题无关的文档评分结果。
更细的比较，不等于通用真值
例如问题问“不允许停机时怎样迁移”，两个段落都谈迁移，其中一个要求停机，另一个讨论在线切换。只看主题，两者都像相关资料；更细的重排希望识别条件上的区别，把真正满足问题的段落提前。
但模型输出的高分仍是相关性判断，不是事实正确或操作可行性的证明。它也可能忽略否定、混淆版本或受训练分布影响。分数是否经过概率校准，还取决于模型和训练目标，不能看到零到一之间的输出就当成准确置信度。
有些系统还会使用其他重排方式，例如根据规则、多个特征或生成式模型评分。面试里讲清双编码与交叉编码的常见组合即可，不要把 Rerank 定义成某一个模型架构的专属名称。
候选集决定了能找回什么
如果正确证据根本没有进入候选列表，再强的重排器也无法对它评分。它能改变已有项的先后，不能从空白处凭空取回一份文档。因此“召回漏了”和“排得不好”应分开定位。
可以先人工确认候选里是否存在足够证据，再观察相关项是否被排到前面。如果候选缺失，应检查查询、索引或过滤条件；如果候选齐备但排序不对，再分析重排输入、长度截断和模型适配。这比把候选数量无限调大更有方向。
同一候选里还可能存在重复段落、过期版本和无权限内容。权限与数据有效性应在相应读取边界保证，不能寄希望于重排器主动打低分就解决访问控制。业务过滤与相关性排序承担不同责任。
长度和开销也是输入条件
问题与候选联合输入后，需要受模型长度限制。若直接截断，决定答案的句子可能恰好被删掉；长文档也可能因为背景很多而稀释关键内容。切块、保留标题和定位原文，都应围绕实际证据位置设计。
候选数量增加，通常会增加需要处理的对数，实际耗时还受批处理、长度分布和设备影响。不能从一个固定数字断言所有重排请求都能在相同时限内完成。先设候选预算，再测目标输入分布，比凭经验写死一个所谓最佳值可靠。
用分阶段指标核对收益
可以记录候选中是否有答案证据、重排后证据是否进入下游允许的前几项，以及最终回答是否正确使用材料。三个层次分别对应覆盖、排序和使用，不该只用最终回答的一次偶然表现判断整个系统。
训练和评测数据还要与真实任务匹配。通用问答上表现不错，不保证对内部编号、专业术语或特定语言同样有效。评价收益应与增加的计算和等待一起看，而不是只看一份更顺眼的结果列表。
这道题可以回答成“先广搜，再细比，同时守住候选上限和证据边界”。如果正确材料原本排在语料的很后面，甚至没进入首轮候选，你会优先换重排模型，还是先检查召回链路？