Bâtir un jeu d’évaluation par scénarios pour un système d’IA d’entreprise

Un bon jeu d’évaluation ne commence pas par une pile de questions brillantes, mais par un processus d’affaires bien délimité. Imaginez un assistant qui reçoit une demande d’achat plausible, un identifiant de fournisseur contradictoire, une politique introuvable et une soumission contenant des instructions destinées au système. Une moyenne élevée sur des demandes simples ne dira pas s’il gère correctement cette combinaison. Il faut plutôt cartographier le travail, reconstruire chaque situation de façon reproductible, fixer la notation avant de voir les réponses et protéger une partie des cas contre l’influence du développement.

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

Le jeu doit couvrir le travail attendu en proportion raisonnable de son occurrence, tout en réservant une place délibérée aux situations rares mais importantes. Commencez par une version précise du système, un seul processus borné, les acteurs et intrants permis, les connaissances et outils accessibles, puis la décision que l’évaluation doit éclairer. Une mesure crédible repose sur des cas clairement définis, réalistes et représentatifs des conditions d’utilisation prévues, avec une méthode documentée.

Dressez les familles de tâches et leurs variations pertinentes à partir de preuves autorisées. Les cas peuvent provenir de dossiers historiques, d’activités de production, de recherches auprès des utilisateurs, d’experts du domaine ou de données synthétiques, pourvu que leur réutilisation soit autorisée et leur représentativité examinée. Marquez les inconnues lorsque les journaux sont incomplets ou que le service n’est pas encore déployé; une hypothèse explicite vaut mieux qu’une précision inventée.

• Travail représentatif : demandes, rôles, intrants et conditions ordinaires, pondérés selon les données observées sans effacer les sous-groupes pertinents.
• Cas limites importants : ambiguïté, information manquante ou contradictoire, format inhabituel, permission restreinte ou résultat d’outil peu fiable.
• Échecs connus : reproductions minimisées et autorisées de défauts, d’incidents ou de plaintes dont les faits et le résultat attendu ont été vérifiés.
• Comportements interdits : tentatives directes ou indirectes d’obtenir une action, une divulgation ou un changement d’état que les responsables ont expressément barré.

Des guides officiels distinguent les cas représentatifs, les limites valides, les entrées adversariales et les échecs connus conservés comme cas de régression. La carte à quatre familles est toutefois une synthèse éditoriale adaptable, et non une taxonomie imposée par une seule source. Définissez aussi les segments à publier, les barrières liées aux interdictions et l’usage prévu du résultat avant de générer ou d’examiner les sorties. Les résultats doivent être ventilés lorsque des segments ou des contextes peuvent masquer des échecs aux conséquences différentes.

Dans l’exemple de l’assistant de demandes d’achat, les règles demeurent illustratives et propres à l’organisation. Les cas ordinaires portent sur un dossier complet et une politique accessible. Les variantes ciblées couvrent un document manquant, des montants ou identifiants contradictoires, une preuve insuffisante, une demande de contourner l’approbation humaine, des instructions cachées dans une soumission et une recherche documentaire indisponible. Le système peut vérifier et préparer une note, mais il ne doit ni autoriser la dépense, ni inventer une règle, ni exposer des renseignements confidentiels.

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

Chaque scénario doit être un dossier qu’une autre personne peut recréer sans deviner le contexte manquant. Une tâche d’évaluation doit définir ses intrants et ses critères de réussite; l’évaluateur peut ensuite examiner le résultat, la sortie produite ou la trace d’exécution. Donnez au cas un identifiant stable, un propriétaire, un historique de versions, une famille de couverture, des étiquettes de segment, un niveau de conséquence, une provenance, une preuve d’autorisation et une affectation au jeu de développement ou au test protégé.

• Configuration : acteur et objectif, état initial, demande, fichiers, historique pertinent, instructions du système et variation testée.
• Capacités disponibles : corpus autorisé, permissions, outils, résultats d’outils et conditions environnementales reproduites.
• Attentes : faits ou changements d’état requis, voies acceptables, besoin de clarification, d’abstention, de refus ou de transfert.
• Interdictions et fonctionnement : sorties, divulgations, appels d’outils ou changements d’état barrés, évaluateur, grille, barrières, versions et voie d’arbitrage.

Le dossier proposé ici rassemble provenance, configuration, preuves et outils disponibles, résultats acceptables et interdits, méthode de notation, versions et responsabilité. Il s’agit d’une synthèse adaptable. Pour un système non déterministe ou à plusieurs étapes, fixez avant l’exécution le nombre d’essais jugé nécessaire et la règle d’agrégation, sans prétendre qu’une quantité convient partout. Des évaluations professionnelles réalistes peuvent partir de produits de travail et fournir le contexte ainsi que les fichiers de référence nécessaires.

Décrivez plusieurs résultats acceptables lorsque la tâche le permet plutôt que d’imposer une phrase idéale. Une solution de référence fonctionnelle peut confirmer qu’un cas borné est réalisable et aider à vérifier l’évaluateur, sans devenir la seule formulation ni la seule voie acceptable. Pour l’assistant d’achat, une bonne réponse peut demander la pièce manquante ou transférer le dossier selon le processus établi; elle échoue toutefois si elle prétend qu’une approbation a été accordée ou masque l’absence de preuve.

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 de notation la plus étroite qui distingue validement la réussite de l’échec. Les vérifications déterministes, les évaluateurs fondés sur un modèle et le jugement humain ont des forces différentes; un évaluateur automatisé de qualité ouverte exige une grille structurée et un étalonnage par rapport à des jugements humains pertinents. OpenAI indique d’ailleurs que l’évaluateur automatisé de GDPval n’était pas assez fiable pour remplacer les évaluateurs professionnels expérimentés.

