18.02.2024 AI Engineering5 Minuten Lesezeit

Matryoshka-Embeddings: Kürzere Vektoren in text-embedding-3

OpenAIs text-embedding-3-Modelle vom 25. Januar 2024 können Vektoren über den dimensions-Parameter gezielt verkürzen. Wir erklären die zugrunde liegende Technik, Matryoshka Representation Learning, prüfen die Benchmark-Zahlen und rechnen die Speicherersparnis im großen Maßstab durch. Zugleich zeigen wir, warum der Umstieg von ada-002 trotzdem eine vollständige Neu-Einbettung des Korpus erfordert.

Warum Embedding-Dimensionen zum Kostenfaktor wurden

Jedes Retrieval-System auf Embedding-Basis speichert pro Textabschnitt einen Vektor. Dessen Dimension gibt das Modell vor. text-embedding-ada-002, seit Dezember 2022 der Standard von OpenAI, liefert 1536 Dimensionen — 6.144 Byte pro Vektor in float32. Bei hundert Millionen Chunks sind das 614 GB an reinen Vektordaten, vor jeder Indexstruktur. HNSW-Indizes halten Vektoren im Arbeitsspeicher; die Dimensionszahl bestimmt damit Speicherkosten, Latenz und Hardware-Dimensionierung nahezu linear.

Bis Januar ließ sich diese Dimension nicht an den Anwendungsfall anpassen. Eine nachträgliche Reduktion per PCA ist zwar möglich, ergänzt die Pipeline jedoch um eine trainierte Transformation, die versioniert und auf jede Anfrage konsistent angewendet werden muss. Zugleich verschlechtert sie die Retrieval-Qualität auf schwer vorhersagbare Weise. Die meisten Teams bezahlten daher für 1536 Dimensionen, unabhängig vom tatsächlichen Bedarf. Die Rechnung erschien an anderer Stelle: in größeren Indizes, mehr RAM und langsameren Distanzberechnungen.

Dokumente werden gechunkt, eingebettet und indexiert — Vektoren plus Volltext. 1/4

Was OpenAI am 25. Januar veröffentlicht hat

Am 25. Januar 2024 hat OpenAI zwei neue Embedding-Modelle veröffentlicht. text-embedding-3-small erzeugt 1536 Dimensionen und kostet 0,00002 $ pro 1.000 Token — fünfmal weniger als ada-002 mit 0,0001 $. Der MTEB-Durchschnitt steigt von 61,0 auf 62,3, der mehrsprachige MIRACL-Durchschnitt von 31,4 auf 44,0. text-embedding-3-large erzeugt bis zu 3072 Dimensionen für 0,00013 $ pro 1.000 Token und erreicht 64,6 auf MTEB sowie 54,9 auf MIRACL.

Die strukturelle Neuerung ist weniger das Benchmark-Delta als der API-Parameter dimensions. Beide Modelle können gekürzte Vektoren zurückgeben; laut OpenAI wurden sie mit einer Technik trainiert, die einen kontrollierten Tausch zwischen Performance und Kosten erlaubt. Die Ankündigung erwähnt diese Technik nur knapp. Dahinter steht Matryoshka Representation Learning, veröffentlicht im Mai 2022 — lange vor dem Produktlaunch.

Matryoshka Representation Learning kompakt

MRL stammt von Kusupati et al. (arXiv:2205.13147) und wurde auf der NeurIPS 2022 vorgestellt. Das Problem: Konventionelles Training verteilt Information über alle Dimensionen eines Embeddings; schneidet man den Vektor ab, zerstört man seine Geometrie. MRL legt zusätzliche Trainingsverluste auf verschachtelte Präfixe des Vektors — typischerweise Halbierungsschritte wie 64, 128, 256 bis zur vollen Dimension —, sodass bereits die ersten m Dimensionen ein brauchbares Embedding bilden.

Das Paper berichtet bis zu 14-fach kleinere Embeddings bei gleicher Klassifikationsgenauigkeit auf ImageNet-1K, ohne Mehrkosten zur Inferenzzeit. Information interpoliert zudem: Auch Dimensionen zwischen den explizit trainierten Größen bleiben aussagekräftig. Die Struktur ist grob-zu-fein, wie die namensgebenden Schachtelpuppen — frühe Dimensionen tragen die allgemeinste Semantik, spätere fügen zunehmend Detail hinzu.

Vektoren kürzen mit minimalem Qualitätsverlust

Mit text-embedding-3 übergeben Sie entweder den Parameter dimensions im API-Aufruf, oder Sie kürzen den vollen Vektor selbst. Wer selbst trunkiert, muss das Ergebnis auf Einheitslänge renormalisieren: OpenAI liefert normalisierte Vektoren aus, und Indizes, die das Skalarprodukt als Kosinus-Ersatz verwenden, verlassen sich auf genau diese Eigenschaft. Nach den von OpenAI veröffentlichten Zahlen erreicht text-embedding-3-large, auf 256 Dimensionen gekürzt, noch 62,0 auf MTEB — mehr als das volle 1536-dimensionale ada-002 mit 61,0, bei zwölfmal weniger Gleitkommazahlen pro Vektor.

