Comprendre les embeddings : la traduction du sens en vecteurs

Chaque fois que vous tapez une question dans un moteur de recherche et obtenez des résultats qui ne contiennent pas vos mots exacts mais semblent comprendre votre intention, un embedding est à l’œuvre. Cette technique transforme un morceau de texte en une liste ordonnée de nombres qui capture son sens, permettant à une machine de comparer, chercher et raisonner sur le langage sans jamais le « comprendre » comme un humain.

Un mot, un vecteur : transformer le sens en nombres

Imaginez une carte géographique. Chaque ville y occupe une position précise : deux villes proches sur la carte sont nécessairement voisines dans la réalité, et la distance entre elles a un sens concret. Un embedding fonctionne sur le même principe, mais dans un espace de sens plutôt que d’espace physique.

Concrètement, un embedding est un vecteur dense, c’est-à-dire une liste de nombres réels (typiquement entre 128 et 4 096 valeurs) attribuée à un mot, une phrase ou un document entier ^[1]. Chacun de ces nombres encode une facette de la signification du texte. Deux textes qui veulent dire la même chose produisent des vecteurs proches ; deux textes sans rapport produisent des vecteurs éloignés ^[2].

Ce qui rend cette représentation si puissante, c’est qu’elle permet à un algorithme de mesurer la similarité sémantique (la ressemblance de sens) entre deux textes par un simple calcul géométrique, sans jamais avoir besoin de partager les mêmes mots.

Pourquoi la machine ne comprend pas le texte brut

Une machine ne manipule que des nombres. Pour qu’elle traite du texte, il faut d’abord convertir ce texte en nombres. La méthode la plus naïve s’appelle le one-hot encoding : on attribue à chaque mot unique un vecteur rempli de zéros, avec un seul 1 à la position qui lui correspond.

Prenons trois diplômes. En one-hot encoding :

Le problème est immédiat : selon ces vecteurs, « Licence » est tout aussi éloigné de « Master » que de « Doctorat » ^[3]. Aucune relation hiérarchique, aucune notion de proximité n’est capturée. Pour un moteur de recherche, deux synonymes (« voiture » et « automobile ») seraient aussi différents que « voiture » et « démocratie ».

C’est précisément ce que les embeddings corrigent. Un modèle d’embedding apprend à positionner les concepts sémantiquement proches dans un espace vectoriel continu, de sorte que « Licence » se retrouve entre « Master » et le lycée, et que « voiture » et « automobile » partagent presque la même adresse ^[3].

Sous le capot : de la phrase au vecteur dense

Comment un modèle transforme-t-il une phrase en vecteur ? Le processus suit un pipeline en quatre étapes :

