Un grand modèle de langage (LLM) est impressionnant, mais il ne connaît que ce qu'il a vu pendant son entraînement : il ignore tout de vos données — vos fiches produit, vos procédures internes, l'état d'une commande précise. Pour qu'il réponde sur ces sujets, il faut lui fournir les bons passages au bon moment. Mais comment retrouver, dans des centaines de documents, ceux qui parlent vraiment de la question posée — surtout quand l'utilisateur n'emploie pas les mêmes mots que vos documents ? C'est le rôle des embeddings : transformer du texte en vecteurs pour rechercher par le sens, et non par les mots. C'est la première brique de tout système RAG (Retrieval-Augmented Generation).
Pourquoi un LLM ne suffit pas à répondre sur vos données
Un modèle de langage est entraîné sur un grand corpus public, figé à une certaine date. Il n'a jamais vu votre base documentaire interne. Posez-lui une question sur votre politique de remboursement : au mieux il invente une réponse plausible, au pire il se trompe — dans les deux cas, il hallucine.
La parade naïve serait de tout coller dans le prompt : l'intégralité du corpus à chaque question. Cela ne tient pas. La fenêtre de contexte est limitée, le coût explose avec le nombre de tokens, et noyer le modèle sous des pages non pertinentes dégrade sa réponse au lieu de l'améliorer. Il faut donc faire l'inverse : ne lui donner que les quelques passages utiles à la question. Reste à les retrouver — et c'est là que les embeddings entrent en jeu.
Qu'est-ce qu'un embedding ?
Un embedding est la représentation d'un texte sous forme de vecteur : une liste de nombres à virgule de taille fixe, souvent quelques centaines à quelques milliers de dimensions. Un modèle d'embedding prend un texte en entrée — un mot, une phrase, un paragraphe — et renvoie ce vecteur.
Ce vecteur n'a rien d'aléatoire : c'est une empreinte numérique du sens du texte. Deux textes qui veulent dire la même chose produisent des vecteurs proches ; deux textes sans rapport produisent des vecteurs éloignés. Le modèle a appris cette correspondance « sens → position » sur d'immenses quantités de texte.
Le sens devient géométrie
L'idée clé : une fois le texte transformé en vecteur, on peut le situer dans un espace à plusieurs centaines de dimensions. Dans cet espace, la proximité géométrique traduit la proximité de sens. Des formulations différentes mais synonymes se retrouvent côte à côte, même sans aucun mot en commun.
« Comment renvoyer un article ? » et « Je veux être remboursé » ne partagent pas un seul mot, mais relèvent du même sujet : leurs vecteurs sont voisins. « Quelle tente pour deux personnes ? » parle d'autre chose : son vecteur atterrit loin des deux premiers. C'est exactement ce comportement qui permet de chercher par intention plutôt que par vocabulaire exact.
Mesurer la proximité : la similarité cosinus
Pour exploiter cette géométrie, il faut chiffrer la proximité entre deux vecteurs. La mesure la plus courante est la similarité cosinus : elle regarde l'angle entre deux vecteurs, indépendamment de leur longueur.
- Vecteurs alignés (même direction) → cosinus proche de 1 → sens très proches.
- Vecteurs perpendiculaires → cosinus proche de 0 → sans rapport.
- Vecteurs opposés → cosinus proche de -1 → sens contraires.
Rechercher les documents pertinents revient alors à une opération simple : transformer la question en vecteur, puis trouver les vecteurs de documents dont la similarité cosinus avec la question est la plus élevée.
Recherche par mot-clé ou recherche sémantique ?
C'est ce qui distingue la recherche sémantique de la traditionnelle recherche par mot-clé. Une recherche par mot-clé cherche une correspondance de chaînes de caractères : la requête « récupérer mon argent » ne trouvera pas un document qui parle de « remboursement », faute de mots communs. La recherche par embeddings, elle, rapproche les deux par le sens.
| Aspect | Recherche par mot-clé | Recherche sémantique (embeddings) |
|---|
| Critère | Correspondance de mots | Proximité de sens |
| « récupérer mon argent » trouve « remboursement » | ❌ Non | ✅ Oui |
| Sensible aux synonymes / reformulations | Non | Oui |
| Tolérance au vocabulaire de l'utilisateur | Faible | Élevée |
Cette capacité à retrouver le bon passage même quand les mots diffèrent est précisément ce dont un RAG a besoin pour répondre aux questions réelles des utilisateurs, qui ne reprennent jamais le vocabulaire exact de la documentation.
Les embeddings sont produits par des modèles d'embedding, distincts des LLM génératifs : ils ne « parlent » pas, ils ne font que transformer du texte en vecteurs. On y accède de deux façons.
- Par API : un appel à un fournisseur renvoie le vecteur. Côté propriétaire,
text-embedding-3-small et text-embedding-3-large (OpenAI) sont des références ; d'autres fournisseurs comme Cohere, Voyage AI ou Mistral proposent les leurs. - En local / open source : des modèles téléchargeables comme la famille
sentence-transformers, BGE ou E5 tournent sur votre propre infrastructure, sans envoyer vos données à un tiers — au prix d'un peu d'ingénierie.
Deux règles pratiques à retenir. D'abord, un même modèle produit toujours des vecteurs de taille fixe (par exemple 1536 dimensions) : c'est cette taille qui définit l'espace. Ensuite — et c'est essentiel — il faut indexer les documents et encoder les requêtes avec le même modèle : deux modèles différents créent des espaces incompatibles, où les distances n'ont plus aucun sens.
Conclusion
Un embedding transforme un texte en vecteur dont la position encode le sens : les textes proches par le sens deviennent des voisins dans l'espace, ce qu'on mesure par la similarité cosinus. C'est le fondement de la recherche sémantique, et donc de tout RAG. Mais dès qu'on dépasse quelques dizaines de documents, comparer la requête à chaque vecteur « à la main » ne tient plus la charge : il faut une infrastructure capable de stocker ces vecteurs et de retrouver les plus proches en un instant. C'est précisément le rôle des bases vectorielles.
