Cohere、Voyage、Jina 与 Qwen3：检索栈里唯一一个你真能反悔的模型

速览

两个托管 API，两套开放权重，而分界线并不在你以为的地方。

为什么这个决定很便宜，以及这件事为何要紧

我们在 嵌入模型那一篇 里论证过：嵌入模型是你无法低价反悔的那个部件——两个模型产出的向量处在不同空间里，所以换一个就意味着把整个语料重新嵌入、把每一个阈值重新调过、还要把一份黄金集重新标注，因为它的相关性判断当初是对着另一批近邻作出的。

重排序模型恰好是它的反面，而且原因是结构性的。它在检索之后被调用，作用于一份候选列表，返回一个排序。它什么也不写，什么也不存。换掉它，唯一变化的产物是一个分数分布——这确实意味着要重新调你的截断线，但也就仅此而已。一支团队可以在一个下午之内，用线上流量对两个重排序模型做影子对比；而检索栈里其他任何部件，这句话都写不出来。

这种不对称应该改变你的选购姿态。通常撑起一场漫长评估的是锁定风险，而这里根本没有锁定，所以正确的姿态是：快选、在自己的查询上测、半年后排行榜重新洗牌时再复查一遍。它不该做的，是把你送到排行榜跟前——因为排行榜度量的那条轴，恰是你的选择最不要紧的那条。

Cohere Rerank 4——计价平坦的那一个

发布了什么

Cohere 于 2025 年 12 月发布 Rerank 4.0，分两档：rerank-v4.0-pro 每次检索 $0.0025，rerank-v4.0-fast 每次 $0.002，两者训练时的上下文长度均为 32,768 令牌。相对 rerank-v3.5 的 4,096 令牌与每千次检索 $2.00，这个上下文长度才是主要升级。

计费单位本身就是产品

一次"检索"是一个查询加上它的候选列表，而收费不随你传了多少候选、候选有多长而变化。重排一百个片段，还是二十个长小节，账单一模一样。对于长文档负载，这是这一类里最宽容的定价模型，而且它让成本预测简单到按令牌计价永远做不到的程度。

有一个从旧模型延续下来的小坑，值得在它出现在账单上之前先知道。当"查询 + 单个文档"超出模型上下文时，该文档会被自动切块并分多次推理处理，而每一个块都要计入这次请求的文档额度——端点的上限被表述为"文档数乘以每文档最大块数需低于 10,000"。在 v3.5 的 4,096 令牌上下文下，这条会不断被触发；而在 v4 的 32,764 令牌切块尺寸下，它几乎不会。如果你还在用 v3.5，请查一查你那个"平坦"的按次成本，是不是其实是"每 500 令牌"的成本。

它适合谁

对于希望把重排序变成一个已解决的成本科目的团队，Cohere 是那个无聊但正确的默认选项：主流云上都有、语言覆盖广、不用 GPU、没有许可证问题。独立测评也一贯把它列在托管选项里最快的那一档。

Voyage rerank-2.5——你可以跟它说话的那一个

发布了什么

Voyage AI 于 2025 年 8 月 11 日发布 rerank-2.5 与 rerank-2.5-lite，按其说法是首批具备指令跟随能力的重排序模型。两者支持 32K 令牌的"查询—文档对"上下文，其中查询本身最多可占 8K；两者均按令牌计价：rerank-2.5 每百万令牌 $0.05，lite 版本 $0.02。

指令是那个值得一测的差异点

这个对比里的其他每一个模型，接收的都是一个查询和一份列表。Voyage 接收的是一个查询、一份列表，外加一句关于"本次请求中相关性意味着什么"的自然语言指令——"优先取最近一个季度的文档"、"按流程适用性排序，而非按主题相似度"。对智能体而言，这是真正的新能力而非一项便利，因为智能体对相关性的理解会在同一个任务的不同步骤之间发生变化：同一份语料，按"政策是怎么规定的"和按"我们实际做了什么"分别重排，是两种不同的排序，而单一的静态重排序模型产出不了。

