Embeddings : représenter le sens — RAG : de la théorie à la production

Table des matières

Ce que mesure réellement un embedding

Un embedding est une représentation numérique dense d'un texte — mot, phrase, paragraphe — sous la forme d'un vecteur de nombres réels, le plus souvent entre 256 et 4096 dimensions. Ce vecteur n'a pas de sens interprétable dimension par dimension : ce qui compte est la position relative des vecteurs entre eux. Deux textes de sens proche produisent des vecteurs proches ; deux textes sans rapport produisent des vecteurs éloignés.

C'est cette propriété, et uniquement elle, qui rend le RAG possible. Un moteur de recherche vectorielle ne « comprend » pas une requête : il calcule une distance entre le vecteur de la requête et les vecteurs des passages indexés, puis retourne les plus proches. Toute la qualité d'un pipeline RAG repose donc sur cette projection sémantique, en amont de tout raisonnement produit par le modèle génératif. Un moteur de génération excellent branché sur une récupération médiocre produit des réponses fluides mais construites sur de mauvaises sources — un défaut invisible à la lecture mais déterminant sur le fond.

Un embedding encode une similarité statistique apprise sur un corpus d'entraînement, pas une équivalence logique. Deux phrases peuvent être vectoriellement proches sans être interchangeables dans un contexte métier — par exemple « annuler la commande » et « modifier la commande » partagent un contexte lexical fort tout en déclenchant des actions opposées dans un système transactionnel.

Deux formulations proches sémantiquement produisent des vecteurs proches (angle θ faible), tandis qu'un texte sans rapport se projette loin, avec un angle bien plus large.

Du mot au vecteur : une évolution technique récente

Les premiers systèmes d'embedding, word2vec et GloVe (2013-2014), attribuaient un vecteur fixe à chaque mot du vocabulaire, indépendamment de son contexte d'emploi. Le mot « avocat » recevait le même vecteur qu'il désigne un fruit ou une profession — une limite structurelle pour toute tâche de recherche fine, puisque le sens réel d'un mot ne se fixe qu'en contexte.

L'arrivée des modèles transformer contextuels (BERT, 2018) a changé la donne : chaque token reçoit un vecteur qui dépend de son contexte de phrase. Mais ces modèles n'étaient pas conçus pour produire directement un vecteur de phrase comparable par similarité — il fallait les détourner de leur usage d'origine (moyenne des vecteurs de tokens, ou vecteur du token spécial de début de séquence), avec des résultats médiocres pour la recherche.

La rupture est venue des architectures bi-encoder entraînées spécifiquement pour la similarité, popularisées par Sentence-BERT en 2019 : deux textes sont encodés séparément par le même réseau, puis le modèle apprend par contraste à rapprocher les paires pertinentes et à éloigner les paires non pertinentes — y compris des « négatifs durs », des textes lexicalement proches mais sémantiquement différents, qui forcent une distinction plus fine que la simple superposition de mots. C'est ce paradigme qui structure les modèles d'embedding actuels : text-embedding-3 (OpenAI), embed-v3 (Cohere), mistral-embed, ou les familles ouvertes BGE, E5, GTE et Nomic Embed.

Un modèle génératif classique n'est pas conçu pour produire de bons embeddings de recherche, même s'il est techniquement possible d'en extraire un état caché. Les modèles d'embedding dédiés sont entraînés avec un objectif différent — la perte contrastive — qui optimise directement la géométrie de l'espace vectoriel pour la similarité, et non pour la génération de texte.

Cette distinction a une conséquence pratique : les modèles récents sont entraînés en deux temps, un pré-entraînement à grande échelle sur des paires faiblement supervisées, puis un affinage sur des jeux de données de recherche construits (MS MARCO et équivalents). Certains sont symétriques, optimisés pour comparer deux textes similaires (paraphrase, doublons) ; d'autres sont asymétriques, entraînés pour la recherche où une requête courte doit matcher un passage plus long — un choix qui influence l'architecture du système RAG visé.

Mesurer la similarité : cosinus, produit scalaire, distance euclidienne

Trois métriques dominent la recherche vectorielle. Elles ne sont pas interchangeables : le choix doit correspondre à la métrique utilisée lors de l'entraînement du modèle.