Ebenso wichtig sind die Grenzen des Verfahrens. Die Token-Preise ändern sich nicht, denn abgerechnet wird pro Eingabe-Token und unabhängig von der Ausgabegröße. Gekürzte Vektoren machen unterschiedliche Modellräume außerdem nicht vergleichbar. Und der Qualitätsverlust ist zwar klein, aber messbar: 64,6 bei 3072 Dimensionen gegenüber 62,0 bei 256. Ob diese Differenz relevant ist, entscheidet Ihre Retrieval-Aufgabe, nicht der Benchmark.

Die Speicherrechnung im großen Maßstab

Float32 kostet 4 Byte pro Dimension, und im Korpusmaßstab ist die Arithmetik unerbittlich. Die Tabelle kombiniert die von OpenAI veröffentlichten MTEB-Durchschnitte mit dem reinen Vektorspeicher für einen Korpus von 100 Millionen Chunks. Index-Overhead, Replikate und Backups kommen zu diesen Zahlen in jedem Fall noch hinzu.

Meist limitiert der Arbeitsspeicher, nicht die Festplatte. Ein HNSW-Index über 3072-dimensionale float32-Vektoren braucht die vollen 1,23 TB im RAM plus Graph-Overhead; mit 256 Dimensionen passt derselbe Korpus in 102 GB. Das MRL-Paper zeigt außerdem adaptives Retrieval: Kandidaten mit kurzem Präfix vorauswählen, die Shortlist mit vollen Vektoren nachranken — mit bis zu 14-facher Beschleunigung in der Wall-Clock-Zeit bei vergleichbarer Genauigkeit.

Modell	Dimensionen	MTEB-Schnitt	Byte pro Vektor (float32)	Speicher für 100 Mio. Vektoren
text-embedding-ada-002	1536	61,0	6.144	614 GB
text-embedding-3-small	1536	62,3	6.144	614 GB
text-embedding-3-small	512	61,6	2.048	205 GB
text-embedding-3-large	3072	64,6	12.288	1,23 TB
text-embedding-3-large	1024	64,1	4.096	410 GB
text-embedding-3-large	256	62,0	1.024	102 GB

Migration bedeutet vollständige Neuindexierung

Embedding-Räume verschiedener Modelle sind zueinander inkompatibel. Eine mit text-embedding-3-small eingebettete Anfrage kann keine ada-002-Dokumente durchsuchen, und auch gekürzte Vektoren der neuen Modelle werden dadurch nicht mit alten vergleichbar; eine Konvertierungsfunktion existiert nicht. Der Umstieg bedeutet deshalb: jeden Chunk im Korpus neu einbetten und jeden Index neu aufbauen. Eine Abkürzung gibt es nicht — und auch die beiden neuen Modelle spannen untereinander verschiedene Räume auf.

Die API-Rechnung ist dabei der kleinere Posten: Eine Milliarde Token kosten 20 $ mit 3-small und 130 $ mit 3-large. Aufwendig ist der Betrieb — Batch-Pipelines unter Rate-Limits, eine Dual-Write-Phase für Systeme ohne Ausfallfenster und eine Retrieval-Evaluation auf eigenen Daten vor der Umschaltung. MRL liefert immerhin eine praktische Option: Speichern Sie einmal die vollen 3072 Dimensionen, lassen sich kürzere Indizes später durch Trunkierung ableiten, ohne die API erneut aufzurufen.

Messen Sie, bevor Sie migrieren. Einige hundert annotierte Frage-Dokument-Paare aus der eigenen Domäne sagen mehr als jedes Leaderboard. Lassen Sie sie gegen den alten und den neuen Index laufen, in voller und gekürzter Dimension, und lassen Sie die Deltas die Konfiguration entscheiden. In unseren Projekten ist dieses Evaluationsset das am besten wiederverwendbare Artefakt einer Migration.

Ausblick vom Februar 2024

Wir erwarten, dass Matryoshka-Training zur Standardeigenschaft von Embedding-Modellen wird, statt ein Alleinstellungsmerkmal von OpenAI zu bleiben. Die Open-Source-Seite hat binnen drei Wochen nachgezogen: Nomic hat am 14. Februar 2024 nomic-embed-text-v1.5 veröffentlicht — mit MRL trainiert, skalierbar von 768 bis hinunter zu 64 Dimensionen, mit offenen Gewichten und offenen Trainingsdaten. Bei 256 Dimensionen erreicht es 61,04 auf MTEB — weniger als einen Punkt unter der vollen Größe.

Zwei Entwicklungen halten wir von hier aus für wahrscheinlich. Vektordatenbanken werden Multi-Resolution-Indizes und Trunkierung zur Abfragezeit nativ unterstützen. Außerdem wird MRL mit skalarer und binärer Quantisierung kombiniert werden, die bei den 4 Byte pro Dimension statt bei der Dimensionszahl ansetzt — dadurch multiplizieren sich die Ersparnisse. Speicher dürfte damit aufhören, die Modellwahl zu diktieren. Unverändert bleibt die Arbeit, die kein Launch-Post übernimmt: Retrieval-Qualität auf dem eigenen Korpus zu messen.