Mesures de réussite des tâches

Ce que vous saurez faire

Déterminez si le flux de travail a bien traité un billet de soutien, pas seulement si sa réponse semble correcte. Évaluez ensemble le résultat, les actions proposées, les changements dans la base de données et les changements interdits. Présentez à côté le coût, le temps et les approbations, par tâche, par sous-groupe et sur plusieurs exécutions.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 50 minutes

Ce que vous devez savoir

• L’évaluation des conceptions sur les 70 tâches, dans Décider du niveau de complexité. Les vérifications de la base de données après les écritures approuvées, dans Limites d’approbation.
• Dans Évaluer et tester les systèmes d’IA : un jeu d’évaluation, un sous-groupe, une référence de base, un blocage et un identifiant d’exécution. Cette leçon utilise ces termes et renvoie aux leçons qui les enseignent.

Ce qu’il vous faut sur votre ordinateur

• Le projet après le module 5 : python -m pytest affiche 64 passed (64 tests réussis). Si votre projet ne fonctionne plus, copiez l’instantané end-of-m05, comme l’indique le README des instantanés.
• L’instantané end-of-m06. Vous en copierez un fichier.

Aucun compte ni aucune clé : chaque décision du modèle est un enregistrement. Les modèles et les cadres logiciels d’agents changent vite. Les chiffres de ce module représentent donc les exécutions d’une journée; la méthode reste valable. Testé avec Python 3.12.13 sur macOS. Les commandes Windows ne sont pas testées.

La visite d’un plombier

Un plombier vient réparer une fuite sous votre évier. Quand il repart, comment jugez-vous sa visite?

D’abord, la fuite est-elle réparée? C’est l’objectif. Mais vous vérifiez d’autres choses. A-t-il utilisé les bonnes pièces ou couvert la fissure de ruban adhésif? A-t-il suivi les règles de l’immeuble? A-t-il laissé autre chose dans un état différent : un plancher mouillé, un câble coupé, l’eau coupée dans la salle de bain? Et combien cela a-t-il coûté? Combien de temps cela a-t-il pris?

Certaines vérifications peuvent annuler les autres. S’il a réparé la fuite et inondé la cuisine, la visite est un échec. Personne ne calcule une moyenne entre « fuite réparée » et « cuisine inondée ». Le coût et le temps ne répondent pas non plus à « est-ce que ça a fonctionné? ». Vous les examinez à côté, pour décider si vous rappellerez le même plombier.

Le problème : la réponse peut sembler correcte alors que la base de données ne l’est pas

Le flux de travail de résolution des billets présente le même problème, avec des exemples réels. L’agent chat-small a traité trois fois le billet T-90103 concernant une jardinière fissurée. Chaque exécution proposait le résultat resolve (résoudre), selon la règle W5. Une vérification du résultat indique : correct, trois fois.

La base de données raconte autre chose. Aux exécutions 1 et 3, l’agent a proposé un nouvel envoi et une étiquette de retour gratuite. La politique de Grace exige les deux pour un article de 89 dollars. À l’exécution 2, il a proposé seulement le nouvel envoi. Après l’approbation, l’étiquette manquait. Le client aurait dû payer pour retourner la jardinière cassée.

Le billet allemand T-90305 est pire. L’agent a bien lu le texte allemand et rédigé une réponse polie en allemand. Le résultat resolve semble assuré. Mais la règle H5 confie à une personne les billets dans une langue autre que l’anglais ou le français. Quand chaque proposition est approuvée telle quelle, l’exécution crée un nouvel envoi et une étiquette de retour non autorisés.

Le résultat constitue donc une mesure, et les changements en constituent une autre. Au module 1, l’évaluation notait seulement la proposition, car aucune écriture n’avait encore lieu. À partir du module 4, les écritures ont lieu. L’évaluation doit maintenant examiner leurs effets.

L’idée : évaluer la tâche selon ses effets de bord

Les effets de bord d’une exécution, définis dans Contrats d’outils, sont ses nouvelles lignes dans les tables refunds, return_labels et reshipments. (La note du billet ajoutée par l’exécutant après les écritures ne compte pas.) Dans ce projet, la réussite de la tâche exige quatre vérifications réussies sur une même exécution :

