Choisir la dimension des embeddings pour la recherche sémantique

Introduction

Si tu construis de la recherche sémantique (RAG, moteur interne, FAQ), choisir la dimension des embeddings est une décision technique simple en apparence mais qui a un vrai impact sur le coût, la latence et la qualité des réponses.

Ce guide pratique (testé sur des modèles open-source courants) explique :

• les principes pour prendre une décision
• un protocole de benchmark A/B reproductible
• des exemples concrets (modèles 384d vs 768d)
• une recette two-stage (index rapide + rerank) quand tu veux le meilleur des deux mondes

Je m’appuie sur des fiches modèles (Hugging Face), la documentation fournisseurs d’embeddings et nos articles internes sur la recherche sémantique.

Pourquoi la dimension importe

La “dimension” d’un embedding est la longueur du vecteur qui représente un document ou un passage. C’est la capacité expressive du vecteur : plus il y a de dimensions, plus on peut encoder de nuances, mais :

• stockage : taille totale = N_documents * dimension * bytes_per_float
• temps de similarité : calculs de produit scalaire / cosine sont proportionnels
• coût d’indexation et de recherche (surtout en CPU/serveur cloud)
• algorithmique : certains algorithmes ANN (IVF, PQ) demandent des paramètres différents selon la dimension

Exemples de modèles (sources primaires) :

• all-MiniLM-L6-v2 : 384 dimensions (Hugging Face model card)
• all-mpnet-base-v2 : 768 dimensions (Hugging Face model card)
• Documentation fournisseurs (OpenAI, etc.) pour les modèles commerciaux — vérifie la dimension indiquée sur la page produit.

Compromis : règles simples

• Prototype rapide → commence par 384d (MiniLM) : rapide et économique.
• Besoin de finesse → teste 768d (MPNet) ou plus.
• Index large (millions) + contrainte budget → 384d souvent prioritaire.
• Données multi-domaines / textes longs → préférer dimension plus grande.
• Meilleure pratique : two-stage (index 384d + rerank 768d) pour limiter le coût.

Protocole de benchmark A/B (obligatoire)

Avant de changer quoi que ce soit en production, fais un benchmark reproductible.

1. Jeu de test

• Rassemble 200–500 requêtes réelles représentatives.
• Pour chaque requête, crée un gold set (1–5 documents pertinents).

2. Métriques

• précision@1, @5
• MRR (Mean Reciprocal Rank)
• latence moyenne (encode + query + rerank)
• taille index (Go)

3. Pipeline de test

• Encoder les documents avec Modèle A (384d) → indexer → mesurer.
• Encoder avec Modèle B (768d) → indexer → mesurer.
• Toujours mesurer sur le même hardware ou répéter sur une VM identique.

4. Critère de décision

• Si gain métrique significatif (statistical/operational) ET coût/latence admissible → passer à la plus grande dimension.
• Sinon : garder la petite dimension et équiper un reranker.

Exemple de script Python minimal pour A/B (encoding + mesure)

Voici un squelette que tu peux adapter selon ton vector store (Faiss, Annoy, Milvus, Pinecone) :

from sentence_transformers import SentenceTransformer
import faiss
import numpy as np
import time

# modèles
mA = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2') # 384d
mB = SentenceTransformer('sentence-transformers/all-mpnet-base-v2') # 768d

# documents = list of texts
# queries = list of (query_text, gold_ids)

def build_index(model, docs):
    emb = model.encode(docs, show_progress_bar=True, convert_to_numpy=True)
    emb = np.array(emb).astype('float32')
    faiss.normalize_L2(emb)
    index = faiss.IndexFlatIP(emb.shape[1])
    index.add(emb)
    return index, emb

# Mesure simple : précision@k

Two-stage pipeline (pratique recommandée)

1. Index rapide (384d)

• Indexe tout en 384d. Requête pour obtenir top-N rapides (N≈50).

2. Reranker fin (768d)

• Réencode les N candidats avec un modèle plus expressif ou utilise embeddings pré-calculés en 768d et applique un rerank strict.

Avantages : grosse réduction du coût (tu ne fais le rerank que sur N candidats) et meilleure précision finale.

Quantization et compression

Si ton index est massif, la quantization est utile : PQ (product quantization), OPQ, quantization 8/4 bits. Elle réduit l’empreinte tout en gardant une précision acceptable. Attention :

• la quantization impacte différemment selon la dimension ;
• les hyperparamètres (nlist, m, bits) doivent être testés pour chaque dimension.

Cas d’usage & recommandations rapides

• FAQ / support interne (≈500–50k docs) : 384d, index CPU + rerank quand nécessaire.
• Recherche d’articles longs / documentation technique : 768d ou pipeline two-stage.
• Multilingue + contenu juridique/médical : favoriser un modèle plus riche et une évaluation stricte.

Sources primaires consultées

• Hugging Face — sentence-transformers/all-MiniLM-L6-v2 (384d) https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2

• Hugging Face — sentence-transformers/all-mpnet-base-v2 (768d) https://huggingface.co/sentence-transformers/all-mpnet-base-v2

• Documentation fournisseurs d’embeddings (guides produits) — vérifie la dimension et les recommandations sur la page produit (OpenAI, Hugging Face, etc.)

• Article interne : “RAG PME — guide recherche sémantique” (blog) — pour architecture et intégration RAG.

Checklist de déploiement (pratique)

• Jeu de test représentatif (200–500 requêtes) et gold set
• Script d’encodage et indexation reproduit (Docker/CI)
• Mesures enregistrées (CSV) : pr@1,@5, MRR, latence, index size
• Policy de rollback si latence > seuil
• Assets documentés pour reproduire le benchmark

Ce qu’il faut retenir

• La dimension des embeddings n’est pas une décision binaire : c’est un compromis entre précision et coût.
• Prototyper avec 384d, benchmark propre, puis monter en dimension si la métrique l’exige.
• Two-stage (384d index + 768d rerank) est souvent le meilleur compromis en production.

Si tu veux, je lance le benchmark A/B sur ton index : fournis le dump des documents ou l’accès au vector store et un fichier de 200 requêtes. Je peux :

• générer le script d’encodage + indexation (Faiss/Pinecone/Weaviate),
• exécuter localement ou sur une VM, stocker les résultats CSV et produire un rapport simple avec la décision recommandée.

---

Tags: embeddings, recherche sémantique, RAG, sentence-transformers