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

Un jeu d’évaluation utile commence par un travail métier délimité, pas par une collection de prompts séduisants. Imaginez un assistant interne qui reçoit une demande d’achat plausible, mais aussi un identifiant fournisseur contradictoire, une politique indisponible et un devis contenant des instructions destinées à détourner son comportement. Une moyenne flatteuse ne dira pas s’il a signalé le conflit, demandé la pièce manquante ou franchi une limite. Il faut des cas reproductibles, des critères fixés avant les résultats et des preuves distinctes pour l’itération et la décision de mise en production.

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

Il doit couvrir le travail représentatif, les limites importantes, les échecs connus et les comportements interdits autour d’un seul workflow borné. Commencez par préciser la version du système, les utilisateurs admis, les entrées, les connaissances, les outils et la décision que l’évaluation doit éclairer. Un jeu valable doit recréer des conditions d’utilisation réalistes et documenter sa méthode de test. Cette carte en quatre familles est une synthèse éditoriale adaptable, et non une norme imposée par une source unique.

Reconstituez d’abord les familles de tâches à partir d’éléments autorisés: traces opérationnelles, dossiers historiques, demandes d’assistance, recherche utilisateur et parcours commentés par des spécialistes du métier. Les cas peuvent aussi être synthétiques ou sélectionnés manuellement, à condition d’en vérifier l’autorisation, la qualité et la représentativité. Lorsque les journaux sont incomplets ou que le système n’est pas encore lancé, notez explicitement l’incertitude au lieu d’inventer une répartition précise. Les données de production ne sont ni automatiquement licites à réutiliser ni automatiquement correctes.

Échantillonnez le travail ordinaire en rapport avec le mix observé, puis ajoutez volontairement les situations rares mais lourdes de conséquences. Pour l’assistant d’achat, cela peut inclure un dossier complet, une pièce absente, des montants contradictoires, une politique inaccessible, une demande de contourner l’approbation ou des instructions cachées dans un devis. Ces règles restent illustratives et propres à chaque organisation. Définissez aussi les segments à publier et les barrières de décision avant d’observer les sorties, car les résultats doivent être lus selon les conséquences plutôt qu’à travers une seule moyenne.

Comment consigner chaque scénario pour qu’il soit reproductible ?

Consignez chaque scénario dans une fiche versionnée qui permet à une autre personne de recréer l’état initial, d’identifier les issues acceptables et de détecter les actes interdits. Donnez-lui un identifiant stable, un propriétaire, une famille de couverture, des étiquettes de segment, une conséquence, une provenance, une autorisation et une affectation au développement ou au test protégé. Une évaluation professionnelle réaliste peut partir d’un livrable de travail et fournir le contexte ainsi que les fichiers nécessaires, mais tout contenu sensible doit être minimisé et soumis aux contrôles d’accès applicables.

• Configuration: rôle et objectif de l’acteur, état du workflow, demande, fichiers, historique pertinent, conditions environnementales et instructions reçues.
• Moyens disponibles: connaissances autorisées, permissions, outils, résultats d’outils et limites d’accès reproduits tels qu’ils existent dans le cas.
• Attentes: faits ou changements d’état requis, variantes acceptables et circonstances imposant clarification, abstention, refus ou escalade.
• Interdits et exploitation: sorties, divulgations, appels d’outil ou changements d’état prohibés, mode de notation, versions techniques et voie d’arbitrage.

Ne réduisez pas une tâche ouverte à une réponse modèle mot pour mot. Une solution de référence fonctionnelle peut démontrer qu’un cas borné est réalisable et aider à contrôler l’évaluateur, sans devenir la seule formulation admise. Pour un système non déterministe ou à plusieurs étapes, fixez avant les sorties le nombre d’essais utile au cas et la règle d’agrégation, sans chercher un nombre universel. Conservez également les versions du modèle, de l’invite, du corpus de recherche, des outils, de la politique et du dispositif d’évaluation.

Un bon cas 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 ?

Choisissez la méthode la plus étroite capable de distinguer valablement la réussite de l’échec. Un contrôle déterministe convient à un schéma, un calcul, un argument d’outil, un état de dossier ou une action interdite objectivement vérifiable. Des faits ou une solution de référence conviennent lorsque l’issue est bornée mais que plusieurs formulations restent correctes. Pour une qualité réellement ouverte, séparez les dimensions de la grille, décrivez des repères observables et calibrez tout évaluateur fondé sur un modèle par rapport à des jugements humains qualifiés dans le contexte concerné.

