Votre assistant documentaire change de moteur de recherche. Son score progresse, mais une question reste mal traitée : la réponse cite une procédure qui concerne l’ancienne version du produit. En relisant le jeu de test, vous découvrez que cette procédure était justement marquée comme pertinente.
Une évaluation RAG dépend de la qualité des questions, des preuves attendues et des règles d’annotation. Si la référence se trompe de version, transforme un passage non relu en document inutile ou mélange les exemples de réglage et de test, le score peut récompenser le mauvais comportement.
Le RAG associe recherche documentaire et génération de réponse. Ce guide prépare les données nécessaires pour juger ces deux étapes. Il complète notre atelier de comparaison des rerankers : avant de comparer leur classement, il faut décider ce qui constitue une bonne preuve.
La méthode ci-dessous s’accompagne d’un jeu d’annotation fictif et d’un validateur Python, exécutés localement pour cet article. Aucun modèle RAG ni annotateur humain n’a été benchmarké. Documentation vérifiée le 13 octobre 2026.
Que faut-il annoter pour évaluer un RAG ?
Un fichier contenant une question et une réponse idéale convient à certains contrôles, mais ne suffit pas pour expliquer une erreur de recherche. Ajoutez les passages qui justifient la réponse, leur version et le comportement attendu lorsque l’information manque.
La documentation LangSmith distingue notamment la justesse par rapport à une réponse de référence, la fidélité aux documents transmis et la pertinence des documents pour la question. Ces contrôles répondent à des questions différentes. Une réponse peut reprendre fidèlement une procédure périmée tout en étant incorrecte pour l’utilisateur. Tutoriel officiel d’évaluation RAG.
Pour votre premier jeu, conservez trois niveaux :
| Niveau |
Information à conserver |
Décision rendue possible |
| Question |
Formulation, intention, rôle utilisateur, périmètre et version du corpus |
Déterminer si une réponse est possible dans ce contexte |
| Paire question-passage |
Identifiant stable, extrait exact, pertinence et avis des annotateurs |
Vérifier les documents retrouvés par le moteur |
| Réponse attendue |
Faits indispensables, preuves et comportement attendu |
Juger la réponse finale sans imposer une formulation unique |
Dans l’atelier, reference_facts contient les faits indispensables. evidence_sets contient des ensembles de passages acceptables : tous les passages d’un ensemble doivent être disponibles pour constituer cette preuve ; plusieurs ensembles peuvent représenter des alternatives. Le petit exemple utilise des preuves à un passage. Pour une procédure répartie entre une règle et son exception, vous devrez annoter les deux.
Cette représentation est une proposition de travail, pas un standard universel. Adaptez-la au besoin : recherche d’un document, réponse synthétique ou exécution d’une procédure ne se jugent pas exactement de la même façon.
Ne pas confondre absence de réponse et échec de recherche
Prenons Orion, un produit entièrement inventé pour l’exercice. Sa documentation décrit les exports CSV et Parquet, une limite de lignes et la durée des liens de téléchargement. Elle ne donne aucun tarif.
Trois questions conduisent à trois annotations distinctes :
- « Quel est le tarif annuel ? » : information absente du corpus autorisé. Le comportement attendu est de reconnaître cette limite et d’orienter vers le bon interlocuteur.
- « Combien de temps le lien reste-t-il valide en version 2 ? » : réponse présente dans la documentation. Si le moteur ne retrouve pas ce passage, l’échec appartient à la recherche.
- « Puis-je exporter en Parquet ? » : la réponse dépend de la version du produit. Notre consigne demande une précision avant de répondre.
Marquez la possibilité de répondre par rapport à un corpus daté et accessible à un rôle donné, pas à toute la connaissance disponible sur Internet. Une information réservée à un autre service ne devient pas une preuve utilisable pour cet utilisateur.
En dehors d’un corpus minuscule relu intégralement, prouver qu’une réponse est absente demande du travail. Documentez les recherches et les sources examinées ; si la revue reste incomplète, gardez un statut « à vérifier » dans votre processus. Ne forcez pas prématurément un choix binaire. Notre validateur vise un export déjà arbitré et refuse les statuts qu’il ne connaît pas.
Définir la pertinence au niveau du passage
Un passage qui mentionne Parquet n’explique pas forcément comment exporter un fichier. Un document complet peut contenir la réponse alors que le fragment envoyé au modèle l’a perdue. Annotez donc l’unité réellement évaluée, avec un lien vers le document original et sa version.
Nous proposons cette échelle pour l’atelier :
- 0 : le passage ne contribue pas à répondre dans le périmètre demandé.
- 1 : il apporte du contexte ou une partie de la réponse, sans suffire seul.
- 2 : il fournit une preuve directement exploitable.
- Non jugé : personne n’a encore rendu de décision exploitable sur cette paire.
La note 2 ne signifie pas nécessairement que le passage répond à toutes les parties d’une question complexe. Les ensembles de preuves précisent les compléments nécessaires. Conservez aussi les exceptions, dates d’effet, unités et conditions qui changent le sens d’une consigne.
Dans Orion, « seul le CSV est disponible en version 1 » reçoit 0 pour une question explicitement consacrée à la version 2. Le glossaire de Parquet reçoit également 0 pour une demande de procédure : partager le vocabulaire ne suffit pas. En revanche, la fiche de contact commercial peut aider à orienter une question de tarif sans fournir le prix demandé.
Une paire non annotée reste inconnue. Dans votre table de travail, utilisez une valeur distincte, comme null, plutôt qu’un zéro par défaut. Vous pourrez ensuite choisir la convention d’un outil de mesure, mais elle devra être explicite dans le rapport. Microsoft documente par exemple une métrique Holes qui compte les documents retrouvés sans jugement associé. Évaluateurs RAG de Microsoft.
Le NIST décrit les qrels comme les jugements de pertinence associés aux questions et le pooling comme la sélection des premiers résultats de plusieurs exécutions pour constituer le lot à juger. Guide TREC. Pour un pilote métier, vous pouvez combiner plusieurs méthodes de recherche et ajouter les sources connues des experts. Ce lot reste une sélection, pas une preuve d’exhaustivité.
Échantillonner des besoins, pas seulement des questions faciles
Partez des formulations réellement rencontrées, lorsque leur utilisation est autorisée : demandes de support, recherches internes et tâches métier. Retirez les données personnelles inutiles et conservez le contexte qui change la réponse. Une question courte sans version ou sans date peut devenir artificiellement ambiguë après nettoyage.
Séparez un lot représentatif du flux habituel et un lot de difficulté ciblée : documents contradictoires, procédures réparties, acronymes, anciennes versions, information absente. Rapportez leurs résultats séparément. Une moyenne sur un ensemble enrichi en incidents ne décrit pas automatiquement l’usage quotidien.
Les questions synthétiques peuvent compléter cette collecte. Ragas documente une génération à partir des documents, incluant questions portant sur une source ou plusieurs sources et variation des scénarios. Génération de jeux RAG. Relisez ces propositions : une question fabriquée depuis un passage peut en reprendre les mots, oublier les demandes sans réponse et simplifier excessivement la recherche.
Gardez l’origine de chaque question et mesurez séparément les cas réels et synthétiques. N’ajoutez pas cent reformulations d’un même besoin pour donner l’apparence d’un corpus diversifié. Les six questions de notre exercice servent à comprendre le format, pas à estimer une performance de production.
Arbitrer les désaccords avant de regarder les scores
Faites annoter indépendamment un premier lot par deux personnes qui connaissent le domaine, avec la même consigne. Évitez de leur montrer le nom du système, sa réponse ou la note de l’autre personne avant leur décision.
Conservez les deux avis originaux, puis un champ distinct pour la décision finale, son auteur et sa raison. Un désaccord 0 contre 2 ne se résout pas en prenant mécaniquement la moyenne : il peut révéler une version oubliée, une question ambiguë ou une mauvaise définition de « pertinent ».
Dans le jeu fictif, deux paires sur dix doublement annotées sont en désaccord. Le taux d’accord brut est donc de 80 % avant arbitrage. Ce chiffre décrit uniquement les avis inventés du fichier, pas la qualité d’une équipe. L’accord ne prouve d’ailleurs pas la justesse : deux personnes peuvent appliquer la même consigne erronée.
Relisez les raisons par catégorie. Si une règle change, repérez les annotations concernées, réexaminez-les et créez une nouvelle version. Ne modifiez pas les réponses attendues pour faire gagner le dernier modèle testé. Un juge LLM peut aider à trier les cas à revoir ; il doit lui-même être confronté à une référence contrôlée avant de décider seul. La résolution motivée des désaccords et la révision des consignes font aussi l’objet du protocole d’Oortwijn et collègues, publié en 2021.
Séparer le réglage et le test par groupes
Deux reformulations du même ticket placées dans des lots différents ne constituent pas deux besoins indépendants. Regroupez les variantes proches avant la séparation. Selon ce que vous voulez mesurer, le groupe peut être un incident, une famille de procédures ou un ensemble de versions liées.
La validation par groupes de scikit-learn garde chaque groupe d’un seul côté d’une séparation. Documentation des groupes. Nous appliquons ce principe aux questions du RAG : le lot dev sert à améliorer les consignes et les paramètres, le lot test à confirmer la décision une fois les choix figés.
Le corpus documentaire peut rester commun si vous évaluez de nouvelles questions sur une base connue. Si vous voulez mesurer l’adaptation à de nouvelles familles documentaires, il faudra aussi séparer ces familles. Le choix dépend de la généralisation revendiquée.
Réservez les réponses de référence et leurs annotations à l’évaluateur. Les documents sources, eux, alimentent normalement la recherche. Archivez les versions du corpus, du découpage, des consignes, de la référence et de la configuration évaluée.
Tutoriel : contrôler un export d’annotation localement
1. Télécharger les ressources
Python 3.10 ou supérieur suffit. Aucun compte, appel réseau ou paquet externe n’est nécessaire. Placez dans le même dossier :
Le fichier contient des avis et arbitrages simulés, tous signalés comme fictifs. Il ne contient aucune donnée client.
2. Exécuter le contrôle
python3 valider_annotations.py --self-test
python3 valider_annotations.py jeu-annotation.json > rapport.json
Le premier appel vérifie le cas nominal et huit erreurs injectées : groupe partagé entre lots, texte modifié, arbitrage absent, preuve non jugée, question dupliquée, version incohérente, note invalide et avis manquant. Ces contrôles ont été exécutés pour l’article.
Le second produit notamment valid: true, cinq groupes, trois questions dans chaque lot, deux désaccords avant arbitrage et une paire explicitement non jugée. Les vingt-cinq paires non déclarées restent elles aussi non jugées. Elles ne sont pas transformées en notes de pertinence nulles au sens de « zéro ».
3. Vérifier une erreur volontaire
Copiez le JSON sous un autre nom. Changez le split de q1b en test, sans changer celui de q1. Relancez le validateur sur cette copie : il doit refuser le groupe format-v2, désormais présent dans les deux lots, avec un code de sortie 1.
Restaurez ensuite la copie. Essayez de vider la raison d’arbitrage de la première paire : le contrôle doit également échouer. Vous vérifiez ainsi que l’export ne perd pas une décision de revue importante.
4. Adapter le format sans surestimer le contrôle
Remplacez les exemples par vos questions autorisées, attribuez les groupes et annotez les preuves. L’empreinte SHA-256 porte sur le texte exact du passage en UTF-8 ; toute modification du texte impose de recalculer cette empreinte et de revoir ses annotations. Une empreinte correcte garantit seulement la cohérence des octets enregistrés.
Le script ne comprend pas les procédures, ne découvre pas les doublons sémantiques et ne prouve pas que les passages répondent à la question. Il vérifie les liens et les champs nécessaires, pas la vérité de l’annotation. Les pièces de référence doivent encore être relues. Supprimez les copies d’exercice devenues inutiles après avoir archivé le rapport retenu.
Décider ce qui mérite d’être évalué ensuite
Avant de comparer des modèles, vérifiez que chaque question a un périmètre, un comportement attendu et des preuves contrôlées, ou une absence de réponse documentée. Traitez les désaccords non résolus et inspectez la couverture des jugements parmi les résultats des systèmes comparés.
Si un nouveau moteur ramène beaucoup de passages jamais annotés, complétez cette revue avant d’interpréter une baisse de score. Si le corpus change, revalidez les réponses concernées. Si la recherche trouve les bonnes preuves mais que la réponse finale reste fausse, évaluez aussi la génération.
L’effort principal est le temps métier consacré à ces décisions : collecte, annotation, arbitrage et maintenance. Mesurez-le sur un premier lot, avec le taux de désaccord et les cas encore indécidables. Aucun abonnement n’est nécessaire pour l’atelier ; un outil de gestion peut devenir utile lorsque le volume et le nombre de relecteurs augmentent.
Le livrable à obtenir avant un comparatif est simple : des questions distinctes, des preuves versionnées et des décisions que l’équipe sait expliquer. Le score du RAG aura alors une référence qu’il est possible de discuter et de corriger.
