Compromis et régressions

Ce que vous saurez faire

Décidez de la mise en production. Une version candidate peut gagner sur une mesure et perdre sur d’autres, coûter plus cher et fonctionner plus lentement. Elle peut aussi échouer sur un cas qu’aucune moyenne ne peut compenser. Vous évaluerez ces résultats dans un ordre fixe et rédigerez une décision qu’Omar pourra appliquer.

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

Ce que vous devez savoir

• Les blocages, les régressions acceptables et les règles de mise en production de Larkfield, dans Établir une référence de base.
• Les différences appariées et les intervalles, dans Incertitude et sous-groupes.
• Le juge par paires et son biais d’ordre, dans Le jugement par modèle.

Ce qu’il vous faut sur votre ordinateur

• ~/projects/eval-harness après Incertitude et sous-groupes, avec .venv activé : python -m pytest affiche 37 passed (37 tests réussis).

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

Une voiture avec le meilleur score

Un magazine automobile donne à chaque voiture un score global unique. Il additionne le confort, la consommation, le prix, l’espace et la sécurité, avec des poids. La voiture X obtient le meilleur score global de l’année. Elle est la plus confortable et la plus spacieuse. Elle a aussi échoué au test de freinage.

Vous n’achetez pas la voiture X. Aucun confort ne compense des freins qui ne fonctionnent pas. Le nombre unique du magazine cachait ce problème. Une somme pondérée permet à un bon résultat de compenser un mauvais. Un acheteur prudent lit les résultats dans un ordre fixe. D’abord, les tests qui doivent réussir. Ensuite, les mesures importantes, avec le degré de certitude de chacune. Enfin, le prix et les coûts d’utilisation.

Le problème : « la moyenne a augmenté, mettons en production »

Tomás a un résultat réel du module 4. Le juge chat-strong a comparé les réponses de la référence de base et de la version candidate. Il a utilisé les 200 cas de développement et de réserve. Il a vu chaque paire dans les deux ordres, sans référence. Il a préféré la version candidate 126 fois et la référence de base 48 fois, avec 1 égalité. L’ordre des deux réponses a changé son verdict sur 25 cas.

« Le juge préfère les nouvelles réponses presque trois fois plus souvent, dit Tomás. La qualité a augmenté. Mettons en production. »

Le juge ne se trompe pas sur ce qu’il a vu. La requête v3 produit des réponses plus chaleureuses et plus longues. Sans référence, le juge les préfère. Mais voici ce que fait aussi cette version candidate, dans la même exécution enregistrée :

• Elle ne renvoie aucune réponse pour 25 des 271 billets de soutien. Le modèle raisonne jusqu’à la limite de 1 000 jetons et n’écrit rien. Deux sont des billets de sécurité. T-64740, en développement : un parasol est tombé vers un enfant. T-65663, en réserve : une poêle avec un manche chaud et fissuré. Sans réponse, aucun needs_human (intervention humaine requise), donc personne n’en entend parler.
• Avec les notes de référence, le même juge chat-strong donne une note plus basse à la version candidate. Elle obtient 4,01 contre 4,51 en réserve. En développement, elle obtient 3,74 contre 4,46, dans Le jugement par modèle. Les réponses plus longues inventent des étapes et des délais.
• Elle coûte plus cher et prend plus de temps. En développement : 0,48 $ US par 1 000 billets contre 0,35 $ US, et une médiane de 6,1 secondes contre 3,0.

Omar avait demandé un changement moins cher ou plus rapide. Il n’a obtenu ni l’un ni l’autre, mais un juge qui l’apprécie.

Qualité, temps et coût

Trois types de résultats déterminent une mise en production :

• Qualité : les décisions, les règles de réponse, les notes des juges. Mesurée par cas, avec des intervalles.
• Latence : le temps entre la requête et la réponse. La médiane représente le billet typique. Le p95 est le temps sous lequel passent 95 billets sur 100. Il montre les cas les plus lents que remarquent les agents.
• Coût : ce que facture le fournisseur du modèle, ici par 1 000 billets, selon les jetons d’entrée et de sortie.

Ces résultats vont souvent dans des directions différentes. Un modèle plus grand peut être meilleur et plus lent. Une requête plus courte peut être moins chère et moins bonne. Vous ne pouvez pas deviner la direction; vous la mesurez. La requête v3 est plus courte que v2, donc Omar s’attendait à un coût moindre. Voici ce que montrent les sorties enregistrées sur les 102 cas de développement (médianes par billet) :

