


Heute veröffentlichen wir jina-embeddings-v4, unser neues universelles 向量模型 (Embedding)-Modell mit 3,8 Milliarden Parametern für Text und Bilder. Es enthält eine Reihe von aufgabenspezifischen LoRA-Adaptern, die die Leistung für die beliebtesten Abrufaufgaben optimieren, darunter Abfrage-Dokument-Abruf, semantisches Matching und Codesuche. jina-embeddings-v4 erzielt hochmoderne Abrufleistungen bei multimodalen und mehrsprachigen Aufgaben in den Benchmarks MTEB, MMTEB, CoIR, LongEmbed, STS, Jina-VDR, CLIP und ViDoRe, mit besonderer Stärke bei der Verarbeitung von visuell reichhaltigen Inhalten wie Tabellen, Diagrammen, Grafiken und deren Mischung. Das Modell unterstützt sowohl Einzelvektor- als auch Multivektoreinbettungen.

jina-embeddings-v4 ist unser bisher ehrgeizigstes Einbettungsmodell. Als Open-Source-Modell übertrifft jina-embeddings-v4 die führenden proprietären Einbettungsmodelle der großen Anbieter und liefert eine um 12 % bessere Leistung als text-embedding-3-large
von OpenAI beim mehrsprachigen Abruf (66,49 vs. 59,27), eine um 28 % bessere Leistung bei Aufgaben mit langen Dokumenten (67,11 vs. 52,42), 15 % besser als voyage-3
beim Code-Abruf (71,59 vs. 67,23) und entspricht der Leistung von gemini-embedding-001
von Google. Dies macht v4 zum leistungsfähigsten Open-Source-Universal-Einbettungsmodell, das heute verfügbar ist und Forschern und Entwicklern multimodale Einbettungsfunktionen in Unternehmensqualität mit vollständiger Transparenz hinsichtlich des Trainingsprozesses, der Architekturentscheidungen und der Modellgewichte durch unseren umfassenden technischen Bericht bietet.

