Évaluer un pipeline RAG

Pourquoi évaluer un RAG ne se résume pas à évaluer un LLM

Un pipeline 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 (Retrieval-Augmented Generation) combine deux systèmes dont les défaillances sont indépendantes. Le retriever peut ramener des passages hors sujet pendant que le générateur produit une réponse parfaitement rédigée — et fausse, parce qu'elle s'appuie sur du bruit. Inversement, le retriever peut ramener exactement le bon passage pendant que le générateur l'ignore et répond depuis sa mémoire paramétrique, avec le risque d'halluciner un détail que le 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 ne contenait pas.

Évaluer un RAG « à l'œil », en relisant quelques réponses, ne permet pas de distinguer ces deux causes d'échec. Un score global de satisfaction (« la réponse est bonne / mauvaise ») masque où se situe le problème et empêche de prioriser le correctif : faut-il retravailler 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, changer d'embeddingembeddingIARepré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, 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 du générateur, ou augmenter le nombre de passages récupérés ? Sans décomposition métrique, chaque itération devient un pari.

Un pipeline RAG s'évalue à deux étages distincts et complémentaires : la récupération (le retriever a-t-il trouvé la bonne information ?) et la génération (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 a-t-il utilisé correctement cette information ?). Mélanger les deux dans un score unique rend le diagnostic impossible.

Context Precision et Context Recall : évaluer le retriever

Ces deux métriques mesurent la qualité de la liste de passages renvoyée par le retriever, indépendamment de ce que le générateur en fera ensuite.

Context Precision répond à la question : parmi les passages récupérés, combien sont réellement pertinents pour répondre à la question ? Un retriever qui ramène 10 passages dont seuls 3 sont utiles a une 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 faible, même si la bonne information est présente — le générateur doit alors filtrer du bruit, ce qui augmente le risque de dilution ou de confusion.

Context Precision@k = (nombre de passages pertinents dans le top-k) / k

Une version pondérée par le rang existe aussi (Context Precision moyenne), qui pénalise davantage un passage pertinent classé en position 8 qu'un passage pertinent classé en position 1 — cohérent avec le fait que les 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 accordent souvent plus d'attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire aux premiers éléments d'un contexte long.

Context 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 répond à la question inverse : parmi tous les passages pertinents qui existent dans la base documentaire, combien le retriever en a-t-il effectivement remontés ? C'est la métrique qui révèle les angles morts du retriever — une information existe dans la base mais n'est jamais retrouvée, parce que le chunking l'a coupée en deux, parce que l'embedding ne capture pas la formulation, ou parce que k est trop petit.

Context Recall = (passages pertinents récupérés) / (total des passages pertinents existants)

