


Hoy lanzamos jina-embeddings-v4, nuestro nuevo modelo de "embedding" universal de 3.8 mil millones de parámetros para texto e imágenes. Incluye un conjunto de adaptadores LoRA específicos de la tarea que optimizan el rendimiento para las tareas de recuperación más populares, incluida la recuperación de consulta-documento, la coincidencia semántica y la búsqueda de código. jina-embeddings-v4 logra un rendimiento de recuperación de vanguardia en tareas multimodales y multilingües en los puntos de referencia MTEB, MMTEB, CoIR, LongEmbed, STS, Jina-VDR, CLIP y ViDoRe, con una fortaleza particular en el procesamiento de contenido visualmente rico, como tablas, gráficos, diagramas y mezclas de ellos. El modelo admite "embeddings" de un solo vector y de múltiples vectores.

jina-embeddings-v4 es nuestro modelo de "embedding" más ambicioso hasta el momento. Como modelo de código abierto, jina-embeddings-v4 supera a los principales modelos de "embedding" de código cerrado de los principales proveedores, ofreciendo un rendimiento un 12% mejor que text-embedding-3-large
de OpenAI en la recuperación multilingüe (66.49 frente a 59.27), una mejora del 28% en las tareas de documentos largos (67.11 frente a 52.42), un 15% mejor que voyage-3
en la recuperación de código (71.59 frente a 67.23) e igualando el rendimiento de gemini-embedding-001
de Google. Esto convierte a v4 en el modelo de "embedding" universal de código abierto más capaz disponible en la actualidad, que ofrece a los investigadores y desarrolladores capacidades de "embedding" multimodal de nivel empresarial con total transparencia en el proceso de entrenamiento, las decisiones arquitectónicas y los pesos del modelo a través de nuestro informe técnico completo.

