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

本文涉及的产品
模型在线服务 PAI-EAS,A10/V100等 500元 1个月
模型训练 PAI-DLC,100CU*H 3个月
交互式建模 PAI-DSW,每月250计算时 3个月
简介: Jina AI正式推出第三代重排器 Jina Reranker v3。它在多项多语言检索基准上刷新了当前最佳表现(SOTA)。


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


模型链接:

https://modelscope.cn/models/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 格式。相关权重可直接在魔搭社区模型详情页获取。


GGUF & MLX 权重:https://modelscope.cn/models/jinaai/jina-reranker-v3

模型 参数量 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-multilingualjina-colbert-v2),也成功超越了许多(如 Qwen3-Reranker-4Bjina-reranker-m0)等体量远大于它的模型,实现了性能与效率的最佳平衡。


点击可跳转模型链接~

https://modelscope.cn/models/jinaai/jina-reranker-v3

目录
相关文章
|
1月前
|
人工智能 运维 Serverless
函数计算 × MSE Nacos : 轻松托管你的 MCP Server
本文将通过一个具体案例,演示如何基于 MCP Python SDK 开发一个标准的 MCP Server,并将其部署至函数计算。在不修改任何业务代码的前提下,通过控制台简单配置,即可实现该服务自动注册至 MSE Nacos 企业版,并支持后续的动态更新与统一管理。
516 42
|
1月前
|
存储 消息中间件 Kafka
Confluent 首席架构师万字剖析 Apache Fluss(一):核心概念
Apache Fluss是由阿里巴巴与Ververica合作开发的Flink表存储引擎,旨在提供低延迟、高效率的实时数据存储与变更日志支持。其采用TabletServer与CoordinatorServer架构,结合RocksDB和列式存储,实现主键表与日志表的统一管理,并通过客户端抽象整合湖仓历史数据,弥补Paimon在实时场景下的性能短板。
323 22
Confluent 首席架构师万字剖析 Apache Fluss(一):核心概念
|
1月前
|
人工智能 安全 Java
分布式 Multi Agent 安全高可用探索与实践
在人工智能加速发展的今天,AI Agent 正在成为推动“人工智能+”战略落地的核心引擎。无论是技术趋势还是政策导向,都预示着一场深刻的变革正在发生。如果你也在探索 Agent 的应用场景,欢迎关注 AgentScope 项目,或尝试使用阿里云 MSE + Higress + Nacos 构建属于你的 AI 原生应用。一起,走进智能体的新世界。
409 36
|
1月前
|
SQL 人工智能 运维
一场由AI拯救的数据重构之战
本文以数据研发工程师小D的日常困境为切入点,探讨如何借助AI技术提升数据研发效率。通过构建“数研小助手”智能Agent,覆盖需求评估、模型评审、代码开发、运维排查等全链路环节,结合大模型能力与内部工具(如图治MCP、D2 API),实现影响分析、规范检查、代码优化与问题定位的自动化,系统性解决传统研发中耗时长、协作难、维护成本高等痛点,推动数据研发向智能化跃迁。
199 29
一场由AI拯救的数据重构之战
|
1月前
|
测试技术
哪里不对改哪里!全能图像编辑模型Qwen-Image-Edit来啦
Qwen-Image-Edit基于20B Qwen-Image模型,融合视觉语义与外观控制,支持中英文文字精准编辑、风格迁移、IP创作等多重功能,具备SOTA性能,助力低门槛、高精度图像编辑。
708 23
|
1月前
|
人工智能 IDE 程序员
Qoder 负责人揭秘:Qoder 产品背后的思考与未来发展
AI Coding 已经成为软件研发的必选项。根据行业的调研,目前全球超过 62% 的开发者正在使用 AI Coding 产品,开发者研发效率提升 30% 以上。当然,有很多开发者用得比较深入,提效超过 50%。
420 20
|
2月前
|
人工智能 运维 安全
配置驱动的动态 Agent 架构网络:实现高效编排、动态更新与智能治理
本文所阐述的配置驱动智能 Agent 架构,其核心价值在于为 Agent 开发领域提供了一套通用的、可落地的标准化范式。
567 52
|
1月前
|
人工智能 安全 Serverless
再看 AI 网关:助力 AI 应用创新的关键基础设施
AI 网关作为云产品推出已有半年的时间,这半年的时间里,AI 网关从内核到外在都进行了大量的进化,本文将从 AI 网关的诞生、AI 网关的产品能力、AI 网关的开放生态,以及新推出的 Serverless 版,对其进行一个全面的介绍,期望对正在进行 AI 应用落地的朋友,在 AI 基础设施选型方面提供一些参考。
461 36

热门文章

最新文章