重排序Rerank配置怎么调，检索结果才真正按相关性排序
很多检索系统加了向量召回之后，前几条结果仍然不相关，问题往往出在缺少重排序这一步。
Rerank 配置要解决的核心只有一件事：把召回阶段拿到的候选文档，按与查询的真实相关性重新打分排序，再截取前 N 条交给下游。
配置得当，效果提升立竿见影；
配置不当，只会白白增加延迟。
先弄清 Rerank 在链路中的位置
召回和重排序是两件事。
向量检索或关键词检索负责从海量文档里快速筛出一批候选，追求的是快和全；
重排序模型（常见的是 Cross-Encoder 结构）把查询和每篇文档拼成一对输入，逐对打分，追求的是准。
因此配置前要确认三点：
- 你的检索链路里已经有召回步骤，能拿到一批带文本内容的候选文档；
- 候选文档保留了原始文本，而不只是向量 ID，否则重排序模型无法逐对打分；
- 下游只消费前几条结果，所以需要一个明确的截断数量。
如果候选文档只有 ID、没有正文，重排序会直接失败或拿到空分数，这是最常见的配置前提错误。
关键参数怎么定
不同框架的参数名不一样，但需要调整的就那几个。
以常见的 LangChain 风格接口为例：
from langchain.retrievers import ContextualCompressionRetriever
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder
encoder = HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-base")
compressor = CrossEncoderReranker(model=encoder, top_n=5)
retriever = ContextualCompressionRetriever(
base_compressor=compressor,
base_retriever=vector_retriever,
)对应到参数含义：
- 候选召回数：由底层向量检索器的
k或search_kwargs控制，建议先设为 20 到 50。太小会漏掉正确文档，太大则重排序耗时线性上升。 - 重排序模型：中小规模场景可先用 base 级别的中文或中英双语重排序模型；文档以英文为主时选英文效果更好的模型。模型名必须与本地缓存或下载源一致。
- top_n：重排序后保留的条数，通常与下游提示词能容纳的上下文长度匹配，常见是 3 到 8。
- 批量大小：部分实现支持
batch_size，显存或内存紧张时调小，能避免单次打分过多文档导致 OOM。
一个实用原则是：先让召回数明显大于 top_n，再让重排序做减法。
如果召回数本身就等于 top_n，重排序几乎失去意义。
从改配置到验证效果的完整流程
第一步，固定一组测试问题，并准备每个问题对应的正确文档。
没有标注数据时，至少人工准备 5 到 10 个问题和期望命中的文档片段。
第二步，先关闭重排序，记录每个问题的前 5 条结果，作为基线。
第三步，开启重排序，保持召回数不变，只截取 top_n 条，再对比结果顺序。
重点关注两件事：正确文档是否进入前 3，以及原本排在前面的无关文档是否被压下去。
第四步，逐步调整召回数，从 20 调到 50，观察正确文档命中率是否继续上升、耗时是否可接受。
第五步，记录每次配置下的延迟。
重排序是逐对推理，文档数翻倍，耗时通常也会明显增加。
如果接口有超时限制，优先降低召回数或减小 top_n，而不是盲目换更大的模型。
验证时不要只看“结果变了没有”，要看“正确文档是否更靠前”。
顺序变化不等于效果变好。
容易踩的几个坑
- 候选文档没有文本：只传了向量或 ID，重排序拿不到内容，直接报错或打分为空。检查召回结果是否包含
page_content之类的正文字段。 - 模型与语言不匹配：用英文重排序模型处理中文查询，分数区分度会变差，排序看起来“随机”。
- top_n 设得比召回数还大：实际不会报错，但等于没有截断，下游可能收到超长上下文。
- 忽略延迟：重排序是同步推理，在请求链路里串行执行，QPS 高时容易成为瓶颈。可以考虑缓存查询结果或异步预计算。
- 把重排序当成召回用：重排序不负责从全库里找文档，只负责给已有候选排序。候选集本身没包含正确文档时，重排序无能为力。
什么情况下值得加 Rerank
候选文档数量不大、相关性要求不高、延迟预算很紧时，可以不加。
当出现“召回里明明有正确文档，但排在第 8 条之后”“相似度分数接近、顺序不稳定”“下游回答经常引用无关段落”这些现象时，重排序通常能带来直接改善。
配置完成后，建议把召回数、top_n、模型名和实测延迟记录下来，后续换模型或扩文档时才有对比依据。
重排序 Rerank 配置不是一次性动作，而是一组需要随数据和延迟预算一起复查的参数。
常见疑问
重排序模型必须和嵌入模型配套吗？ 不需要。
嵌入模型负责召回，重排序模型独立打分，两者可以来自不同厂商，只要输入输出格式对得上即可。
召回数量设多少合适？ 没有统一值。
先取 20 到 50 做对比测试，以正确文档进入前 3 的比例和接口延迟共同决定，不要只追求命中率而忽略响应时间。
没有 GPU 能跑重排序吗？ 小参数模型可以在 CPU 上运行，但延迟会明显升高，适合离线批处理或低并发场景；
在线高并发建议评估推理服务或更小的模型。
