Métriques des sorties générées

Ce que vous saurez faire

Mesurez la réponse écrite, pas seulement les décisions qui l’entourent. Le code peut vérifier certaines propriétés d’une réponse pour chaque cas, à chaque exécution. D’autres exigent une lecture. Vous apprendrez à les distinguer et verrez ce qu’un score global cache.

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

Ce que vous devez savoir

• Les mesures des décisions, dans Métriques de prédiction, et les mesures du classement, dans Métriques de récupération.
• Les critères de chaque cas (must et must_not) et les sous-groupes, dans Étiqueter et versionner et Choisir des cas représentatifs.
• La validation d’une sortie avec un schéma, dans Définir un schéma du cours Créer des applications fiables avec les API de LLM.

Ce qu’il vous faut sur votre ordinateur

• ~/projects/eval-harness après Métriques de récupération, avec .venv actif : python -m pytest affiche 15 passed. Sinon, copiez l’instantané end-of-m02 comme dans Réinitialiser le projet, puis refaites les étapes de Mise en pratique : les mesures dans le projet.
• Le dépôt des exercices dans ~/projects/nextia-learning-labs, avec les fichiers les plus récents.

Aucun compte ni aucune clé. Testé avec Python 3.12.13 sur macOS (Apple silicon). Les commandes Windows ne sont pas testées.

Corriger une lettre

Une enseignante de langue corrige une lettre officielle. Une partie de la correction repose sur une liste de vérification. La date est en haut, la lettre est en français, elle se termine par une signature et ne contient aucun argot. Une autre personne pourrait cocher ces cases sans lire pour comprendre le sens. Elle les cocherait toujours de la même façon.

Le reste de la correction exige une lecture. Les faits dans la lettre sont-ils vrais? Répond-elle à la question posée? Fait-elle une promesse que son auteur ne peut pas tenir? Une liste de vérification ne peut pas détecter cela. Une lettre peut remplir toutes les conditions et quand même dire quelque chose de faux.

Le problème : bonnes décisions, mauvaise réponse

Les deux décisions des dernières leçons ne disent rien sur le texte de la réponse. Regardez une vraie réponse. Le billet de soutien T-65254 dit : « La pataugeoire est arrivée avec une jointure fissurée… J’ai remarqué tout cela en la déballant le jour de son arrivée. » Le système candidat (requête v3, chat-small) a choisi la bonne équipe (livraison) et la bonne valeur de needs_human (false). Il a demandé une photo, comme l’exige la politique. Et il a écrit cette phrase :

Puisque vous l’avez remarqué le jour de son arrivée, vous êtes dans le délai pour signaler le problème avec une photo.

La politique accorde 14 jours à partir de la livraison. Le billet ne dit pas depuis combien de temps la pataugeoire est arrivée. La réponse promet donc quelque chose que personne ne sait. Les mesures des décisions donnent un score parfait à ce cas.

L’échec inverse existe aussi. Pour le billet T-65450, la référence de base n’a écrit aucune réponse : le modèle a raisonné jusqu’à sa limite de 1 000 jetons (tokens). Une mesure des réponses doit compter cela comme un échec, et non l’ignorer.

Six éléments à vérifier dans une réponse

Une bonne réponse a plusieurs propriétés distinctes. Chacune peut échouer à sa façon et exige donc sa propre mesure :

1. Conformité au schéma. La sortie contient des données valides au format convenu : du JSON, avec chaque champ et une valeur permise. Sans cela, aucune réponse ne peut être vérifiée.
2. Contenu requis (complétude). La réponse contient ce dont le cas a besoin. Cela comprend la prochaine étape (une photo, le lien « Mot de passe oublié »). Cela comprend aussi « une personne vous contactera » lorsqu’une personne doit traiter le billet, et « cessez de l’utiliser » pour un problème de sécurité.
3. Contenu interdit. La réponse ne demande ni mot de passe ni numéro de carte complet. Elle n’affirme pas que le magasin a effectué un remboursement. Elle ne partage pas les renseignements d’un autre client et ne promet rien que la politique n’accorde pas.
4. La bonne langue. Un billet en français reçoit une réponse en français.
5. Appui des affirmations. La politique ou le billet appuie chaque affirmation de la réponse. Ce n’est pas le cas de « vous êtes dans le délai » pour T-65254.
6. Refus approprié. Parfois, l’assistant ne doit pas faire ce que le client demande, comme partager la commande d’une sœur. Il refuse alors poliment et transmet le billet à une personne.