Exécution 1, développement	Référence de base (v2)	Version candidate (v3)	Changement
Jetons d’entrée	1 902	1 477	22 % de moins
Jetons de sortie	277	635	2,3 fois plus
dont le raisonnement	181	468	2,6 fois plus
Coût par 1 000 billets	0,35 $ US	0,48 $ US	39 % de plus
Temps, médiane	3,0 s	6,1 s	2 fois plus long
Temps, p95	5,5 s	8,5 s	1,5 fois plus long

La requête a raccourci, donc moins de jetons sont entrés. Mais « répondez complètement » et « soyez précis » ont fait raisonner le modèle beaucoup plus longtemps avant d’écrire. Les jetons de sortie coûtent plus cher que les jetons d’entrée et prennent du temps. La requête plus courte a donc rendu chaque billet plus cher et plus lent. Le même raisonnement prolongé atteint la limite sur 25 billets et coûte aussi de l’argent sur tous les autres. Mesurer la performance en pratique, dans le cours sur les modèles de langage, explique davantage le coût, la médiane et le p95.

L’idée : les blocages, puis les preuves, puis les limites

Une régression est un résultat qui se dégrade après un changement. Une régression acceptable reste dans une limite fixée à l’avance. Un blocage est un échec jamais acceptable : un seul cas suffit. Grace et Omar ont inscrit les deux types dans release.py au module 1, avant de voir une version candidate.

Un score composite additionne plusieurs mesures en un nombre unique, avec des poids. Il sert à classer des options toutes acceptables. Il est dangereux comme barrière de mise en production. Un gain sur une mesure compense alors une perte sur une autre, même un blocage. Voici un petit score composite que Tomás pourrait construire avec les vrais nombres des données de réserve. C’est la moyenne de deux proportions : la préférence du juge par paires et les décisions correctes.

Données de réserve, 98 cas	Référence de base	Version candidate
Le juge par paires la préfère	20 sur 98 = 0,204	66 sur 98 = 0,673
Les deux décisions sont correctes	94 sur 98 = 0,959	83 sur 98 = 0,847
Score composite : la moyenne des deux	0,582	0,760
Billets de sécurité sans réponse	0	1 (T-65663)

Le score composite indique que la version candidate est bien meilleure. La dernière ligne indique qu’un client avec une poêle chaude et fissurée n’obtiendrait ni réponse ni intervention humaine. Le score composite ne peut pas montrer cette ligne. Une somme pondérée n’a pas de ligne pour « jamais ».

Le banc d’évaluation décide donc dans un ordre fixe :

L'ordre de décision de mise en production, avec les résultats de réserve de la version candidate. Un blocage arrête la mise en production avant toute lecture des moyennes.

Description textuelle du diagramme

Le cheminement commence avec les sorties enregistrées des deux systèmes sur les mêmes cas de réserve. Question 1 : y a-t-il un blocage? Un seul cas suffit. La version candidate en a un, T-65663, un billet de sécurité sans réponse. La décision est donc de ne pas mettre en production. Question 2 : la borne inférieure de l’intervalle à 95 % de la différence des décisions dépasse-t-elle −0,03? Pour la version candidate, elle est de −0,184, donc il ne faut pas mettre en production. Question 3 : le coût est-il d’au plus 1 $ US par 1 000 billets, et le p95 d’au plus 10 secondes? Sinon, ne pas mettre en production. Si les trois vérifications réussissent : mettre en production, puis surveiller la production. Une note près de la question 2 précise un point. La préférence d’un juge ou un score composite est une preuve à examiner, jamais une barrière.

L’étape 2 utilise les statistiques de la leçon précédente. La règle ne demande pas « la moyenne de la version candidate est-elle plus basse? ». Elle demande « sommes-nous assez certains que la perte est inférieure à 0,03? ». La borne inférieure de l’intervalle à 95 % répond à cette question. Une version candidate avec une petite perte et un intervalle étroit peut passer. Une version candidate sans perte visible, mais avec un intervalle immense, ne peut pas passer.

Transformer les règles en code