Voyage 报告称，在 93 个数据集上 rerank-2.5 与 lite 分别比 Cohere Rerank v3.5 准确 7.94% 与 7.16%，若提供指令再增约 8%。这些是厂商自行公布的数字，对标的又是一个如今已被取代的竞品模型，因此应当读作"这一量级的收益是存在的"，而不是一次当下的正面较量。

它适合谁

当相关性取决于查询文本本身并不携带的某样东西时、并且你的候选很短时，去拿 Voyage。在下文那种智能体形态的负载上，它是最便宜的托管选项，便宜两到五倍。

Jina Reranker v3.5——很快，但许可证有问题的那一个

发布了什么

jina-reranker-v3 是一个 0.6B 参数的列表式重排序模型，基于 Qwen3-0.6B，采用其作者所称的"last but not late"交互：查询与至多 64 个候选一同放进一个 131K 令牌的上下文、以因果注意力处理，一次前向即为每个候选产出上下文化嵌入。它在 BEIR 上报告 61.94 nDCG@10，而体量约为生成式列表重排序模型的十分之一。3.5 版本于 2026 年 7 月发布，带来混合注意力与自蒸馏：BEIR 上 63.20 nDCG@10，在各种上下文长度上比 v3 快 1.22 到 1.56 倍，在半结构化检索上 nDCG@10 跃升 9.6 个点。它是一个请求 schema 不变的原位替换。

列表式是它押下的架构赌注

孤立地给候选打分是标准的交叉编码器设计，而它有一个已知的弱点：一份文档是否相关，往往取决于还有些什么别的可选。列表式打分让模型在排序之前先看清整个场面，这也是为什么 v3.5 最大的增益出现在半结构化数据上——那里必须把近乎重复的行区分开。代价是一个上限——每次前向 64 个候选——以及一套在高负载下与逐点重排序模型表现不同的批处理模型。

然后请读许可证

jina-reranker-v3.5 以 CC BY-NC 4.0 发布。非商用。权重可以下载、论文是公开的、模型很出色，而在与 Jina 谈妥条款之前，你不能把它放进你的产品——与此同时，其托管 API 仍以商业条款提供。这是整个对比里后果最重的一个事实，而它不出现在任何排行榜上，因为排行榜没有"我能不能用"这一列。如果你的评估候选名单是从一张基准表上抄下来的，请在动感情之前把名单上每一个的许可证都查一遍。

Qwen3-Reranker——你真能部署的那一个

发布了什么

Qwen3-Reranker 作为 Qwen3 Embedding 系列的一部分，提供 0.6B、4B、8B 三种尺寸，覆盖 100 多种语言，以 Apache 2.0 许可证发布在 Hugging Face 与 ModelScope 上。它在查询之外还接收一个 instruction 字段，所以"按指令条件化的相关性"在这里也能用，而且是自建的。

许可证就是它的特性

没有非商用条款、也不附带任何厂商关系的 Apache 2.0，与一个你租来的模型是不同种类的资产。它可以进入气隙部署，可以进入那种"一次对外 API 调用就是一次合规事件"的受监管环境，也可以进入你交付给客户、由客户自行运行的产品。这个对比里没有第二个能同时做到这三件事。

账单以延迟的形式送达

较大的那几个尺寸并不快。独立测试测得 Qwen3-Reranker-4B 每次查询超过一秒，而 0.6B 参数的 Jina v3 是 188ms——这个差距在聊天产品里几乎看不见，在智能体里却是残酷的，原因见下一节。请从 0.6B 起步，只有当你自己的评测表明那点准确率值这些毫秒时才往上爬。

横向对比：计费单位会把排名颠倒过来

这两个托管模型不只是收费金额不同，它们收费所依据的轴就不同，而交叉点恰好落在常规用法的正中间。在智能体形态上——来自混合检索的一百个短候选，每个约 200 令牌——Voyage rerank-2.5 每千次重排约一美元，对比 Cohere Rerank 4 Fast 的两美元，而 lite 版本是四毛。别的都不动，只改候选的形态——二十个三千令牌的小节，也就是文档问答系统的画像——Voyage 就变成了三美元的那个贵家伙，而 Cohere 纹丝未动，因为按次计费对文档长度毫无意见。