Métrique	Ce qu'elle mesure	Sensible à la norme du vecteur	Usage typique
Similarité cosinus	L'angle entre deux vecteurs	Non	Standard pour la majorité des modèles de recherche
Produit scalaire	Angle et magnitude combinés	Oui	Modèles entraînés explicitement pour cette métrique
Distance euclidienne (L2)	Distance géométrique directe	Oui	Équivalente au cosinus si les vecteurs sont normalisés à la norme 1

Sur des vecteurs normalisés (norme égale à 1), le classement produit par ces trois métriques devient strictement identique — ce qui explique pourquoi certains moteurs vectoriels normalisent systématiquement les vecteurs à l'indexation, quelle que soit la métrique affichée.

Utiliser une métrique différente de celle prévue par le modèle dégrade silencieusement le classement des résultats, sans qu'aucune erreur ne soit levée : vérifiez systématiquement la documentation du modèle avant de configurer l'index vectoriel, en particulier lors d'une migration entre deux bases vectorielles.

Modèles multilingues et recherche cross-lingue

Un modèle d'embedding multilingue projette plusieurs langues dans un espace vectoriel partagé, ce qui permet de poser une question en français et de retrouver un passage pertinent rédigé en anglais. Des modèles comme multilingual-e5, LaBSE ou les versions multilingues de Cohere sont conçus pour cet usage.

En pratique, la qualité cross-lingue varie fortement selon les langues et le domaine traité. La plupart des corpus d'entraînement restent centrés sur l'anglais ; le français bénéficie d'un support correct sur le vocabulaire général, mais se dégrade sur le jargon technique ou les formulations juridiques précises, faute d'exemples suffisants dans les données d'entraînement.

Une base de connaissances juridique en français utilisant un modèle multilingue généraliste peut mal distinguer « résiliation » et « résolution » du contrat — deux notions juridiques précises mais lexicalement proches. Un test de recall ciblé sur des paires question/réponse issues du métier permet de détecter ce type de confusion avant la mise en production, alors qu'un benchmark public généraliste ne le révèlera pas.

Pour un corpus strictement francophone, un modèle monolingue ou un modèle multilingue solide sur le français reste souvent préférable à un modèle générique optimisé en priorité pour l'anglais. Le choix ne devrait jamais reposer sur un score de classement général publié par le fournisseur, mais sur une évaluation menée avec du vocabulaire représentatif du corpus final.

Dimension, quantization et coût de stockage

Un vecteur plus grand n'améliore pas systématiquement la qualité de recherche : au-delà d'un certain seuil, le gain de précision devient marginal alors que le coût de stockage et de calcul augmente linéairement avec la dimension. Un index de plusieurs millions de vecteurs à 3072 dimensions consomme un espace disque et une mémoire vive nettement supérieurs à un index à 768 dimensions, pour un gain de recall souvent marginal.

Deux techniques permettent de réduire ce coût sans réentraîner de modèle :

La quantization — convertir les vecteurs de flottants 32 bits vers des entiers 8 bits, voire des représentations binaires, divise le stockage par 4 à 32, au prix d'une perte de recall généralement faible et mesurable sur un jeu de test dédié.
Les embeddings Matryoshka (Matryoshka Representation Learning) — certains modèles récents restent performants même après troncature du vecteur à une dimension plus courte, par exemple de 1536 à 256, en conservant l'essentiel du signal de similarité. Cela permet d'ajuster le compromis stockage/précision après coup, sans réindexer avec un autre modèle.

Le choix de l'index vectoriel (HNSW, IVF, ou recherche exacte brute) influence également ce compromis entre latence, mémoire et exhaustivité du résultat retourné, indépendamment du modèle d'embedding lui-même — un sujet traité plus en détail dans le chapitre consacré à l'architecture de récupération.

Fine-tuning et adaptation au domaine

Quand un modèle d'embedding généraliste ne distingue pas assez finement le vocabulaire d'un domaine spécialisé, trois options existent, par ordre de coût croissant :

Recherche hybride — combiner recherche vectorielle et recherche lexicale classique (BM25), qui capture les termes exacts que l'embedding pourrait diluer, notamment pour les références précises (numéros de contrat, codes produit, noms propres).
Fine-tuning léger — entraîner une couche d'adaptation (adapter, LoRA) au-dessus du modèle d'embedding gelé, avec des paires requête/passage propres au domaine, sans toucher aux poids du modèle de base.
Fine-tuning complet — réentraîner le modèle sur des paires positives et négatives spécifiques au métier, éventuellement générées en demandant à un modèle génératif de produire des questions plausibles à partir de passages existants.