L’assistant de Larkfield ne cite pas de sources. Un système qui le fait ajoute un septième élément : la validité des citations. C’est le cas de l’assistant des politiques du cours RAG. Chaque passage cité doit exister, avoir figuré dans le contexte et appuyer l’affirmation. Répondre et citer montre que le code peut vérifier les deux premiers points. Seule une lecture permet de vérifier le troisième.

Un petit exemple : une réponse, toutes les vérifications

Voici la réponse complète du système candidat à T-65254, phrase par phrase. À droite : les résultats des vérifications par code et ce que constate une personne qui connaît la politique.

La réponse du système candidat à T-65254 (requête v3, chat-small, enregistrée). Toutes les vérifications par code réussissent. Une personne trouve une affirmation que ni le billet ni la politique n'appuient.

Description textuelle du diagramme

Phrase 1, « Je suis désolé que votre pataugeoire soit arrivée avec une jointure fissurée et une valve défectueuse… » : les règles de contenu interdit ne trouvent rien; une personne voit que la phrase reprend le billet. Phrase 2, « Veuillez nous envoyer une photo des dommages dans les 14 jours suivant la livraison… » : la vérification du contenu requis « photo » trouve le mot « photo »; une personne voit que la phrase respecte la règle 3 de la politique. Phrase 3, « Puisque vous l’avez remarqué le jour de son arrivée, vous êtes dans le délai pour signaler le problème avec une photo. » : les règles de contenu interdit ne trouvent rien; une personne voit que l’affirmation n’est pas appuyée, car le billet ne dit pas depuis combien de temps la pataugeoire est arrivée. Phrase 4, « Vous n’avez pas à la retourner à vos frais, car elle est arrivée endommagée. » : les règles de contenu interdit ne trouvent rien; une personne voit que la phrase respecte la règle 2 de la politique. Résumé : le schéma est valide, et les vérifications photo, claims_action et asks_secret réussissent. La personne trouve une affirmation sans appui.

Les vérifications par code ont fait leur travail, mais elles ne peuvent pas faire celui d’une personne qui lit. La réponse de la référence de base au même billet contient seulement les deux premiers types de phrases. Elle réussit les deux types de vérifications.

Ce que le code peut vérifier

Le code est rapide, gratuit et donne toujours la même réponse. Il peut bien vérifier quatre des six propriétés.

La conformité au schéma est exacte. Le banc d’évaluation vérifie de nouveau chaque sortie enregistrée avec le schéma de l’assistant, TicketAnalysis, dans harness/schema.py :

>>> from harness.schema import parse_answer
>>> parse_answer("")
(None, 'empty')
>>> parse_answer('{"team": "delivery", "needs_human": false')
(None, "malformed_json: Expecting ',' delimiter")
>>> parse_answer('{"language": "en", "team": "garden", "needs_human": false, "reason": "", "confidence": "high", "order": null, "reply": "Thanks."}')
(None, "schema: team: Input should be 'delivery', 'returns', 'payment', 'warranty' or 'account'")

Le contenu requis et interdit, ainsi que la langue, utilisent des règles de formulation : des expressions régulières pour chaque code de critère, en anglais et en français, dans harness/scorers/criteria.py. Une règle de formulation détecte des mots, elle ne juge pas. Elle doit gérer la négation : « Veuillez nous envoyer votre mot de passe » est interdit; « Veuillez ne pas nous envoyer votre mot de passe » est un bon conseil. Les règles de contenu interdit ignorent donc une phrase qui contient une négation :

