Retrieval : retrouver le bon passage

Le retrieval est le goulot d'étranglement silencieux du RAG

Quand un système RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire produit une réponse fausse ou incomplète, le réflexe naturel est d'incriminer le LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire : il aurait mal compris la question, ou mal rédigé la synthèse. Dans une proportion importante de cas observés en production, le LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire n'est pourtant coupable de rien — il a simplement généré la meilleure réponse possible à partir d'un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire qui ne contenait pas l'information pertinente. Le problème s'est joué une étape plus tôt, au moment du retrieval : les bons passages n'ont tout simplement pas été récupérés.

Le retrieval est l'étape qui, à partir d'une requête utilisateur, interroge l'index construit sur le corpus (voir le chapitre sur le chunkingChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire et celui sur les bases vectorielles) et en extrait un sous-ensemble de passages censés contenir la réponse. Tout ce que le LLM produira ensuite est borné par la qualité de cette sélection : un modèle de génération excellent ne peut pas répondre correctement avec un contexte qui ne contient pas l'information recherchée, et il ne peut pas deviner qu'il lui en manque une partie.

Contrairement à un moteur de recherche classique qui peut renvoyer une liste vide, un LLM recevant un contexte incomplet ou hors sujet produit presque toujours une réponse — formulée avec la même assurance que s'il disposait du bon passage. Améliorer le retrieval a donc un effet direct et mesurable sur le taux d'hallucinationhallucinationIAProduction par un modèle d'un énoncé faux formulé avec la même assurance qu'un fait établi. Le phénomène est structurel : le modèle optimise la vraisemblance, pas la vérité.Voir dans le glossaire perçu, souvent plus important que d'ajuster le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire de génération.

Recherche lexicale : BM25, la base solide

BM25 (Best Matching 25) est un algorithme de recherche lexicale, héritier direct des moteurs de recherche classiques. Son principe : un document est pertinent pour une requête s'il contient les mêmes termes, pondérés selon leur rareté dans le corpus et leur fréquence dans le document.

Concrètement, BM25 combine deux signaux. Le TF (term frequency) récompense un document où le terme recherché apparaît souvent, avec un effet de saturation — passer de 1 à 2 occurrences compte plus que passer de 20 à 21. L'IDF (inverse document frequency) pénalise les termes trop communs : le mot « le » n'apporte aucune information discriminante, tandis qu'un identifiant technique rare comme « CVE-2024-3094 » concentre fortement le signal de pertinence.

La force de BM25 tient précisément à ce qu'on lui reproche parfois d'être « dépassé » : il excelle sur les correspondances exactes. Un numéro de série, un code d'erreur, un acronyme métier, le nom exact d'une fonction dans une base de code — sur tous ces cas, BM25 retrouve le document pertinent de façon quasi infaillible, là où une recherche vectorielle peut se laisser distraire par la proximité sémantique d'un terme voisin mais non identique.

Une requête « comment résilier mon abonnement » ne matchera pas un document qui parle uniquement de « mettre fin à mon contrat » si aucun des deux textes ne partage suffisamment de termes exacts. BM25 raisonne sur des chaînes de caractères, pas sur du sens. C'est exactement la limite que la recherche vectorielle vient combler.

Recherche vectorielle dense : capter le sens

La recherche vectorielle dense encode la requête et chaque chunk du corpus en vecteurs numériques (embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire), puis mesure leur proximité — le plus souvent via une similarité cosinus. Deux formulations différentes d'une même idée (« résilier mon abonnement » et « mettre fin à mon contrat ») se retrouvent proches dans cet espace même si elles ne partagent presque aucun mot, parce que le modèle d'embedding a appris à représenter le sens plutôt que la surface lexicale. Cette capacité est précieuse pour toutes les requêtes formulées en langage naturel, avec des synonymes ou un vocabulaire différent de celui du document source — c'est-à-dire la majorité des questions posées par un utilisateur qui ne connaît pas la terminologie exacte de la documentation.