Le fine-tuning complet n'est justifié que lorsque la recherche hybride et l'adaptation légère ne suffisent plus. C'est une option coûteuse à maintenir, car elle crée une dépendance à revalider à chaque évolution du corpus, et un jeu de données synthétique mal contrôlé peut introduire un biais qui dégrade la performance sur des formulations imprévues.

Le drift des embeddings en production

Le drift d'embedding est l'un des risques les plus sous-estimés d'une architecture RAG en production, précisément parce qu'il ne produit aucune erreur visible. Trois formes distinctes méritent d'être distinguées.

Le drift de modèle survient quand le fournisseur met à jour silencieusement les poids derrière un même nom d'endpoint. Les vecteurs déjà indexés utilisent l'ancienne version ; les nouvelles requêtes, la nouvelle. Les deux espaces ne sont plus comparables, même si le calcul de similarité continue de renvoyer des nombres valides.

Le drift de données est plus progressif : le vocabulaire du corpus évolue — nouveaux produits, nouvelle terminologie, évolution réglementaire — et s'éloigne de la distribution sur laquelle le modèle a été évalué, réduisant la précision de façon insidieuse, sans point de rupture identifiable.

Le mismatch de version est une erreur d'exploitation plus basique : indexation et requête utilisent deux versions différentes du modèle, ou un prétraitement différent (troncature, normalisation, préfixes) — un défaut de configuration plutôt qu'une dérive progressive, mais tout aussi corrosif.

Mélanger dans un même index des vecteurs générés par deux versions différentes du même modèle d'embedding revient à comparer des grandeurs incompatibles. Le calcul de similarité reste techniquement valide — il retourne toujours un nombre — mais son sens sémantique est corrompu, sans qu'aucune erreur applicative ne se déclenche pour l'alerter.

La parade est opérationnelle plus que technique : figer la version du modèle utilisé, sans alias mouvant en production, enregistrer cette version aux côtés de chaque vecteur stocké, et documenter un plan de ré-indexation complète avant tout changement de modèle. Une migration partielle entre deux modèles n'est pas une option viable : elle laisse coexister deux espaces incompatibles sous couvert d'une même collection.

Pièges pratiques fréquents

Troncature silencieuse — la plupart des modèles imposent une limite de tokens (512, 2048, parfois 8191). Un passage plus long est tronqué sans avertissement, et l'information en fin de passage disparaît du vecteur produit, sans alerte au moment de l'ingestion.
Préfixes ignorés — plusieurs modèles ouverts performants, comme E5 ou BGE, exigent un préfixe explicite avant l'encodage : « query: » pour les requêtes, « passage: » pour les documents. L'omettre, souvent mal documenté, dégrade fortement le classement sans qu'aucune erreur ne le signale.
Granularité incohérente entre requête et document — une requête courte et un chunk de plusieurs centaines de mots ne s'encodent pas dans la même zone de l'espace vectoriel même sur le même sujet, ce qui pénalise le score de similarité pour des modèles mal adaptés à cette asymétrie.
Absence de jeu d'évaluation métier — sans paires requête/passage issues de cas réels, impossible de détecter objectivement une régression lors d'un changement de modèle ; seul un vrai jeu de test le révèle, un score public ne s'y substitue pas.

Constituez un petit jeu d'évaluation « maison » de 50 à 200 paires requête → passage attendu, à partir de vrais tickets ou questions d'utilisateurs. C'est le seul moyen fiable de comparer deux modèles d'embedding sur votre corpus réel, plutôt que de se fier à des benchmarks publics qui ne reflètent pas votre domaine ni vos langues.

Checklist avant mise en production

Le modèle d'embedding est figé et versionné explicitement, sans alias mouvant en production.
La métrique de similarité configurée dans l'index correspond à celle recommandée par le fournisseur du modèle.
Les préfixes requis (query/passage) sont appliqués de façon cohérente à l'indexation et à la requête.
Un jeu d'évaluation métier existe et est rejoué à chaque changement de modèle ou de version.
Un runbook de ré-indexation complète est documenté, testé, et déclenchable sans downtime prolongé.
Le comportement multilingue a été vérifié sur les langues réellement présentes dans le corpus, pas seulement sur l'anglais.
La stratégie de troncature a été validée sur les documents les plus longs du corpus, pas uniquement sur des exemples courts.
Le compromis dimension/quantization a été mesuré sur un jeu de test avant d'être figé, plutôt que fixé par défaut.

