Inbeddingsgrootte: afmetingen 768, 1536 of 3072?

Het is duidelijk dat de keuze tussen text-embedding-3-small en text-embedding-3-large eerst neerkomt op het kiezen tussen 1536 en 3072 native dimensies, voordat er zelfs maar over truncatie wordt gesproken. De onderstaande tabel vat de verifieerbare feiten samen op de drie niveaus die pgvector van nature herkent aan de indexzijde, en die Aurabase-route.

Bronnen: OpenAI, officiële blog “Nieuwe embeddingmodellen en API-updates”, 25 januari 2024 (MTEB-scores en lanceringsprijzen, controleer voor gebruik de huidige prijspagina); aura-ai/src/embeddings/mod.rs, Aurabase (kolommen en indexondersteuning, geverifieerd op 24 augustus 2026).

Een inbedding wordt opgeslagen als een array van drijvende-kommagetallen. In pgvector codeert het klassieke vector-type elke dimensie op 4 bytes (float32): 768 dimensies wegen daarom ongeveer 3 KB aan ruwe gegevens per vector, 1536 dimensies ongeveer 6 KB en 3072 dimensies ongeveer 12 KB, zelfs voordat de pgvector-header en de Postgres-pagina overhead worden geteld.

Dit is waar het halfvec type pgvector in beeld komt, dat elke dimensie codeert in 2 bytes (float16) in plaats van 4. Een 3072-dimensionale vector opgeslagen in halfvec weegt ongeveer 6 KB: precies het gewicht van een 1536-dimensionale vector opgeslagen in de klassieke vector.

Direct en niet-intuïtief gevolg: bij Aurabase verdubbelt het gaan van 1536 naar 3072 dimensies niet de werkelijke opslag op schijf, aangezien de kolom embedding_3072 wordt opgevraagd via een halfveccast. De echte extra kosten van 3072-dimensies zijn daarom niet in de eerste plaats de schijf: het zijn de prijs van het bijbehorende OpenAI-model en de uitvoer van native indexondersteuning van het type vector, zoals beschreven in de volgende sectie.

Met het type pgvector vector is het niet mogelijk een HNSW- of IVFFlat-index te bouwen die groter is dan 2000 dimensies. 3072-dimensies overschrijdt daarom deze limiet: geen enkele vectorzoekopdracht op een vector(3072)-kolom kan vertrouwen op een geschatte index, deze valt terug op een volledige sequentiële scan, onbruikbaar op de schaal van een RAG-corpus in productie.

De Aurabase-code behandelt dit geval expliciet: de kolom embedding_3072 wordt bij elke invoeg- en zoekopdracht omgezet naar halfvec(3072), een type dat pgvector tot 4000 dimensies kan indexeren. Kolommen 768 en 1536 blijven native vector, ongecast, omdat ze de limiet niet naderen.

// Voor 3072 (>2000) indexeert HNSW het type `vector` → cast halfvec niet
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(...), // niet-ondersteunde afmeting
    }
}

Dit detail verklaart ook waarom een inbeddingsdimensie die niet wordt vermeld in [768, 1536, 3072] expliciet mislukt aan de Aurabase-kant, in plaats van te worden geaccepteerd en vervolgens slecht geïndexeerd: de kolomnaam komt altijd van een vaste toelatingslijst, nooit van een gratis waarde die door de klant is verzonden. Om dieper in te gaan op het bouwen van een HNSW-index op Postgres buiten dit specifieke geval, zie ons artikel HNSW-index en Postgres vector zoeken.

Vanaf januari 2024 accepteert de Embeddings API van OpenAI een parameter dimensions die de geretourneerde vector verkort zonder opnieuw een ander model aan te roepen. De techniek heet Matryoshka Representation Learning: het model is getraind om nuttige informatie in de eerste dimensies van de vector te concentreren, zodat een afknotting geleidelijk aan nauwkeurigheid verliest in plaats van abrupt.

