text-embedding-3-large ist OpenAIs qualitativ hochwertigeres Embedding-Modell, veröffentlicht am 25. Januar 2024 zusammen mit dem kleineren text-embedding-3-small. Ein Embedding-Modell erzeugt keinen Text — es wandelt ein Textstück in einen Vektor fester Länge um, der dessen Bedeutung erfasst, sodass zwei bedeutungsähnliche Textstücke als Vektoren enden, die in diesem numerischen Raum nahe beieinanderliegen. Diese Eigenschaft macht Embeddings nützlich für semantische Suche, Clustering, Deduplizierung, Empfehlungen und Retrieval-Augmented Generation (RAG), wo ein System die relevantesten Passagen finden muss, bevor es sie an ein Sprachmodell übergibt.
Was „large" gegenüber „small" bringt
Standardmäßig erzeugt text-embedding-3-large einen Vektor mit 3.072 Dimensionen, gegenüber 1.536 bei text-embedding-3-small. Auf OpenAIs eigenem MTEB-Benchmark, einer Standardsuite zur Bewertung der Embedding-Qualität über Retrieval-, Klassifikations- und Clustering-Aufgaben hinweg, erzielt large 64,6 gegenüber 62,3 bei small — eine reale, aber nicht enorme Qualitätslücke. Das größere Modell erfasst mehr Nuance pro Embedding, was vor allem bei schwierigeren Retrieval-Aufgaben zählt: das Unterscheiden eng verwandter Dokumente, Arbeiten in weniger verbreiteten Domänen oder Sprachen, oder das gegenseitige Ranking vieler ähnlicher Kandidaten.
Der dimensions-Parameter
Beide Modelle unterstützen einen dimensions-Parameter, der den Ausgabevektor durch Kürzung verkürzt, ohne den Text erneut durch ein anderes Modell einbetten zu müssen. Laut OpenAI übertrifft ein auf 256 Dimensionen gekürzter text-embedding-3-large-Vektor weiterhin das ältere, ungekürzte Modell text-embedding-ada-002 bei dessen nativen 1.536 Dimensionen. Das ist operativ bedeutsam: Ein kürzerer Vektor benötigt weniger Speicher in einer Vektordatenbank und lässt sich zur Abfragezeit günstiger und schneller vergleichen — der dimensions-Parameter ist also ein echter Hebel, um einen kleinen Teil der Retrieval-Qualität gegen deutlich geringere Indexgröße und Suchlatenz einzutauschen, ohne das Modell zu wechseln oder die Pipeline neu zu bauen.
Unter der Haube
Die maximale Eingabelänge beträgt 8.192 Token pro Anfrage. Die Ausgabe ist rein embeddingbasiert — es gibt keine Textgenerierung, keine Chat-Schnittstelle, keinen Werkzeugeinsatz. Das Modell ist Text-rein, Vektor-raus, und sonst nichts, was seine Integrationsfläche klein hält: Ein einzelner API-Aufruf nimmt einen String entgegen und liefert ein Array von Floats fester Größe zurück.
Wann Sie large statt small wählen
Greifen Sie zu text-embedding-3-large, wenn die Retrieval-Qualität der Flaschenhals ist: ein RAG-System, das relevante Passagen verpasst, eine Suchfunktion, die Beinahe-Treffer statt des richtigen Ergebnisses liefert, oder eine Clustering-Aufgabe, bei der feine Unterscheidungen zwischen ähnlichen Elementen zählen. Es ist auch die besser begründbare Standardwahl bei der Arbeit in weniger verbreiteten Sprachen oder spezialisierten Domänen, wo ein kleinerer Embedding-Raum weniger Platz hat, um Nuancen abzubilden.
Für sehr hochvolumige Indexierung — Millionen von Dokumenten, oder einen Workload, bei dem Abfragelatenz und Speicherkosten das Design dominieren — ist text-embedding-3-small, oder ein per dimensions-Parameter gekürztes large-Embedding, meist der praktischere Ausgangspunkt. Die MTEB-Lücke zwischen beiden Modellen ist real, aber moderat, daher lohnt es sich, beide an einer repräsentativen Stichprobe der eigenen Daten zu testen, statt sich allein aufgrund der Annahme „größer ist besser" standardmäßig für large zu entscheiden.
Alternativen im Vergleich
text-embedding-ada-002 bleibt als OpenAIs Embedding-Modell der vorherigen Generation verfügbar, wird aber von beiden aktuellen Modellen qualitativ übertroffen, selbst bei einem Bruchteil von deren Dimensionalität — es gibt also wenig Grund, es für neue Arbeiten zu wählen. Außerhalb von OpenAIs eigener Reihe bieten mehrere andere Anbieter allgemeine Text-Embedding-Modelle mit vergleichbarer Positionierung an; die richtige Wahl läuft meist darauf hinaus, die Retrieval-Qualität am eigenen Korpus zu testen statt sich allein auf Benchmark-Werte zu verlassen, da MTEB-Leistung sich nicht immer sauber auf eine bestimmte Domäne überträgt.