Mais cette force a un revers symétrique à celui de BM25 : la recherche dense peut manquer une correspondance exacte critique si le modèle d'embedding n'a pas appris à représenter fidèlement un tokentokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire rare — un identifiant, une référence produit, un nom propre peu fréquent dans ses données d'entraînementdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire. Un vecteur moyenne les concepts d'un texte ; il ne préserve pas nécessairement l'exactitude d'une chaîne de caractères précise.

Recherche hybride : combiner les deux approches

Aucune des deux approches ne domine l'autre sur l'ensemble des requêtes réelles d'un corpus hétérogène. C'est pourquoi la quasi-totalité des architectures RAG de production actuelles adoptent une recherche hybride : la requête est envoyée en parallèle à un moteur BM25 et à un moteur vectoriel, et les deux listes de résultats sont ensuite combinées.

Reste à résoudre un problème simple en apparence mais délicat en pratique : les deux moteurs produisent des scores sur des échelles totalement différentes. Un score BM25 peut valoir 12,4, un score de similarité cosinus 0,87 — les comparer directement, ou les additionner après une normalisation naïve, produit des résultats instables selon la requête. C'est le rôle de la fusion de rangs.

Fusion des résultats : Reciprocal Rank Fusion

La méthode la plus utilisée en production pour combiner deux listes de résultats hétérogènes est le Reciprocal Rank Fusion (RRF). Son principe évite justement le problème de comparaison de scores en ignorant les scores eux-mêmes et en ne retenant que le rang de chaque document dans chacune des deux listes.

Pour un document donné, son score RRF se calcule ainsi :

score_RRF(d) = somme sur chaque liste de résultats de  1 / (k + rang(d))

où k est une constante de lissage, généralement fixée à 60 dans la littérature originale et en pratique. Un document classé 1er dans la liste BM25 et 3e dans la liste vectorielle obtient un score cumulé plus élevé qu'un document classé 1er dans une seule des deux listes et absent de l'autre. RRF récompense donc la convergence des deux méthodes, ce qui est en général un bon indicateur de pertinence réelle : un passage jugé pertinent à la fois sur des critères lexicaux et sémantiques a statistiquement plus de chances d'être effectivement la bonne réponse qu'un passage qui ne convainc qu'un seul des deux moteurs.

Contrairement à une fusion par somme pondérée (score = α · score_BM25 + (1-α) · score_dense) qui exige de calibrer α par corpus et par cas d'usage, RRF fonctionne raisonnablement bien avec sa constante par défaut et sans normalisation préalable des scores. C'est pour cette raison qu'il est devenu le choix par défaut de la plupart des frameworks et bases vectorielles qui proposent une recherche hybride native.

Réécriture de requête (query rewrite)

Une requête utilisateur brute est rarement la formulation optimale pour un moteur de recherche, qu'il soit lexical ou vectoriel. Elle peut être trop courte, ambiguë hors contexte conversationnel, ou dépendante d'échanges précédents dans une session. La réécriture de requête intervient avant le retrieval pour transformerTransformerIAArchitecture introduite en 2017, fondée sur le mécanisme d'attention, qui traite une séquence entière en parallèle. Elle sert de base à tous les grands modèles de langage actuels.Voir dans le glossaire cette requête brute en une ou plusieurs requêtes mieux formées.

Plusieurs techniques coexistent, souvent combinées :

• Résolution des références conversationnelles. Dans un échange multi-tours, « et pour la version entreprise ? » n'a de sens qu'en connaissant la question précédente. La réécriture la reformule en version autonome — « quelles sont les conditions tarifaires de la version entreprise ? ».
• Expansion de requête. Le LLM génère des reformulations ou des termes associés (synonymes, acronymes développés, vocabulaire métier), et chaque variante est envoyée séparément au moteur de retrieval avant fusion des résultats. Cela compense en partie la faiblesse de BM25 sur les synonymes.
• HyDE (Hypothetical Document Embeddings). Plutôt que d'embedder directement la question, on demande au LLM de générer une réponse hypothétique plausible, puis on embedde cette réponse pour la recherche vectorielle. Une réponse hypothétique, même imparfaite, est structurellement plus proche d'un vrai passage de documentation qu'une question interrogative.
• Décomposition de requêtes complexes. Une question qui combine plusieurs sous-questions (« quelle est la différence de prix et de SLA entre l'offre standard et l'offre entreprise ? ») est découpée en sous-requêtes indépendantes, recherchées séparément puis recombinées.

