Embeddings : c'est quoi, concrètement (et pourquoi ça fait tourner le RAG) ?

Tu tapes « rembourser ma commande » dans un moteur de recherche, et il te sort une page qui dit « obtenir un remboursement » — sans que les deux phrases partagent un seul mot utile. Comment la machine sait-elle que c’est la même demande ? Réponse : les embeddings. C’est la brique qui permet à un ordinateur de manipuler du sens au lieu de comparer bêtement des chaînes de caractères. Et c’est exactement ce qui fait tourner le RAG et toute la recherche sémantique moderne. Voici comment ça marche vraiment, sans maths inutiles.

La définition courte (et l’intuition qui va avec)

Un embedding, c’est la transformation d’un texte en un vecteur — une liste de nombres — calculée par un modèle pour que le vecteur capture le sens du texte. La propriété qui rend tout ça utile : deux textes de sens proche produisent des vecteurs proches.

Le mot « vecteur » fait peur, alors prenons-le simplement. Imagine que chaque texte reçoit des coordonnées dans un espace. À deux dimensions, ce serait un point sur une carte : [longitude, latitude]. Les embeddings font pareil, mais avec des centaines ou des milliers de dimensions — typiquement 768, 1536 ou 3072 selon le modèle. Trop pour qu’on se le représente, mais le principe ne change pas : chaque texte devient un point dans un immense espace, et les textes qui parlent de la même chose atterrissent au même endroit.

L’intuition à garder : sur cette carte du sens, « chat » est tout près de « félin », un peu plus loin de « chien », et à l’autre bout du monde de « tableur ». Un embedding transforme « est-ce que ces deux textes parlent de la même chose ? » — une question floue et humaine — en « ces deux flèches pointent-elles dans la même direction ? », une question de géométrie qu’un ordinateur tranche en une milliseconde.

Ce que l’embedding n’est pas : ce n’est pas un résumé (tu ne peux pas le relire), ce n’est pas un mot-clé, et ce n’est pas le texte compressé que tu pourrais « décompresser ». C’est une empreinte de sens, lisible par une machine, illisible pour toi.

Pourquoi ça bat la recherche par mots-clés (le vrai déclic)

Pendant cinquante ans, chercher dans du texte, c’était chercher des mots. Tu tapes un mot, le moteur te rend les documents qui contiennent ce mot. Simple, rapide, et fragile dès que l’humain reformule.

Le problème : le langage déborde de pièges que les mots-clés ne voient pas.

• Les synonymes. « Voiture » et « automobile » ne matchent pas. « Bug » et « erreur » non plus.
• Les reformulations. « Comment annuler mon abonnement » et « résilier mon compte » : zéro mot en commun utile, même intention exacte.
• Le contexte. « Souris » (l’animal) et « souris » (le périphérique) : même mot, deux sens. Les mots-clés les confondent ; les embeddings modernes, eux, les séparent selon la phrase qui les entoure.

Les embeddings renversent la logique. Au lieu de comparer des mots, on compare des positions dans l’espace du sens. « Résilier mon compte » et « annuler mon abonnement » se retrouvent voisins parce que le modèle a appris, sur des milliards de phrases, qu’on les emploie dans les mêmes contextes. C’est ce qu’on appelle la recherche sémantique : on cherche par le sens, pas par la lettre.

Le « so what » pour toi qui construis un produit : ta barre de recherche, ton support client, ton moteur de doc interne arrêtent de rater une requête parce que l’utilisateur n’a pas deviné le mot exact que tu avais indexé. C’est rarement spectaculaire en démo, mais ça change tout en usage réel — là où les humains écrivent comme ils pensent, pas comme ta base de données voudrait.

D’où viennent ces nombres (sans entrer dans les maths)

Personne ne pose les coordonnées à la main. C’est un modèle entraîné qui les produit, et le principe d’entraînement est élégant : on apprend au modèle à rapprocher ce qui va ensemble et à éloigner ce qui n’a rien à voir.

L’idée fondatrice remonte à 2013 avec word2vec (Mikolov et al., Google) : un mot est défini par la compagnie qu’il fréquente. Si « médecin » et « infirmier » apparaissent dans les mêmes voisinages de phrases, le modèle leur donne des coordonnées proches. À cette époque, chaque mot recevait un vecteur figé, identique quel que soit le contexte. word2vec a rendu célèbre l’exemple roi - homme + femme ≈ reine : les relations de sens devenaient des opérations arithmétiques sur les vecteurs. La preuve que ces nombres encodaient vraiment quelque chose du sens, pas un hash arbitraire.

Le saut suivant vient des LLM et de l’architecture Transformer. Là, le vecteur d’un mot dépend de toute la phrase : c’est ce qui permet enfin de distinguer la « souris » de bureautique de la « souris » de biologie — le même mot reçoit des coordonnées différentes selon le contexte. Sur cette base, des modèles comme Sentence-BERT (Reimers & Gurevych, 2019) sont conçus pour produire un bon vecteur d’une phrase complète (et non d’un mot isolé), directement comparable par similarité cosinus. C’est ce type de modèle qu’on branche aujourd’hui dans un moteur de recherche sémantique.

Le point pratique à retenir : un modèle d’embedding n’est pas un LLM. Le LLM génère du texte ; le modèle d’embedding encode du texte et s’arrête là. Même famille technique, deux métiers. On les utilise côte à côte, mais ce sont deux outils distincts.

Comment on mesure « proche » : la similarité cosinus

Une fois tes textes transformés en vecteurs, « ces deux textes se ressemblent-ils ? » devient « ces deux vecteurs sont-ils proches ? ». Reste à définir proche.