Ce qu'il faut retenir

L'embedding est la brique la plus discrète d'une architecture RAG, et l'une des plus déterminantes : toute erreur de récupération en amont ne pourra jamais être corrigée par la qualité du modèle génératif en aval. Choisir un modèle d'embedding n'est pas un détail interchangeable — c'est un choix d'architecture qui engage la métrique de similarité, la stratégie de chunking, la gestion des versions et le plan de test en production. Le chapitre suivant aborde l'indexation et les architectures de récupération, qui déterminent comment ces vecteurs sont interrogés à l'échelle.

L'essentiel à retenir

Ce chapitre explique ce que mesure réellement un embedding et pourquoi cette représentation vectorielle est la brique la plus déterminante d'une architecture RAG, en amont même du modèle génératif. Il détaille l'évolution des modèles d'embedding (word2vec, BERT contextuel, bi-encoders entraînés par apprentissage contrastif), les trois métriques de similarité et leurs pièges de configuration, ainsi que les compromis multilingues, de dimension et de coût de stockage. Une large place est faite au drift de modèle en production — le risque le plus sous-estimé d'un pipeline RAG — et aux pièges pratiques fréquents comme la troncature silencieuse ou les préfixes query/passage ignorés. Le chapitre se conclut par une checklist opérationnelle avant mise en production.

Questions fréquentes

Combien de dimensions doit avoir un bon embedding ?

Il n'existe pas de valeur universelle : les modèles courants vont de 384 à plus de 3000 dimensions. Plus de dimensions n'améliore pas systématiquement le recall, surtout sur un petit corpus, alors que cela augmente linéairement le coût de stockage et de calcul. Le bon réglage se détermine en testant plusieurs options sur un jeu d'évaluation propre à votre corpus.

Peut-on utiliser un LLM génératif comme ChatGPT pour générer des embeddings de recherche ?

C'est techniquement possible en extrayant un état caché du modèle, mais ce n'est pas recommandé : ces modèles ne sont pas entraînés avec un objectif contrastif optimisant la géométrie de similarité. Un modèle bi-encoder dédié, entraîné spécifiquement pour la recherche, donnera des résultats nettement plus fiables pour un coût souvent inférieur.

Faut-il re-générer tous les embeddings si on change de modèle ?

Oui, systématiquement et intégralement. Les espaces vectoriels produits par deux modèles différents ne sont pas comparables entre eux, même s'ils ont la même dimension. Une ré-indexation partielle laisse coexister des vecteurs incompatibles dans le même index, ce qui corrompt silencieusement le classement des résultats.

Comment savoir si mon modèle d'embedding gère bien le français ?

Un benchmark public filtré sur le français donne une première indication, mais l'essentiel se joue sur un jeu d'évaluation construit à partir de vrai vocabulaire métier — jargon technique, acronymes internes, formulations juridiques. C'est souvent là que les modèles multilingues généralistes montrent leurs limites, invisibles sur un score de classement général.

Qu'est-ce que les embeddings Matryoshka et à quoi ça sert ?

C'est une technique d'entraînement qui permet de tronquer un vecteur à une dimension plus courte après coup, par exemple de 1536 à 256, en conservant l'essentiel du signal de similarité. Cela permet d'ajuster le compromis entre stockage, latence et précision sans avoir à réentraîner ou changer de modèle.

La similarité cosinus et le produit scalaire donnent-ils le même classement de résultats ?

Uniquement si les vecteurs sont normalisés à une norme égale à 1 ; dans ce cas les deux métriques produisent un classement strictement identique. Sur des vecteurs non normalisés, les deux métriques peuvent diverger notablement, d'où l'importance de vérifier la convention attendue par le modèle utilisé.

Comment détecter un drift d'embedding une fois le système en production ?

En journalisant la version exacte du modèle utilisée pour chaque vecteur stocké, et en rejouant régulièrement un jeu d'évaluation métier pour surveiller une baisse de recall. Une chute progressive et inexpliquée de la pertinence des résultats, sans changement de code identifiable, est souvent le premier signal d'un drift de données ou de modèle.

Progression sauvegardée dans votre navigateur.

Quiz de validation

Quiz indisponible (données invalides).

Vos projets IA sont-ils sécurisés ? Audit LLM, conformité AI Act, red teaming — devis sous 48h.

Devis gratuit