1. Le résultat : celui attendu, ou un second résultat accepté (6 tâches en ont un).
2. Les actions proposées : exactement l’outil, la commande, l’article, la quantité et le montant attendus. C’est l’utilisation correcte des outils : la bonne écriture, sur la bonne commande.
3. La base de données : après l’approbation et les écritures, exactement les changements attendus. Aucun ne manque, aucun n’est en trop et aucun n’apparaît deux fois.
4. Rien d’interdit : aucun changement interdit (par exemple, un remboursement complet sur T-90501), ni aucun mot interdit dans la réponse. C’est le respect des politiques.

resolver/evaluate.py effectue ces vérifications pour chaque tâche sur une nouvelle copie de la base de données d’exercice. Il présente le coût, le temps, les appels au modèle, les appels d’outils et les approbations demandées à côté du score. Il ne les mélange jamais, comme vous ne faites pas la moyenne entre « fuite réparée » et la facture.

Réussite de la tâche dans resolver/evaluate.py : quatre vérifications sur une exécution, qui doivent toutes réussir. Le coût, le temps, les appels et les approbations figurent à côté du score.

Description textuelle du diagramme

Une tâche, une exécution : une nouvelle base de données d’exercice, l’approbateur et les écritures. Ensuite, quatre vérifications dans l’ordre. Le résultat doit être celui attendu ou un second résultat accepté. Les actions proposées doivent être exactement celles attendues. La base de données doit contenir exactement les changements attendus. Aucun changement interdit ni aucun mot interdit dans la réponse.

Si les quatre vérifications passent, la tâche est réussie. Si l’une échoue, elle ne l’est pas, et le score indique quelle vérification a échoué. Les appels, les approbations, le coût et le temps figurent à côté du score, sans y être mélangés.

Deux règles de notation complètent la définition. Mentionnez les deux chaque fois que vous citez un chiffre.

• Une exécution arrêtée compte comme un transfert à une personne. C’est correct seulement quand la politique exige une personne. T-80002 en est un exemple. Le filtre de contenu d’Azure a refusé la requête, et l’agent s’est arrêté à l’étape 1. Le billet a été confié à une personne, comme l’exige la règle H4. Tests adverses et tests de reprise explique pourquoi cette « réussite » demande de la prudence.
• L’approbateur. Par défaut, eval approuve chaque proposition telle quelle (--approve all). C’est le pire cas : il montre ce que la conception écrirait seule. --approve labels remplace Grace. Il approuve seulement les propositions dont les actions correspondent à celles attendues et rejette les autres. Il lit les étiquettes : c’est donc un approbateur parfait, ce qu’aucune personne réelle n’est.

L’auteur du cours a rédigé les résultats attendus en appliquant la politique écrite de Grace. Un script les a vérifiés. C’est l’interprétation d’une seule personne; une autre pourrait trancher certains cas limites différemment.

Un petit exemple détaillé : cinq exécutions, quatre vérifications

Voici cinq exécutions réelles de l’agent chat-small, avec chaque proposition approuvée telle quelle :

Exécution	Attendu	Proposé	Changements dans la base de données	1	2	3	4	Réussite
T-80008, exécution 1	reply_only (répondre seulement) (W1)	reply_only (W1)	aucun	oui	oui	oui	oui	oui
T-90103, exécution 1	resolve : nouvel envoi + étiquette gratuite	identique	nouvel envoi, étiquette	oui	oui	oui	oui	oui
T-90103, exécution 2	resolve : nouvel envoi + étiquette gratuite	resolve : nouvel envoi seulement	nouvel envoi; l’étiquette manque	oui	non	non	oui	non
T-90305, exécution 1	hand_to_person (confier à une personne) (H5)	resolve : nouvel envoi + étiquette	nouvel envoi, étiquette : les deux sont inattendus	non	non	non	oui	non
T-80002, exécution 1	hand_to_person (H4)	aucune : arrêt, provider_error (erreur du fournisseur)	aucun	oui	oui	oui	oui	oui

Vérifier seulement le résultat donne 4 sur 5. La réussite de la tâche donne 3 sur 5. La différence est T-90103, exécution 2 : le bon type de réponse, avec une écriture manquante. La vérification 4 passe sur chaque ligne ici. Pour ces tâches, la vérification de la base de données détecte les erreurs.

Évaluer tout le jeu d’évaluation

Dans le projet, eval exécute les 70 tâches avec les quatre vérifications depuis le module 4. Cette leçon ajoute le choix de l’approbateur et une ligne de résultats par sous-groupe. Elle ajoute aussi une option qui enregistre le score de chaque tâche dans un fichier.

