Einbettungsgröße: 768, 1536 oder 3072 Abmessungen?

Offensichtlich bedeutet die Wahl zwischen „text-embedding-3-small“ und „text-embedding-3-large“ zunächst die Wahl zwischen 1536 und 3072 nativen Dimensionen, bevor überhaupt über die Kürzung gesprochen wird. Die folgende Tabelle fasst die überprüfbaren Fakten zu den drei Ebenen zusammen, die pgvector auf der Indexierungsseite nativ erkennt, und zur Aurabase-Route.

Quellen: OpenAI, offizieller Blog „Neue Einbettungsmodelle und API-Updates“, 25. Januar 2024 (MTEB-Ergebnisse und Einführungspreise, vor der Verwendung auf der aktuellen Preisseite prüfen); aura-ai/src/embeddings/mod.rs, Aurabase (Spalten- und Indexunterstützung, verifiziert am 24. August 2026).

Eine Einbettung wird wie ein Array von Gleitkommazahlen gespeichert. In pgvector kodiert der klassische Typ vector jede Dimension auf 4 Bytes (float32): 768 Dimensionen wiegen daher etwa 3 KB Rohdaten pro Vektor, 1536 Dimensionen etwa 6 KB und 3072 Dimensionen etwa 12 KB, noch bevor der pgvector-Header und der Postgres-Seiten-Overhead mitgezählt werden.

Hier kommt der pgvector-Typ halfvec ins Spiel, der jede Dimension in 2 Bytes (float16) statt in 4 kodiert. Ein in halfvec gespeicherter 3072-dimensionaler Vektor wiegt etwa 6 KB: genau das Gewicht eines im klassischen vectorgespeicherten 1536-dimensionalen Vektors.

Direkte und nicht intuitive Konsequenz: Bei Aurabase verdoppelt der Wechsel von 1536 auf 3072 Dimensionen nicht den tatsächlichen Speicherplatz auf der Festplatte, da die Spalte embedding_3072 über eine halfvec-Umwandlung abgefragt wird. Die tatsächlichen zusätzlichen Kosten von 3072-Dimensionen sind daher nicht in erster Linie auf die Festplatte zurückzuführen: Es handelt sich um den Preis des zugehörigen OpenAI-Modells und die Ausgabe der nativen Indexunterstützung vom Typ vector, die im folgenden Abschnitt näher erläutert wird.

Der pgvector-Typ vector erlaubt keine Erstellung eines HNSW- oder IVFFlat-Index über 2000 Dimensionen hinaus. 3072-Dimensionen überschreiten daher diesen Grenzwert: Keine Vektorsuchabfrage für eine vector(3072)-Spalte kann sich auf einen ungefähren Index verlassen, sie greift auf einen vollständigen sequentiellen Scan zurück, der im Maßstab eines RAG-Korpus in der Produktion unbrauchbar ist.

Der Aurabase-Code behandelt diesen Fall explizit: Die Spalte embedding_3072 wird bei jeder Einfüge- und Suchabfrage in halfvec(3072) umgewandelt, ein Typ, den pgvector bis zu 4000 Dimensionen indizieren kann. Die Spalten 768 und 1536 bleiben nativ vectorund werden nicht übertragen, da sie den Grenzwert nicht erreichen.

// Für 3072 (>2000) indiziert HNSW den Typ „vector“ nicht → wandelt halfvec um
fn vec_query_parts(dims: usize) -> AuraResult<(&'static str, &'static str, &'static str)> {
    match dims {
        768  => Ok(("embedding_768",  "", "::vector")),
        1536 => Ok(("embedding_1536", "", "::vector")),
        3072 => Ok(("embedding_3072", "::halfvec(3072)", "::halfvec(3072)")),
        other => Err(...), // nicht unterstützte Dimension
    }
}

Dieses Detail erklärt auch, warum eine Einbettungsdimension, die nicht in [768, 1536, 3072] aufgeführt ist, auf der Aurabase-Seite explizit fehlschlägt, anstatt akzeptiert und dann schlecht indiziert zu werden: Der Spaltenname stammt immer aus einer festen Zulassungsliste, niemals aus einem vom Client gesendeten freien Wert. Weitere Informationen zum Aufbau eines HNSW-Index auf Postgres über diesen speziellen Fall hinaus finden Sie in unserem Artikel HNSW-Index und Postgres-Vektorsuche.

Ab Januar 2024 akzeptiert die Embeddings-API von OpenAI einen dimensions-Parameter, der den zurückgegebenen Vektor verkürzt, ohne ein anderes Modell erneut aufzurufen. Die Technik heißt Matryoshka Representation Learning: Das Modell wird darauf trainiert, nützliche Informationen in den ersten Dimensionen des Vektors zu konzentrieren, sodass eine Kürzung nicht abrupt, sondern allmählich an Präzision verliert.

