Jina Reranker v3: 全新“列式”重排器，0.6B参数刷新文档检索SOTA

原创于 2025-10-09 16:06:52 发布 · 308 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#jina

我们正式推出第三代重排器 Jina Reranker v3。它在多项多语言检索基准上刷新了当前最佳表现（SOTA）。

🤗：https://huggingface.co/jinaai/jina-reranker-v3

📖：https://arxiv.org/abs/2509.25085

这是一款仅有 6 亿参数的多语言重排模型。我们为其设计了名为 “last but not late” （中文我们译作后发先至）的全新交互机制，使其能接受 Listwise 即列式输入，在一个上下文窗口内一次性完成对查询和所有文档的深度交互。

凭借这一高效架构，Jina Reranker v3 以小 6 倍的体量，在 BEIR 基准上取得 61.94 的 nDCG@10 分数，性能成功反超了 40 亿参数的 Qwen3-Reranker-4B。

为了方便大家在不同硬件环境，尤其是本地 CPU 和苹果芯片上部署 Jina Reranker v3，我们现已提供动态量化的 GGUF 与 MLX 格式。相关权重可直接在我们的 Hugging Face 主页获取。

🤗 GGUF & MLX 权重：https://huggingface.co/collections/jinaai/jina-reranker-v3-68de3ce4fa0668eeee4fd2c1

模型	参数量	BEIR	MIRACL	MKQA	CoIR
jina-reranker-v3	0.6B	61.94	66.83	67.92	70.64
jina-reranker-v2	0.3B	57.06	63.65	67.90	56.14
jina-reranker-m0	2.4B	58.95	66.75	68.19	63.55
bge-reranker-v2-m3	0.6B	56.51	69.32	67.88	36.28
mxbai-rerank-base-v2	0.5B	58.40	55.32	64.24	65.71
mxbai-rerank-large-v2	1.5B	61.44	57.94	67.06	70.87
Qwen3-Reranker-0.6B	0.6B	56.28	57.70	65.34	65.18
Qwen3-Reranker-4B	4.0B	61.16	67.52	67.52	73.91
jina-code-embeddings-0.5b	0.5B	-	-	-	73.94

BEIR 评测：验证核心性能

BEIR

我们首先在 BEIR 基准上，检验模型在英文检索任务中的核心性能，并采用 nDCG@10 作为关键指标。

整个评测流程模拟了真实的两阶段检索场景：我们先用 jina-embeddings-v3 模型进行初步检索，抓取前 100 个最相关的文档，然后交由 Reranker v3 进行精排。

MIRACL & MKQA 跨语言能力评测

MIRACL

MKQA

除了强大的英文处理能力，我们更关注模型在全球化场景下的通用性。因此，我们分别采用 MIRACL 和 MKQA 两大基准，对模型的跨语言检索能力进行了全面评测。

结果显示，虽然模型结构十分紧凑，它依然在 18 种语言（MIRACL） 和 26 种语言（MKQA） 中，性能表现卓越且一致，在多语言、多地区场景下实现了高度的通用性与稳定性。

MIRACL：覆盖英语、中文、西班牙语、阿拉伯语、法语、俄语、德语、日语、韩语等 18 种主流语言，模型在各语言中均表现稳定。
MKQA：在 MIRACL 的基础上，进一步扩展至越南语、土耳其语、波兰语、泰语、瑞典语、希伯来语、繁体中文、香港中文等 26 种语言及地区方言。模型同样保持了优异的检索效果。

重排器的技术演进

在深入 Jina Reranker v3 的设计之前，我们有必要快速回顾一下重排器技术的主流范式。传统的学习排序（Learning-to-Rank）方法，大致可以分为三类：

1. Pointwise：这是最早期的方法。模型每次仅考虑一个文档，逐个判断每个文档与查询的相关性，输出一个绝对分数。它的问题在于完全忽略了文档之间的相互关系，缺乏全局视野。

2. Pairwise：该方法更进一步。模型不再是看单个文档，而是通过比较文档对（例如，判断“文档 A 是否比文档 B 更相关”）来学习排序。它开始具备相对的判断能力，但其视野依然局限在“二选一”的比较中，无法理解整个候选列表的全局信息。

然而，这两种方法都缺乏对候选文档的整体洞察。 一个理想的重排器，应该能够审阅 全部的 候选文档，综合考量它们之间的互补、冗余甚至矛盾关系，最终给出一个最优的整体排序。

这正是 Listwise 的核心思想，也是 Jina Reranker v3 所选择的技术路线。

为了实现这一点，Jina Reranker v3 将用户查询和所有候选文档拼接 (concatenate) 成一个长序列，作为一个整体输入到模型中。在单一的上下文窗口内，模型通过因果注意力机制，同时处理所有文本。