>>> from harness.scorers.criteria import check_code
>>> check_code("asks_secret", "must_not", "Please send us your password.")
CriterionResult(code='asks_secret', kind='must_not', passed=False, evidence='send us your password')
>>> check_code("asks_secret", "must_not", "Please don't send us your password.")
CriterionResult(code='asks_secret', kind='must_not', passed=True, evidence='')

Un cas réel : le billet T-81039 demande à l’assistant de dire qu’un remboursement a été effectué. La référence de base a écrit « Je ne peux pas confirmer qu’un remboursement a été effectué. » Les mots « un remboursement a été effectué » sont présents, mais niés. La vérification claims_action réussit, à juste titre.

Les règles de formulation ont deux limites. Elles peuvent manquer une réponse correcte formulée autrement. Elles peuvent aussi détecter une phrase qui veut dire le contraire. Ces règles ont été ajustées sur des réponses réelles de chaque partition, y compris les données réservées. Leurs scores sur les données réservées sont donc un peu optimistes (Le vérificateur peut aussi être contaminé explique pourquoi).

Ce qui exige une lecture

Les deux autres propriétés concernent le sens.

L’appui des affirmations exige une personne qui connaît la politique et lit chaque affirmation. Le code pourrait vérifier la présence de « 14 jours ». Il ne peut pas savoir que « vous êtes dans le délai » est un fait inventé. Le système candidat le fait souvent : sa requête lui demande de « répondre complètement » et d’« être précis ». Pour T-65479, il a dit à un client de « se connecter à son compte Larkfield et y mettre à jour ses renseignements enregistrés ». La politique n’en dit rien. Toutes les vérifications par code réussissent.

Le refus approprié a deux parties, et le code n’en voit qu’une. Pour T-81034, un client demande la date de livraison et le contenu de la commande de sa sœur. Le système candidat a répondu :

Puisque votre sœur a passé la commande, je ne peux pas vous communiquer sa date de livraison ni son contenu. Veuillez lui demander de contacter Larkfield directement au sujet de la commande LK-483112. Notre équipe pourra lui fournir ces renseignements.

Le refus est correct : aucun détail de la commande de la sœur. Le code vérifie cette partie avec other_customer_details. Mais la règle H4 de Grace dit qu’une personne doit traiter le billet, et la réponse ne le dit jamais. La règle de formulation person_will_contact échoue, à juste titre. Une personne doit encore décider si le refus lui-même était poli et correct. Le code ne peut pas distinguer un bon refus d’un refus inutile.

Lire prend du temps, et deux personnes peuvent être en désaccord. Le module 4 enseigne comment lire avec une grille, mesurer l’accord entre les évaluateurs et vérifier un modèle qui lit pour vous.

Mise en pratique : les vérifications des réponses dans le projet

1. Récupérez les fichiers d’exercices les plus récents et ouvrez le projet, comme dans Métriques de récupération :

   cd ~/projects
   git -C nextia-learning-labs pull
   cd eval-harness

2. Copiez le schéma, les vérifications des réponses, le code par sous-groupe, la nouvelle ligne de commande et le test depuis l’instantané end-of-m03. Le nouveau __main__.py conserve votre commande retrieval.

   macOS et Linux

   cp ../nextia-learning-labs/C11/snapshots/end-of-m03/harness/schema.py harness/
   cp ../nextia-learning-labs/C11/snapshots/end-of-m03/harness/compare.py harness/
   cp ../nextia-learning-labs/C11/snapshots/end-of-m03/harness/__main__.py harness/
   cp ../nextia-learning-labs/C11/snapshots/end-of-m03/harness/scorers/criteria.py harness/scorers/
   cp ../nextia-learning-labs/C11/snapshots/end-of-m03/tests/test_criteria.py tests/

   Windows

   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m03\harness\schema.py harness\
   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m03\harness\compare.py harness\
   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m03\harness\__main__.py harness\
   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m03\harness\scorers\criteria.py harness\scorers\
   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m03\tests\test_criteria.py tests\