OpenAI veranschaulicht die Wirksamkeit dieser Technik anhand eines konkreten Beispiels in seiner Ankündigung: text-embedding-3-large, auf nur 256 Dimensionen gekürzt, übertrifft immer noch den MTEB-Score des alten text-embedding-ada-002, das in seiner vollen Größe von 1536 Dimensionen verwendet wird (Quelle: OpenAI, offizieller Blog, 25. Januar 2024). Ein zwölfmal kleinerer Vektor, der bei diesem speziellen Benchmark eine bessere Leistung als ein vollständiger Vektor erbringt.

let body = json!({
    "model": self.embed_model,       // z.B. „text-embedding-3-large“
    "input": text,
    "dimensions": self.embed_dimensions, // kürzt 3072 → den konfigurierten Wert
});

Wichtiger und oft missverstandener Punkt: Eine Kürzung führt nicht zu einer Reduzierung des berechneten Preises. OpenAI-Gebühren basieren auf dem abgefragten Modell und nicht auf der Größe des zurückgegebenen Vektors, da die tatsächlichen Kosten die Berechnung sind, die am Eingabetext durchgeführt wird. Das Anfordern von 1536 Dimensionen von text-embedding-3-large kostet daher den gleichen Preis wie die 3072 nativen Dimensionen (Quelle: OpenAI, offizieller Blog, 25. Januar 2024); Lediglich die Speicher- und Suchgeschwindigkeit ändert sich.

Dies ist genau die Standardauswahl von Aurabase, die in config/mod.rsüberprüft wurde: Das standardmäßig konfigurierte Modell ist text-embedding-3-large, aber die standardmäßig konfigurierte Ausgabedimension ist 1536und nicht 3072. Der Dienst zahlt daher für die Darstellung des breiten Modells, gekürzt, um auf einer indizierbaren vector-Spalte in nativem HNSW zu verbleiben, ohne die erforderliche halfvec-Umsetzung auf 3072.

1536-Dimensionen bleiben der vernünftige Ausgangspunkt für die meisten RAG- oder semantischen Suchprojekte: Der MTEB-Score von text-embedding-3-small (62,3 %) bleibt nahe an dem des großen Modells, der Speicher bleibt gering und der klassische vector-Typ von pgvector-Indizes in HNSW ohne besondere Konfiguration.

3072-Dimensionen sind gerechtfertigt, wenn der Korpus mehrdeutig oder technisch ist und der Qualitätsunterschied zwischen 62,3 % und 64,6 % zu sichtbar besseren Suchergebnissen bei Ihren eigenen Suchanfragen führt, nicht beim allgemeinen OpenAI-Benchmark. Mehrere Team-Feedbacks, die in den Diskussionen der OpenAI-Entwickler-Community aufgezeichnet wurden, deuten in diese Richtung: Der Gewinn von 3072 Dimensionen wird von Fall zu Fall gemessen, er kann nicht angenommen werden.

768-Dimensionen eignen sich besonders dann, wenn Volumen Vorrang vor Nuancen hat: ein großer Korpus, bei dem das Speicher- oder Berechnungsbudget die eigentliche Einschränkung darstellt, oder die Verwendung eines alten Einbettungsmodells, das bereits in nativen 768-Dimensionen vorhanden ist.

Diese Dimensionsauswahl ist Teil eines größeren RAG-Stacks, Einbettungen, HNSW-Index und Hybridsuche, den unsere Seite Native AIdokumentiert.

Die Abmessungen 768, 1536 und 3072 sind nicht auf einer einzigen Achse unterteilt. 3072 steigert den von OpenAI veröffentlichten MTEB-Score, verlässt jedoch die native HNSW-Unterstützung von pgvector und zahlt den Preis des großen Modells, unabhängig von der letztendlich angeforderten Dimension. 1536 bleibt das häufigste Standardguthaben, auch bei Aurabase. 768 bedient Fälle, in denen Lautstärke Vorrang vor Nuancen hat.

Der Parameter dimensions von OpenAI ändert die zu stellende Frage: Es geht nicht mehr darum, „welches Modell ich wählen soll“, sondern „welche Kürzung ich akzeptieren soll, für welchen Gewinn, gemessen an meinem Korpus“. Bevor Sie eine endgültige Entscheidung für die Produktion treffen, testen Sie die Suchqualität anhand einer realen Stichprobe und nicht nur anhand eines allgemeinen Benchmarks. Unser Leitfaden RAG-Pipeline mit pgvector beschreibt detailliert die vollständige Einrichtung, von der Aufnahme bis zur Hybridsuche.