Question : « Quelle est la durée de préavis pour résilier un contrat cadre ? » La base documentaire contient 2 passages pertinents (un dans les CGV, un dans l'avenant signé). Le retriever renvoie 5 passages au total, dont 1 seul est pertinent (celui des CGV) — l'avenant n'est jamais retrouvé. Context Precision@5 = 1/5 = 0,20 Context Recall = 1/2 = 0,50 Le diagnostic est clair : le retriever manque de rappel sur ce cas, probablement parce que l'avenant est mal indexé. Augmenter k seul ne suffira pas si le chunk n'est jamais dans le voisinage vectoriel de la question.

La mesure du recall exige de connaître à l'avance l'ensemble des passages pertinents pour chaque question — d'où la nécessité d'un jeu de donnéesdonné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 annoté, abordé plus loin.

Faithfulness : la réponse est-elle fondée sur le contexte ?

La faithfulness (fidélité) mesure si chaque affirmation de la réponse générée est effectivement soutenue par le contexte fourni au LLM — et non par sa mémoire paramétrique ou par une extrapolation. C'est la métrique la plus directement liée au risque 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 dans un RAG.

Le calcul typique se fait en deux temps, souvent via un LLM auxiliaire :

1. Décomposer la réponse générée en affirmations atomiques (claims) individuelles.
2. Pour chaque affirmation, vérifier si elle peut être déduite du contexte fourni, indépendamment.

Faithfulness = (nombre d'affirmations soutenues par le contexte) / (nombre total d'affirmations)

Une réponse peut être fluide, cohérente et grammaticalement irréprochable tout en ayant une faithfulness basse : c'est précisément le cas qui inquiète le plus en production, car rien dans la forme ne signale le problème à l'utilisateur.

Une réponse peut être parfaitement fidèle au contexte tout en étant fausse dans l'absolu — si le contexte récupéré contient lui-même une erreur ou une information obsolète, le générateur la reproduira fidèlement. La faithfulness mesure la fidélité à la source fournie, pas la vérité du monde. C'est pourquoi elle doit toujours être lue conjointement avec le context recall : un contexte incomplet ou erroné produit une réponse fidèle mais incorrecte.

Dans un RAG bien conçu, une faithfulness basse doit déclencher un audit du prompt système du générateur (instruction explicite de ne répondre qu'à partir du contexte, gestion du cas « information absente ») avant de suspecter le modèle lui-même.

Answer Relevancy et les métriques complémentaires

Answer Relevancy mesure si la réponse générée traite effectivement la question posée, sans digression ni réponse partielle. Une technique courante consiste à faire régénérer par un LLM plusieurs questions hypothétiques à partir de la réponse produite, puis à mesurer leur similarité (cosinus, embeddings) avec la question d'origine. Plus les questions reconstruites ressemblent à la question initiale, plus la réponse est jugée pertinente.

Cette métrique capture un mode d'échec distinct de la faithfulness : une réponse peut être entièrement fidèle au contexte fourni tout en étant hors sujet, par exemple si le retriever a ramené un passage voisin mais non pertinent et que le générateur en fait un résumé fidèle — fidèle, mais inutile.

D'autres métriques complètent souvent le tableau, en particulier pour l'étage retrieval, héritées de la recherche d'information classique :

Face à un utilisateur qui signale une mauvaise réponse, commencez par le context recall avant le faithfulness. Si l'information pertinente n'était pas dans le contexte, le problème vient du retriever — inutile de retravailler le prompt du générateur, qui ne peut pas répondre correctement avec un contexte incomplet.

Construire un golden dataset

Toutes ces métriques supposent une référence : un ensemble de questions accompagnées de la liste des passages pertinents attendus, et idéalement d'une réponse de référence. C'est le golden dataset, et sa qualité conditionne directement la fiabilité de l'évaluation — un golden set bâclé produit des métriques qui rassurent à tort.

Trois approches, combinables :

• Constitution manuelle par des experts métier : la plus fiable, la plus coûteuse. Réservée aux cas critiques (questions réglementaires, cas à fort enjeu).
• Extraction depuis les logs de production : les vraies questions posées par les utilisateurs, annotées a posteriori. Reflète l'usage réel mais demande un pipeline d'annotationannotationIAProcessus d'étiquetage manuel des données d'entraînement par des experts humains. La qualité de l'annotation conditionne directement les performances du modèle d'apprentissage supervisé.Voir dans le glossaire continu.
• Génération synthétique assistée par LLM : à partir d'un corpus documentaire, générer automatiquement des paires question/passage/réponse, puis faire relire un échantillon par un humain pour valider la méthode. Rapide à mettre en place, mais risque de produire des questions artificiellement faciles si le LLM générateur des questions reformule trop fidèlement le passage source.

Un golden dataset utile pour un RAG en production couvre au minimum : des questions factuelles simples, des questions nécessitant l'agrégation de plusieurs passages, des questions dont la réponse n'existe pas dans la base (pour vérifier que le système sait dire « je ne sais pas » plutôt que d'halluciner), et des questions ambiguës ou mal formulées représentatives du langage réel des utilisateurs.

Il n'est pas nécessaire de viser des centaines de questions pour démarrer. Un socle de 50 à 100 questions bien réparties sur les cas d'usage réels suffit à détecter des régressions significatives et à comparer deux configurations du pipeline. La taille peut croître progressivement avec les retours de production.

LLM-as-judge : l'outil pratique et ses pièges

Calculer faithfulness et answer relevancy à la main, question par question, n'est pas praticable à l'échelle d'un golden set de plusieurs dizaines d'entrées. La pratique courante consiste à déléguer ce jugement à un LLM — l'approche dite du LLM-as-judgeLLM-as-judgeIAÉvaluation automatisée où un LLM note ou compare des sorties selon des critères définis, souvent en complément de métriques classiques.Voir dans le glossaire, mise en œuvre par des frameworks comme RAGAS, TruLens ou DeepEval.

Ces outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire automatisent le calcul des métriques présentées plus haut en orchestrant des appels structurés à un modèle « juge » : décomposition en affirmations atomiques, vérification de chacune contre le contexte, agrégation en un score. Le gain en vitesse est réel, mais le LLM-as-judge introduit ses propres biaisbiaisIARégularité correctement apprise dans des données qui ne représentent pas la réalité visée, ou qui enregistrent des décisions passées avec leurs préjugés. Changer d'algorithme ne le corrige pas.Voir dans le glossaire qu'il faut connaître pour ne pas leur faire une confiance aveugle.

• Biais de longueur : certains juges accordent un score plus favorable aux réponses plus longues et détaillées, indépendamment de leur exactitude.
• Biais de position : dans les comparaisons de deux réponses, l'ordre de présentation influence parfois le verdict.
• Auto-préférence : un modèle juge tend à mieux noter les réponses produites par un modèle de la même famille que lui.
• Instabilité : deux appels au même juge sur la même paire question/réponse peuvent donner des scores légèrement différents, ce qui impose de fixer une température basse et d'agréger sur plusieurs échantillons pour les cas limites.

Ne jamais valider une mise en production sur la seule foi d'un score LLM-as-judge agrégé. Sur un échantillon d'une vingtaine de cas, comparez systématiquement le verdict automatique à une relecture humaine avant de faire confiance au score sur l'ensemble du golden set. Un écart significatif signale un prompt de jugement mal calibré, pas nécessairement un problème dans le pipeline évalué.

En pratique, un juge distinct du modèle de production (idéalement plus capable, ou d'une famille différente) et un prompt de jugement qui impose une justification explicite avant le score réduisent sensiblement ces biais.

Mettre en place une évaluation continue

Une évaluation ponctuelle, réalisée avant la mise en production initiale, ne protège pas contre les régressions ultérieures : changement de modèle d'embedding, mise à jour du LLM générateur, modification du prompt système, ajout de nouveaux documents dans la base. Chacun de ces changements peut faire chuter silencieusement une métrique.

Le schéma qui fonctionne en production ressemble à un pipeline de tests automatisés classique :

1. Le golden dataset est versionné avec le code du pipeline.
2. À chaque modification substantielle (prompt, modèle, stratégie de chunking, paramètre de k), le pipeline complet est rejoué sur le golden set.
3. Les quatre métriques centrales sont calculées et comparées à la version précédente — un seuil de tolérance (par exemple -3 points sur le faithfulness) déclenche une alerte avant tout déploiement.
4. Les résultats sont historisés pour visualiser la tendance dans le temps, pas seulement l'instantané.
5. Un échantillon des cas en régression est relufonction d'activationIAOpération non linéaire appliquée en sortie d'un neurone. Sans elle, empiler des couches serait inutile : une succession d'opérations linéaires reste équivalente à une seule.Voir dans le glossaire manuellement avant d'accepter ou de rejeter le changement.

Cette non-régression continue transforme l'évaluation d'un exercice ponctuel et anxiogène en un filet de sécurité intégré au cycle de développement, au même titre qu'une suite de tests unitaires.

Checklist avant mise en production

• Le golden dataset couvre les questions factuelles, les questions d'agrégation, les cas hors périmètre et les formulations réalistes des utilisateurs.
• Context Precision et Context Recall sont mesurés séparément de Faithfulness et Answer Relevancy — un score global ne suffit pas au diagnostic.
• Le seuil acceptable de chaque métrique est défini explicitement, avec l'accord des parties prenantes métier, avant de comparer des configurations.
• Le LLM-as-judge utilisé a été validé sur un échantillon relu par des humains, avec un écart mesuré et documenté.
• Un pipeline de non-régression rejoue automatiquement le golden set à chaque changement significatif du système.
• Les cas où le système doit répondre « je ne sais pas » sont explicitement testés, pas seulement les cas où une réponse existe.
• Les résultats d'évaluation sont historisés, pas seulement consultés au moment du déploiement.

Cette discipline d'évaluation ne remplace pas le jugement humain — elle le rend possible à l'échelle, en concentrant l'attention humaine sur les cas où les métriques automatisées divergent ou se dégradent, plutôt que sur une relecture exhaustive impraticable en continu.