tagNueva Arquitectura
Qwen2.5-VL-3B-Instruct
(3.8B parámetros). Las entradas de texto e imagen se procesan a través de una vía compartida: las imágenes primero se convierten en secuencias de "tokens" a través de un codificador de visión, luego ambas modalidades se procesan conjuntamente mediante el decodificador del modelo de lenguaje con capas de atención contextual. Tres adaptadores LoRA específicos de la tarea (60 millones de parámetros cada uno) proporcionan una optimización especializada para las tareas de recuperación, coincidencia de texto y código sin modificar los pesos de la base congelada. La arquitectura admite modos de salida dual: (1) "embeddings" de un solo vector (2048 dimensiones, truncables a 128) generados a través de la agrupación media para una búsqueda de similitud eficiente, y (2) "embeddings" de múltiples vectores (128 dimensiones por "token") a través de capas de proyección para estrategias de recuperación de interacción tardía.La actualización de jina-embeddings-v3 ajina-embeddings-v4 representa un cambio de paradigma desde los modelos de 向量模型 (Embeddings) que solo utilizaban texto, hacia los modelos multimodales. Mientras que v3 se centraba en optimizar los 向量模型 (Embeddings) de texto con adaptadores LoRA específicos para cada tarea, v4 aborda la creciente necesidad de integrar contenido textual y visual en representaciones unificadas.
Aspecto | <strong>jina-embeddings-v3</strong> | <strong>jina-embeddings-v4</strong> |
---|---|---|
Modelo Base | jina-XLM-RoBERTa | Qwen2.5-VL-3B-Instruct |
Parámetros (Base) | 559M | 3.8B |
Parámetros (con adaptadores) | 572M | 3.8B + 60M por adaptador |
Modalidades | Solo texto | Texto + Imágenes (multimodal) |
Longitud Máxima de Entrada | 8,192 词元 (Tokens) | 32,768 词元 (Tokens) |
Procesamiento de Imágenes | Ninguno | Hasta 20 megapíxeles, documentos visualmente ricos |
Soporte Multilingüe | 89 idiomas | 29+ idiomas |
Tipos de Vectores | Solo vector único | Vector único + Multi-vector (interacción tardía) |
Dimensiones del Vector Único | 1024 (MRL truncable a 32) | 2048 (MRL truncable a 128) |
Dimensiones del Multi-vector | No disponible | 128 por 词元 (Token) |
Especializaciones LoRA por Tarea | • Recuperación asimétrica • Similitud semántica • Clasificación • Separación |
• Recuperación asimétrica • Similitud semántica • Recuperación de código |
Etapas de Entrenamiento | 3 etapas: Pre-entrenamiento → Ajuste fino del 向量模型 (Embedding) → Entrenamiento del adaptador | 2 etapas: Entrenamiento de pares conjuntos → Entrenamiento del adaptador específico para la tarea |
Funciones de Pérdida | InfoNCE, CoSent, Pérdida de tripletes extendida | InfoNCE conjunto + Divergencia KL para vector único/múltiple |
Codificación Posicional | RoPE (ajuste de frecuencia base rotatoria) | M-RoPE (Codificación Posicional Rotatoria Multimodal) |
Procesamiento Intermodal | N/A | Codificador unificado (brecha de modalidad reducida) |
Soporte MRL | Sí | Sí |
Implementación de Atención | FlashAttention2 | FlashAttention2 |
tagBackbone
El cambio arquitectónico más significativo en v4 es el cambio del backbone de XLM-RoBERTa
a Qwen2.5-VL-3B-Instruct
. Esta decisión fue impulsada por el objetivo central de v4 de crear un modelo de 向量模型 (Embedding) universal que permita el "verdadero procesamiento multimodal" donde las imágenes se convierten en secuencias de 词元 (Tokens) y se procesan junto con el texto, eliminando la brecha de modalidad presente en las arquitecturas de codificador dual.
La selección del backbone se alinea con varios objetivos de diseño clave: la excelencia de Qwen2.5-VL en la comprensión de documentos apoya directamente la fortaleza de v4 en el procesamiento de contenido visualmente rico como tablas, gráficos y capturas de pantalla. Las capacidades de resolución dinámica permiten a v4 manejar imágenes redimensionadas a 20 megapíxeles como se especifica en la arquitectura. La codificación posicional avanzada proporciona la base que permite a v4 lograr una alineación intermodal superior con una puntuación de alineación de 0.71 en comparación con 0.15 para OpenAI CLIP.
tagAdaptadores LoRA
V4 se simplifica de las cinco tareas de v3 a tres tareas enfocadas, lo que refleja las lecciones aprendidas sobre la efectividad y la adopción por parte del usuario:
- Recuperación asimétrica (consolidando los adaptadores de consulta/pasaje de v3)
- Similitud simétrica (el equivalente de coincidencia de texto de v3 para las tareas STS)
- Recuperación de código (aprendido de v2-code, ausente en v3)
Esta consolidación elimina los adaptadores de clasificación y separación de v3, enfocando v4 en los casos de uso de 向量模型 (Embedding) de mayor impacto: la recuperación y STS.
tagOutput Embeddings
V4 introduce un sistema de salida dual que soporta tanto 向量模型 (Embeddings) de vector único como multi-vector, mientras que v3 solo proporcionaba salidas de vector único. Esto aborda diferentes escenarios de recuperación:
- Modo de vector único: 向量模型 (Embeddings) de 2048 dimensiones (truncables a 128 a través de MRL) para una búsqueda de similitud eficiente
- Modo multi-vector: 128 dimensiones por 词元 (Token) para la recuperación de interacción tardía
Este enfoque dual proporciona una mayor eficacia con representaciones multi-vectoriales, particularmente en la recuperación de documentos visualmente ricos, manteniendo la eficiencia para las tareas de similitud estándar. La ventaja de rendimiento constante del 7-10% del modo multi-vector sobre el modo de vector único en las tareas visuales sugiere que la interacción tardía proporciona una coincidencia semántica fundamentalmente mejor para el contenido multimodal.
tagParameter Size
Si bien v4 es 6.7 veces más grande que v3 (3.8B vs 570M parámetros), las mejoras de rendimiento solo en texto son en realidad modestas, lo que sugiere que el escalamiento de parámetros fue impulsado principalmente por los requisitos multimodales en lugar de la mejora de texto. En los puntos de referencia de texto centrales, v4 alcanza 66.49 en MMTEB en comparación con los 58.58 de v3 (mejora del 14%) y 55.97 en MTEB-EN versus los 54.33 de v3 (mejora del 3%). Para la recuperación de código, v4 obtiene 71.59 en CoIR en comparación con los 55.07 de v3 (mejora del 30%), mientras que el rendimiento de documentos largos muestra v4 en 67.11 versus los 55.66 de v3 en LongEmbed (mejora del 21%). El escalamiento sustancial se justifica al considerar las capacidades multimodales de v4: alcanzar 84.11 nDCG@5 en la recuperación de documentos visuales (Jina-VDR) y 90.17 en los puntos de referencia de ViDoRe, capacidades totalmente ausentes en v3. El aumento de parámetros representa así nuestra inversión en la funcionalidad multimodal manteniendo un rendimiento de texto competitivo, con la arquitectura unificada eliminando la necesidad de modelos separados de texto y visión al tiempo que se logra una alineación intermodal de 0.71 en comparación con 0.15 para los enfoques tradicionales de codificador dual.
tagEmpezando
Para una verificación rápida, pruebe nuestra demostración de texto a imagen en la caja de herramientas de Search Foundation. Hemos preparado una colección de imágenes de documentos de nuestro sitio web, y también puede agregar sus propias URL de imágenes. Simplemente escriba su consulta y presione enter para ver los resultados clasificados. Puede retirarlo ya sea como OCR o recuperación de imágenes basada en contenido; también siéntase libre de probar consultas en idiomas que no sean inglés.
La demostración está disponible en: https://jina.ai/api-dashboard/m0-image-rerank Tenga en cuenta que el uso de esta demostración consumirá los 词元 (Tokens) de su clave API principal. Además, la demostración puede parecer un poco lenta, ya que necesita descargar todas las imágenes en el servidor desde esas URL, y no se implementa el almacenamiento en caché para las imágenes.
tagA través de la API
El código a continuación muestra cómo usar jina-embeddings-v4. Puede pasar una cadena de texto, una imagen codificada en base64 o una URL de imagen. Los nuevos usuarios pueden obtener una clave API de Jina con 10 millones de 词元 (Tokens) gratuitos.
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
Debido a los recursos limitados de la GPU, nuestra API de Vectorización (Embedding API) actualmente admite documentos de hasta 8K *tokens* (Tokens) de longitud, a pesar de la capacidad nativa de jina-embeddings-v4 para manejar hasta 32K *tokens* (Tokens). Para las aplicaciones que requieren contextos más largos de 8K *tokens* (Tokens) (como Late Chunking), recomendamos implementar nuestros modelos a través de CSP o auto alojar el modelo.
tagA través de los mercados de CSP
jina-embeddings-v4 pronto estará disponible directamente en AWS, Azure y GCP a los precios que se indican allí.
tagA través de HuggingFace
Para fines de investigación y experimentación, puede utilizar el modelo localmente desde nuestra página de Hugging Face. Hemos preparado un cuaderno de Google Colab que demuestra cómo funciona.

