Stratégie d'embeddings pour les systèmes RAG avancés

Stratégie d'embedding pour systèmes RAG avancés

Le choix de la stratégie d'embedding est la décision architecturale la plus sous-estimée dans la conception d'un système RAG. On déploie souvent le premier modèle disponible, on l'utilise en production pendant six mois, puis on découvre que 30% des requêtes échouent par manque de précision — et que migrer un index vectoriel de plusieurs millions de vecteurs est une opération douloureuse.

Voici le panorama des stratégies disponibles et le cadre pour choisir la bonne.

Dense vs Sparse : deux philosophies de représentation

Les embeddings denses (BERT, E5, GTE, OpenAI) projettent un texte dans un espace vectoriel continu de dimension fixe (768 à 3072 dimensions). La similarité sémantique se mesure par proximité cosinus. Puissants pour la compréhension sémantique, mais opaques et peu efficaces sur les requêtes lexicales exactes.

Les embeddings sparse (BM25, SPLADE, BGE-M3 en mode sparse) produisent des vecteurs de très haute dimension (taille du vocabulaire) mais très creux. La plupart des dimensions sont à zéro — seuls les termes présents ont des poids non-nuls. Excellents pour les requêtes lexicales précises, noms propres, identifiants techniques.

La dichotomie n'est plus aussi stricte : BGE-M3 produit simultanément des représentations denses, sparse et multi-vecteurs depuis un seul modèle, ce qui en fait une option très attractive pour les systèmes hybrides.

Bi-encodeurs vs Cross-encodeurs

Bi-encodeur : encode séparément la requête et le document, compare les représentations. Rapide à l'inférence (O(1) par requête sur un index pré-calculé). Adapté au retrieval à grande échelle.

Cross-encodeur : encode conjointement la requête et le document. Voit l'interaction entre les deux. Beaucoup plus précis mais quadratique en complexité — impossible à utiliser pour le retrieval initial, indispensable pour le re-ranking.

# Architecture recommandée : bi-encoder pour retrieval, cross-encoder pour re-ranking
from sentence_transformers import SentenceTransformer, CrossEncoder
 
# Retrieval : bi-encoder (rapide, scalable)
bi_encoder = SentenceTransformer("BAAI/bge-large-en-v1.5")
query_embedding = bi_encoder.encode(query)
candidates = vector_store.search(query_embedding, top_k=100)
 
# Re-ranking : cross-encoder (précis, appliqué aux top-K candidats seulement)
cross_encoder = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")
scores = cross_encoder.predict([(query, doc.text) for doc in candidates])
reranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
final_context = [doc for doc, _ in reranked[:5]]

ColBERT : l'interaction tardive

ColBERT (Contextualized Late Interaction over BERT) est une architecture qui combine les avantages des bi-encodeurs et des cross-encodeurs. Elle encode séparément la requête et les documents en multi-vecteurs (un vecteur par token), puis calcule une similarité par interaction tardive (MaxSim operator).

Score(Q, D) = Σ_qi max_dj (qi · dj)

Le gain est significatif : ColBERT atteint des performances proches du cross-encoder avec une complexité de retrieval bien inférieure. RAGatouille facilite l'intégration de ColBERT dans des pipelines LangChain/LlamaIndex.

Adaptation au domaine

Un modèle généraliste sur un corpus spécialisé sous-performe systématiquement. Les options pour l'adaptation :

• Fine-tuning avec contrastive learning : construire des paires (requête, document positif, documents négatifs) et fine-tuner avec une loss InfoNCE
• Domain-adaptive pre-training : continuer le pre-training sur votre corpus avant le fine-tuning de retrieval
• Matryoshka Representation Learning (MRL) : modèles qui supportent des dimensions réduites sans perte proportionnelle de qualité (OpenAI text-embedding-3-* l'implémente nativement)

Comparaison de performances sur benchmarks MTEB

Snapshot : données consultées en janvier 2025. Les scores MTEB, les prix et les modèles disponibles évoluent rapidement — vérifier le MTEB Leaderboard avant toute décision. Ne pas adosser un choix produit à ce tableau seul.

Recommandations pratiques

1. Évaluez sur vos données, pas sur les leaderboards : un jeu de test propriétaire de 200-500 paires (requête, document pertinent) est systématiquement plus prédictif qu'un benchmark générique. Un modèle classé 3ème sur MTEB peut être meilleur que le 1er sur votre corpus spécifique. Construire cet eval set avant de choisir un modèle est la décision la plus rentable du projet.

2. Pour les systèmes budget-contraints : bge-large-en-v1.5 hébergé localement offre le meilleur rapport qualité/coût. Pas de coût marginal, 512 tokens max est suffisant pour la plupart des chunks bien conçus.

3. Pour les systèmes haute précision : combinez voyage-large-2 ou E5-mistral pour le bi-encoder avec un cross-encoder ms-marco pour le re-ranking. Ajoutez ColBERT si le budget le permet.

4. Pour le multilingue : multilingual-e5-large ou BGE-M3 — ce dernier étant particulièrement robuste sur les requêtes mixtes langues.

5. Dimensionnalité : ne réduisez les dimensions que si la contrainte est réelle (coût de stockage, latence). Avec MRL, préférez une réduction native plutôt qu'une PCA post-hoc.

La stratégie d'embedding est un investissement long terme. Migrer un index de production est coûteux — faites le bon choix dès la conception.