Un système RAG peut citer des documents et pourtant donner une mauvaise réponse. Il peut retrouver la bonne page mais ignorer le passage décisif, répondre correctement avec une source périmée, ou produire une phrase convaincante qui dépasse ce que les documents permettent d’affirmer. L’évaluer exige donc plus qu’une démonstration réussie sur quelques questions faciles.
Ce guide propose une méthode pratique pour tester un système de génération augmentée par recherche. Il sépare la qualité de la récupération, la fidélité de la réponse et l’utilité pour la personne qui pose la question. Il s’adresse à une équipe qui possède déjà un prototype ou prépare son premier déploiement. Pour comprendre l’architecture de base, commencer par le guide du RAG.
Partir des tâches réellement attendues
Avant de choisir une métrique, décrivez les tâches que le système doit accomplir. Cherche-t-il une procédure interne, compare-t-il deux versions d’un règlement, résume-t-il un dossier, ou répond-il à des questions courtes sur un catalogue ? Une bonne réponse à une question factuelle simple n’établit pas qu’il sait gérer une comparaison, une contradiction ou une demande sans réponse disponible.
Définissez le public, le niveau de précision nécessaire et le coût des erreurs. Un assistant qui aide à retrouver un document peut tolérer une réponse partielle accompagnée d’une source claire. Un outil qui suggère une action opérationnelle peut exiger une vérification humaine et une abstention en cas d’incertitude. Ces différences déterminent les critères de réussite. « Réponse plausible » est trop vague pour guider un test ou une décision de publication.
Écrivez ensuite ce qu’une bonne réponse doit contenir : fait central, conditions, date de validité, source et éventuelle limite. Pour certaines questions, la bonne réponse est « le corpus ne permet pas de conclure ». Intégrer ce cas dès le départ évite de récompenser un système qui répond toujours, même lorsqu’il ne dispose pas d’information suffisante.
Dessiner la chaîne à évaluer
Un RAG courant transforme la question, cherche des passages, sélectionne un contexte, puis demande au modèle de générer une réponse. Chaque étape peut échouer. La requête reformulée peut perdre un nom important ; la recherche peut rater le document ; le classement peut le placer trop bas ; la fenêtre de contexte peut couper le passage ; enfin le modèle peut mal interpréter une phrase pourtant présente.
Conservez les traces nécessaires pour diagnostiquer ces étapes : question originale, éventuelle reformulation, identifiants et versions des documents récupérés, ordre des passages, réponse produite et références affichées. Sans ces éléments, une note faible ne dit pas quoi corriger. Une réponse erronée issue d’une recherche correcte demande un autre travail qu’une réponse erronée parce que le bon document n’a jamais été trouvé.
Documentez également les paramètres qui changent le comportement : modèle de représentation, méthode de découpage, nombre de passages, filtres, consignes et version du modèle génératif. Une comparaison entre deux versions du système n’est valable que si ces conditions sont connues. Le principe rejoint la reproductibilité des expériences : garder les entrées et les versions permet de comprendre un gain ou une régression.
Construire un jeu de questions représentatif
Un jeu de test utile ressemble aux demandes que les utilisateurs formuleront réellement. Collectez des questions autorisées issues du support, des recherches internes ou d’ateliers avec les équipes, puis retirez les données sensibles qui n’ont pas leur place dans le jeu. Ajoutez des formulations courtes, longues, ambiguës et contenant des termes métier. Une liste écrite uniquement par les développeurs risque de reprendre le vocabulaire exact des documents et de surestimer la recherche.
Répartissez les questions par type : réponse dans un seul passage, réponse nécessitant plusieurs sources, comparaison de versions, question sans réponse, document obsolète et question à accès restreint. Pour chaque type, indiquez sa fréquence ou son importance. Un petit jeu équilibré peut être utile pour le diagnostic, mais sa moyenne ne doit pas être présentée comme un taux de réussite représentatif de tous les usages si l’échantillon a été construit artificiellement.
Évitez de modifier le jeu de référence chaque fois qu’une nouvelle configuration échoue. Gardez un ensemble de développement pour ajuster le système et un ensemble de contrôle réservé à la comparaison finale. Ajoutez de nouveaux cas d’incident dans une suite de régression distincte. Cette discipline limite l’optimisation sur quelques questions connues et conserve une mesure crédible des progrès.
Rédiger des références vérifiables
Pour chaque question, notez les documents qui contiennent l’information, les passages précis et les éléments obligatoires de la réponse. Lorsque plusieurs réponses sont acceptables, décrivez les critères plutôt qu’une phrase unique à reproduire. Une réponse correcte peut employer d’autres mots sans perdre son sens. À l’inverse, une réponse qui reprend la phrase de référence mais ignore une condition importante doit pouvoir être considérée comme incomplète.
Datez les références. Dans un corpus vivant, la « vérité » peut changer après la création du jeu de test. Une ancienne procédure peut être correcte pour une question historique et fausse pour une question au présent. Associez donc au cas de test une date d’effet ou une version du corpus. Si le système doit citer la politique actuelle, la référence doit pointer vers le document en vigueur au moment du test.
Prévoyez une revue par une personne connaissant le domaine lorsque les questions portent sur des règles métier. Les annotateurs peuvent eux-mêmes se tromper ou interpréter différemment une exception. Une courte discussion sur les désaccords améliore le jeu d’évaluation et révèle parfois un problème dans la documentation source. Le test ne peut pas rendre un corpus ambigu plus clair qu’il ne l’est réellement.
Mesurer la récupération des documents
La première question est : le système retrouve-t-il les passages nécessaires ? Un rappel sur les premiers résultats mesure la part des questions pour lesquelles au moins un passage pertinent figure parmi les résultats examinés. Mais « présent quelque part dans les cinquante premiers » ne suffit pas si seuls cinq passages sont transmis au modèle. Mesurez au niveau où la sélection a effectivement lieu.
La précision de la récupération examine la proportion de passages utiles parmi ceux sélectionnés. Un contexte chargé de documents hors sujet peut augmenter le coût, diluer l’information et rendre une mauvaise réponse plus probable. Il faut toutefois accepter certains passages complémentaires : une définition et une exception peuvent être réparties dans deux documents. Les critères de pertinence doivent refléter le type de question, pas seulement une correspondance de mots.
Analysez l’ordre des résultats. Si la source correcte apparaît régulièrement en dixième position alors que le système n’en conserve que cinq, le problème vient du classement ou du seuil de sélection. Si elle n’apparaît jamais, examinez l’indexation, les filtres d’accès, les synonymes et le découpage. Une métrique globale de récupération doit toujours pouvoir être décomposée en cas concrets, avec le passage attendu et les passages réellement fournis.
Tester le découpage et les métadonnées
La taille des morceaux de texte influence ce que le moteur peut retrouver. Un passage trop court peut perdre la condition qui donne son sens à une règle ; un passage trop long peut contenir beaucoup de bruit. Testez plusieurs stratégies sur le même jeu de questions, en gardant constants les autres paramètres. Vérifiez notamment les tableaux, les titres et les listes : une découpe mécanique peut séparer une valeur de son intitulé.
Les métadonnées aident à filtrer les versions, les langues, les entités et les droits d’accès. Leur qualité doit être testée comme celle du contenu. Un document correctement indexé mais marqué avec une mauvaise date peut être exclu à tort ; une page obsolète non marquée peut être citée comme actuelle. Le guide sur la qualité des données dans les pipelines décrit les contrôles de schéma, de fraîcheur et de cohérence utiles ici.
Évaluez les changements de corpus avec une suite de questions connue. Après l’ajout de nouveaux documents, vérifiez que les anciennes réponses importantes restent accessibles et que les nouvelles informations priment quand elles sont plus récentes. Le résultat d’un RAG dépend du corpus autant que du modèle. Un changement documentaire doit donc être traité comme une modification du système, avec une revue et une possibilité de retour arrière.
Vérifier la fidélité de la réponse aux sources
Une réponse fidèle n’affirme pas davantage que ce que les passages transmis permettent de soutenir. Évaluez chaque affirmation importante séparément : est-elle appuyée, contredite ou absente des sources ? Cette méthode révèle les réponses qui mélangent une phrase correcte avec une conclusion inventée. Une note unique de « qualité de réponse » masquerait cette différence.
La fidélité n’est pas la même chose que la vérité. Si le corpus contient une erreur, une réponse peut lui être fidèle et néanmoins fausse. À l’inverse, le modèle peut donner une information vraie de mémoire sans qu’elle apparaisse dans les sources autorisées ; dans un RAG conçu pour répondre à partir d’un corpus, cette réponse est insuffisamment justifiée. Évaluez donc séparément le fondement documentaire et la justesse par rapport à une référence externe validée.
Les citations doivent être contrôlées, pas seulement comptées. Un lien vers le bon document peut renvoyer à une page qui ne soutient pas la phrase voisine. Vérifiez le passage cité, sa version et sa portée. Une citation crédible mais inexacte peut inspirer plus de confiance qu’une réponse sans source ; c’est précisément pourquoi elle mérite un test spécifique.
Mesurer l’utilité et l’abstention
Une réponse peut être fidèle et néanmoins inutile : trop générale, incomplète, mal structurée ou incapable de répondre à la demande concrète. Notez si elle traite la question, donne les conditions nécessaires et permet à l’utilisateur de poursuivre. Pour une question procédurale, la présence des étapes et des exceptions peut compter davantage qu’une formulation élégante.
Testez les cas où le système devrait s’abstenir. Si aucun document autorisé ne répond, une bonne sortie peut dire clairement que l’information manque et proposer où la chercher. Mesurez les réponses inventées sur ces cas, mais aussi les abstentions injustifiées lorsque la réponse existe. Augmenter l’abstention peut réduire certaines erreurs tout en rendant l’outil moins utile ; le bon équilibre dépend des conséquences métier.
La latence et le coût participent à l’utilité. Une configuration qui améliore légèrement la réponse mais multiplie le délai peut dégrader l’expérience. Mesurez ces éléments sur les mêmes types de questions et dans des conditions proches de l’usage réel. Le choix final doit expliciter le compromis, avec des critères fixés avant de comparer les variantes plutôt qu’après avoir vu les résultats.
Combiner jugement humain et mesures automatiques
Des métriques automatiques accélèrent les comparaisons, mais elles ne remplacent pas une lecture de cas difficiles. Des outils comme Ragas et sa liste de métriques proposent des mesures de précision du contexte et de fidélité. Leurs résultats dépendent de la définition des données, de la version de l’outil et parfois d’un modèle évaluateur. Interprétez-les comme des indices à confronter aux annotations humaines.
Créez une grille courte pour les évaluateurs : réponse correcte, complète, fondée, citation pertinente et abstention appropriée. Donnez des exemples de chaque niveau. Faites annoter un échantillon par deux personnes pour repérer les désaccords. Si elles ne s’accordent pas sur ce qu’est une bonne réponse, une métrique automatique ne résoudra pas la question ; il faut clarifier la tâche ou la documentation.
Quand un modèle juge un autre modèle, vérifiez ses propres erreurs. Il peut préférer une réponse longue, croire une citation qui semble plausible ou mal traiter une négation. Échantillonnez les notes extrêmes et les cas où la mesure automatique contredit les utilisateurs. Conservez les explications et les traces, afin qu’une équipe puisse corriger la méthode d’évaluation plutôt que d’optimiser aveuglément un score.
Tester sécurité, droits et questions adverses
La qualité d’un RAG inclut le respect des limites d’accès. Une recherche qui retrouve un document interdit pour l’utilisateur représente un défaut même si la réponse paraît exacte. Testez des identités et des droits différents, puis vérifiez les filtres avant la génération et dans les citations. Un document confidentiel ne doit pas devenir accessible parce qu’un extrait a été copié dans un index partagé.
Ajoutez des questions qui demandent explicitement d’ignorer les règles, de révéler des instructions internes ou de suivre un texte malveillant présent dans un document. Le risque de prompt injection dans les agents IA concerne aussi les systèmes qui récupèrent du contenu externe. Le contenu récupéré doit rester une donnée à examiner, non une autorité capable de changer les consignes du système.
Prévoyez les documents contradictoires et les sources périmées. Un bon système doit signaler l’incertitude ou privilégier la source en vigueur selon une règle documentée. Testez aussi les questions formulées de manière trompeuse : elles peuvent contenir une prémisse fausse. La réponse utile corrige cette prémisse lorsque les sources le permettent, au lieu de la reprendre pour produire une réponse fluide mais incorrecte.
Organiser les comparaisons et le suivi en production
Avant un changement, fixez une version de référence et une liste de critères : récupération, fidélité, utilité, abstention, latence et coût. Exécutez les deux configurations sur le même jeu, avec le même corpus lorsque l’objectif est d’isoler le modèle ou la recherche. Si le corpus change aussi, notez-le clairement. Une comparaison équitable doit permettre d’attribuer les écarts à une cause probable.
Après déploiement, collectez des retours structurés sur les réponses : question, documents consultés, type d’erreur, gravité et correction attendue. Protégez les données personnelles et limitez les accès aux journaux. Les taux de clic ou les pouces levés peuvent orienter l’enquête, mais ne prouvent pas qu’une réponse est vraie. Revoyez régulièrement un échantillon de conversations et enrichissez la suite de tests avec les incidents représentatifs.
La surveillance doit tenir compte du changement documentaire. Un nouvel index, une source absente ou un retard de synchronisation peut dégrader le système sans modifier le modèle génératif. Vérifiez la fraîcheur du corpus et les volumes indexés, puis reliez les alertes aux questions touchées. La méthode de surveillance de la dérive des modèles aide à structurer cette boucle : observer, enquêter, décider et vérifier l’effet du changement.
Questions fréquentes
Peut-on évaluer un RAG sans réponse de référence ?
Oui, partiellement. On peut examiner la pertinence des passages et la fidélité des affirmations aux sources. Pour juger la justesse complète et l’utilité sur une tâche précise, des critères validés par le domaine restent nécessaires. Un jeu sans référence claire convient surtout à l’exploration, pas à une affirmation forte de performance.
Combien de questions faut-il pour commencer ?
Il n’existe pas de nombre universel. Commencez avec assez de cas pour couvrir les tâches et les échecs importants, puis indiquez la taille et les limites de l’échantillon. La diversité et la qualité des annotations comptent davantage qu’une grande liste de questions presque identiques.
Une meilleure métrique automatique garantit-elle une meilleure expérience ?
Non. Elle indique une amélioration sur ce qu’elle mesure et sur le jeu utilisé. Vérifiez les cas individuels, les retours humains, la latence et les risques. Une modification qui augmente la fidélité tout en multipliant les abstentions peut être moins utile pour certains usages.
Évaluer un RAG revient à rendre ses échecs diagnostiquables. Un jeu de questions documenté, des références vérifiables, des mesures séparées et une revue humaine permettent de savoir si la prochaine amélioration concerne les documents, la recherche, la génération ou les règles d’usage. Ce travail donne aussi une base solide pour expliquer les limites du système aux personnes qui s’en servent.