RAG 召回够多还是不准？问题多半出在重排这一层

几乎所有 RAG 系统上线后都会经历同一个阶段：召回率很漂亮，答出来的内容却总差点意思。

原因是检索质量不等于生成质量。向量检索本质是「语义相似」，而「语义相似」和「能回答问题」是两件事。

一、召回和重排解决的不是同一个问题

双塔向量模型的局限在结构上：文档和查询分别编码，两者之间没有交互。它能判断「这段话在说同一类事」，判断不了「这句话里有没有答案」。

Cross-encoder 把 query 和 document 拼在一起送进模型，逐 token 做注意力交互，精度高一个档次——代价是无法预建索引，必须实时计算。

所以标准架构是：向量召回 top 50100 → 重排 → 取 top 35 给大模型。

二、top-k 怎么定

两个数字要分开看：

• 召回 k：宁多勿少，50 起步。召回多只增加重排成本，不增加大模型成本。
• 入 prompt k：宁少勿多。3~5 条通常够用，超过 8 条反而因上下文稀释降低质量。

常见误区是只做召回不做重排，靠「多塞几条」弥补精度——这恰恰效果最差，大模型对无关内容的容忍度比人想象的低得多。

三、reranker 选型

类型	代表	适用
专用小模型	BGE-Reranker、Cohere Rerank	主流选择，延迟 50~200ms
多语言模型	BGE-M3 系	中英混排文档
LLM 重排	大模型打分或 listwise	高价值低频场景

LLM 重排性价比通常不高：50 条候选的 listwise 排序可能几万 token，还容易受位置偏差影响。除非单次查询价值极高，不推荐。

专用小模型在中文场景一定要用自己的语料实测，榜单分数经常和实际分布对不上。

四、两个容易忽略的细节

截断长度。 cross-encoder 常见最大输入 512 token。文档块若切成 1000 token，后半段根本不会被重排模型看到。要么把块切小，要么选支持长输入的模型。

分数校准。 重排分数是相对的，跨 query 不可比。想用它做「无答案过滤」（低于阈值就回复没找到），阈值必须在自己的数据上标定，别照抄别人的 0.5。

五、什么时候不需要重排

同时满足三条可以先不上：文档库很小（< 1 万条）且领域单一；查询与文档表述高度一致；延迟预算极紧（< 300ms）。

但只要出现「召回对了但答案不对」的反馈，重排就是第一优先级，比换更大模型划算得多。

一句话：召回决定上限，重排决定下限。多数 RAG 的效果问题，卡在下限。