1. Tokenisation. La phrase est découpée en tokens, des sous-unités de texte (parfois un mot entier, parfois un morceau de mot). Par exemple, « l’intelligence artificielle » pourrait devenir les tokens [l', intel, ligence, artificielle].

2. Encodeur Transformer. Chaque token traverse un réseau profond basé sur l’architecture Transformer, qui utilise un mécanisme appelé self-attention (attention dirigée sur le contexte) : chaque token « regarde » tous les autres tokens de la phrase pour enrichir son sens ^[1]. Le mot « banque » dans « la banque de la rivière » ne produira pas le même vecteur intermédiaire que dans « la banque a refusé mon prêt ». C’est l’initialisation à partir de modèles pré-entraînés comme BERT qui donne au modèle cette capacité ^[4].

3. Pooling. Le modèle produit un vecteur par token. Pour obtenir un seul vecteur pour la phrase entière, on applique une opération de pooling, le plus souvent une moyenne arithmétique de tous les vecteurs de tokens. On parle de mean pooling ^[4]. C’est l’étape cruciale : elle condense l’information de toute la phrase en un seul vecteur fixe, quelle que soit la longueur du texte d’entrée.

4. Vecteur dense en sortie. Le résultat final est un vecteur de dimension d (par exemple 384, 768 ou 1 024) qui représente la phrase complète dans l’espace sémantique. C’est ce vecteur qu’on stocke, qu’on compare, qu’on recherche.

L’entraînement de ce modèle repose sur l’apprentissage par contraste (contrastive learning) : on lui présente des paires de textes similaires et dissimilaires, et on ajuste les poids internes pour que les vecteurs des textes similaires se rapprochent, tandis que les vecteurs des textes différents s’éloignent ^[4]. Dans le modèle BGE-M3, la température de cet apprentissage (un paramètre qui contrôle la sélectivité du modèle) est fixée à 0.01, ce qui rend le modèle très strict sur ce qu’il considère comme similaire ^[4].

La magie de la proximité : quand « roi » est voisin de « reine »

L’espace vectoriel créé par un embedding possède une propriété remarquable : la distance géométrique entre deux vecteurs reflète la distance de sens entre les textes qu’ils représentent ^[2].

Pour mesurer cette distance, on utilise la similarité cosinus. Plutôt que de calculer la distance brute entre deux vecteurs (ce qui dépendrait de leur longueur), la similarité cosinus mesure l’angle entre eux ^[3]. Deux vecteurs qui pointent dans la même direction (angle faible) ont une similarité proche de 1 ; deux vecteurs perpendiculaires (angle droit) ont une similarité de 0 ; deux vecteurs opposés approchent -1 ^[5].

similarité = (A · B) / (norme de A × norme de B)

Concrètement, dans l’espace d’un modèle entraîné, les vecteurs de « le roi règne » et « la reine gouverne » seront beaucoup plus proches (similarité cosinus élevée) que « le roi règne » et « la température descend » ^[2]. Et cette proximité n’est pas programmée à la main : le modèle l’a apprise en observant des milliards de phrases pendant son entraînement.

Attention cependant : une similarité cosinus de 0.85 ne signifie pas que deux textes sont « 85 % similaires ». C’est une mesure relative qui dépend du corpus et du modèle. Ce qui compte, c’est le classement : dans un ensemble de résultats, les textes avec la similarité la plus élevée sont les plus pertinents sémantiquement ^[3].

Du vecteur au système qui tourne : recherche sémantique et RAG

Un embedding isolé ne sert pas à grand-chose. Sa puissance apparaît quand on en stocke des milliers (ou des millions) dans une base de données vectorielle et qu’on les utilise pour retrouver les informations les plus pertinentes en réponse à une question.

C’est exactement le fonctionnement d’un système RAG (Retrieval-Augmented Generation, « génération augmentée par récupération »). Un pipeline RAG repose sur trois étapes ^[6] :

Indexation. Les documents sources sont découpés en chunks (morceaux de texte, typiquement quelques centaines de tokens). Chaque chunk est converti en vecteur par le modèle d’embedding, puis stocké dans une base vectorielle ^[7].

Recherche. Quand un utilisateur pose une question, celle-ci est convertie en vecteur par le même modèle d’embedding. On effectue alors une recherche par similarité cosinus dans la base vectorielle pour retrouver les chunks les plus proches de la question ^[5].

Génération. Les chunks récupérés sont injectés comme contexte dans le prompt d’un grand modèle de langage (LLM), qui génère une réponse informée et sourcée ^[6].

Le modèle BGE-M3, reconnu pour son efficacité sur des benchmarks multilingues, encode les chunks de documents et les requêtes de recherche avec une similarité mesurée par cosinus standard ^[8]. Un reranking (réordonnancement par un modèle plus lourd) peut ensuite affiner les résultats en réexaminant les meilleurs candidats : dans les expérimentations de ^[8], un pool de 100 candidats est réexaminé par un cross-encodeur avant de ne garder que les 5 chunks les plus pertinents.

Ce qui rend la recherche vectorielle indispensable, c’est qu’elle capte l’intention et le contexte, pas seulement les mots. Une recherche par mots-clés classique ne trouvera jamais « hypertension artérielle » en réponse à « tension élevée ». Un embedding, si ^[9].

Tous les embeddings ne se valent pas : choisir le bon modèle

La famille des modèles d’embedding a considérablement évolué :

Le choix du modèle dépend de plusieurs facteurs concrets :

La langue. Les embeddings ne sont pas universellement multilingues. Le modèle BGE-M3 se distingue par son support large de langues multiples ^[8]. Les embeddings textuels sont intrinsèquement dépendants de la langue : un modèle entraîné principalement sur de l’anglais perdra en qualité sur du texte français ou japonais ^[7].

Le domaine. Un modèle entraîné sur du texte général (Wikipedia, Common Crawl) manquera de finesse sur du texte médical, juridique ou scientifique. PhysBERT, par exemple, est spécialisé sur la littérature en physique ^[1]. L’utilisation de modèles de domaine spécifique améliore significativement la précision du regroupement thématique et du matching entre chercheurs et articles ^[1].

La dimension des vecteurs. Un vecteur de 384 dimensions occupe moins de mémoire et se recherche plus vite qu’un vecteur de 4 096 dimensions, mais encode moins d’information. Les modèles les plus performants sur le classement MTEB (Massive Text Embedding Benchmark) atteignent 4 096 dimensions et 7 milliards de paramètres, ce qui en fait des modèles coûteux à déployer ^[10]. Pour des applications en temps réel ou sur des ressources limitées, un modèle compact offre souvent un excellent compromis entre qualité et coût.

La fenêtre de contexte. Chaque modèle d’embedding a une limite sur le nombre de tokens qu’il peut traiter en entrée. Au-delà, le texte doit être découpé en chunks avant d’être encodé ^[11]. Cette contrainte impose un choix stratégique dans le découpage : des chunks trop petits perdent le contexte, des chunks trop grands dépassent la fenêtre du modèle.

Ce qu’il faut retenir (et les pièges à éviter)

Un embedding est un vecteur de nombres qui représente le sens d’un texte dans un espace géométrique. Voici les points essentiels à garder en tête :

• Ne pas confondre mots-clés et sens. La recherche par embedding est sémantique : elle trouve des résultats pertinents même quand aucun mot ne correspond exactement ^[9].
• La qualité dépend du modèle et du domaine. Un modèle généraliste appliqué sur du texte de spécialité produira des embeddings médiocres. Investir dans un modèle adapté au domaine ou le fine-tuner sur vos données est souvent le meilleur levier d’amélioration ^[1].
• Le chunking est une décision d’ingénierie, pas un détail. La taille des chunks, leur chevauchement et la fenêtre de contexte du modèle d’embedding doivent être cohérents entre eux ^[11]. Un mauvais chunking casse la qualité de la recherche en aval.
• Plus de dimensions n’est pas toujours mieux. Un vecteur de 1 024 dimensions sur un corpus petit et homogène sera souvent surdimensionné. Commencez par un modèle compact (384 dimensions) et mesurez la qualité avant de monter en puissance ^[10].
• La similarité cosinus n’est pas une probabilité. Un score de 0.9 ne signifie pas « 90 % de pertinence ». C’est un classement relatif : utilisez-la pour trier, pas pour fixer un seuil absolu ^[3].

Pour démarrer concrètement : prenez un jeu de données textuel représentatif de votre domaine, encodez-le avec un modèle open-source comme BGE-M3, stockez les vecteurs dans une base vectorielle (Qdrant, Milvus, ou FAISS), et mesurez la qualité de la recherche cosinus sur 20 à 30 requêtes réelles. C’est le meilleur moyen de sentir ce qu’un embedding change concrètement à la pertinence de vos résultats.

Sources

• [1] PhysBERT: A Text Embedding Model for Physics Scientific Literature · Thorsten Hellert et al. · 2024 · preprint · arXiv:2408.09574
• [2] Building Applications with AI Agents Designing and Implementing Multiagent Systems · livre · Amazon
• [3] RAG with Python Cookbook Practical Recipes from Data Preprocessing to LLM Agents · livre · Amazon
• [4] Towards General Text Embeddings with Multi-stage Contrastive Learning · Zehan Li et al. · 2023 · preprint · arXiv:2308.03281
• [5] Open-World 3D Scene Graph Generation for Retrieval-Augmented Reasoning · Fei Yu et al. · 2025 · preprint · arXiv:2511.05894
• [6] VideoRAG: Retrieval-Augmented Generation with Extreme Long-Context Videos · Xubin Ren et al. · 2025 · preprint · arXiv:2502.01549
• [7] Data Engineering with Generative and Agentic AI on AWS · livre · Amazon
• [8] Quantifying the Accuracy and Cost Impact of Design Decisions in Budget-Constrained Agentic LLM Search · Kyle McCleary et al. · 2026 · preprint · arXiv:2603.08877
• [9] Designing Data-Intensive Applications, 2nd Edition · livre · Amazon
• [10] Jasper and Stella: distillation of SOTA embedding models · Dun Zhang et al. · 2024 · preprint · arXiv:2412.19048
• [11] Hands-On RAG for Production · Ofer Mendelevitch and Forrest Sheng Bao · livre · Amazon