La mesure dominante s’appelle la similarité cosinus. Elle ne regarde pas la distance entre les deux points, mais l’angle entre les deux flèches partant de l’origine. La question qu’elle pose : ces deux vecteurs pointent-ils dans la même direction ?

• Cosinus proche de 1 → même direction → même sens.
• Cosinus proche de 0 → directions perpendiculaires → aucun rapport.
• Cosinus proche de -1 → directions opposées → sens contraires.

Pourquoi l’angle plutôt que la distance ? Parce qu’on veut comparer le sens, pas la longueur. Un paragraphe long et une phrase courte qui disent la même chose peuvent avoir des vecteurs de tailles différentes mais pointer dans la même direction — le cosinus les juge identiques, ce qu’on veut. C’est un détail technique, mais il explique pourquoi tu verras « cosine similarity » partout dans le code de RAG et de recherche sémantique.

Le lien avec le RAG : embeddings = le moteur du retrieval

C’est ici que tout se connecte. Le RAG consiste à récupérer les passages pertinents dans ta base, puis à les injecter dans le prompt pour que le LLM réponde à partir de tes données réelles plutôt que de sa mémoire floue. Or l’étape « récupérer les bons passages » est précisément un problème d’embeddings.

Le déroulé concret :

1. En amont (indexation). Tu découpes tes documents en morceaux (chunks), tu passes chaque chunk dans un modèle d’embedding, et tu stockes le vecteur obtenu dans une base vectorielle. Ta base de connaissance devient un nuage de points dans l’espace du sens.
2. À chaque question. La question de l’utilisateur passe dans le même modèle d’embedding et devient un vecteur.
3. La recherche. On cherche, parmi tous les vecteurs stockés, les k plus proches de celui de la question (les k meilleurs voisins, k valant souvent 3 à 10), par similarité cosinus.
4. La suite. Ces passages partent dans le prompt, et le LLM rédige sa réponse en s’appuyant dessus.

Autrement dit : sans embeddings, pas de RAG. C’est l’étape 1 de la phase d’indexation et l’étape de recherche réunies. Et comme je le rappelle dans la fiche RAG, le maillon faible d’un RAG n’est presque jamais la génération — c’est le retrieval. Si ton modèle d’embedding place mal tes passages, le meilleur LLM du monde répondra parfaitement à côté. La qualité de tes embeddings est la qualité de ton RAG.

Ce raisonnement par chunks et par voisins explique aussi pourquoi tout ne tient pas dans le prompt d’un coup : c’est le même arbitrage que celui détaillé dans la fiche contexte et tokens. La grande fenêtre fixe le plafond du possible ; les embeddings décident intelligemment de ce qu’il vaut la peine d’y mettre.

La base vectorielle et les pièges qui coûtent cher

Stocker quelques vecteurs, n’importe quel tableau le fait. Mais dès que tu en as des centaines de milliers, comparer la question à tous à chaque requête devient trop lent. D’où la base vectorielle (vector database) : une base spécialisée dans la recherche des plus proches voisins à grande échelle, via des index astucieux qui trouvent les bons candidats sans tout scanner.

Les noms que tu croiseras : pgvector (une extension de PostgreSQL — souvent le départ le plus pragmatique si tu es déjà sur Postgres), Pinecone, Qdrant, Weaviate. Le choix dépend de ton volume et de ton infra, pas de la mode.

Les pièges qui plombent un système à base d’embeddings, eux, sont presque toujours les mêmes :

• Un modèle d’embedding anglo-centré sur du français. Beaucoup de modèles sont surtout entraînés sur de l’anglais et se dégradent sur ta langue et ton jargon métier. Teste plusieurs modèles (OpenAI, Mistral, modèles multilingues open-weight) sur tes vraies données et mesure le recall — la part des bons passages effectivement retrouvés. Le classement public MTEB aide à dégrossir, mais rien ne remplace un test sur ton corpus.
• Mélanger deux modèles d’embedding. Les vecteurs d’un modèle ne sont pas comparables à ceux d’un autre — chaque modèle a sa propre géométrie. Si tu changes de modèle, tu dois ré-indexer toute ta base. Question et documents doivent passer par le même modèle, toujours.
• Croire que l’embedding suffit. La recherche vectorielle brute ramène souvent du « presque pertinent ». Les meilleurs systèmes la combinent avec une recherche par mots-clés classique (le hybrid search) et ajoutent un reranker qui re-trie finement les candidats. L’embedding ouvre la porte ; il ne fait pas tout le travail.

Les embeddings en une phrase pour ton board

Si tu dois l’expliquer à quelqu’un qui ne code pas : « C’est ce qui permet à une IA de comprendre que deux phrases veulent dire la même chose même si elles n’emploient pas les mêmes mots — et c’est grâce à ça qu’on peut chercher, trier et retrouver de l’information par le sens. »

C’est une brique invisible mais structurante. Tu ne la vends jamais à un client — personne n’a envie d’« acheter des embeddings ». Mais dès qu’un produit fait de la recherche sémantique, de la recommandation, de la détection de doublons, du classement automatique de tickets ou du RAG, il y a des embeddings dessous. Le LLM écrit la réponse visible ; l’embedding, lui, a fait le travail souterrain de trouver de quoi parler.

Pour relier toutes ces briques — modèle, contexte, RAG, agents — la page pour comprendre l’IA générative met le tout en perspective. Et si ta prochaine question est « ok, mais comment je branche ça sur mes documents sans réentraîner un modèle ? », la réponse tient en trois lettres et a sa propre fiche : le RAG.