Évaluation RAG : construire un jeu de tests représentatif sans fausser la décision

Un jeu de tests RAG représentatif ne cherche pas à confirmer que le système sait répondre à quelques questions bien choisies. Il doit reproduire les tâches, rôles, sources autorisées, sources exclues et situations d'incertitude du périmètre à ouvrir. La fiche de chaque cas doit permettre d'expliquer une régression, puis de décider si une version peut avancer, doit être limitée ou doit être corrigée.

En bref

• Construisez les cas à partir de tâches métier et de corpus réellement concernés, pas à partir des seules capacités du modèle.
• Décrivez aussi les refus attendus : utilisateur non autorisé, source retirée, document contradictoire ou absence de preuve exploitable.
• Figez la version du corpus, des droits et de la règle de revue avant de comparer deux versions. Sinon, l'écart observé n'est pas attribuable.

Cette méthode aide une équipe à préparer une décision d'évaluation. Elle ne fournit ni seuil universel, ni garantie de qualité, de sécurité ou de conformité. Les critères et les responsables doivent être définis pour le cas d'usage concerné.

Pourquoi un jeu de démonstration fausse-t-il la décision ?

Un jeu de démonstration contient souvent les questions les plus faciles, les documents les plus propres et un seul rôle utilisateur. Il peut montrer une capacité technique sans représenter la situation que l'équipe devra exploiter.

Dans ses travaux sur les collections de test, TREC décrit les trois éléments d'une infrastructure d'évaluation de recherche d'information : des documents, des sujets ou tâches, et des jugements de pertinence. Pour un RAG d'entreprise, ce principe doit être complété par les règles d'accès et le comportement attendu lorsqu'aucune preuve autorisée ne permet de répondre.

Le profil du NIST consacré à l'IA générative recommande d'adapter l'évaluation au contexte et aux risques du système. Il ne transforme pas une série de questions réussies en autorisation de déploiement. L'enjeu est de rendre visible ce que le système traite bien, ce qu'il refuse correctement et ce qui reste hors périmètre.

Que doit représenter un jeu de tests RAG ?

La représentativité n'est pas une question de volume isolé. Elle vient de la couverture des situations qui comptent pour la décision. Avant de rédiger les cas, définissez le périmètre : tâche, utilisateurs, corpus, droits, conséquence d'une réponse erronée et comportement attendu hors périmètre.

Une matrice de couverture rend cette préparation lisible :

Dimension	Question à couvrir	Éléments à conserver dans le cas
Tâche métier	Quelle décision, recherche ou action l'utilisateur doit-il accomplir ?	Demande réaliste, résultat utile et critère d'inutilité
Rôle et droits	Qui pose la question et quelles sources peut-il consulter ?	Rôle, attributs nécessaires, sources autorisées et interdites
Corpus	Quels documents représentent les cas réels ?	Identifiants, version, propriétaire, fraîcheur et exclusions
Difficulté	Quels cas révèlent une limite plutôt qu'une démonstration ?	Ambiguïté, contradiction, document obsolète ou absence de source
Réponse attendue	Que doit faire le système avec les preuves disponibles ?	Éléments attendus, citations, abstention ou escalade
Revue	Comment une personne qualifie-t-elle le résultat ?	Règle de notation, propriétaire de revue et motif d'écart

Le cadrage d'un projet RAG d'entreprise permet de réunir ce périmètre avant de choisir une métrique. Sans cette étape, un jeu de tests mesure surtout ce que l'équipe a eu la possibilité de collecter, pas ce qui décide de l'ouverture du système.

Comment écrire une fiche de cas exploitable ?

Une fiche doit pouvoir être relue sans reconstruire le contexte de mémoire. Utilisez un format identique pour tous les cas :

1. La tâche utilisateur. Écrivez la question comme elle est posée dans le travail, avec le contexte indispensable mais sans données superflues.
2. Le rôle de test. Indiquez l'identité ou le rôle simulé et les attributs qui gouvernent l'accès.
3. Le corpus de référence. Listez les documents ou passages qui peuvent étayer la réponse, avec leur version. Listez aussi les sources que le système ne doit pas exposer.
4. Le contrat de réponse. Précisez ce qui doit être présent, ce qui doit être cité et les situations où le système doit signaler une limite plutôt qu'inférer.
5. La règle de revue. Décrivez les motifs de réussite, d'échec et d'escalade. Une appréciation vague comme « réponse correcte » ne permet pas de comparer deux versions.
6. Les traces nécessaires. Conservez les éléments qui permettront d'analyser l'écart : version du système, récupération, filtres, contexte envoyé, réponse et décision de revue, selon les règles de données applicables.

Cette fiche distingue une réponse exacte mais obtenue avec une source non autorisée d'une réponse utile, fondée et accessible au rôle concerné. C'est aussi ce qui permet d'investiguer une régression après une mise à jour de corpus, de modèle, de prompt ou de récupération.

Pour transformer cette méthode en fiche exportable, utilisez notre constructeur de jeu de tests RAG. Il prépare un modèle de cas autorisé, refusé ou documentaire sans demander de donnée métier. Les sources, rôles, versions et critères réels restent à compléter dans le dossier de test de l'équipe.

Quels cas difficiles faut-il intégrer dès le départ ?

Les cas difficiles ne sont pas des exceptions à ajouter après le premier succès. Ils sont nécessaires pour éviter de conclure sur un système qui ne rencontre que son meilleur scénario. Le choix exact dépend du métier, mais la matrice doit inclure des situations comme celles-ci :

