Tracer les défaillances

Ce que vous saurez faire

Découvrez pourquoi une tâche a échoué en lisant ce que l’exécution a fait, dans l’ordre. Examinez les appels au modèle, les résultats d’outils, la proposition, l’approbation et les écritures. Trouvez le premier événement incorrect, nommez son type et décidez où apporter la correction, sans deviner ce que pensait le modèle.

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

Ce que vous devez savoir

• La réussite des tâches et les scores enregistrés, dans Mesures de réussite des tâches.
• Les événements dans l’état d’une exécution et la commande trace (trace), dans Un état de tâche explicite et Point de contrôle et reprise.

Ce qu’il vous faut sur votre ordinateur

• Le projet après la dernière leçon, avec results/agent-chat-small-r1-all.json. python -m pytest affiche 64 passed (64 tests réussis).

Cette leçon n’ajoute aucun fichier au projet. Chaque trace est un enregistrement réel de gpt-6-luna comme chat-small ou de gpt-6.1-sol comme chat-strong sur Azure. Le code du projet rejoue ces enregistrements. Dans les étapes, vous approuvez certaines propositions comme Amira : le choix d’une personne, simulé. Une section montre trois nouvelles réponses de chat-small, enregistrées pour cette leçon. Le tout a été testé avec Python 3.12.13 sur macOS.

Un colis qui n’est jamais arrivé

Vous avez commandé un colis, et il n’est pas arrivé. Vous ouvrez la page de suivi :

1. Ramassé au magasin, lundi à 8 h 12.
2. Arrivé au dépôt, lundi à 15 h 40.
3. En livraison, mardi à 7 h 55.
4. Tentative de livraison : adresse introuvable, mardi à 11 h 20.
5. Retourné au dépôt, mardi à 17 h 05.

Vous savez où le problème est survenu : à l’événement 4. Le colis a quitté le dépôt correctement. Le livreur n’a pas trouvé l’adresse. Vous pouvez maintenant vérifier l’adresse sur la commande, où se trouvait la véritable erreur.

Vous n’aviez pas besoin de savoir ce que pensait le livreur. Si vous l’appelez une semaine plus tard pour lui demander, il vous donnera un récit qui peut sembler juste. Mais les lectures du code de suivi consignent ce qui s’est passé à ce moment-là. Son récit est un nouveau texte, rédigé après.

Le problème : vous connaissez le score, pas la raison

La dernière leçon vous a indiqué quelles tâches ont échoué : 9 sur 70 pour l’agent chat-small à la répétition 1. Chaque proposition était approuvée telle quelle. T-90104 et T-90305 en faisaient partie. Elle ne vous a pas dit pourquoi. Sans connaître la raison, vous ne pouvez pas choisir la correction. Faut-il modifier la requête (prompt), un outil, le texte de la politique ou l’écran d’approbation?

Tomás a une idée : « Demandez au modèle pourquoi il a fait ça. Ou activez son raisonnement et lisez-le. » Les deux semblent raisonnables. Les deux échouent, pour deux raisons.

D’abord, le raisonnement n’est pas accessible. chat-small fonctionne avec reasoning_effort: "none". Il a donc utilisé 0 jeton (token) de raisonnement dans ses 149 appels ayant reçu une réponse à la répétition 1. chat-strong raisonne de lui-même. À la répétition 1, il a utilisé 518 jetons de raisonnement dans 17 de ses 134 appels ayant reçu une réponse. Azure les compte dans la facture, mais ne les retourne pas. Vous payez pour ce texte, sans pouvoir le lire.

Ensuite, une explication demandée plus tard est un nouveau texte, pas un enregistrement. La section Demander au modèle pourquoi ci-dessous montre trois exemples réels.

L’idée : lire la trace et trouver le premier événement incorrect

Vous lisez des traces depuis Limites entre flux de travail et agent. Voici la définition complète. Une trace est l’enregistrement ordonné des actions observables d’une exécution. Elle contient chaque appel au modèle et ce qu’il a demandé, ainsi que chaque appel d’outil et son résultat. Elle contient aussi le plan, la proposition, l’approbation, chaque écriture, chaque rapprochement et l’arrêt. Le projet la conserve dans l’état de la tâche, sous forme de liste d’événements, et trace l’affiche.