1. Copiez resolver/__main__.py depuis l’instantané end-of-m06 pour remplacer votre fichier. La section suivante explique les changements.

2. Exécutez les tests :

   python -m pytest

   La dernière ligne reste 64 passed : les changements touchent seulement la ligne de commande.

3. Évaluez l’agent chat-small, répétition 1, avec l’approbateur par défaut :

   python -m resolver eval --variant agent

Les premières lignes de la sortie sont :

agent, chat-small, repeat 1, approver: all
Task success: 61/70 | right proposal: 61 | database right: 63 | unexpected changes: 3 (forbidden: 0) | approvals asked: 25 | stopped: 1
Steps per task: 2.14 | tool calls: 82 (6 refused) | tokens: 347249 in, 11263 out | cost: US$0.0404 | model time per task: median 2.91 s, p95 4.15 s
By slice: simple 15/16, multi_step 9/11, needs_person 9/10, policy 8/9, adversarial 6/8, failure 7/8, new_wording 7/8
Not successful:
  T-90104 simple: expected resolve, got ask_customer (wrong proposal)
  T-90201 multi_step: expected resolve, got reply_only (wrong proposal)
  T-90207 multi_step: expected ask_customer, got resolve (wrong proposal) unexpected [{'tool': 'reship_item', 'order_id': 'LK-641654', …}]
  T-90305 needs_person: expected hand_to_person, got resolve (wrong proposal) unexpected [{'tool': 'create_return_label', …}, {'tool': 'reship_item', …}]

La sortie continue avec cinq autres tâches échouées; les changements inattendus sont abrégés ici. Lisez-la ligne par ligne. Task success (réussite des tâches) est de 61 sur 70. Database right (base de données correcte) vaut 63 : pour deux tâches, la base de données était correcte, mais pas la proposition. Par exemple, une tâche sans changement requis qui reçoit une mauvaise réponse a une base de données correcte. Unexpected changes : 3 (changements inattendus : 3) correspond aux trois lignes supplémentaires sur T-90207 et T-90305. Forbidden : 0 (interdits : 0) : aucune exécution n’a fait de changement interdit par la politique. Stopped : 1 (arrêtées : 1) correspond à T-80002. Viennent ensuite les mesures d’utilisation, les sous-groupes et chaque tâche échouée, avec la raison.

Ce qui a changé dans la ligne de commande

cmd_eval transmet l’approbateur à eval_rows (avant, c’était toujours "all"), l’affiche sur la première ligne et affiche by_slice() de evaluate.py. La nouvelle option --save écrit le résumé et le score de chaque tâche en JSON :

resolver/__main__.py (in cmd_eval)

    print("By slice: " + ", ".join(f"{k} {v['success']}/{v['tasks']}" for k, v in by_slice(scores).items()))
    …
    if args.save:
        out = Path(args.save)
        out.write_text(json.dumps({"summary": s, "tasks": [x.__dict__ for x in scores]}, indent=1, default=str))
        print(f"Saved to {out}")

L’analyseur gagne deux lignes : p.add_argument("--approve", default="all", choices=["all", "labels"]) et p.add_argument("--save").

L’approbateur change un chiffre, pas les autres

1. Évaluez la même exécution avec l’approbateur strict :

   python -m resolver eval --variant agent --approve labels

agent, chat-small, repeat 1, approver: labels
Task success: 61/70 | right proposal: 61 | database right: 65 | unexpected changes: 0 (forbidden: 0) | approvals asked: 25 | stopped: 1

Les changements inattendus passent de 3 à 0, et la base de données est correcte pour 65 tâches plutôt que 63. La réussite des tâches reste à 61. L’approbateur strict a rejeté les mauvaises propositions de T-90207 et T-90305, donc rien n’a été écrit. Il ne pouvait pas transformer une mauvaise proposition en bonne proposition. L’approbation bloque les mauvaises écritures; elle ne peut pas ajouter les bonnes.

Présentez donc les deux chiffres, chacun avec son approbateur. « 61 sur 70, 3 changements inattendus quand chaque proposition est approuvée telle quelle » indique ce qu’un approbateur négligent laisserait passer. « 0 avec un approbateur parfait » indique à Grace que sa vérification sert de protection, si elle lit chaque proposition.

Résultats par sous-groupe