• une même question posée par deux rôles aux droits différents ;
• un document applicable mais ancien, remplacé ou contradictoire ;
• une question ambiguë qui exige une clarification ou une réponse limitée ;
• une demande dont la preuve est absente du corpus autorisé ;
• une source dont l'accès a été retiré ou dont la suppression doit être prise en compte ;
• un document indexé qui contient une instruction non pertinente pour la tâche ;
• une demande qui doit être refusée plutôt que reformulée à partir de données hors périmètre.

Ces scénarios ne demandent pas de présumer qu'une architecture est défaillante. Ils donnent une manière de vérifier le comportement attendu lorsqu'un élément de la chaîne sort du scénario idéal. Pour préparer les règles d'autorisation qui les soutiennent, consultez aussi notre guide sur les choix d'architecture de contrôle d'accès dans un RAG.

Comment éviter que le jeu de tests dérive avec le système ?

Un jeu de tests devient peu utile si le corpus, les droits ou le système changent sans que le cas ne le dise. Figez donc une ligne de base avant chaque comparaison : version de l'index ou du corpus, règles d'accès, configuration de récupération, modèle, prompt et date d'exécution.

La documentation Microsoft sur l'évaluation et le monitoring des applications RAG rappelle que les composants d'un système interagissent et qu'un changement dans les données peut affecter les chunks récupérés et la qualité globale. Cette dépendance rend la traçabilité plus utile qu'un score isolé : l'équipe doit pouvoir voir si la différence vient du corpus, de la récupération, de la génération ou d'une règle de contrôle.

Lorsqu'un cas n'est plus représentatif, ne le supprimez pas silencieusement. Marquez le motif : tâche abandonnée, source retirée, changement de politique d'accès ou évolution du périmètre. Conservez les cas qui ont révélé une erreur réelle comme cas de régression, sauf si leur contexte n'est plus légalement ou techniquement utilisable.

Comment relier le jeu de tests à une décision de version ?

Comparez une version candidate à une référence sur le même périmètre. Une revue de décision peut suivre cinq étapes :

1. Figez les cas, rôles, sources et règles de revue pour la comparaison.
2. Exécutez la référence et la version candidate en conservant les traces nécessaires.
3. Examinez séparément la récupération, la réponse, les refus, la latence et le coût.
4. Faites relire les écarts qui touchent une tâche critique, une donnée sensible ou un comportement attendu hors périmètre.
5. Consignez une décision : poursuivre, limiter le périmètre, corriger ou revenir à la référence, avec le motif et le responsable.

Notre guide pour évaluer un RAG en production détaille les dimensions à séparer pendant cette revue. Cette page se concentre sur la qualité du matériau de départ : si les cas ne représentent pas la décision, les métriques les plus rigoureuses restent difficiles à interpréter.

Quand le jeu de tests est-il suffisamment représentatif ?

Il n'existe pas de quantité universelle de cas qui rende un jeu de tests représentatif. La question de décision est plus concrète : les tâches prioritaires, les rôles distincts, les sources sensibles, les refus attendus et les situations qui peuvent bloquer l'ouverture sont-ils explicitement couverts ?

Un jeu de tests peut être incomplet tout en étant déjà utile, à condition que ses limites soient écrites. Cette transparence vaut mieux qu'une conclusion générale tirée d'une démonstration propre. Avant d'élargir le périmètre, préparez aussi la décision de déploiement avec les critères de go/no-go d'un système LLM.

FAQ

• Quelle est la différence entre un jeu de tests RAG et un benchmark public ?

  Un benchmark public peut aider à comprendre une méthode ou à comparer des approches dans son propre cadre. Un jeu de tests RAG d'entreprise doit surtout représenter les tâches, documents, droits et comportements attendus du périmètre réellement ouvert. Il ne peut pas être remplacé par un score obtenu sur un corpus externe.

• Faut-il utiliser des questions réelles dans un jeu de tests RAG ?

  Oui, lorsque les règles de données le permettent. Les tâches réelles ou relues par les personnes qui connaissent le métier réduisent le risque de tester des formulations artificielles. Elles doivent être traitées avec les règles de confidentialité et de conservation applicables.

• Comment tester un RAG lorsqu'aucune réponse ne doit être donnée ?

  Créez un cas où la source est absente, insuffisante ou non autorisée, puis décrivez la réponse de limitation, de refus ou d'escalade attendue. Vérifiez aussi que les traces permettent d'identifier la décision de contrôle sans exposer davantage de données.

• Faut-il modifier le jeu de tests après un changement de corpus ?

  Oui. Identifiez les cas affectés, conservez la version du corpus et indiquez le motif de la modification. Comparez le changement à une référence sur les cas toujours pertinents avant d'élargir le nouveau périmètre.

Méthodologie et sources

• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, juillet 2024, consulté le 17 septembre 2026. Le profil décrit une gestion des risques à adapter au contexte des systèmes d'IA générative.
• NIST, The 34th Text REtrieval Conference, mars 2026, consulté le 17 septembre 2026. La publication décrit l'infrastructure d'évaluation de la recherche d'information, notamment les collections de documents, tâches et jugements de pertinence.
• Microsoft Learn, Introduction to evaluation & monitoring RAG applications, consulté le 17 septembre 2026. La documentation présente les relations entre données, composants RAG, évaluation et monitoring.

La méthode proposée est une grille de conception pour l'évaluation de systèmes RAG d'entreprise. Elle ne contient ni résultat client, ni score, ni délai, ni promesse de sécurité, de conformité ou de performance. Les cas de test, les règles de conservation et les critères de décision doivent être validés par les fonctions métier, sécurité, données et exploitation concernées.

---

Vous devez comparer un RAG à une nouvelle version sans confondre démonstration et preuve de production ? Décrivez votre périmètre à IgnitionAI. Un premier échange peut aider à organiser les tâches, les cas de refus et les preuves nécessaires à une décision de mise en production.