La recherche lexicale reste efficace et peu coûteuse. Elle échoue pourtant sur une classe de requêtes précise, et comprendre laquelle évite de la remplacer là où elle fonctionne très bien.
Ce que fait réellement un index inversé
Un index inversé associe chaque terme à la liste des documents qui le contiennent. Une fonction de pondération comme BM25 classe ensuite les documents selon la fréquence des termes de la requête, atténuée par la fréquence du terme dans le corpus et par la longueur du document. Le modèle est un sac de mots : l’ordre des termes n’intervient pas, et deux termes distincts sont deux dimensions orthogonales.
Cette propriété est aussi la limite. « Vélo électrique » et « VAE » ne partagent aucun token. Un index lexical les considère comme sans rapport, quelle que soit la qualité de la pondération. Les remèdes classiques — listes de synonymes, stemming, expansion de requête — sont des correctifs maintenus à la main, qui vieillissent mal et se multiplient dès qu’on ajoute une langue.
Ce qu’apporte la représentation dense
Un modèle d’embedding projette un texte dans un espace de dimension fixe, typiquement quelques centaines de composantes, où la proximité géométrique approxime la proximité de sens. On compare ensuite deux vecteurs avec la similarité cosinus :
cos(a, b) = (a · b) / (‖a‖ · ‖b‖)Le cosinus ignore la norme et ne retient que la direction, ce qui le rend insensible à la longueur du texte encodé. Si les vecteurs sont normalisés à la production, le cosinus se ramène au produit scalaire, moins coûteux à évaluer — c’est la raison pour laquelle la plupart des index normalisent à l’ingestion.
L’intérêt pratique : deux formulations différentes du même besoin se retrouvent proches dans l’espace, sans dictionnaire de synonymes. Avec un modèle multilingue, une requête en français peut atteindre un document en anglais, parce que les deux sont projetés dans le même espace.
Là où le lexical reste supérieur
La recherche dense se comporte mal sur les identifiants exacts. Une référence produit, un numéro de série, un nom propre rare ou un extrait de code sont souvent absents ou mal représentés dans le vocabulaire du modèle. L’index inversé, lui, les retrouve exactement. La négation et les contraintes strictes lui échappent également : un embedding ne représente pas « sans gluten » de façon fiablement opposée à « avec gluten ».
C’est pourquoi les systèmes de production combinent les deux signaux. On exécute les deux recherches en parallèle et on fusionne les listes, par exemple avec une combinaison pondérée des scores ou une fusion par rang réciproque, qui a l’avantage de ne pas dépendre de l’échelle des scores.
Les filtres ne sont pas un détail
En pratique, une requête n’est presque jamais purement sémantique : elle est restreinte à une langue, une période, un espace client. Filtrer après la recherche vide les résultats dès que le filtre est sélectif ; filtrer avant impose de parcourir un sous-ensemble sur lequel l’index n’a pas été construit. Un moteur vectoriel utilisable doit appliquer les prédicats de métadonnées pendant le parcours du graphe, et non après. Nous y reviendrons dans une note dédiée.
Retenir
Le passage au vectoriel n’est pas un remplacement mais un élargissement du rappel sur les reformulations, les langues et les paraphrases. La question à se poser avant de migrer n’est pas « BM25 est-il dépassé », mais « quelle proportion de mes requêtes échoue faute de recouvrement lexical ».