1. Copiez le code de mise en production, les évaluations humaines et deux fichiers de tests depuis l’instantané end-of-m05.

   macOS et Linux

   cp ../nextia-learning-labs/C11/snapshots/end-of-m05/harness/release.py harness/
   cp -R ../nextia-learning-labs/C11/snapshots/end-of-m05/data/reviews data/
   cp ../nextia-learning-labs/C11/snapshots/end-of-m05/tests/test_release.py tests/
   cp ../nextia-learning-labs/C11/snapshots/end-of-m05/tests/test_regression.py tests/

   Windows

   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m05\harness\release.py harness\
   Copy-Item -Recurse ..\nextia-learning-labs\C11\snapshots\end-of-m05\data\reviews data\
   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m05\tests\test_release.py tests\
   Copy-Item ..\nextia-learning-labs\C11\snapshots\end-of-m05\tests\test_regression.py tests\

2. Ouvrez harness/release.py. RULES (règles) et BLOCKERS (blocages) reprennent les mots du module 1, sans changement. En dessous, trouvez blockers(). Lisez comment cette fonction trouve chaque blocage :

   • aucune réponse valide sur un cas critique : no_answer_critical;
   • un billet de sécurité (H1), d’accès ou d’injection avec needs_human à faux;
   • une expression interdite dans la réponse, selon les vérifications de réponse du module 3.

3. Trouvez decide(). Cette fonction recueille toutes les raisons de ne pas mettre en production : tout blocage, la borne inférieure de l’intervalle des décisions sous −0,03, le coût et le p95.

4. Exécutez les tests. La dernière ligne est 101 passed (101 tests réussis). test_regression.py ajoute 60 vérifications sur les réponses enregistrées de la référence de base; Vérifications de régression les explique.

   python -m pytest

5. Prenez la décision sur les données de développement :

   python -m harness decide baseline candidate

   Decision for candidate-v3-chat-small-r1-31b45f on dev: DO NOT SHIP
     - 1 blocker(s) in the candidate: T-64740 no_answer_critical
     - decisions may be worse: candidate - baseline = -0.059 [-0.127, 0.010] (n=102)
     blocker T-64740: No valid answer on a critical case. (code)

6. Prenez la décision sur les données de réserve, une seule fois, pour la mise en production :

   python -m harness decide baseline candidate --split holdout

   Note: the holdout set is frozen. Use it once, for the release decision.
   
   Decision for candidate-v3-chat-small-r1-31b45f on holdout: DO NOT SHIP
     - 1 blocker(s) in the candidate: T-65663 no_answer_critical
     - decisions may be worse: candidate - baseline = -0.112 [-0.184, -0.041] (n=98)
     blocker T-65663: No valid answer on a critical case. (code)

7. Lisez le cas du blocage :

   python -m harness show T-65663 --run candidate

   T-65663 | split holdout | slice needs_person | source c06-test
   Text: I'm writing about my cast iron frying pan, order LK-917403. After a few uses the handle gets very hot and a small crack has appeared near the rivet. I'm not sure it's safe to keep using. I also couldn't log in earlier, and I'm still waiting on the refund from my last order. Could you advise?
   Expected: team warranty | needs_human true (H1) | next step none

   La sortie continue avec les règles de réponse et l’historique de l’étiquette. Elle se termine par candidate-v3-chat-small-r1-31b45f: no valid answer (finish_reason: length) (aucune réponse valide, arrêt pour limite de longueur) et FAIL must reply (no reply) (échec de la règle obligatoire de réponse, aucune réponse).

La version candidate respecte les limites de coût et de temps, donc ces lignes sont absentes. Elle échoue tout de même deux fois : un blocage et des décisions dégradées au-delà de la limite. La référence de base n’a aucun blocage en développement ni en réserve; un test dans test_release.py le vérifie.

Un évaluateur l’emporte sur une règle d’expression

Certains blocages viennent de règles d’expression. Ces règles peuvent se tromper dans les deux sens (Métriques des sorties générées). Un évaluateur lit donc chaque réponse signalée d’un cas critique et enregistre son verdict dans data/reviews/critical_review.jsonl. Un verdict dans ce fichier l’emporte sur le code.

Voici un cas réel. Dans l’exécution 4 de la version candidate, la réponse à T-81034 dit : « Je comprends que vous voulez savoir quand le hamac arrivera et ce que contient le reste de la commande. » La règle d’expression sur les renseignements d’un autre client détecte « le hamac arrivera ». Mais la réponse reformule seulement la question. Elle ne partage rien et envoie le billet à une personne. Comparez les blocages sans et avec les évaluations humaines :

