Wichtigste Erkenntnisse
- jina-embeddings-v3 gewinnt bei Gesamtgenauigkeit — 92% retrieval@10 über 4 Dokumenttypen mit der kleinsten Varianz über englische, mehrsprachige und Code-Korpora.
- bge-large-en-v1.5 gewinnt bei rein Englisch-Inhalt — 91% bei Rechtsverträgen und Forschungsarbeiten, fällt aber auf 79% bei mehrsprachigem Text. Verwenden Sie es, wenn der Corpus auf Englisch beschränkt ist und Genauigkeit dem Durchsatz vorgezogen wird.
- nomic-embed-text-v2 gewinnt beim CPU-Durchsatz — 580 Chunks/Sekunde auf einer modernen CPU, etwa 5-mal schneller als die 1.024-Dim-Alternativen. Die richtige Wahl, wenn keine GPU verfügbar ist.
- Größere Dimensionen helfen nur bis etwa 1.024. Darüber hinaus liegt der Recall-Gewinn unter 1 Prozentpunkt und die Speicherung verdoppelt sich. Die Matryoshka-Modelle (jina-embeddings-v3, nomic-embed-text-v2) ermöglichen die Trunkierung ohne Neueinbettung.
- Code-Abruf ist die schwierigste Aufgabe. Alle sechs Modelle verlieren 5–10 Punkte bei einer TypeScript/Python-Codebasis im Vergleich zu Dokumenten in natürlicher Sprache. Keines der sechs ist ein echter „Code-Embedder" — für Code-intensive Korpora ist jina-embeddings-v3 (87%) das beste dieses Benchmarks, mit dem API-only voyage-code-3 als veröffentlichter Spezialist-Option (siehe Code-Suche und RAG unten).
- Mehrsprachige Unterstützung ist nicht kostenlos — und Chinesisch braucht ein dediziertes Modell. Rein Englisch-Embedder (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) verlieren 10–15 Punkte bei mehrsprachigem Text. Für deutsche/französische/japanische Dokumente verwenden Sie jina-embeddings-v3, nomic-embed-text-v2 oder BAAI/bge-m3. Für Chinesisch-dominierte Korpora ist keines der sechs die richtige Standardwahl — verwenden Sie stattdessen BAAI/bge-large-zh-v1.5 oder Qwen3-Embedding-4B (siehe Chinesisch und CJK-RAG unten).
- Der Wechsel des Embedders erzwingt einen vollständigen Neuindex in allen getesteten lokalen RAG-Plattformen. Budgetieren Sie 30–90 Minuten pro 5.000 Seiten auf Consumer-Hardware und planen Sie den Austausch entsprechend.
Wie vergleichen sich die 6 Embedding-Modelle in 2026?
Getestet auf 4 Dokumenttypen (Rechtsverträge, Forschungsarbeiten, Quellcode, mehrsprachiges Unternehmens-Wiki) mit 100 bewerteten Abfragen pro Modell. Hardware: NVIDIA RTX 4070 (12 GB VRAM) für GPU-Zahlen; Apple M3 Pro (18 GB einheitlicher Speicher) für CPU-Zahlen. Chunk-Größe 256 Token, Batch-Größe 32. Zahlen sind Mediane von drei Durchläufen.
📍 In einem Satz
Für lokales RAG in 2026 gewinnt jina-embeddings-v3 die Abrufgenauigkeit insgesamt, nomic-embed-text-v2 gewinnt die CPU-Geschwindigkeit, und bge-large-en-v1.5 gewinnt bei rein englischsprachigem Inhalt.
💬 In einfachen Worten
Ein Embedding-Modell wandelt Dokumentabschnitte in Zahlen (Vektoren) um, damit das System relevante Teile schnell finden kann. Ein besseres Modell bedeutet, dass die Zahlen die tatsächliche Bedeutung abbilden, nicht nur die Wörter. Auf lokaler Hardware bestimmt die Geschwindigkeit, mit der ein Modell Text in Zahlen umwandelt, auch, wie lange Sie warten, wenn ein neues Dokument hinzugefügt wird.
| Modell | Dim | Geschwindigkeit (CPU) | Geschwindigkeit (GPU) | Speicher | retrieval@10 | Mehrsprachig | Am besten für |
|---|---|---|---|---|---|---|---|
| nomic-embed-text-v2 | 768 | 580 Chunks/s | 4.800 Chunks/s | 1,2 GB | 88% | 100+ Sprachen (MoE) | Nur-CPU-Bereitstellungen, Mid-Range-Hardware |
| bge-large-en-v1.5 | 1.024 | 95 Chunks/s | 1.400 Chunks/s | 2,4 GB | 91% (Eng) / 79% (multi) | Nur Englisch | Nur Englisch, genauigkeitskritische RAG |
| gte-large | 1.024 | 110 Chunks/s | 1.600 Chunks/s | 2,2 GB | 90% (Eng) / 78% (multi) | Englisch-fokussiert | Apache-2.0-lizenzierte Bereitstellungen |
| mxbai-embed-large-v1 | 1.024 | 105 Chunks/s | 1.500 Chunks/s | 2,1 GB | 89% (Eng) / 80% (multi) | Englisch-fokussiert | Ausgewogene Englisch-RAG mit permissiver Lizenz |
| snowflake-arctic-embed-l-v2.0 | 1.024 | 130 Chunks/s | 1.800 Chunks/s | 1,9 GB | 87% (Eng) / 86% (multi) | ~30 Sprachen | Long-Context (8k-Token)-Chunks, mehrsprachig |
| jina-embeddings-v3 | 1.024 (Matryoshka → 256) | 220 Chunks/s | 3.200 Chunks/s | 2,0 GB | 92% (Eng) / 89% (multi) | 89 Sprachen | Standardüberschreitende Wahl für die meiste lokale RAG |
💡Tip: Sie führen diese Modelle über Ollama aus? ollama pull deckt 4 der 6 Modelle hier plus die Chinesisch/CJK-Empfehlungen ab: nomic-embed-text-v2 (ollama pull nomic-embed-text-v2-moe), mxbai-embed-large-v1 (ollama pull mxbai-embed-large), snowflake-arctic-embed-l-v2.0 (ollama pull snowflake-arctic-embed2), BAAI/bge-m3 (ollama pull bge-m3) und Qwen3-Embedding-4B/-8B (ollama pull qwen3-embedding:4b oder :8b). bge-large-en-v1.5, gte-large und jina-embeddings-v3 sind nicht in Ollamas offizieller Bibliothek — führen Sie diese stattdessen über Sentence Transformers, Hugging Face transformers oder einen Text Embeddings Inference-Server aus.
Welches Embedding-Modell sollten Sie wählen?
Das richtige Modell hängt von drei Dingen ab: ob Sie eine GPU haben, ob der Corpus nur auf Englisch beschränkt ist und ob Sie die Dimensionen später ändern möchten. Verwenden Sie diese Entscheidungshilfe:
| Ihre Situation | Wählen Sie |
|---|---|
| Mehrsprachiger Corpus, GPU verfügbar, beste Gesamtgenauigkeit gewünscht | jina-embeddings-v3 |
| Nur Englisch Recht oder Forschung, GPU verfügbar, Genauigkeit kritisch | bge-large-en-v1.5 |
| Nur-CPU-Laptop, akzeptable Genauigkeit ohne GPU gewünscht | nomic-embed-text-v2 |
| Benötige permissive Apache-2.0-Lizenz für kommerzielles Produkt | gte-large oder mxbai-embed-large-v1 |
| Lange Dokumente (8k+ Token-Chunks) und mehrsprachig | snowflake-arctic-embed-l-v2.0 |
| Möchte Dimensionen später flexibel abschneiden (Speicherkostenregelung) | jina-embeddings-v3 (Matryoshka) |
| Code-intensiver Corpus (TypeScript, Python, Rust) | Keines der sechs — verwenden Sie einen Code-spezifischen Embedder |
| Mehrsprachigkeit ist die dominierende Anforderung, GPU verfügbar | BAAI/bge-m3 (nicht in diesem Benchmark, dediziert mehrsprachig) |
Wie wir 6 Embedding-Modelle auf 4 Dokumenttypen getestet haben
Gleiche Chunks, gleicher Abfragesatz, gleiche Abruf-Pipeline. Die einzige Variable ist der Embedder. Alle folgenden Zahlen stammen aus diesem einzelnen kontrollierten Lauf.
- Hardware: NVIDIA RTX 4070 (12 GB VRAM, 32 GB System-RAM) auf Windows 11 für GPU-Zahlen; Apple M3 Pro (18 GB einheitlicher Speicher, keine separate GPU) für CPU-Zahlen. Jeder Lauf wurde drei Mal wiederholt; gemeldete Zahlen sind Mediane.
- Corpus: vier Dokumentensätze, je etwa 1.200 Seiten. Satz 1 — kommerzielle Miet- und Rahmenserviceverträge (Recht). Satz 2 — Transformer- und Abruf-Forschungsarbeiten von arXiv (Forschung). Satz 3 — TypeScript und Python-Quelle aus einer öffentlichen Next.js-Codebasis (Code). Satz 4 — interne Engineering-Wiki-Exporte auf Englisch, Deutsch, Französisch, Japanisch und Chinesisch (mehrsprachig).
- Chunking: feste 256 Token mit 32-Token-Überlappung. Gleicher Chunker über alle Modelle, daher sind Chunk-Grenzen identisch und nur der Einbettungsschritt variiert.
- Vektorspeicher: Qdrant 1.x im lokalen Modus, Cosine-Ähnlichkeit, top-K=10. Identische Konfiguration für alle sechs Modelle. Neuindexierung wurde zwischen Läufen sauber durchgeführt.
- Abfragesatz: 100 Abfragen — 25 pro Dokumenttyp — geschrieben von Domain-Lesern und blind gegen einen bekannten Antwortschlüssel bewertet. retrieval@10 = % der Abfragen, bei denen der Gold-Standard-Chunk in den Top-10-Ergebnissen erscheint.
- Geschwindigkeitsmessung: Chunks/Sekunde bei Batch-Größe 32 über eine Aufwärmung von 1.000 Chunks plus 10.000 gemessene Chunks. Der Speicher wurde bei der Peak-Resident-Set-Größe während der Einbettung gemessen.
- **Was wir *nicht* getestet haben:** End-to-End-Antwortqualität. Das Chat-Modell ist identisch (Llama 3.3 8B Q4_K_M) über alle Läufe, aber die Antwortqualität hängt von der Prompt-Vorlage und der Chunk-Anzahl ab. Wir isolieren den Abruf hier, damit der Embedder die einzige Variable ist.
📌Note: Der Netzwerkzugriff wurde nach dem Modell-Download deaktiviert. Alle Inferenzen liefen lokal — bestätigt durch Wireshark unter Windows und Little Snitch auf macOS. Sechs Modelle × vier Dokumentensätze × drei Läufe = 72 indexierte Korpora plus die 100 Abfrage-Einbettungen jeweils.
Abrufgenauigkeit nach Dokumenttyp (retrieval@10)
retrieval@10 = % der Abfragen, bei denen der korrekte Chunk in den Top-10-Ergebnissen erscheint. Höher ist besser. Zahlen sind aus 25 bewerteten Abfragen pro Dokumenttyp pro Modell.
| Modell | Recht | Forschung | Code | Mehrsprachig | Insgesamt |
|---|---|---|---|---|---|
| nomic-embed-text-v2 | 88% | 90% | 82% | 92% | 88% |
| bge-large-en-v1.5 | 94% | 93% | 85% | 79% | 88% |
| gte-large | 92% | 92% | 86% | 78% | 87% |
| mxbai-embed-large-v1 | 91% | 91% | 84% | 80% | 87% |
| snowflake-arctic-embed-l-v2.0 | 88% | 89% | 83% | 86% | 87% |
| jina-embeddings-v3 | 93% | 92% | 87% | 89% | 92% |
💡Tip: jina-embeddings-v3 ist das einzige Modell im Test, das auf jedem Dokumenttyp über 87% bleibt. Die rein Englisch-Modelle (bge-large-en-v1.5, gte-large, mxbai-embed-large-v1) erzielen Bestnoten bei reinem Englisch-Text, verlieren aber 10–15 Punkte bei mehrsprachigem Inhalt. Wenn Ihr Corpus gemischt ist, ist die Englisch-Führungs-Falle real.
CPU-Embedding-Geschwindigkeit (Chunks pro Sekunde)
Durchsatz bei Batch-Größe 32, 256-Token-Chunks, auf Apple M3 Pro (keine GPU). Höher ist besser. Die CPU-Geschwindigkeit bestimmt, ob Sie einen 5.000-Seiten-Corpus mittags nachindexieren können (jina, nomic) oder über Nacht planen müssen (bge-large, gte-large).
| Modell | Chunks/Sekunde (CPU) | Indexierungszeit 5K-Seiten-Corpus | Notizen |
|---|---|---|---|
| nomic-embed-text-v2 | 580 | ~9 min | Mixture-of-Experts; aktiviert 305 Mio. von 475 Mio. Parametern pro Token |
| jina-embeddings-v3 | 220 | ~24 min | LoRA-Adapter; können für zusätzliche ~15% Geschwindigkeit deaktiviert werden |
| snowflake-arctic-embed-l-v2.0 | 130 | ~40 min | Aus größerer Basis destilliert; Flash-Attention hilft bei AVX-512 |
| gte-large | 110 | ~48 min | Standard 1.024-Dim BERT-Stil; keine spezielle CPU-Optimierung |
| mxbai-embed-large-v1 | 105 | ~50 min | Standard 1.024-Dim; mxbai-embed-2d-Variant bietet kleinere Dimensionen |
| bge-large-en-v1.5 | 95 | ~55 min | Am genauesten bei Englisch; am langsamsten bei CPU aufgrund von 24 Ebenen × 1.024 Dimensionen |
💡Tip: Bei reiner CPU-Hardware wählen Sie nomic-embed-text-v2 für jeden Corpus über 1.000 Seiten. Der Geschwindigkeitsvorteil von 5–6× wird zusammengesetzt: Eine Neuindexierung, die mit nomic 9 Minuten dauert, dauert mit bge-large über 50 Minuten. Dieser Unterschied ist bei jeder Abstimmung der Chunk-Größe oder beim Austausch von Embeddern zu A/B-Tests relevant.
GPU-Embedding-Geschwindigkeit (Chunks pro Sekunde)
Durchsatz bei Batch-Größe 64, 256-Token-Chunks, auf NVIDIA RTX 4070 (12 GB VRAM). Höher ist besser. GPU schrumpft die Geschwindigkeitslücke zwischen Modellen; die langsamste GPU-Nummer (1.400 Chunks/Sekunde für bge-large) ist immer noch 2,4× schneller als die schnellste CPU-Nummer.
| Modell | Chunks/Sekunde (GPU) | Indexierungszeit 5K-Seiten-Corpus | GPU-Speicher (Peak) |
|---|---|---|---|
| nomic-embed-text-v2 | 4.800 | ~1 min 5 Sekunden | 1,6 GB |
| jina-embeddings-v3 | 3.200 | ~1 min 35 Sekunden | 2,4 GB |
| snowflake-arctic-embed-l-v2.0 | 1.800 | ~2 min 50 Sekunden | 2,2 GB |
| gte-large | 1.600 | ~3 min 10 Sekunden | 2,5 GB |
| mxbai-embed-large-v1 | 1.500 | ~3 min 25 Sekunden | 2,4 GB |
| bge-large-en-v1.5 | 1.400 | ~3 min 35 Sekunden | 2,7 GB |
📌Note: Diese Zahlen gehen davon aus, dass das Embedding-Modell die GPU besitzt. Wenn ein Chat-Modell (Llama 3.3 8B Q4_K_M nimmt etwa 5 GB in Anspruch) bereits geladen ist, konkurriert der Embedder um VRAM und der Durchsatz sinkt um 30–50% durch Contention. Auf einer 12-GB-Karte können Sie entweder indizieren oder chatten — nicht beides gleichzeitig mit voller Geschwindigkeit.
Speichergröße und Dimensions-Verhältnis
Die Dimensionszahl ist die am meisten über-konstruierte Wahl in lokaler RAG. Mehr Dimensionen helfen den Abruf bis zu etwa 1.024, dann Plateau. Darüber hinaus zahlen Sie die doppelte Speicherung für Gewinne unter 1 Prozentpunkt.
- 768 Dimensionen (nomic-embed-text-v2): 768 × 4 Byte = 3 KB pro Chunk. Ein 5.000-Seiten-Corpus, das bei 256 Token in Chunks aufgeteilt ist (~30.000 Chunks), benötigt etwa 90 MB nur für Vektoren.
- 1.024 Dimensionen (alles andere): 4 KB pro Chunk. Gleicher Corpus benötigt ~120 MB für Vektoren. Speicher skaliert linear — ein 50.000-Seiten-Corpus benötigt 1,2 GB bei 1.024 Dimensionen gegenüber 0,9 GB bei 768 Dimensionen.
- Matryoshka-Repräsentationslernen — jina-embeddings-v3 und nomic-embed-text-v2 sind trainiert, damit Sie den Vektor auf 768, 512, 256 oder sogar 128 Dimensionen abschneiden und immer noch gut abrufen können. Abschneiden ist nur das Schneiden des Arrays — keine Neueinbettung. Wir maßen retrieval@10 fällt um ~1 Punkt bei 512 Dimensionen, ~3 Punkte bei 256 Dimensionen, ~7 Punkte bei 128 Dimensionen.
- Quantisierung — int8-Quantisierung von gespeicherten Vektoren halbiert Speicher und etwa halbiert Abruf-Latenz, mit retrieval@10-Fällen ~0,5 Prozentpunkte in unserem Test. Lohnt sich für jeden Corpus über 25.000 Chunks.
- Speicher zur Inferenzzeit — das Modell selbst wird einmal in RAM geladen. nomic-embed-text-v2 benötigt etwa 1,2 GB (Mixture-of-Experts bedeutet Aktivierungen sind kleiner als Parameter), 1.024-Dim-Modelle benötigen 1,9–2,4 GB. Keines der sechs übersteigt 3 GB auch auf bf16.
- Speicherung in Produktion — für einen 50.000-Seiten-Corpus ist die Vektordatenbank-Größe auf der Festplatte 0,9 GB (768 Dim) → 1,2 GB (1.024 Dim) → 0,6 GB (1.024 Dim, int8 quantisiert). Sicherung, Synchronisierung und inkrementelle Update-Kosten skalieren alle mit dieser Zahl.
💡Tip: Wenn Speicherkosten wichtig sind, betten Sie mit jina-embeddings-v3 bei 1.024 Dimensionen ein und schneiden Sie für die Speicherung auf 512 Dimensionen ab. Sie erhalten die Indexierungs-Zeit-Genauigkeit des vollständigen Modells und die halbe Speicherkostung, mit etwa 1 Prozentpunkt retrieval@10 verloren. Das Abschneiden ist nur umkehrbar, wenn Sie die vollständigen Vektoren behalten — entscheiden Sie, bevor Sie sich festlegen.
Mehrsprachige Qualität: Wenn die englischen Führungskräfte verlieren
Die große Qualitätslücke in diesem Benchmark liegt zwischen mehrsprachigen und reinen Englisch-Modellen, nicht zwischen zwei bestimmten Modellen. Ein Satz von 25 mehrsprachigen Abfragen (Englisch, Deutsch, Französisch, Japanisch, Chinesisch — je 5) macht die Lücke deutlich.
| Modell | Englische Abfrage → Englisches Dokument | EN-Abfrage → DE/FR-Dokument | EN-Abfrage → JA/ZH-Dokument | Mehrsprachiger Durchschnitt |
|---|---|---|---|---|
| jina-embeddings-v3 | 94% | 90% | 84% | 89% |
| nomic-embed-text-v2 | 92% | 93% | 90% | 92% |
| snowflake-arctic-embed-l-v2.0 | 90% | 88% | 80% | 86% |
| mxbai-embed-large-v1 | 92% | 82% | 66% | 80% |
| bge-large-en-v1.5 | 94% | 79% | 64% | 79% |
| gte-large | 93% | 78% | 63% | 78% |
📌Note: nomic-embed-text-v2 schlägt tatsächlich jina-embeddings-v3 bei mehrsprachigen Abfragen, weil seine Mixture-of-Experts-Architektur sprachspezifische Experten für nicht-englische Inhalte aktiviert. Für Korpora mit erheblichem Japanisch- oder Chinesisch-Inhalt ist nomic-embed-text-v2 eine direkte Vergleichswert — es ist auch die billigste, auf CPU zu laufen, was seinen Reiz für mehrsprachige Arbeitslasten auf Laptops verdoppelt.
📌Note: Dieser Satz von 25 Abfragen deckt nur Englisch, Deutsch, Französisch, Japanisch und Chinesisch ab, aber dieselben beiden Modelle (nomic-embed-text-v2, BAAI/bge-m3) werben mit einer Trainingsabdeckung von über 100 Sprachen, darunter Vietnamesisch, Russisch und Griechisch. Sprachen mit lateinischer und kyrillischer Schrift wie Vietnamesisch und Russisch sowie griechische Schrift tokenisieren in diesen Modellen näher an Deutsch/Französisch als an Japanisch/Chinesisch — erwarten Sie daher eine Abrufqualität, die eher der Zeile „EN-Abfrage → DE/FR-Dokument" oben entspricht als der CJK-Zeile. Betrachten Sie das als Richtwert, nicht als gemessenen Wert, bis Sie es an Ihrem eigenen Corpus getestet haben.
Chinesisch und CJK-RAG: Welches Embedding-Modell gewinnt?
Für stark chinesischsprachige Korpora sind die sechs allgemeinen Modelle im Hauptbenchmark nicht die stärkste Option. In diesem Test führte nomic-embed-text-v2 die Gruppe der allgemeinen Modelle bei Chinesisch/Japanisch-Inhalten an (84% EN-Abfrage → JA/ZH-Dokument, siehe Mehrsprachige Qualität oben), aber zwei zweckgebundene Alternativen übertreffen jedes der sechs Hauptmodelle beim nativen chinesischen Abruf.
| Modell | Chinesisch retrieval@10 | Dim | Lizenz | Am besten für |
|---|---|---|---|---|
| BAAI/bge-large-zh-v1.5 | ~90% (nativer Chinesisch-Benchmark) | 1.024 | MIT | Rein chinesische Korpora, genauigkeitskritisch |
| Qwen3-Embedding-4B | ~91% (nativer Chinesisch-Benchmark) | 2.560 (Matryoshka → 32) | Apache-2.0 | Gemischte Chinesisch/Englisch-Korpora, flexible Dimensionen |
| BAAI/bge-m3 | ~88% (nativer Chinesisch-Benchmark) | 1.024 | MIT | Chinesisch + 100 weitere Sprachen in einem Index |
| jina-embeddings-v3 (dieser Benchmark) | 89% (mehrsprachiges Set, nicht rein Chinesisch) | 1.024 (Matryoshka → 256) | CC BY-NC 4.0 | Bereits jina für andere Sprachen im Einsatz |
| nomic-embed-text-v2 (dieser Benchmark) | 84% (EN-Abfrage → JA/ZH-Dokument, cross-lingual) | 768 | Apache-2.0 | Nur-CPU, Chinesisch ist ein kleiner Teil des Corpus |
💡Tip: Wenn Chinesisch die dominierende oder mehrheitliche Sprache in Ihrem Corpus ist, greifen Sie nicht standardmäßig zu den sechs Modellen im Hauptbenchmark — keines von ihnen wurde mit Chinesisch als primärem Ziel trainiert. BAAI/bge-large-zh-v1.5 (rein Chinesisch, MIT-Lizenz) und Qwen3-Embedding-4B (gemischt Chinesisch/Englisch, Apache-2.0, Matryoshka-Trunkierung bis auf 32 Dimensionen) übertreffen beide die sechs allgemeinen Modelle bei nativen chinesischen Abruf-Benchmarks. Für stark japanischsprachige Korpora gilt die gleiche Logik: Bevorzugen Sie ein japanisch- oder CJK-getuntes Modell gegenüber einem allgemeinen mehrsprachigen Modell, wenn Japanisch die Mehrheitssprache ist.
Bestes Embedding-Modell für Code-Suche und RAG
Code-Abruf ist die schwächste Aufgabe für alle sechs Modelle im Hauptbenchmark (82–87% retrieval@10, gegenüber 88–94% bei Rechts- und Forschungstexten), weil keines von ihnen ein dedizierter Code-Embedder ist. Wenn Ihr Corpus code-lastig ist — Repository-Suche, Agent-Tooling über eine Codebasis, interne API-Dokumentation, die mit Quellcode verbunden ist — schließt ein code-spezifischer Embedder die Lücke.
| Modell | Code retrieval@10 (dieser Test / veröffentlicht) | Dim | Lizenz | Am besten für |
|---|---|---|---|---|
| jina-embeddings-v3 (dieser Benchmark) | 87% (Führer unter allgemeinen Modellen) | 1.024 (Matryoshka → 256) | CC BY-NC 4.0 | Gemischter Code- und Prosa-Corpus, ein Embedder für alles |
| voyage-code-3 | Veröffentlichter Führer bei Code-Abruf-Benchmarks (nicht in diesem lokalen Test) | 1.024 (Matryoshka → 256) | Nur kommerzielle API — nicht selbst hostbar | Reine Code-Korpora, wo API-Nutzung akzeptabel ist |
| gte-large (dieser Benchmark) | 86% | 1.024 | Apache-2.0 | Selbst gehostet, permissive Lizenz, zweitbester Code-Score hier |
| mxbai-embed-large-v1 (dieser Benchmark) | 84% | 1.024 | Apache-2.0 | Ausgewogener Code + Englisch-Prosa |
📌Note: Wir haben in dieser Runde keinen dedizierten Open-Weight-Code-Embedder lokal benchmarkt — voyage-code-3 ist nur API, kann also nicht vollständig lokal ausgeführt werden. Unter den tatsächlich getesteten, selbst hostbaren Modellen ist jina-embeddings-v3 die beste Code-Abruf-Wahl (87%), mit gte-large (86%, Apache-2.0) als beste permissiv lizenzierte Alternative. Der praktische Ansatz für code-lastige Korpora: Beginnen Sie mit jina-embeddings-v3 für alles, messen Sie retrieval@10 auf einem zurückgehaltenen Set echter Code-Abfragen, und fügen Sie nur dann einen zweiten, code-spezifischen Index hinzu, wenn die Lücke Ihre Ergebnisse tatsächlich beeinträchtigt.
Modellprofile pro Modell: Wozu jeder Embedder wirklich gut ist
Jedes Modell hat eine andere Design-Absicht. Die Benchmark-Zahlen oben stammen von diesen Design-Entscheidungen.
- nomic-embed-text-v2 — Open-Weights Mixture-of-Experts (475 Mio. Gesamtparameter, ~305 Mio. aktiv pro Token). Trainiert auf 1,6 Mrd. Paaren über 100+ Sprachen. Lizenz: Apache-2.0. Stärken: CPU-Durchsatz (5× schneller als 1.024-Dim-Peers), starke Cross-Lingual-Recall, kleinster Speicher-Footprint. Schwächen: 768-Dim-Obergrenze bedeutet leicht niedrigere englische Recall gegenüber 1.024-Dim-Modellen. Am besten für reine CPU-Laptops, mehrsprachige Korpora und jede Indexierungs-Pipeline, die häufig laufen muss.
- bge-large-en-v1.5 (BAAI) — 335 Mio. Parameter, 1.024 Dimensionen, 24 Ebenen. Trainiert hauptsächlich auf Englisch mit abruf-fokussierten Contrastive-Paaren. Lizenz: MIT. Stärken: Top-Leistung bei englischen Rechts- und Forschungstexten, reife Ökosystem (jede lokale RAG-Plattform unterstützt es), gut dokumentiertes Verhalten unter Fine-Tuning. Schwächen: Nur Englisch — fällt 12–15 Punkte bei mehrsprachigen Abfragen. Langsamster CPU-Durchsatz im Test. Am besten für rein Englisch-RAG, wo Genauigkeit wichtiger ist als Indexierungsgeschwindigkeit.
- gte-large (Alibaba) — 335 Mio. Parameter, 1.024 Dimensionen. Trainiert auf Web-Paaren mit Fokus auf allgemeine semantische Suche. Lizenz: Apache-2.0. Stärken: permissive Lizenz, starke Englisch-Leistung, breite Framework-Unterstützung (Sentence Transformers, LangChain, LlamaIndex). Schwächen: Englisch-fokussiert (gte-multilingual-large existiert separat und fügt ~1 GB Speicher hinzu). Am besten für kommerzielle Bereitstellungen, bei denen Apache-2.0 die Lizenzüberprüfung vereinfacht.
- mxbai-embed-large-v1 (Mixedbread) — 335 Mio. Parameter, 1.024 Dimensionen. Aus starker Basis destilliert und mit abruf-fokussierten Contrastive-Training fine-getuned. Lizenz: Apache-2.0. Stärken: ausgewogene Englisch-Leistung, leicht bessere Cross-Lingual-Recall als bge-large, mxbai-embed-2d-Variant unterstützt Matryoshka-Trunkierung (separates Modell). Schwächen: kleinere Community als bge oder gte. Am besten für Englisch-RAG mit permissiver Lizenzierung und der Option, auf mxbai-embed-2d für Dimensions-Flexibilität zu aktualisieren.
- snowflake-arctic-embed-l-v2.0 (Snowflake) — 568 Mio. Parameter, 1.024 Dimensionen, unterstützt nativ bis zu 8.192-Token-Chunks. Lizenz: Apache-2.0. Stärken: Long-Context-Fähigkeit (die meisten Embedder beschränken auf 512 Token), ~30 Sprachen, stark bei Enterprise-Stil-Dokumenten. Schwächen: Mittelklasse-Genauigkeit bei Short-Chunks. Am besten für Korpora mit sehr langen strukturierten Dokumenten (Rechtsverträge, technische Handbücher, Regulatory Filings), wo 8k-Token-Chunks nützlich sind.
- jina-embeddings-v3 (Jina AI) — 570 Mio. Parameter, 1.024 Dimensionen mit Matryoshka-Trunkierung auf 768/512/256. Trainiert mit Task-spezifischen LoRA-Adaptern (Abruf, Klassifizierung, Ähnlichkeit). 89-Sprachen-Unterstützung. Lizenz: CC BY-NC 4.0 für die Open Weights (kommerzielle Nutzung benötigt eine kostenpflichtige Lizenz) — überprüfen Sie vor der Bereitstellung in einem kostenpflichtigen Produkt. Stärken: beste Gesamtabruf-Genauigkeit in diesem Benchmark, starke mehrsprachige Leistung, Matryoshka-Trunkierung, Task-bewusste Adapter. Schwächen: Lizenzierung erfordert Vorsicht für kommerzielle Bereitstellungen. Am besten für persönliche RAG, Forschung und jede Bereitstellung, bei der die Lizenzierung akzeptabel ist.
- Qwen3-Embedding-4B / -8B (Alibaba) — nicht im obigen Haupt-Benchmark der 6 Modelle enthalten, aber hier für Chinesisch/CJK- und gemischtsprachige Korpora aufgeführt (siehe Abschnitt Chinesisch und CJK-RAG). 2.560 Dimensionen mit Matryoshka-Trunkierung bis auf 32 Dimensionen. Lizenz: Apache-2.0. Stärken: stärkster chinesischer Abruf jedes auf dieser Seite besprochenen Modells, wettbewerbsfähige englische Leistung, vollständig selbst hostbar. Schwächen: größerer Speicher-Footprint als die 335–570M-Modelle im Hauptbenchmark; die 8B-Variante benötigt für praktischen Durchsatz eine GPU. Am besten für Chinesisch-dominierte oder gemischte Chinesisch/Englisch-Korpora.
💡Tip: Überprüfen Sie die Lizenz immer zur Integrations-Zeit erneut. Embedding-Modell-Lizenzen haben sich mehrmals verschoben — bge war von MIT zu einem restriktiveren kommerziellen Term und zurück, jina-embeddings-v3 wird unter CC BY-NC für die Open Weights ausgeliefert und Snowflake fügte eine Akzeptable-Use-Policy zusätzlich zu Apache-2.0 hinzu. Behandeln Sie die README als eine aktuelle Aussage, nicht als historisches Dokument.
Selbst gehostet vs OpenAI text-embedding-3-large: Kosten pro Million Token
Selbst gehostete Einbettung ist im großen Maßstab im Grunde kostenlos. Die einzigen aussagekräftigen Kosten sind Elektrizität und Hardware-Amortisation — beide runden zu Rauschen im Vergleich zu API-Preisen für jeden Corpus über ein paar tausend Seiten.
| Ansatz | Kosten / 1 Million Token | Zeit für 1 Million Token | Notizen |
|---|---|---|---|
| OpenAI text-embedding-3-large (API) | €0,12* | ~3 min (netzwerkgebunden) | Höchste absolute Genauigkeit bei Englisch; Daten verlassen Ihren Computer |
| jina-embeddings-v3 auf RTX 4070 | ~€0,001 (Elektrizität) | ~5 min | Beste lokale Genauigkeit; CC BY-NC-Lizenz — überprüfen Sie kommerziell |
| bge-large-en-v1.5 auf RTX 4070 | ~€0,001 | ~12 min | Beste Englisch-Genauigkeit; MIT-Lizenz |
| nomic-embed-text-v2 auf RTX 4070 | ~€0,0005 | ~3 min 30 Sekunden | Schnellster GPU-Durchsatz; mehrsprachig; Apache-2.0 |
| nomic-embed-text-v2 auf M3 Pro CPU | ~€0,0008 | ~30 min | Keine GPU erforderlich; sinnvoll nur, weil es ohne GPU möglich ist |
📌Note: Für einen 5.000-Seiten-Corpus (~5 Mio. Token bei 1.000 Token pro Seite) berechnet OpenAI ~€0,60 pro vollständiger Neuindexierung — trivial. Die echte Kosten ist Daten-Egress: jeder Chunk verlässt Ihren Computer, und viele Compliance-Regime erlauben es einfach nicht. Selbst gehostete Einbettung ist eine Datenschutz- und Kontrollentscheidung zuerst, eine Kostenentscheidung zweite. *konvertiert von $0,13 mit aktuellem Kurs.
Entscheidungsbaum: Welchen Embedder sollten Sie wählen?
Fünf binäre Fragen, in dieser Reihenfolge, führen die meisten Leser zum richtigen Embedder.
- 1. Haben Sie eine GPU für die Indexierung verfügbar? → Nein: nomic-embed-text-v2 (5× CPU-Geschwindigkeit). Ja: fortfahren.
- 2. Ist der Corpus rein Englisch? → Nein: fortfahren. Ja: bge-large-en-v1.5, wenn Genauigkeit am wichtigsten ist, gte-large oder mxbai-embed-large-v1, wenn Apache-2.0-Lizenz wichtig ist.
- 3. Sind Dokumente sehr lang (8k+ Token-Chunks)? → Ja: snowflake-arctic-embed-l-v2.0. Nein: fortfahren.
- 4. Möchten Sie die Dimensionen später für Speicherkosten abschneiden? → Ja: jina-embeddings-v3 (Matryoshka). Nein: fortfahren.
- 5. Ist die Bereitstellung ein kommerzielles Produkt? → Ja: vermeiden Sie jina-embeddings-v3 (CC BY-NC), es sei denn, Sie kaufen die kommerzielle Lizenz — verwenden Sie stattdessen nomic-embed-text-v2 (Apache-2.0) oder BAAI/bge-m3 (MIT).
- Wenn unsicher: jina-embeddings-v3. Es ist die höchste-Genauigkeit allgemeine Wahl im Benchmark und das einzige Modell, das über 87% auf jedem Dokumenttyp bleibt. Lizenz-zulassende Bereitstellungen sollten sich standardmäßig dafür entscheiden.
Häufige Fehler beim Wählen eines Embedding-Modells
- Fehler 1: An der Plattform-Standard haften. AnythingLLM wird mit einem winzigen eingebauten Embedder ausgeliefert; PrivateGPT setzt auf all-MiniLM-L6-v2; Open WebUI setzt auf nomic-embed-text-v1.5. Alle drei Standards unterperformen jina-embeddings-v3 um 5–10 Prozentpunkte bei retrieval@10. Wechseln.
- Fehler 2: Ein 1.024-Dim-Modell wählen, wenn retrieval@10 bei 90% mit einem 768-Dim-Modell bereits war. Der marginale Gewinn rechtfertigt selten die verdoppelte Speicherung und 5× langsamer CPU-Durchsatz. nomic-embed-text-v2 erreicht 88% — genug für die meisten Anwendungsfälle.
- Fehler 3: Einen reinen Englisch-Embedder für einen mehrsprachigen Corpus wählen. bge-large-en-v1.5 ist der beste Englisch-Embedder im Test und einer der schlechtesten bei Japanisch- oder Chinesisch-Inhalten. Die „beste Embedder"-Antwort ist corpus-abhängig — messen Sie auf Ihren Daten.
- Fehler 4: Die Lizenz ignorieren. jina-embeddings-v3 wird unter CC BY-NC für die Open Weights ausgeliefert. Wenn Sie es ohne die kommerzielle Lizenz in einem bezahlten Produkt ausliefern, haben Sie ein Rechtsproblem. Überprüfen Sie die Lizenz immer zur Integrations-Zeit.
- Fehler 5: Auf einem zu kleinen Corpus benchmarken. Alle sechs Modelle sehen auf 100 Dokumenten großartig aus. Unterschiede werden über ~5.000 Chunks hinweg entscheidend, wo die Recall-Obergrenze schwächerer Embedder auftaucht. Testen Sie auf mindestens 5.000 Chunks Ihres tatsächlichen Inhalts.
- Fehler 6: Vergessen, dass der Wechsel des Embedders einen vollständigen Neuindex erzwingt. Keine lokale RAG-Plattform unterstützt inkrementelle Migration. Jeder Embedder-Austausch kostet 30–90 Minuten pro 5.000 Seiten auf Consumer-Hardware. Wählen Sie einmal, tauschen Sie bewusst.
Häufig gestellte Fragen
Welches Embedding-Modell ist nur auf CPU am schnellsten?
nomic-embed-text-v2 — 580 Chunks/Sekunde auf Apple M3 Pro bei Batch-Größe 32, 256-Token-Chunks. Ungefähr 5× schneller als die 1.024-Dim-Alternativen (bge-large-en-v1.5 bei 95, gte-large bei 110, mxbai-embed-large-v1 bei 105 Chunks/Sekunde). Der Geschwindigkeitsvorteil kommt von seiner Mixture-of-Experts-Architektur, die nur etwa 305 Mio. von 475 Mio. Parametern pro Token aktiviert. Für jeden Corpus über 1.000 Seiten auf reiner CPU-Hardware ist nomic-embed-text-v2 die praktische Standardeinstellung.
Verbessern größere Embedding-Dimensionen wirklich den Abruf?
Bis zu etwa 1.024 Dimensionen, ja. Darüber hinaus, nein. Im Benchmark lag 768-Dim nomic-embed-text-v2 (88% retrieval@10) um 4 Punkte hinter 1.024-Dim jina-embeddings-v3 (92%) insgesamt. Die Skalierung auf 1.536 oder 3.072 Dimensionen (einige kommerzielle APIs) gewinnt weniger als 1 Prozentpunkt in veröffentlichten Vergleichen. Dimensionen kosten Speicher linear: Ein 50.000-Seiten-Corpus benötigt 0,9 GB bei 768 Dimensionen gegenüber 1,2 GB bei 1.024 Dimensionen gegenüber 3,6 GB bei 3.072 Dimensionen. Der Matryoshka-Trick — nach dem Einbetten abschneiden — gibt Ihnen Flexibilität ohne die Kosten.
Kann ich mehrsprachige Einbettungen ohne Leistungsverlust verwenden?
Mehrsprachige Modelle haben sich 2026 erheblich aufgeholt. jina-embeddings-v3 erreichte 92% retrieval@10 insgesamt (89% bei mehrsprachigen Abfragen speziell) — wettbewerbsfähig mit den besten reinen Englisch-Embeddern bei Englisch-Text und weit voraus bei nicht-Englisch. Die historische Lücke (mehrsprachig = niedrigere Genauigkeit) hat sich auf 1–2 Punkte bei englischen Abfragen für einen 10-Punkt-Gewinn bei nicht-Englisch verengt. Für gemischte Korpora ist mehrsprachig jetzt die Standardwahl.
Welches Embedding-Modell behandelt Code am besten?
Keines der sechs getesteten sind dedizierte Code-Embedder. Bei einer TypeScript/Python-Codebasis führte jina-embeddings-v3 mit 87% retrieval@10 an, die anderen lagen zwischen 82–86%. Für Code-intensive Korpora — Code-Suche, Repository-RAG, Agent-Tooling über einer Codebasis — kombinieren Sie einen allgemeinen Embedder mit einem Code-spezifischen (voyage-code-3, nur API, oder eine Fine-Tuned-Variante) und verwenden Sie den besser bewerteten für Code-Chunks. Siehe den Abschnitt Bestes Embedding-Modell für Code-Suche und RAG oben für einen direkten Vergleich. Der einfachste Ansatz: Betten Sie alles zuerst mit jina-embeddings-v3 ein, messen Sie retrieval@10 auf einem gehaltenen Abfrage-Set und tauschen Sie nur aus, wenn es unter Ihren Schwellenwert fällt.
Welches Embedding-Modell ist am besten für Chinesisch-RAG?
Keines der sechs Modelle im Hauptbenchmark wurde mit Chinesisch als primärem Ziel trainiert — das nächstliegende, nomic-embed-text-v2, erreicht nur 84% bei Abruf von Englisch-Abfrage zu chinesischem Dokument. Für Chinesisch-dominierte oder rein chinesische Korpora verwenden Sie stattdessen BAAI/bge-large-zh-v1.5 (rein Chinesisch, MIT-Lizenz, ~90% bei nativen Chinesisch-Benchmarks) oder Qwen3-Embedding-4B (gemischt Chinesisch/Englisch, Apache-2.0, Matryoshka-Trunkierung). Siehe den Abschnitt Chinesisch und CJK-RAG oben für den vollständigen Vergleich.
Wie oft sollte ich mein Embedding-Modell aktualisieren?
Aktualisierung, wenn ein neu veröffentlichtes Modell einen Benchmark veröffentlicht, der Ihren um 3+ Prozentpunkte bei ähnlichen Daten Ihres Corpus schlägt, UND Sie eine gemessene retrieval@10-Nummer haben, mit der Sie vergleichen können. Ohne eine Baseline-Messung können Sie nicht sagen, ob das neue Modell tatsächlich besser bei Ihrem Inhalt ist. Für die meisten lokalen RAG-Bereitstellungen ist ein Embedder für 12–18 Monate gut, bevor eine bedeutsam bessere Option ankommt. Neuindexierung ist der Kosten — budgetieren Sie 30–90 Minuten pro 5.000 Seiten auf Consumer-Hardware.
Kann ich Embedding-Modelle im selben RAG-System mischen?
Technisch ja, praktisch nein. Das Mischen erfordert entweder zwei parallele Vektor-Indexes (beide Abfragen, Ergebnisse zusammenführen — fügt 50–150 ms Latenz hinzu und verkompliziert die Relevanz-Bewertung) oder Training einer kleinen Projektions-Schicht zum Ausrichten von Dimensionen (Research-Grade, zerbrechlich). Für 95% der lokalen Bereitstellungen müssen Sie einen Embedder auswählen und neuindexieren. Die Ausnahme: Code-Repositories mit einem dedizierten Code-Embedder für Code-Chunks und einem allgemeinen Embedder für Dokumentation — teilen Sie nach Dokumenttyp beim Ingestion auf, beide Indexes abfragen, wenn die Benutzer-Abfrage mehrdeutig ist.
Sind Open-Source-Einbettungen genauso gut wie OpenAIs?
Für die meisten lokalen RAG-Anwendungsfälle, ja. OpenAI text-embedding-3-large führt immer noch veröffentlichte Englisch-Benchmarks um 2–4 Prozentpunkte bei retrieval@10 an, aber die Lücke hat sich erheblich verengt. jina-embeddings-v3 kam innerhalb von 2 Punkten auf dem Test-Corpus, und die OpenAI-Route erfordert Daten verlassen Ihren Computer — ein Non-Starter für jede Bereitstellung mit Datenschutz- oder Compliance-Einschränkungen. Für reine Qualität bei englischem Text ohne Datenschutz-Anforderung und ein bescheidenes Budget ist OpenAI immer noch die höchste absolute Zahl; für alles andere haben Open-Source-Lösungen aufgeholt.
Beeinflusst Quantisierung die Einbettungsqualität?
int8-Quantisierung von gespeicherten Vektoren kostet etwa 0,5 Prozentpunkte retrieval@10 im Austausch gegen die Halbierung des Speichers und etwa die Halbierung der Abruf-Latenz. Lohnt sich bei jedem Corpus über 25.000 Chunks. Die Quantisierung des Einbettungs-Modells selbst (die Gewichte — bf16 → int8 → int4) ist aggressiver: int8-Modell-Quantisierung kostet 1–2 Prozentpunkte; int4 kostet 3–5 Punkte und verletzt die mehrsprachige Recall merklich. Für lokale RAG auf Consumer-Hardware führen Sie das Modell bei bf16 (oder fp16) aus und quantisieren Sie nur die gespeicherten Vektoren.
Welches Modell ist am besten für juristische Dokumente?
bge-large-en-v1.5 führte die juristische Teilmenge bei 94% retrieval@10 an — die höchste einzelne Nummer im Benchmark — aber nur für englische Verträge. Für deutsche, französische oder mehrsprachige juristische Korpora ist jina-embeddings-v3 (93% Englisch / 89% mehrsprachig) der bessere Allrounder. Juridischer Text belohnt 1.024-Dim-Modelle, weil terminologische Präzision wichtig ist; das 768-Dim nomic-embed-text-v2 fiel um 6 Punkte bei der juristischen Teilmenge zurück. Für sehr lange Verträge (50+ Seiten dichtes Legalese) reduziert snowflake-arctic-embed-l-v2.0 mit 8k-Token-Chunks Fragmentierungs-Verluste.
Können Einbettungen wiederverwendet werden, wenn ich RAG-Plattformen wechsle?
Quell-Dokumente werden frei zwischen Plattformen verschoben. Einbettungen werden nur verschoben, wenn die neue Plattform das gleiche Vektor-Format und das gleiche Embedding-Modell unterstützt. AnythingLLM (LanceDB), PrivateGPT (Qdrant oder Chroma) und Open WebUI (ChromaDB) verwenden alle unterschiedliche Vektor-Stores; selbst wenn der Embedder identisch ist, unterscheiden sich die Metadaten-Schemas. In der Praxis ist jeder Plattform-Wechsel auch ein Neuindexierungs-Durchlauf. Planen Sie entsprechend: Wählen Sie den Embedder für die Abruf-Qualität, wählen Sie die Plattform für alles andere.
Kann ich diese Embedding-Modelle mit Ollama ausführen?
Ja, für die meisten davon. ollama pull deckt nomic-embed-text-v2 (nomic-embed-text-v2-moe), mxbai-embed-large-v1 (mxbai-embed-large), snowflake-arctic-embed-l-v2.0 (snowflake-arctic-embed2), BAAI/bge-m3 (bge-m3) und Qwen3-Embedding-4B/-8B (qwen3-embedding:4b / :8b) direkt aus Ollamas offizieller Bibliothek ab. bge-large-en-v1.5, gte-large und jina-embeddings-v3 sind dort nicht veröffentlicht — führen Sie diese stattdessen mit Sentence Transformers, Hugging Face transformers oder einem Text Embeddings Inference-Server aus und richten Sie Ihre RAG-Plattform dann auf diesen Endpunkt statt auf Ollama.