这个设计使得任何一个文档在被编码时，都能关注到其他文档的内容，从而实现跨文档的信息交互。当整个序列处理完毕后，模型再从每个文档末尾预设的特殊位置，提取出包含了上下文信息的表征向量。

模型架构

Jina Reranker v3 是在 Qwen3-0.6B 基础模型上构建。它是一个典型的仅解码器（decoder-only）Transformer 架构，其核心机制是因果自注意力（causal self-attention）。

模型能够在一个统一的上下文中，同时处理查询和所有文档，并在我们预设的特定词元（token）位置，提取出包含上下文信息的向量，用于后续的相似度计算。

核心技术参数如下：

参数	值
总参数量	6 亿
模型主体参数量	4.4 亿
隐藏层维度	1,024
网络层数	28
注意力头 (Q/KV)	16/8 (GQA)
上下文长度	131,072
MLP 投射层	1024→512→256
最终向量维度	256

为了在模型中实现 Listwise 排序，我们设计了一套专门的输入格式 (prompt template)。该格式将系统指令、用户查询和所有待排序的文档，全部组织在一个文本序列中。

<|im_start|>system
You are a search relevance expert who can determine
a ranking of passages based on their relevance to the query.
<|im_-end|>

<|im_start|>user
I will provide you with k passages, each indicated by a numerical identifier.
Rank the passages based on their relevance to query: [QUERY]

<passage id="1">
[DOCUMENT_1]<|doc_emb|>
</passage>
<passage id="2">
[DOCUMENT_2]<|doc_emb|>
</passage>
...
<passage id="k">
[DOCUMENT_k]<|doc_emb|>
</passage>

<query>
[QUERY]<|query_emb|>
</query>
<|im_end|>

<|im_start|>assistant
<think></think>

这个结构有几个关键设计：

1. 文档的边界：

每个文档都用 <passage> 标签包裹住，并分配了独立 ID，确保在长上下文中模型能清晰地区分每一个文档。在 131K 的上下文长度内，模型一次最多可以处理 64 个文档。对于超出的部分，系统会进行分批处理，并在各批次间复用同一个查询。

2. 查询的双重布局：

我们特意将查询（Query）放置了两次。第一次出现在开头的指令部分，用于向模型设定任务目标；第二次则放在末尾，用于最终的注意力计算。

正是这种将文档“三明治”式地夹在两次查询之间的结构，才使得因果注意力机制能够发挥作用（当前 token 只能关注到它前面的所有 token），处于序列末尾的查询，可以物理上看到并关注到前面所有的文档内容，从而形成一个包含了全局信息的查询表征。

3. 专用的向量提取词元：

为了从处理后的序列中精确提取向量，我们引入了两个特殊词元（special token）。

<|doc_emb|> 放置在每个文档末尾，用来提取文档的最终向量。
<|query_emb|> 跟在末尾的全局查询之后，提取最终查询的向量。

整个过程依赖于共享的因果自注意力机制，它确保了最终生成的向量，既能忠实地反映每个文档自身的局部语义，又能充分体现文档间相互对比、关联后产生的全局上下文信息。

核心交互机制： “last but not late”(后发先至)

我们将这种独特的交互机制命名为 “last but not late” (后发先至)。

Last（后发）指的是指的是我们提取文档表征向量的位置。我们刻意将向量提取点设置在每个文档最后一个词元之后，附加上专用的 <|doc_emb|>词元，确保了在生成该向量时，模型已经完整捕捉了文档的全部信息。

Not Late（先至）则强调了 Jina Reranker v3 与 ColBERT 等迟交互（late interaction）模型的根本区别。

迟交互模型的流程是“先编码，后交互”：它先在各自独立的上下文中为每个文档生成向量，然后再进行匹配计算。在这个过程中，文档编码时彼此隔离。
我们的方法则是“编码即交互”：我们将查询和所有文档置于同一个上下文窗口这个共享空间内，通过一次完整的前向传播，就同步实现了查询与文档、以及文档与文档之间的充分交互。交互贯穿于编码的全过程，因此不存在延迟。

评分与排序

当模型完成对整个序列的一次前向传播后，评分和排序是最后一步。

我们在 Transformer 主体结构上，增加了一个轻量级的 MLP 投射层（带 ReLU 激活函数），将提取出来的文档和查询表征，转化成为排序任务专门优化的向量。

具体来说，是先从 <|doc_emb|> 和 <|query_emb|> 位置提取出 1024 维的隐藏状态，投射到 256 维的专用于排序的向量空间，然后再计算查询与各文档向量间的余弦相似度，得出最终的相关性分数并完成排序。

