Dimensioni di incorporamento: dimensioni 768, 1536 o 3072?

Chiaramente, scegliere prima tra text-embedding-3-small e text-embedding-3-large equivale a scegliere tra 1536 e 3072 dimensioni native, prima ancora di parlare di troncamento. La tabella seguente riassume i fatti verificabili sui tre livelli che pgvector riconosce nativamente sul lato dell'indicizzazione e che Aurabase instrada.

Fonti: OpenAI, blog ufficiale “Nuovi modelli di incorporamento e aggiornamenti API”, 25 gennaio 2024 (punteggi MTEB e prezzi di lancio, controllare la pagina dei prezzi attuali prima dell'uso); aura-ai/src/embeddings/mod.rs, Aurabase (colonne e supporto dell'indice, verificato il 24 agosto 2026).

Un incorporamento viene archiviato come un array di numeri in virgola mobile. In pgvector, il classico tipo vector codifica ogni dimensione su 4 byte (float32): 768 dimensioni pesano quindi circa 3 KB di dati grezzi per vettore, 1536 dimensioni circa 6 KB e 3072 dimensioni circa 12 KB, anche prima di contare l'intestazione pgctor e l'overhead della pagina Postgres.

È qui che entra in gioco il tipo halfvec di pgvector, che codifica ciascuna dimensione in 2 byte (float16) invece di 4. Un vettore a 3072 dimensioni memorizzato in halfvec pesa circa 6 KB: esattamente il peso di un vettore a 1536 dimensioni memorizzato nel classico vector.

Conseguenza diretta e non intuitiva: in Aurabase, passare da 1536 a 3072 dimensioni non raddoppia lo spazio di archiviazione effettivo su disco, poiché la colonna embedding_3072 viene interrogata tramite un cast halfvec. Il vero costo aggiuntivo delle dimensioni 3072 non è quindi principalmente il disco: è il prezzo del modello OpenAI associato e l'output del supporto dell'indice nativo del tipo vector, dettagliato nella sezione seguente.

Il tipo vector di pgvector non consente la creazione di un indice HNSW o IVFFlat oltre le 2000 dimensioni. 3072 dimensioni supera quindi questo limite: nessuna query di ricerca vettoriale su una colonna vector(3072) può basarsi su un indice approssimativo, si ricorre ad una scansione sequenziale completa, inutilizzabile sulla scala di un corpus RAG in produzione.

Il codice Aurabase gestisce questo caso in modo esplicito: la colonna embedding_3072 viene convertita in halfvec(3072) su ogni query di inserimento e ricerca, un tipo che pgvector può indicizzare fino a 4000 dimensioni. Le colonne 768 e 1536 rimangono native vector, non convertite, poiché non si avvicinano al limite.

// Per 3072 (>2000), HNSW non indicizza il tipo "vettore" → cast halfvec
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(...), // dimensione non supportata
    }
}

Questo dettaglio spiega anche perché una dimensione di incorporamento non elencata in [768, 1536, 3072] fallisce esplicitamente sul lato Aurabase, anziché essere accettata e quindi indicizzata in modo inadeguato: il nome della colonna proviene sempre da una lista consentita fissa, mai da un valore libero inviato dal client. Per approfondire la creazione di un indice HNSW su Postgres oltre questo caso specifico, vedere il nostro articolo Indice HNSW e ricerca vettoriale Postgres.

A partire da gennaio 2024, l'API Embeddings di OpenAI accetta un parametro dimensions che accorcia il vettore restituito senza richiamare nuovamente un modello diverso. La tecnica si chiama Matryoshka Representation Learning: il modello è addestrato a concentrare le informazioni utili nelle prime dimensioni del vettore, in modo che un troncamento perda precisione gradualmente anziché bruscamente.

OpenAI illustra l'efficacia di questa tecnica con un esempio specifico nel suo annuncio: text-embedding-3-large, troncato a sole 256 dimensioni, supera ancora il punteggio MTEB del vecchio text-embedding-ada-002 utilizzato alla sua dimensione completa di 1536 dimensioni (fonte: OpenAI, blog ufficiale, 25 gennaio 2024). Un vettore 12 volte più piccolo che si comporta meglio di un vettore completo, su questo benchmark specifico.

let body = json!({
    "model": self.embed_model,       // ad es. "incorporamento-testo-3-grande"
    "input": text,
    "dimensions": self.embed_dimensions, // tronca 3072 → il valore configurato
});

Punto importante e spesso frainteso: il troncamento non riduce il prezzo applicato. OpenAI addebita i costi in base al modello richiesto, non alla dimensione del vettore restituito, poiché il costo effettivo è il calcolo eseguito sul testo di input. Richiedere 1536 dimensioni da text-embedding-3-large costa quindi lo stesso prezzo delle sue 3072 dimensioni native (fonte: OpenAI, blog ufficiale, 25 gennaio 2024); cambiano solo la velocità di archiviazione e di ricerca.

Questa è proprio la scelta di default di Aurabase, verificata in config/mod.rs: il modello configurato di default è text-embedding-3-large, ma la dimensione di output configurata di default è 1536, non 3072. Il servizio paga quindi per la rappresentazione del modello wide, troncato per rimanere su una colonna indicizzabile vector in HNSW nativo, senza il cast halfvec richiesto per 3072.

Le dimensioni 1536 rimangono il punto di partenza ragionevole per la maggior parte dei progetti RAG o di ricerca semantica: il punteggio MTEB di text-embedding-3-small (62,3%) rimane vicino a quello del modello large, l'archiviazione rimane leggera e il classico tipo vector degli indici pgctor in HNSW senza alcuna configurazione particolare.

Le dimensioni 3072 sono giustificate quando il corpus è ambiguo o tecnico, dove il divario di qualità tra il 62,3% e il 64,6% si traduce in risultati di ricerca visibilmente migliori sulle tue stesse query, non sul benchmark generale di OpenAI. Diversi feedback del team registrati nelle discussioni della comunità degli sviluppatori OpenAI vanno in questa direzione: il guadagno di 3072 dimensioni viene misurato caso per caso, non può essere dato per scontato.

Le dimensioni 768 sono particolarmente adatte quando il volume ha la precedenza sulle sfumature: un corpus di grandi dimensioni in cui il budget di archiviazione o calcolo è il vero vincolo, o l'uso di un modello di incorporamento legacy già in 768 dimensioni native.

Questa scelta di dimensione fa parte di uno stack RAG più ampio, incorporamenti, indice HNSW, ricerca ibrida, che la nostra pagina AI nativadocumenta.

Le dimensioni 768, 1536 e 3072 non sono divise su un unico asse. 3072 guadagna nel punteggio MTEB pubblicato da OpenAI, ma lascia il supporto HNSW nativo di pgvector e paga il prezzo del modello di grandi dimensioni, qualunque sia la dimensione richiesta alla fine. 1536 rimane il saldo predefinito più comune, anche in Aurabase. 768 serve casi in cui il volume ha la precedenza sulla sfumatura.

Il parametro dimensions di OpenAI cambia la domanda da porsi: non è più "quale modello scegliere", ma "quale troncamento accettare, per quale guadagno misurato sul mio corpus". Prima di finalizzare una scelta produttiva, testare la qualità della ricerca su un campione reale, non solo su un benchmark generale. La nostra guida Pipeline RAG con pgvector descrive in dettaglio la configurazione completa, dall'acquisizione alla ricerca ibrida.