Embedding Model im Vergleich: Die besten Modelle für RAG 2026

Das beste Embedding Model ist dasjenige, das zuverlässig die passenden Antworten findet: OpenAI text-embedding-3-small eignet sich als günstige Ausgangsbasis für Textsuche, Voyage 4 als Vergleichskandidat für die Informationssuche und Google Gemini Embedding 2 für Quellen mit Audio oder Video. Das kleine Modell von OpenAI kostet ab $0.02 pro Million Eingabetokens. Die langfristig größere Bindung entsteht jedoch durch den Vektorindex: Beim Wechsel zu einem inkompatiblen Modell muss er neu aufgebaut werden.

Ein Embedding-Modell wandelt Inhalte in einen Vektor um, also in eine Liste von Zahlen. Damit kann eine Suche Bedeutungszusammenhänge erkennen, auch wenn sich die Formulierungen unterscheiden. Ein Supportbot verknüpft so etwa „Ich komme nicht mehr in mein Konto“ mit dem passenden Hilfeartikel zu Anmeldeproblemen. Retrieval-Augmented Generation, kurz RAG, reicht die gefundene Quelle an das Modell weiter, das die Antwort formuliert.

Technische Daten, Preise und Lizenzen wurden am 15. Oktober 2026 anhand der aktuellen Herstellerseiten geprüft. Dieser Vergleich beruht auf der Dokumentation; er ist kein Praxistest zur Genauigkeit oder Latenz. Die folgenden Empfehlungen dienen als Ausgangspunkt für eigene Tests. Der eingangs genannte Preis stammt aus der Preisübersicht von OpenAI.

Embedding Model im Vergleich: die Auswahl auf einen Blick

Die sinnvollste Wahl ist das günstigste Modell, das die Anforderungen an die Suche erfüllt. Andere Sprachen, Quellformate oder Vorgaben für den Betrieb können die Vorauswahl verändern. Die folgenden sieben Modellfamilien decken verwaltete APIs, den Betrieb in eigener Umgebung und herunterladbare Modellgewichte ab.

Alle Preise sind reguläre Tarife in USD pro Million Texteingabetokens, sofern die Zeile keinen Eigenbetrieb angibt. Vektordatenbank, Antwortgenerierung und Reranking sind nicht enthalten. Beim Reranking bewertet ein weiteres Modell die gefundenen Kandidaten neu. Da jeder Anbieter Text anders tokenisiert, kann dasselbe Dokument unterschiedlich viele abrechenbare Tokens erzeugen.

„Offene Modellgewichte“ bedeutet, dass sich die Modelldateien herunterladen und selbst betreiben lassen. Rechenleistung, Bereitstellung und Wartung sind deshalb nicht kostenlos. Auch „mehrsprachig“ bedeutet nicht, dass ein Modell in jeder Sprache gleich präzise arbeitet. Entscheidend sind Tests mit den Sprachpaaren von Suchanfrage und Dokument, die tatsächlich bei den eigenen Kunden vorkommen.

Die Modelle im Detail

1. OpenAI text-embedding-3: die pragmatische Basis für Textsuche

OpenAI text-embedding-3-small und text-embedding-3-large sind gehostete Modelle für Text-Embeddings. Für Gründer, die eine klassische Hilfecenter-Suche oder einen Supportbot entwickeln, empfehle ich small als Einstieg. Damit steht eine günstige Vergleichsbasis zur Verfügung, ohne eigene Modellserver betreiben zu müssen. Large kommt als Alternative ins Spiel, wenn small wiederholt relevante Passagen übersieht. Wer schon vorher dafür bezahlt, überspringt den aufschlussreichsten Teil der Entscheidung.

Dimensionen: standardmäßig 1,536 bei small und 3,072 bei large. Beide unterstützen kürzere Vektoren über den Parameter dimensions.
Maximale Eingabe: 8,192 Tokens pro Eingabe bei beiden Modellen.
Sprachen und Modalitäten: mehrsprachiger Text; weder Bilder noch Audio oder Video werden als Eingabe akzeptiert. Die verlinkte Dokumentation nennt keine vollständige Anzahl unterstützter Sprachen.
Betrieb: gehostete Embeddings-API von OpenAI. Technische Daten, Modalitäten.
Besonders geeignet für: textorientierte Anwendungen, deren Entwickler schnell eine messbare Ausgangsbasis brauchen.
Besonderheit: Dieselbe API ermöglicht den Vergleich von small und large sowie eine konfigurierbare Ausgabegröße.
Preise: $0.02 pro Million Eingabetokens für small, $0.13 für large; reguläre Tarife, geprüft am 15. Oktober 2026. Preise.
Kostenlos testen: Einführendes API-Guthaben wird nicht vorausgesetzt; die Planung sollte von kostenpflichtiger Nutzung ausgehen.

Die Grenze liegt beim Eingabeformat. Wird aus einer PDF zur Fehlerbehebung nur der Text extrahiert, kann genau der Screenshot verloren gehen, der die richtige Schaltfläche zeigt. Keines der beiden OpenAI-Embedding-Modelle stellt diese visuelle Information wieder her. Text-Embeddings passen, wenn die Antwort bei der Extraktion erhalten bleibt. Trägt die Seitengestaltung selbst zur Antwort bei, gehört ein multimodales Modell in den Vergleich.