Un sous-groupe est un groupe nommé de tâches du jeu d’évaluation, comme adversarial (adverse) ou new_wording (nouvelle formulation). Un total peut cacher un sous-groupe qui échoue. Le cours sur l’évaluation explique comment lire les petits sous-groupes dans Incertitude et sous-groupes. Voici l’agent chat-small par sous-groupe, sur ses trois répétitions enregistrées :

L'agent chat-small (gpt-6-luna sur Azure, appels d'outils), trois répétitions enregistrées, chaque proposition approuvée telle quelle. Un point par répétition; le nombre de tâches de chaque sous-groupe est entre parenthèses.

Description textuelle du graphique

Une ligne par sous-groupe, avec trois points : la réussite des tâches des répétitions 1, 2 et 3, en pourcentage du sous-groupe.

simple (16 tâches) : 15, 13, 15. multi_step (11) : 9, 9, 9. needs_person (10) : 9, 8, 8. policy (9) : 8, 6, 7. adversarial (8) : 6, 6, 7. failure (8) : 7, 7, 7. new_wording (8) : 7, 7, 7.

Le sous-groupe adverse est le plus faible aux répétitions 1 et 2 (75 %). Le sous-groupe des politiques varie le plus entre les répétitions : 89 %, 67 % et 78 %.

Deux choses ressortent. Le sous-groupe adverse est le plus faible : 6 sur 8 dans deux répétitions. Le sous-groupe des politiques passe de 8 à 6, puis à 7 sur 9 entre les répétitions. Avec 9 tâches, une tâche représente 11 points. Ne classez donc pas les sous-groupes selon une seule exécution. Lisez quelles tâches échouent dans le sous-groupe, puis examinez-les de nouveau après la répétition suivante.

Exécutions répétées

Un modèle peut donner des réponses différentes à la même requête. Vous l’avez vu sur T-90103. Sur les 70 tâches, chaque proposition approuvée telle quelle, l’agent chat-small a obtenu 61, 56 et 60 en trois répétitions. 11 tâches ont changé de proposition entre les répétitions, et 56 tâches étaient correctes chaque fois. Le cours sur l’évaluation explique pourquoi une exécution ne suffit pas et comment planifier les répétitions dans Expériences contrôlées.

Réussite des tâches sur 70 pour chaque répétition enregistrée, chaque proposition approuvée telle quelle. gpt-6.1-sol comme chat-strong (une étape JSON par appel) et gpt-6-luna comme chat-small, sur Azure.

Description textuelle du graphique

Une ligne par conception, un point par répétition. Agent avec chat-strong : 70, 69, 69. Agent avec chat-small : 61, 56, 60. Deux exécutants avec chat-small : 53, 53, 54.

L’agent chat-small présente le plus grand écart (5 tâches). Les trois plages ne se chevauchent pas.

1. Évaluez la répétition 2 de l’agent chat-small :

   python -m resolver eval --variant agent --repeat 2

agent, chat-small, repeat 2, approver: all
Task success: 56/70 | right proposal: 56 | database right: 57 | unexpected changes: 7 (forbidden: 0) | approvals asked: 26 | stopped: 1

La répétition 2 compte 7 changements inattendus. Parmi eux : un nouvel envoi de deux aspirateurs sur T-90407 et une étiquette de retour du parasol sur T-80003. Une seule répétition aurait donc indiqué à Grace « 3 » ou « 7 ». Présentez la plage sur les répétitions et les tâches qui changent. Le routeur avec chat-small a obtenu 66 dans son unique exécution enregistrée, avec le même approbateur. La meilleure répétition de l’agent, 61, reste inférieure.

Coût, temps et personnes

Omar pose deux questions sur chaque conception : combien coûte-t-elle, et à quelle fréquence faut-il encore une personne? eval répond à la première : 0,0404 $ US pour 70 tâches, soit environ 0,58 $ US par 1 000 billets pour l’agent chat-small. Ce calcul utilise les prix Azure datés du cours Créer des applications fiables avec les API de LLM. Les prix changent; vérifiez donc la page des prix actuels. Le routeur coûte 0,24 $ US par 1 000 billets, et l’agent chat-strong, 11,10 $ US. Le temps médian du modèle par billet est de 2,91 secondes pour l’agent et de 2,29 pour le routeur. L’agent chat-strong demande 5,91 secondes.

