Les embeddings expliqués simplement : comment un texte devient un vecteur

Un embedding (on dit aussi « plongement » en français) est une liste de nombres qui représente le sens d’un texte : deux phrases qui veulent dire la même chose reçoivent des nombres proches, même si elles n’ont aucun mot en commun. C’est le moteur de la recherche sémantique, celle qui retrouve « Puis-je récupérer mon argent ? » dans une page intitulée « Conditions de remboursement ». Cet article explique les embeddings sans jargon, déroule un calcul de similarité cosinus que vous pouvez refaire à la calculatrice, et fait le tour des limites à connaître avant de bâtir quoi que ce soit dessus.

Qu’est-ce qu’un embedding, en termes simples ?

Un ordinateur compare très bien des nombres et très mal des idées. Pour un moteur de recherche classique, « voiture » et « automobile » sont deux chaînes de caractères différentes, donc deux choses sans rapport, sauf si quelqu’un a saisi une liste de synonymes. Les embeddings contournent ce problème en traduisant le texte en nombres, d’une manière qui conserve le sens.

Concrètement, un modèle d’embedding lit un mot, une phrase ou un paragraphe et renvoie une liste de nombres de longueur fixe, par exemple 768 ou 1 024 valeurs. Cette liste s’appelle un vecteur. Le modèle a été entraîné pour que des textes de sens voisin obtiennent des vecteurs qui pointent dans des directions voisines, et que des textes sans rapport se retrouvent éloignés.

L’analogie de la carte des idées

Imaginez une immense carte sur laquelle chaque phrase possède une punaise. Les phrases qui parlent de remboursement se regroupent dans un quartier, celles qui parlent de stationnement dans un autre, celles qui parlent de TVA plus loin encore. Un embedding, ce sont simplement les coordonnées GPS d’une phrase sur cette carte. Pour trouver les documents liés à une question, on plante une punaise pour la question et on regarde quelles punaises sont à côté.

Seule différence avec une carte routière : celle-ci ne compte pas deux dimensions mais des centaines, voire des milliers. Le sens d’un texte a bien plus de directions que le nord et l’est : sujet, ton, domaine, registre et quantité de nuances plus fines. Personne ne peut se représenter un tel espace, mais les calculs de distance et d’angle s’y font exactement comme sur une feuille de papier.

Comment un texte devient un vecteur

Inutile de connaître les réseaux de neurones pour comprendre le principe. Tout se passe en trois temps :

1. Le découpage en tokens. Le texte est coupé en petites unités : mots entiers, morceaux de mots, ponctuation. « Inconstitutionnellement » sera découpé en plusieurs fragments.
2. L’encodage en contexte. Un réseau de neurones entraîné lit les tokens en tenant compte de leurs voisins. « Avocat » dans « mon avocat plaide » et dans « salade d’avocat » n’obtient pas la même représentation dans un modèle moderne.
3. La synthèse en un seul vecteur. Les représentations internes sont combinées en une liste unique pour tout le texte, souvent ramenée à une longueur de 1. Ce vecteur final, c’est l’embedding.

D’où le modèle tire-t-il sa « compréhension » ? D’un entraînement sur de très grandes quantités de texte, fondé sur une vieille intuition de la linguistique : des mots employés dans des contextes semblables ont des sens proches. Un exemple fondateur est word2vec, présenté en 2013 dans l’article Efficient Estimation of Word Representations in Vector Space, qui attribuait un vecteur à chaque mot. Les modèles actuels encodent des phrases et des paragraphes entiers : une question et le passage qui y répond peuvent ainsi se retrouver côte à côte même avec peu de vocabulaire commun.

La similarité cosinus, calculée pas à pas

Une fois deux textes transformés en vecteurs, comment mesurer leur proximité ? La mesure la plus répandue est la similarité cosinus, qui s’intéresse à l’angle entre les deux vecteurs. Même direction : le score vaut 1. Directions perpendiculaires (aucun rapport) : 0. Directions opposées : -1, même si avec des embeddings de texte la plupart des scores restent entre 0 et 1.

La formule tient en une ligne : on multiplie les vecteurs composante par composante, on additionne (c’est le produit scalaire), puis on divise par le produit de leurs longueurs. Faisons-le à la main avec des vecteurs jouets de trois dimensions. Pour rendre l’exemple lisible, faisons comme si les trois nombres signifiaient « argent », « retour d’un achat » et « lieu ». Les vrais modèles n’étiquettent pas leurs dimensions, mais le calcul est identique.

1. Produit scalaire A·B = 0,9 × 0,8 + 0,8 × 0,9 + 0,1 × 0,2 = 0,72 + 0,72 + 0,02 = 1,46.
2. Longueurs. |A| = √(0,81 + 0,64 + 0,01) = √1,46 ≈ 1,208 ; |B| = √(0,64 + 0,81 + 0,04) = √1,49 ≈ 1,221.
3. Cosinus A, B = 1,46 ÷ (1,208 × 1,221) ≈ 1,46 ÷ 1,475 ≈ 0,99 : quasiment la même question, alors que les deux phrases ne partagent presque aucun mot.
4. Produit scalaire A·C = 0,09 + 0,16 + 0,09 = 0,34 ; |C| = √(0,01 + 0,04 + 0,81) = √0,86 ≈ 0,927.
5. Cosinus A, C = 0,34 ÷ (1,208 × 0,927) ≈ 0,34 ÷ 1,120 ≈ 0,30 : un tout autre sujet.