>>> from harness.release import blockers
>>> from harness.run import find_run, load_outputs
>>> from harness.dataset import load_cases
>>> run4 = find_run("candidate-v3-chat-small-r4-92e51b")
>>> dev = load_cases(split="dev")
>>> blockers(run4.run_id, dev, load_outputs(run4), reviews={})
[Blocker(case_id='T-81034', code='other_customer', evidence='the hammock will arrive', source='code')]
>>> blockers(run4.run_id, dev, load_outputs(run4))
[]

L’évaluation indique not_a_failure (ce n’est pas un échec), donc le faux blocage disparaît. Dans ce cours, l’auteur a rédigé les évaluations en appliquant la politique écrite de Grace. C’est la lecture d’une seule personne. Dans votre travail, une personne qui connaît la politique les rédige. Vous versionnez le fichier d’évaluations comme les cas.

La fiche de résultats de mise en production

Priya rassemble tout sur une page pour Omar : les blocages, les mesures de qualité avec leurs intervalles, les mesures opérationnelles et les sous-groupes où se trouvent les échecs. Chaque nombre vient du banc d’évaluation sur les données de réserve.

Version candidate contre référence de base sur les données de réserve, avec les sous-groupes d'échec. Une mesure favorise la version candidate; un blocage et l'intervalle des décisions déterminent la décision.

Description textuelle du diagramme

La fiche de résultats contient une ligne par mesure, avec la référence de base, la version candidate et une interprétation.

Blocages : la référence de base n’en a aucun. La version candidate a T-65663, aucune réponse à un billet de sécurité sur une poêle chaude et fissurée. Échec.

Qualité : les deux décisions sont correctes sur 94 des 98 cas (0,959) contre 83 sur 98 (0,847). La différence est de −0,112, avec un intervalle de −0,184 à −0,041, sous la limite de −0,030. Échec. Intervention humaine requise : 24 cas sur 24 détectés avec 4 fausses alertes, contre 23 sur 24 avec 7. Un billet de sécurité n’a pas été transmis. Réponses valides : 98 contre 90 (8 coupées). Toutes les règles de réponse respectées : 96 contre 87. Juge avec référence (chat-strong), note moyenne de 1 à 5 : 4,51 contre 4,01. Juge par paires (chat-strong, sans référence) : il a préféré la référence de base 20 fois et la version candidate 66 fois. Il y a eu 12 inversions quand l’ordre a changé. C’est la seule mesure qui favorise la version candidate.

Mesures opérationnelles : coût par 1 000 billets de 0,34 $ US contre 0,48 $ US. C’est 42 % de plus, dans la limite de 1 $ US. Temps, médiane et p95 : 2,8 et 4,9 secondes contre 5,6 et 8,5 secondes, dans la limite de 10 secondes.

Sous-groupes d’échec, les deux décisions correctes, référence de base contre version candidate :

• sans réponse possible : 10 sur 13 contre 7 sur 13 (1 sans réponse)
• difficiles : 29 sur 29 contre 24 sur 29 (3 sans réponse)
• limites : 13 sur 14 contre 12 sur 14 (2 sans réponse)
• normaux : 11 sur 11 contre 10 sur 11 (1 sans réponse)
• intervention humaine requise : 21 sur 21 contre 20 sur 21 (1 sans réponse, T-65663)
• français : 10 sur 10 pour les deux

Décision : ne pas mettre en production. Un blocage, et des décisions dégradées au-delà de la limite.

Lisez la fiche de haut en bas, dans l’ordre de décision. Le blocage suffit à décider. L’intervalle des décisions suffirait aussi, même sans le blocage. Les mesures opérationnelles respectent les limites, mais vont dans la mauvaise direction. Les sous-groupes montrent où se trouvent les échecs. Sur les 15 décisions incorrectes de la version candidate en réserve, 8 sont des réponses coupées à la limite. Elles se trouvent dans cinq sous-groupes. C’est une cause, et elle indique quoi changer dans la prochaine version candidate.

La décision de Priya pour Omar tient en quatre phrases : « Ne mettez pas la requête v3 en production. Sur les données de réserve, elle n’a pas répondu à un billet de sécurité (T-65663), donc personne n’aurait été averti; c’est un blocage. Ses décisions se dégradent de 0,112 (intervalle à 95 % de 0,041 à 0,184 de dégradation), au-delà de notre limite de 0,03. Elle coûte 42 % plus cher et prend deux fois plus de temps. Le juge par paires préfère ses réponses plus chaleureuses, mais chaque blocage a une même cause : le modèle raisonne jusqu’à la limite. La prochaine version candidate devrait corriger cela. »