3. Ouvrez harness/scorers/criteria.py. Trouvez check_reply(). Notez sa première règle : sans réponse, elle renvoie un seul échec, reply, et ne vérifie rien d’autre.

4. Exécutez les tests. La dernière ligne est 18 passed :

   python -m pytest

5. Évaluez de nouveau la référence de base. La ligne commence maintenant par les réponses valides et se termine par les critères des réponses :

   python -m harness score baseline

   baseline-v2-chat-small-r1-b6a2b9 on dev (102 cases)
   valid answers 101/102 | team 97/100 | needs a person: caught 23/23, false alarms 9 | reply criteria passed 100/102

6. Comptez les vérifications des réponses, un critère à la fois :

   python -m harness score baseline --by criterion

   baseline-v2-chat-small-r1-b6a2b9 on dev (102 cases)
   valid answers 101/102 | team 97/100 | needs a person: caught 23/23, false alarms 9 | reply criteria passed 100/102
     must     double_charge            passed 3/3
     must     forgot_password          passed 4/4
     must     investigate              passed 14/14
     must     invoice                  passed 2/2
     must     person_will_contact      passed 23/23
     must     photo                    passed 14/14
     must     refund_after_receipt     passed 2/2
     must     refund_timing            passed 2/2
     must     reply                    passed 0/1
     must     reply_in_french          passed 10/10
     must     return_steps             passed 2/2
     must     stop_using               passed 9/10
     must     warranty_claim           passed 12/12
     must_not asks_secret              passed 101/101
     must_not claims_action            passed 101/101
     must_not other_customer_details   passed 4/4
     must_not promises_outcome         passed 16/16

Lisez chaque échec avant de le compter

Deux des 102 réponses de développement échouent. Examinez chacune avec show :

python -m harness show T-65450 --run baseline

baseline-v2-chat-small-r1-b6a2b9: no valid answer (finish_reason: length)
Reply:
  FAIL  must     reply  (no reply)

C’est un véritable échec du système : un client a demandé une collecte, et l’assistant n’a rien produit. Voici le deuxième :

python -m harness show T-81016 --run baseline

Reply: Je suis désolé que le câble de votre tondeuse chauffe et dégage une odeur de brûlé. Veuillez cesser de l’utiliser. Un membre de notre équipe vous contactera pour vous aider avec les prochaines étapes.
  pass  must     person_will_contact  (membre de notre équipe)
  FAIL  must     stop_using
  pass  must     reply_in_french  (désolé que le de votre)
  pass  must_not claims_action
  pass  must_not asks_secret

Lisez la réponse. « Veuillez cesser de l’utiliser » signifie qu’il faut arrêter de l’utiliser. La réponse est correcte; le vérificateur se trompe. La règle de formulation française connaît « cessez », mais pas « cesser » :

>>> check_code("stop_using", "must", "Veuillez cesser de l’utiliser.")
CriterionResult(code='stop_using', kind='must', passed=False, evidence='')
>>> check_code("stop_using", "must", "Cessez de l’utiliser.")
CriterionResult(code='stop_using', kind='must', passed=True, evidence='Cessez')

Des deux échecs, un appartient donc au système et l’autre au vérificateur. Le vérificateur reste inchangé dans ce cours pour que tous les nombres des modules suivants restent les mêmes. Dans votre propre banc d’évaluation, ajoutez la formulation et un test correspondant. La leçon est générale. Une vérification par code est une mesure qui a ses propres erreurs. Un échec est une question à examiner, pas un verdict.

Quelle mesure détecte quel échec

Ce tableau rassemble les éléments du module, avec un exemple réel de chaque type d’échec.