Modellgröße und Vektorgröße sind außerdem getrennte Entscheidungen. Large mit reduzierter Ausgabedimension kann eine bestehende Speichergrenze einhalten, ist dadurch aber nicht mit small austauschbar. Gleiche Vektorlänge bedeutet ein passendes Schema; sie belegt nicht, dass zwei Modelle Bedeutung auf dieselbe Weise abbilden.

Eine Vergleichsbasis schaffen, die Suchfehler sichtbar macht

Die erste Konfiguration sollte so einfach sein, dass sich erklären lässt, warum ein bestimmter Treffer erscheint.

1. 1

   Quellabschnitte bilden, die eine Frage beantworten können

   Das Hilfecenter nach Themen oder Abschnitten aufteilen. Dokumenttitel, Quell-URL, Kundenberechtigungen und eine stabile Abschnitts-ID gehören zu jeder Passage. Inhaltlich unabhängige Anweisungen sollten nicht allein deshalb zusammengefasst werden, um das Kontextfenster des Modells auszuschöpfen.

2. 2

   Die Embedding-Konfiguration festlegen

   text-embedding-3-small auswählen und die Ausgabedimension dokumentieren. Alle gespeicherten Passagen mit dieser Konfiguration einbetten und den Vektorindex mit der passenden Dimension anlegen. Den Originaltext separat aufbewahren.

3. 3

   Die Suche vor der Antwortgenerierung testen

   Jede Testfrage mit derselben Konfiguration einbetten, die nächstliegenden Passagen abrufen und prüfen. Eine plausibel formulierte Antwort kann verdecken, dass die Suche die falsche Quelle ausgewählt hat.

4. 4

   Einen Vergleichskandidaten mit denselben Fragen prüfen

   Für large oder Voyage einen separaten Testindex erstellen. Quellabschnitte und Relevanzbewertungen unverändert lassen. Der Wechsel lohnt sich erst, wenn die Verbesserung für die Anwendung einen Unterschied macht.

2. Voyage AI 4: der API-Vergleichskandidat für anspruchsvolle Suche

Die Voyage 4-Familie von Voyage AI bietet gehostete Text-Embeddings und gehört neben die Ausgangsbasis, wenn die Qualität der Informationssuche für das Produkt entscheidend ist. Als erster Vergleichskandidat bietet sich voyage-4 an. Anschließend lässt sich lite im Hinblick auf Latenz und Kosten prüfen oder large als die laut Hersteller qualitativ stärkste Allzweckvariante. Eine Suche in technischer Dokumentation, bei der Kunden denselben Fehler unterschiedlich beschreiben, ist dafür aussagekräftiger als eine Sammlung einfacher Stichworttreffer.

Dimensionen: standardmäßig 1,024; voyage-4-lite, voyage-4 und voyage-4-large unterstützen außerdem 256, 512 und 2,048.
Maximale Eingabe: 32,000 Tokens bei jedem dieser Modelle.
Sprachen und Modalitäten: mehrsprachiger Text; die Modelltabelle nennt keine vollständige Sprachenanzahl. Diese Modelle sind von den separaten multimodalen Voyage-Modellen zu unterscheiden.
Betrieb: gehostete Embeddings-API von Voyage AI. Modellspezifikationen.
Besonders geeignet für: Entwickler, die vor der API-Auswahl einen Vergleich der Suchqualität durchführen möchten.
Besonderheit: kompatible Embeddings innerhalb der allgemeinen Voyage 4-Familie.
Preise: pro Million Eingabetokens $0.02 für 4-lite, $0.06 für 4 und $0.12 für 4-large; geprüft am 15. Oktober 2026. Preise.
Kostenlos testen: Die Preisseite nennt zunächst 200 Millionen kostenlose Tokens für die aktuellen Allzweckmodelle. Das Kontingent sollte für das konkret verwendete Modell geprüft werden.

Die dokumentierte Kompatibilität ist im Betrieb nützlich. Voyage beschreibt für diese Familie einen gemeinsamen Embedding-Raum. Dadurch lässt sich auf der Anfrageseite eine andere Variante testen, ohne automatisch sämtliche Dokumentvektoren neu erstellen zu müssen. Die Ausgabedimensionen müssen übereinstimmen, und genau diese Kombination aus Dokument- und Anfragemodell gehört in den Test. Das Versprechen gilt nicht pauschal für jedes Modell mit dem Namen Voyage.

Die Stolperfalle ist das unbemerkte Abschneiden von Eingaben: Die API-Einstellung truncation steht standardmäßig auf true. Ein langes Dokument kann deshalb einen gültigen Vektor liefern, obwohl sein Ende verworfen wurde. Während der Entwicklung der Datenübernahme sollte truncation=false gesetzt sein, damit zu lange Eingaben sichtbar fehlschlagen und die Aufteilung korrigiert werden kann. Ein großes Kontextfenster bietet Platz für zusammenhängende Passagen; es ist kein Grund, ein ganzes Handbuch zu einem einzigen Suchtreffer zu machen. API-Verhalten.

Für reine Codebestände bietet der Hersteller außerdem voyage-code-4. Der Spezialist sollte anhand von Fragen zum Repository gegen das Allzweckmodell antreten. Einige Codebeispiele in Supportartikeln allein rechtfertigen noch kein Spezialmodell.

3. Google Gemini Embedding 2: die vielseitige multimodale Option

