Embeddings et recherche sémantique — comment les LLM comprennent le sens

Un embedding transforme un texte en coordonnées dans un espace mathématique où la proximité exprime la parenté de sens. Comprendre ce mécanisme, c'est comprendre pourquoi RAG fonctionne — et pourquoi il échoue.

En bref

Quand vous tapez “voiture pas chère à acheter” dans un moteur de recherche, vous ne voulez pas une page qui contient exactement ces mots — vous voulez des résultats sur l’achat de véhicules d’occasion à petit budget. La recherche sémantique fait cette distinction. Elle repose sur les embeddings : des représentations numériques qui encodent le sens d’un texte, pas seulement ses mots. Cet article explique ce que sont ces vecteurs, pourquoi ils nécessitent des outils d’indexation spécialisés, et ce que cela implique concrètement dans un système RAG.

Du mot au vecteur : une brève histoire

L’idée d’encoder du texte sous forme de nombres n’est pas nouvelle. Les premières méthodes — TF-IDF, bag-of-words — traitaient un document comme un sac de mots, sans ordre ni sens. Elles étaient efficaces pour la correspondance exacte, pas pour la compréhension.

En 2013-2014, Word2Vec et GloVe ont posé les bases des embeddings modernes. Ces modèles attribuent à chaque mot un vecteur fixe appris sur de vastes corpus. La propriété remarquable : des mots utilisés dans des contextes similaires se retrouvent proches dans l’espace vectoriel. “Roi” et “reine” sont voisins. “Paris” et “France” entretiennent une relation géométrique similaire à celle de “Berlin” et “Allemagne”.

Mais ces modèles avaient un défaut fondamental : chaque mot n’avait qu’un seul vecteur, quel que soit son contexte. “Avocat” (le fruit) et “avocat” (le juriste) recevaient la même représentation.

BERT, publié en 2018 par Devlin et al. chez Google, a résolu ce problème avec des représentations contextualisées : le vecteur d’un mot dépend de ses voisins dans la phrase. Une avancée décisive — mais qui créait un nouveau problème pour la recherche à grande échelle.

Sentence-BERT : le tournant pratique

Pour comparer deux phrases avec BERT original, il fallait les encoder ensemble en un seul passage. Sur 10 000 phrases, cela représente environ 50 millions de paires à traiter — soit 65 heures de calcul sur un GPU standard. Inutilisable en production.

Reimers et Gurevych (EMNLP 2019) ont contourné ce problème avec Sentence-BERT (SBERT). L’architecture utilise deux encodeurs BERT identiques travaillant en parallèle : chaque phrase est encodée séparément, puis les représentations sont comparées. Le temps de traitement pour 10 000 comparaisons tombe à 5 secondes.

Ce changement architectural a posé le standard de toute la recherche sémantique moderne : encoder séparément, stocker, comparer. C’est le fondement du pipeline RAG.

Comment fonctionne un embedding de phrase

Un modèle d’embedding prend un texte en entrée et produit un vecteur de nombres flottants — typiquement entre 384 et 4096 dimensions selon le modèle. Ce vecteur est une coordonnée dans un espace mathématique où la proximité entre points exprime la parenté de sens.

La métrique utilisée est la similarité cosinus : elle mesure l’angle entre deux vecteurs, indépendamment de leur taille. Deux phrases proches sémantiquement auront un cosinus proche de 1. Deux phrases sans rapport, proche de 0. Des phrases de sens opposé, négatif.

Ce qui rend ce mécanisme puissant : une requête formulée différemment d’un document peut quand même retrouver ce document, si les deux ont des vecteurs proches. “Voiture pas chère” et “achat véhicule budget serré” peuvent se retrouver dans le même voisinage.

Ce qui le rend fragile : le vecteur capture principalement la similarité de surface — le thème, le registre lexical, la syntaxe. Il peine sur la sémantique implicite : les sous-entendus conversationnels, le raisonnement par analogie, la pragmatique. Une question rhétorique et une question sincère peuvent produire des vecteurs très proches alors qu’elles appellent des réponses opposées.

Un autre biais structurel mérite d’être mentionné : les modèles d’embedding projettent les textes dans un cône étroit de l’espace vectoriel, n’utilisant qu’une fraction des dimensions disponibles. Ce phénomène, appelé anisotropie, entraîne une compression artificielle de la diversité sémantique.

Pourquoi les bases SQL ne suffisent plus

Une base de données classique excelle dans un cas : vous cherchez une valeur exacte. “Donne-moi tous les clients dont le nom est Dupont.” La requête compare des chaînes de caractères ou des nombres.

La recherche par similarité vectorielle est un problème différent. La question n’est plus “est-ce que ces deux valeurs sont identiques ?” mais “parmi un million de vecteurs, lesquels sont les plus proches de ce vecteur requête ?”. C’est le problème du k plus proche voisin (kNN).

La recherche exacte a une complexité proportionnelle au nombre de vecteurs multiplié par leur dimension. Sur un milliard de vecteurs à 768 dimensions, c’est infaisable en temps réel.

La solution : les algorithmes de recherche approchée (ANN — Approximate Nearest Neighbor). Ils renoncent à la garantie de trouver les voisins exacts pour trouver des voisins très proches en une fraction du temps.

Les deux grandes familles d’indexation

Deux approches dominent l’indexation ANN dans les vector stores :

