Rerank（重排序）处在检索链路的最后一公里：先用向量检索或混合检索召回几十到几百条候选，再用 cross-encoder 逐条计算 query 与文档的相关性，把真正有用的片段排到前面。它不生成文字，却能明显改善“答案就在第十名”的问题。

但 Rerank 没有唯一正确的实现方式。托管 API、开源权重模型、向量数据库内置能力，三条路线都能用，差别在质量、延迟、语言覆盖、隐私、成本和运维。本文按六个维度拆开，最后给场景表和迁移清单。具体模型与价格以站内模型价格为准。

说明：Cohere、Jina、Voyage、Qwen、BGE、Weaviate、Milvus、Elasticsearch 等名称均为其权利人的商标，本文仅作技术讨论。各产品能力、限额与条款会调整，接入前请核对对应厂商文档。

一、先确认瓶颈在重排

不是所有 RAG 效果差都值得上重排。先看三个信号：正确片段能被召回，但经常排在五名以后；混合检索后前几条噪声明显，关键词匹配压过了语义相关；生成答案引用了错误段落，手工换入正确段落就能答对。

如果正确片段根本不在召回集里，重排无能为力，应该先改切块、Embedding 或召回数量。如果候选只有三五条，重排收益也有限。经验上，候选集在二十到两百条之间时，重排的性价比更高；超过几百条，延迟和费用会快速上升。

二、三条路线各是什么

托管 Rerank API：厂商把模型和推理封装成接口，通常接收 query、documents、top_n，返回按相关性排序的 index 和分数。优点是接入快、多语言覆盖通常较好、无需 GPU；缺点是数据要出网、受限于厂商限额与接口格式，长期成本随调用量增长。

开源权重 cross-encoder：把模型部署在自己的 GPU 或推理服务上，常见选择包括 BGE 重排系列、Qwen3-Reranker、Jina Reranker 等。优点是数据不出内网、可微调、可固定版本；缺点是要自己承担 GPU、扩缩容、模型升级和推理框架维护。vLLM、TEI 等框架已提供重排接口，能减少一部分适配工作。

向量数据库内置重排：部分向量库提供内置或集成的重排能力，例如 Weaviate 的 rerank 模块、Elasticsearch 的 rerank retriever、Milvus 较新版本提供的 rerank function；也有产品只负责检索，把重排交给外部服务。优点是少一次网络跳转、权限和运维边界统一；缺点是模型选择受产品限制，深度定制空间小。

需要特别注意：Rerank 并不像 Chat Completions 那样有统一的 OpenAI 兼容标准。Jina、Cohere、Voyage 三族的字段就不完全一样，例如 top_n 与 top_k、是否返回文档正文、单文档截断参数都不同；端点也可能是 /v1/rerank 或 /v2/rerank。替换供应商时，协议适配往往比模型本身更花时间。

三、六个维度怎么比

质量上，托管 API 与开源模型都可能是 cross-encoder，差别更多在训练数据、语言分布和版本。不要只看公开榜单，要用自己的业务 query 和候选集评测。向量库内置能力如果调用的是同一类模型，效果通常接近，但可调参数更少。

延迟上，重排耗时大致随“候选条数乘文档长度”增长。托管 API 多一次公网往返，适合候选集较小、并发稳定的场景；自建少一次外部依赖，但要处理 GPU 排队；内置方案省掉网络跳转，却可能和检索争抢同一套资源。

语言覆盖上，中文、中英混合、小语种要分开看。很多模型在英文榜单上表现接近，落到中文长文档和行业术语上差距会放大。建议分别准备中文、英文、混合三组评测集。

隐私上，只要文档离开自己的网络，就要评估数据条款、传输加密、日志留存和跨境路径。合同、客户资料、医疗与财务文本通常优先考虑自建或私有化部署。

成本上，托管按调用量或 token 计费，调用越多越接近线性；自建是 GPU 固定成本加人力，低调用量时不一定便宜；内置方案可能包含在数据库套餐里，也可能按推理量另计。要把重试、离线评测和峰值扩容一起算进去。

运维上，托管把模型升级和扩缩容交给厂商，但你要管理 Key、限额和多供应商差异；自建要有人值守 GPU、处理驱动与框架升级；内置方案把两套系统合成一套，故障域也更集中。

四、按场景选型