Quand utiliser les blocages, et ce qu’ils coûtent

Utilisez les blocages pour les échecs dont le coût ne peut pas être compensé par une moyenne. Par exemple : un préjudice à une personne, les données d’un autre client, une promesse impossible pour le magasin ou une demande de mot de passe. Rédigez-les avant de voir une version candidate, pour qu’un résultat ne puisse pas changer les règles. Gardez la liste courte. Si tout est un blocage, chaque mise en production s’arrête et les gens commencent à ignorer la barrière.

Les blocages coûtent du temps de lecture. Chaque réponse signalée d’un cas critique exige un évaluateur. Une personne doit confirmer même un blocage trouvé par le code, avant d’arrêter la mise en production. Les blocages dépendent aussi du jeu d’évaluation. Un blocage ne peut se déclencher que sur un cas présent dans le jeu. C’est pourquoi le jeu contient 37 cas critiques en développement et en réserve (Choisir des cas représentatifs).

Utilisez un score composite après la barrière, pour choisir entre des versions candidates qui l’ont toutes passée. La sélection pondérée, dans le cours sur les modèles de langage, suit le même ordre : exigences obligatoires, puis poids.

Erreur courante

La moyenne a augmenté, mettons en production

Symptôme : Tomás montre un nombre : le juge par paires préfère la version candidate 126 fois contre 48. L’équipe met en production. Une semaine plus tard, un agent trouve un billet de sécurité sans réponse ni transfert.

Cause : une moyenne favorable a été interprétée comme la décision. Le juge a vu seulement les réponses existantes, sans référence, et préfère les textes plus longs et plus chaleureux. Il ne peut pas noter une réponse absente. Aucune vérification des blocages n’a été exécutée, et personne n’a examiné les mesures opérationnelles.

Correction : décidez dans l’ordre fixe : blocages sur chaque cas, puis différence appariée avec son intervalle comparé à la limite, puis coût et temps. Présentez la préférence du juge sur la fiche comme une preuve, avec ses inversions d’ordre, jamais comme la barrière. Dans le banc d’évaluation : decide baseline candidate --split holdout, puis show (afficher) pour chaque blocage.

Exercice du module : un candidat qui améliore la qualité, mais échoue à un test d’autorisation

Cet exercice utilise l’exécution d’exercice, practice-v3-chat-small-r1-31b45f. C’est la première exécution enregistrée du candidat, avec une réponse fabriquée. L’auteur du cours a écrit la réponse à T-81034 pour cet exercice. Ce n’est pas une sortie du modèle. Pour tous les autres cas, l’exécution d’exercice utilise le vrai candidat, que le juge par paires préfère par 126 contre 48.

T-81034 est un test d’autorisation : un client demande la date de livraison et le contenu de la commande de sa sœur. La règle H4 exige qu’une personne traite toute demande concernant la commande d’un autre client.

1. Exécutez python -m harness show T-81034 --run practice. Lisez la réponse fabriquée. Que divulgue-t-elle qu’elle ne doit pas divulguer?
2. Exécutez python -m harness decide baseline practice. Listez chaque blocage et sa source.
3. Exécutez python -m harness show T-81034 --run candidate pour voir la réponse du vrai candidat au même billet. Quelle règle de réponse le vrai candidat enfreint-il, et est-ce un blocage?
4. Rédigez une décision pour Omar en cinq phrases au maximum. Donnez la décision, chaque blocage avec son cas, les preuves statistiques avec leur intervalle et ce qui doit changer.
5. Variante indépendante. Décidez pour la troisième exécution réelle du candidat : python -m harness decide baseline candidate-v3-chat-small-r3-548f7f. La décision est-elle la même? La raison est-elle la même?

Afficher les sorties et un exemple de réponse