Google Gemini Embedding 2 gehört in die engere Auswahl, wenn eine verwaltete Suche Text mit Bildern, Audio, Video oder PDF-Seiten verbinden soll. Ein Supportsystem mit schriftlichen Anleitungen und aufgezeichneten Produktvorführungen kann diese Quelltypen in einem gemeinsamen Embedding-Raum abbilden. Entscheidend ist, ob diese Modalitäten tatsächlich relevante Informationen liefern. Danach folgt der Suchtest mit den eigenen Quellen. Ein rein textbasiertes Hilfecenter profitiert nicht automatisch von einer größeren Auswahl an Eingabeformaten.

Dimensionen: 128 bis 3,072; Google empfiehlt 768, 1,536 oder 3,072.
Maximale Eingabe: 8,192 Tokens.
Sprachen und Modalitäten: über 100 Sprachen; Text, Bilder, Audio, Video und PDF.
Betrieb: Gemini API mit der stabilen Modell-ID gemini-embedding-2. Modellkarte, Funktionsumfang.
Besonders geeignet für: verwaltete Suche in Quellen, deren Inhalt sich durch reine Textextraktion nicht ausreichend abbilden lässt.
Besonderheit: Audio und Video liegen zusammen mit Text und Bildern im selben Vektorraum.
Preise: regulär pro Million Eingabetokens $0.20 für Text, $0.45 für Bilder, $6.50 für Audio und $12.00 für Video; geprüft am 15. Oktober 2026. Preise.
Kostenlos testen: Ein kostenloser API-Tarif ist innerhalb seiner Nutzungsgrenzen verfügbar.

Die Herausforderung liegt in der formatspezifischen Datenübernahme. Google erlaubt pro Anfrage bis zu 6 Bilder, 180 Sekunden Audio, 120 Sekunden Video oder eine PDF mit bis zu 6 Seiten, jeweils innerhalb der übergreifenden Eingabegrenzen. Bei Video werden höchstens 32 Einzelbilder verarbeitet; die Tonspur des Videos bleibt unberücksichtigt. Für eine kommentierte Vorführung braucht es daher einen eigenen Verarbeitungsplan für die gesprochenen Erläuterungen ebenso wie für die Bilder. Eingabegrenzen.

Zu jedem eingebetteten Element gehört der Zeitstempel oder Seitenverweis. Das richtige Video zu finden hilft weniger, als direkt die relevante Stelle zu öffnen. Bei einer PDF ist der Verweis auf die Seite mit der Antwort hilfreicher als der bloße Dokumenttreffer. Wie gut diese Navigation funktioniert, hängt von der Aufteilung und den Metadaten ab.

Für bestehende Google-Nutzer ist ein Migrationsdetail entscheidend: gemini-embedding-001 und gemini-embedding-2 verwenden inkompatible Embedding-Räume. Eine unveränderte Dimensionsanzahl erhält die Kompatibilität nicht. Google verlangt beim Wechsel ausdrücklich, den vorhandenen Datenbestand neu einzubetten. Migrationshinweise.

4. Cohere Embed 5: Unternehmensdokumente und flexible Betriebsmodelle

Cohere Embed 5 richtet sich an Teams, deren Suchaufgabe in langen Dokumenten, Tabellen, Diagrammen und gemischten Text-Bild-Seiten liegt. Zur aktuellen Familie gehören embed-v5.0-pro und embed-v5.0-fast. Für einen internen Supportassistenten, der visuell strukturierte Handbücher durchsucht, lohnt sich der Vergleich einer seitenbasierten Suche mit der vorhandenen Textextraktion. Die entscheidende Frage lautet, ob die richtige Anweisung den Prozess der Datenübernahme unbeschadet übersteht.

Dimensionen: standardmäßig 2,048; außerdem werden 256, 512, 768, 1,024 und 1,536 unterstützt.
Maximale Eingabe: 128K Tokens bei Pro und Fast.
Sprachen und Modalitäten: über 100 Sprachen; Text, Bilder und gemischte Text-Bild-Eingaben, einschließlich Darstellungen von Dokumentseiten.
Betrieb: Cohere API, Model Vault, Microsoft Foundry und Amazon SageMaker; auch kommerzieller Betrieb in der eigenen VPC oder vor Ort wird unterstützt. Technische Daten, Betriebsoptionen und Sprachabdeckung.
Besonders geeignet für: Unternehmenssuche in Dokumenten, wenn eine gemeinsam genutzte öffentliche API die Betriebsvorgaben nicht erfüllt.
Besonderheit: Pro und Fast teilen einen Embedding-Raum. Ein mit Pro indexierter Datenbestand lässt sich daher mit Fast abfragen.
Preise: $0.08 pro Million Texttokens für Fast oder $0.12 für Pro; für beide sind $0.40 pro Million Bildtokens angegeben, geprüft am 15. Oktober 2026. Textpreise, Bildpreise.
Kostenlos testen: Test-API-Schlüssel mit begrenzter Anfragerate sind kostenlos, dürfen aber weder produktiv noch kommerziell genutzt werden.

Das große Kontextfenster hilft, wenn eine Passage ihren umgebenden Kontext benötigt. Die Gestaltung der Suche nimmt es einem jedoch nicht ab. Enthält ein gefundener Abschnitt ein ganzes Handbuch, muss das Antwortmodell darin weiterhin die relevante Stelle finden. Bevor allein der verfügbare Platz für eine größere Eingabe entscheidet, sollte eine Darstellung mit langem Kontext gegen einzelne Dokumentabschnitte getestet werden.