IVF (Inverted File Index) — Partition de l’espace vectoriel en clusters via k-means. Lors d’une requête, on ne cherche que dans les clusters les plus proches (paramètre nprobes). La compression par quantification de produit (PQ) réduit encore la mémoire : chaque vecteur est découpé en sous-vecteurs, chacun approximé par un code de quelques bits. C’est l’algorithme au cœur de FAISS, la bibliothèque de Meta AI (Johnson et al., 2017), référence industrielle et académique.

HNSW (Hierarchical Navigable Small World) — Approche par graphe. Chaque vecteur est un nœud connecté à ses voisins proches. Une hiérarchie de couches permet une navigation rapide : on entre dans le graphe par les couches les plus éparses (longue portée), on descend vers les couches denses (précision locale). La complexité de recherche est logarithmique en fonction du nombre de vecteurs. HNSW offre en général un meilleur compromis rappel/latence qu’IVF, au prix d’une empreinte mémoire plus élevée. Formalisé par Malkov et Yashunin (2016).

Critère	IVF-PQ	HNSW
Empreinte mémoire	Faible (compression PQ)	Élevée
Latence de requête	Variable (dépend de nprobes)	Stable, logarithmique
Rappel à iso-budget	Légèrement inférieur	Généralement supérieur
Cas d’usage typique	Milliards de vecteurs, mémoire contrainte	Millions de vecteurs, latence critique

L’écosystème des vector stores

De bibliothèques d’indexation, le domaine a évolué vers des bases de données vectorielles complètes, avec persistance, filtres sur métadonnées, et APIs standardisées. Quelques représentants :

FAISS (Meta AI, open-source) : bibliothèque de référence pour la performance brute, CPU et GPU, jusqu’aux milliards de vecteurs. Pas une base de données autonome — s’intègre dans une architecture.
Milvus (open-source, LF AI) : architecture distribuée, conçue pour des volumes massifs, supporte plusieurs types d’index.
Weaviate (open-source, Go) : orienté objets avec schéma, GraphQL API, modules d’embedding intégrés.
Chroma (open-source, Python) : embarqué, zéro configuration, ciblé développement local.
Pinecone (propriétaire, cloud) : entièrement managé, scaling automatique, latence garantie par contrat.

Aucune de ces solutions n’est universellement supérieure. Le choix dépend du volume de données, des contraintes de latence, de l’infrastructure disponible et du budget.

Le pipeline RAG et ses points de fragilité

Les embeddings et les vector stores sont les composants centraux d’un pipeline RAG (Retrieval-Augmented Generation). Le principe : au lieu de mémoriser des connaissances dans les poids du modèle, on indexe des documents dans un vector store. À chaque requête, on recherche les passages les plus pertinents et on les injecte dans le contexte du LLM.

Le pipeline complet :

Découpage des documents en passages (chunking)
Embedding de chaque passage
Indexation dans le vector store
À l’inférence : embedding de la requête, recherche ANN, récupération des top-k passages
Injection dans le prompt du LLM

Ce pipeline est conceptuellement simple. Il est fragile en pratique. Gao et al. (2023) ont documenté les échecs systématiques dans une revue de la littérature, et Barnett et al. (2024) ont identifié sept points de défaillance récurrents :

Un découpage trop fin perd le contexte. Trop large introduit du bruit.
Le modèle d’embedding peut ne pas capter les nuances du domaine métier.
La requête et les documents peuvent appartenir à des distributions sémantiques différentes, même s’ils traitent du même sujet.
La similarité cosinus ne capture pas la confiance : un vecteur “ambigu” et un vecteur “précis” peuvent être traités comme équivalents.

Le dernier point est documenté dans Semantics at an Angle (2025) : la similarité cosinus ignore la magnitude du vecteur, effaçant une information potentiellement utile.

Dense, sparse, hybride : un débat non tranché

La communauté oppose deux grandes familles de méthodes de recherche. Les méthodes denses (embeddings) capturent la sémantique mais peuvent rater des correspondances exactes. Les méthodes sparses (BM25, TF-IDF) repèrent les correspondances lexicales précises mais ignorent le sens.

La réponse pratique — combiner les deux en retrieval hybride — est empiriquement supérieure sur la plupart des tâches. Elle introduit cependant un paramètre de pondération difficile à calibrer sans données de validation. Des travaux récents (DAT, 2025) explorent un ajustement dynamique par requête, mais cette approche n’est pas encore standardisée.

Sur certaines tâches — récupération de code, domaines très spécialisés, hors-domaine — BM25 surpasse systématiquement les méthodes denses. Ce résultat, mis en évidence sur le benchmark BEIR, reste difficile à prédire a priori.

Ce qu’il faut retenir

Un embedding est une représentation vectorielle d’un texte dans un espace où la proximité géométrique exprime la parenté de sens. C’est le mécanisme qui permet à un système de comprendre l’intention d’une requête, pas seulement ses mots.
Les vector stores sont des bases de données optimisées pour la recherche par similarité à grande échelle. Les deux algorithmes dominants — IVF et HNSW — offrent des compromis différents entre mémoire, latence et précision.
RAG repose entièrement sur la qualité du retrieval : un mauvais embedding ou un mauvais découpage de documents produit des résultats médiocres, indépendamment de la puissance du LLM.
La similarité cosinus a des limites structurelles : elle ignore la magnitude du vecteur et peine sur la sémantique implicite. Ces limites sont actives dans tout pipeline RAG.
La combinaison dense + sparse (retrieval hybride) est empiriquement supérieure à chaque méthode seule sur la plupart des tâches, mais introduit une complexité de calibration.