Recherche et évaluation pour RAG : pourquoi la récupération nécessite une étape de réclassement distincte
RAG a besoin de recherche et d’évaluation : les embeddings identifient des candidats mais ne peuvent pas évaluer leur pertinence. Une conception en deux étapes avec RRF, des cross-encoders, ColBERT et des rerankers basés sur des LLM.
De nombreuses équipes se heurtent au même problème avec la génération améliorée par la récupération d’informations. Sur un tableau blanc, le système semble simple : on insère la requête, on compare les vecteurs, on transmet les meilleurs résultats au modèle, et on obtient une réponse. En environnement de production, les problèmes apparaissent rapidement. Des documents pertinents sont manqués, des extraits irrelevants s’infiltrent, une question légèrement reformulée change la réponse, et les hallucinations persistent même lorsque la récupération d’informations semble avoir fonctionné.
La réponse habituelle consiste à remplacer le modèle d’incorporation par un meilleur modèle, à augmenter la dimension des vecteurs, ou à ajuster les paramètres top-k et la taille des chunks. Ces solutions sont raisonnables, mais elles ciblent le mauvais élément. Le problème réel est d’ordre architectural : un pipeline conventionnel demande à un seul mécanisme, la similarité des incorporations, d’effectuer deux tâches très différentes : trouver des candidats et déterminer quels candidats sont importants.
La solution consiste à diviser les tâches. On peut utiliser une recherche de motifs suivie d’un jugement : une approche en deux étapes où la génération des candidats et l’évaluation de la pertinence constituent des problèmes d’ingénierie distincts nécessitant des outils différents.
Pourquoi la similitude seule ne suffit pas
Le RAG naïf convertit la requête en un vecteur d’incorporation, extrait les K éléments les plus proches de la base de connaissances, les place à côté de la question et laisse le modèle répondre. L’hypothèse implicite est que la proximité équivaut à la pertinence, ce qui fait que la liste des K éléments les plus proches est acceptée sans aucune validation. Quatre problèmes surviennent ainsi.
Similaire ne signifie pas pertinent. La distance d’incorporation constitue un indicateur approximatif de la proximité thématique. Deux passages peuvent se trouver côte à côte sans que l’un réponde à la question posée par l’autre. Un texte sur les directives de traitement de l’hypertension et un autre sur la méthodologie des essais cliniques pour les médicaments cardiovasculaires peuvent être placés côte à côte, mais seul le premier est utile à celui qui doit décider comment traiter un patient.
Le classement est peu fiable. La distance vectorielle est une heuristique et non une fonction de classement conçue de manière à ce que la position reflète la pertinence. L’écart entre le troisième et le septième résultat dans un classement par cosinus est souvent dû au bruit.
Le contexte est fragmenté. Le découpage en blocs perturbe les relations, la hiérarchie ainsi que les liens de cause à effet. Un bloc concernant la dose peut se trouver séparé du bloc décrivant les contre-indications, et aucun des deux n’est complet à lui seul.
Les résultats sont instables. De légères modifications des formulations peuvent faire varier l’ensemble des K meilleurs résultats. Poser des questions sur les effets secondaires du metformine par rapport aux réactions indésirables peut donner des candidats différents, et la réponse finale peut changer en conséquence. Il s’agit d’un défaut de fiabilité et non d’un détail de réglage.
En bref, la recherche fournit des candidats, mais elle ne garantit pas la justesse des résultats.
La conception en deux étapes
Plutôt que d’avoir un seul système chargé de la recherche et de l’évaluation, on crée deux étapes, chacune ajustée en fonction de son propre objectif.
La première étape, la recherche, déploie intentionnellement un filet large. On sélectionne entre 50 et 200 candidats, bien plus que ce que l’on montrerait jamais au modèle, car l’objectif ici est le taux de rappel. Les documents pertinents doivent simplement se trouver quelque part dans cet ensemble, même s’il est bruyant.
La deuxième étape, juge, applique un critère bien plus strict. Il s’agit généralement d’un réclassificateur à codage croisé qui lit en même temps la requête et chaque candidat pour calculer un score de pertinence réel. Cela réduit la liste aux cinq à dix passages présentant un haut degré de fiabilité. Ce n’est qu’alors que le contexte ainsi constitué est transmis au modèle de langage.
Quel est réellement le rôle des embeddings
C’est une mauvaise compréhension du rôle des embeddings qui pousse les équipes à s’y fier excessivement. Imaginez un bibliothécaire qui ne lit pas chaque livre mais qui y ajoute des étiquettes correspondant à quelques thèmes clés. Lorsqu’une question arrive, le bibliothécaire la traduit en étiquettes similaires et sélectionne les livres dont les étiquettes correspondent le mieux. C’est rapide et permet généralement de trouver quelque chose d’utile, mais cela se base sur des thèmes superficiels plutôt que sur une compréhension profonde, si bien que certains livres sont pertinents sans pour autant correspondre exactement à ce dont on a besoin.
La conséquence : votre modèle d’embedding correspond à votre comportement de recherche. Il décide de ce qui est trouvé et de ce qui est manqué. Il ne décide pas de ce qui est correct, c’est là le rôle de l’étape de jugement.
Choisir un modèle d’embedding revient donc à prendre une décision liée au taux de rappel. Vous choisissez le prisme à travers lequel la première étape perçoit le corpus. Évaluez des critères de récupération tels que MTEB et BEIR, la couverture linguistique, la taille du modèle par rapport à votre matériel, la dimension vectorielle, la longueur maximale des entrées et la vitesse d’inférence. Tous ces éléments concernent le taux de rappel.
Options de jugement et situations d’application
Le juge est un rôle au sein de l’architecture. Plusieurs implémentations peuvent le remplir, avec des compromis différents en termes de précision, de latence, de complexité et de coût.
Fusion par rang réciproque
RRF ne prend absolument pas en compte la pertinence. Il fusionne les listes classées provenant de plusieurs sources, comme une recherche par mot-clé et une recherche sémantique, en une seule séquence d’ordre. Pour chaque document, il ajoute la valeur 1 / (k + rang) pour l’ensemble des listes, où k est une constante, généralement 60, qui atténue la domination des positions les plus élevées dans le classement. Les documents qui se classent bien dans plusieurs listes montent en position.
Cette méthode est rapide, déterministe, ne nécessite aucune inférence de modèle et ne provoque presque aucune latence. Comme elle utilise les positions dans le classement plutôt que des scores bruts, elle évite le décalage entre les scores BM25 et les similarités cosinus, ce qui rend toute normalisation inutile.
Sa limite réside dans le fait qu’il ne prend en compte que la concordance. Si plusieurs moteurs de recherche jugent un document important, RRF en déduit qu’il l’est probablement. Il s’agit d’une heuristique sensée, mais qui reste néanmoins une heuristique. Il ne peut pas retrouver un document pertinent que tous les moteurs ont manqué, ni distinguer un document thématiquement proche d’un autre qui répond à la question.
Utilisez-le pour des recherches hybrides lorsque vous avez besoin d’une méthode simple pour fusionner des listes. Il fait partie de l’étape de recherche afin d’améliorer les candidats, mais il ne remplace pas l’expert chargé de l’évaluation.
Encodateurs croisés
Un cross-encodeur passe la requête et un des candidats au modèle sous forme de séquence combinée et renvoie un score de pertinence. Les bi-encodeurs incorporent séparément la requête et le document, tandis qu’ici chaque token de la question peut interagir avec chaque token du texte. Le modèle peut donc analyser comment des phrases spécifiques dans la question se rapportent à des phrases spécifiques dans le texte. Des exemples typiques sont les modèles Sentence Transformers tels que cross-encoder/ms-marco-MiniLM-L-12-v2, les services de réclassement hébergés, ainsi que les cross-encodeurs affinés sur des données médicales, juridiques ou scientifiques.
Leur force réside dans leur précision. Sur les benchmarks de classement, ils battent généralement les autres approches, car ils captent des interactions fines que la similarité d’incorporation ne peut pas détecter. C’est ce qui se rapproche le plus de la question de savoir si un document répond réellement à la question, sans avoir à faire appel à un LLM complet.
Le coût correspond à un traitement séparé pour chaque paire de requête et de candidat. Un ensemble de 100 documents signifie 100 exécutions du modèle par requête, de sorte que la latence augmente linéairement avec la taille de l’ensemble, et les modèles plus gros aggravent encore la situation.
Ils constituent le juge par défaut là où la qualité de la réponse est primordiale : santé, droit, conformité, analyse financière, tout endroit où une récupération erronée a des conséquences. Si le budget de latence permet environ 50 à 200 millisecondes pour un réclassement, ce que la plupart des systèmes non en temps réel peuvent se permettre, commencez par eux.
ColBERT et interaction tardive
ColBERT, abréviation de contextualized late interaction over BERT, se situe entre les bi-encodeurs et les cross-encodeurs. Il encode indépendamment la requête et le document en vecteurs par token, puis évalue leur correspondance en comparant les tokens de la requête avec ceux du document. Comme les vecteurs de document peuvent être calculés à l’avance, son utilisation est beaucoup moins coûteuse au moment de la requête qu’avec un cross-encodeur, tout en conservant plus de détails qu’un vecteur agrégé unique. Le prix à payer est un index plus volumineux, car chaque token dispose de son propre vecteur. Il convient aux systèmes qui nécessitent une meilleure hiérarchisation que les embeddings simples, tout en offrant un débit supérieur à celui que peuvent fournir les cross-encodeurs.
Un LLM en tant que juge
Un modèle de langage général peut évaluer directement les candidats. Il gère une pertinence nuancée et à plusieurs étapes, comme le fait de comprendre qu’un document sur les interactions médicamenteuses est pertinent pour une question sur la sécurité du traitement, même si les vocabulaires ne coïncident pas. Il peut également suivre des critères de pertinence explicites indiqués dans la demande, ce qui le rend adaptable aux significations spécifiques à un domaine pour le terme « pertinent ».
C’est aussi de loin l’option la plus coûteuse. Une opération de réclassement peut prendre de une à cinq secondes et coûter dix à cent fois plus cher qu’un traitement par encodage croisé. Les scores peuvent varier d’une exécution à l’autre, et les modèles présentent un biais de position, en favorisant les documents mentionnés en premier dans la demande. Les modèles hébergés ajoutent une dépendance externe.
Cela est pertinent dans deux contextes : en mode hors ligne ou pour des tâches par lots où la latence est sans importance, comme la création de bases de connaissances soigneusement sélectionnées, l’évaluation des résultats de recherche pendant le développement ou la génération de données d’entraînement pour un réordonneur dédié ; ainsi que pour des outils à haute valeur ajoutée mais à faible volume, où la pertinence d’une réponse correcte justifie le coût par requête, comme les recherches médicales ou juridiques de niveau expert.
Choix des modèles pour chaque étape
Comprendre le schéma est une chose, choisir les modèles en est une autre. L’architecture vous impose deux décisions de sélection, chacune déterminée par la tâche à accomplir.
Commencez par la tâche
La réponse à des questions cliniques, l’exploration de documents et le respect des réglementations exigent des approches différentes. Le contrôle de qualité nécessite une grande précision même avec un petit ensemble de données. L’exploration privilégie l’ampleur et la diversité. Le respect des réglementations exige une récupération déterministe et auditable, avec un minimum de faux négatifs. Le profil de la tâche influence chaque choix ultérieur.
Le modèle d’embedding fixe la limite de votre taux de rappel
Il détermine ce que le système peut trouver avant que l’humain ne prenne une décision. Un document pertinent qui n’entre jamais dans l’ensemble de données ne peut être retrouvé par aucun autre algorithme de classement. Comparez les candidats sur ces critères :
- Étalons de performance. Examinez les résultats MTEB et BEIR pour le type de tâche le plus proche du vôtre, comme la récupération de passages ou la réponse à des questions, et non seulement la note globale.
- Langues et domaine. Les modèles multilingues sacrifient une partie de la précision des modèles monolingues au profit d’une plus grande portée, tandis que les modèles adaptés à un domaine font l’inverse. Vérifiez la couverture de votre terminologie.
- Taille et infrastructure. Les modèles plus gros offrent généralement de meilleures performances mais coûtent plus à grande échelle. Prenez en compte le volume d’indexation, le débit des requêtes ainsi que l’utilisation des GPU par rapport aux CPU. Un modèle 3 % plus performant sur un test nécessitant deux fois plus de ressources informatiques peut s’avérer un mauvais compromis.
- Dimension vectorielle. Plus de dimensions permettent de capturer davantage de nuances, mais augmentent les coûts de stockage et la latence. De nombreux modèles sont disponibles en plusieurs tailles ; testez donc si passer de 768 à 1536 dimensions justifie les surcoûts.
- Longueur maximale de l’entrée. Cela limite la façon dont le texte est divisé en fragments. Une limite de 512 tokens oblige à des fragments plus petits et entraîne une plus grande fragmentation, tandis que 2048 ou 8192 tokens permettent de conserver plus de contexte par fragment.
- Vitesse. Le temps de latence d’incorporation est important tant au moment de l’indexation que lors des requêtes. Des modèles distillés plus petits permettent d’obtenir un bon taux de rappel avec une latence bien plus faible lorsque les SLA sont stricts.
Le principe : ajuster le modèle d’incorporation en fonction de la couverture et de la vitesse, et non de la précision. La précision relève du rôle du juge.
Le reranker définit la correction finale
C’est le dernier filtre avant le LLM, donc sa qualité influence directement la précision des réponses. Évaluez-le selon :
- Précision du classement. C’est la principale métrique. Vérifiez le nDCG, le MRR et le MAP sur des benchmarks proches de votre domaine. De petites améliorations ici peuvent réduire de manière significative les hallucinations ultérieures.
- Latence. Le reranker s’exécute une fois par candidat, donc un ensemble de 100 candidats signifie 100 exécutions. Le temps par exécution et le temps total constituent des limites importantes en environnement de production.
- Alignement avec le domaine. Les outils de réclassification généraux performent bien pour une recherche large, mais les domaines à haute importance profitent souvent de ceux qui ont été affinés à l’aide de données relatives à la pertinence du domaine. Un outil de réclassification entraîné sur de la littérature médicale évaluera mieux les requêtes cliniques qu’un outil général, même si ce dernier obtient de meilleurs résultats sur des benchmarks génériques.
- Rendement. En cas de trafic important, l’outil de réclassification peut devenir un goulot d’étranglement. Envisagez le regroupement des tâches, le parallélisme des modèles, ainsi que l’utilisation d’une option plus légère, comme un encodage croisé simplifié ou un modèle d’interaction tardive, qui offre une précision acceptable avec un rendement bien plus élevé.
Investissez dans les deux
Les systèmes les plus performants ne choisissent pas entre un bon générateur d’encodages et un bon réordonneur, car ces deux composants s’occupent de tâches non superposées. Un générateur d’encodages performant associé à un réordonneur faible donne un taux de rappel élevé mais des résultats finaux peu fiables. Un générateur d’encodages faible associé à un réordonneur performant permet d’obtenir un classement précis à partir d’un ensemble incomplet de résultats. Aucun de ces deux éléments seul ne suffit.
La solution consiste en une recherche rapide offrant un bon taux de rappel, combinée à un jugement précis et solide. Adaptez le générateur d’encodages en fonction de vos besoins en termes de rappel, et le réordonneur en fonction de vos besoins en termes de précision ; ajustez ensuite la taille de l’ensemble de candidats entre les différentes étapes afin d’équilibrer la couverture des résultats et le temps de traitement du réordonnement.
Un exemple concret
Imaginons qu’un assistant clinique soit interrogé sur la possibilité pour un patient prenant un médicament spécifique contre le diabète de prendre en toute sécurité un deuxième médicament. L’étape de recherche effectue en parallèle une recherche par mots-clés et une recherche vectorielle, les fusionne à l’aide de RRF et retient 100 résultats potentiels. Parmi ceux-ci se trouvent la monographie de chaque médicament, un article sur la conception d’essais cliniques, un dépliant sur l’alimentation en général ainsi que plusieurs tableaux d’interactions. La similarité seule pourrait placer l’article sur les essais cliniques et le dépliant au-dessus des tableaux d’interactions, car leur vocabulaire est plus proche de la question posée.
La phase du juge lit la question associée à chacun des cent extraits et évalue si l’extrait aborde réellement l’usage combiné. Le tableau d’interaction ainsi que le paragraphe de contre-indication pertinent remontent en tête, la fiche correspondante est éliminée, et le modèle reçoit six extraits au lieu des dix bruyants initiaux. Même corpus, mêmes embeddings, résultat différent, car un deuxième composant a pris une décision pour laquelle le premier n’a jamais été conçu.
Ajustement du passage de phase en phase
La taille de la pool de candidats est un paramètre essentiel. Trop petite, et le juge ne voit jamais le passage correct, ce qui limite fortement le taux de rappel pour tout le système. Trop grande, et la latence ainsi que le coût de reclassement augmentent sans apporter de gain significatif. Une méthode pratique pour la déterminer consiste à enregistrer, sur un échantillon étiqueté, le rang auquel le passage correct apparaît lors de la première étape, puis à choisir une pool couvrant presque tous ces passages. Si le passage correct se situe régulièrement au-delà du rang 150, le problème réside probablement dans l’étape de recherche, avec un meilleur outil d’incorporation, une méthode de récupération hybride ou un découpage amélioré, et non dans un reclasseur plus puissant.
D’autres habitudes sont également utiles :
- Évaluer les deux étapes séparément. Mesurer le taux de rappel de la pool avant le jugement, ainsi que la précision de la liste finale après le jugement, afin de pouvoir identifier précisément l’étape en cause en cas de dégradation des résultats.
- Stocker en mémoire les scores des reclasseurs pour les requêtes fréquentes lorsque le corpus évolue lentement.
- Privilégiez un contexte final restreint. Utiliser cinq passages pertinents est généralement préférable à vingt passages de qualité variable, car le matériel supplémentaire concurrence pour l’attention.
- Revoyez la configuration lorsque le mélange de corpus ou de requêtes change, car un algorithme de rérankage ajusté pour un domaine donné peut se montrer moins efficace dans un autre.
Considérez cela comme une hypothèse à tester sur vos propres données et non comme une garantie, car les gains varient en fonction du domaine et de la faiblesse de la base de référence initiale.
Le point clé
Un RAG fiable ne s’obtient pas en trouvant une meilleure embedding. Il résulte de la séparation de la recherche et du jugement : une étape vise à maximiser la couverture, tandis que l’autre vise à maximiser la précision.
Le changement est d’abord conceptuel avant d’être technique. Cessez de considérer les résultats top-K comme une réponse définitive et traitez-les plutôt comme un ensemble de candidats. Cessez de considérer la similarité comme une vérité et traitez-la comme une hypothèse qui doit être vérifiée. Recherchez largement, puis jugez avec précision.
Lectures complémentaires
- RAG avancé sur Milvus : recherche hybride, HyDE, réécriture des requêtes et réclassement — Construire pas à pas un pipeline RAG avec Milvus : vecteurs denses et BM25, recherche hybride RRF, filtres de métadonnées, réécriture des requêtes, HyDE, décomposition et réclassement par cross-encoder.
- Notes pratiques : Les agents IA n’ont plus besoin de recherche vectorielle : à l’intérieur de l’architecture de recherche Agentic — Guide opérationnel des notes pratiques : Les agents IA n’ont plus besoin de recherche vectorielle : à l’intérieur de l’architecture de recherche Agentic. La pile de recherche qui remplacera le RAG en 2026 : contrats, vérifications et code adaptable.