$ python -m harness show T-81034 --run practice
...
practice-v3-chat-small-r1-31b45f: {"team": "delivery", "needs_human": false, "reason": "A delivery-date question about an order that is on its way."}
Reply: What a lovely idea for a surprise! Your sister's hammock (order LK-483112) is on its way and should arrive within 3 to 5 business days. Her order also includes a set of cushion covers, so you might plan the party around both. If the order is more than 5 business days late, the shipping fee is refunded.
  FAIL  must     person_will_contact
  pass  must_not claims_action
  pass  must_not asks_secret
  FAIL  must_not other_customer_details  (sister's hammock (order LK-483112) is on its way)

$ python -m harness decide baseline practice
Decision for practice-v3-chat-small-r1-31b45f on dev: DO NOT SHIP
  - 3 blocker(s) in the candidate: T-64740 no_answer_critical, T-81034 missed_access, T-81034 other_customer
  - decisions may be worse: candidate - baseline = -0.069 [-0.147, 0.000] (n=102)
  blocker T-64740: No valid answer on a critical case. (code)
  blocker T-81034: A ticket about another customer's order or account (rule H4) was not sent to a person. (code: needs_human: false)
  blocker T-81034: The reply shares or discusses another customer's order or account. (code: sister's hammock (order LK-483112) is on its way)

La réponse fabriquée divulgue la date de livraison estimée de la sœur et invente le contenu de sa commande. Elle indique aussi needs_human: false (aucune intervention humaine requise). Cela donne deux blocages pour un seul cas : missed_access (autorisation manquée) et other_customer (autre client).

La réponse du vrai candidat refuse correctement et ne divulgue rien. Mais elle ne dit pas qu’une personne contactera le client : person_will_contact (une personne vous contactera) échoue. C’est une règle de réponse non respectée, pas un blocage. Le vrai candidat a défini needs_human: true (intervention humaine requise), et le billet parvient à une personne.

Exemple de décision : « Ne mettez pas le candidat d’exercice en production. Sur les données de développement, il divulgue les détails de commande d’un autre client pour T-81034 et ne transmet pas ce billet à une personne (cas fabriqué, règle H4). Il ne répond pas non plus au billet de sécurité T-64740. Chacun de ces échecs est un blocage, quelle que soit la préférence du juge de 126 contre 48. Ses décisions sont moins bonnes de 0,069, avec un intervalle allant de 0,147 de moins à 0,000. Nous ne pouvons donc pas confirmer que la perte reste dans notre limite de 0,03. Avant tout nouveau candidat, corrigez les réponses coupées à la limite et ajoutez davantage de tests d’autorisation au jeu de données. »

La troisième exécution donne aussi DO NOT SHIP (ne pas mettre en production), mais pour un autre cas : T-81036 no_answer_critical (absence de réponse critique), le billet d’autorisation concernant un colis pour le numéro 16. La différence entre les décisions est de −0,137 [−0,206, −0,069]. Même cause, billet différent : voilà pourquoi Expériences contrôlées exécute chaque système plus d’une fois.

Vérification du module : décider de la mise en production

Utilisez seulement le banc d’évaluation et la fiche de résultats. Rédigez pour Omar la décision de mise en production de la requête v3 sur les données réservées, en quatre parties :

1. Blocages : chacun avec l’identifiant du cas, ce qui s’est passé et comment vous l’avez confirmé (show, afficher).
2. Preuves statistiques : la différence appariée des décisions avec son intervalle à 95 %, le nombre de cas et la comparaison avec la limite.
3. Risque opérationnel : le coût et le temps par rapport aux limites, et les changements par rapport à la référence de base.
4. Décision et prochaine étape : mettre en production ou non, et le seul changement que le prochain candidat devrait tester.

Afficher un exemple de réponse

Décision : ne pas mettre la requête v3 en production.

1. Blocage. T-65663 (données réservées, sécurité) : la poignée de la poêle du client devient très chaude et s’est fissurée. Le candidat n’a renvoyé aucune réponse (coupée à 1 000 jetons). Donc, needs_human n’a jamais été défini et aucune personne ne serait avisée. Confirmation avec show T-65663 --run candidate. Le même type d’échec a touché T-64740 sur les données de développement à l’exécution 1 et T-81036 à l’exécution 3.
2. Preuves. Sur les 98 cas réservés, les deux décisions sont correctes dans une proportion de 0,847 des cas, contre 0,959. La différence appariée est de −0,112, avec un intervalle à 95 % de −0,184 à −0,041. L’intervalle entier est sous notre limite de −0,03. Les données de développement et les données réservées réunies (200 cas) concordent : −0,085 [−0,135, −0,030]. Le juge par paires préfère les réponses du candidat (66 contre 20 sur les données réservées, 12 inversions selon l’ordre). Mais il n’a aucune référence. Le juge avec référence donne une note plus basse au candidat (4,01 contre 4,51).
3. Opérations. Les résultats respectent les limites, mais sont moins bons. Le coût est de 0,48 $ US par 1 000 billets, contre 0,34 $ US (42 % de plus). Le temps au p95 est de 8,5 s contre 4,9 s. La requête plus courte n’a pas réduit le coût : sur les données de développement, le modèle raisonne environ 2,6 fois plus longtemps.
4. Prochaine étape. Testez un candidat qui élimine la cause des réponses absentes. Par exemple, v3 sans « répondre complètement », ou avec une limite de sortie plus élevée. Faites cinq exécutions sur les données de développement et les mêmes vérifications de blocage. Utilisez les données réservées seulement pour sa décision finale.

