Embeddings et vectorisation : le vocabulaire minimum pour suivre

Dès qu'une conversation sur l'IA en entreprise dépasse la première demi-heure, trois mots finissent par tomber : embeddings, vecteurs, base vectorielle. Ils arrivent souvent sans explication, comme s'ils allaient de soi, et la discussion continue sans que la moitié de la salle sache exactement de quoi il est question.

C'est dommage, parce que le concept est simple et qu'il ne demande aucune mathématique pour être compris. Voici les embeddings expliqués avec des mots ordinaires : ce que contient un vecteur, ce que la machine mesure quand elle compare deux textes, et pourquoi cette mécanique change la façon dont on cherche de l'information.

L'objectif de cet article est utilitaire. Une fois ce vocabulaire posé, les sujets qui en dépendent deviennent lisibles : la recherche augmentée sur vos documents, le choix d'une base de données spécialisée, la déduplication de fiches clients ou le classement automatique de demandes entrantes.

Un embedding, c'est quoi exactement

Un embedding est une liste de nombres qui représente un morceau de texte. Rien de plus. Là où l'informatique classique stocke la phrase « le contrat arrive à échéance en mars » comme une suite de caractères, un modèle d'embedding la transforme en une liste de plusieurs centaines ou milliers de nombres, par exemple 768 ou 1 536 valeurs.

Cette liste s'appelle un vecteur. Prise isolément, elle ne veut rien dire : aucun de ces nombres ne correspond à une notion identifiable. Ce qui compte, c'est la position relative des vecteurs les uns par rapport aux autres. Le modèle a été entraîné pour que deux textes de sens proche produisent deux vecteurs proches, et deux textes sans rapport des vecteurs éloignés.

C'est tout le tour de force de la vectorisation de texte : elle transforme une question de sens, que l'ordinateur ne sait pas traiter, en une question de distance, qu'il traite très bien et très vite.

Les embeddings expliqués par l'image de la carte

Imaginez une carte géographique où chaque texte serait une ville. Les documents parlant de facturation se retrouvent dans une même région, ceux parlant de recrutement dans une autre, à l'autre bout de la carte. Une note sur les notes de frais atterrit quelque part entre la facturation et la gestion du personnel, plus près de la première.

Un embedding, c'est la coordonnée de la ville. Sauf que la carte n'a pas deux dimensions mais plusieurs centaines, ce qui lui permet de représenter simultanément le thème, le ton, la langue, le niveau de formalité et beaucoup d'autres nuances que nous ne savons pas nommer.

Chercher devient alors une opération géométrique : on place la question sur la carte, et on regarde quels documents sont dans le voisinage. La mesure utilisée s'appelle le plus souvent la similarité cosinus. Elle compare la direction de deux vecteurs et renvoie une valeur entre 0 et 1, où 1 signifie « même direction, donc même sens ». Vous croiserez ce terme partout : c'est simplement l'outil qui mesure la similarité de texte.

L'idée n'est pas neuve. Elle descend des travaux sur les représentations vectorielles de mots publiés au début des années 2010, qui montraient déjà qu'un modèle statistique pouvait placer « roi » et « reine » à une distance comparable à celle qui sépare « homme » et « femme ». Les modèles actuels font la même chose sur des phrases et des paragraphes entiers, avec une finesse sans commune mesure.

Pourquoi la recherche sémantique trouve ce que les mots-clés ratent

La recherche par mots-clés compare des chaînes de caractères. Si le document dit « résiliation » et que l'utilisateur tape « annuler mon abonnement », rien ne sort. La recherche sémantique, elle, compare des vecteurs, et les deux formulations se retrouvent voisines sur la carte.

Les gains sont concrets et faciles à observer sur vos propres données :

• Les synonymes et le jargon. « Congé sans solde » et « absence non rémunérée » sont deux façons de dire la même chose. Un index de mots-clés a besoin qu'on lui apprenne ce lien, un embedding le connaît déjà.
• Les reformulations maladroites. Les vraies questions des utilisateurs sont mal orthographiées, incomplètes, parfois posées à l'envers. La proximité de sens résiste bien mieux à ce bruit qu'une correspondance exacte.
• Le multilingue. Certains modèles alignent les langues dans le même espace : une question en français peut alors ramener un document en anglais qui répond exactement.
• Le regroupement automatique. En dehors de la recherche, comparer les vecteurs permet de détecter les doublons dans une base clients ou de regrouper des demandes entrantes par thème sans écrire une seule règle.