tagNeue Architektur
Qwen2.5-VL-3B-Instruct
Backbone (3,8 Milliarden Parameter). Text- und Bildeingaben werden über einen gemeinsamen Pfad verarbeitet: Bilder werden zuerst über einen Vision Encoder in Token-Sequenzen konvertiert, dann werden beide Modalitäten gemeinsam vom Sprachmodell-Decoder mit kontextbezogenen Aufmerksamkeits-Layern verarbeitet. Drei aufgabenspezifische LoRA-Adapter (jeweils 60 Millionen Parameter) bieten eine spezialisierte Optimierung für Abruf-, Text-Matching- und Codeaufgaben, ohne die eingefrorenen Backbone-Gewichte zu verändern. Die Architektur unterstützt zwei Ausgabemodi: (1) Einzelvektor-Einbettungen (2048 Dimensionen, auf 128 trunkierbar), die über Mean Pooling für eine effiziente Ähnlichkeitssuche generiert werden, und (2) Multivektor-Einbettungen (128 Dimensionen pro Token) über Projektions-Layer für Late-Interaction-Abrufstrategien.Das Upgrade von jina-embeddings-v3 zujina-embeddings-v4 stellt einen Paradigmenwechsel von reinen Text- zu multimodalen Vektormodellen (Embeddings) dar. Während sich v3 auf die Optimierung von Text-Vektormodellen (Embeddings) mit aufgabenspezifischen LoRA-Adaptern konzentrierte, adressiert v4 die wachsende Anforderung, sowohl textuelle als auch visuelle Inhalte in einheitlichen Darstellungen einzubetten.
Aspekt | <strong>jina-embeddings-v3</strong> | <strong>jina-embeddings-v4</strong> |
---|---|---|
Backbone Modell | jina-XLM-RoBERTa | Qwen2.5-VL-3B-Instruct |
Parameter (Basis) | 559M | 3.8B |
Parameter (mit Adaptern) | 572M | 3.8B + 60M pro Adapter |
Modalitäten | Nur Text | Text + Bilder (multimodal) |
Maximale Eingabelänge | 8.192 Tokens (词元) | 32.768 Tokens (词元) |
Bildverarbeitung | Keine | Bis zu 20 Megapixel, visuell reichhaltige Dokumente |
Mehrsprachige Unterstützung | 89 Sprachen | 29+ Sprachen |
Vektortypen | Nur Einzelvektor | Einzelvektor + Multivektor (späte Interaktion) |
Einzelvektor-Dimensionen | 1024 (MRL auf 32 verkürzbar) | 2048 (MRL auf 128 verkürzbar) |
Multivektor-Dimensionen | Nicht verfügbar | 128 pro Token (词元) |
Task-LoRA-Spezialisierungen | • Asymmetrische Suche • Semantische Ähnlichkeit • Klassifizierung • Trennung |
• Asymmetrische Suche • Semantische Ähnlichkeit • Code-Suche |
Trainingsphasen | 3-phasig: Vortraining → Vektormodell (Embedding) Feintuning → Adaptertraining | 2-phasig: Gemeinsames Paar-Training → Aufgabenspezifisches Adaptertraining |
Loss-Funktionen | InfoNCE, CoSent, Erweiterter Triplet-Loss | Gemeinsames InfoNCE + KL-Divergenz für Einzel-/Multivektor |
Positionelle Kodierung | RoPE (rotatorische Basisfrequenzabstimmung) | M-RoPE (Multimodales rotatorisches Position Embedding) |
Cross-modale Verarbeitung | N/A | Einheitlicher Encoder (reduzierter Modalitätsabstand) |
MRL Unterstützung | Ja | Ja |
Attention Implementierung | FlashAttention2 | FlashAttention2 |
tagBackbone
Die bedeutendste architektonische Änderung in v4 ist die Änderung des Backbones von XLM-RoBERTa
zu Qwen2.5-VL-3B-Instruct
. Diese Entscheidung wurde durch das Kernziel von v4 getrieben, ein universelles Vektormodell (Embedding) zu erstellen, das "echte multimodale Verarbeitung" ermöglicht, bei der Bilder in Token (词元)-Sequenzen umgewandelt und zusammen mit Text verarbeitet werden, wodurch die Modalitätslücke beseitigt wird, die in Dual-Encoder-Architekturen vorhanden ist.
Die Auswahl des Backbones steht im Einklang mit mehreren wichtigen Designzielen: Die Exzellenz von Qwen2.5-VL im Dokumentenverständnis unterstützt direkt die Stärke von v4 bei der Verarbeitung visuell reichhaltiger Inhalte wie Tabellen, Diagramme und Screenshots. Die dynamischen Auflösungsfunktionen ermöglichen es v4, Bilder zu verarbeiten, die auf 20 Megapixel skaliert wurden, wie in der Architektur angegeben. Die fortschrittliche positionelle Kodierung bietet die Grundlage, die es v4 ermöglicht, eine überlegene cross-modale Ausrichtung mit einem Alignment-Score von 0,71 im Vergleich zu 0,15 für OpenAI CLIP zu erreichen.
tagLoRA Adapters
V4 optimiert von den fünf Aufgaben von v3 auf drei fokussierte Aufgaben, was die gewonnenen Erkenntnisse über Effektivität und Benutzerakzeptanz widerspiegelt:
- Asymmetrische Suche (Konsolidierung der Abfrage-/Passagenadapter von v3)
- Symmetrische Ähnlichkeit (das Text-Matching-Äquivalent von v3 für STS-Aufgaben)
- Code-Suche (gelernt von v2-code, fehlend in v3)
Diese Konsolidierung entfernt die Klassifizierungs- und Trennungsadapter von v3 und konzentriert v4 auf die wirkungsvollsten Anwendungsfälle für Vektormodelle (Embeddings) - Suche und STS.
tagOutput Embeddings
V4 führt ein Dual-Output-System ein, das sowohl Einzelvektor- als auch Multivektor-Vektormodelle (Embeddings) unterstützt, während v3 nur Einzelvektor-Outputs bereitstellte. Dies adressiert verschiedene Suchszenarien:
- Einzelvektor-Modus: 2048-dimensionale Vektormodelle (Embeddings) (über MRL auf 128 verkürzbar) für effiziente Ähnlichkeitssuche
- Multivektor-Modus: 128 Dimensionen pro Token (词元) für Late-Interaction Retrieval
Dieser duale Ansatz bietet eine höhere Effektivität mit Multivektor-Darstellungen, insbesondere bei der Suche in visuell reichhaltigen Dokumenten, und behält gleichzeitig die Effizienz für Standard-Ähnlichkeitsaufgaben bei. Der konsistente Leistungsvorteil von 7-10 % von Multivektor gegenüber Einzelvektor im visuellen Aufgabenbereich deutet darauf hin, dass die späte Interaktion eine grundlegend bessere semantische Übereinstimmung für multimodale Inhalte bietet.
tagParameter Size
Während v4 6,7-mal größer ist als v3 (3,8B vs. 570M Parameter), sind die Leistungsverbesserungen bei reinen Texten tatsächlich gering, was darauf hindeutet, dass die Parameterskalierung in erster Linie durch multimodale Anforderungen und nicht durch Textverbesserung bedingt war. Auf den wichtigsten Text-Benchmarks erreicht v4 66,49 auf MMTEB im Vergleich zu 58,58 von v3 (14 % Verbesserung) und 55,97 auf MTEB-EN gegenüber 54,33 von v3 (3 % Verbesserung). Für die Code-Suche erzielt v4 71,59 auf CoIR im Vergleich zu 55,07 von v3 (30 % Verbesserung), während die Leistung bei langen Dokumenten v4 mit 67,11 gegenüber 55,66 von v3 auf LongEmbed zeigt (21 % Verbesserung). Die erhebliche Skalierung wird gerechtfertigt, wenn man die multimodalen Fähigkeiten von v4 berücksichtigt: Erreichen von 84,11 nDCG@5 bei der Suche nach visuellen Dokumenten (Jina-VDR) und 90,17 bei ViDoRe-Benchmarks - Fähigkeiten, die in v3 vollständig fehlen. Die Parametererhöhung stellt somit unsere Investition in die multimodale Funktionalität dar, während die Textleistung wettbewerbsfähig bleibt, wobei die einheitliche Architektur die Notwendigkeit separater Text- und Visionsmodelle eliminiert und gleichzeitig eine cross-modale Ausrichtung von 0,71 im Vergleich zu 0,15 für traditionelle Dual-Encoder-Ansätze erreicht wird.
tagErste Schritte
Für einen schnellen Vibe-Check probieren Sie unsere Text-zu-Bild-Demo in der Search Foundation-Toolbox aus. Wir haben eine Sammlung von Dokumentenbildern von unserer Website vorbereitet, und Sie können auch Ihre eigenen Bild-URLs hinzufügen. Geben Sie einfach Ihre Abfrage ein und drücken Sie die Eingabetaste, um die sortierten Ergebnisse anzuzeigen. Sie können sie entweder wie OCR oder inhaltsbasierte Bildersuche zurückziehen - Sie können auch Abfragen in nicht-englischer Sprache ausprobieren.
Die Demo ist verfügbar unter: https://jina.ai/api-dashboard/m0-image-rerank Bitte beachten Sie, dass die Verwendung dieser Demo die Tokens (词元) Ihres primären API-Schlüssels verbraucht. Auch die Demo scheint etwas langsam zu sein, da sie alle Bilder auf dem Server von diesen URLs herunterladen muss und kein Cache für Bilder implementiert ist.
tagVia API
Der folgende Code zeigt, wie jina-embeddings-v4 verwendet wird. Sie können eine Textzeichenfolge, ein Base64-kodiertes Bild oder eine Bild-URL übergeben. Neue Benutzer können einen Jina API-Schlüssel mit 10 Millionen kostenlosen Tokens (词元) erhalten.
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
Aufgrund begrenzter GPU-Ressourcen unterstützt unsere Embedding API derzeit Dokumente mit einer Länge von bis zu 8.000 Tokens (Tokens), obwohl jina-embeddings-v4 nativ bis zu 32.000 Tokens verarbeiten kann. Für Anwendungen, die längere Kontexte als 8.000 Tokens erfordern (wie z. B. Late Chunking), empfehlen wir, unsere Modelle über CSPs bereitzustellen oder das Modell selbst zu hosten.
tagÜber CSP-Marktplätze
jina-embeddings-v4 wird in Kürze direkt auf AWS, Azure und GCP zu den dort aufgeführten Preisen verfügbar sein.
tagÜber HuggingFace
Für Forschungs- und Experimentierzwecke können Sie das Modell lokal von unserer Hugging Face-Seite aus verwenden. Wir haben ein Google Colab-Notebook vorbereitet, das die Funktionsweise demonstriert.

