Embedding-Modell wählen 2026: Leaderboards, Kosten und ein Vergleichstest mit eigenen Daten

Das Embedding-Modell ist der unsichtbarste Teil eines RAG-Systems und einer der am schwersten zu ändernden. Jeder Chunk im Index wurde von ihm erzeugt, jede Anfrage muss durch dasselbe Modell, und Vektoren eines anderen Modells sind nicht vergleichbar. Wer schlecht wählt, merkt es Monate später, wenn die Korrektur ein Neu-Embedding des ganzen Korpus bedeutet.

Dieser Leitfaden zeigt, wie ich im Oktober 2026 eines auswähle: wofür Leaderboards taugen, welche Modelle auf eine Shortlist gehören, welche Eigenschaften wichtiger sind als der Rang und wie man einen kleinen Vergleichstest mit eigenen Daten durchführt. Er ergänzt die schrittweise produktive RAG-Pipeline, die ein bereits gewähltes Modell voraussetzt.

Warum ist das Embedding-Modell eine langfristige Entscheidung?

Ein Embedding ist eine Position in einem Raum, den nur ein Modell definiert. Zwei Modelle können beide 1.024 Zahlen pro Text ausgeben und füreinander trotzdem bedeutungslos sein, weil jedes seine eigene Geometrie gelernt hat. Google sagt es für die eigenen Modelle deutlich: Die Räume von gemini-embedding-001 und gemini-embedding-2 sind inkompatibel, ein Wechsel erfordert das Neu-Embedding aller vorhandenen Daten.

Die Token-Rechnung fürs Neu-Embedding ist selten das Problem. Ein Korpus von 50 Millionen Tokens kostet mit text-embedding-3-large bei 0,13 $ pro Million einmalig 6,50 $. Die echten Kosten sind Pipeline-Zeit: neu parsen, neu chunken, Indizes neu bauen, Evaluationen wiederholen und den Verkehr ohne Ausfall umstellen. Deshalb verdient die Wahl eine Woche Messung statt eines Blicks aufs Leaderboard.

Was sagen MTEB und RTEB tatsächlich aus?

MTEB ist der öffentliche Standard-Benchmark für Embedding-Modelle. Seine mehrsprachige Erweiterung MMTEB umfasst über 500 qualitätsgeprüfte Aufgaben in mehr als 250 Sprachen, darunter Retrieval, Klassifikation, Clustering, Befolgen von Anweisungen, lange Dokumente und Code. Ein Befund des MMTEB-Papers ist merkenswert: Modelle mit Milliarden Parametern führen bei manchen Teilmengen, doch das beste öffentlich verfügbare Modell der Studie war multilingual-e5-large-instruct mit nur 560 Millionen Parametern. Größe ist nicht dasselbe wie Eignung für die eigene Aufgabe.

Die Schwäche eines öffentlichen Benchmarks ist, dass er öffentlich ist. Wenn Testsets sich mit Trainingsdaten überschneiden, schneiden Modelle gut ab, ohne zu generalisieren; das Team von Hugging Face nennt das Lernen für den Test. Die Antwort, RTEB, startete am 1. Oktober 2025 als Beta: ein Retrieval-Benchmark mit offenen und privaten Datensätzen, die nur die MTEB-Betreuer auswerten, für Recht, Gesundheit, Code und Finanzen in 20 Sprachen, gereiht nach nDCG@10.

Anbieter-Benchmarks sind eine dritte Kategorie und brauchen die meiste Vorsicht. Voyage berichtet, dass voyage-4-large OpenAIs text-embedding-3-large im Schnitt über die RTEB-Datensätze um 14,05 % und Gemini Embedding 001 um 3,87 % schlägt, gemessen von Voyage selbst. Solche Zahlen helfen bei der Frage, was man testet, nicht, was man kauft.

Welche Modelle gehören 2026 auf die Shortlist?

Die Tabelle zeigt Modelle, die ich heute für ein neues RAG-Projekt in Betracht ziehen würde, mit Angaben aus der Dokumentation oder Model Card des jeweiligen Anbieters, Stand Oktober 2026. Preise pro Million Eingabe-Tokens zum Standardtarif.

Zwei Details aus den Model Cards sind für deutsche oder ungarische Inhalte wichtig. Qwen3-Embedding-8B lag am 5. Juni 2025 mit 70,58 Punkten auf Platz eins des mehrsprachigen MTEB-Leaderboards, und die Autoren empfehlen, Aufgabenanweisungen auch bei mehrsprachiger Nutzung auf Englisch zu schreiben. Google bezeichnet EmbeddingGemma als das bestplatzierte offene mehrsprachige Text-Embedding-Modell unter 500 Millionen Parametern auf MTEB, mit einem Kontext von nur rund 2.000 Tokens. Meine Notizen zu mehrsprachigem RAG für Deutsch und Ungarisch behandeln, was sich für diese Sprachen sonst ändert.

Welche Kriterien zählen mehr als der Leaderboard-Rang?