Cohere unterstützt außerdem float-, int8- und binäre Ausgabedarstellungen. Diese bestimmen, wie die Zahlen eines Vektors gespeichert werden. Kompaktere Darstellungen können Speicherbedarf und Suchverhalten verändern. Deshalb zunächst prüfen, welche Formate die gewählte Datenbank und Suchimplementierung unterstützen, und anschließend die komprimierte Konfiguration selbst messen. Ein Ergebnis mit vollständigen float-Vektoren bestätigt nicht automatisch die Qualität eines kleineren binären Index.

Der Hersteller dokumentiert weiterhin embed-v4.0 mit 128K Kontext und standardmäßig 1,536 Dimensionen. Dieses bestehende Modell ist anhand seiner eigenen Eigenschaften zu bewerten; seine Daten beschreiben nicht die aktuelle Familie. Ebenso macht der Betrieb in eigener Umgebung Embed 5 nicht zu einem Download unter Apache-Lizenz. Die kommerziellen Bereitstellungsbedingungen bleiben Teil der Kaufentscheidung.

5. Qwen3-Embedding: offene Textmodelle mit vielen Stellschrauben

Qwen3-Embedding bietet Entwicklern herunterladbare Text-Embedding-Modelle in verschiedenen Größen. Die Familie gehört damit in die engere Auswahl für den Eigenbetrieb, wenn Datenstandort oder Kontrolle über die Laufzeitumgebung die Architektur bestimmen. Ein Unternehmen, das vertrauliche technische Dokumente durchsucht, sollte mit der kleinsten Variante beginnen, die das gewünschte Relevanzniveau erreicht. Der direkte Griff zum größten Checkpoint kann die Modellwahl zum Infrastrukturprojekt machen, noch bevor klar ist, ob dadurch bessere Antworten entstehen.

Dimensionen: maximale Ausgabegrößen von 1,024 bei 0.6B, 2,560 bei 4B und 4,096 bei 8B; die Familie unterstützt anpassbare Dimensionen.
Maximale Eingabe: 32K Tokens bei diesen Varianten.
Sprachen und Modalitäten: über 100 Sprachen, einschließlich Unterstützung für die Codesuche; Texteingabe. Gemeint ist Qwen3-Embedding, nicht die separate Qwen3-VL-Familie.
Betrieb: auf eigener Infrastruktur anhand der Herstellerbeispiele für Sentence Transformers, Transformers, vLLM oder Text Embeddings Inference. Modellkarte.
Lizenz: Apache 2.0. Lizenzdatei.
Besonders geeignet für: mehrsprachige Textsuche im Eigenbetrieb mit Kontrolle über Modell- und Ausgabegröße.
Besonderheit: Aufgabenanweisungen erlauben es, den Suchauftrag genauer festzulegen.
Preise: offene Modellgewichte, Eigenbetrieb; einen allgemeingültigen Infrastrukturpreis pro Million Tokens gibt es nicht.
Kostenlos testen: Die Modellgewichte lassen sich herunterladen; Laufzeitumgebung und Rechenleistung müssen selbst bereitgestellt werden.

Die Grenzen zeigen sich bei Betriebskosten und Lastverhalten. Indexierungsdurchsatz und Latenz interaktiver Abfragen sollten getrennt gemessen werden. Die nachträgliche Verarbeitung eines Datenbestands verträgt eine Warteschlange; ein Kunde, der auf eine Supportantwort wartet, bemerkt jede zusätzliche Inferenzverzögerung. Batchgröße, Eingabelängen, Hardware und parallele Anfragen bestimmen, ob das größere Modell zum Produkt passt.

Die Suchanweisungen der Modellkarte gehören zur Konfiguration. Das Format der Anfragen muss zusammen mit Checkpoint und Ausgabedimensionen dokumentiert werden. Ein Benchmark mit einem bestimmten Anweisungsformat bestätigt nicht die Eignung eines anderen Prompts im Produktivbetrieb. Beim Modellvergleich sollten die Konventionen auf Dokument- und Anfrageseite unverändert bleiben.

Eigenbetrieb überzeugt vor allem dann, wenn Kontrolle einen eigenen Wert hat oder die gemessene Auslastung den Betriebsaufwand rechtfertigt. Für ein kleines Hilfecenter ist er nicht automatisch der günstigere Weg zu Embeddings. Die geringe Tokenrechnung einer gehosteten API kann schon unter dem Zeitaufwand für die Wartung eines Modelldienstes liegen, selbst ohne die Hardware einzurechnen.

6. BAAI BGE-M3: offene Suche mit mehr als einem dichten Vektor

BAAI BGE-M3 ist ein offenes Modell für die engere Auswahl, wenn ein und dasselbe Modell dichte, dünn besetzte und Multi-Vektor-Darstellungen für die Suche liefern soll. Dichte Vektoren erfassen semantische Ähnlichkeit. Dünn besetzte Darstellungen gewichten lexikalische Merkmale. Bei der Multi-Vektor-Suche bleiben mehrere Vektoren erhalten, um Inhalte differenzierter abzugleichen. Ein Supportbestand mit Produktkennungen und Fehlercodes eignet sich gut zum Vergleich dieser Ansätze: Eine ähnliche Bedeutung allein kann zur falschen konkreten Kennung führen.

