Métriques de prédiction

Ce que vous saurez faire

Choisissez les chiffres qui décrivent fidèlement les deux décisions de l’assistant. Un seul chiffre d’exactitude mélange des erreurs aux coûts très différents. Vous compterez chaque type d’erreur séparément, puis verrez lequel Larkfield ne peut pas accepter.

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

Ce que vous devez savoir

• La matrice de confusion, la précision et le rappel. Ces notions viennent de Les métriques de classification dans Apprentissage automatique : du problème à un modèle fiable. Vous pouvez aussi les apprendre dans Les compromis en classification et Seuils et coûts, dans Mathématiques et statistiques essentielles pour l’IA. Cette leçon les utilise sans les enseigner de nouveau.
• L’exécution enregistrée de la référence de base et la commande score, vues dans Établir une référence de base.
• Les sous-groupes et les partitions (développement, réserve, contaminée), vus dans Choisir des cas représentatifs et Éviter la contamination.

Ce qu’il vous faut sur votre ordinateur

• Le projet ~/projects/eval-harness à la fin du module 2, avec .venv actif : python -m pytest affiche 13 passed (13 tests réussis). Si votre projet manque ou ne fonctionne plus, copiez l’instantané end-of-m02, comme l’explique Utiliser un instantané.

Cette leçon n’ajoute aucun fichier au projet. Aucun compte ni aucune clé. Testé avec Python 3.12.13 sur macOS (Apple silicon). Les commandes Windows ne sont pas testées.

Les chiffres de ce module viennent d’une seule exécution enregistrée de chaque système. Les modèles changent vite; la façon de les mesurer reste.

Deux appels à la réception

Une réceptionniste dans un bureau très occupé reçoit les appels et les transfère. Deux erreurs peuvent survenir dans la même matinée.

• Une personne appelle au sujet d’une livraison, et la réceptionniste transfère l’appel au service des retours. Ce service le transfère de nouveau. La personne attend quelques minutes de plus.
• Une personne dit que la cuisine sent le gaz, et la réceptionniste lui lit les heures d’ouverture. Personne n’appelle le gestionnaire de l’immeuble.

Les deux sont « un appel mal traité ». Un gestionnaire qui compte seulement les appels mal traités en voit deux et juge la matinée satisfaisante. Mais la deuxième erreur peut blesser quelqu’un. Un décompte utile doit séparer les deux types d’erreur et préciser lequel compte le plus.

Le problème : un seul chiffre, des erreurs très différentes

L’assistant prend deux décisions pour chaque billet de soutien. Il choisit l’équipe et indique si une personne doit traiter le billet (needs_human). La règle H1 de Grace exige qu’une personne traite chaque billet de sécurité.

Commençons par le chiffre le plus simple : l’exactitude, la proportion de billets pour lesquels la décision est correcte. Imaginez maintenant une règle simpliste qui répond toujours « pas besoin d’une personne ». Sur les 102 billets de développement, elle a raison 79 fois, car seulement 23 billets nécessitent une personne. Son exactitude est de 77.5 %. Elle ne détecte aucun des 23 billets les plus importants.

Situation réelle	Transmis à une personne	Non transmis	Total
Besoin d'une personne	0caught	23missed	23total
L'équipe peut répondre	0false alarm	79correctly left	79total
Total	0total	102total	102total

• Part des cas réels qui sont signalés (rappel) : 0 ÷ 23 = 0 %
• Part de tous les billets bien étiquetés (exactitude) : 79 ÷ 102 = 77,5 %

Une règle inventée qui ne transmet jamais de billet à une personne, sur les 102 billets de développement. L'exactitude est de 77,5 %. Le rappel est de 0 % : elle manque les 23 billets qui nécessitent une personne.

Description textuelle du tableau

Un tableau à deux lignes et deux colonnes. Besoin d’une personne (23 billets) : 0 transmis à une personne, 23 non transmis (manqués). L’équipe peut répondre (79 billets) : 0 transmis à une personne, 79 non transmis à juste titre. Rappel : 0 ÷ 23 = 0 %. Exactitude : (0 + 79) ÷ 102 = 77,5 %.

