先设一个教学场景。
用户问的是某项规则“哪些情况不适用”。粗召回带回了两段内容。
一段是真正的例外条款，另一段是字面上很像、却只介绍正常适用范围的正文。
正确证据已经进了候选集，只是排在后面。如果系统直接截取最前面的内容交给模型，最后答案仍可能跑偏。
这时适合处理问题的是 Rerank，也就是重排。
可另一个问题马上来了：既然 Rerank 能更细地比较问题与候选，为什么不跳过向量检索，直接让它给整个知识库打分？
Bi-Encoder 和 Cross-Encoder 差在哪里？
Embedding 模型通常采用双塔，也叫 Bi-Encoder。
Query 进入一侧编码器，文档进入另一侧编码器，最后比较两个向量的距离。文档向量可以在离线阶段提前算好，用户提问时只需要计算 Query 向量，再到索引中寻找近邻。
这种方式适合从大量语料里快速找出“可能相关”的内容。
它的限制也来自独立编码。
模型生成文档向量时并不知道未来用户会问什么。Query 和文档直到最后计算相似度时才相遇，细粒度条件、否定、时效词和上下文关系不一定能充分参与判断。
Cross-Encoder 的做法不同。
它把 Query 与某一条候选组成一对，一起输入模型，再输出这对内容的相关性分数。两边在编码过程中可以直接交互，更有机会区分“包含相同词”和“真正回答这个问题”。
代价也很直接。
Bi-Encoder 的文档向量可以复用，Cross-Encoder 则要针对当前 Query，把每条候选重新读一遍。Query 变化后，上一轮的成对分数通常不能直接复用。
Bi-Encoder 用独立向量快速找候选，Cross-Encoder 让问题和候选共同参与计算，适合在小集合里精细排序。
因此，“Rerank 更准”不是说它能替代所有检索，而是说在候选集合已经形成时，它通常能做更细的相关性比较。
为什么不能直接对全库 Rerank？
假设知识库里有大量 Chunk。
如果直接用 Cross-Encoder 扫全库，每次提问都要把同一个 Query 分别与每条 Chunk 组成输入，再逐对推理。语料越多，成对计算越多。
更关键的是，它无法像向量索引那样提前把文档变成可快速搜索的固定表示。
这会让一次在线查询的成本随候选规模明显增长，也失去了近似最近邻索引快速缩小范围的意义。
合理的链路更像漏斗。
第一层先根据知识库、文档状态和权限限定搜索范围。
第二层用 BM25、向量或混合检索快速取得一批候选。
第三层对候选执行 Rerank，重新计算相关性顺序。
第四层根据分数、来源和上下文预算截取最终证据。
快速召回负责缩小范围，Rerank 只处理候选，最终再按上下文预算截断。各层解决的问题不同。
这条链路里，Rerank 不负责凭空找回候选集之外的文档。
如果正确证据没有进入粗召回 Top-N，Cross-Encoder 根本看不到它。无论模型多大、打分多细，都不能把不存在的候选重新创造出来。
所以排查时必须先问：正确证据在不在 Top-N？
不在，先查解析、切分、过滤、Query、Embedding 和召回策略。
已经在，但排得太后，再查 Rerank 是否能把它提上来。
Top-N 和 Top-K 应该怎样定？
Top-N 是交给 Rerank 的候选数量，Top-K 是最终保留给模型的证据数量。
Top-N 太小，粗召回稍有排序误差，正确证据就可能被挡在门外。Rerank 再准也没有处理机会。
Top-N 太大，正确证据覆盖可能增加，但成对推理、排队时间和无关候选也一起增加。
选择 Top-N 时，可以同时观察两条线。
一条是粗召回的 Recall@N。它回答在前 N 条候选中，应该找回的证据出现了多少。
另一条是重排成本，包括成对数量、批量推理耗时、队列等待和资源占用。
当继续增加 N 已经很少补回新证据，却持续增加推理成本时，扩大的价值就开始下降。
选择 N 不能只跑一次平均值。可以按问题类型画出 Recall@N 曲线：精确标题题可能很早饱和，口语改写、否定和多证据问题可能需要更宽候选。再把每个 N 对应的候选 Token、成对推理次数和延迟分布放在一起，才能看出“新增一批候选究竟补回了什么”。没有新增证据的候选只是成本，不应因为上下文还放得下就保留。
还要避免数据泄漏。若用同一批问题反复调 Top-N、阈值和路由，再用它们宣布方案有效，结果会过度适配。至少保留一组未参与调参的问题做最终回放，并按业务重要性固定评价规则。这里不需要给出一个通用 N，只需要证明选择过程能够复现。
Top-K 也不能只按模型上下文长度设置。
保留太少，可能丢掉多段互补证据；保留太多，相邻重复、冲突版本和弱相关内容会一起进入 Prompt。最终要结合问题需要几段证据、Chunk 长度、冗余和生成预算决定。
不同 Query 也未必需要相同候选量。
精确编号、明确标题已经由关键词路线高置信命中时，可以减少复杂处理。表达模糊、需要多段证据或候选高度相似时，才可能需要更宽的候选和精排。
这是一种按问题风险分配计算的思路，不是给每次请求固定堆满组件。
Rerank 模型应该怎么选？
本题只保留和“成本”直接相关的判断：在固定粗召回候选上比较排序质量、候选截断、批量吞吐和尾延迟。Embedding 与 Rerank 的完整候选筛选、榜单边界、部署约束和迁移流程，单独放在 模型选型题 中展开。
Embedding 先看召回覆盖和索引成本，Rerank 再看排序质量与成对推理成本。榜单只能缩小候选范围。
这张图在本题里的用途，是提醒你把“排序收益”和“成对推理成本”放在同一张表里，避免只谈准确率。
Rerank 实际应该读到哪些内容？
Rerank 的输入通常不应只有一段被拍平的正文。
候选的标题路径、表头、内容类型和版本信息，可能正是判断相关性的关键。如果用户问某个流程的当前规则，而候选只保留正文，没有标题与版本，Cross-Encoder 也无法利用已经丢失的信息。
但这不代表把所有元数据都拼进输入。
无关字段会占用输入长度，重复标题还可能让很多候选变得更相似。应该选择真正帮助判断问题与候选关系的字段，并在评测中固定输入模板。
输入长度尤其需要检查。
Query 与候选拼接后超过模型上限时，部分内容会被截断。如果正确答案恰好位于候选尾部，表面上看是 Rerank 排错，实际是模型从未看到关键句。
调试时要保存截断前长度、最终输入和截断策略。可以调整 Chunk 边界、保留标题和关键区域，或选择支持合适输入长度的模型，但每种改动都要重新评测排序与成本。
Rerank 分数也不宜跨模型直接比较。
不同模型的分数范围和校准方式可能不同，同一阈值从一个模型搬到另一个模型，并不代表相同相关性。更稳妥的是先用名次指标比较，再在固定模型和数据上选择过滤阈值。
相同分数或非常接近时，还要定义稳定的次级排序规则，例如沿用粗召回名次或固定 Chunk ID。否则同一 Query 翻页时，候选顺序可能因为非稳定排序发生跳动。
输入模板、截断、阈值和稳定排序都属于 Rerank 配置。只记录模型名称，不足以复现一次排序结果。
什么时候值得做领域微调？
微调不是解决 Rerank 延迟的办法。只有通用模型在一类专业术语、否定或内部缩写问题上持续排错，并且已有真实难负样本和独立测试集时，才值得进入微调评估；完整训练与验收条件同样放在模型选型题中。本题继续回答的是：已经决定使用 Rerank 后，怎样把在线成本控制在预算内。
Rerank 太慢，可以从哪里优化？
第一种办法是减少无效候选。
先用知识库、权限、版本和文档类型过滤，再让召回缩小范围。不要把本来就没有资格参与搜索的内容交给 Rerank。
第二种办法是批量推理。
同一个 Query 与多条候选可以组成一个批次，减少逐条调用的调度开销，提高设备利用率。但批量提高的是吞吐，不代表每个请求的等待一定更短。批次需要等待凑齐时，单请求延迟还可能增加。
第三种办法是选择更小的模型或量化。
这样可能降低资源与推理成本，但必须用同一评测集确认排序质量没有不可接受的退化。
第四种办法是按 Query 路由。
高置信精确命中可以跳过高成本精排，候选相似、含否定或需要严格排序的问题再启用。路由本身也要记录和评测，不能因为省计算而漏掉难题。
第五种办法是控制输入长度。
如果 Chunk 超过 Rerank 模型的最大输入，尾部可能被截断。此时盲目扩大候选或更换更大模型，不如先检查正确证据是否恰好在被截掉的位置，并调整 Chunk 或输入组织。
还可以把成本预算拆成可观测部分。一次请求的精排成本不只由候选数量决定，还受候选长度、批量大小、排队时间、模型推理和跨服务传输影响。下面的关系只用于帮助定位，不是性能承诺：
精排总耗时 = 候选准备 + 排队 + 批量推理 + 结果回传
成对输入量 = Query 与每条候选拼接后的 Token 总和
如果推理本身很短而排队很长，继续量化模型未必解决问题；如果大量候选在过滤前就没有访问资格，优化批处理也只是更快地处理无效数据。先把端到端时间拆开，再选择减少候选、缩短输入、调整批次或更换模型。
按 Query 路由时必须保留安全出口。被判断为“高置信可跳过”的请求，应记录触发条件和粗召回分数，并在离线回放中检查是否漏掉否定、时效或多证据问题。路由不确定时宁可回到标准精排链路，不能为了得到更低平均延迟，悄悄牺牲最难的一组问题。
四种排序异常，先判断“没召回”还是“排错了”
这四种异常要先按候选覆盖、输入截断、排序误判和请求预算分层，否则很容易把粗召回问题错误归因给精排模型。
正确证据没进入 Top-N
这是召回覆盖问题，不是 Rerank 失败。
先检查文档是否入库、过滤范围是否正确、Query 是否被改写带偏、关键词和向量路线是否找到正确内容。
正确证据进入候选，却排在后面
这是 Rerank 应该处理的典型问题。
保存重排前后列表，查看正确证据名次是否上升，同时检查前面的错误候选为什么看起来相关。
重排后正确证据反而下降
检查模型语种、候选文本长度、截断位置以及训练数据。Rerank 不是天然只会变好，更强模型也可能不适合当前文档。
翻页后结果重复或跳动
如果只对部分候选或前几页执行精排，不同页面可能使用不同排序口径。
需要明确精排范围、稳定排序字段和分页策略，不能把产品取舍包装成统一行业方案。
怎么证明 Rerank 值得保留？
先固定一批问题、参考答案和正确证据。
对每个问题保存粗召回 Top-N 与重排后列表，比较正确证据是否存在、第一条正确证据排在哪里、前 K 条的相关性与冗余。
召回层看 Recall@N，确认正确证据有没有资格进入精排。
排序层看 MRR、NDCG 或 Precision@K，确认正确证据是否更靠前。
工程层记录候选数量、批量大小、模型版本、输入截断、推理耗时、队列等待和资源峰值。
还要按问题类型拆结果。
专业术语、否定、时效条件、短 Query 和多证据问题可能表现不同。平均分上升，不代表最重要的失败类型都被修好。
先确认候选覆盖，再比较排序变化，最后核对新增延迟和资源。只有排序收益能覆盖成本，Rerank 才值得保留。
不要只展示一条重排成功的案例。
一条案例能解释机制，不能证明稳定收益。也不要只报延迟下降，排序质量可能同时退化。效果与成本必须在同一批问题上一起看。
评测记录最好保留问题类型，而不是只看总分。
每条样本可以标记为精确标题、口语改写、否定、时效条件、专业术语或多证据问题。这样模型更换后，团队能看到它究竟修好了哪类排序，又让哪类问题退步。
还要保存重排前后前几条候选原文。分数变化能告诉你排序变了，原文对照才能解释为什么变。若错误候选长期都是“主题相关但不回答”，它们也可以成为后续模型选型或微调的难负样本。
比较延迟时也要拆开测量。
模型实际推理、候选准备、跨进程调用和队列等待不是同一段时间。只看端到端耗时，无法判断瓶颈来自模型太大，还是服务批处理与排队策略不合理。
同时记录单请求和并发情况下的分布，而不是只报平均值。平均值可能看起来稳定，少数复杂 Query 却因为候选更多、文本更长而等待很久。是否启用 Rerank，最终要服从当前产品的响应预算与问题风险。
模型升级后，同一 Query 的分数范围和排序都可能改变。应先在固定候选集上回放，确认关键问题没有退化，再逐步切换。没有回放记录，直接替换模型会把选型问题变成新的不可复现变量。
固定候选集非常关键。评测 Rerank 时先冻结粗召回结果，才能判断名次变化来自精排模型；评测整条检索链时再允许召回一起变化。若候选和模型同时改变，正确证据从 Top-N 消失后，很容易被误判为新 Rerank 排序失败。
对每个失败样本，至少保存 Query、候选原文、重排前名次、重排后名次、输入是否截断和模型版本。复盘时先判断正确证据是否可见，再比较错误候选为什么得分更高。常见原因可能是标题重复、否定被忽略、版本信息未进入输入，或正确句落在截断区域。只有把原因落到具体候选，优化才不会变成盲目换模型。
上线切换也应支持回退。新旧模型在同一候选上并行打分一段时间，先只记录差异，不立即影响用户；确认关键问题和尾延迟满足预算后再逐步放量。若无法同时运行，也至少保留离线回放产物与旧配置，使回退能够恢复同一输入模板、阈值和稳定排序规则。
成本结论最终应落到具体请求预算。先明确检索链为生成、网络和其他步骤预留多少时间，再决定 Rerank 能使用的候选量和推理预算；不能先选一个模型，再要求所有请求迁就它。若某些问题确实需要更多证据，可以按风险单独放宽，而不是把最慢路径变成所有查询的默认路径。
同样，降低延迟不能只看平均值。应该分别报告候选短与长、并发低与高、是否触发重排等分组的中位数和尾部表现。这样才能识别是模型本身慢，还是少量超长候选或排队把尾延迟拉高。
Rerank 追问怎么接：候选、模型、成本分开说
后续问题始终沿着同一个顺序回答：正确证据是否进入候选，模型是否看见完整输入，排序收益是否值得新增的延迟与资源。
正确证据不在候选里，Rerank 能补救吗？
不能。它只能给已有候选重新打分。证据缺失要回到解析、切分、Query、过滤与粗召回层排查。
Top-N 为什么不能越大越好？
因为候选增加会提高覆盖机会，也会线性增加成对推理和队列压力。要同时看 Recall@N 是否仍在增长，以及新增成本是否值得。
批量推理为什么不一定降低单请求延迟？
批量通常提高设备吞吐，但请求可能等待其他样本组成批次。批次过大还会增加一次计算时间，所以要同时看吞吐、队列和尾延迟。
Embedding 与 Rerank 为什么不能只看同一个榜单？
Embedding 负责大规模召回，Rerank 负责候选排序，任务和资源约束不同。它们应在各自阶段用对应指标评测。
什么时候才考虑领域微调？
当专业术语、否定或内部缩写出现稳定可复现错误，并且已有真实正样本和难负样本时。微调后还要与未微调基线严格对照。
什么时候可以跳过 Rerank？
当检索已经提供高置信、低歧义的正确证据，且评测显示精排没有稳定增益时，可以考虑跳过。但决定要来自分类型评测，而不是感觉。
把 Rerank 的价值讲到可验收
口述时先把 Bi-Encoder 与 Cross-Encoder 的职责分开，再用候选覆盖、排序变化和尾延迟说明是否值得接入：
Rerank 常用 Cross-Encoder，把 Query 和每条候选一起编码，能捕捉否定、条件和候选细节之间的交互，因此排序更细。但它无法像 Bi-Encoder 那样提前保存文档向量，每条候选都要针对当前 Query 重新推理，因此不适合直接扫描全库。
工程上我会先用关键词或向量检索取 Top-N，再批量 Rerank 到较小 Top-K。Top-N 太小会把正确证据挡在精排外，太大又增加延迟和资源，所以要同时看 Recall@N、重排后的 MRR 或 NDCG、队列等待和资源占用。
模型选型时，Embedding 看召回覆盖和索引成本，Rerank 看排序质量、输入长度和批量推理。只有专业术语或否定问题出现稳定错误、并且有真实难负样本时，才考虑领域微调。验证时保存重排前后名次，分清召回缺失与排序错误，再决定 Rerank 的收益是否值得新增成本。
最后要能解释一条具体候选怎样从粗召回进入精排、名次为什么变化，以及这次变化付出了多少请求预算。面试时只使用本人实践中的候选规模、排序变化和资源记录；没有完成对照实验，就讲清验证方案，不使用未经验证的示例数据。