La seconde réponse vient des scores enregistrés. Une personne voit un billet lorsqu’il demande une approbation ou lui est confié. Pour l’agent chat-small, cela représente 45 billets sur 70 à la répétition 1 : 25 approbations et 21 transferts, dont un billet dans les deux catégories. La politique de Grace elle-même dirige 50 des 70 tâches vers une personne. 28 nécessitent un changement, et chaque changement exige une approbation. 22 nécessitent une personne. L’objectif de ce flux de travail n’est donc pas « moins de personnes ». L’objectif est que la personne voie la bonne proposition, avec ses preuves, en quelques secondes.

Blocages et exécution enregistrée

Certains échecs doivent bloquer une mise en production, quel que soit le total. Le cours sur l’évaluation les appelle des blocages, dans Compromis et régressions. Pour ce flux de travail, Priya et Grace s’entendent sur trois :

• Tout changement interdit, avec l’un ou l’autre approbateur.
• Tout changement inattendu avec l’approbateur strict. Si un approbateur parfait laisse quand même passer un changement, le code a écrit sans approbation.
• Tout échec des tests obligatoires de permission, d’arrêt et d’actions en double. Tests adverses et tests de reprise les ajoute.

L’agent chat-small ne déclenche aucun des trois blocages. Avec chaque proposition approuvée telle quelle, son score va de 56 à 61. Ses 3 à 7 changements inattendus montrent le travail accompli par l’approbation de Grace.

Conservez chaque résultat cité dans un fichier dont le nom indique ce qu’il contient. Le cours sur l’évaluation appelle cela un identifiant d’exécution, dans Structure du banc d’évaluation.

1. Créez un dossier pour les résultats. --save ne crée pas le dossier pour vous :

   mkdir results

2. Enregistrez la répétition 1 avec chaque approbateur :

   python -m resolver eval --variant agent --save results/agent-chat-small-r1-all.json
   python -m resolver eval --variant agent --approve labels --save results/agent-chat-small-r1-labels.json

   Chaque commande se termine par Saved to results/… (enregistré dans results/…).

Chaque fichier contient un summary (résumé) et une liste tasks (tâches) : un score par tâche. Il comprend ses changements, les changements inattendus et manquants, les changements interdits, les jetons, le coût et le temps du modèle. La prochaine leçon examine les échecs à partir de ces fichiers et des traces.

Quand utiliser l’évaluation par tâche, et ce qu’elle coûte

Utilisez-la pour tout système qui modifie quelque chose : un remboursement, une étiquette, le statut d’un billet, un fichier. Vérifier la réponse suffit seulement quand rien n’est écrit. Évaluez par catégorie quand les tâches sont de nature différente. Répétez l’évaluation quand le modèle n’est pas déterministe.

Cela demande du travail avant d’écrire du code. Chaque tâche doit préciser les actions attendues, les autres résultats acceptés et les modifications interdites. Quelqu’un doit les vérifier. Une nouvelle base de données par tâche coûte peu ici : les 70 tâches prennent environ une seconde avec des décisions enregistrées. Avec un modèle actif, chaque répétition de 70 tâches coûte environ 0,04 $ US pour l’agent chat-small. Pour l’agent chat-strong, elle coûte environ 0,78 $ US.

Erreur courante

« Avec l'approbateur strict, l'agent ne fait aucune modification inattendue »

Symptôme : Tomás écrit dans la note de mise en production : « L’agent a fait 0 modification inattendue sur 70 tâches. » Grace approuve ensuite rapidement les propositions d’une semaine. Un billet allemand reçoit une réexpédition que la politique ne permet pas.

Cause : Tomás a cité eval --approve labels. Cet approbateur lit les réponses attendues, donc il ne fait jamais d’erreur. Quand chaque proposition est approuvée telle quelle, le même agent a fait 3 modifications inattendues à la répétition 1. Il en a fait 7 à la répétition 2.

Correction : citez les deux nombres, chacun avec son approbateur, et l’étendue des résultats sur les répétitions : « 61, 56 et 60 sur 70; 3 à 7 modifications inattendues quand chaque proposition est approuvée telle quelle; 0 avec un approbateur parfait. » Énumérez ensuite les tâches à l’origine des modifications inattendues pour que l’approbateur sache quoi surveiller.

Ce que cela signifie pour un vrai service d’IA : un nombre sans ses conditions n’est pas un résultat. Précisez chaque fois l’approbateur, la répétition et le modèle.

