什么是 重排序（Reranking）？
重排序（Reranking）是在已召回候选集合上，把 Query 与每个候选共同评分，再按任务需要重新排列候选的第二阶段排序操作。它通常位于关键词、稠密或混合检索之后，因为成对评分的成本高于独立建立文档索引。
快速了解
| 全称 | 信息检索与 RAG 中的重排序 |
|---|---|
| 创建时间 | 随着 2023-2024 年 RAG 技术的工程化落地，Rerank 作为解决检索痛点的核心手段被广泛采用。 |
| 规范文档 | 官方规范 |
工作原理
重排序只能改善已有候选集的顺序，不能生成召回阶段完全遗漏的内容，也不能证明片段已构成充分证据或当前用户有权访问它。Cross-Encoder 是常见的重排序器：它同时读取 Query 与候选内容，捕捉独立 Embedding 可能遗漏的交互信号，并返回模型特定的分数。Late Interaction、学习特征和任务规则也可用于重排序，因此不能只凭 Rerank 这个名称推断具体实现。
Cross-Encoder 分数是排序信号，不是可以跨模型复用的概率。有的模型输出 Logit，而不是 0 到 1 的数值；模型 Revision、语言、Query 形态、文档长度和候选来源都会改变分数分布。任何阈值、拒答或自动化动作都应使用目标负载的带标注样本校准，而不是复制厂商示例中的固定分数。
生产评测应固定语料、权限、查询、来源 Revision 和候选生成策略，再比较基线与重排序版本。先测重排前的 Candidate Recall@K，再测 nDCG、MRR、Precision@K、回答证据支持度、p50/p95 延迟、成本和失败切片。Retriever、Reranker、Prompt 或 Context Assembler、Policy 与评测集必须共同版本化，排序变化才可解释。
主要特点
- 第二阶段操作：重排已有候选集，而不是默认遍历整个语料库
- 常用 Cross-Encoder：联合处理 Query 与单个候选，但不生成可复用的文档 Embedding
- 受候选召回限制：未进入候选集的相关来源无法被提升
- 分数是模型和负载相关信号，必须在自动化阈值或决策前完成校准
- 延迟与成本受候选数量和输入长度影响，候选深度需要与质量一起评测
- 私有内容进入 Reranker 前仍需完成授权与来源生命周期过滤
常见用途
- 在 RAG 回答组装证据前，对混合或稠密检索候选重新排序
- 在关键词和语义候选生成后，为客服知识库排序文章
- 在已授权的小范围文档内选出与当前问题最相关的片段
- 使用离线相关性和回答证据评测对比不同检索版本
- 在租户、语言、时效和文档类型过滤后应用任务专用排序模型
示例
Loading code...常见问题
重排序与检索有什么区别？
检索从语料库生成候选集，通常依赖关键词、稠密或混合索引；重排序更细致地比较 Query 与每个候选，再改变其顺序。候选生成阶段排除的相关文档，重排序无法重新找回。
所有重排序器都是 Cross-Encoder 吗？
不是。Cross-Encoder 是常见的成对排序架构，Late Interaction、学习特征、规则和其他任务专用 Ranker 也可用于重排序。接口应记录实际模型与分数语义，不能假设所有 Reranker 行为相同。
可以使用固定的重排序分数阈值吗？
不能安全地跨模型或负载复用。部分模型输出 Logit，不同模型、语言、文档长度和候选来源也会改变分数分布。保留、拒绝或拒答阈值必须在目标模型 Revision 的带标注查询、Hard Negative 和文档类型上校准。
Reranker 应该处理多少候选？
没有通用 Top-K。先把候选深度增加到相关证据足以稳定进入 Reranker，再测排序增益是否值得 p95 延迟和成本。必须在相同过滤条件与语料上一起评估候选 Recall 和最终排名。
重排序能避免 RAG 幻觉吗？
不能。更好的排序可能改善模型看到的证据，但不能证明来源权威、内容充分、数据新鲜、访问已授权或结论被证据支持。还需要检索评测、证据充分性检查、引用校验和明确的无答案策略。