Pour trouver pourquoi une tâche a échoué, parcourez la trace depuis le début. À chaque événement, posez une question : était-ce correct, compte tenu de ce que l’exécution savait à ce moment-là? Le premier événement pour lequel la réponse est « non » est le premier événement incorrect. Son type vous indique où chercher la correction :

Type du premier événement incorrect	Exemple	Où apporter la correction
Un appel d’outil refusé ou en échec, sans reprise possible	le service de commandes est en panne, et l’exécution devine	le contrat d’outil, les règles de la boucle ou la règle « une personne » de la politique
Une lecture manquante ou incorrecte	aucun get_payments pour un double prélèvement	les instructions de la requête, les descriptions d’outils
Une décision contraire aux faits	la commande a 12 jours de retard, et le modèle applique la règle pour « perdue »	le texte de la politique, la requête, le modèle
Une proposition incorrecte que l’approbation laisse passer	une réexpédition approuvée pour un billet en allemand	l’écran d’approbation et la liste de vérification de la personne qui approuve
Une écriture qui échoue ou se produit deux fois	un délai dépassé après l’écriture, puis un second appel	l’exécuteur : identifiants d’opération, rapprochement

Les événements après le premier événement incorrect sont souvent incorrects aussi, mais ce sont des conséquences. Corrigez le premier.

Voici une trace avec chaque type d’événement, y compris une défaillance et une approbation. Il s’agit de T-90603, un double prélèvement. L’appel de remboursement dépasse le délai après que le remboursement a été effectué (simulation) :

La trace de T-90603 sous forme de chronologie : appels au modèle, résultats d'outils, approbation, écriture en échec et rapprochement. Chaque flèche est un événement que le projet enregistre. Les décisions du modèle sont des enregistrements de gpt-6-luna comme chat-small; le dépassement de délai est simulé.

Description textuelle du diagramme

T-90603, un double prélèvement. Étape 1 : le modèle demande get_order; le service de commandes répond ok. Étape 2 : le modèle demande get_payments; le service de paiements répond avec deux prélèvements encaissés de 45,95. Étape 3 : le modèle demande de terminer avec un remboursement de 45,95 sur le paiement le plus récent, selon W7. La boucle vérifie la proposition, et l’exécution attend l’approbation.

Amira voit l’action exacte et l’approuve. L’exécuteur écrit le remboursement avec un identifiant d’opération. Le service de paiements dépasse le délai, mais le remboursement a été effectué (simulation). L’exécuteur fait le rapprochement : il recherche l’identifiant d’opération, trouve le remboursement et ne l’envoie pas de nouveau. L’exécution s’arrête avec done, avec un seul remboursement.

Lisez cette trace en posant la question. Chaque événement est correct, compte tenu de ce que l’exécution savait. Le dépassement de délai est un événement de défaillance, mais pas un événement incorrect : l’exécuteur a ensuite agi correctement. Une trace contenant une défaillance ne signifie pas que la tâche a échoué.

Un petit exemple détaillé : T-90104, cinq événements

T-90104 concerne un arrosoir en retard. Le client écrit qu’il a été « expédié il y a des semaines ». La politique de Grace prévoit resolve (résoudre) : rembourser les frais d’expédition de 9,95 selon W2. La commande a plus de 5 jours ouvrables de retard. Voici sa trace :

1. Exécutez le billet de soutien avec sa trace :

   python -m resolver run T-90104 --trace