实际推论是：没有哪个重排序模型在一般意义上比另一个便宜；任何一份不说明候选画像的成本比较，等于什么也没告诉你。在读任何人的定价页之前——包括这一页——先算出你自己的那两个数字：每次重排多少候选、每个候选多少令牌。自建的那一对完全在这套算术之外：它们的成本是一块你反正也在租的 GPU，这在每月百万次重排以上会成为决定性因素，而在十万次以下无关紧要。

横向对比：延迟是被乘上去的，不是只付一次

在一个搜索框里，重排序模型只跑一次，几百毫秒消融在页面加载里。而在一个 智能体式检索 循环里，模型会改写查询再搜一遍——一个任务里五次、二十次、四十次——而重排序模型的延迟会被乘上其中的每一次。第三方测评把 Jina Reranker v3 测在 188ms，托管的 Cohere Rerank 3.5 连同网络往返约 600ms，Qwen3-Reranker-4B 在一秒以上。摊到四十次检索上，那就是"给任务加七秒"和"加四十秒"的差别。

由此有三个推论。把一个小的重排序模型自建在索引旁边，能去掉一次网络跳转，而这一跳可能占托管延迟的三分之一——这是比令牌成本更强的开放权重理由。一旦乘数进场，"更少但更好的检索"就胜过"更多但更便宜的检索"。而重排序模型的延迟应当作为一个明确科目进入你智能体的步骤预算，而不是作为一个实现细节——请像 延迟预算 对待其他每一跳那样对待它。

那些延迟数字请当作方向性的来读。它们来自不同的测试框架、不同的硬件、不同的候选数量，而且没有一个是你的负载。它们可靠到足以告诉你自己身处哪个数量级，而这正是它们需要支撑的那个决定。

横向对比：相关性，以及为何它不是那条决定性的轴

在公开检索基准上，这几个模型很接近，而且排序并不稳定。jina-reranker-v3.5 在 BEIR 上报告 63.20 nDCG@10，v3 为 61.94；Qwen3-Reranker-0.6B 在同一榜单上接近 59，而 8B 版本高于 jina-v3；Cohere 与 Voyage 干脆公布的是相对增益，而非可比的 BEIR 数字。诚实的总结是：一个两到四个 nDCG 点的区间，且会随领域和语言重新排序。

把它对照管线里其他环节的效应量。在一个纯稠密检索栈上加入任何一个称职的重排序模型，通常值十个点以上；修好一个会把表格从中间切断的分块器，其价值超过这四家之间的全部差距。如果你在还没有混合检索和结构感知分块的时候就在几个重排序模型之间纠结，那你是在优化这个等式里最小的那一项。

这也正是"把相关性当作一道资格线、而非一份排名"的理由。先在你自己标注的查询上确认某个候选模型落在那个区间内，然后再按真正把它们区分开的那些轴来定：账单跟着什么增长、每一跳多加多少毫秒，以及许可证允不允许你把它交付出去。

什么时候选哪个

延伸阅读

本站内容：

• 混合检索与重排序——重排序模型待在哪儿、它在修什么。
• 智能体式检索——把延迟乘上去的那个循环。
• 分块与向量搜索——通常更值钱的那个上游修复。
• 小模型与本地模型——为什么重排序是自建的典范活儿。
• 你无法低价反悔的那个嵌入模型——这个决定的镜像。

项目来源：

• Cohere Rerank 文档
• Voyage AI：rerank-2.5 与 rerank-2.5-lite
• jina-reranker-v3: Last but Not Late Interaction for Listwise Document Reranking
• Hugging Face 上的 jina-reranker-v3.5
• Qwen3 Embedding: Advancing Text Embedding and Reranking Through Foundation Models