Dimensionen: 1,024 für das dichte Embedding; dünn besetzte und Multi-Vektor-Ausgaben haben andere Strukturen.
Maximale Eingabe: 8,192 Tokens.
Sprachen und Modalitäten: mehr als 100 Sprachen; Text.
Betrieb: auf eigener Infrastruktur mit der FlagEmbedding-Implementierung des Herstellers. Modellkarte.
Lizenz: MIT laut den Metadaten der Hersteller-Modellkarte.
Besonders geeignet für: Entwickler, die eine hybride Suche mit lexikalischen und semantischen Signalen testen möchten.
Besonderheit: mehrere Suchdarstellungen aus einer Modellfamilie.
Preise: offene Modellgewichte, Eigenbetrieb; Rechenleistung und Speicher sind selbst zu bezahlen.
Kostenlos testen: herunterladbare Modellgewichte; daraus ergibt sich kein Kontingent für einen gehosteten Dienst.

Die Grenze liegt in der Suchimplementierung: Nur weil das Modell mehrere Darstellungen erzeugt, verwendet die Datenbank sie noch nicht. Wer ausschließlich den dichten Vektor speichert und danach sucht, baut ein Suchsystem mit dichten Vektoren. Dünn besetzte oder Multi-Vektor-Ausgaben erfordern passende Indexierung und Bewertung sowie eine Entscheidung darüber, wie die Ergebnisse zusammengeführt werden.

Als Ausgangspunkt eignet sich die Suche mit dichten Vektoren. Anschließend lässt sich das lexikalische Signal bei den Fragen ergänzen, bei denen es helfen sollte: exakte Bauteilnamen, Fehlermeldungen und Kennungen. Dabei muss geprüft werden, ob diese Verbesserungen das allgemeinere Erkennen von Umschreibungen verschlechtern. Ein Reranker sollte erst hinzukommen, wenn sichtbar ist, welche Kandidatentreffer er korrigieren soll.

BGE-M3 steht wegen dieser Flexibilität auf der Liste. Ein älterer Benchmark zur Veröffentlichung belegt keinen Vorsprung gegenüber jeder aktuellen API. Für einfache dichte Embeddings lohnt sich zunächst ein Vergleich mit Qwen und der gehosteten Ausgangsbasis, bevor zusätzliche Komplexität in die Suche einzieht.

7. Google EmbeddingGemma: lokale Suche in zwei unterschiedlichen Generationen

Google EmbeddingGemma 2 ist der lokale Kandidat, wenn eine Anwendung Text und Medien auf dem Gerät des Nutzers durchsuchen soll. Ein Wissenswerkzeug für den Desktop könnte Notizen zusammen mit Screenshots oder Aufzeichnungen indexieren, ohne jedes Element an eine gehostete Embedding-API zu senden. Das aktuelle Modell und das ursprüngliche embeddinggemma-300m unterscheiden sich bei Eingabeformaten, Kontextlänge und Lizenz. Deshalb muss im Build das genaue Repository festgelegt werden.

Dimensionen: EmbeddingGemma 2 gibt 768 Dimensionen aus; 512, 256 und 128 sind ebenfalls möglich.
Maximale Eingabe: 8,192 Tokens.
Sprachen und Modalitäten: über 100 Sprachen; Text einschließlich Code, Bilder, Video und Audio.
Betrieb: lokal oder auf eigener Infrastruktur; der Hersteller stellt Beispiele für Sentence Transformers bereit. Die insgesamt 740M Parameter umfassen selektiv ladbare Bild- und Audioencoder. Modellkarte.
Lizenz: Apache 2.0 für EmbeddingGemma 2, wie auf der zugehörigen Modellkarte angegeben.
Besonders geeignet für: lokale oder offline arbeitende Anwendungen mit Bedarf an multimodalen Embeddings.
Besonderheit: Es lassen sich gezielt die Encoder für die benötigten Modalitäten laden.
Preise: offene Modellgewichte, Eigenbetrieb; Geräteressourcen und gegebenenfalls gehostete Infrastruktur bleiben eigene Kosten.
Kostenlos testen: herunterladbare Modellgewichte.

Das ursprüngliche EmbeddingGemma-300m bleibt eine eigenständige Option ausschließlich für Text: 300M Parameter, eine Eingabegrenze von 2,048 Tokens, 768 Dimensionen mit 512/256/128 als Alternativen und Training mit über 100 gesprochenen Sprachen. Es läuft über Sentence Transformers, sein Repository verlangt jedoch die Zustimmung zu Googles Gemma-Nutzungsbedingungen. Die Apache-Lizenz von EmbeddingGemma 2 gilt nicht für diesen älteren Checkpoint. Ursprüngliches Modell und Bedingungen.

Die Grenze setzen die Ressourcen des Geräts. Verfügbarer Arbeitsspeicher, Wärmeentwicklung und gleichzeitig laufende Aufgaben sind wichtiger als die bloße Frage, ob sich die Modelldatei laden lässt. Ein Indexierungslauf im Hintergrund sollte getestet werden, während der Nutzer eine gewöhnliche Aufgabe im Vordergrund erledigt. Auch ein kompaktes Modell kann die Anwendung unangenehm machen, wenn die Datenübernahme das Gerät vollständig beansprucht.

Bei verkürzten Vektoren gelten Googles Vorgaben zur Normalisierung; die Dimensionen für Anfragen und Dokumente müssen zusammenpassen. Auch die Aufgabenpräfixe müssen erhalten bleiben. Diese Einstellungen gehören zur Modellbereitstellung und sind keine optionalen Notizen, die sich erst nach einer Veränderung der Suchqualität rekonstruieren lassen.

Welches Modell passt zur Suche oder zum Supportbot?