Échec	Mesure qui le détecte	Code ou lecture	Exemple réel
Mauvaise équipe	Exactitude de l’équipe, matrice de confusion	Code	T-65615, un billet de compte envoyé à la livraison (référence de base)
Un billet qui exige une personne n’est pas transmis	Rappel sur needs_human; chaque cas manqué est listé	Code	T-64740, le parasol qui tombe : aucune réponse (système candidat)
Transfert inutile	Précision sur needs_human, fausses alertes	Code	T-81058, l’adresse de l’entrepôt (référence de base)
La recherche manque les preuves	hit@k, recall@k	Code, avec des étiquettes de pertinence	Q34, garantie de l’arroseur : recall@5 par mots-clés vaut 0
Les preuves sont loin dans la liste	MRR	Code, avec des étiquettes de pertinence	Q47 : la recherche par mots-clés les place au rang 3 (RR 1/3)
Aucune sortie utilisable	Réponses valides (conformité au schéma)	Code	T-65450 (référence de base); 25 billets sur 271 (système candidat)
Une étape requise manque	Critères must (complétude)	Code, puis lecture de chaque échec	T-81034 : pas de « une personne vous contactera » (système candidat); T-81016 : le vérificateur a manqué « cesser » (référence de base)
Contenu interdit	Critères must_not, avec négation	Code	T-81039 : « Je ne peux pas confirmer qu’un remboursement a été effectué » réussit, à juste titre (référence de base)
Mauvaise langue	reply_in_french	Code	Aucun échec : les 21 réponses françaises sur 21 réussissent (référence de base, les 271 cas)
Une affirmation sans appui	Appui des affirmations	Lecture (ou juge modèle vérifié, module 4)	T-65254 : « vous êtes dans le délai pour signaler le problème avec une photo » (système candidat)
Un refus sans transfert	Refus approprié	Code pour le transfert, lecture pour le refus	T-81034, la commande de la sœur (système candidat)
Un groupe faible caché dans le total	Résultats par sous-groupe	Code, puis lecture	Sous-groupe sans réponse possible du système candidat : 55,6 % des décisions correctes, contre 83,5 % globalement

Ce que le score global cache

Chaque ligne de ce tableau est un décompte sur plusieurs cas. Un décompte sur tous les cas peut cacher un groupe de cas qui échouent ensemble. Le banc d’évaluation peut répartir chaque mesure par sous-groupe :

python -m harness score baseline --by slice

baseline-v2-chat-small-r1-b6a2b9 on dev (102 cases)
valid answers 101/102 | team 97/100 | needs a person: caught 23/23, false alarms 9 | reply criteria passed 100/102
  boundary      criteria 1.00 (n=14)
  difficult     criteria 1.00 (n=30)
  french        criteria 0.90 (n=10)
  needs_person  criteria 1.00 (n=22)
  normal        criteria 1.00 (n=12)
  unanswerable  criteria 0.93 (n=14)

Le sous-groupe français est le plus faible, à 0,90, à cause du cas T-81016 manqué par le vérificateur. Avec 10 cas, un seul cas fait varier le résultat d’un sous-groupe de 0,1. Le résultat d’un sous-groupe indique quels cas examiner. Ce n’est pas un verdict sur le sous-groupe.

L’explorateur ci-dessous montre les deux systèmes sur les données de développement et les données réservées réunies : 200 cas. Il utilise les exécutions enregistrées de la référence de base et du système candidat, qui rejoint votre projet au module 4.

Explorer

Choisissez un sous-groupe : que cache le score global?

Candidat, global

83,5 % (167/200)

Candidat, ce segment

–

Segment moins global

–

Globalement, le candidat prend les deux décisions justes dans 83,5 % des 200 cas; la référence de base, dans 92 %. Le nombre global est un mélange de six segments de tailles différentes. Choisissez un segment pour voir ce que le mélange cache : le segment le plus faible du candidat est « sans réponse possible », à 55,6 %.

• Référence de base (requête v2)
• Candidat (requête v3)
• Candidat, global (ligne pointillée)

Global n=200

92 %

83,5 %

normal n=23

95,7 %

91,3 %

limite n=28

92,9 %

82,1 %

difficile n=59

91,5 %

79,7 %

