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

Un bon jeu d’évaluation commence par un morceau de travail précisément borné, pas par une collection de prompts séduisants. Imaginons un assistant interne de demandes d’achat face à un dossier plausible, mais incomplet : deux identifiants fournisseur se contredisent, la politique applicable est momentanément inaccessible et le devis joint contient une instruction destinée à détourner l’assistant. Un score moyen ne dira pas s’il a demandé la bonne pièce, signalé l’incertitude, résisté à l’instruction importée et respecté l’étape d’approbation humaine.

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

Il doit combiner une représentation crédible du travail ordinaire avec une sélection volontaire des limites importantes, des échecs confirmés et des conduites interdites. Commencez par une version du système, un processus délimité, ses acteurs autorisés, ses entrées, ses connaissances, ses outils et la décision que l’évaluation doit éclairer. Les cas courants doivent suivre autant que possible le mélange observé dans l’activité, tandis que les événements rares mais lourds de conséquences exigent une présence délibérée.

Construisez ensuite une carte des familles de tâches et des variations réellement pertinentes : rôle de l’utilisateur, ambiguïté, pièce manquante, format inhabituel, autorisation, résultat d’outil ou information contradictoire. Les traces autorisées, dossiers de travail, demandes d’assistance, recherches utilisateurs, incidents et ateliers métier peuvent nourrir cette carte, sans être considérés automatiquement comme complets ou correctement étiquetés. Si l’activité n’est pas encore observable, consignez les hypothèses et leur degré d’incertitude au lieu d’inventer une précision statistique.

• Travail représentatif : demandes ordinaires, rôles, entrées et conditions usuelles, pondérés selon des observations autorisées.
• Cas limites importants : demandes ambiguës, informations absentes ou contradictoires, restrictions d’accès et défaillances d’outils.
• Échecs connus : reproductions minimisées d’incidents ou de défauts dont les faits et l’issue attendue ont été vérifiés.
• Comportements interdits : actions, divulgations ou contournements expressément exclus par le produit, la politique ou les responsables du risque.

Pour l’assistant de demandes d’achat, cette carte pourrait réunir un dossier complet, une pièce obligatoire absente, des montants incompatibles, une décision impossible faute de preuve, une tentative de contourner l’approbation, une consigne malveillante dans un devis et une récupération de politique indisponible. Ces règles restent illustratives et propres à l’organisation. Définissez avant toute sortie les segments à publier, les interdictions bloquantes et la décision de mise en production afin que les résultats ne dictent pas après coup les critères retenus.

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

Chaque scénario doit prendre la forme d’un dossier qu’un autre évaluateur peut rejouer sans deviner le contexte manquant. Donnez-lui un identifiant stable, un propriétaire, un historique de versions, une famille de couverture, des segments, une conséquence, une provenance, une autorisation d’usage et une affectation au jeu de développement ou au test protégé. Décrivez aussi l’acteur, son objectif, l’état initial, la demande, les fichiers et l’historique utiles.

• Configuration : instructions système, connaissances autorisées, droits, outils, résultats d’outils et conditions de l’environnement.
• Attentes : faits ou changements d’état nécessaires, chemins alternatifs recevables et situations imposant clarification, abstention, refus ou escalade.
• Interdictions : sorties, divulgations, appels d’outil, actions et changements d’état exclus, séparés des critères généraux de qualité.
• Opération : type d’évaluateur, grille, conditions de blocage, référence éventuelle, versions techniques, qualification des relecteurs et voie d’arbitrage.

Ne réduisez pas une tâche ouverte à une phrase idéale. Une solution de référence peut prouver que le cas est réalisable et aider à contrôler l’évaluateur, mais le dossier doit aussi reconnaître les formulations et chemins équivalents. Lorsque l’aléa ou une séquence d’actions compte, fixez avant l’observation le nombre d’essais jugé nécessaire pour ce cas et la règle d’agrégation. Archivez les versions du modèle, du prompt, du corpus de récupération, des outils, des permissions, de la politique et du harnais.

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

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érifiables. Des faits ou une solution de référence conviennent lorsque plusieurs formulations sont possibles mais que les preuves nécessaires ou l’état final restent bornés. Pour une qualité réellement ouverte, utilisez des dimensions distinctes assorties de repères observables.

• Contrôle déterministe pour une condition objective, après vérification que le cas est réalisable et que le contrôle est complet.
• Référence factuelle pour vérifier les éléments indispensables sans imposer une formulation unique.
• Grille ancrée pour la pertinence, la complétude, l’explication ou l’ancrage dans les preuves, avec calibration sur des jugements humains qualifiés.
• Jugement expert lorsque l’interprétation métier ou les conséquences ne peuvent pas être tranchées valablement par automatisation.