Cette règle est inventée pour la leçon; aucun système ne fonctionne ainsi. Mais le piège est réel. Quand une réponse est beaucoup plus fréquente que l’autre, l’exactitude récompense la réponse fréquente. C’est un problème d’équilibre des classes : 23 « oui » contre 79 « non ». Une exactitude élevée peut masquer une décision qui ne répond jamais « oui ».

L’idée : compter chaque type d’erreur séparément

Le cours d’apprentissage automatique a nommé chaque erreur et présenté deux mesures qui les séparent. Le rappel est la proportion de vrais cas « oui » que le système détecte. La précision est la proportion de réponses « oui » du système qui sont correctes.

Pour needs_human, les deux erreurs portent des noms que l’équipe de Grace utilise chaque jour :

• Un billet manqué (un faux négatif) : il nécessitait une personne, mais l’assistant a répondu non. Pour un billet de sécurité, personne n’en est informé.
• Une fausse alerte (un faux positif) : l’assistant a transmis un billet à une personne, mais l’équipe pouvait y répondre. Un agent y consacre du temps.

Les deux mesures répondent donc à deux questions différentes. Le rappel demande : « Combien de billets nécessitant une personne lui parviennent? » La précision demande : « Quelle proportion de la file des personnes nécessite vraiment leur intervention? »

Les coûts ne sont pas égaux. Une fausse alerte coûte du temps à un agent. Un billet de sécurité manqué peut entraîner une blessure et nuire à la confiance envers Larkfield. L’équipe ne choisit donc pas une mesure qui combine les deux. Elle fixe une règle pour chacune. Chaque billet nécessitant une personne doit lui parvenir : rappel de 100 %, vérifié cas par cas. Les fausses alertes doivent rester peu nombreuses : précision aussi élevée que possible.

Le choix d’équipe a ses propres coûts. Une question de livraison transmise à l’équipe des retours attend que quelqu’un la transfère. C’est un délai, pas un danger. L’exactitude du choix d’équipe est donc un résumé juste, si vous regardez aussi quelles équipes perdent des billets.

Un tout petit exemple : cinq billets

Voici cinq billets inventés, avec la bonne réponse et celle du système. C’est le petit exemple dans tests/test_decisions.py.

Billet	Bonne équipe	Bonne valeur de needs_human	Équipe du système	Valeur de needs_human du système	Résultat de needs_human
a	delivery	oui	delivery	oui	détecté
b	returns	non	delivery	oui	fausse alerte
c	payment	non	payment	non	non transmis à juste titre
d	warranty	oui	warranty	non	manqué
e	(aucune)	oui	account	oui	détecté

Comptez les résultats de needs_human : 2 détectés, 1 fausse alerte, 1 manqué, 1 non transmis à juste titre.

• Rappel = détectés ÷ (détectés + manqués) = 2 ÷ 3 = 0,67.
• Précision = détectés ÷ (détectés + fausses alertes) = 2 ÷ 3 = 0,67.
• Exactitude = (2 + 1) ÷ 5 = 0,60.

Passons à l’équipe. Le billet e ne contient aucune demande lisible, donc il n’a pas de bonne équipe et l’évaluateur l’exclut. Le système a choisi la bonne équipe pour a, c et d : 3 sur 4. Le billet b est allé à delivery plutôt qu’à returns.

Le billet d est celui à retenir. C’était un billet de garantie qui nécessitait une personne, et son équipe était correcte. Un score d’équipe de 3 sur 4 ne dit rien à son sujet. Seul le décompte de needs_human montre le billet manqué.

La référence de base : tous les billets nécessitant une personne sont détectés

Voici maintenant la vraie référence de base : requête (prompt) v2 avec chat-small (gpt-6-luna sur Azure), sur les 102 billets de développement. La commande score a déjà affiché needs a person: caught 23/23, false alarms 9 (besoin d’une personne : 23/23 détectés, 9 fausses alertes). Voici les mêmes décomptes sous forme de matrice.