快速上手

通过 API 调用

使用 jina-reranker-v3 模型最简便的方式，是通过我们提供的 Search Foundation API 进行调用。

curl -X POST \
  https://api.jina.ai/v1/rerank \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer JINA_API_KEY" \
  -d '{
  "model": "jina-reranker-v3",
  "query": "slm markdown",
  "documents": [
    ...
  ],
  "return_documents": false
}'

API 将返回如下格式的 JSON 数据：

{
  "model":"jina-reranker-v3",
"usage": {
    "total_tokens":2813
  },
"results":[
    {
      "index":1,
      "relevance_score":0.9310624287463884
    },
    {
      "index":4,
      "relevance_score":0.8982678574191957
    },
    {
      "index":0,
      "relevance_score":0.890233167219021
    },
    ...
  ]
}

返回结果中的 relevance_score 字段代表了每个文档与查询的相关度。分值越高，表示相关性越强。

通过 transformers 调用

from transformers import AutoModel

model = AutoModel.from_pretrained(
    'jinaai/jina-reranker-v3',
    dtype="auto",
    trust_remote_code=True,
)
model.eval()

接着，可以使用模型的 rerank 函数来计算查询和文档列表的相关性得分：

query = "What are the health benefits of green tea?"
documents = [
    "Green tea contains antioxidants called catechins that may help reduce inflammation and protect cells from damage.",
    "El precio del café ha aumentado un 20% este año debido a problemas en la cadena de suministro.",
    "Studies show that drinking green tea regularly can improve brain function and boost metabolism.",
    "Basketball is one of the most popular sports in the United States.",
    "绿茶富含儿茶素等抗氧化剂，可以降低心脏病风险，还有助于控制体重。",
    "Le thé vert est riche en antioxydants et peut améliorer la fonction cérébrale.",
]

# Rerank documents
results = model.rerank(query, documents)

# Results are sorted by relevance score (highest first)
for result in results:
    print(f"Score: {result['relevance_score']:.4f}")
    print(f"Document: {result['document'][:100]}...")
    print()

结论

Jina Reranker v3 作为一款仅有 6 亿参数的多语言 Listwise 重排模型，其核心优势在于 “last but not late” 交互机制，让所有文档在编码阶段就能相互进行注意力计算，从而利用文档间的交互信息来指导最终的排序决策。

作为 Listwise 模型，一个核心的工程疑虑是：它对输入文档的顺序到底有多敏感？如果第一阶段检索器（Retriever）给出的初始排序质量不高，甚至完全是随机的，Jina Reranker v3 的最终排序结果是否会产生剧烈波动？

为了量化和验证这一点，我们进行了一项严苛的压力测试。我们固定一个查询和 110 个候选文档，然后对其输入顺序进行了 1000 次随机打乱，并绘制了每个排序位置的抖动情况，也就是稳定性方差图。

这张排序稳定性图表，直观地展示了在 1000 次随机输入顺序下，文档在各个排序位置上出现的稳定性。

Y 轴 代表稳定性方差：可以理解为排序位置的抖动程度。0% 表示完美的稳定性，即无论输入顺序如何，同一个文档总是出现在该位置；100% 意味着该位置的文档极其混乱，几乎每次都被不同的文档占据。
X 轴 代表从 1 到 110 的排序位置。

图表揭示了几个关键现象：

1. 头部结果极其稳定：从图中可以看到，Top 1-10 的位置方差极小，几乎没有抖动。这强有力地证明了，无论输入顺序如何混乱，v3 总能稳稳地将最相关的结果识别出来并置于顶端。这对于 nDCG@10 这类只关注头部结果的评价指标来说，是至关重要的。

2. 尾部结果同样稳定：不相关的文档被稳定地压制在排序末尾，清晰地实现了相关与不相关内容的分离。

3. 中部波动符合预期：图中部位置出现了明显的排序交换现象，完全符合我们的设计预期。因为模型采用的是因果自注意力机制，对于序列中不同位置的文档，其编码会受到前面文档的影响，从而捕捉到不同的上下文信息。在绝大多数只关注 Top-K 结果的实际应用中，这种中间位置的排序不确定性是完全可以接受的。

在实际应用中，用户最关心的是头部结果的准确性和稳定性，Jina Reranker v3 在这一点上表现相当出色。

Jina Reranker v3 作为一款轻量级模型，性能不仅全面超越了自身的早期版本（如 jina-reranker-v2-base-multilingual 和 jina-colbert-v2），也成功超越了许多（如 Qwen3-Reranker-4B 和 jina-reranker-m0）等体量远大于它的模型，实现了性能与效率的最佳平衡。