• Vérification déterministe pour une valeur, un schéma, un calcul, un argument d’outil, un état de dossier ou une action interdite objectivement vérifiable.
• Faits ou solution de référence lorsque plusieurs formulations sont valides, mais que les preuves requises ou l’état final sont bornés.
• Grille dimensionnelle avec repères observables pour la qualité ouverte, comme l’utilité, l’exhaustivité, l’ancrage dans les preuves ou la clarté.
• Jugement humain qualifié lorsque l’interprétation du domaine ou les conséquences ne peuvent pas être résolues validement par une vérification automatisée.

Noter le résultat et les contraintes importantes est souvent moins fragile qu’exiger un parcours exact, et les composantes utiles d’une tâche peuvent recevoir un crédit partiel. Certaines étapes demeurent toutefois obligatoires lorsqu’elles matérialisent une permission ou une approbation. Un résultat explicitement interdit devrait constituer une barrière non compensable, définie à l’avance par les responsables autorisés du produit et du risque. Fixez également les versions de la grille, les segments, l’agrégation des essais et la règle de décision avant de comparer les sorties.

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

Les évaluateurs appliquent plus uniformément les critères lorsqu’ils reçoivent un guide court, concret et versionné avant de voir les sorties. Présentez le but du processus, le rôle de l’acteur, les preuves disponibles, les comportements permis et les limites du produit. La fiabilité du travail de révision peut s’améliorer lorsque les évaluateurs reçoivent le contexte de la tâche, de l’information sur la solution prévue et des exemples positifs et négatifs; leurs désaccords peuvent révéler des règles ambiguës.

• Définir des repères observables pour chaque niveau de la grille, avec des exemples positifs, négatifs et frontaliers.
• Prévoir une option « preuves insuffisantes » ou « impossible à noter » pour les cas incomplets ou défectueux.
• Faire des cas d’étalonnage avant la révision et recommencer si la tâche, la politique, la grille ou le bassin d’évaluateurs change.
• Masquer l’identité du système et varier l’ordre des sorties lorsque cela est pratique pour une comparaison.
• Recueillir séparément les notes et leurs justifications avant la discussion, puis confier l’arbitrage à un responsable nommé.

GDPval illustre une révision experte en plusieurs étapes, une comparaison à l’aveugle et des grilles détaillées, sans établir un protocole universel. L’examen conjoint des sorties, des traces et des notes aide à distinguer une défaillance du système d’un cas, d’un évaluateur ou d’un environnement défectueux. Un désaccord ne doit pas être forcé vers un consensus lorsqu’il révèle plusieurs résultats légitimes ou une décision de produit encore non résolue. Conservez les notes initiales, les justifications, la version de grille et l’issue de l’arbitrage.

Comment garder le jeu utile pendant le développement et la mise en production?

Séparez un jeu de développement visible d’un test de mise en production protégé, puis consignez l’exposition et les changements des deux. Utiliser répétitivement un jeu d’essai pour guider des changements crée un risque d’adaptation implicite à ses cas; l’évidence de développement et le test final doivent donc être séparés. Le premier peut servir souvent à ajuster les requêtes, le corpus de recherche, les outils, les règles et le processus. Son score demeure une preuve de développement puisque l’équipe connaît ses cas.

Affectez chaque cas à son jeu dès son entrée au registre, avant que ses sorties influencent une décision de sélection. Réservez le test protégé aux comparaisons finales ou aux décisions de mise en production et limitez l’accès à son contenu, à ses réponses, à ses grilles et à ses résultats. Un cas protégé perd sa valeur d’évidence indépendante dès que son contenu, sa réponse, sa grille ou son résultat guide matériellement une modification. Déplacez-le alors vers la régression et créez un remplacement indépendant et versionné.

• Détecter les doublons exacts ou proches, les paraphrases, les dossiers sources communs et les scénarios issus du même gabarit.
• Consigner le propriétaire, la provenance, l’autorisation, l’affectation, l’exposition, les versions, les révisions et les motifs de retrait.
• Ajouter les échecs vérifiés après avoir minimisé les renseignements sensibles et confirmé le comportement attendu.
• Réexaminer la couverture après un changement important de processus, d’utilisateurs, de politique, de corpus, de modèle, de requête, d’outil ou de permission.
• Publier les résultats par tâche, famille, segment, conséquence et barrière plutôt que de se fier à une seule moyenne.

Les jeux de validation et de test s’usent par des utilisations répétées, et un test fiable doit éviter les doublons avec les données de développement tout en demeurant représentatif de l’usage prévu. Un jeu propre à une tâche peut croître avec des cas vérifiés provenant de sources de production, historiques, spécialisées, synthétiques et organisées par des humains. Les méthodes et les mesures doivent être réévaluées durant le cycle de vie en fonction du but, du contexte, des données disponibles et des risques importants.

Le registre et les contrôles d’exposition proposés ici n’imposent ni pourcentage de partage, ni calendrier de renouvellement, ni garantie absolue d’indépendance. La réussite d’un jeu hors ligne ne prouve pas, à elle seule, la valeur opérationnelle, la sûreté, l’équité, la conformité ou l’aptitude à la mise en production. Les responsables du produit et du risque doivent fixer l’usage des résultats; les spécialistes du domaine doivent valider le réalisme. Lorsque des renseignements ou décisions régis sont en cause, les fonctions qualifiées et autorisées doivent rester responsables, avec le suivi, la recherche utilisateur et l’examen des incidents comme preuves complémentaires.