Ein Unterschied von zwei Punkten in einem aggregierten Benchmark verschwindet neben einer Fehlanpassung bei einer dieser Eigenschaften:

• Sprachen und Domäne. Die Sprachen prüfen, in denen Nutzer tatsächlich fragen, inklusive gemischtsprachiger Anfragen, und ob das Modell Text wie den eigenen gesehen hat: Artikelnummern, juristisches Deutsch, Quellcode.
• Kontextlänge gegenüber Chunk-Größe. Ein Modell mit 2.000 Tokens reicht für Chunks mit 400 Tokens; einen Abschnitt mit 6.000 Tokens schneidet es stillschweigend ab. Voyage kürzt zu lange Eingaben standardmäßig, außer man setzt truncation auf false.
• Dimensionen und Ausgabetypen. Matryoshka-Modelle erlauben, beim Aufruf einen kleineren Vektor zu wählen, und mehrere APIs liefern direkt int8- oder Binärvektoren. Beides senkt den Speicherbedarf des Index, wie in Embedding-Quantisierung beschrieben.
• Hosting und Datenresidenz. Ob Dokumente die eigene Infrastruktur verlassen dürfen und in welche Region, entscheidet zwischen gehosteter API und offenen Gewichten, noch bevor es die Qualität tut.
• Anfragelatenz und Volumen. Jede Suche bettet zuerst eine Anfrage ein. Ein Netzwerk-Roundtrip pro Anfrage ist für einen Chat-Assistenten in Ordnung, bei Suche während der Eingabe aber spürbar.
• Familie und Lebensdauer. Eine Modellfamilie mit gemeinsamem Raum, veröffentlichter Abkündigungspolitik und mehreren Größen lässt später mehr Spielraum als ein einzelner Checkpoint.

Gehostete API oder offene Gewichte?

Gehostete Modelle sind der schnellste Start: keine GPUs, kein Serving-Stack und Batch-Preise für den großen Indexierungslauf. Google bietet seine Embedding-Modelle über die Batch-API zum halben Standardpreis an, Voyage rechnet Batch-Anfragen 33 % unter dem Standardtarif ab. Der Preis dafür: Jedes Dokument und jede Anfrage geht durch einen Dritten, was die Wahl zur Datenschutzfrage macht. Regionssteuerung und Aufbewahrungsoptionen habe ich in DSGVO und LLM-Datenresidenz behandelt.

Modelle mit offenen Gewichten verlagern die Arbeit zu einem selbst, sind aber klein geworden. EmbeddingGemma hat rund 308 Millionen Parameter und bleibt quantisiert unter 200 MB RAM; die Qwen3-Embedding-Reihe beginnt bei 0,6 Milliarden Parametern unter Apache 2.0; Voyage hat voyage-4-nano unter Apache 2.0 auf Hugging Face veröffentlicht. Auf einem gewöhnlichen CPU-Server schaffen diese Modelle das Einbetten von Anfragen problemlos, und der große Indexierungslauf kann ein einmaliger Job auf einer gemieteten GPU sein. Selbst wer am Ende ein gehostetes Modell nimmt, erfährt durch ein offenes Modell im Vergleichstest, was der Aufpreis tatsächlich bringt.

Was ändern gemeinsame Embedding-Räume?

Die jüngste Verschiebung sind Modellfamilien, die in einen gemeinsamen Raum trainiert wurden. Die vier Voyage-4-Modelle erzeugen kompatible Embeddings, sodass einmal mit voyage-4-large eingebettete Dokumente mit Anfragen aus voyage-4-lite oder dem offenen voyage-4-nano durchsucht werden können. Voyage nennt das asymmetrisches Retrieval. Die Indexqualität kommt vom teuren Modell, Kosten und Latenz pro Anfrage vom günstigen, und das Anfragemodell lässt sich später wechseln, ohne den Index anzufassen.

Die von Voyage dokumentierte Kompatibilität umfasst die vier Voyage-4-Modelle und nichts Älteres; beim Wechsel von der Voyage-3-Generation also ein Neu-Embedding einplanen. Ein gemeinsamer Raum ist ein Grund, eine Familie zu bevorzugen, aber kein Grund, nicht mehr zu speichern, welches Modell jeden Vektor erzeugt hat.

Welche API-Details kosten unbemerkt Qualität?

Die meisten schlechten Ergebnisse in Vergleichstests, die ich sehe, kommen von falsch aufgerufenen Modellen, nicht vom Modell. Drei Details lohnen den Abgleich mit der Dokumentation für jeden Kandidaten:

1. Anfrage- und Dokumentmodus. Voyage stellt für input_type query und document jeweils einen anderen Prompt voran. Gemini-embedding-001 nimmt einen task_type wie RETRIEVAL_QUERY, gemini-embedding-2 erwartet ein Aufgabenpräfix im Text. Qwen3-Embedding erwartet auf Anfrageseite eine Anweisung, was laut Autoren die Ergebnisse typischerweise um 1 bis 5 % verbessert.
2. Normalisierung nach dem Kürzen. OpenAI-Embeddings sind auf Länge 1 normalisiert, und der Parameter dimensions erhält das. Wer einen Vektor selbst kürzt oder gemini-embedding-001 unter 3.072 Dimensionen nutzt, muss ihn vor dem Skalarprodukt neu normalisieren.
3. Kürzen langer Eingaben. Wissen, ob die API zu lange Eingaben abschneidet oder ablehnt, und die Token-Zahl pro Chunk protokollieren, damit eine Chunker-Änderung Chunks nicht unbemerkt über das Limit schiebt.

