在检索增强生成 (RAG) 系统中，当初始检索步骤返回的段落数量众多、噪声大或与查询意图不够一致时，你可能会选择使用高级的重排序模型。重排序通过使用比初始检索器更复杂的模型，重新排序或过滤段落来提高相关性。例如，如果你的第一阶段检索器（如 BM25 或轻量级嵌入模型）提取了 100 个文档，则重排序器可以根据语义相似性、交叉注意力或特定领域的标准，优先选择前 5 个。当初始检索缺乏精确性时，这尤其有用——例如，当查询含糊不清、依赖细微的上下文或需要领域专业知识（例如，法律或医疗应用程序）时。重排序弥合了快速但浅层的检索与 LLM 对高质量输入的需求之间的差距。
权衡在于增加的延迟和系统复杂性。重排序增加了计算开销，因为它通过一个单独的模型处理每个检索到的段落——比如交叉编码器或微调过的 transformer——这比简单的相似性评分要慢。例如，使用 BERT 风格的模型对 100 个段落进行重排序可能需要几秒钟，这对于实时应用程序来说可能是不可接受的。复杂性也在增加：你现在要管理两个模型（检索器和重排序器）、它们的兼容性（例如，输入格式）以及可能用于并行化或缓存结果的基础设施。此外，重排序模型通常需要更多的内存和 GPU 资源，从而增加了部署成本。这些权衡迫使人们做出平衡：重排序提高了答案质量，但在低延迟场景（例如，聊天机器人）或初始检索已经足够准确时，可能不值得付出成本。
考虑一个客户支持 RAG 系统，用户可以在其中提出技术问题。基于初始关键词的检索器可能会提取包含匹配术语的手册，但会遗漏上下文（例如，“更新后出现 error 500” 与一般的 “error 500” 文档）。在支持工单上训练的重排序器可以优先处理提及最新软件版本的段落。相反，在吞吐量高的搜索引擎中，添加重排序可能会将响应时间从 200 毫秒减慢到 2 秒，从而降低用户体验。开发人员必须评估准确性的提高（例如，错误答案减少 20%）是否证明了成本的合理性。像 sentence-transformers 或 Cohere 的重排序器这样的工具提供了即插即用的选项，但自定义模型可能需要在领域数据上进行微调。最终，重排序是一种用于对精度要求高的用例的工具，在这些用例中，延迟和复杂性是可以接受的权衡。