Requête brute : « ça marche comment pour annuler ». Sans contexte, un moteur lexical ne sait pas s'il s'agit d'annuler un abonnement, une commande ou un rendez-vous. Après réécriture contextuelle, appuyée sur l'historique de la conversation où l'utilisateur venait de parler de facturation, la requête devient : « procédure d'annulation d'un abonnement en cours de facturation ». Le taux de récupération du bon passage augmente nettement avec cette seule transformation, avant même de toucher au moteur de recherche.

Top-k, reranking et fenêtre de contexte

Le paramètre top-k détermine combien de passages sont finalement retenus après retrieval (et éventuel reranking) pour être injectés dans le prompt du LLM. Ce choix arbitre un compromis direct : un k trop faible risque d'omettre un passage pertinent classé en 6e ou 7e position ; un k trop élevé dilue le contexte utile avec des passages marginaux, consomme des tokens, et peut dégrader la génération — un excès d'information non pertinente noie l'information réellement utile, même présente dans le prompt.

La pratique courante consiste à séparer deux étapes avec des k différents : une première récupération large (par exemple top-50) issue de la fusion hybride, suivie d'un reranking qui réordonne finement ces candidats, avant de ne conserver que les 5 à 10 meilleurs pour la génération finale.

Le reranking s'appuie généralement sur un cross-encoderCross-encoderIAModèle qui encode conjointement une requête et un document pour produire un score de pertinence, plus précis qu'un bi-encodeur mais plus coûteux à l'inférence.Voir dans le glossaire : contrairement à un modèle d'embedding classique (bi-encoder) qui encode indépendamment la requête et chaque document puis compare leurs vecteurs, un cross-encoder prend en entrée la paire requête-document concaténée et produit directement un score de pertinence. Cette architecture est plus précise, car le modèle fait interagir explicitement les tokens de la requête avec ceux du document — mais aussi plus coûteuse en calcul, ce qui interdit de l'appliquer à l'ensemble d'un corpus de plusieurs millions de documents. D'où le schéma en deux temps : le bi-encoder (ou BM25) pour un filtrage large et rapide, le cross-encoder pour un reclassement précis d'un petit nombre de candidats.

Ce gain de précisionprécisionIAProportion des alertes émises par un modèle qui sont justifiées. Elle s'oppose au rappel : améliorer l'une dégrade l'autre.Voir dans le glossaire a un coût de latence non négligeable : un cross-encoder appliqué à 50 candidats ajoute typiquement plusieurs centaines de millisecondes au temps de réponse total, contre quelques millisecondes pour un tri par score vectoriel simple. Dans un contexte de production avec des exigences de latence strictes (assistant conversationnel temps réel), ce coût doit être mesuré et budgété explicitement, pas découvert après déploiement.

Mesurer le retrieval : recall@k, MRR, précision

Sans mesure, toute affirmation sur la qualité d'un pipeline de retrieval reste une impression. Trois métriques standards permettent de l'évaluer objectivement, à condition de disposer d'un golden set — un ensemble de questions associées aux passages qui constituent la réponse correcte attendue.