import numpy as np

def prepare(vec: list[float], dims: int | None = None) -> np.ndarray:
    """Truncate a Matryoshka embedding and re-normalize it for dot-product search."""
    v = np.asarray(vec, dtype=np.float32)
    if dims is not None:
        v = v[:dims]               # keep the leading dimensions only
    return v / np.linalg.norm(v)   # unit length again, so dot product == cosine

# Store the model id next to every vector: vectors from different models never mix.
row = {"chunk_id": "doc-42#3", "model": "voyage-4-large", "dims": 1024,
       "embedding": prepare(raw_vector, 1024).tolist()}

Wie führt man einen Vergleichstest mit eigenen Daten durch?

Ein nützlicher Vergleichstest ist klein und dauert etwa eine Woche. Man braucht echte Anfragen, die Chunks, die sie beantworten, und dieselbe Chunking-Strategie für jeden Kandidaten, damit nur das Modell variiert.

1. 100 bis 300 echte Anfragen aus Suchlogs, Support-Tickets oder von Nutzern sammeln und die Chunks markieren, die jede beantworten. Kurze Stichwortanfragen und lange Fragen einschließen, und jede Sprache, in der Nutzer schreiben.
2. Drei bis fünf Kandidaten wählen: ein günstiges gehostetes Modell, ein starkes gehostetes Modell, ein Modell mit offenen Gewichten und das, was das aktuelle System nutzt.
3. Dieselben Chunks mit jedem einbetten, mit korrektem Anfrage- und Dokumentmodus, in der Dimension, die man ausrollen würde.
4. Recall@10 und nDCG@10 pro Kandidat messen und dann mit hybrider Suche und Reranker wiederholen, weil ein Reranker Unterschiede der ersten Stufe verdecken kann. Die Metriken erklärt RAG evaluieren.
5. Qualität, Indexgröße, Kosten pro Million Tokens und p95-Anfragelatenz in eine Tabelle stellen und das günstigste Modell im Qualitätsbudget wählen.

Wie plant man für das nächste Modell?

Man wird wieder wechseln; das Veröffentlichungstempo der letzten zwei Jahre macht das zur sicheren Wette. Von Anfang an dafür planen: den geparsten und gechunkten Text aufbewahren, damit Neu-Embedding kein Neu-Parsen bedeutet, den Indexnamen mit dem Modell versionieren und den neuen Index neben dem alten aufbauen. Die Anfragen des Vergleichstests gegen beide laufen lassen, einen Teil des Live-Verkehrs spiegeln, dann per Konfigurationsänderung umschalten und den alten Index behalten, bis die Evaluation hält. Dieselbe Disziplin gilt für das Generierungsmodell, wie in LLM-Modellmigrationen ohne Regressionen beschrieben.

Was sind Ende 2026 sinnvolle Standardwahlen?

Das sind meine Meinungen, keine Benchmark-Ergebnisse. Für eine deutsche oder ungarische B2B-Wissensbasis, die eine gehostete API nutzen darf, starte ich den Vergleichstest mit einer Modellfamilie mit gemeinsamem Raum und mehreren Größen, einem Gemini-Modell und Qwen3-Embedding-0.6B als offener Basislinie. Wenn Dokumente vor Ort bleiben müssen, vergleiche ich Qwen3-Embedding in zwei Größen mit EmbeddingGemma und nehme das größere nur, wenn der gemessene Gewinn die zusätzliche Hardware rechtfertigt. In beiden Fällen rolle ich mit 1.024 Dimensionen oder weniger aus, sofern der Test keinen klaren Verlust zeigt.

Das Modell zählt weniger als erwartet, sobald Chunking, hybride Suche und Reranking stehen. Die erste Woche ins Evaluationsset stecken, denn es überdauert jedes Modell, das man ausprobieren wird.

Quellen

1. Enevoldsen et al.: MMTEB, Massive Multilingual Text Embedding Benchmark (2025)
2. Hugging Face: Introducing RTEB, a new standard for retrieval evaluation (Oct 2025)
3. OpenAI: Vector embeddings guide
4. OpenAI: API pricing
5. Voyage AI: The Voyage 4 model family, shared embedding space with MoE architecture (Jan 2026)
6. Voyage AI: Text embeddings documentation
7. Voyage AI: Pricing
8. Google: Gemini API embeddings documentation
9. Google: Gemini API pricing
10. Cohere: Embed models documentation
11. Qwen: Qwen3-Embedding-8B model card
12. Google Developers Blog: Introducing EmbeddingGemma (Sep 2025)