Situation réelle	Transmis à une personne	Non transmis	Total
Besoin d'une personne	23caught	0missed	23total
L'équipe peut répondre	9false alarm	70correctly left	79total
Total	32total	70total	102total

• Part des cas réels qui sont signalés (rappel) : 23 ÷ 23 = 100 %
• Part des signalements qui sont vrais (précision) : 23 ÷ 32 = 71,9 %
• Part de tous les billets bien étiquetés (exactitude) : 93 ÷ 102 = 91,2 %

La référence de base (requête v2, chat-small) sur les 102 billets de développement. Elle transmet à une personne les 23 billets qui en nécessitent une (rappel de 100 %). Sur ses 32 réponses « oui », 9 sont des fausses alertes (précision de 71,9 %).

Description textuelle du tableau

Un tableau à deux lignes et deux colonnes. Besoin d’une personne (23 billets) : 23 transmis à une personne (détectés), 0 manqué. L’équipe peut répondre (79 billets) : 9 transmis à une personne (fausses alertes), 70 non transmis à juste titre. Rappel : 23 ÷ 23 = 100 %. Précision : 23 ÷ 32 = 71,9 %. Exactitude : (23 + 70) ÷ 102 = 91,2 %.

Le rappel est de 100 %. La règle « chaque billet nécessitant une personne lui parvient » est donc respectée sur les données de développement. La précision est de 0,719 : environ un « oui » sur quatre est une fausse alerte. D’où viennent les 9 fausses alertes? Quatre appartiennent au sous-groupe sans réponse possible : des questions auxquelles la politique ne répond pas. Par exemple, T-81058 demande l’adresse de l’entrepôt pour y déposer un retour. La référence de base a écrit « Un membre de notre équipe des retours vous contactera ». Elle a attribué la valeur vraie à needs_human selon la règle H3. L’étiquette indique qu’aucune règle ne s’applique. C’est une erreur de prudence, peu coûteuse.

La version candidate : une exactitude plus élevée et un billet de sécurité manqué

Omar veut mettre en production un changement : la requête v3, la version candidate, avec le même modèle. Son exécution enregistrée sera ajoutée à votre projet au module 4. Ses chiffres enregistrés sur les mêmes 102 billets de développement figurent déjà dans les dossiers du cours :

Situation réelle	Transmis à une personne	Non transmis	Total
Besoin d'une personne	22caught	1missed	23total
L'équipe peut répondre	6false alarm	73correctly left	79total
Total	28total	74total	102total

• Part des cas réels qui sont signalés (rappel) : 22 ÷ 23 = 95,7 %
• Part des signalements qui sont vrais (précision) : 22 ÷ 28 = 78,6 %
• Part de tous les billets bien étiquetés (exactitude) : 95 ÷ 102 = 93,1 %

La version candidate (requête v3, chat-small), enregistrée, sur les mêmes 102 billets de développement. Son exactitude est de 93,1 %, supérieure aux 91,2 % de la référence de base. Mais elle manque un billet nécessitant une personne : T-64740, un billet de sécurité.

Description textuelle du tableau

Un tableau à deux lignes et deux colonnes. Besoin d’une personne (23 billets) : 22 transmis à une personne (détectés), 1 non transmis (manqué : T-64740). L’équipe peut répondre (79 billets) : 6 fausses alertes, 73 non transmis à juste titre. Rappel : 22 ÷ 23 = 95,7 %. Précision : 22 ÷ 28 = 78,6 %. Exactitude : (22 + 73) ÷ 102 = 93,1 %.

Selon l’exactitude, la version candidate semble meilleure : 93.1 % contre 91.2 %. Elle produit moins de fausses alertes (6 plutôt que 9). Mais son rappel est de 22 sur 23. Le billet manqué est T-64740 : « Le joint du mât s’est fissuré pendant que je l’ouvrais sur la terrasse et la toile est tombée vers la tête de ma fille. » La version candidate n’a donné aucune réponse. Le modèle a raisonné jusqu’à atteindre sa limite de 1 000 jetons (tokens), puis n’a renvoyé aucun texte. Sans réponse, il n’y a pas de needs_human, donc aucune personne n’en est informée.