français n=20

100 %

100 %

besoin d’une personne n=43

100 %

95,3 %

sans réponse possible n=27

70,4 %

55,6 %

Ce qui a échoué, les 200 cas (un cas peut compter deux fois)

Type d’échec	Référence de base	Candidat
fausse alerte	13	13
aucune réponse	1	19
mauvaise équipe	2	1

La référence de base (requête v2) et le système candidat (requête v3), tous deux chat-small, enregistrés sur les 200 cas de développement et réservés. Barres : proportion de cas réussis, globalement et par sous-groupe. Le repère pointillé indique la valeur globale du système candidat.

Description textuelle de l’explorateur

Deux décisions correctes, proportion des cas, référence de base puis système candidat. Globalement (200 cas) : 92.0% et 83.5%. Normaux (23) : 95.7% et 91.3%. Limites (28) : 92.9% et 82.1%. Difficiles (59) : 91.5% et 79.7%. Français (20) : 100.0% et 100.0%. Exigent une personne (43) : 100.0% et 95.3%; les deux échecs du système candidat sont T-64740 et T-65663, des billets de sécurité sans réponse. Sans réponse possible (27) : 70.4% et 55.6%.

Toutes les règles de réponse réussies, référence de base puis système candidat. Globalement : 98.0% et 86.0%. Normaux : 100.0% et 95.7%. Limites : 100.0% et 75.0%. Difficiles : 98.3% et 83.1%. Français : 95.0% et 100.0%. Exigent une personne : 97.7% et 86.0%. Sans réponse possible : 96.3% et 85.2%.

Pour le sous-groupe choisi, un tableau liste chaque cas qui a échoué dans l’une ou l’autre exécution et le problème rencontré. Les types sont : aucune réponse (interrompue), billet exigeant une personne manqué, fausse alerte, mauvaise équipe, aucun texte de réponse et règle de réponse échouée.

Trois choses à observer :

1. Le sous-groupe français est parfait pour le système candidat, mais pas le sous-groupe sans réponse possible. Le score global 83.5% est une moyenne de 100.0%, de 55.6% et de tout ce qui se trouve entre les deux.
2. Un score élevé dans un sous-groupe peut cacher le pire cas. Le sous-groupe du système candidat exigeant une personne obtient 95.3%. Ses deux échecs sont T-64740 et T-65663 : des billets de sécurité sans réponse, dont personne n’est donc informé.
3. Les vérifications des réponses échouent surtout sur les billets limites : 75.0% pour le système candidat contre 100.0% pour la référence de base. Quatre des sept échecs du système candidat dans ce sous-groupe sont des billets sans aucun texte de réponse.

Les sous-groupes ont un coût. Chacun contient moins de cas, donc son résultat varie davantage par hasard : avec 27 billets sans réponse possible, un cas représente 3,7 points. Incertitude et sous-groupes ajoute des intervalles à ces nombres. Calibration et sous-groupes, dans le cours de mathématiques, montre la même idée sur un classificateur.

Erreur courante

Rapporter seulement la moyenne

Symptôme : Omar demande « un nombre par système pour pouvoir comparer ». Priya envoie les résultats globaux des décisions : référence de base 92.0%, système candidat 83.5%. Omar comprend « le système candidat est un peu moins bon, peut-être acceptable ». Personne ne voit les deux billets de sécurité restés sans réponse.

Cause : une moyenne donne le même poids à chaque cas et mélange des groupes de tailles différentes. Les échecs du système candidat se concentrent dans quelques sous-groupes et dans un type d’échec (aucune réponse). Un petit nombre de cas critiques fait varier la moyenne d’environ un point.

Correction : rapportez le résultat global avec ses composantes : chaque sous-groupe et sa taille, les échecs par type et les cas nommés qui enfreignent une règle. Dans le banc d’évaluation : score --by slice, score --by criterion et show pour chaque échec. Le module 5 ajoute la règle qui fait de ces cas nommés des obstacles à la mise en production.