• RecallrappelIAProportion des cas positifs réels effectivement détectés par un modèle. Sur un jeu déséquilibré, c'est un indicateur bien plus parlant que l'exactitude globale.Voir dans le glossaire@k mesure la proportion de requêtes pour lesquelles le passage pertinent figure bien parmi les k premiers résultats retournés. C'est la métrique la plus directement actionnable : un recall@10 de 0,72 signifie que, pour 28 % des questions du golden set, le bon passage n'apparaît même pas dans les dix premiers résultats — aucune génération, aussi bonne soit-elle, ne peut compenser cette absence.
• MRR (Mean Reciprocal Rank) mesure à quel rang moyen apparaît le premier résultat pertinent, en pénalisant fortement les rangs éloignés (l'inverse du rang est sommé puis moyenné). Un MRR proche de 1 signifie que le bon passage arrive presque toujours en première position ; un MRR de 0,3 signifie qu'il faut en moyenne parcourir plusieurs résultats avant de tomber dessus, ce qui pénalise directement l'efficacité d'un reranking en aval s'il n'est pas assez profond.
• Précision@k mesure, parmi les k résultats retournés, quelle proportion est effectivement pertinente. Une précision faible avec un recall élevé indique un pipeline qui retrouve bien l'information recherchée mais la noie dans du bruit — un signal fort pour investir dans le reranking plutôt que dans le retrieval initial.

Tester manuellement quelques requêtes donne une impression, pas une mesure. Un golden set de 50 à 150 questions représentatives, construit à partir de vraies requêtes utilisateurs si possible, permet de comparer objectivement deux configurations (avec ou sans hybridation, avec ou sans reranking, k=5 contre k=10) et de trancher sur des chiffres plutôt que sur une intuition.

Pièges fréquents en production

• Se fier uniquement à la recherche vectorielle par simplicité d'implémentation. De nombreux échecs de retrieval observés en production concernent des requêtes contenant un identifiant précis (référence produit, code d'erreur) que la recherche dense seule ne retrouve pas de façon fiable, faute d'hybridation avec BM25.
• Fixer top-k arbitrairement sans le valider sur un golden set. Une valeur qui « semble raisonnable » (souvent k=3 ou k=5 copié d'un tutoriel) peut être trop faible pour un corpus où l'information pertinente est dispersée sur plusieurs passages complémentaires.
• Ignorer la réécriture de requête dans un contexte conversationnel. Sans résolution des références à l'historique, un système multi-tours produit un retrieval de mauvaise qualité dès la deuxième question de l'échange, alors même que le retrieval fonctionnait bien en isolation sur la première question testée.
• Appliquer un reranking coûteux à un volume de candidats trop large. Reranker 500 candidats avec un cross-encoder pour n'en garder que 5 gaspille du calcul et de la latence sans bénéfice supplémentaire par rapport à un filtrage initial mieux calibré à 30 ou 50 candidats.
• Ne jamais mesurer le recall@k séparément de la qualité de génération finale. Un problème de retrieval mal diagnostiqué est souvent attribué à tort au LLM ou au prompt, ce qui conduit à optimiser la mauvaise étape du pipeline pendant des semaines sans résultat.
• Négliger la latence cumulée du pipeline complet. Réécriture, double recherche, fusion et reranking s'additionnent ; un pipeline non instrumenté peut dépasser un budget de latence acceptable sans qu'aucune étape individuelle ne semble, isolément, être le coupable.

Checklist avant mise en production

• La recherche hybride (BM25 + dense) est en place, pas uniquement l'une des deux approches.
• Une méthode de fusion de rangs (RRF ou équivalent) combine les deux listes sans dépendre d'une normalisation manuelle de scores instable.
• La réécriture de requête gère au minimum la résolution des références conversationnelles si le système est multi-tours.
• Le top-k de récupération initiale et le top-k final après reranking sont distincts et chacun validé sur un golden set, pas fixés par défaut.
• Un cross-encoder de reranking est utilisé si la latence budgétée le permet, avec sa contribution mesurée sur le recall@k et la précision@k.
• Un golden set de 50 questions minimum, représentatif des requêtes réelles, sert de référence pour toute évolution du pipeline de retrieval.
• Les métriques recall@k, MRR et précision@k sont mesurées avant et après tout changement de configuration, pas seulement en début de projet.
• La latence cumulée du pipeline complet (réécriture, double recherche, fusion, reranking) est mesurée de bout en bout, pas étape par étape isolément.