Embedding : transformer le sens des mots en géométrie

Ou : Comment apprendre à un ordinateur que « chat » et « chaton » sont proches, sans jamais lui montrer un chat

Imaginez qu’on vous demande de placer tous les mots de la langue française sur une carte. Pas par ordre alphabétique — par sens. « Chat » et « chaton » seraient proches. « Chat » et « démocratie » seraient loin. « Roi » et « reine » seraient à la même distance l’un de l’autre que « homme » et « femme ». Et « Paris » serait à « France » ce que « Tokyo » est à « Japon ».

Maintenant imaginez que cette carte n’a pas deux dimensions, mais 768. Ou 1 536. Ou 3 072.

C’est ça, un embedding. C’est une représentation d’un morceau de texte — un mot, une phrase, un paragraphe entier — sous forme de vecteur numérique. Une liste de nombres qui encode le sens du texte dans un espace géométrique à haute dimension. Et c’est la technologie qui rend possible la recherche sémantique, le RAG, les systèmes de recommandation, et à peu près tout ce qui nécessite qu’un ordinateur « comprenne » de quoi parle un texte.

Du mot au vecteur — une histoire de coordonnées qui ont du sens

L’intuition fondamentale

L’idée derrière les embeddings repose sur une hypothèse linguistique simple, formulée par le linguiste britannique John Rupert Firth en 1957 : « Vous connaîtrez un mot par la compagnie qu’il garde. » (You shall know a word by the company it keeps.)

Dit autrement : les mots qui apparaissent dans les mêmes contextes ont des sens similaires. « Chat » et « chaton » apparaissent souvent à côté des mêmes mots — « caresser », « ronronner », « litière », « croquettes ». « Chat » et « serveur » aussi, mais dans des contextes complètement différents — ce qui est exactement le genre de problème que les embeddings résolvent remarquablement bien.

L’idée est de convertir cette intuition en mathématiques. On entraîne un modèle à prédire les mots qui entourent un mot donné (ou l’inverse), et les poids internes du modèle deviennent les coordonnées du mot dans l’espace vectoriel. Les mots qui se comportent de la même façon dans le langage se retrouvent avec des coordonnées similaires. Pas parce qu’on a programmé « chat ≈ chaton ». Parce que le modèle a observé qu’ils apparaissent dans les mêmes contextes.

Word2Vec : le moment où tout a basculé

En 2013, Tomáš Mikolov et son équipe chez Google ont publié un article qui a changé le traitement du langage naturel : « Efficient Estimation of Word Representations in Vector Space ». Le modèle s’appelait Word2Vec, et il a démontré quelque chose de remarquable.

Non seulement les mots similaires se retrouvaient proches dans l’espace vectoriel, mais les relations entre mots étaient encodées sous forme de directions géométriques. La relation « masculin → féminin » correspondait à un vecteur dans l’espace. La relation « pays → capitale » correspondait à un autre vecteur. Et on pouvait faire de l’arithmétique avec :

roi − homme + femme ≈ reine

Ce n’est pas une métaphore. C’est littéralement une opération vectorielle. On prend le vecteur du mot « roi », on soustrait le vecteur « homme », on ajoute le vecteur « femme », et le résultat est un vecteur dont le plus proche voisin est « reine ». Le modèle n’a jamais appris cette règle. Il l’a déduite des patterns statistiques de la langue¹.

(En réalité, cette analogie est un peu l’exemple soigneusement choisi de la discipline — elle fonctionne bien pour certaines relations comme genre ou pays-capitale, et beaucoup moins bien pour d’autres. Mais le principe sous-jacent est solide : les relations sémantiques sont encodées sous forme de directions dans l’espace vectoriel.)

Des mots aux phrases : l’évolution des modèles d’embedding

Word2Vec avait une limitation fondamentale : chaque mot avait un seul vecteur, quel que soit le contexte. « Chat » avait le même embedding dans « le chat ronronne » et « le chat du serveur est tombé ». Ce problème de polysémie a motivé une nouvelle génération de modèles.

GloVe (Global Vectors for Word Representation), développé à Stanford par Pennington, Socher et Manning en 2014, a amélioré la qualité des embeddings en combinant les statistiques locales (contexte immédiat) et globales (co-occurrence dans tout le corpus). Mais le problème de la polysémie restait.

La vraie rupture est venue avec les modèles contextuels — BERT (2018), puis les LLM modernes. Dans ces modèles, l’embedding d’un mot dépend de tout son contexte. « Chat » dans « le chat ronronne » et « chat » dans « le serveur de chat » produisent des vecteurs complètement différents. Le modèle comprend la nuance.

Aujourd’hui, les modèles d’embedding spécialisés encodent des phrases ou paragraphes entiers en un seul vecteur. Les plus utilisés :

La similarité cosinus : mesurer la proximité du sens

Une fois les textes convertis en vecteurs, il faut pouvoir mesurer à quel point deux vecteurs sont « proches ». La métrique standard est la similarité cosinus — elle mesure l’angle entre deux vecteurs, indépendamment de leur longueur.

Deux vecteurs qui pointent dans la même direction ont une similarité cosinus de 1 (identiques en sens). Deux vecteurs perpendiculaires ont une similarité de 0 (aucun rapport). Deux vecteurs opposés ont une similarité de -1 (sens contraire).

