在 RAG 系统中，检索阶段通常返回多个候选片段（例如 top‑k 取 20 条），但这些片段的准确排序直接影响最终答案的质量。向量检索基于语义相似度打分，受嵌入模型能力、切分粒度等因素影响，相似度最高的片段不一定是回答问题最需要的那一个。重排序（Rerank）就是在初步检索结果基础上，用更精细的模型再次打分，重新排列片段顺序，让真正最有价值的内容排在前面，送入生成环节。
8.5.1 为什么仅靠向量检索不够
向量检索速度快、适合大规模数据，但其打分方式存在明显局限：
- 语义近似不等于回答所需：问题“如何申请退款”和片段“退款申请流程”在语义上高度相似，但另一个片段“退款申请需提供订单截图”虽然语义得分稍低，却对生成答案更关键。
- 长文本中的关键信息容易被稀释：一个很长的 chunk 即便整体相似度高，真正有用的句子可能只占一小部分，而较短的 chunk 反而更精准。
- 跨领域匹配不精准：通用嵌入模型在处理细粒度专业术语时，可能出现语义相近但无关的误召回。
重排序可以看作是在检索粗排基础上的精排，用更强的相关性判断模型，从候选池里挑出“最值得模型阅读”的片段。
8.5.2 重排序的常见方法
目前工业界常用的重排序方案主要有三类：
1. 交叉编码器模型
使用专门的交叉编码器（cross‑encoder）直接计算查询和每个候选片段的匹配分数。与双塔模型（分别对查询和文档编码再计算内积）不同，交叉编码器将查询和文档拼接后统一送入 Transformer，进行深度交互，能捕捉更细粒度的语义匹配关系。
- 优势：准确性明显优于双塔模型，能发现词序、指代、否定等细节。
- 成本：需要逐对计算，速度较慢，通常只对 top‑k（如 20~50 条）候选做重排序，而非全库检索。
常用的开源交叉编码器模型有 BAAI/bge-reranker 系列、Cohere rerank 等，可直接接入 RAG 流水线。
2. 基于大语言模型的重排序
随着 LLM 能力的增强，也可以直接让大模型来“挑选”最相关的片段。将候选片段连同问题一并送入 LLM，要求模型输出相关性排序或选取最相关的几段。这种方法的优势在于能理解复杂意图，甚至可以进行跨片段对比；但缺点是成本高、延迟大，且输出格式需要严格控制。实际应用中通常只在候选片段数量很少（如 5 条以内）或对质量要求极高的场景下使用。
3. 特征融合排序
除了模型分数，还可以结合其他特征进行加权排序，例如：
- 关键词匹配度：BM25 等词汇级别分数，能弥补语义检索对精确词匹配的忽视。
- 来源权重：正式文档、权威资料给予更高权重，避免无关草稿或过时信息排在前面。
- 时效性：对更新的文档赋予时间衰减权重，保证新信息优先。
通过简单的加权公式或使用一个轻量级线性模型即可实现特征融合，工程上更容易控制。
8.5.3 重排序在 RAG 流程中的位置
典型的流水线为：
- 向量数据库粗召回 → 前 N 个候选（如 N=50）
- 重排序模型精排 → 取前 M 个高质量片段（如 M=5）
- 最终这 M 个片段与问题一起送入大模型生成答案
这样既平衡了检索速度和排序精度，也控制了给大模型的上下文长度，避免无关内容占用 token 窗口。
8.5.4 实际应用建议
- 选择合适的 N 和 M：粗召回 N 建议 20~50，太小可能漏掉关键信息，太大则重排序开销增加。最终保留 M 建议 3~8 条，保证上下文精炼。
- 在可接受延迟内使用交叉编码器：对于在线问答，重排序需在几十毫秒内完成，通常建议使用轻量化 reranker 模型或利用 GPU 加速。如果对实时性要求极高，可考虑离线缓存常见问题的重排序结果。
- 与检索策略联动优化：如果向量检索的 chunk 大小不一致，重排序可能对长片段有偏好，因此最好先统一切片粒度或对分数做长度惩罚。
- 定期评测排序效果：建立标注数据集，对比使用重排序前后的命中率（Hit Rate）和答案准确率变化，确保重排序真正带来增益而非单纯增加系统复杂度。
重排序虽然引入额外计算，但它往往是提升 RAG 系统最终回答质量最有效的单步优化之一。许多实际部署中，加入交叉编码器重排序后，答案的事实准确率能提升 10%~25%，尤其是在多文档、复杂问题的场景下效果尤为明显。