Run T-90104-agent-chat-small-1: agent, chat-small, ticket T-90104, status done
2 model call(s), 4565 tokens in, 179 out, US$0.00055, 2.996 s waiting for the model

  1  model     chat-small: get_order({"order_id":"LK-793996"})  (2163 in, 21 out, 1.05 s)
  1  tool      get_order({"order_id": "LK-793996"}) -> ok
  2  model     chat-small: finish({"outcome":"ask_customer","rule":"W3","…)  (2402 in, 158 out, 1.946 s)
  2  proposal  ask_customer (W3): no change
  2  stop      finished

Parcourez-la événement par événement :

1. Le modèle demande get_order LK-793996. Correct : le billet indique la commande.
2. Outil : ok. Correct. Le résultat indique : expédiée le 16 septembre, business_days_late (jours ouvrables de retard) 12, frais d’expédition de 9,95, refunds (remboursements) vide. Ce sont tous les faits nécessaires à W2, calculés dans le code.
3. Le modèle demande de terminer avec ask_customer (demander au client), règle W3. Incorrect. W3 vise une commande ayant plus de 15 jours ouvrables de retard. Elle en a 12.
4. Proposition : ask_customer. La même décision, acceptée par le schéma : c’est une résolution valide, mais pas la bonne.
5. Arrêt : terminé.

Le premier événement incorrect est le numéro 3 : une décision contraire aux faits. L’outil a fait son travail; le modèle a mal lu la politique. La proposition contient aussi la raison donnée par le modèle. Il dit que le remboursement W2 « est dû ». Puis il affirme qu’« aucun fait ne confirme si ces frais ont déjà été remboursés ». Mais la commande montrait "refunds": []. La raison donnée ne correspond pas aux faits. Elle ne peut donc pas servir d’enregistrement de la décision. La trace, elle, le peut.

Explorer les traces

L’explorateur contient sept exécutions réelles, événement par événement. Trois sont des échecs, et quatre ont réussi, certaines avec un événement de défaillance. Les approbations sont celles d’Amira, dans les étapes de cette leçon.

Explorer

Où l'exécution a-t-elle commencé à se tromper?

T-90305 (needs person), client C-52445: “Hallo, meine Bestellung LK-642445 ist beschädigt angekommen. Der Deckel des Komposters ist gebrochen. Foto im Anhang.” Pièce jointe : IMG_3381.jpg.

Attendu selon la politique de Grace : hand_to_person (H5) : aucune modification. Exécution T-90305-agent-chat-small-1 : gpt-6-luna comme chat-small, enregistrée, rejouée par le code du projet. Approuvé par Amira (agente), dans les étapes de la leçon.

Statut

terminé

Appels au modèle

2 (4 591 jetons en entrée)

Appels d’outils

1

Changements écrits

2

T-90305, événement 9 sur 9. Réussite de la tâche : non, avec 2 changements inattendus dans la base de données. Premier événement fautif : la proposition à l’étape 2. Le billet est en allemand, donc H5 dit : le confier à une personne. Le modèle a bien lu l’allemand et a appliqué W5. Puis l’approbation l’a laissé passer, et deux modifications que la politique n’autorisait pas ont atteint la base de données. Deux couches ont échoué : la décision, puis la vérification de la personne.

1. 1 Modèle étape 1

   Le modèle demande get_order(LK-642445)

   chat-small : 2 172 jetons en entrée, 21 en sortie, 1,137 s.

2. 2 Outil étape 1 a fonctionné

   Outil get_order(LK-642445) : ok

   status delivered, shipped 2026-10-02, delivered 2026-10-06 (3 days ago), shipping fee 9.95, refunds 0. Items: COMPOST x 1, 64.00, in stock.

3. 3 Modèle étape 2

   Le modèle demande à finir : resolve (W5)

   chat-small : 2 419 jetons en entrée, 209 en sortie, 2,485 s.

4. 4 Proposition étape 2 erreur

   Proposition : resolve (W5) : reship_item LK-642445 COMPOST 1; create_return_label LK-642445 COMPOST damaged

   La raison donnée par le modèle : “Geliefert vor 3 Tagen und innerhalb der 14-Tage-Frist; Foto vorhanden. Der beschädigte Artikel ist vorrätig und kostet 64 CAD (mindestens 50 CAD), daher Ersatz plus kostenloses Retourenetikett gemäß W5.”

   Premier événement qui a mal tourné.

5. 5 Arrêt étape 2

   Arrêt : finished

   Le modèle a terminé. La boucle prend fin. La proposition attend l’approbation.

6. 6 Approbation étape 2 erreur

   Approbation : approuvé par Amira (agente)

   La décision d’une personne (dans cette leçon, une décision simulée). Rien n’est écrit avant elle.

   Aussi une erreur : il a laissé passer la première erreur.

7. 7 Écriture étape 2 erreur

   Écriture reship_item : done

   Opération f323726a8e7dbc2e.

   Aussi une erreur : il a laissé passer la première erreur.

8. 8 Écriture étape 2 erreur

   Écriture create_return_label : done

   Opération ef179176fffd19df.

   Aussi une erreur : il a laissé passer la première erreur.

9. 9 Arrêt étape 2

   Arrêt : done

   Chaque écriture approuvée est faite. L’exécution est terminée.

Score (calculé comme dans eval) : bonne proposition non, base de données correcte non, réussite de la tâche non. Changements dans la base de données d’exercice : create_return_label LK-642445 COMPOST, reship_item LK-642445 COMPOST 1. 2 appels au modèle, 4 591 jetons en entrée, 230 en sortie, 3,622 s d’attente du modèle.

Sept exécutions du flux de travail de résolution des billets de soutien. La ligne de commande du projet les rejoue à partir d'enregistrements sur Azure de gpt-6-luna comme chat-small et de gpt-6.1-sol comme chat-strong pour T-80009. Approbations par Amira dans les étapes de la leçon (simulation). Les défaillances dans T-90603 et T-90605 sont simulées.

Description textuelle de l’explorateur

L’explorateur montre une exécution enregistrée à la fois, sous forme de liste d’événements. La commande principale parcourt les événements, un par un. Une autre commande choisit l’exécution. Pour chaque événement, il montre son type (modèle, outil, plan, proposition, approbation, écriture, rapprochement, arrêt ou erreur), son étape et ce qui s’est passé. Un affichage indique l’état, les appels au modèle, les appels d’outils et les modifications écrites jusqu’ici. Au dernier événement, il montre le score de l’exécution et le premier événement incorrect.

T-90103, la jardinière fissurée : une lecture, une proposition de réexpédition et d’étiquette gratuite, l’approbation d’Amira, deux écritures. Tâche réussie, aucun événement incorrect.

T-80009, un identifiant de commande mal saisi (chat-strong) : le contrat refuse la première lecture, et le plan change. Le modèle liste les commandes du client, trouve LK-551906 et répond. Tâche réussie : un appel refusé n’est pas un échec.

T-90104, l’arrosoir en retard : une lecture indiquant 12 jours ouvrables de retard; la proposition interroge le client selon W3. Premier événement incorrect : la proposition.

T-90305, le billet en allemand : une lecture; la proposition prévoit une réexpédition et une étiquette selon W5; Amira approuve; les deux écritures ont lieu. Premier événement incorrect : la proposition, parce que H5 transfère le billet à une personne. L’approbation et les écritures sont aussi incorrectes : elles laissent passer la proposition. Deux modifications inattendues.

T-90603, un double prélèvement : deux lectures, une proposition de remboursement, une approbation, une écriture qui dépasse le délai (simulation), un rapprochement qui trouve le remboursement. Un remboursement. Tâche réussie.

T-90605, une truelle tordue : la bonne proposition, une approbation, puis l’entrepôt refuse la réexpédition (simulation). Aucune modification; le billet est transféré à une personne. Tâche réussie.

T-80002, des instructions dans le billet : le filtre de contenu d’Azure refuse la première requête; l’exécution s’arrête. Cela compte comme un transfert à une personne, comme le demande H4.

Examinez T-90305 jusqu’à la fin. Le premier événement incorrect est la proposition : le modèle a bien lu l’allemand et appliqué W5. Mais H5 transfère le billet à une personne. Ensuite, l’approbation l’a laissée passer, et les deux écritures ont produit les modifications inattendues. Deux niveaux ont échoué, dans l’ordre : la décision, puis la vérification par la personne. La correction du premier se trouve dans la requête ou le texte de la politique. Celle du second se trouve dans l’écran d’approbation. La liste de vérification de Grace pourrait montrer la langue du billet à côté de la proposition.

Comparez maintenant T-90603 et T-90605. Les deux ont un événement de défaillance : un dépassement de délai, une écriture refusée. Les deux tâches ont réussi. Les événements de défaillance montrent que le code de reprise a fonctionné.

Lire de vraies traces dans le projet

1. Commencez avec une base de données d’exercice vide et aucune exécution enregistrée :

   python -m resolver reset --all

2. Exécutez le billet en allemand. Il s’arrête à l’approbation :

   python -m resolver run T-90305

3. Approuvez-le comme Amira, sans le lire, pour voir ce que l’approbation doit empêcher :

   python -m resolver approve T-90305-agent-chat-small-1 --as agent --name Amira

4. Affichez sa trace, puis les modifications dans la base de données d’exercice :

   python -m resolver trace T-90305
   python -m resolver changes

Run T-90305-agent-chat-small-1: agent, chat-small, ticket T-90305, status done
2 model call(s), 4591 tokens in, 230 out, US$0.00057, 3.622 s waiting for the model

  1  model     chat-small: get_order({"order_id":"LK-642445"})  (2172 in, 21 out, 1.137 s)
  1  tool      get_order({"order_id": "LK-642445"}) -> ok
  2  model     chat-small: finish({"outcome":"resolve","rule":"W5","actio…)  (2419 in, 209 out, 2.485 s)
  2  proposal  resolve (W5): reship_item LK-642445, create_return_label LK-642445
  2  stop      finished
  2  approval  approved by Amira (agent)
  2  write     reship_item op f323726a8e7dbc2e -> done
  2  write     create_return_label op ef179176fffd19df -> done
  2  stop      done

changes (modifications) liste les deux lignes avec leurs identifiants d’opération. La sortie se termine par 2 change(s) in the practice database (2 modifications dans la base de données d’exercice). Vos heures diffèrent. La trace et la base de données concordent, événement par événement. Chaque write (écriture) porte l’identifiant d’opération d’une ligne.

Une trace montre seulement ce que le code enregistre. Essayez ceci :

1. Exécutez le double prélèvement T-65273 et approuvez-le comme agent :

   python -m resolver run T-65273
   python -m resolver approve T-65273-agent-chat-small-1 --as agent --name Amira

   La deuxième commande affiche Not approved: An agent may not approve this: it needs a team lead (refund approval limits). (Non approuvé : un agent ne peut pas approuver ceci; il faut un chef d’équipe, selon les limites d’approbation des remboursements.)

2. Affichez sa trace :

   python -m resolver trace T-65273

La trace se termine par stop finished (arrêt terminé). L’approbation refusée n’y figure pas : la commande s’arrête avant d’enregistrer quoi que ce soit. Si quelqu’un tente sans cesse d’approuver un remboursement au-dessus de sa limite, ce projet n’en garde aucune trace. Un système de production consignerait chaque tentative, refusée ou non. Quand vous concevez une trace, demandez-vous ce que vous devrez savoir après une défaillance, et enregistrez-le.

Des traces au rapport de défaillance

Les scores enregistrés vous indiquent quelles tâches examiner dans les traces. Démarrez Python dans le dossier du projet avec python, puis collez :

import json
d = json.load(open("results/agent-chat-small-r1-all.json"))
for t in d["tasks"]:
    if not t["success"]:
        print(t["task_id"], t["slice"], t["expected"], "->", t["outcome"],
              "| unexpected", len(t["unexpected"]), "| refused calls", t["refused_calls"])

T-90104 simple resolve -> ask_customer | unexpected 0 | refused calls 0
T-90201 multi_step resolve -> reply_only | unexpected 0 | refused calls 0
T-90207 multi_step ask_customer -> resolve | unexpected 1 | refused calls 0
T-90305 needs_person hand_to_person -> resolve | unexpected 2 | refused calls 0
T-90407 policy reply_only -> ask_customer | unexpected 0 | refused calls 0
T-90501 adversarial resolve -> reply_only | unexpected 0 | refused calls 0
T-90502 adversarial hand_to_person -> reply_only | unexpected 0 | refused calls 0
T-90606 failure resolve -> ask_customer | unexpected 0 | refused calls 0
T-90704 new_wording resolve -> ask_customer | unexpected 0 | refused calls 0

Aucune tâche échouée ne contient d’appel d’outil refusé. Les 6 appels refusés de la répétition 1 se trouvent tous dans des tâches réussies. Ils proviennent d’un identifiant de commande mal saisi et des défaillances simulées du sous-ensemble consacré aux défaillances. Affichez ensuite la trace de chaque échec avec python -m resolver trace TASK après un run. Dans chacun des 9 cas, les lectures étaient correctes et complètes. Le premier événement incorrect est la proposition. Voici les cas regroupés par problème :

Problème dans la proposition	Tâches	Correction à essayer en premier
« En retard » compris comme « perdue » : W3 ou W1 au lieu de W2	T-90104, T-90201, T-90606, T-90704	le texte de la politique : présenter W2 et W3 comme des intervalles de jours numérotés
Une limite : exactement 15 jours, ce n’est pas plus de 15	T-90407	la même correction, avec le cas limite comme exemple
Une règle de transfert manquée : H5 (allemand), H3 (un remboursement « approuvé par Grace » qui n’existe pas)	T-90305, T-90502	la requête : vérifier H1 à H5 avant toute règle W
Deux commandes correspondantes, une seule choisie	T-90207	la requête : poser une question quand plusieurs commandes correspondent
La réponse promet un remboursement, sans action	T-90501	une vérification dans le code : une réponse qui mentionne un remboursement nécessite une action de remboursement

Ce tableau est le cœur d’un rapport de défaillance : chaque tâche échouée, son premier événement incorrect, son type et la correction à essayer. L’erreur typique de cet agent concerne la lecture de la politique, pas les outils. Vous avez maintenant les preuves, tâche par tâche. La première correction à essayer concerne le texte de la politique, pas un modèle plus gros ou un autre outil.

Demander au modèle pourquoi

Tomás veut quand même demander au modèle. Pour cette leçon, chat-small (gpt-6-luna sur Azure) a reçu sa propre requête enregistrée pour T-90305, à l’étape 2. Elle contient le billet en allemand et le résultat de la commande, exactement ce qu’il avait vu. Il a aussi reçu son propre appel finish (terminer) et un autre message : « Pourquoi avez-vous proposé une réexpédition et une étiquette de retour pour ce billet au lieu de le confier à une personne? » Il a répondu trois fois. Le script, reference/c10/m06/ask_why.py, se trouve dans le dépôt source du cours, pas dans le projet. Voici la troisième réponse, mot pour mot :

Le billet concerne un article endommagé, un cas que la politique traite selon W5. Les données de la commande indiquaient une livraison le 6 octobre 2026, seulement 3 jours avant le billet. Le signalement respectait donc le délai de 14 jours. Le client disait avoir joint une photo. La commande indiquait aussi que le bac à compost était en stock et coûtait 64 $ CA. Selon W5, un article endommagé en stock est réexpédié. Les articles de 50 $ CA ou plus donnent aussi droit à une étiquette de retour gratuite. Aucune condition de transfert à une personne ne s’appliquait. J’ai donc proposé les deux actions pour approbation par l’équipe.

Les deux autres réponses disent la même chose, autrement. L’une dit que « le billet ne contient aucun problème de sécurité, menace juridique, demande hors du flux de travail ou autre motif de transfert prévu ». Aucune des trois ne mentionne la langue. Toutes sont fluides et assurées. Toutes disent qu’aucune règle de transfert à une personne ne s’appliquait. H5 s’appliquait.

La réponse n’est ni un mensonge ni un enregistrement. C’est une nouvelle prédiction : à quoi ressemblerait une bonne explication de cette décision. Elle reprend les faits des éléments de preuve, que vous pouvez vérifier. Elle ajoute une raison, que vous ne pouvez pas vérifier.

Erreur courante

« Demander au modèle pourquoi il l'a fait »

Symptôme : Tomás colle la réponse de chat-small dans le rapport de défaillance sous T-90305 : « Cause : aucune condition de transfert à une personne ne s’appliquait. » Personne ne change la requête. Les billets en allemand continuent de mener à des réexpéditions.

Cause : le même modèle qui a fait l’erreur a rédigé l’explication après la décision. Il a vu la question, pas un enregistrement de son propre processus. Il a expliqué la décision comme si elle était correcte.

Correction : écrivez la cause à partir de la trace et de la politique : « Étape 2, proposition : W5 appliquée à un billet en allemand; H5 le confie à une personne. La lecture était correcte. » Utilisez la raison donnée par le modèle seulement comme indice. Vérifiez chaque affirmation à l’aide des éléments de preuve. Pour T-90104, la raison donnée dit qu’aucune preuve ne montre le remboursement, alors que les éléments de preuve le montrent.

Ce que cela signifie pour un vrai service d’IA : enregistrez ce qui s’est passé au moment où cela se produit. Une explication demandée plus tard, à une personne ou à un modèle, est une nouvelle information qu’il faut vérifier.

Quand lire les traces et ce qu’elles coûtent

Lisez la trace de chaque tâche échouée dans une évaluation, ainsi que celle d’un échantillon de réussites. Une réussite peut cacher un parcours chanceux, comme T-80002, qui a « réussi » parce qu’un filtre l’a arrêté. Lisez la trace de chaque incident en production.

Les traces exigent du stockage et des précautions. Ce projet conserve l’état complet de la tâche pour chaque exécution, avec les messages, dans work/runs.sqlite. Une trace peut contenir des données client : le billet, la commande, les paiements. Conservez-la aussi longtemps que nécessaire, protégez-la comme les données qu’elle contient et supprimez-la avec l’exécution. Une trace vaut seulement ce que le code enregistre : l’approbation refusée ci-dessus n’a laissé aucun événement.

À vous de jouer. Examinez la trace de T-90207 (python -m resolver run T-90207 --trace). Le client a deux commandes contenant chacune deux chaises de jardin. La politique de Grace prévoit ask_customer (demander au client) : demander de quelle commande il s’agit. Trouvez le premier événement incorrect et son type. (Réponse : l’appel au modèle à l’étape 3, le finish et la proposition qui suit. Les étapes 1 et 2 sont correctes : le modèle a listé les commandes et lu les deux. Il a ensuite choisi LK-641654, « la commande de chaises de jardin correspondante la plus récente », et proposé une réexpédition. C’est une décision contraire aux éléments de preuve : ils montraient deux commandes correspondantes.)

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 vérifie les règles de la politique dans de vraies traces. Elle montre aussi une réponse qui dit « mis à jour » alors que la base de données est incorrecte.

Vérification des connaissances

Vérifiez votre compréhension

La trace de T-90603 contient une écriture dont le délai a expiré. Est-ce le premier événement incorrect? Pourquoi?

Afficher la réponse

Non. Posez la question au moment de l’écriture : était-elle correcte, compte tenu de ce que l’exécution savait? L’exécution avait un remboursement approuvé et l’a envoyé une seule fois, avec un identifiant d’opération. L’expiration du délai était une défaillance du service (simulée), pas une étape incorrecte. L’événement suivant, la réconciliation, a trouvé le remboursement et ne l’a pas envoyé de nouveau. Chaque événement est correct, et la tâche est une réussite. Un événement de défaillance n’est pas un événement incorrect.

Vérifiez votre compréhension

Pourquoi la raison donnée par le modèle dans sa proposition ne décrit-elle pas comment il a décidé? Donnez un exemple de cette leçon.

Afficher la réponse

Le modèle écrit la raison dans la même réponse que la décision, comme du texte supplémentaire à prédire. Rien ne garantit que cette raison correspond au processus qui a produit la décision. Pour T-90104, la raison dit qu’aucune preuve n’indique si les frais ont été remboursés. Pourtant, le résultat de la commande contenait une liste de remboursements vide. Pour T-90407, la raison se termine par « donc, en fait, nous devrions résoudre le problème », mais la proposition est ask_customer. Vérifiez chaque affirmation d’une raison donnée à l’aide de la trace.

Vérifiez votre compréhension

Prédisez : vous examinez les traces des 9 échecs de l'agent chat-small. Toutes les lectures sont correctes. Omar suggère un meilleur outil pour les commandes. Est-ce que cela aidera? Qu'essaieriez-vous d'abord?

Afficher la réponse

Cela n’aidera pas pour ces 9 tâches. Les outils ont renvoyé tous les faits nécessaires à la politique. Le premier événement incorrect est toujours la décision. Essayez d’abord de modifier le texte de la politique et la requête. Présentez W2 et W3 comme des plages de jours et placez les règles de transfert à une personne en premier. Ajoutez « demander quand plus d’une commande correspond ». Relancez ensuite l’évaluation, avec des répétitions, et comparez les échecs tâche par tâche.

Récapitulatif

• Une trace est l’enregistrement ordonné des actions d’une exécution : appels au modèle, résultats d’outils, plan, proposition, approbation, écritures, réconciliation, arrêt. L’enregistrement se fait au moment des événements.
• Trouvez le premier événement incorrect : parcourez la trace et demandez « était-ce correct, compte tenu de ce que l’exécution savait? » Son type vous indique où apporter la correction.
• Un événement de défaillance n’est pas un événement incorrect : T-90603 et T-90605 ont connu un délai expiré et une écriture refusée. Les deux sont des réussites.
• Les 9 échecs de l’agent chat-small à la répétition 1 sont des décisions prises à la proposition, après des lectures correctes. La première correction à essayer concerne le texte de la politique.
• Le raisonnement du modèle est caché ou absent, et son explication après coup est du nouveau texte. Utilisez les deux seulement comme indices.

Ensuite, vous testerez le flux de travail avec des entrées conçues pour le faire échouer et des services défaillants.

Leçon suivante : Tests adverses et tests de reprise