tagFazit
jina-embeddings-v4 stellt unseren bisher bedeutendsten Sprung dar – ein universelles 向量模型 (Embedding)-Modell mit 3,8 Milliarden Parametern, das Text und Bilder über einen einheitlichen Pfad verarbeitet und sowohl dichte als auch Late-Interaction-Retrieval unterstützt, während es proprietäre Modelle von Google, OpenAI und Voyage AI insbesondere beim visuell ansprechenden Dokumentenabruf übertrifft. Diese Fähigkeit entstand jedoch nicht isoliert; sie ist der Höhepunkt von vier Generationen der Lösung grundlegender Einschränkungen.
Als wir Anfang 2022 mit jina-embeddings-v1
begannen, ging jeder davon aus, dass mehr Daten eine bessere Leistung bedeuten. Wir haben das Gegenteil bewiesen – das Filtern von 1,5 Milliarden Paaren auf 385 Millionen hochwertige Beispiele übertraf viel größere Datensätze. Die Lektion: Kuration schlägt Sammlung.

Aber die Benutzer stießen immer wieder auf die 512-Token-Grenze von BERT. Das Training mit längeren Sequenzen schien teuer, bis jina-embeddings-v2
eine elegante Lösung offenbarte: kurz trainieren, lang bereitstellen. Die linearen Aufmerksamkeitsverzerrungen von ALiBi ermöglichen es Modellen, die auf 512 Tokens trainiert wurden, nahtlos 8.192 Tokens bei der Inferenz zu verarbeiten. Wir haben mehr Leistung für weniger Rechenaufwand bekommen.