Voilà tout le principe de la recherche sémantique. On calcule une fois l’embedding de chaque passage de vos documents, on calcule celui de la question au moment de la recherche, on compare, et on renvoie les passages aux meilleurs scores. Avec des millions de passages, tout comparer un par un devient lent : c’est le rôle des index spécialisés et des bases de données vectorielles, qui trouvent les vecteurs les plus proches de façon approchée mais très rapide.

Les embeddings multilingues : une seule carte pour plusieurs langues

Certains modèles sont entraînés sur de nombreuses langues à la fois, souvent avec des paires de phrases traduites. Résultat : « conditions de remboursement », « refund policy » et « Rückerstattungsbedingungen » atterrissent au même endroit de la carte. Une question posée en français peut alors retrouver un passage rédigé en anglais.

C’est précieux pour une entreprise qui travaille avec une documentation en anglais ou des clients étrangers, mais la qualité varie. Les modèles sont généralement meilleurs dans les langues très présentes dans leurs données d’entraînement, et moins fiables sur les langues rares, les régionalismes ou le vocabulaire métier pointu. Si la recherche interlangue compte pour vous, testez-la avec de vraies questions dans chaque langue.

Les limites des embeddings et de la recherche sémantique

• Les identifiants exacts. Un numéro d’article comme « L. 1234-1 du Code du travail », un SIRET, une référence produit ou un code d’erreur ont peu de « sens » pour un modèle. La recherche sémantique peut renvoyer un passage vaguement lié là où une recherche par mots-clés trouverait la bonne ligne instantanément.
• La négation. « Couvert par la garantie » et « non couvert par la garantie » parlent du même sujet : leurs vecteurs peuvent être très proches. La similarité mesure la proximité de thème, pas l’accord entre deux affirmations.
• Le jargon et les termes récents. Un nom de produit lancé le mois dernier ou un sigle de votre secteur peut être mal représenté si le modèle ne l’a jamais rencontré.
• Les passages longs deviennent flous. Un seul vecteur pour un long extrait fait la moyenne de plusieurs idées ; un détail précis peut s’y noyer.
• Les vecteurs dépendent du modèle. Des vecteurs issus de deux modèles différents ne sont pas comparables. Changer de modèle oblige à tout recalculer.
• L’explicabilité. Quand une recherche par mots-clés échoue, on voit pourquoi. Quand une recherche vectorielle renvoie un résultat étrange, il est rare de pouvoir l’expliquer.
• Les données personnelles. Un embedding n’est pas une anonymisation : des travaux de recherche ont montré qu’on peut reconstituer en partie un texte à partir de son vecteur. Au sens du RGPD, mieux vaut traiter les embeddings de documents personnels comme des données personnelles, avec les mêmes mesures de sécurité que celles recommandées par la CNIL pour les fichiers d’origine.

Aucune de ces limites n’est rédhibitoire. Elles expliquent pourquoi beaucoup de systèmes en production combinent similarité sémantique et recherche plein texte classique, ce qu’on appelle la recherche hybride, afin de couvrir à la fois les reformulations et les termes exacts.

Avez-vous vraiment besoin d’embeddings ?

Dans un système RAG (une IA qui répond à partir de vos documents), les embeddings sont un moyen de retrouver les passages pertinents, pas le seul. Le bon choix dépend de vos documents et de la façon dont on vous pose les questions.

Il existe une voie intermédiaire, souvent oubliée : garder la recherche plein texte, mais demander d’abord à un modèle de langage de développer la question en mots-clés et synonymes. « Récupérer mon argent » devient alors une recherche qui inclut aussi « remboursement », « rembourser » et « avoir ». On obtient une bonne part du bénéfice sémantique sans stocker le moindre vecteur. C’est l’approche de Kopik : Kopik n’utilise pas d’embeddings ni de base vectorielle, mais une recherche hybride plein texte et élargissement sémantique des mots-clés, la question étant développée dans la langue des documents pour que les questions posées dans une autre langue trouvent quand même les bons passages.

Si vous choisissez malgré tout les embeddings, prévoyez l’ensemble des coûts : stockage, indexation, recalcul à chaque mise à jour des documents ou changement de modèle. Notre article sur le prix d’une base de données vectorielle détaille ce que vous payez vraiment, et le fonctionnement d’un pipeline RAG montre où se place la recherche entre le découpage et la rédaction de la réponse.

La liste de contrôle avant de vous fier aux embeddings

• Rédigez 20 à 30 vraies questions et vérifiez que le bon passage apparaît dans les premiers résultats.
• Incluez des questions avec des numéros, des noms et des références exacts, pas seulement des questions floues.
• Testez des paires qui ne diffèrent que par une négation (« éligible » et « non éligible »).
• Si vous servez plusieurs langues, testez chacune séparément.
• Notez le modèle d’embedding utilisé, pour savoir quand une réindexation s’impose.
• Protégez les vecteurs comme les documents sources : mêmes droits d’accès, même durée de conservation.

Vous préférez ne gérer aucune infrastructure ? Sur Kopik, vous déposez des PDF, des fichiers Word, du texte ou du Markdown et obtenez une base de connaissances qui répond en citant ses passages, sur le site, par API REST ou depuis des clients MCP comme Claude, Cursor ou ChatGPT. La création d’une base est gratuite.