场景 建议路线 理由 注意点
快速验证、候选集几十条 托管 Rerank API 当天可接入，无需 GPU 先确认数据能否出网
中文为主、数据敏感 开源自建 可私有化，可选中文强的模型 预留 GPU 与运维人力
已在用某向量库且需求简单 向量库内置 少一次集成，权限统一 确认模型与参数可满足
高并发、延迟敏感 自建或同区内置 避免公网往返与排队 做压测，不只看均值
多语言、小语种 托管 API 或强多语言开源模型 语言覆盖更省事 用小语种评测集验证
调用量很小、团队无 GPU 托管 API 固定成本更低 设置预算与限额告警

这张表只是起点。同一个团队也可以组合：线上用托管 API 保底，离线评测用开源自建，向量库内置只处理低风险业务。

五、质量怎么评，不要凭感觉

至少准备三样东西：一批真实 query、每个 query 的正确文档标注，以及当前召回集。指标看 Recall@k、MRR 或 nDCG，不要只看“看起来更相关”。把重排前后同一批候选导出，人工抽查前十条，记录错误类型：是召回缺失、切块断裂，还是重排把正确段落压后。

下面这段 Python 只做一件事：比较重排前后正确文档是否进入前 k 条。它不依赖具体厂商，输入是两份排好序的 index 列表。

def hit_rate(cases, k):
    hits = 0
    for gold, ranked in cases:
        if gold in ranked[:k]:
            hits += 1
    return hits / len(cases)

# cases: [(正确文档 index, 重排后的 index 列表), ...]
before = hit_rate(baseline_cases, 5)
after = hit_rate(reranked_cases, 5)
print(f"Recall@5: {before:.3f} -> {after:.3f}")

样本量建议不少于一百条，覆盖不同业务线和文档长度。上线前再看 p95 延迟和单次调用成本，别用平均值掩盖长尾。

六、迁移清单

从一家 Rerank API 换到另一家，或从托管换到自建，按下面顺序做：

  1. 固定评测集与当前基线，记录 Recall@k、MRR、p95 延迟和单次成本。
  2. 确认新方案的端点路径、鉴权方式与请求字段，重点核对 top_n 与 top_k、是否返回正文、截断参数。
  3. 对齐分数语义：是零到一的相关性分数还是未归一化 logits，排序是升序还是降序，不要直接混用阈值。
  4. 核对单次文档数、单文档 token、请求体大小和并发限额，超限时在客户端拆分，而不是等接口报错。
  5. 把超时、429 和 5xx 的重试与降级写好，降级时保留原召回顺序，避免整条链路失败。
  6. 用影子流量对比新旧结果，至少观察一周，记录排序差异和答案质量变化。
  7. 灰度切流，设置回滚阈值，例如错误率或 p95 超过基线一定比例就回退。
  8. 更新监控与账单口径，确认重试、缓存和离线评测没有被漏算。

常见问题

Rerank API 和 Embedding API 有什么区别？

Embedding 把文本变成向量，用于大规模召回；Rerank 逐条读取 query 和文档，精度更高但更慢。常见做法是先召回几十到几百条，再精排前几条。

开源重排序模型一定比托管 API 便宜吗？

不一定。调用量小的时候，GPU 固定成本和运维人力通常高于按量付费；调用量大、数据敏感或有定制需求时，自建才更容易摊薄成本。要把峰值扩容算进去。

向量数据库自带的重排够用吗？

看场景。如果候选集不大、对模型选择没有特殊要求，内置能力可以省掉一次集成；如果需要特定语言、特定领域微调或更细的参数控制，独立的重排服务更灵活。

中文场景怎么选重排模型？

先看模型是否明确支持中文或多语言，再用自己的中文 query 和文档做评测。不要直接用英文榜单排名代替。中英混合、长文档和行业术语要单独抽样。

换重排服务后分数阈值要重调吗？

通常要。不同模型的分数分布不同，有的归一化到零到一，有的输出 logits。依赖固定阈值过滤的场景，应重新标定，或改用排名位置而不是绝对分数。

下一步

如果只是想先跑通链路，可以在中商起航 AI 网关创建一个测试 Key，用同一批 query 对比重排前后的召回质量，再按模型价格估算调用成本。模型可用性与计费口径以价格页为准。

相关阅读：