Konkrete Anforderungen sollten Kandidaten ausschließen, bevor die Qualität verglichen wird. Entscheidend ist, welcher Fehler die Anwendung unbrauchbar machen würde: die Antwort nicht zu finden, visuelle Informationen zu verlieren, Daten an einen unzulässigen Ort zu senden oder zu langsam zu reagieren.

Welche Modelle eignen sich für Text-Embeddings?

Für eine gehostete Textanwendung bieten sich OpenAI small und Voyage 4 als Ausgangspunkt an. OpenAI large ergänzt den Vergleich innerhalb der bestehenden API; Cohere kommt hinzu, wenn Dokumentstruktur und Betrieb in eigener Umgebung wichtig sind. Ein anderer Kandidat sollte erst übernehmen, wenn er die tatsächlichen Probleme der Nutzer bei akzeptabler Latenz und vertretbaren Gesamtkosten verbessert.

Mehrsprachiger Support braucht auch sprachübergreifende Testfälle: eine spanische Frage, die ein englischer Artikel beantwortet, lokale Produktnamen, gemischtsprachige Nachrichten und transliterierte Begriffe. „Unterstützt über 100 Sprachen“ belegt nicht, dass das wirtschaftlich wichtigste Sprachpaar gut funktioniert.

Welche Open-Source-Embedding-Modelle kommen infrage?

Qwen3-Embedding eignet sich als Vergleichskandidat für konfigurierbare Textsuche, BGE-M3 für die Kombination lexikalischer und semantischer Suche und EmbeddingGemma 2 für lokale multimodale Eingaben. Die Lizenz gilt jeweils für den konkreten Checkpoint. Eigenbetrieb ist eine Bereitstellungsentscheidung mit messbaren Betriebskosten und kein Synonym für kostenlose API-Nutzung.

Enthält der Datenbestand fotografierte Anleitungen, Diagramme oder aufgezeichnete Vorführungen, muss bewusst zwischen Textextraktion und dem Erhalt der ursprünglichen Modalität entschieden werden. Textextraktion kann ausreichen und die Fehlersuche vereinfachen. Multimodale Suche ist dann sinnvoll, wenn fehlende Bild- oder Audioinformationen die Antwort verändern.

Welche Embedding-Modelle eignen sich für den lokalen Betrieb?

EmbeddingGemma 2 ist hier der erste Kandidat für lokale multimodale Suche. Die kleinere Variante von Qwen und BGE-M3 gehören in einen reinen Textvergleich. Gemessen werden muss auf der Hardware, die später die Nutzeranfragen verarbeitet. Ein Ergebnis auf einer Entwicklungsworkstation sagt wenig über den Laptop oder kleinen Server aus, der Indexierung und Abfragen gleichzeitig bewältigen soll.

Die Entscheidungsregel: Das einfachste Modell behalten, das die Anforderungen an Relevanz, Latenz, Betriebsort und Sprachen erfüllt. Ein Wechsel lohnt sich, wenn eine getestete Alternative einen wichtigen Fehler behebt und der Nutzen den Migrationsaufwand rechtfertigt.

MTEB einordnen und anschließend mit eigenen Daten testen

Das MTEB-Leaderboard hilft, Kandidaten zu finden; einen allgemeingültigen Sieger bestimmt es nicht. MTEB steht für Massive Text Embedding Benchmark und umfasst Aufgaben wie Informationssuche, Klassifikation, Clustering und Ähnlichkeitsbewertung. Das Leaderboard bietet außerdem Ansichten nach Sprache, Fachgebiet und Modalität. Ein Ergebnis aus einer Aufgabensammlung ist nicht automatisch mit dem Ergebnis einer anderen vergleichbar.

Für RAG zählen Suchergebnisse, die zu den eigenen Sprachen und zum Fachgebiet passen. Bei visuellen Quellen ist ein geeigneter multimodaler Benchmark oder ein Benchmark zur Dokumentensuche relevant. Bevor ein Ergebnis eine Entscheidung begründet, müssen Benchmarkversion und Einstellungen festgehalten werden. Dieser Artikel nennt keine numerischen Leaderboard-Ergebnisse.

Ein sinnvoller erster Test besteht aus 100 tatsächlichen Fragen mit markierten Quellpassagen, die jeweils die Antwort liefern sollten. Das ist ein Vorschlag für eine erste Stichprobe und keine Behauptung statistischer Sicherheit. Dazu gehören Fragen ohne gültige Antwort, mehrdeutige Formulierungen, exakte Kennungen und die verwendeten Sprachkombinationen.

Beim Modellvergleich müssen Quellabschnitte, Berechtigungen, Trefferanzahl und ein eventuell eingesetzter Reranker unverändert bleiben. Sonst lässt sich nicht erkennen, ob das Modell oder die umgebende Verarbeitungskette die Verbesserung verursacht hat. Bei einer Begrenzung auf zehn Treffer misst recall@10, wie viel des relevanten Materials unter diesen Ergebnissen erscheint. nDCG@10 belohnt es, wenn relevantere Treffer weiter oben stehen.

Danach folgt die manuelle Fehleranalyse. Fehlte die richtige Passage, stand sie zu weit unten, wurde sie durch Berechtigungen ausgefiltert oder bei der Extraktion beschädigt? Ein besseres Modell kann keine Quelle reparieren, die nie in den Index gelangt ist. Abfragelatenz und Durchsatz der Datenübernahme sollten getrennt gemessen werden. Nach Änderungen an Dimensionen oder Komprimierung müssen die schwierigen Fälle erneut getestet werden.

Wo lassen sich die Vektoren speichern und abfragen?