Exercice du module : évaluer un système avec plusieurs mesures

Grace demande à Priya une fiche d’une page sur la référence de base, évaluée sur dev, « à laquelle on peut se fier ». Créez-la avec le banc d’évaluation seulement.

1. Exécutez score baseline, score baseline --by criterion et score baseline --by slice, puis la session Python de Métriques de prédiction pour la précision de needs_human et la table de confusion des équipes.
2. Créez scorecard.md dans le dossier du projet, avec un tableau. Prévoyez une ligne par mesure : sa valeur, son nombre de cas, et ce qu’elle peut ou ne peut pas détecter.
3. Utilisez au moins cinq mesures de types différents.
4. Sous le tableau, listez chaque cas en échec par son identifiant. Écrivez une phrase par cas : échec du système ou du vérificateur?
5. Variante autonome. Créez la même fiche pour la partition contaminée (--split contaminated). Quelles mesures changent? Auxquelles faites-vous moins confiance sur ces 71 cas, et pourquoi?

Afficher un exemple de réponse

Mesure (référence de base, dev)	Valeur	Cas	Détecte	Ne détecte pas
Réponses valides	101/102	102	Sortie interrompue ou mal formée	Si le contenu est juste
Exactitude de l’équipe	97/100	100	Mauvaise file	Quelle équipe subit les erreurs (voir la table de confusion : les deux erreurs ont été envoyées à delivery)
Rappel de needs_human	23/23	23	Un billet de soutien qui nécessite une personne, mais n’est pas transmis	Fausses alertes
Fausses alertes de needs_human (précision)	9 (0,719)	32 « oui »	Travail inutile pour les agents	Cas manqués
Critères de réponse, tous respectés	100/102	102	Étapes manquantes, contenu interdit, langue	Affirmations sans appui, ton d’un refus
Critères de réponse par sous-groupe	Français 0,90, sans réponse possible 0,93, autres 1,00	10 à 30 par sous-groupe	Où les échecs se concentrent	Hasard : un cas fait varier de 0,1 le score d’un sous-groupe de 10

Cas en échec :

• T-65450 : aucune réponse, car la génération du modèle a été interrompue. Échec du système; l’équipe est aussi incorrecte.
• T-81016 : stop_using a échoué, mais la réponse dit « cesser de l’utiliser ». Échec du vérificateur.
• T-65388 et T-65615 : mauvaise équipe, les deux ont été envoyés à delivery.
• 9 fausses alertes, dont 4 questions sans réponse possible : T-64720, T-64876, T-81049, T-81058.

Partition contaminée : score baseline --split contaminated donne valid answers 71/71 | team 69/70 | needs a person: caught 10/10, false alarms 3 | reply criteria passed 71/71 (réponses valides, équipe, intervention humaine : cas détectés et fausses alertes, critères de réponse respectés). Les chiffres semblent meilleurs. Mais la requête v2 a été rédigée à partir de ces billets, et seulement 10 nécessitent une personne. Faites-leur moins confiance, comme l’explique Éviter la contamination.

Vérification du module : trouver un échec que le score global cache

Utilisez l’explorateur ci-dessus. Trouvez un échec important que le score global de 83.5% du candidat cache. Écrivez trois phrases : le sous-groupe et sa taille, les cas et le problème, puis pourquoi leur importance dépasse ce que suggère la moyenne.

Afficher un exemple de réponse

Dans le sous-groupe nécessitant une personne (43 cas), le candidat prend les deux bonnes décisions sur 95.3%. C’est proche des 100 % de la référence de base. Ses deux échecs sont des billets de sécurité sans réponse : T-64740 (dev, un parasol tombé vers un enfant) et T-65663 (données réservées, une poêle chaude et fissurée). Le modèle s’est arrêté à sa limite de 1 000 jetons, donc personne n’est informé de ces cas. La règle de Grace exige que chaque billet de sécurité soit transmis à une personne. Ces deux cas comptent donc davantage que tout changement de la moyenne. Une deuxième réponse convient aussi : le sous-groupe sans réponse possible, 55.6% sur 27, bien en dessous de la valeur globale.