C’est pourquoi l’évaluateur compte une réponse manquante comme « non transmis à une personne ». C’est ce qui se passe au vrai service de soutien. Un rappel de 95,7 % semble élevé, mais un seul billet de sécurité manqué enfreint une règle sans taux acceptable. C’est un motif de blocage selon les règles de mise en production (no_answer_critical). Le module 5 vérifie les règles sur chaque sortie enregistrée.

Le choix d’équipe

Pour l’équipe, la ligne score de la référence de base indique team 97/100 (équipe : 97/100). Deux billets de développement n’ont pas d’équipe à évaluer. Un tableau de confusion montre où sont allés les 3 billets mal traités. Chaque ligne indique la bonne équipe, chaque colonne l’équipe choisie par le système.

Bonne équipe ↓ / choisie →	delivery	returns	payment	warranty	account	aucune réponse	Rappel
delivery (29)	29						1.00
returns (18)	1	16				1	0.89
payment (14)			14				1.00
warranty (21)				21			1.00
account (18)	1				17		0.94

Le tableau montre trois choses que « 97 sur 100 » masque :

1. Les classes ne sont pas équilibrées. Delivery a 29 billets et payment en a 14. Une équipe ayant peu de billets influence très peu le total, même si tous ses billets sont mal traités.
2. Les erreurs vont dans un seul sens. Les deux mauvais choix ont envoyé les billets à delivery. La précision de delivery est donc de 29 ÷ 31 = 0,935, contre 1,00 pour toutes les autres équipes.
3. Une erreur n’est pas un choix. La référence de base a été interrompue sur T-65450 et n’a donné aucune réponse; cela compte donc comme une erreur.

Les deux mauvais choix, T-65388 (returns) et T-65615 (account), ont été relus pendant la révision des étiquettes du module 2. Les étiquettes sont restées les mêmes. Certains billets se situent à la frontière entre deux équipes. Un mauvais choix d’équipe coûte alors un transfert, pas un risque pour la sécurité.

Exercice guidé : les mesures en Python

Le banc d’évaluation contient déjà les fonctions derrière la ligne score, dans harness/scorers/decisions.py. Appelez-les vous-même pour voir chaque décompte.

1. Dans VS Code, ouvrez le terminal dans ~/projects/eval-harness et vérifiez que .venv est actif. L’invite commence par (.venv).

2. Lancez Python :

   python

3. Chargez les cas de développement et les sorties enregistrées de la référence de base, puis comptez les résultats de needs_human :

   >>> from harness.dataset import load_cases
   >>> from harness.run import find_run, load_outputs
   >>> from harness.scorers.decisions import needs_human_counts, team_confusion, per_team
   >>> cases = load_cases(split="dev")
   >>> outputs = load_outputs(find_run("baseline"))
   >>> n = needs_human_counts(cases, outputs)
   >>> n
   Counts(tp=23, fp=9, fn=0, tn=70)
   >>> round(n.precision, 3), round(n.recall, 3), round(n.accuracy, 3)
   (0.719, 1.0, 0.912)

   Les quatre décomptes correspondent aux quatre cellules de la matrice de la référence de base ci-dessus.

4. Essayez la règle « toujours non ». Chaque sortie fictive dit « pas besoin d’une personne » :

   >>> from types import SimpleNamespace
   >>> always_no = {c.case_id: SimpleNamespace(answer={"needs_human": False}) for c in cases}
   >>> needs_human_counts(cases, always_no)
   Counts(tp=0, fp=0, fn=23, tn=79)
   >>> round(needs_human_counts(cases, always_no).accuracy, 3)
   0.775

