


Aujourd'hui, nous publions jina-embeddings-v4, notre nouveau modèle d'向量模型 (Embeddings) universel de 3,8 milliards de paramètres pour le texte et les images. Il comprend un ensemble d'adaptateurs LoRA spécifiques à chaque tâche qui optimisent les performances pour les tâches de récupération les plus courantes, notamment la récupération de requêtes-documents, la correspondance sémantique et la recherche de code. jina-embeddings-v4 atteint des performances de récupération de pointe sur les tâches multimodales et multilingues à travers les benchmarks MTEB, MMTEB, CoIR, LongEmbed, STS, Jina-VDR, CLIP et ViDoRe, avec une force particulière dans le traitement de contenu visuellement riche tel que les tableaux, les graphiques, les diagrammes et les mélanges de ceux-ci. Le modèle prend en charge à la fois les 向量模型 (Embeddings) à vecteur unique et à vecteurs multiples.

jina-embeddings-v4 est notre modèle d'向量模型 (Embeddings) le plus ambitieux à ce jour. En tant que modèle open source, jina-embeddings-v4 surpasse les principaux modèles d'向量模型 (Embeddings) propriétaires des principaux fournisseurs, offrant des performances supérieures de 12 % à text-embedding-3-large
d'OpenAI sur la récupération multilingue (66,49 contre 59,27), une amélioration de 28 % sur les tâches de documents longs (67,11 contre 52,42), 15 % de mieux que voyage-3
sur la récupération de code (71,59 contre 67,23) et égalant les performances de gemini-embedding-001
de Google. Cela fait de v4 le modèle d'向量模型 (Embeddings) universel open source le plus performant disponible aujourd'hui, offrant aux chercheurs et aux développeurs des capacités d'向量模型 (Embeddings) multimodales de niveau entreprise avec une transparence totale sur le processus de formation, les décisions architecturales et les poids du modèle grâce à notre rapport technique complet.

