Construire un jeu d’évaluation par scénarios pour un système d’IA métier

Un bon jeu d’évaluation ne commence pas par une collection de prompts élégants, mais par un morceau de travail précisément délimité. Imaginez un assistant interne qui reçoit une demande d’achat plausible, un identifiant fournisseur contradictoire, une politique momentanément inaccessible et un devis contenant des instructions adressées à l’IA. Une moyenne flatteuse obtenue sur des demandes simples ne montre pas si le système détecte cette combinaison, s’abstient lorsqu’une preuve manque ou respecte l’étape d’approbation humaine. Il faut des cas reproductibles, des critères fixés avant les résultats et des verrous séparés pour les comportements interdits.

Que doit couvrir un jeu d’évaluation fondé sur des scénarios ?

Il doit couvrir le travail attendu en proportion des conditions observées, tout en réservant une place explicite aux limites importantes, aux défaillances confirmées et aux comportements interdits. Commencez par une version du système, un processus borné, ses acteurs autorisés, ses entrées, ses connaissances, ses outils et la décision que l’évaluation doit éclairer. Les dossiers de travail autorisés, tickets d’assistance, entretiens utilisateurs, incidents et parcours commentés par des spécialistes métier peuvent alimenter la carte. Lorsque les traces sont incomplètes ou que le service n’est pas encore lancé, signalez l’incertitude au lieu d’inventer une précision.

Pour l’assistant de demandes d’achat, cette carte peut réunir un dossier complet, une pièce manquante, des montants ou identifiants divergents, une politique indisponible, une tentative de contourner l’approbation et des instructions cachées dans un devis. Ces règles restent illustratives et propres à l’organisation. Définissez avant toute sortie les segments à publier, les comportements qui bloquent une mise en production et la décision visée. La fréquence du trafic guide le travail ordinaire; elle ne doit pas éliminer un cas rare mais lourd de conséquences.

Comment consigner chaque scénario de façon reproductible ?

Chaque scénario doit devenir un dossier qu’une autre personne peut recréer sans deviner le contexte ou la réponse attendue. Une tâche valable définit ses entrées et ses critères de réussite; selon le cas, le contrôle examine l’état final, la sortie produite ou la trace d’exécution. Le dossier doit aussi séparer les résultats acceptables des actes interdits. Cette distinction évite qu’une réponse bien rédigée masque une divulgation, un appel d’outil non autorisé ou une modification d’état que le système n’avait pas le droit d’effectuer.

• Identité et gouvernance : identifiant stable, propriétaire, statut, historique, famille de couverture, famille de tâche, segments, conséquence, provenance, autorisation et répartition prévue.
• Configuration : rôle et objectif de l’acteur, état initial, demande, fichiers, historique utile, connaissances autorisées, outils, permissions, résultats d’outil, conditions d’environnement et instructions système.
• Attentes : faits ou changements requis, variantes acceptables, conditions de clarification, d’abstention, de refus ou d’escalade, puis sorties, divulgations, appels d’outil et changements d’état interdits.
• Exploitation : type de contrôle, grille et verrous, éventuelle solution de référence, nombre d’essais et règle d’agrégation préalables, qualification des évaluateurs, arbitrage et versions du modèle, du prompt, du corpus, des outils, de la politique et du banc de test.

Une solution de référence qui fonctionne peut prouver qu’un cas borné est réalisable et révéler un contrôle défectueux. Elle ne doit toutefois pas devenir l’unique formulation admise si plusieurs parcours atteignent valablement le même résultat. Pour un système non déterministe ou à plusieurs étapes, fixez avant l’inspection le nombre d’essais nécessaire au cas et la manière de les agréger. Conservez aussi les désaccords non résolus et les limites connues : ils indiquent si le problème vient du système, du scénario ou d’une décision métier encore absente.

Un cas utile ne pose pas seulement une question difficile : il recrée un travail borné et rend inspectables la réussite, les variantes acceptables et les interdits.

Comment noter un scénario sans récompenser le mauvais comportement ?

Il faut employer la méthode de notation la plus étroite qui distingue valablement la réussite de l’échec. Un contrôle précis peut néanmoins être incomplet, récompenser un raccourci ou rejeter une alternative correcte; vérifiez donc que le cas est réalisable et que le contrôle mesure bien le résultat matériel. Les évaluateurs déterministes, les modèles de notation et les personnes ont des forces différentes. Pour une qualité ouverte, un modèle évaluateur nécessite des dimensions observables et un étalonnage contre des jugements humains qualifiés dans le contexte pertinent.

• Contrôle déterministe pour un calcul, un schéma, un argument d’outil, un état de dossier ou une action interdite objectivement vérifiables.
• Faits ou solution de référence lorsque les preuves et l’état final sont bornés, mais que plusieurs formulations ou parcours restent acceptables.
• Grille par dimensions avec repères observables pour l’utilité, l’exhaustivité, l’ancrage dans les sources ou une autre qualité réellement ouverte.
• Jugement humain qualifié lorsque l’interprétation métier ou les conséquences ne peuvent pas être résolues valablement par un contrôle automatisé; les décisions réglementées restent aux rôles autorisés.