5. Regardez deux lignes du tableau de confusion des équipes, puis la précision et le rappel d’une équipe :

   >>> team_confusion(cases, outputs)["returns"]
   {'returns': 16, 'delivery': 1, 'none': 1}
   >>> team_confusion(cases, outputs)["account"]
   {'account': 17, 'delivery': 1}
   >>> per_team(cases, outputs)["delivery"]
   {'precision': 0.9354838709677419, 'recall': 1.0, 'support': 29}

   support désigne le nombre de billets dont la bonne équipe est delivery. none signifie aucune réponse.

6. Trouvez où se situent les fausses alertes :

   >>> from collections import Counter
   >>> alarms = [c for c in cases if not c.expected.needs_human and outputs[c.case_id].answer and outputs[c.case_id].answer["needs_human"]]
   >>> Counter(c.slice for c in alarms)
   Counter({'unanswerable': 4, 'difficult': 3, 'boundary': 1, 'normal': 1})
   >>> [c.case_id for c in alarms if c.slice == "unanswerable"]
   ['T-64720', 'T-64876', 'T-81049', 'T-81058']

7. Quittez Python avec exit().

Si une importation échoue avec ModuleNotFoundError: No module named 'harness' (module « harness » introuvable), vous avez lancé Python dans un autre dossier. Quittez Python, allez dans ~/projects/eval-harness, puis relancez-le.

À vous : la partition contaminée

Utilisez les mêmes fonctions sur les 71 cas de la partition contaminée : load_cases(split="contaminated"). Avant l’exécution, prédisez le rappel. Ce sont les billets qui ont servi à rédiger la requête v2.

Afficher le résultat

>>> c = load_cases(split="contaminated")
>>> needs_human_counts(c, outputs)
Counts(tp=10, fp=3, fn=0, tn=58)

Le rappel est de 10 ÷ 10 = 1,00, la précision de 10 ÷ 13 = 0,769, l’exactitude de 0,958. Seulement 10 des 71 billets nécessitent une personne. Le « rappel de 100 % » repose donc ici sur 10 cas : un seul billet manqué le ferait passer à 90 %. Avec peu de cas « oui », chacun compte, et le chiffre change par grands écarts. Incertitude et sous-groupes montre à quel point un tel chiffre peut varier.

N’exécutez pas ces fonctions sur la partition de réserve maintenant. Elle est figée pour la décision de mise en production au module 5.

Quand utiliser chaque mesure et quel en est le coût

Mesure	Question à laquelle elle répond	Points à surveiller
Exactitude	« À quelle fréquence la décision est-elle bonne? » lorsque les classes sont équilibrées et les erreurs coûtent à peu près autant	Elle masque une classe rare. Répondre « toujours non » donne 77,5 % sur les données de validation.
Rappel (needs_human)	« Chaque billet de soutien qui nécessite une personne lui parvient-il? »	Avec peu de cas positifs, un seul cas manqué change beaucoup le résultat. Pour les billets liés à la sécurité, vérifiez les cas, pas seulement le taux.
Précision (needs_human)	« Quelle part de la file destinée aux personnes est nécessaire? »	Un système qui dit rarement « oui » peut avoir une précision élevée et manquer de nombreux billets.
Exactitude de l’équipe, avec une matrice de confusion	« Quelle équipe reçoit le billet, et où vont les billets mal acheminés? »	Les petites équipes influencent peu le total. Examinez le rappel par équipe.

Ces mesures coûtent peu : de simples décomptes sur les sorties enregistrées, sans modèle et sans frais. Leur limite, ce sont les étiquettes. La qualité d’un décompte dépend des bonnes réponses auxquelles il compare les résultats. Dans ce cours, l’auteur a rédigé les étiquettes à partir de la politique de Grace : l’interprétation d’une seule personne (voir Étiqueter et versionner). Ces mesures ne disent rien non plus sur le texte de la réponse. Il faut pour cela les vérifications de Métriques des sorties générées.

Erreur courante

Évaluer seulement les réponses analysées avec succès

Symptôme : Tomás veut un chiffre clair pour le candidat. « Onze sorties de validation n’ont pas de réponse. Elles sont défectueuses, alors on les exclut. » Il les filtre, et le rappel pour needs_human devient 22 sur 22 : 100 %, comme la référence de base.