tagNouvelle architecture
Qwen2.5-VL-3B-Instruct
(3,8 milliards de paramètres). Les entrées de texte et d'image sont traitées via un chemin partagé : les images sont d'abord converties en séquences de 词元 (Tokens) via un encodeur de vision, puis les deux modalités sont traitées conjointement par le décodeur de modèle de langage avec des couches d'attention contextuelle. Trois adaptateurs LoRA spécifiques à chaque tâche (60 millions de paramètres chacun) fournissent une optimisation spécialisée pour les tâches de récupération, de correspondance de texte et de code sans modifier les poids de la base gelée. L'architecture prend en charge deux modes de sortie : (1) 向量模型 (Embeddings) à vecteur unique (2048 dimensions, tronquables à 128) générés via un pooling moyen pour une recherche de similarité efficace, et (2) 向量模型 (Embeddings) à vecteurs multiples (128 dimensions par 词元 (Token)) via des couches de projection pour les stratégies de récupération d'interaction tardive.La mise à niveau de jina-embeddings-v3 àjina-embeddings-v4 représente un changement de paradigme, passant des 向量模型 (Embeddings) uniquement textuels aux 向量模型 (Embeddings) multimodaux. Alors que la version v3 se concentrait sur l'optimisation des 向量模型 (Embeddings) textuels avec des adaptateurs LoRA spécifiques à chaque tâche, la version v4 répond au besoin croissant d'intégrer à la fois du contenu textuel et visuel dans des représentations unifiées.
Aspect | <strong>jina-embeddings-v3</strong> | <strong>jina-embeddings-v4</strong> |
---|---|---|
Backbone Model | jina-XLM-RoBERTa | Qwen2.5-VL-3B-Instruct |
Parameters (Base) | 559M | 3.8B |
Parameters (with adapters) | 572M | 3.8B + 60M per adapter |
Modalities | Text only | Text + Images (multimodal) |
Max Input Length | 8,192 tokens | 32,768 tokens |
Image Processing | None | Up to 20 megapixels, visually rich documents |
Multilingual Support | 89 languages | 29+ languages |
Vector Types | Single-vector only | Single-vector + Multi-vector (late interaction) |
Single-vector Dimensions | 1024 (MRL truncatable to 32) | 2048 (MRL truncatable to 128) |
Multi-vector Dimensions | Not available | 128 per token |
Task LoRA Specializations | • Asymmetric retrieval • Semantic similarity • Classification • Separation |
• Asymmetric retrieval • Semantic similarity • Code retrieval |
Training Stages | 3-stage: Pre-training → Embedding fine-tuning → Adapter training | 2-stage: Joint pair training → Task-specific adapter training |
Loss Functions | InfoNCE, CoSent, Extended triplet loss | Joint InfoNCE + KL divergence for single/multi-vector |
Positional Encoding | RoPE (rotary base frequency tuning) | M-RoPE (Multimodal Rotary Position Embedding) |
Cross-modal Processing | N/A | Unified encoder (reduced modality gap) |
MRL Support | Yes | Yes |
Attention Implementation | FlashAttention2 | FlashAttention2 |
tagBackbone
Le changement architectural le plus important de la version v4 est le passage de XLM-RoBERTa
à Qwen2.5-VL-3B-Instruct
pour le backbone. Cette décision a été motivée par l'objectif principal de la version v4, qui est de créer un modèle de 向量模型 (Embedding) universel permettant un "véritable traitement multimodal" où les images sont converties en séquences de 词元 (Tokens) et traitées aux côtés du texte, éliminant ainsi le modality gap présent dans les architectures à double encodeur.
La sélection du backbone s'aligne sur plusieurs objectifs de conception clés : l'excellence de Qwen2.5-VL dans la compréhension des documents soutient directement la force de la version v4 dans le traitement de contenu visuellement riche comme les tableaux, les graphiques et les captures d'écran. Les capacités de résolution dynamique permettent à la version v4 de gérer des images redimensionnées jusqu'à 20 mégapixels, comme spécifié dans l'architecture. L'encodage positionnel avancé fournit la base qui permet à la version v4 d'obtenir un alignement intermodal supérieur avec un score d'alignement de 0,71 contre 0,15 pour OpenAI CLIP.
tagLoRA Adapters
La version v4 simplifie les cinq tâches de la version v3 en trois tâches ciblées, reflétant les leçons apprises sur l'efficacité et l'adoption par les utilisateurs :
- Asymmetric retrieval (consolidation des adaptateurs query/passage de la version v3)
- Symmetric similarity (l'équivalent de text-matching de la version v3 pour les tâches STS)
- Code retrieval (appris de v2-code, manquant dans v3)
Cette consolidation supprime les adaptateurs de classification et de séparation de la version v3, concentrant la version v4 sur les cas d'utilisation de 向量模型 (Embedding) les plus efficaces : la recherche et le STS.
tagOutput Embeddings
La version v4 introduit un système à double sortie prenant en charge à la fois les 向量模型 (Embeddings) à vecteur unique et à vecteurs multiples, alors que la version v3 ne fournissait que des sorties à vecteur unique. Cela répond à différents scénarios de recherche :
- Single-vector mode: 向量模型 (Embeddings) de dimension 2048 (troncables à 128 via MRL) pour une recherche de similarité efficace
- Multi-vector mode: 128 dimensions par 词元 (Token) pour late-interaction retrieval
Cette double approche offre une plus grande efficacité avec les représentations multi-vecteurs, en particulier dans la recherche de documents visuellement riches, tout en maintenant l'efficacité pour les tâches de similarité standard. L'avantage constant de 7 à 10 % en termes de performances des multi-vecteurs par rapport au mode single-vector dans les tâches visuelles suggère que l'interaction tardive offre une correspondance sémantique fondamentalement meilleure pour le contenu multimodal.
tagParameter Size
Bien que la version v4 soit 6,7 fois plus grande que la version v3 (3,8B contre 570M de paramètres), les améliorations de performances en texte seul sont en fait modestes, ce qui suggère que la mise à l'échelle des paramètres a été principalement motivée par les exigences multimodales plutôt que par l'amélioration du texte. Sur les principaux benchmarks de texte, la version v4 atteint 66,49 sur MMTEB contre 58,58 pour la version v3 (amélioration de 14 %) et 55,97 sur MTEB-EN contre 54,33 pour la version v3 (amélioration de 3 %). Pour la recherche de code, la version v4 obtient un score de 71,59 sur CoIR contre 55,07 pour la version v3 (amélioration de 30 %), tandis que les performances sur les documents longs montrent la version v4 à 67,11 contre 55,66 pour la version v3 sur LongEmbed (amélioration de 21 %). L'augmentation substantielle devient justifiée lorsque l'on considère les capacités multimodales de la version v4 : atteindre 84,11 nDCG@5 sur la recherche de documents visuels (Jina-VDR) et 90,17 sur les benchmarks ViDoRe - des capacités totalement absentes dans la version v3. L'augmentation des paramètres représente donc notre investissement dans la fonctionnalité multimodale tout en maintenant des performances de texte compétitives, avec l'architecture unifiée éliminant le besoin de modèles de texte et de vision séparés tout en atteignant un alignement intermodal de 0,71 contre 0,15 pour les approches traditionnelles à double encodeur.
tagGetting Started
Pour une vérification rapide, essayez notre démo texte-image dans la boîte à outils Search Foundation. Nous avons préparé une collection d'images de documents provenant de notre site Web, et vous pouvez également ajouter vos propres URL d'images. Tapez simplement votre requête et appuyez sur Entrée pour voir les résultats classés. Vous pouvez les récupérer comme de la reconnaissance optique de caractères (OCR) ou de la recherche d'images basée sur le contenu - n'hésitez pas non plus à essayer des requêtes dans des langues autres que l'anglais.
The demo is available at: https://jina.ai/api-dashboard/m0-image-rerank Please note that using this demo will consume your primary API key's tokens. Also the demo might seem a bit slow since it needs to download all images on the server from those URLs, and no cache is implemented for images.
tagVia API
Le code ci-dessous montre comment utiliser jina-embeddings-v4. Vous pouvez transmettre une chaîne de texte, une image codée en base64 ou une URL d'image. Les nouveaux utilisateurs peuvent obtenir une clé API Jina avec 10 millions de 词元 (Tokens) gratuits.
curl https://api.jina.ai/v1/embeddings \
-H "Content-Type: application/json" \
-H "Authorization: Bearer JINA_API_KEY" \
-d @- <<EOFEOF
{
"model": "jina-embeddings-v4",
"task": "text-matching",
"input": [
{
"text": "A beautiful sunset over the beach"
},
{
"text": "Un beau coucher de soleil sur la plage"
},
{
"text": "海滩上美丽的日落"
},
{
"text": "浜辺に沈む美しい夕日"
},
{
"image": "https://i.ibb.co/nQNGqL0/beach1.jpg"
},
{
"image": "https://i.ibb.co/r5w8hG8/beach2.jpg"
},
{
"image": "iVBORw0KGgoAAAANSUhEUgAAABwAAAA4CAIAAABhUg/jAAAAMklEQVR4nO3MQREAMAgAoLkoFreTiSzhy4MARGe9bX99lEqlUqlUKpVKpVKpVCqVHksHaBwCA2cPf0cAAAAASUVORK5CYII="
}
]
}
EOFEOF
En raison de ressources GPU limitées, notre API d'向量模型 (Embeddings) prend actuellement en charge les documents d'une longueur maximale de 8 000 词元 (Tokens), bien que jina-embeddings-v4 puisse nativement traiter jusqu'à 32 000 词元 (Tokens). Pour les applications nécessitant des contextes plus longs que 8 000 词元 (Tokens) (telles que le Late Chunking), nous vous recommandons de déployer nos modèles via des CSP ou d'auto-héberger le modèle.
tagVia les places de marché CSP
jina-embeddings-v4 sera bientôt disponible directement sur AWS, Azure et GCP aux prix qui y sont indiqués.
tagVia HuggingFace
À des fins de recherche et d'expérimentation, vous pouvez utiliser le modèle localement à partir de notre page Hugging Face. Nous avons préparé un bloc-notes Google Colab qui montre comment cela fonctionne.

tagConclusion
jina-embeddings-v4 représente notre avancée la plus significative à ce jour : un modèle d'向量模型 (Embedding) universel de 3,8 milliards de paramètres qui traite le texte et les images via un chemin unifié, prenant en charge la récupération dense et à interaction tardive tout en surpassant les modèles propriétaires de Google, OpenAI et Voyage AI, en particulier pour la récupération de documents riches en visuels. Mais cette capacité n'est pas apparue isolément ; elle est l'aboutissement de quatre générations de résolution des limitations fondamentales.
Lorsque nous avons commencé avec jina-embeddings-v1
au début de 2022, tout le monde supposait que davantage de données signifiait de meilleures performances. Nous avons prouvé le contraire : le filtrage de 1,5 milliard de paires à 385 millions d'exemples de haute qualité a surpassé des ensembles de données beaucoup plus volumineux. La leçon : la conservation bat la collecte.

Mais les utilisateurs continuaient de se heurter au mur des 512 词元 (Tokens) de BERT. L'apprentissage sur des séquences plus longues semblait coûteux, jusqu'à ce que jina-embeddings-v2
révèle une solution élégante : apprendre court, déployer long. Les biais d'attention linéaire d'ALiBi permettent aux modèles appris sur 512 词元 (Tokens) de gérer de manière transparente 8 192 词元 (Tokens) lors de l'inférence. Nous avons obtenu plus de capacités pour moins de calcul.

Le succès de jina-embeddings-v2
a mis en évidence une autre contrainte : différentes tâches nécessitaient différentes optimisations. Plutôt que de construire des modèles distincts, jina-embeddings-v3 a utilisé de minuscules adaptateurs LoRA de 60M pour personnaliser un modèle de base de 570M pour n'importe quelle tâche. Un modèle est devenu cinq modèles spécialisés.

Même avec la spécialisation des tâches, nous sommes restés axés sur le texte, tandis que les utilisateurs avaient besoin d'une compréhension visuelle. Les modèles standard basés sur CLIP comme jina-clip-v1 et jina-clip-v2 utilisent des encodeurs distincts, créant un « écart de modalité » où un contenu similaire dans différents formats finit par être éloigné. Comme notre jina-reranker-m0 récemment publié, jina-embeddings-v4 a complètement éliminé cet écart : un seul chemin unifié traite tout, supprimant l'écart plutôt que de le combler.

jina-embeddings-v4 et jina-reranker-m0 partagent un changement fondamental : l'utilisation de 大模型 (LLM) comme backbones au lieu de modèles à encodeur uniquement. Ce n'est pas une coïncidence : cela reflète un avantage profond que la plupart manquent : les modèles à encodeur uniquement créent des « écarts de modalité » où les images se regroupent séparément du texte. Les modèles à décodeur uniquement ouvrent des possibilités qui n'étaient pas réalisables avec les architectures à encodeur uniquement, y compris la véritable représentation mixte de la modalité et l'explicabilité.
Notre principale idée : les vecteurs modèles (Embeddings) et la génération concernent tous deux la compréhension de la sémantique. Les grands modèles de langage (LLM) qui excellent dans la génération excellent naturellement dans la représentation. Nous pensons que l'avenir réside dans des architectures unifiées où les vecteurs modèles (embedding) et le réordonnancement (reranking) émergent du même modèle de base de recherche, et c'est exactement ce vers quoi Jina AI s'oriente.
{{{output start}}}