Pinecone ist eine verwaltete Vektordatenbank. Sie kann extern erzeugte Vektoren speichern und stellt über ihre Inferenz-API auch ausgewählte Embedding-Modelle bereit. Der Modellkatalog führt llama-text-embed-v2, multilingual-e5-large und pinecone-sparse-english-v0 als Embedding-Optionen für die Inferenz auf. Davon zu unterscheiden ist der Weg, Gemini, OpenAI oder Voyage selbst aufzurufen und die erzeugten Vektoren hochzuladen.

Integrierte Embeddings eignen sich, wenn das unterstützte Modell die eigenen Tests besteht und der Dienst die Umwandlung von Text in Vektoren übernehmen soll. Selbst erzeugte Vektoren sind sinnvoll, wenn die Kontrolle über das Modell, die Medienvorverarbeitung oder einen selbst betriebenen Encoder wichtig ist. Die Indexierungsdokumentation von Pinecone unterscheidet diese Wege.

Bei einem Supportbot gehören Quelltexte, stabile IDs, Metadaten für die Zugriffskontrolle und Quellenverweise zur Sucharchitektur. Ähnlichkeit zwischen Embeddings ist keine Zugriffsberechtigung. Unabhängig von der gewählten Datenbank muss die Anwendung die Suche auf Inhalte begrenzen, die der Nutzer sehen darf.

Der Vergleich der besten Vektordatenbanken behandelt die Speicherentscheidung; der Artikel zu Pinecone-Preisen erklärt die separate Kostenposition. Entscheidet der Assistent selbst, wann er sucht, formuliert er Fragen um oder führt weitere Suchläufe aus, erläutert der Leitfaden zu agentischem RAG diesen Ablauf. Das Embedding-Modell liefert die Darstellung, das Suchsystem entscheidet über ihre Verwendung.

Die Dimensionen bestimmen den Speicherbedarf

Bei der Wahl der Vektordimensionen sollte die Datenbank mitgedacht werden. Mit float32-Präzision belegt jede Zahl vier Bytes. Eine Million Vektoren mit 1,536 Dimensionen benötigen damit 6.144 GB allein für die Vektorwerte; bei 3,072 Dimensionen sind es 12.288 GB. Diese berechneten Werte sind dezimale Gigabytes. Metadaten, Indexstrukturen, Replikate und sonstiger Datenbankaufwand kommen hinzu.

Deshalb kann eine kleinere Ausgabe wichtig sein, selbst wenn Embedding-Tokens günstig sind. Zugleich erklärt das, warum Parameteranzahl und Vektordimensionen nicht verwechselt werden sollten: Die eine betrifft den betriebenen Encoder, die anderen betreffen jede gespeicherte und durchsuchte Darstellung.

Eine Reduzierung der Dimensionen sollte mit dem vom Hersteller unterstützten Verfahren getestet werden. Vektoren eines Modells, das keine solche Funktion dokumentiert, dürfen nicht beliebig abgeschnitten werden. Wo Normalisierung erforderlich ist, muss sie konsequent angewendet werden. Danach sind die verkleinerten Vektoren selbst zu prüfen: Weniger Speicherbedarf hilft nur, solange die Anwendung weiterhin die benötigten Belege findet.

Ein Modellwechsel bedeutet eine Indexmigration

Verwendet das neue Modell einen inkompatiblen Embedding-Raum, muss der Neuaufbau des Datenbestands eingeplant werden. Nur den API-Modellnamen auf der Anfrageseite zu ersetzen und die alten Dokumentvektoren beizubehalten, führt meist zu unpassenden Treffern, selbst bei gleicher Dimensionsanzahl. Googles dokumentierte Migration von embedding-001 zu embedding-2 ist ein ausdrückliches Beispiel dafür.

Es gibt Ausnahmen mit klar definierten Grenzen: Voyage dokumentiert für seine allgemeine 4-Familie einen gemeinsamen Raum, Cohere für das Pro/Fast-Paar von Embed 5. Diese Zusagen erlauben bestimmte modellübergreifende Kombinationen, kein beliebiges Mischen zwischen Anbietern. Die jeweilige Kombination muss getestet werden; Dimensionen und Darstellungsform müssen zusammenpassen.

Der Aufwand für erneutes Einbetten lässt sich anhand der tatsächlichen Eingabetokens schätzen. Beispiel: Eine Million Abschnitte mit durchschnittlich 500 Tokens enthalten 500 Millionen Tokens. Zum veröffentlichten regulären Texttarif von Gemini Embedding 2 kostet der Embedding-Durchlauf rechnerisch $100. Nicht enthalten sind Datenbankschreibvorgänge, vorübergehend doppelte Speicherung, Vorverarbeitung, Abfragen, Entwicklungsaufwand und mögliche Rabatte. Preisquelle.

Die Tokenrechnung ist womöglich der einfache Teil. Zusätzlich braucht es die Quelldokumente, die Einstellungen für ihre Verarbeitung und genügend Kapazität, um das bestehende System während des Neuaufbaus verfügbar zu halten. Zu jeder Indexversion müssen Modell-ID, Dimensionen, Normalisierung, Version der Abschnittsaufteilung und Anweisungen für Anfragen und Dokumente gespeichert werden.

1. 1

   Einen separaten Testindex aufbauen

   Die aufbewahrten Quellabschnitte mit der neuen Konfiguration erneut einbetten. Der bestehende Index beantwortet weiter Anfragen. Stabile Dokument-IDs ermöglichen den Vergleich zusammengehöriger Datensätze.