tagConclusión
jina-embeddings-v4 representa nuestro salto más significativo hasta el momento: un modelo de *vectorización* (embedding) universal de 3.8 mil millones de parámetros que procesa texto e imágenes a través de una vía unificada, que admite la recuperación densa y de interacción tardía, al tiempo que supera a los modelos propietarios de Google, OpenAI y Voyage AI, especialmente en la recuperación de documentos visualmente ricos. Pero esta capacidad no surgió de forma aislada; es la culminación de cuatro generaciones de resolución de limitaciones fundamentales.
Cuando comenzamos con jina-embeddings-v1
a principios de 2022, todos asumieron que más datos significaban un mejor rendimiento. Demostramos lo contrario: filtrar 1.5 mil millones de pares a 385 millones de ejemplos de alta calidad superó a conjuntos de datos mucho más grandes. La lección: la selección supera a la recopilación.

Pero los usuarios seguían topándose con el muro de 512 *tokens* (Tokens) de BERT. El entrenamiento en secuencias más largas parecía costoso, hasta que jina-embeddings-v2
reveló una solución elegante: entrenar corto, implementar largo. Los sesgos de atención lineal de ALiBi permiten que los modelos entrenados en 512 *tokens* (Tokens) manejen sin problemas 8,192 *tokens* (Tokens) en la inferencia. Obtuvimos más capacidad por menos cómputo.

El éxito de jina-embeddings-v2
expuso otra limitación: diferentes tareas necesitaban diferentes optimizaciones. En lugar de construir modelos separados, jina-embeddings-v3 utilizó pequeños adaptadores LoRA de 60M para personalizar un modelo base de 570M para cualquier tarea. Un modelo se convirtió en cinco modelos especializados.

Incluso con la especialización de tareas, seguimos siendo solo texto, mientras que los usuarios necesitaban comprensión visual. Los modelos estándar basados en CLIP como jina-clip-v1 y jina-clip-v2 utilizan codificadores separados, creando una "brecha de modalidad" donde el contenido similar en diferentes formatos termina muy separado. Al igual que nuestro recientemente lanzado jina-reranker-m0, jina-embeddings-v4 eliminó esto por completo: una vía unificada procesa todo, eliminando la brecha en lugar de salvarla.

Tanto jina-embeddings-v4 como jina-reranker-m0 comparten un cambio fundamental: el uso de *LLM* (LLM) como base en lugar de modelos de solo codificador. Esto no es una coincidencia, refleja una profunda ventaja que la mayoría pasa por alto: los modelos de solo codificador crean "brechas de modalidad" donde las imágenes se agrupan por separado del texto. Los modelos de solo decodificador abren posibilidades que no eran alcanzables con arquitecturas de solo codificador, incluida la verdadera representación de modalidad mixta y la explicabilidad.
Nuestra principal conclusión: los modelos de 向量模型 (embeddings) y la generación tratan sobre la comprensión de la semántica. Los 大模型 (LLM) que sobresalen en la generación, naturalmente, sobresalen en la representación. Creemos que el futuro reside en arquitecturas unificadas donde los modelos de 向量模型 (embedding) y el 重排器 (reranking) surgen del mismo modelo de base de búsqueda, y eso es exactamente hacia lo que Jina AI está construyendo.