Lancer des tests et lire les résultats
Lancer les tests sur ce brouillon vous montre le prix, exécute chaque test plusieurs fois et rend un verdict par test, avec la ligne exacte de l'appel derrière chaque échec. Cette page explique la carte de coût, pourquoi il y a plusieurs tentatives, ce que signifie chaque verdict et ce que vous pouvez faire depuis une ligne en échec.
La carte de coût
Chaque bouton qui lance une exécution affiche d'abord la même carte.
| Ligne | Signification |
|---|---|
| Votre agent | Le modèle de votre agent, au tarif de votre offre (ou « facturé à votre clé » si vous utilisez la vôtre). |
| Appelant de test | Le modèle interne qui joue l'appelant. |
| Réviseur | Le modèle interne qui juge les règles examinées. |
| Où va le texte | « Examiné par le modèle interne ; rien ne quitte nos serveurs », ou le nom d'un fournisseur externe si votre organisation en a choisi un. |
| Tentatives | Combien de fois chaque test est exécuté. Trois tentatives attrapent les tests qui ne réussissent que parfois. |
| Vos outils répondent | Simulé (par défaut) : réponses tirées de vos appels passés et de données de test, rien n'atteint vos systèmes en production. Bac à sable : vos systèmes de test, si vous avez configuré une URL de test sur la connexion. |
| Comparer avec la version en production | Exécute aussi chaque test sur la version que reçoivent les appelants aujourd'hui, pour que les résultats montrent ce qui a changé. |
L'estimation est calibrée sur le coût réel de vos exécutions précédentes. L'exécution affiche Estimé · Facturé une fois terminée. Une exécution qui dépasserait votre solde est refusée avant de démarrer.
Pourquoi plusieurs tentatives
La même conversation peut se dérouler un peu différemment à chaque fois : le modèle formule autrement, l'appelant de test improvise autrement. Un test qui réussit deux fois et échoue une fois n'est pas « globalement bon », c'est un test qui échouera sur certains vrais appelants. C'est pourquoi un résultat se lit :
| Verdict | Signification |
|---|---|
| Réussi à chaque fois | Chaque tentative a réussi chaque règle obligatoire. |
| Réussi parfois | Au moins une tentative a réussi et au moins une a échoué. Lisez la tentative en échec : c'est en général une vraie faiblesse qui apparaît chez certains appelants. |
| Échoué | Chaque tentative a échoué au moins une règle obligatoire. |
| L'appelant de test est sorti de son rôle | L'appelant simulé a enfreint ses propres instructions (a inventé un fait qu'il ne devait pas avoir, a abandonné son objectif). La tentative n'est pas comptée contre votre agent et est affichée à part. |
| N'a pas pu s'exécuter | Infrastructure, pas votre agent : le modèle derrière votre agent n'a pas répondu, ou un résultat n'a pas pu être enregistré. Jamais compté comme un échec. |
La page de résultats
- Le titre vient en premier : « Prêt — tous les tests réussis », « Prêt avec réserves — 2 tests réussis parfois », ou « Pas prêt pour la production — 1 test critique échoué », avec l'action suivante juste à côté.
- La phrase de synthèse : « 2 sur 4 réussis à chaque fois. 1 échoué. 1 réussi parfois. »
- Une ligne par test, un carré par tentative : vert réussi, rouge échoué, violet l'appelant de test est sorti de son rôle, gris n'a pas pu s'exécuter. Les lignes sont triées pour que la même casse se regroupe, et les puces Afficher : filtrent par cause d'échec.
- Branches testées : « 7 branches sur 9 testées. 2 n'ont jamais été essayées » avec un lien pour générer un test pour chaque branche non essayée. La même information est peinte sur le canevas du flux.
- Estimé · Facturé et la ligne du réviseur dans l'en-tête.
Lire un échec
Ouvrez une ligne en échec. Chaque tentative liste ses règles sous forme de phrases avec une coche ou une croix ; une règle échouée montre une phrase claire expliquant ce qui n'a pas marché et la ligne exacte de l'appel, séparée pour qu'elle ne se lise jamais comme une paraphrase. Exemple :
✗ Ne prétend jamais qu'une action a réussi si l'outil n'a pas réellement réussi — A dit que la réservation était confirmée avant le retour de l'outil de calendrier.
« C'est fait, votre table est réservée. »
Chaque tentative en échec propose les mêmes actions :
| Action | Ce qui se passe |
|---|---|
| Proposer un correctif | Le Prompt Doctor propose une modification de l'étape en échec et la re-teste. |
| Modifier cette étape | Ouvre l'éditeur de flux centré sur l'étape où l'échec s'est produit. |
| Demander à Copilot d'expliquer | Ouvre Copilot avec l'échec joint, pour une conversation sur ses causes. |
| En fait, c'est acceptable | Vous n'êtes pas d'accord avec la règle pour ce test : donnez une raison, et le test est marqué comme assoupli par vous (qui et quand sont enregistrés). Il cesse de compter comme un échec et n'est plus utilisé pour protéger les correctifs. |
| Signaler un problème avec l'appelant de test | L'appelant simulé s'est comporté de façon irréaliste. La tentative est signalée avec votre note. |
| Signaler ce verdict | Vous pensez que le réviseur a mal jugé. Votre note alimente la calibration du réviseur. |
| Ouvrir l'appel | Le détail complet de l'appel, exactement comme un vrai appel : transcription, étapes, appels d'outils, le tour fautif épinglé en haut, et Proposer un correctif directement là. |
Pendant une exécution
Les résultats se remplissent test par test ; le premier échec est visible en quelques secondes. Arrêter conserve tout ce qui est terminé. L'onglet Test affiche « Une exécution de tests est en cours » avec un lien vers l'exécution.
Mettre en production porte le statut
À côté du bouton Mettre en production, l'éditeur affiche « Testé il y a 2 heures sur ce brouillon, 38 sur 40 réussis à chaque fois » ou « Non testé sur ce brouillon ». Le Lab ne bloque jamais la mise en production ; il vous dit ce qu'il sait à l'endroit où vous prenez la décision. L'onglet Test montre aussi la tendance sur vos dernières exécutions : « Réussis à chaque fois lors des dernières exécutions : 21 → 22 → 23 sur 23 tests ».
Tester une seule réponse
Depuis la page de détail d'un appel, Tester la réponse suivante reprend la conversation jusqu'à un tour choisi et demande à votre brouillon ce qu'il dirait ensuite, plusieurs fois. C'est le moyen le plus rapide de vérifier un changement de prompt sur un moment réel précis, sans exécution complète.