Pourquoi l’angle plutôt que la distance ? Parce que dans un espace à 1 536 dimensions, la notion de « distance » devient problématique — c’est ce qu’on appelle la malédiction de la dimensionnalité. Deux points aléatoires dans un espace à haute dimension sont presque toujours à la même distance l’un de l’autre. L’angle, lui, reste discriminant².

En pratique, ça ressemble à ça :

• « Comment nourrir un chat ? » vs « Alimentation féline : guide pratique » → similarité ~0.92 (très proches)
• « Comment nourrir un chat ? » vs « Les chats sont des animaux indépendants » → similarité ~0.75 (liés mais différents)
• « Comment nourrir un chat ? » vs « La politique monétaire européenne » → similarité ~0.15 (aucun rapport)

Le pipeline : de votre question à la réponse pertinente

Les embeddings sont la technologie fondamentale derrière le RAG et la recherche sémantique. Voici comment ça fonctionne en pratique :

1. Indexation — Vos documents sont découpés en chunks, chaque chunk est converti en vecteur par un modèle d’embedding, et les vecteurs sont stockés dans une base de données vectorielle (Pinecone, Weaviate, pgvector, etc.).

2. Requête — L’utilisateur pose une question. La question est elle-même convertie en vecteur, avec le même modèle d’embedding. C’est crucial : si vous utilisez un modèle différent pour l’indexation et la recherche, les vecteurs ne sont pas comparables — c’est comme chercher des coordonnées GPS sur une carte routière.

3. Recherche — On cherche dans la base les vecteurs les plus proches du vecteur de la question. Les chunks correspondants sont les documents les plus pertinents.

4. Génération — Les documents pertinents sont injectés dans le prompt du LLM, qui génère une réponse basée sur eux.

La qualité de l’ensemble dépend entièrement de la qualité des embeddings. Si le modèle d’embedding est mauvais — s’il ne capture pas bien le sens — la recherche ramène les mauvais documents, et le LLM génère une réponse basée sur des informations non pertinentes. Ou pire, il hallucine à partir de documents qui ne répondent pas à la question. Garbage in, garbage out — mais avec des vecteurs.

Les pièges des embeddings

Les embeddings ne sont pas magiques. Voici les pièges classiques :

Le biais — Les embeddings héritent des biais présents dans les données d’entraînement. Si le corpus associe systématiquement « infirmière » à « femme » et « chirurgien » à « homme », les embeddings reproduiront ces associations. Le vecteur roi − homme + femme = reine fonctionne aussi pour des associations moins flatteuses.

La langue — Un modèle d’embedding entraîné principalement sur de l’anglais sera moins performant en français, en arabe ou en mandarin. Les modèles multilingues existent (Cohere embed-v3, E5 multilingual) mais restent généralement meilleurs en anglais qu’ailleurs.

Le domaine — Un modèle d’embedding généraliste peut mal capturer le vocabulaire spécialisé. Dans un contexte médical, « positif » et « négatif » ont un sens très différent de leur usage courant. Le fine-tuning d’embeddings sur un corpus spécialisé améliore significativement la qualité de la recherche dans ce domaine.

La taille — Plus un vecteur a de dimensions, plus il capture de nuances. Mais plus il coûte en stockage et en calcul. Un embedding de 3 072 dimensions prend 4 fois plus d’espace qu’un embedding de 768 dimensions, et la recherche de voisins les plus proches est proportionnellement plus lente.

Le dialogue du moteur de recherche sémantique

DevOps Dave : J’ai remplacé notre recherche Elasticsearch par un système basé sur des embeddings. Les résultats sont incroyables.

Security Sarah : Incroyables comment ?

DevOps Dave : Genre, un client cherche « je n’arrive plus à me connecter » et le système trouve la documentation sur la réinitialisation de mot de passe. Avant, il fallait taper exactement « mot de passe oublié ».

Security Sarah : Et si quelqu’un cherche « erreur 403 endpoint /api/v2/users » ?

DevOps Dave : … Il remonte la documentation sur les erreurs d’authentification en général.

Security Sarah : Parce que « 403 » et « authentification » sont sémantiquement proches. Mais le client veut la doc spécifique pour cet endpoint précis.

DevOps Dave : Donc la recherche sémantique est moins bonne que la recherche par mots-clés ?

Security Sarah : Non. Les deux sont bons pour des choses différentes. C’est pour ça que la recherche hybride existe — BM25 pour la précision lexicale, embeddings pour la compréhension sémantique. Tu as besoin des deux.

Tableau récapitulatif

Le mot de la fin

Les embeddings sont un de ces concepts qui paraissent abstraits jusqu’au moment où on réalise qu’ils sont partout. Chaque fois que Netflix vous recommande un film, qu’un moteur de recherche comprend votre question mal formulée, qu’un chatbot trouve le bon article dans une base de connaissances — il y a des embeddings en dessous.

L’idée que le sens peut être encodé en géométrie — que « roi − homme + femme = reine » est une opération mathématique valide — reste une des découvertes les plus élégantes de l’IA moderne. Pas parce que c’est compliqué. Parce que c’est simple. Le sens du langage, ce truc nébuleux et philosophique que les linguistes étudient depuis des siècles, se réduit à des coordonnées dans un espace. Et un ordinateur qui ne comprend rien au langage peut quand même naviguer dans cet espace et trouver les bons voisins.

C’est peut-être pas de la compréhension. Mais ça y ressemble suffisamment pour être utile.