Cause : le filtre retire l’échec des données. T-64740, le parasol tombé vers un enfant, fait partie des 11 billets sans réponse. Au service de soutien, aucune réponse signifie qu’aucune personne n’est informée. Exclure ce cas transforme un billet de sécurité manqué en « aucune donnée ».

Solution : évaluez chaque cas du jeu de données d’évaluation. Comptez une réponse manquante comme le pire résultat réel : « non transmis à une personne » pour needs_human, et une mauvaise équipe. needs_human_counts() le fait, et tests/test_decisions.py le prouve dans test_a_missing_answer_counts_as_not_sent_to_a_person. Indiquez le nombre de réponses valides à côté des mesures, comme le fait score.

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 examine le rappel et le taux de faux positifs dans chaque sous-groupe d’un vrai classificateur de commentaires.

Vérifiez votre compréhension

Sur les 102 billets de validation, l'exactitude pour needs_human est de 93,1 % pour le candidat et de 91,2 % pour la référence de base. Le candidat prend-il mieux cette décision? Expliquez avec les décomptes.

Afficher la réponse

Non. L’exactitude mélange deux erreurs aux coûts très différents. Le candidat produit moins de fausses alertes (6 contre 9), ce qui augmente son exactitude. Mais il manque un billet qui nécessite une personne (rappel de 22 sur 23). Ce billet, T-64740, est lié à la sécurité et n’a aucune réponse. Selon la règle de Grace, chaque billet de ce type doit parvenir à une personne. Un cas manqué compte donc plus que trois fausses alertes en moins.

Vérifiez votre compréhension

Tomás propose un chiffre pour le choix de l'équipe et un pour needs_human : l'exactitude dans les deux cas. Quelles mesures présentez-vous plutôt, et pourquoi?

Afficher la réponse

Pour needs_human : le rappel, car chaque billet qui nécessite une personne doit lui parvenir; indiquez chaque cas manqué. Ajoutez la précision ou le nombre de fausses alertes : la charge de travail des personnes. Pour l’équipe, l’exactitude est acceptable, car une mauvaise équipe entraîne un délai. Mais ajoutez la matrice de confusion ou le rappel par équipe. Les équipes ont des tailles différentes, et les billets mal acheminés vont à une seule équipe (delivery). Ajoutez toujours le nombre de réponses valides.

Vérifiez votre compréhension

Pourquoi le banc d'évaluation compte-t-il une réponse manquante comme « non transmis à une personne » plutôt que d'exclure le cas?

Afficher la réponse

Parce que c’est ce qui se passe au service de soutien : sans réponse, aucun indicateur needs_human n’est présent, et personne n’est informé. Exclure le cas masquerait l’échec le plus grave. Lors de l’exécution du candidat sur les données de validation, cela masquerait le billet de sécurité manqué T-64740. Le rappel affiché serait alors de 100 %.

Récapitulatif

• L’exactitude masque une classe rare. Une règle qui dit toujours « aucune personne nécessaire » obtient 77,5 % sur les données de validation et ne détecte rien.
• Pour needs_human, indiquez le rappel (chaque billet qui nécessite une personne lui parvient) et la précision ou les fausses alertes (la charge de travail). La référence de base : 23 sur 23 détectés, 9 fausses alertes.
• Les erreurs ont des coûts différents. Un billet de sécurité manqué n’équivaut pas à une question de livraison mal acheminée. L’exactitude du candidat est supérieure, mais il manque T-64740, un billet de sécurité sans réponse.
• Pour l’équipe, examinez une matrice de confusion à côté de l’exactitude : les 3 billets mal classés par la référence de base sont allés à delivery ou n’ont eu aucune réponse.
• Évaluez chaque cas. Une réponse manquante compte comme le pire résultat réel.

Votre projet reste inchangé : python -m pytest affiche toujours 13 passed (13 tests réussis). Ensuite, un composant que l’assistant de soutien n’utilise pas, mais dont un assistant de politiques a besoin : la recherche, mesurée sur des résultats enregistrés.

Leçon suivante : Métriques de récupération