C'est cette mécanique qui rend possible la recherche augmentée sur vos propres documents, que nous avons détaillée dans notre article sur le RAG appliqué aux documents d'entreprise : on découpe le corpus, on vectorise chaque morceau, on vectorise la question, et on donne au modèle les morceaux les plus proches.

Et ce que la recherche sémantique rate, elle

C'est la partie que les présentations commerciales oublient. La proximité de sens est parfois exactement ce qu'il ne faut pas.

• Les identifiants exacts. Une référence produit « XK-4471 » et une référence « XK-4417 » sont sémantiquement identiques pour un modèle. Elles désignent pourtant deux pièces différentes. Sur les codes, les numéros de facture et les immatriculations, la recherche par mots-clés reste supérieure.
• La négation. « Le congé est accordé » et « le congé n'est pas accordé » sont très proches dans l'espace vectoriel. Beaucoup de modèles gèrent mal cette inversion, alors que le sens est opposé.
• Les nombres et les dates. Un seuil à 10 000 euros et un seuil à 100 000 euros se ressemblent pour un embedding. Toute recherche à contrainte chiffrée doit passer par un filtre classique.
• Les mots rares propres à votre métier. Un modèle généraliste n'a jamais vu votre nomenclature interne. Il la traitera comme du bruit, et placera vos documents au mauvais endroit sur la carte.

La conclusion pratique est simple : dans la vraie vie, on combine les deux. On appelle cela la recherche hybride, et c'est aujourd'hui l'approche par défaut dans les systèmes sérieux. Un score de mots-clés, un score sémantique, une fusion des deux classements, et souvent une étape de reclassement final par un modèle plus lourd sur la vingtaine de résultats retenus.

Choisir un modèle d'embedding : les quatre critères

Il existe des dizaines de modèles, des services par API et des modèles ouverts que l'on fait tourner soi-même. Quatre critères suffisent à trancher.

Un point qui compte plus que le classement dans un tableau de benchmarks : le jour où vous changez de modèle, vous devez tout revectoriser. Les vecteurs produits par deux modèles différents ne sont pas comparables entre eux, jamais. Prévoyez cette opération dès la conception, comme une opération de maintenance normale et non comme un accident. Et lisez les classements avec la prudence que nous recommandions dans notre article sur la lecture d'un benchmark de modèle : un écart de deux points sur un score public ne dit rien de vos documents à vous.

Le vocabulaire minimum, en six termes

• Vecteur. La liste de nombres qui représente un texte.
• Dimension. La longueur de cette liste.
• Chunk. Le morceau de document que l'on vectorise. Trop grand, il noie l'information ; trop petit, il perd le contexte. Entre 200 et 500 mots est un point de départ raisonnable.
• Index vectoriel. La structure qui permet de retrouver les voisins d'un vecteur sans comparer avec la totalité de la base.
• Top-k. Le nombre de résultats les plus proches que l'on récupère. Souvent entre 5 et 20.
• Reclassement. Une seconde passe qui réordonne les résultats avec un modèle plus précis et plus lent.

Ce que cela change pour vos décisions

Comprendre les embeddings expliqués de cette façon vous évite deux erreurs coûteuses. La première consiste à croire qu'une base vectorielle remplace un moteur de recherche : elle le complète, elle ne le remplace pas, et un système qui ne sait pas retrouver un numéro de facture exact sera jugé cassé par ses utilisateurs. La seconde consiste à confondre représentation et compréhension : un modèle qui place bien vos documents sur la carte ne sait pas pour autant ce qu'ils disent, il sait seulement qu'ils se ressemblent.

Concrètement, si vous démarrez : découpez cinquante documents représentatifs, vectorisez-les avec un modèle multilingue courant, posez vingt questions réelles d'utilisateurs et regardez si le bon passage remonte dans les cinq premiers résultats. Ce petit test, monté en une journée, vous en apprendra plus que trois semaines de comparatifs. Il vous dira aussi si votre problème relève de la recherche ou d'une autre approche, question que nous avons traitée dans notre comparaison entre fine-tuning et RAG.