文档API 参考📓 教程🧑‍🍳 食谱🤝 集成💜 Discord🎨 Studio
文档

选择合适的排序器

本页面提供了关于在 Haystack 中为您的 Pipeline 选择合适 Ranker 的指导。它解释了基于 API、本地部署的 Ranker 和启发式方法之间的区别，并根据延迟、隐私和多样性需求提供建议。

建议编辑

Haystack 中的 Ranker 会根据检索到的文档与用户查询的估算相关性来重新排序文档集。Ranker 在检索之后运行，旨在在将结果列表传递给下游组件（如 Generator 或 Reader）之前进行优化。

这种重新排序基于简单的向量相似性以外的附加信号。根据所使用的 Ranker，这些信号可以包括语义相似性（通过 cross-encoder）、结构化元数据（如时间戳或类别）或基于位置的启发式方法（例如，将相关内容放在开头和结尾）。

使用 Ranker 的典型问答 Pipeline 包括：

  1. 检索：使用 Retriever 查找候选文档集。
  2. 排序：使用 Ranker 组件重新排序这些文档。
  3. 回答：将重新排序后的文档传递给下游的 Generator 或 Reader。

本指南将帮助您根据用例选择合适的 Ranker，无论您是优化性能、成本、准确性还是结果的多样性。它侧重于在 Haystack 中选择不同类型的 Ranker，而不是具体的模型，而是最适合您设置的通用机制和接口。

基于 API 的 Ranker

这些 Ranker 使用外部 API，通过托管在远程的强大模型来重新排序文档。它们提供高质量的相关性评分，无需本地计算，但由于网络延迟可能较慢，并且在大规模使用时成本较高。

定价模型因提供商而异，有些按处理的 token 收费，有些则按使用时间或 API 调用次数计费。有关精确的成本结构，请参阅各自提供商的文档。

Haystack 中大多数基于 API 的 Ranker 目前依赖于 cross-encoder 模型（目前如此，但未来可能会改变），它们将查询和文档一起评估，以产生高度相关的评分。例如，包括 AmazonBedrockRanker、CohereRanker 和 JinaRanker。

相比之下，NvidiaRanker 使用大型语言模型 (LLMs) 进行排名。这些模型将相关性视为一个语义推理任务，这对于复杂或多步查询可以产生更好的结果，但通常计算成本更高。

本地部署 Ranker

这些 Ranker 完全在您的本地基础设施上运行。它们非常适合优先考虑数据隐私、成本控制或低延迟推理而无需依赖外部 API 的团队。由于模型在本地执行，因此避免了网络瓶颈和重复的使用成本，但需要足够的计算资源，特别是对于 cross-encoder 模型，通常需要 GPU 支持。

Haystack 中所有本地部署的 Ranker 都使用 cross-encoder 架构。这些模型共同处理查询和每个文档，以深入的上下文感知来评估相关性。例如：

  • SentenceTransformersSimilarityRanker 根据与查询的语义相似性对文档进行排名。除了默认的 PyTorch 后端（最适合 GPU）外，它还提供其他内存效率高的选项，适合纯 CPU 环境：ONNX 和 OpenVINO。
  • TransformersSimilarityRanker 是其旧版本，通常应避免使用，而应选择更新、更灵活的 SentenceTransformersSimilarityRanker。
  • HuggingFaceTEIRanker 基于 Text Embeddings Inference 项目：无论您是否有 GPU 资源，它都能为本地服务模型提供高性能。此外，您还可以使用此组件对托管在 Hugging Face Inference Endpoints 上的 reranking 模型进行推理。
  • FastembedRanker 支持各种 cross-encoder 模型，最适合纯 CPU 环境。
  • SentenceTransformersDiversityRanker 重新排序文档以最大化多样性，有助于减少冗余并涵盖更广泛的相关主题。

这些 Ranker 让您可以完全控制模型选择、优化和部署，非常适合具有严格 SLA 或合规性要求的生产环境。

基于规则的 Ranker

Haystack 中的基于规则的 Ranker 根据启发式逻辑而不是语义理解来优先排序或重新排序文档。它们基于文档元数据或简单的结构模式进行操作，计算效率高，并且对于强制执行特定领域规则或在检索 Pipeline 中构建输入很有用。虽然它们不直接评估语义相关性，但它们可以作为 cross-encoder 或基于 LLM 的 Ranker 等更高级方法的有价值的补充。

例如：

  • MetaFieldRanker 根据元数据值（如时效性、来源可靠性或自定义定义的优先级）对文档进行评分和排序。
  • MetaFieldGroupingRanker 按指定元数据字段对文档进行分组，并将每个组中的所有文档一起返回，确保相关文档（例如，来自同一文件）作为一个整体进行处理，这已被证明可以提高 LLM 的性能。
  • LostInTheMiddleRanker 在排名之后重新排序文档，以减轻具有有限上下文窗口的模型的定位偏差，确保不会忽略高度相关的项目。

MetaFieldRanker Ranker 通常在语义排序 *之前* 使用，以根据业务逻辑过滤或重构文档。

相比之下，LostInTheMiddleRanker 和 MetaFieldGroupingRanker 则用于排名 *之后*，以提高 LLM 等下游组件的有效性。这些确定性方法提供了速度、透明度和精细的控制，非常适合需要可解释性或严格操作逻辑的 Pipeline。

更新于 4 个月前