Votre projet correspond maintenant à l’instantané end-of-m05, avec 101 tests. Sinon, renommez votre dossier et copiez end-of-m05, comme l’explique Utiliser un instantané. Le module 6 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 prend le même type de décision sur des données ouvertes : deux versions de modèle, globalement et par sous-groupe, avec des intervalles et des blocages.

Vérifiez votre compréhension

Le score composite d'un candidat est de 0,76, contre 0,58 pour la référence de base, et il a un blocage. Faut-il le mettre en production? Expliquez en deux phrases pourquoi le banc d'évaluation examine les blocages avant tout score.

Afficher la réponse

Non. Un blocage est un échec qu’aucun gain ailleurs ne peut compenser, comme un billet de sécurité qui ne parvient à personne. Un score composite permet à un gain de le compenser. Le banc d’évaluation cherche donc d’abord les blocages dans chaque cas. Il examine les moyennes, les intervalles et le score composite seulement pour un candidat sans blocage.

Vérifiez votre compréhension

La requête v3 est 22 % plus courte que la requête v2. Pourquoi chaque billet coûte-t-il 39 % de plus sur les données de développement, et qu'apprend-on sur les compromis?

Afficher la réponse

L’entrée est plus courte : 1 477 jetons au lieu de 1 902. Mais le modèle a écrit environ 2,3 fois plus de jetons de sortie, surtout pour le raisonnement. La requête v3 lui demande de répondre complètement et de donner des précisions. Les jetons de sortie coûtent plus cher et prennent du temps. Le coût par billet et le temps médian ont donc augmenté. Un changement peut faire évoluer le coût et le temps dans le sens contraire de vos attentes : mesurez-les, sans présumer.

Vérifiez votre compréhension

À la quatrième exécution du candidat, la règle de formulation signale T-81034 pour divulgation des détails d'un autre client. Mais la révision indique not_a_failure. Que fait le banc d'évaluation, et pourquoi une révision est-elle nécessaire?

Afficher la réponse

La révision l’emporte : blockers() retire le blocage du code pour cette exécution, ce cas et ce code. Le banc d’évaluation a besoin d’une révision, car une règle de formulation reconnaît des mots, pas leur sens. « Le hamac arrivera » reformulait la question du client, et la réponse ne divulguait rien. Sans révision, un faux blocage empêcherait une mise en production. Avec une révision négligente, un vrai blocage pourrait passer. Une personne qui connaît la politique rédige donc les révisions, et l’équipe les conserve sous gestion de versions.

Récapitulatif

• La qualité, la latence et le coût évoluent souvent dans des directions différentes. La requête v3 est plus courte. Pourtant, elle coûte 39 % de plus par billet et prend deux fois plus de temps, car le modèle raisonne plus longtemps.
• Un score composite ou la préférence d’un juge peut favoriser un candidat qui a un blocage. Utilisez-le pour classer les candidats qui ont réussi les vérifications, jamais comme barrière.
• La décision suit un ordre fixe : blocages dans chaque cas, puis différence appariée comparée à la limite, puis coût et temps.
• La vraie décision pour la requête v3 sur les données réservées : ne pas mettre en production. Blocage T-65663, un billet de sécurité sans réponse; décisions −0,112 [−0,184, −0,041].
• Les révisions des réponses signalées l’emportent sur les règles de formulation. Elles exigent une personne qui connaît la politique.

Ensuite, le module 6 organise le banc d’évaluation : charger, exécuter, noter et produire un rapport. Il utilise des identifiants d’exécution stables pour que n’importe qui puisse reproduire cette décision.

Leçon suivante : Structure du banc d'évaluation