RAG 项目里，很多人把注意力放在召回 topK 上：多召回一点，总能把答案需要的资料放进去。但模型上下文不是垃圾桶。召回很多资料，不代表模型会用对；无关资料越多，反而越容易干扰生成。
重排的价值，就是在初步召回之后，把更可能回答问题的片段排到前面，把噪声片段压下去。它不是锦上添花，在很多知识库问答场景里，它直接决定答案是否抓住关键证据。
第一阶段召回追求别漏
向量召回、关键词召回、混合召回的目标，是尽量不要漏掉可能相关的资料。这个阶段可以相对宽一些，因为漏掉正确资料后，后面再强的模型也无法基于证据回答。
但召回阶段宽，会带来噪声。用户问某个功能的限制条件，系统可能召回功能介绍、使用教程、历史公告、FAQ 和无关案例。它们都含有相似词，但真正能回答限制条件的可能只有一两段。
重排追求把证据放前面
重排模型会重新判断问题和候选片段的匹配程度。相比单纯向量相似，它更关注片段是否能回答当前问题。好的重排能把关键证据放到前几位，让后续生成更稳定。
不过重排不是免费。候选片段越多，重排耗时越高；使用更强的重排模型，成本也会上升。低风险、简单 FAQ 可能不需要复杂重排；企业知识库、长文档、多条件问题则更值得引入。
上下文长度不是越长越好
有些系统为了稳妥，把召回结果全部塞给模型。这样会增加延迟和成本，也会让模型在无关资料里迷失。更好的做法是根据重排结果选择少量高质量片段，并保留标题、层级、时间和来源等必要元信息。
如果资料之间冲突，还要有版本和权威性判断。不是排第一就一定正确，可能它是旧版本文档。重排要和文档元数据、权限过滤、版本管理一起工作。
面试里可以讲评估闭环
评价重排效果，可以看正确证据是否进入前几位，答案是否引用了正确片段，坏例是否减少，延迟是否可接受。不要只说“加 rerank 后效果更好”，要说明用什么问题集比较，指标怎么变，成本是否增加。
一个成熟表达是：我会把 RAG 分成召回和重排两阶段。召回阶段保证候选不漏，重排阶段把可回答问题的证据放前面；同时控制候选数量、上下文长度和延迟。这样模型生成时看到的是更干净的证据，而不是一堆看似相关的噪声。
重排还有一个容易忽略的边界：它只能在候选里重新排序，不能凭空找回没召回到的资料。如果第一阶段召回漏掉了正确文档，重排模型再强也没用。因此调优时要先看正确证据有没有进入候选，再看它排在第几位。
面试里可以把排查顺序讲清：先查召回覆盖，再查重排顺序，最后查生成是否遵守证据。这样能避免把所有 RAG 坏例都归因于模型生成。
如果候选片段很长，还可以先做粗粒度召回，再对段落级片段重排。这样既能保留文档上下文，又能把真正回答问题的段落挑出来。重排不是单点算法优化，它要和切分、候选数量、上下文预算一起设计。