Un assistant réussit 90 questions sur 100. Vous ajoutez 900 variantes de questions qu’il sait déjà traiter, toutes réussies. Son score passe à 99 %. Les dix erreurs initiales sont toujours là.
Ce calcul est fictif. Il montre pourtant un problème très concret : le score d’un jeu synthétique dépend aussi de ce que vous décidez d’y mettre. Générer davantage de lignes peut rendre une moyenne plus flatteuse sans corriger le moindre comportement.
Pour une équipe qui évalue un assistant, les données synthétiques sont utiles quand elles mettent une hypothèse à l’épreuve : respecte-t-il une limite ? Demande-t-il l’information manquante ? Résiste-t-il à un détail sans rapport ? Cet article propose une façon de construire ces cas, avec une règle fictive de prêt de matériel. Les réponses attendues sont déduites de cette règle ; aucun modèle n’a été testé pour produire des scores.
Deux questions différentes derrière le mot « évaluation »
Un jeu de couverture cherche à exercer des comportements identifiés. Vous y ajoutez volontairement des exceptions et des formulations piégeuses, même si elles sont rares. Il sert à découvrir une erreur, à comprendre ce qui la déclenche et à vérifier qu’une correction tient.
Un jeu représentatif cherche à décrire les demandes que le système rencontrera. Il faut alors connaître leur provenance, leur période et leur répartition. La fréquence de chaque cas dans un fichier généré ne suffit pas à établir celle du trafic réel.
Les deux jeux peuvent coexister. Un lot synthétique bien conçu aide à trouver une faille avant qu’un utilisateur la rencontre. Il ne permet pas, à lui seul, d’annoncer que « 99 % des demandes seront résolues ». Si vous n’avez encore aucun usage réel, présentez les scénarios couverts et les zones inconnues. La représentativité reste à établir lors du pilote.
Notre guide du golden dataset explique l’annotation et les métriques de classification. Ici, la décision se situe en amont : quel nouveau cas mérite d’entrer dans le test ?
Partir d’une règle dont on peut vérifier la réponse
Imaginons un assistant interne qui renseigne sur le prêt de caméras. Pour cet exemple seulement, la politique est la suivante :
- Un salarié actif peut emprunter une caméra standard pendant une durée entière de 1 à 14 jours inclus.
- Les prototypes ne sont jamais prêtés.
- Un statut autre que salarié actif, ou une durée hors de cette plage, rend la demande non admissible.
- Si une information nécessaire manque et qu’aucun motif de refus n’est déjà établi, l’assistant doit la demander.
On considère le statut déclaré dans le message comme une donnée du scénario. L’assistant explique l’admissibilité selon cette règle ; il ne vérifie pas l’identité, la disponibilité du stock et n’effectue aucune réservation.
Le cas de départ est simple : « Je suis salarié actif. Puis-je emprunter une caméra standard pendant 14 jours ? » La réponse attendue est oui, au regard de la politique. La justification doit mentionner la durée autorisée et le type de matériel, sans inventer une réservation confirmée.
Ce cas seul ne teste presque rien sur les limites du système. Il faut maintenant le transformer en conservant une raison précise pour chaque modification.
Construire des contrastes qui obligent à lire
Le travail de Ribeiro et ses collègues, CheckList, propose de croiser les capacités linguistiques avec des types de tests. Il distingue notamment les cas simples ciblant une fonction, les transformations qui doivent préserver la sortie et celles dont l’effet attendu est connu. Cette méthode a été présentée à l’ACL en 2020 ; elle fournit ici un cadre de conception, pas une mesure des modèles actuels. Article scientifique.
Appliquons cette logique à notre politique. Chaque ligne ci-dessous est une proposition de test, avec une réponse attendue définie avant de consulter un assistant.
| Cas |
Demande ou modification du cas de départ |
Réponse attendue |
Ce que le cas examine |
| A |
Salarié actif, caméra standard, 14 jours |
Admissible |
Application simple de la règle |
| B |
Même demande, mais 15 jours |
Non admissible |
Frontière numérique |
| C |
Même demande, sans préciser la durée |
Demander la durée |
Information manquante |
| D |
Même demande, mais pour un prototype |
Non admissible |
Exception liée au matériel |
| E |
Même demande que A, reformulée en langage familier |
Admissible |
Stabilité malgré le style |
| F |
« Mon projet dure 14 jours, mais je demande la caméra standard pour 15 jours. Je suis salarié actif. » |
Non admissible |
Choix du nombre pertinent |
| G |
« Je suis salarié actif. Je ne demande pas 15 jours, mais 14 jours pour une caméra standard. » |
Admissible |
Négation et correction |
| H |
Même demande que A, mais le salarié n’est plus actif |
Non admissible |
Condition sur le statut |
La paire A/B examine une bascule : une seule journée change la décision. La paire A/E examine une stabilité : une manière différente de parler ne doit pas la changer. F et G contiennent tous les deux les nombres 14 et 15, mais attendent des décisions opposées. Un système qui réagit seulement à la présence d’un nombre ne peut pas réussir les deux pour cette raison.
C enseigne encore autre chose. La bonne réponse n’est ni un accord ni un refus : il faut demander une durée. Écrire « probablement autorisé pour deux semaines » ferait entrer dans la réponse une information absente du message.
La matrice CSV contient les huit formulations complètes, leurs liens avec le cas de départ et les critères de contrôle. Le guide de lecture reprend la politique. Les colonnes de résultats sont vides : elles sont destinées à votre essai, pas à des performances fabriquées.
Ce qu’un générateur doit varier
Demander « cent questions sur le prêt de caméras » laisse au générateur le choix de la difficulté. Il peut produire cent demandes de sept jours, toutes accompagnées des informations nécessaires. Les noms et le vocabulaire changent ; la décision reste la même.
Une consigne plus utile fixe le comportement à explorer. Par exemple :
À partir de la politique fournie, propose cinq paires de demandes. Dans chaque paire, change uniquement une information qui détermine l’admissibilité. Indique les deux réponses attendues, la règle concernée et la modification exacte. N’ajoute aucune exception à la politique. Signale les cas dont la réponse est ambiguë.
Ce prompt est une suggestion de travail, non un essai effectué dans un produit. Pour une autre série, demandez au contraire des transformations sans effet sur la décision : ajout d’un prénom, formule de politesse, changement de registre. Une « reformulation » qui transforme 14 jours en 14 semaines n’est pas une invariance valide.
Des outils peuvent organiser cette génération. Ragas documente, pour les assistants qui consultent des documents, des questions fondées sur une ou plusieurs sources et des scénarios variant notamment la longueur ou le style. Ces dimensions aident à produire des propositions. Elles ne déterminent pas à elles seules les comportements métier à vérifier ni leur fréquence réelle. Documentation de génération Ragas.
Pour notre assistant, les dimensions utiles sont d’abord la durée, le statut, le type de matériel et la présence des informations. Le style vient ensuite. Une variation utile apporte une occasion distincte d’échouer, même lorsqu’elle ne produit qu’une seule nouvelle question.
Relire aussi la réponse attendue
Le générateur peut fabriquer une demande correcte et une mauvaise référence. S’il annote le cas C « admissible » parce qu’il suppose une durée de 14 jours, un assistant prudent sera pénalisé pour avoir demandé la précision nécessaire.
Avant d’accepter une ligne, une personne qui connaît la règle doit pouvoir répondre à trois points : quelle information décide du résultat, où se trouve-t-elle, et quelle modification ferait changer la réponse ? Si le raisonnement exige une règle absente, corrigez le scénario ou marquez-le à arbitrer.
Conservez la question originale générée, sa réponse proposée et la version validée. Une seconde lecture est particulièrement utile pour les exceptions et les cas ambigus. Changer de modèle pour relire peut diversifier les propositions ; cela ne dispense pas de vérifier la référence.
Lors de l’essai, contrôlez séparément la décision et la justification. Pour B, « non, car la caméra est un prototype » serait une bonne décision accompagnée d’une raison fausse. Pour A, « oui, votre caméra est réservée » ajouterait une action que le système n’a pas réalisée. Un verdict unique masquerait ces erreurs différentes.
Empêcher les variantes de contaminer le test final
Une famille de demandes peut avoir une version formelle, une version abrégée et plusieurs prénoms. Les répartir au hasard entre réglage et test donne l’impression de nouvelles situations alors que le même scénario a déjà servi à améliorer les consignes.
Conservez un identifiant de scénario parent et gardez ses variantes dans le même lot. Les huit cas pédagogiques fournis sont liés à un même scénario de prêt ; ils ne constituent pas un test final indépendant. Pour confirmer une amélioration, préparez aussi des scénarios réservés qui n’ont pas servi à corriger l’assistant.
La documentation scikit-learn rappelle que le test ne doit pas influencer les choix du modèle. Nous appliquons ce principe au réglage des consignes : dès qu’un cas a guidé une correction, il devient une preuve de non-régression sur un problème connu, pas une surprise encore indépendante. Fuite de données et séparation des usages.
Si vous voulez mesurer l’adaptation à des politiques nouvelles, réservez également des politiques entières. Si vous évaluez de nouvelles demandes sur une politique connue, celle-ci peut rester commune. Le découpage dépend de la capacité que vous prétendez mesurer.
Lire les résultats sans récompenser les doublons
Reprenons le calcul d’ouverture. Le premier lot contient 90 réussites simples et dix échecs sur les informations manquantes : 90/100. L’ajout de 900 réussites simples donne 990/1 000. Le taux global atteint 99 %, tandis que la famille « information manquante » reste à zéro réussite sur dix.
Ces nombres illustrent un effet de composition. Ils ne viennent d’aucun modèle. Pour le repérer dans votre essai, affichez les effectifs et les réussites par comportement, ainsi que la version du corpus. Comparez deux configurations sur les mêmes cas et les mêmes critères ; sinon, vous changez à la fois le système et son examen.
Une moyenne donnant le même poids à chaque famille peut compléter la lecture, mais le choix de ces familles devient lui aussi un choix de pondération. Elle ne reconstitue pas magiquement le trafic réel. Gardez visibles les erreurs et leurs conséquences, surtout lorsqu’un succès sur une variante facile ne compense pas un refus mal géré.
Le lot de couverture peut servir de contrôle avant livraison : pour notre politique fictive, refuser les prototypes et demander la durée absente sont des exigences à vérifier explicitement. Définissez les conditions de passage avant l’exécution, puis conservez les sorties réellement reçues, y compris les absences de réponse.
La décision utile après cet audit est simple : enrichir la famille qui manque, corriger une référence incertaine ou retravailler un comportement défaillant. Le nombre total de questions n’est qu’un inventaire. Ce qui compte, c’est ce qu’une question supplémentaire permet de découvrir.