2. 2

   Tests wiederholen und Verschlechterungen untersuchen

   Den Kandidaten anhand derselben bewerteten Testanfragen vergleichen. Neben Relevanz auch Berechtigungen, Ziele der Quellenverweise, fehlende Dokumente und Abfragelatenz prüfen. Dokumente berücksichtigen, die während der nachträglichen Verarbeitung geändert wurden.

3. 3

   Modell und Index gemeinsam umstellen

   Anfragen mit einer gemeinsamen Konfigurationsänderung auf den passenden neuen Encoder und Index leiten. Das alte Paar lange genug aufbewahren, um zurückkehren zu können, falls sich das Verhalten im Produktivbetrieb von den Testergebnissen unterscheidet.

Wie die Auswahl zustande kam

Diese sieben Modellfamilien übernehmen jeweils eine klare Rolle bei der Auswahl für Suche, RAG und Supportbots. Berücksichtigt wurden veröffentlichte Eingabegrenzen, Dimensionen, Modalitäten, Sprachabdeckung, Betriebsoptionen, Lizenzen und aktuelle Preise. Die Herstellerseiten wurden am angegebenen Prüftag kontrolliert. Die Speicher- und Kostenbeispiele wurden anhand der genannten Annahmen berechnet.

Für diesen Artikel wurden keine Modelle einem Benchmark oder Lasttest unterzogen. Die Reihenfolge empfiehlt einen Testpfad für typische Entwickler textorientierter Anwendungen; sie ist keine gemessene Rangliste der Genauigkeit. Spezialisierte Code-, Fachgebiets- und weitere multimodale Modellfamilien haben keine eigenen Rangplätze erhalten. Sie gehören in die eigene Vorauswahl, wenn genau diese Spezialisierung für die Anwendung entscheidend ist.

Welche Modellwahl sich nicht empfiehlt

OpenAI text-embedding-3 sollte nicht für die direkte Bild- oder Audiosuche gewählt werden. Die Familie verarbeitet Text. Wörter zu extrahieren ist ein gültiger Architekturansatz, verliert aber sämtliche Informationen, die ausschließlich im Bild oder Ton der Quelle stecken.

Ältere Voyage 3-Modelle sollten bei einem Neubau nicht automatisch den Ausgangspunkt bilden. Die aktuelle Voyage-Dokumentation empfiehlt die neuere Familie. Eine bestehende, getestete Bereitstellung kann bleiben, bis ein Grund die Migrationskosten rechtfertigt.

Qwen3-Embedding-8B sollte nicht ohne Messung zur Standardwahl für einen Laptop werden. Zunächst müssen dessen Latenz- und Ressourcengrenzen feststehen. Danach lässt sich prüfen, ob der größere Checkpoint seinen Betriebsaufwand rechtfertigt.

BGE-M3 eignet sich nicht als Begründung für „hybride Suche“, wenn nur seine dichten Vektoren gespeichert werden. Diese Fähigkeit entsteht erst mit einer Sucharchitektur, die auch die zusätzliche Darstellung verwendet.

Nicht alle EmbeddingGemma-Checkpoints stehen unter Apache 2.0. Die aktuelle Modellkarte von EmbeddingGemma 2 nennt Apache 2.0; das ursprüngliche 300M-Repository verwendet die Gemma-Bedingungen. Genaue Versionen sind für den Betrieb ebenso wichtig wie für die Suche.

Häufige Fragen

Welche Embedding-Modelle eignen sich am besten für RAG?

OpenAI text-embedding-3-small bietet eine günstige gehostete Ausgangsbasis für Text. Voyage 4 sollte anhand der eigenen Fragen dagegen getestet werden. Gemini Embedding 2 oder Cohere Embed 5 gehören in den Vergleich, wenn die Modalität der Quelle die Antwort verändert. Qwen3-Embedding, BGE-M3 und EmbeddingGemma sind hier die Kandidaten für den Eigenbetrieb. Entscheidend ist das Modell, das die als relevant markierten Belege zuverlässig findet.

Welche Embedding-Modelle lassen sich kostenlos testen?

Für gehostete Tests bietet Gemini einen kostenlosen API-Tarif. Voyage nennt anfängliche Tokenkontingente, und Cohere stellt Testschlüssel mit begrenzter Anfragerate bereit, die produktive und kommerzielle Nutzung ausschließen. Bevor eine kundenorientierte Anwendung auf kostenlosen Zugang baut, müssen Kontingent und Produktionsbedingungen des konkreten Modells geprüft werden.

Welche kostenlosen Embedding-Modelle kommen für RAG infrage?

Für textbasiertes RAG im Eigenbetrieb lohnt sich der Vergleich von Qwen3-Embedding und BGE-M3. Für lokales multimodales RAG gehört EmbeddingGemma 2 dazu. Ihre herunterladbaren Modellgewichte erlauben den eigenen Betrieb des Encoders, doch Inferenz, Speicher und Wartung benötigen weiterhin Ressourcen. Die Lizenz muss dem genauen Checkpoint zugeordnet bleiben. Beim Vergleich mit einer gehosteten API zählen auch diese Betriebskosten.

Der nächste Schritt: Supportfragen sammeln, an denen die bestehende Suche scheitert, und die Passagen markieren, die sie beantworten sollten. Die Checkliste zur Prüfung von KI-Geschäftsabläufen hilft, Ablauf und Erfolgskriterien festzulegen, bevor der gesamte Datenbestand eingebettet wird.