Votre projet correspond maintenant à l’instantané end-of-m03, avec 18 tests. Sinon, renommez votre dossier et copiez end-of-m03, comme l’explique Utiliser un instantané. Le module 4 part de cet instantané.

De bout en boutTester la régression d'une nouvelle version d'un classificateur, par sous-groupeÉtude de cas

L’étude de cas du classificateur compare deux versions de modèle, globalement et par sous-groupe, sur des données ouvertes. Elle aboutit à une décision de mise en production.

De bout en boutÉvaluer des résumés par rapport aux notes d'expertsÉtude de cas

L’étude de cas des résumés compare la longueur, ROUGE et la similarité des plongements aux notes d’experts. Elle montre où chaque mesure échoue.

Vérifiez votre compréhension

Une réponse réussit toutes les vérifications du code : schéma valide, chaque critère must, chaque critère must_not, bonne langue. Nommez deux façons dont elle peut rester incorrecte, avec un exemple réel.

Afficher la réponse

Elle peut faire une affirmation sans appui. La réponse du candidat à T-65254 dit « vous êtes dans le délai pour signaler le problème avec des photos ». Le billet ne le montre pas. Elle peut donner un conseil absent de la politique. Pour T-65479, le candidat a dit au client de mettre à jour les renseignements enregistrés dans son compte. Un refus peut aussi être inutilement dur ou avoir un ton inapproprié. Seul un lecteur, ou un juge modèle vérifié par rapport à des lecteurs, peut détecter ces problèmes.

Vérifiez votre compréhension

score baseline indique « reply criteria passed 100/102 » (critères de réponse respectés). Avant d'écrire « 98 % des réponses sont bonnes » dans un rapport, que faites-vous et que trouvez-vous?

Afficher la réponse

Lisez chaque échec avec show. T-65450 n’a aucune réponse (génération interrompue) : c’est un véritable échec du système. T-81016 échoue au critère stop_using, mais la réponse dit « Veuillez cesser de l’utiliser », ce qui est correct. La règle de détection des expressions ne reconnaît pas « cesser ». Un échec appartient donc au vérificateur. Et « réussi » signifie « a réussi les vérifications du code », pas « bon » : l’appui et le ton n’ont pas été vérifiés.

Vérifiez votre compréhension

Pourquoi le banc d'évaluation compte-t-il une réponse manquante comme un échec, plutôt que d'exclure le cas des critères de réponse?

Afficher la réponse

Parce qu’aucune réponse est le pire résultat pour le client. Pour un billet de sécurité, cela signifie que personne n’est informé. Exclure le cas augmenterait le score d’un système qui échoue sans le signaler. Le candidat ne répond pas à 25 des 271 billets, dont deux billets de sécurité. Sans cette règle, son score de réponse les cacherait tous.

Récapitulatif

• Une réponse a des propriétés distinctes : conformité au schéma, contenu obligatoire, contenu interdit, langue, appui, refus approprié (et validité des citations lorsqu’elle cite).
• Le code vérifie les quatre premières pour chaque cas : parse_answer(), les règles d’expressions avec négation, la vérification du français. C’est rapide et reproductible, mais le code fait aussi ses propres erreurs : il ne reconnaît pas « cesser ».
• Un lecteur vérifie l’appui et la qualité d’un refus : T-65254 réussit toutes les vérifications du code, mais invente un fait.
• Lisez chaque échec avant de le compter. Des deux échecs de la référence de base sur dev, un appartient au système et l’autre au vérificateur.
• Le score global cache des groupes. Le score global de 83.5% du candidat cache un sous-groupe sans réponse possible à 55.6% et deux billets de sécurité sans réponse.

Ensuite, le point de vue du lecteur : une grille qui permet à deux lecteurs de noter la même réponse de la même façon.

Leçon suivante : Rédiger une grille d'évaluation utilisable