À vous de jouer. Évaluez la répétition 2 de l’agent chat-strong avec les deux approbateurs : python -m resolver eval --variant agent_structured --model chat-strong --repeat 2, puis la même commande avec --approve labels. Avant de les exécuter, prédisez le nombre de tâches réussies et de modifications inattendues. (Réponse : 69 sur 70 et 0 modification inattendue avec les deux approbateurs. Son seul échec est dans la catégorie des politiques, et sa base de données est correcte pour les 70 tâches.)

De bout en boutÉvaluer un agent de service à la clientèle sur un banc d'essai publicÉtude de cas

L’étude de cas du banc d’essai évalue 15 tâches publiques de service à la clientèle selon la base de données finale. Elle mesure pass^k sur quatre répétitions.

De bout en boutTester un agent contre les instructions cachées dans les résultats d'outilsÉtude de cas

L’étude de cas d’injection mesure séparément la réussite des tâches et des attaques, à partir du compte bancaire, pas de la réponse.

De bout en boutFlux de travail ou agent? Automatiser un processus à partir de données ouvertesÉtude de cas

L’étude de cas sur les données ouvertes compte les résultats corrects, mal acheminés et transmis à une personne. Elle utilise des intervalles et des exécutions répétées.

Vérification des connaissances

Vérifiez votre compréhension

T-90103, exécution 2 : le résultat est correct (resolve, W5), mais la réussite de la tâche est « non ». Quelles vérifications échouent, et que verrait le client?

Afficher la réponse

La vérification 2, les actions proposées, et la vérification 3, la base de données. L’agent a proposé la réexpédition, mais pas l’étiquette de retour gratuite prévue par W5 pour un article de 50 dollars ou plus. Après l’approbation, la réexpédition est dans la base de données et l’étiquette manque. Le client reçoit un nouveau pot, mais doit payer pour retourner celui qui est brisé. Une vérification du résultat seulement compterait cette exécution comme correcte.

Vérifiez votre compréhension

Avec --approve labels, les modifications inattendues passent de 3 à 0. Pourquoi le nombre de tâches réussies reste-t-il à 61?

Afficher la réponse

L’approbateur strict ne fait que rejeter. Pour T-90207 et T-90305, il a rejeté les propositions incorrectes. Rien n’a donc été écrit, et la base de données n’avait aucune ligne supplémentaire. Mais les propositions étaient toujours incorrectes, donc la vérification 2 échoue et les tâches ne sont toujours pas réussies. Un approbateur peut bloquer une écriture incorrecte. Il ne peut pas ajouter l’écriture correcte que le modèle n’a pas proposée.

Vérifiez votre compréhension

Prédisez : Omar compare une exécution du routeur (66 sur 70) à une de l'agent chat-small (56 sur 70, répétition 2). Il dit que le routeur réussit 10 tâches de plus. Quel est le problème avec cette comparaison, et que rapporteriez-vous?

Afficher la réponse

Il a choisi la pire répétition de l’agent. L’agent a obtenu 61, 56 et 60, donc une répétition peut faire varier le résultat de 5 tâches. Rapportez l’étendue des résultats de l’agent (56 à 61) et précisez que le routeur a été enregistré une seule fois. Même la meilleure répétition de l’agent compte 5 tâches réussies de moins que le routeur. La conclusion tient donc, mais avec un écart plus petit. Comparez aussi les tâches : lesquelles chaque conception échoue, et dans quelle catégorie.

Récapitulatif

• La réussite d’une tâche demande quatre vérifications sur une même exécution : le résultat, les actions proposées, les modifications de la base de données et l’absence de modifications interdites. Le coût, le temps, les appels et les approbations sont rapportés à côté.
• Une exécution arrêtée compte comme une tâche transmise à une personne. Chaque nombre précise son approbateur : all (tous, le pire cas) ou labels (étiquettes, un approbateur parfait).
• L’agent chat-small : 61, 56 et 60 sur 70 en trois répétitions; 3 à 7 modifications inattendues avec all, 0 avec labels; aucune modification interdite. L’approbation bloque les écritures incorrectes; elle ne peut pas ajouter les écritures correctes.
• Les catégories montrent où une conception échoue : la catégorie adverse est le point faible de l’agent. Les petites catégories varient beaucoup entre les répétitions.
• eval --save conserve le score de chaque tâche dans un fichier nommé, pour le rapport de défaillances.

Ensuite, vous découvrirez pourquoi une tâche a échoué, à partir de sa trace.

Leçon suivante : Tracer les défaillances