Construisez un jeu de test RAG avec des questions réalistes, des réponses attendues, des cas sans réponse et des critères que votre équipe peut vérifier.
Pour savoir si un assistant documentaire progresse, il faut lui soumettre des questions comparables entre deux versions. Quelques démonstrations préparées par le développeur ne suffisent pas à représenter le travail du service. Le jeu de test doit conserver les difficultés que les utilisateurs rencontrent, y compris quand le document nécessaire manque.
Ce travail complète la mesure globale d’un pilote IA. Il porte sur la construction des cas : leur provenance, leur réponse de référence et leur séparation avec les exemples utilisés pendant les réglages.
Partir des questions et retrouver leurs documents
Demandez aux utilisateurs des exemples de recherches récentes. Conservez la formulation originale lorsque les données peuvent être utilisées dans ce cadre. Une question courte, une abréviation ou une erreur de vocabulaire révèle une difficulté que la reformulation par un expert peut faire disparaître.
Pour chaque demande, retrouvez les passages nécessaires à sa résolution. Notez aussi les informations que la personne connaissait déjà : son service, le type de dossier ou la date de l’opération. Si l’assistant ne reçoit pas ce contexte, le test doit attendre une question complémentaire.
Évitez de construire tous les cas en lisant un paragraphe puis en rédigeant la question qui lui correspond exactement. Cette méthode produit des exercices propres, mais elle représente mal une personne qui ignore le nom de la procédure recherchée.
Écrire une fiche par cas
Une fiche doit permettre à deux relecteurs de comprendre ce qui constitue une réponse acceptable. Il est rarement nécessaire d’exiger une phrase identique à la référence : les faits attendus et les conditions à respecter sont plus utiles.
| Champ | Contenu à conserver |
|---|---|
| Identifiant | Référence stable du test |
| Question | Formulation donnée à l’assistant |
| Contexte | Profil, date ou situation utiles |
| Documents attendus | Identifiants, versions et passages |
| Éléments obligatoires | Faits et conditions à mentionner |
| Erreur éliminatoire | Réponse qui ferait prendre une mauvaise décision |
| Comportement alternatif | Clarification ou absence de réponse attendue |
Exemple fictif : une procédure précise un délai habituel et une exception pour un équipement particulier. La fiche exige la mention de l’exception lorsque la question concerne cet équipement. Une réponse contenant seulement le délai général échoue, même si sa citation pointe vers le bon document.
Constituer des familles de difficulté
Répartissez les questions selon le travail demandé. Certaines trouvent leur réponse dans un passage unique ; d’autres nécessitent de rapprocher une règle et ses exceptions. Ajoutez les formulations imprécises qui imposent une clarification.
Incluez des cas où le corpus ne contient pas la réponse, ainsi que des documents périmés conservés pour tester leur exclusion. Les droits d’accès demandent également des scénarios distincts : une réponse disponible pour un groupe peut devoir être refusée à un autre.
Pour une équipe travaillant en français et en darija, vérifiez les questions réellement posées dans ces langues. Une simple traduction automatique d’une question française ne couvre pas tous les usages. Faites relire les attentes par une personne qui connaît le vocabulaire du service.
Réserver des cas que les réglages ne verront pas
Séparez un ensemble de développement et un ensemble de validation. Le premier aide à corriger le système. Le second sert à vérifier que les changements fonctionnent sur des demandes non utilisées pour guider chaque modification.
Gardez les variantes très proches dans le même ensemble. Si une question change seulement le nom d’un produit, la placer de l’autre côté ne crée pas forcément un test indépendant. Regroupez aussi les cas issus d’un même incident lorsque leur résolution repose sur la même correction.
Limitez l’accès aux réponses de validation pendant les réglages. Lorsqu’un cas sert directement à modifier le prompt ou la recherche, consignez ce changement de statut. Vous pourrez le conserver comme contrôle de non-régression et ajouter une nouvelle question indépendante.
Noter séparément recherche et réponse
Contrôlez d’abord si les passages nécessaires ont été retrouvés. Examinez ensuite si la réponse les utilise correctement. Cette séparation évite de modifier le prompt de rédaction quand l’information n’arrive jamais au modèle.
Une troisième vérification peut porter sur les références affichées : le lien est-il accessible et le passage cité soutient-il la phrase ? Une citation présente ne suffit pas à démontrer cette relation. Le guide d’audit des réponses avec sources détaille ce contrôle.
Anthropic distingue plusieurs modes d’évaluation, dont les vérifications par code, par modèle et par relecteur humain. Pour votre jeu de questions, utilisez les contrôles automatiques sur des conditions précises et faites examiner les cas ambigus par le service concerné. Un évaluateur automatique mérite lui aussi une vérification sur des exemples connus.
Maintenir le jeu sans réécrire son histoire
Lorsqu’une procédure change, mettez à jour les attentes concernées et conservez la version précédente du test. Une baisse de résultat peut venir d’une règle modifiée ; sans historique, elle ressemble à une dégradation inexpliquée.
Ajoutez les incidents de production après anonymisation ou remplacement des données sensibles. Conservez leur origine et leur motif d’ajout. Avant chaque publication, choisissez une version identifiée du corpus, du jeu de questions et de l’assistant pour pouvoir comparer les résultats.
Le livrable attendu pour votre assistant IA d’entreprise comprend alors les cas, leurs références et les règles de notation. Votre équipe pourra rejouer cette vérification quand le modèle, les documents ou les intégrations évolueront.