Der Erfolg von jina-embeddings-v2
legte eine weitere Einschränkung offen – verschiedene Aufgaben erforderten unterschiedliche Optimierungen. Anstatt separate Modelle zu erstellen, verwendete jina-embeddings-v3 winzige 60M LoRA-Adapter, um ein 570M-Basismodell für jede Aufgabe anzupassen. Aus einem Modell wurden fünf spezialisierte Modelle.

Selbst mit Aufgabenspezialisierung blieben wir auf Text beschränkt, während Benutzer ein visuelles Verständnis benötigten. Die Standard-CLIP-basierten Modelle wie jina-clip-v1 und jina-clip-v2 verwenden separate Encoder, wodurch eine "Modalitätslücke" entsteht, in der ähnliche Inhalte in verschiedenen Formaten weit voneinander entfernt landen. Wie unser kürzlich veröffentlichter jina-reranker-m0, eliminierte jina-embeddings-v4 dies vollständig – ein einheitlicher Pfad verarbeitet alles und beseitigt die Lücke, anstatt sie zu überbrücken.

Sowohl jina-embeddings-v4 als auch jina-reranker-m0 teilen eine grundlegende Verschiebung: die Verwendung von LLMs (LLM) als Backbones anstelle von reinen Encoder-Modellen. Dies ist kein Zufall – es spiegelt einen tiefgreifenden Vorteil wider, den die meisten übersehen: Reine Encoder-Modelle erzeugen "Modalitätslücken", in denen Bilder getrennt von Text gruppiert werden. Die reinen Decoder-Modelle eröffnen Möglichkeiten, die mit reinen Encoder-Architekturen nicht erreichbar waren, einschließlich echter Mixed-Modalitäts-Darstellung und Erklärbarkeit.
Unsere wichtigste Erkenntnis: Sowohl bei Vektor Modellen (Embeddings) als auch bei der Generierung geht es um das Verständnis von Semantik. LLMs, die sich durch Generierung auszeichnen, zeichnen sich naturgemäß auch durch Repräsentation aus. Wir glauben, dass die Zukunft in einheitlichen Architekturen liegt, in denen Vektor Modelle (Embedding) und das Reranking aus demselben Suchgrundlagenmodell hervorgehen – und genau darauf arbeitet Jina AI hin.