OpenAI illustreert de effectiviteit van deze techniek met een specifiek voorbeeld in de aankondiging: text-embedding-3-large, ingekort tot slechts 256 dimensies, overtreft nog steeds de MTEB-score van de oude text-embedding-ada-002, gebruikt op volledige grootte van 1536 dimensies (bron: OpenAI, officiële blog, 25 januari 2024). Een vector die 12 keer kleiner is en beter presteert dan een volledige vector, op deze specifieke benchmark.

let body = json!({
    "model": self.embed_model,       // bijv. "tekst-embedding-3-groot"
    "input": text,
    "dimensions": self.embed_dimensions, // kapt 3072 af → de geconfigureerde waarde
});

Belangrijk punt, en vaak verkeerd begrepen: afkappen verlaagt de aangerekende prijs niet. OpenAI brengt kosten in rekening op basis van het opgevraagde model, niet op basis van de grootte van de geretourneerde vector, aangezien de werkelijke kosten de berekening zijn die op de invoertekst wordt uitgevoerd. Het opvragen van 1536 dimensies uit text-embedding-3-large kost daarom dezelfde prijs als de 3072 oorspronkelijke dimensies (bron: OpenAI, officiële blog, 25 januari 2024); alleen de opslag- en zoeksnelheid veranderen.

Dit is precies de standaardkeuze van Aurabase, geverifieerd in config/mod.rs: het standaard geconfigureerde model is text-embedding-3-large, maar de standaard geconfigureerde uitvoerdimensie is 1536, niet 3072. De service betaalt daarom voor de weergave van het brede model, afgekapt om op een indexeerbare vector-kolom in native HNSW te blijven, zonder de halfvec-cast die vereist is naar 3072.

1536-dimensies blijven het redelijke uitgangspunt voor de meeste RAG- of semantische zoekprojecten: de MTEB-score van text-embedding-3-small (62,3%) blijft dicht bij die van het grote model, de opslag blijft licht en de klassieke vector-type pgvector-indexen in HNSW zonder enige specifieke configuratie.

3072-dimensies zijn gerechtvaardigd als het corpus dubbelzinnig of technisch is, waarbij de kwaliteitskloof tussen 62,3% en 64,6% zich vertaalt in zichtbaar betere zoekresultaten op uw eigen zoekopdrachten, niet op de algemene OpenAI-benchmark. Verschillende teamfeedback die is opgenomen in de discussies in de OpenAI-ontwikkelaarsgemeenschap wijzen in deze richting: de winst van 3072 dimensies wordt van geval tot geval gemeten en kan niet worden aangenomen.

768-dimensies zijn vooral geschikt wanneer volume voorrang heeft op nuance: een groot corpus waarbij het opslag- of berekeningsbudget de echte beperking is, of het gebruik van een oud inbeddingsmodel dat al in 768 native dimensies aanwezig is.

Deze dimensiekeuze maakt deel uit van een grotere RAG-stack, insluitingen, HNSW-index, hybride zoeken, die onze pagina Native AIdocumenten.

De afmetingen 768, 1536 en 3072 zijn niet verdeeld over één enkele as. 3072 wint in MTEB-score gepubliceerd door OpenAI, maar verlaat de eigen HNSW-ondersteuning van pgvector en betaalt de prijs van het grote model, ongeacht de uiteindelijk gevraagde dimensie. 1536 blijft het meest voorkomende standaardsaldo, ook bij Aurabase. 768 dient gevallen waarin volume voorrang heeft op nuance.

De parameter dimensions van OpenAI verandert de te stellen vraag: het is niet langer "welk model ik moet kiezen", maar "welke inkorting moet ik accepteren, voor welke winst wordt gemeten op mijn corpus". Voordat u een keuze maakt tijdens de productie, test u de zoekkwaliteit op een echt monster, en niet alleen op een algemene benchmark. Onze gids RAG-pijplijn met pgvector beschrijft de volledige installatie, van opname tot hybride zoeken.