Les embeddings : comprendre et choisir son modèle
Chaque système RAG de cette série s'appuie sur les embeddings sans jamais les expliquer. Voici ce qu'est réellement un embedding, comment choisir un modèle, et quand le fine-tuning en vaut la peine.
Chaque article RAG de ce blog suppose que vous savez ce qu'est un embedding et passe directement au chunking et au retrieval. Celui-ci comble ce manque,parce que le modèle d'embedding choisi détermine silencieusement le plafond de qualité de tout votre système RAG.
Ce qu'est réellement un embedding
Un embedding est un vecteur,une liste de nombres,qui représente le sens d'un morceau de texte. Des textes de sens proche finissent en vecteurs proches dans cet espace vectoriel, ce qui rend possible la recherche par similarité : trouver les vecteurs les plus proches d'un vecteur de requête, et on trouve le texte le plus pertinent sémantiquement.
Choisir un modèle : les vrais compromis
- ✓OpenAI text-embedding-3 : bonne qualité généraliste, paiement à l'usage, zéro infrastructure à gérer.
- ✓Cohere embed : bon support multilingue,utile quand le contenu couvre plusieurs langues.
- ✓Open-source (sentence-transformers, BGE, E5) : auto-hébergé, zéro coût par appel, mais l'infrastructure de serving est à votre charge et la qualité varie selon le modèle.
Dimensionnalité : plus grand n'est pas toujours mieux
Des embeddings de plus haute dimension (3072 vs 1536, par exemple) capturent plus de nuances mais coûtent plus cher à stocker et à chercher. De nombreux modèles récents supportent une troncature à la Matryoshka, permettant de réduire le vecteur à une dimension plus petite avec une perte de qualité limitée quand le stockage ou la vitesse de recherche compte plus que la précision maximale.
from openai import OpenAI
client = OpenAI()
response = client.embeddings.create(
model="text-embedding-3-small",
input="Migrer un monolithe Laravel vers des microservices",
)
vector = response.data[0].embedding
print(len(vector)) # 1536 dimensionsQuand fine-tuner ses embeddings
Fine-tuner un modèle d'embedding n'est rentable qu'avec un jeu de données labellisé conséquent de paires requête-document propres à votre domaine. La plupart des équipes gagnent plus à améliorer d'abord la stratégie de chunking et la logique de retrieval,le fine-tuning est une optimisation tardive, pas un point de départ.
Ne changez pas de modèle d'embedding à la légère une fois en production. Changer de modèle implique de ré-embedder tout votre corpus, puisque les vecteurs de modèles différents ne sont pas comparables,à planifier comme une migration, pas comme un changement de config.
Les embeddings sont la fondation dont dépend chaque décision de retrieval en aval. Bien choisir le modèle tôt évite une coûteuse migration de ré-embedding plus tard.
Besoin d'aide sur ce sujet ? Intégration IA & RAG
Découvrir ce service →