• Contrôle déterministe: précis pour un résultat vérifiable, mais à tester contre une solution fonctionnelle afin de repérer une règle incomplète ou contournable.
• Référence bornée: utile pour les faits exigés ou l’état final, sans imposer automatiquement le même style ni le même parcours.
• Grille par dimensions: adaptée à l’utilité, la complétude ou l’ancrage, avec des niveaux décrits par des comportements observables.
• Jugement expert: nécessaire lorsque l’interprétation métier ou les conséquences dépassent ce qu’un contrôle automatisé peut résoudre valablement.

Noter le résultat et les contraintes matérielles est souvent moins fragile qu’imposer un chemin unique, et des composantes utiles peuvent recevoir un crédit partiel. Ce crédit doit toutefois rester visible par composante. Un comportement explicitement interdit doit former une barrière non compensable, définie à l’avance par les responsables autorisés du produit et du risque. Une divulgation confidentielle ou une action sans autorisation ne devient pas acceptable parce que le reste de la réponse est excellent. Dans GDPval, OpenAI indique d’ailleurs que son évaluateur automatisé n’était pas assez fiable pour remplacer les évaluateurs professionnels expérimentés.

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

Donnez aux évaluateurs un guide bref qui expose le but du workflow, le rôle de l’utilisateur, les preuves disponibles, les comportements permis, la limite du produit et la version de la grille avant de montrer une sortie. Pour chaque niveau, fournissez des repères observables ainsi que des exemples positifs, négatifs et situés à la frontière. Ajoutez une option « preuves insuffisantes » ou « impossible à noter » afin qu’un cas défectueux ne soit pas transformé artificiellement en échec du système.

1. Faites noter quelques cas de calibration avant la revue réelle et recommencez lorsque la tâche, la politique, la grille ou le groupe d’évaluateurs change.
2. Masquez l’identité du système et alternez l’ordre des sorties lorsque cela est praticable pour une comparaison.
3. Recueillez les notes et justifications indépendamment avant toute discussion collective.
4. Analysez le désaccord comme un signal possible de contexte manquant, de seuil flou, de cas défectueux ou de pluralité légitime.
5. Nommez un responsable de l’arbitrage et conservez les annotations, justifications, versions de grille et décisions finales.

Le contexte, les informations sur la solution attendue et des exemples positifs et négatifs peuvent améliorer la fiabilité des évaluateurs; leurs désaccords peuvent révéler des règles ambiguës. L’examen conjoint des notes, des sorties et, lorsqu’elles existent, des traces aide aussi à distinguer un échec du système d’un cas, d’un évaluateur ou d’un environnement défectueux. Un désaccord ne doit cependant pas être forcé vers un consensus lorsqu’il révèle plusieurs réponses légitimes ou une décision produit encore ouverte. GDPval illustre ces pratiques sans établir de protocole universel.

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

Séparez un jeu de développement visible, utilisé pour l’itération, d’un test de mise en production protégé et consulté avec parcimonie. Les résultats du premier constituent des preuves de développement puisque l’équipe ajuste les invites, la recherche, les outils, les règles ou le workflow en connaissant ses cas. Réutiliser le même test pour guider ces changements crée un risque d’adaptation implicite. Affectez donc les cas à leur jeu lors de l’enregistrement, avant leur exécution habituelle ou l’inspection des sorties servant à la sélection.

Recherchez entre les jeux les doublons exacts, les reformulations proches, les sources communes et les scénarios issus d’un même gabarit. Suivez aussi l’accès au contenu des cas, aux solutions, aux grilles et aux résultats. Un échec déjà utilisé 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 d’échec par un cas créé indépendamment. Dès qu’un cas protégé influence matériellement une modification, déplacez-le et ajoutez une nouvelle version réellement non exposée.

• Propriétaire, provenance, autorisation, famille, segments, conséquence et affectation de chaque cas.
• Versions du cas, des attentes, des grilles, des barrières, du système et du dispositif d’évaluation.
• Expositions connues, doublons repérés, historique de revue, changements d’étiquette et décisions d’arbitrage.
• Motif de chaque ajout, remplacement, déplacement entre jeux, actualisation ou retrait.
• Résultats ventilés par tâche, famille, segment, conséquence et barrière, en plus de toute synthèse.

Réévaluez la couverture lorsque changent le workflow, les utilisateurs, la politique, le corpus de connaissances, le modèle, les invites, les outils, les permissions ou l’environnement d’exploitation. Un jeu peut s’enrichir de cas vérifiés issus de plusieurs sources, mais chaque ajout doit rester autorisé, minimisé et correctement étiqueté. Le registre proposé n’impose ni pourcentage de partage, ni délai fixe de renouvellement, ni garantie d’indépendance. Enfin, un succès hors ligne n’établit à lui seul ni valeur métier, ni sécurité, ni équité, ni conformité, ni aptitude à la production; associez-le au suivi, à la recherche utilisateur et à l’analyse des incidents.