Le crédit partiel est utile lorsque des composantes distinctes représentent une progression réelle, à condition de montrer laquelle a échoué. Il ne doit jamais compenser une divulgation ou une action interdite : ce comportement constitue un verrou séparé, défini à l’avance par les responsables produit et risque. Dans GDPval, OpenAI indique que son évaluateur automatisé n’était pas assez fiable pour remplacer les spécialistes expérimentés. Figez également la version de la grille, les segments, les verrous, l’agrégation des essais et la règle de décision avant de comparer les systèmes.

Comment aider les évaluateurs à appliquer les critères de manière cohérente ?

Donnez aux évaluateurs un guide bref qui expose le but du processus, le rôle de l’utilisateur, les preuves disponibles, les comportements permis, les limites du produit et la version de la grille. Chaque niveau doit correspondre à des signes observables plutôt qu’à des adjectifs vagues. Ajoutez des exemples positifs, négatifs et frontaliers, ainsi qu’une option « preuves insuffisantes » ou « impossible à noter » lorsqu’un scénario est défectueux. Le contexte, les solutions prévues et les exemples concrets peuvent améliorer la fiabilité de l’examen.

1. Faire traiter des cas d’étalonnage avant l’évaluation réelle et recommencer lorsque la politique, la grille, le mélange des tâches ou le groupe d’évaluateurs change.
2. Masquer si possible l’identité du système et varier l’ordre des sorties lors d’une comparaison, afin que le jugement porte sur les éléments fournis.
3. Recueillir les notes et leurs motifs séparément avant toute discussion collective.
4. Examiner les désaccords comme des données : ils peuvent signaler un cas ambigu, un seuil flou, un contexte manquant, plusieurs réponses légitimes ou une décision produit non tranchée.
5. Désigner un responsable de l’arbitrage et conserver les étiquettes, justifications, versions de grille et décisions finales pour les examens futurs.

Ne forcez pas un consensus lorsqu’une pluralité de réponses est légitime ou que le produit n’a pas encore défini la règle. Corrigez le cas si les informations manquent; révisez la grille si les repères se contredisent; sollicitez le propriétaire de la décision si le désaccord est normatif. L’examen des sorties, des traces et des notes aide aussi à distinguer une faiblesse du système d’un outil indisponible, d’un état initial impossible ou d’un contrôle mal construit.

Comment préserver l’utilité du jeu pendant le développement et la mise en production ?

Séparez les cas visibles utilisés pour l’itération d’un test de mise en production protégé et rarement exécuté. L’équipe peut exploiter le jeu de développement pour modifier le prompt, la recherche documentaire, les outils, les règles et le processus; son score reste une preuve de développement puisque le système a été optimisé face à ces exemples. Une utilisation répétée du test final pour choisir les changements crée un surajustement implicite. Attribuez donc la répartition lors de l’enregistrement du cas, avant son exécution habituelle ou l’inspection des sorties.

Protéger un test ne consiste pas seulement à cacher ses demandes. Il faut limiter l’accès aux cas, réponses de référence, grilles et résultats, puis rechercher les doublons exacts, les paraphrases, les dossiers sources partagés et les scénarios issus du même gabarit. Une défaillance déjà utilisée pour diagnostiquer ou corriger le système appartient au développement ou à la régression. Le test protégé peut couvrir la même classe de défaut uniquement avec un cas indépendant qui n’a pas guidé le changement.

• Déplacer vers la régression tout cas protégé qui a matériellement influencé une modification, puis créer un remplacement indépendant et versionné.
• Consigner dans le registre le propriétaire, la provenance, l’autorisation, la répartition, l’exposition, les versions, l’historique d’examen, le motif du changement et celui du retrait.
• Ajouter les défaillances vérifiées après autorisation et minimisation des données sensibles, sans présumer que les traces de production sont complètes ou correctement étiquetées.
• Réévaluer la couverture lorsque changent le processus, les utilisateurs, la politique, les connaissances, le modèle, les prompts, les outils, les permissions ou l’environnement.
• Publier les résultats par famille de tâche, famille de couverture, segment, conséquence et verrou, en plus de tout résumé global.

Un résultat hors ligne constitue une pièce du dossier de décision, pas un certificat de valeur, de sécurité, d’équité, de conformité ou d’aptitude à la production. Les responsables produit et risque doivent fixer l’usage des résultats et les conséquences des verrous avant de les voir; les spécialistes métier valident le réalisme et les issues attendues. Lorsque des données ou jugements gouvernés sont concernés, associez les fonctions autorisées en protection des données, sécurité, droit ou conformité. Les décisions juridiques, médicales, financières, d’emploi, de sûreté ou de sécurité restent entre les mains de personnes qualifiées et mandatées. Complétez enfin les tests par le suivi en exploitation, la recherche utilisateur et l’analyse des incidents.