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 fixe discrètement le plafond de qualité de tout votre système RAG, et en changer après coup est une migration complète de ré-embedding.

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. Un modèle à 1536 dimensions transforme chaque entrée en 1536 floats. Des textes de sens proche atterrissent près les uns des autres dans cet espace ; des textes sans rapport atterrissent loin. La proximité se mesure par similarité cosinus ou produit scalaire, et c'est toute l'astuce de la recherche sémantique : embeddez la requête, trouvez les vecteurs de documents les plus proches, et vous avez le texte le plus pertinent.

La raison pour laquelle ça bat la recherche par mots-clés, c'est que le sens n'est pas les mots. "Comment annuler mon forfait" et "étapes pour résilier un abonnement" ne partagent presque aucun vocabulaire, mais leurs embeddings sont juste à côté l'un de l'autre, donc une recherche vectorielle trouve le bon document sans aucun recoupement de mots-clés. Le même mécanisme alimente le clustering, la déduplication, la recommandation et, bien sûr, la moitié retrieval du RAG.

"annuler mon abonnement"  ->  [ 0.02, -0.41,  0.88, ... ]  -.
"résilier mon forfait"    ->  [ 0.05, -0.39,  0.85, ... ]  -+-- cosinus ~ 0.95  (proche)
"réinitialiser mon mdp"   ->  [ 0.61,  0.12, -0.30, ... ]  ---- cosinus ~ 0.20  (loin)

Choisir un modèle : les vrais compromis

Commencez par un modèle en API pour valider le cas d'usage sans infrastructure. Passez à un modèle open source auto-hébergé seulement quand le coût par appel, la latence ou la résidence des données l'imposent vraiment, et budgétez le travail d'exploitation qui va avec.

Comment les comparer : le benchmark MTEB

MTEB, le Massive Text Embedding Benchmark, classe les modèles d'embedding sur des tâches de retrieval, de classification, de clustering et de reranking dans de nombreuses langues. Regardez la colonne retrieval, pas la moyenne globale, et filtrez le classement sur les langues de votre corpus. Ensuite, traitez-le comme une présélection : lancez votre propre petite évaluation sur vos données, une douzaine de vraies requêtes avec les documents qu'elles devraient retourner, parce que l'adéquation au domaine bat régulièrement un rang de benchmark.

Dimensionnalité : plus grand n'est pas toujours mieux

Un embedding de plus haute dimension, 3072 contre 1536 par exemple, capture plus de nuances, mais il coûte plus cher à stocker, est plus lent à chercher, et prend plus de mémoire d'index. De nombreux modèles récents supportent une troncature à la Matryoshka : vous pouvez couper un vecteur de 3072 dimensions à 512 ou 256 et garder l'essentiel de la qualité de retrieval. La baisse de précision est en général faible et le gain de stockage et de vitesse est important, mais mesurez-la sur vos propres données avant de vous fixer sur une taille.

Les embeddings multimodaux

Certains modèles embeddent le texte et les images dans le même espace, donc une requête texte peut récupérer une image pertinente et une image peut récupérer du texte lié. Les modèles à la CLIP ont commencé cela, et des modèles d'embedding multimodaux plus récents gèrent des documents qui mélangent texte et figures, des catalogues produit avec photos, ou des captures d'écran. Sortez-en un seulement quand votre corpus n'est vraiment pas que du texte : un modèle texte dédié bat toujours un multimodal sur du retrieval texte pur, donc la recherche cross-modale doit être un vrai besoin, pas un confort.

Générer un embedding

from openai import OpenAI

client = OpenAI()

response = client.embeddings.create(
    model="text-embedding-3-small",
    input="Migrer un monolithe Laravel vers des microservices",
    dimensions=512,  # troncature Matryoshka, sous la valeur par défaut
)

vector = response.data[0].embedding  # une liste de 512 floats

Quand fine-tuner un modèle d'embedding

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, en général des milliers. Avant d'en arriver là, la plupart des équipes gagnent plus avec un meilleur chunking, un reranker, ou de la recherche hybride. Quand le fine-tuning a du sens, entraîner un petit adaptateur au-dessus d'un bon modèle de base, avec une librairie comme sentence-transformers, suffit en général ; vous entraînez rarement de zéro.

Les détails opérationnels qui piquent plus tard

• ✓Normalisez de façon cohérente : si le modèle renvoie des vecteurs non normalisés, normalisez avant de stocker pour que similarité cosinus et produit scalaire concordent.
• ✓Batchez vos appels d'embedding : une requête par document est lent et cher à toute échelle réelle.
• ✓Notez le modèle et sa version dans les métadonnées de chaque vecteur, pour savoir quels vecteurs viennent de quel modèle pendant une migration.
• ✓Cachez les embeddings des documents inchangés et ne ré-embeddez que ce qui a réellement changé.
• ✓Chunkez avant d'embedder : chaque modèle a une limite de tokens et tronque silencieusement au-delà, donc un long document embeddé d'un bloc perd sa fin.

FAQ

Qu'est-ce qu'un text embedding ?

Un vecteur de nombres, produit par un modèle, qui représente le sens d'un morceau de texte. Des textes de sens proche ont des vecteurs proches, ce qui permet de chercher par le sens plutôt que par mot-clé.

Quel modèle d'embedding utiliser ?

Commencez par un modèle en API comme OpenAI text-embedding-3 ou Cohere Embed pour valider le cas d'usage sans infrastructure. Passez à un modèle open source auto-hébergé, BGE, E5 ou GTE, quand le coût par appel, la latence ou la résidence des données l'imposent. Regardez la colonne retrieval du classement MTEB pour vos langues, puis lancez une petite évaluation sur vos propres données.

Combien de dimensions faut-il ?

Souvent moins que la valeur par défaut. 512 à 1024 dimensions couvrent la plupart des cas de retrieval, et la troncature Matryoshka permet de raccourcir un vecteur plus grand avec une faible perte de qualité. Plus de dimensions veut dire plus de stockage et une recherche plus lente, donc mesurez la baisse de précision sur vos données avant de payer la taille complète.

Les embeddings fonctionnent-ils entre les langues ?

Avec un modèle multilingue, oui. Cohere Embed et les variantes multilingues de BGE et E5 mappent différentes langues dans un espace partagé, donc une requête dans une langue peut récupérer des documents dans une autre. Un modèle monolingue ne le fait pas, donc faites correspondre le modèle aux langues de votre corpus.

Les embeddings sont la fondation dont dépend chaque décision de retrieval en aval. Choisissez un modèle adapté à vos langues et à votre domaine, gardez les dimensions pas plus grandes que nécessaire, et traitez un changement de modèle comme une migration. Bien choisir tôt, et le reste de la stack RAG a quelque chose de solide sur quoi se construire.