Choisir la dimension de ses embeddings (768/1536/3072) : impact perf/coût

En clair, choisir entre text-embedding-3-small et text-embedding-3-large revient d'abord à choisir entre 1536 et 3072 dimensions natives, avant même de parler de troncature. Le tableau ci-dessous résume les faits vérifiables sur les trois paliers que reconnaît nativement pgvector côté indexation, et que route Aurabase.

Sources : OpenAI, blog officiel « New embedding models and API updates », 25 janvier 2024 (scores MTEB et tarifs de lancement, à vérifier sur la page de tarification actuelle avant usage) ; services/aura-ai/src/embeddings/mod.rs, Aurabase (colonnes et support d'index, vérifié le 24 août 2026).

Un embedding se stocke comme un tableau de nombres à virgule flottante. En pgvector, le type vector classique encode chaque dimension sur 4 octets (float32) : 768 dimensions pèsent donc environ 3 Ko de données brutes par vecteur, 1536 dimensions environ 6 Ko, et 3072 dimensions environ 12 Ko, avant même de compter l'en-tête pgvector et l'overhead de page Postgres.

C'est là qu'intervient le type halfvec de pgvector, qui encode chaque dimension sur 2 octets (float16) au lieu de 4. Un vecteur en 3072 dimensions stocké en halfvec pèse environ 6 Ko : exactement le poids d'un vecteur en 1536 dimensions stocké en vector classique.

Conséquence directe et peu intuitive : chez Aurabase, passer de 1536 à 3072 dimensions ne double pas le stockage réel sur disque, puisque la colonne embedding_3072 est interrogée via un cast halfvec. Le vrai surcoût de 3072 dimensions n'est donc pas d'abord le disque : c'est le tarif du modèle OpenAI associé, et la sortie du support d'index natif du type vector, détaillée dans la section suivante.

Le type vector de pgvector ne permet pas de construire un index HNSW ou IVFFlat au-delà de 2000 dimensions. 3072 dimensions dépasse donc cette limite : aucune requête de recherche vectorielle sur une colonne vector(3072) ne peut s'appuyer sur un index approximatif, elle retombe sur un scan séquentiel complet, inutilisable à l'échelle d'un corpus RAG en production.

Le code d'Aurabase gère ce cas explicitement : la colonne embedding_3072 est castée en halfvec(3072) à chaque requête d'insertion et de recherche, un type que pgvector sait indexer jusqu'à 4000 dimensions. Les colonnes 768 et 1536 restent en vector natif, sans cast, puisqu'elles n'approchent pas la limite.

// Pour 3072 (>2000), HNSW n'indexe pas le type `vector` → 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(...), // dimension non supportée
    }
}

Ce détail explique aussi pourquoi une dimension d'embedding non listée dans [768, 1536, 3072] échoue explicitement côté Aurabase, plutôt que d'être acceptée puis mal indexée : le nom de colonne provient toujours d'une allowlist fixe, jamais d'une valeur libre envoyée par le client. Pour creuser la construction d'un index HNSW sur Postgres au-delà de ce cas précis, voir notre article index HNSW et recherche vectorielle Postgres.

Depuis janvier 2024, l'API Embeddings d'OpenAI accepte un paramètre dimensions qui raccourcit le vecteur renvoyé sans réappeler un modèle différent. La technique s'appelle Matryoshka Representation Learning : le modèle est entraîné pour concentrer l'information utile dans les premières dimensions du vecteur, de sorte qu'une troncature perd de la précision progressivement plutôt que brutalement.

OpenAI illustre l'efficacité de cette technique avec un exemple précis dans son annonce : text-embedding-3-large, tronqué à 256 dimensions seulement, dépasse encore le score MTEB de l'ancien text-embedding-ada-002 utilisé à sa pleine taille de 1536 dimensions (source : OpenAI, blog officiel, 25 janvier 2024). Un vecteur 12 fois plus petit qui fait mieux qu'un vecteur complet, sur ce benchmark précis.

let body = json!({
    "model": self.embed_model,       // ex. "text-embedding-3-large"
    "input": text,
    "dimensions": self.embed_dimensions, // tronque 3072 → la valeur configurée
});

Point important, et souvent mal compris : tronquer ne réduit pas le prix facturé. OpenAI facture selon le modèle interrogé, pas selon la taille du vecteur renvoyé, puisque le coût réel est le calcul effectué sur le texte d'entrée. Demander 1536 dimensions à text-embedding-3-large coûte donc le même tarif que ses 3072 dimensions natives (source : OpenAI, blog officiel, 25 janvier 2024) ; seuls le stockage et la vitesse de recherche changent.

C'est précisément le choix par défaut d'Aurabase, vérifié dans config/mod.rs : le modèle configuré par défaut est text-embedding-3-large, mais la dimension de sortie configurée par défaut est 1536, pas 3072. Le service paie donc la représentation du modèle large, tronquée pour rester sur une colonne vector indexable en HNSW natif, sans le cast halfvec requis à 3072.

1536 dimensions reste le point de départ raisonnable pour la majorité des projets RAG ou de recherche sémantique : le score MTEB de text-embedding-3-small (62,3 %) reste proche de celui du modèle large, le stockage reste léger, et le type vector classique de pgvector s'indexe en HNSW sans configuration particulière.

3072 dimensions se justifie quand le corpus est ambigu ou technique, là où l'écart de qualité entre 62,3 % et 64,6 % se traduit par des résultats de recherche visiblement meilleurs sur vos propres requêtes, pas sur le benchmark général d'OpenAI. Plusieurs retours d'équipes recensés dans les discussions de la communauté développeurs OpenAI vont dans ce sens : le gain de 3072 dimensions se mesure au cas par cas, il ne se suppose pas.

768 dimensions convient surtout quand le volume prime sur la nuance : un corpus volumineux où le budget de stockage ou de calcul est la contrainte réelle, ou l'usage d'un modèle d'embedding legacy déjà en 768 dimensions natives.

Ce choix de dimension s'inscrit dans une pile RAG plus large, embeddings, index HNSW, recherche hybride, que documente notre page IA native.

768, 1536 et 3072 dimensions ne se départagent pas sur un seul axe. 3072 gagne en score MTEB publié par OpenAI, mais sort du support HNSW natif de pgvector et paie le tarif du modèle large, quelle que soit la dimension finalement demandée. 1536 reste l'équilibre par défaut le plus courant, y compris chez Aurabase. 768 sert les cas où le volume prime sur la nuance.

Le paramètre dimensions d'OpenAI change la question à se poser : ce n'est plus « quel modèle choisir », mais « quelle troncature accepter, pour quel gain mesuré sur mon corpus ». Avant de figer un choix en production, testez la qualité de recherche sur un échantillon réel, pas seulement sur un benchmark général. Notre guide pipeline RAG avec pgvector détaille la mise en place complète, de l'ingestion à la recherche hybride.