Le crédit partiel est utile lorsque la tâche comporte des étapes significatives, à condition de montrer précisément laquelle a échoué. Il ne doit jamais compenser une divulgation interdite ou une action non autorisée : ces événements relèvent d’une condition de blocage définie à l’avance par les responsables compétents. Figez aussi la version de la grille, la logique des conditions, les segments, l’agrégation des essais et la règle de décision avant de comparer des systèmes ; toute modification ultérieure crée une nouvelle version d’évaluation.

Un évaluateur fondé sur un modèle n’est pas objectif par nature. Ses jugements doivent être confrontés à ceux de personnes qualifiées dans le contexte pertinent, puis réexaminés lorsque la tâche ou la grille évolue. OpenAI indique d’ailleurs que l’évaluateur automatisé de GDPval ne pouvait pas remplacer les évaluateurs professionnels expérimentés de ce benchmark. Cette observation ne condamne pas l’automatisation ; elle rappelle qu’un accord obtenu sur des exemples de développement ne démontre pas à lui seul la validité du jugement.

Comment aider les évaluateurs à appliquer les critères de façon cohérente ?

Donnez aux évaluateurs un guide court qui expose le but du processus, le rôle de l’acteur, les preuves accessibles, les comportements permis, les limites du produit et la version de la grille avant de montrer une sortie. Chaque niveau de notation doit correspondre à des éléments observables, illustrés par des exemples positifs, négatifs et frontaliers. Prévoyez également une option « impossible à noter » lorsque le cas, la preuve ou l’environnement est défectueux.

1. Faire passer des cas de calibration avant la revue réelle et recommencer lorsque changent les tâches, la politique, la grille ou le groupe d’évaluateurs.
2. Masquer autant que possible l’identité du système et l’ordre des sorties lors d’une comparaison.
3. Recueillir notes et justifications indépendamment avant toute discussion.
4. Nommer un responsable de l’arbitrage et conserver les labels, motifs, versions de grille et décisions.

Un désaccord n’est pas seulement du bruit à éliminer. Il peut signaler un seuil imprécis, une pièce manquante, un cas impossible, plusieurs réponses légitimement acceptables ou une décision produit encore ouverte. L’arbitrage doit donc distinguer la correction d’un défaut de cas d’un véritable choix de politique. Forcer artificiellement le consensus effacerait une information précieuse ; conserver les rationales permet au contraire de réviser la grille, de recalibrer les évaluateurs automatiques et d’expliquer les changements de résultat.

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

Séparez un jeu de développement visible, utilisé pour améliorer prompts, récupération, outils, politiques et processus, d’un test de mise en production protégé et utilisé avec parcimonie. L’équipe optimise nécessairement contre les cas qu’elle examine ; leurs scores constituent donc des preuves de développement, pas une estimation indépendante. Affectez chaque cas à un ensemble dès son entrée dans le registre, avant son exécution habituelle ou l’inspection des sorties servant à sélectionner une solution.

Le test protégé doit refléter le même processus et les mêmes conditions de blocage, mais ses cas exacts, réponses, grilles et résultats ne doivent pas alimenter l’itération. Recherchez entre les ensembles les doublons exacts ou proches, les enregistrements sources partagés, les paraphrases et les scénarios issus du même gabarit. Suivez aussi les accès. Dès qu’un cas protégé influence matériellement une correction, reclassez-le en développement ou en régression et créez un remplacement indépendant et versionné.

• Enregistrer propriétaire, provenance, autorisation, ensemble, exposition, versions, historique de revue, motif de modification et motif de retrait.
• Ajouter les échecs vérifiés après minimisation des données sensibles et validation de l’issue attendue.
• Réexaminer la couverture après une évolution importante du processus, des utilisateurs, des règles, des connaissances, du modèle, des prompts, des outils, des droits ou de l’environnement.
• Publier les résultats par famille de tâches, famille de couverture, segment, conséquence et condition de blocage, pas seulement sous forme de moyenne.

Aucun nombre universel de cas, pourcentage de séparation, seuil de réussite ou rythme de renouvellement ne convient à tous les systèmes. La composition dépend de la décision à prendre, de la variabilité du processus, des segments importants, de la fiabilité de la notation et des preuves autorisées disponibles. Le registre sert à expliquer ce qui a changé et pourquoi, sans prétendre garantir l’indépendance. Il permet aussi d’identifier les références périmées, les labels contestables, les tâches ambiguës et les évaluateurs qui rejettent des variantes valables.

Enfin, considérez le jeu comme un élément du dossier de décision, jamais comme un certificat de sécurité ou d’aptitude à la production. Les responsables produit et risque définissent les usages et conditions de blocage avant les résultats ; les spécialistes métier vérifient le réalisme et les issues attendues. Les fonctions compétentes examinent les cas touchant à des données ou jugements gouvernés. Les décisions juridiques, médicales, financières, d’emploi, de sûreté, de sécurité ou de vie privée restent confiées à des personnes qualifiées et autorisées. Complétez les tests hors ligne par le suivi, la recherche utilisateurs et l’analyse des incidents.