Rétroaction de la production

Ce que vous saurez faire

Après la mise en production, le jeu d’évaluation ne voit plus rien de nouveau; la production, oui. Vous examinez un mois d’utilisation : pouces, modifications des agents, échantillon aléatoire à réviser et dérive. Vous apprenez ce que chaque signal révèle ou non. Vous ajoutez des cas au jeu sans toucher aux données réservées figées.

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

Ce que vous devez savoir

• Les niveaux d’évaluation, y compris la surveillance, dans Choisir les niveaux d’évaluation.
• Les sous-groupes et la couverture, dans Choisir des cas représentatifs; les versions et la version des entrées, dans Étiqueter et versionner; les données de développement et les données réservées, dans Éviter la contamination.

Ce qu’il vous faut sur votre ordinateur

• ~/projects/eval-harness après Vérifications de régression, avec .venv activé : python -m pytest affiche 103 passed, 1 deselected (103 tests réussis, 1 désélectionné).

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

Le journal de production est simulé

L’assistant de Larkfield n’a pas de vrais utilisateurs. Cette leçon utilise donc un journal simulé : un mois fictif de 1 270 billets de soutien. Un script l’a créé avec des effets connus, pour vous exercer à les trouver. Chaque ligne indique "simulated": true. Les nombres ci-dessous décrivent la simulation, pas de vrais clients.

Un nouveau plat après la soirée d’ouverture

Une cheffe teste un nouveau plat pendant des semaines avant de l’ajouter au menu. Puis le restaurant le sert, et de nouvelles preuves arrivent. Quelques clients remplissent des fiches de commentaires. Les clients mécontents écrivent plus souvent que les clients satisfaits. Les serveurs voient chaque assiette qui revient à moitié pleine. Chaque soir, la cheffe goûte aussi quelques plats choisis au hasard, pas seulement ceux qui ont reçu une plainte.

Après un mois, les clients commencent à demander quelque chose de nouveau : une plus petite portion pour les enfants. Elle ne figure pas sur la liste de dégustation, donc la cuisine ne l’a jamais testée. La cheffe l’ajoute aux plats qu’elle prépare pour s’exercer. Mais la dégustation standard qui décide si une nouvelle recette entre au menu reste la même. Sinon, on ne pourrait pas comparer les recettes de ce mois-ci à celles du mois dernier.

Le problème : des signaux qui induisent en erreur

Le candidat n’a pas été mis en production. Imaginez que la référence de base fonctionne maintenant en production depuis quatre semaines. Voici le mois simulé tel que l’équipe le voit, semaine par semaine.

Tomás lit les pouces : « Les clients ont donné de 30 à 43 pouces vers le bas sur 100 pouces. Hors ligne, la référence de base a pris les deux bonnes décisions pour 94 des 98 cas réservés. La production est bien pire que notre évaluation! » Omar lit la révision : « L’équipe de Priya a lu 40 billets au hasard ce mois-ci et n’a rien trouvé de nouveau. Tout va bien. »

Les deux se trompent, et le journal montre pourquoi. Pour le voir, vous devez savoir ce que chaque signal mesure.

L’idée : quatre signaux de production

La rétroaction de la production est ce que l’utilisation réelle du système vous apprend. Elle vient de quatre signaux, chacun avec ses limites :

1. Rétroaction des utilisateurs : pouces vers le haut ou le bas donnés par les clients. Peu coûteuse et rapide, mais peu de gens en donnent, et pas au hasard.
2. Modifications des agents : l’agent a-t-il modifié le brouillon avant de l’envoyer? Chaque brouillon est lu, donc chaque brouillon peut être modifié.
3. Révision d’échantillons : une personne lit un nombre fixe de billets choisis au hasard, avec la grille. C’est lent, mais sans biais lié aux personnes qui se plaignent.
4. Dérive : un changement dans les entrées, comme un nouveau sujet, davantage de billets en français ou des billets plus longs. Le mot signifie « s’éloigner lentement ».

Aucun de ces signaux ne fournit d’étiquettes. Un pouce vers le bas ne dit pas quelle règle a échoué. La production trouve donc des questions, et le jeu d’évaluation y répond.

Ajouter le journal et le code de rétroaction

1. Copiez le code de rétroaction, le journal simulé, son test et le README de fin de cours. Définissez d’abord S à nouveau si vous avez ouvert un nouveau terminal.

   macOS et Linux

   cp $S/harness/feedback.py harness/
   cp -R $S/data/production data/
   cp $S/tests/test_feedback.py tests/
   cp $S/README.md .

   Windows

   Copy-Item $S\harness\feedback.py harness\
   Copy-Item -Recurse $S\data\production data\
   Copy-Item $S\tests\test_feedback.py tests\
   Copy-Item $S\README.md .

2. Examinez une ligne du journal, data/production/feedback_log.jsonl :

   {"agent_edited": true, "day": "2026-11-02", "language": "en", "needs_human_changed": false, "simulated": true, "team": "warranty", "thumb": "none", "ticket": "P-00003", "topic": "warranty", "week": 1}

   Un billet : l’équipe choisie par l’assistant, la langue, les modifications de l’agent au brouillon ou à needs_human, le pouce du client et le sujet. Le texte du billet est absent : comme bien des tableaux de bord, le journal garde seulement ce qu’il compte.

3. Exécutez le résumé :

   python -m harness feedback

   La sortie :

   Production log (SIMULATED for the course; not real usage)
     tickets: 1270
     thumbs given: 181 (14.3%); up 113, down 68
     agent edit rate by week: {1: 0.184, 2: 0.207, 3: 0.19, 4: 0.239}
     thumbs-down share of thumbs by week: {1: 0.429, 2: 0.298, 3: 0.415, 4: 0.364}
     new topic (not in the evaluation set) by week: {1: 0.0, 2: 0.0, 3: 0.124, 4: 0.162}
     French share by week: {1: 0.06, 2: 0.049, 3: 0.042, 4: 0.091}

4. Exécutez les tests. La dernière ligne est 106 passed, 1 deselected (106 tests réussis, 1 désélectionné). test_feedback.py vérifie trois choses. Le journal est complet et simulé, le nouveau sujet apparaît en semaine 3, et l’échantillon de révision reste identique.

Votre projet correspond maintenant à l’instantané end-of-m06, la fin du projet du cours.

Pouces : qui choisit de cliquer

Seulement 181 des 1 270 clients ont donné un pouce : 14,3 %. Les 86 autres sur 100 n’ont rien dit. Les personnes qui cliquent ne forment pas un groupe aléatoire. Dans la simulation, comme dans la réalité, les clients mécontents cliquent plus souvent. La « part des pouces vers le bas » mesure donc surtout qui a choisi de cliquer, plutôt que la qualité des brouillons.

Les modifications des agents donnent un portrait plus juste, car un agent lit chaque brouillon. Voici la comparaison des pouces et des modifications, semaine par semaine.

• Pouces vers le bas, part des pouces
• Brouillons modifiés, part des billets

Journal simulé, 1 270 billets en 4 semaines. La part des pouces vers le bas oscille entre 30 % et 43 %; les agents modifient environ 1 brouillon sur 5, avec une hausse en semaine 4.

Description textuelle du graphique

Deux courbes sur les semaines 1 à 4. Pouces vers le bas, en part des pouces donnés : 42,9 %, 29,8 %, 41,5 %, 36,4 %. Brouillons modifiés par l’agent, en part de tous les billets : 18,4 %, 20,7 %, 19,0 %, 23,9 %. Chaque semaine compte entre 41 et 49 pouces et entre 306 et 331 billets.

Ce que cela nous dit. La courbe des pouces varie de 12 points d’une semaine à l’autre. Chaque semaine compte seulement 41 à 49 pouces, donc quelques clics la font beaucoup bouger. Elle se situe aussi bien au-dessus de la courbe des modifications, à environ deux fois sa hauteur. Cet écart vient surtout du biais : les clients mécontents cliquent plus souvent que les clients satisfaits. La courbe des modifications est plus stable, et elle monte en semaine 4. Cette hausse mérite un examen; les variations de la courbe des pouces, non.

Les deux signaux indiquent toutefois la même direction. Divisez le mois selon que l’agent a modifié le brouillon ou non :

Mois simulé	Billets	Pouces vers le haut	Pouces vers le bas	Aucun pouce
Brouillon modifié par l’agent	260	15	54	191
Brouillon envoyé tel quel	1 010	98	14	898

Les brouillons modifiés reçoivent beaucoup plus de pouces vers le bas. Un pouce vers le bas indique donc un billet qui mérite d’être lu. Il mesure mal la fréquence des erreurs de l’assistant. Cela répond à Tomás : la production n’est pas « bien pire que l’évaluation ». Il a comparé une part biaisée des clics à un taux portant sur tous les cas.

Modifications des agents : plus proches, mais pas des étiquettes

Un taux de modification d’environ 20 % signifie que les agents changent 1 brouillon sur 5. C’est utile, mais ce n’est pas un taux d’échec. Un agent modifie le style, un détail absent de la politique, ou le brouillon parce que le client a écrit à nouveau. Le journal compte aussi un signal plus fort : un agent a changé needs_human. Cela s’est produit pour 30 billets dans le mois. Chacun mérite d’être lu, car il s’agit d’une décision erronée de l’assistant.

Dérive : ce que le jeu ne contient pas

Passons aux entrées : les sujets des demandes des clients.

• Nouveau sujet : demandes liées à une baisse de prix
• Billets en français

Journal simulé. Un sujet absent du jeu d'évaluation apparaît en semaine 3 et augmente; les billets en français doublent presque en semaine 4.

Description textuelle du graphique

Deux courbes sur les semaines 1 à 4. Le nouveau sujet, les demandes liées à une baisse de prix : 0 %, 0 %, 12,4 % (38 billets sur 306), 16,2 % (50 sur 309). Billets en français : 6,0 %, 4,9 %, 4,2 %, 9,1 % (28 sur 309).

Ce que cela nous dit. En semaine 3, un nouveau type de billet apparaît. Des clients ont acheté un article avant un rabais et demandent le remboursement de la différence. En semaine 4, il représente 1 billet sur 6. Les données de développement du jeu d’évaluation ne contiennent aucun cas semblable. Les agents ont modifié 56,8 % de ces brouillons, contre 17,8 % pour les autres sujets. Les billets en français doublent aussi presque en semaine 4. Le sous-groupe français a bien réussi hors ligne, mais il compte seulement 10 cas de développement.

C’est la vraie nouvelle du mois, et les pouces ne l’ont pas montrée. Le jeu d’évaluation décrivait les billets du mois dernier. Il ne peut pas noter ce qu’il ne contient pas.

Révision d’échantillons : aléatoires et petits

Chaque semaine, une personne lit 10 billets choisis au hasard, avec la grille. Le banc d’évaluation les choisit avec une graine fixe, pour que chacun puisse voir quels billets ont été choisis. En Python :

from harness.feedback import load_log, review_sample

rows = load_log()
sample = review_sample(rows)
by_id = {r["ticket"]: r for r in rows}
print(len(sample), sum(by_id[t]["topic"] == "price_adjustment" for t in sample))

La sortie :

40 0

Quarante billets lus, sans aucune demande liée à une baisse de prix, malgré les 88 demandes des semaines 3 et 4. De la malchance? En partie. Avec 38 billets sur 306 en semaine 3, un échantillon aléatoire de 10 les manque tous environ 26 fois sur 100. Les manquer pendant les deux semaines arrive environ 4 fois sur 100. C’est peu probable, mais c’est arrivé.

Le constat d’Omar, « rien de nouveau dans 40 billets », est donc honnête, mais faible. Un échantillon aléatoire de 10 par semaine trouve les problèmes courants, sans biais lié aux personnes qui se plaignent. Il est trop petit pour détecter rapidement un nouveau sujet. Utilisez-le avec les autres signaux. Quand un décompte révèle un nouveau sujet, lisez volontairement tous les billets de ce sujet : ici, les 38 de la semaine 3.

La boucle d’évaluation

Les éléments du cours s’assemblent maintenant. Les vérifications hors ligne protègent chaque changement. La décision de mise en production utilise les données réservées une seule fois. La production révèle ce qui manque au jeu, et de nouveaux cas y ajoutent ces éléments.

La boucle d'évaluation, des tests hors ligne aux observations en production, puis au jeu d'évaluation.

Description textuelle du diagramme

La boucle compte six étapes. Les trois premières se déroulent hors ligne, sur des cas fixes et des sorties enregistrées.

1. Jeu d’évaluation : les données de développement s’enrichissent de nouveaux cas; les données réservées sont figées et jamais modifiées; chaque changement crée une nouvelle version du jeu de données.
2. Vérifications à chaque changement : pytest sur les sorties enregistrées, pour les fonctions, les règles de mise en production et un rapport qui se reconstruit à l’identique.
3. Décision de mise en production : le candidat contre la référence de base, avec les obstacles, les intervalles et le coût, sur les données réservées, une seule fois.

Si le candidat est mis en production, les trois étapes suivantes utilisent de vrais billets, sans étiquettes.

4. Production : l’assistant rédige des réponses, les agents les modifient et les envoient, et chaque billet est journalisé.
5. Observations, chaque semaine : une personne révise un échantillon aléatoire; modifications des agents et pouces, qui sont biaisés; dérive, comme de nouveaux sujets et langues.
6. Nouveaux cas : les observations révèlent un nouvel échec ou sujet. Une personne rédige et étiquette de nouveaux cas, et consigne qui et pourquoi. Les cas vont dans les données de développement, jamais dans les données réservées.

La boucle recommence ensuite à l’étape 1, avec une nouvelle version du jeu de données.

Ajouter de nouveaux cas de façon contrôlée

Le jeu doit intégrer les demandes liées à une baisse de prix. « De façon contrôlée » signifie quatre règles :

1. Une personne rédige et étiquette chaque cas, selon la politique de Grace, et consigne qui l’a étiqueté et comment. Le journal ne contient aucun texte; les cas reprennent donc le style des billets lus.
2. Les nouveaux cas vont dans les données de développement. L’équipe peut les lire et faire des ajustements à partir de ces cas.
3. Le jeu reçoit une nouvelle version, et ses règles restent respectées : aucun identifiant en double, aucun billet dans deux partitions.
4. Les données réservées ne changent pas. Leurs cas et leur version des entrées restent identiques.

Essayez avec un cas, sans modifier votre projet. Créez un fichier try_new_case.py dans le dossier du projet :

try_new_case.py

from pathlib import Path
from harness.dataset import check, inputs_version, load_cases, save_cases, version

cases = load_cases(split="all")
template = next(c for c in cases if c.case_id == "T-81029")   # a dev case: H3, a promise risk
new = template.model_copy(update={
    "case_id": "T-82001",
    "text": "I bought the teak bench for 649 dollars on 2 November. Your sale started a week later "
            "and now it costs 519. Can you refund me the difference?",
    "tags": ["refund_promise_risk", "price_adjustment"],
    "label": template.label.model_copy(update={
        "method": "written for the lesson after the simulated log showed price-drop requests; "
                  "Grace's policy applied by reading (H3)",
        "reviewed": "", "changed": ""}),
})
proposed = cases + [new]
check(proposed)                                   # the rules of the set still hold
save_cases(proposed, Path("../cases-proposed.jsonl"))
print("dataset version", version(), "->", version(Path("../cases-proposed.jsonl")))
for split in ("dev", "holdout"):
    old = [c for c in cases if c.split == split]
    now = [c for c in proposed if c.split == split]
    print(f"{split:8} {len(old)} -> {len(now)} cases | inputs version {inputs_version(old)} -> {inputs_version(now)}")

Le nouveau cas copie la structure de T-81029, un cas de développement où le client demande de l’argent non prévu par la politique. Le remboursement après une baisse de prix n’y figure pas. La règle H3 s’applique donc : une personne traite la demande, et la réponse ne doit pas promettre le remboursement. Exécutez-le avec python try_new_case.py :

dataset version d4c96eaa10c0 -> 1fbe6b1438d4
dev      102 -> 103 cases | inputs version 9b24fa392841 -> 30d3563a9d90
holdout  98 -> 98 cases | inputs version 1be23cc44ea9 -> 1be23cc44ea9

Le jeu proposé a une nouvelle version. Les données de développement ont un cas supplémentaire et une nouvelle version des entrées. Les exécutions enregistrées ne les couvrent donc plus. La référence de base doit répondre à T-82001 avant toute comparaison sur ce cas. La version des entrées des données réservées reste identique. Tous les résultats sur les données réservées de ce cours restent donc valides.

Le fichier ../cases-proposed.jsonl est à l’extérieur de votre projet, et data/cases.jsonl n’a pas changé. Supprimez try_new_case.py quand vous avez terminé. Dans une vraie équipe, le fichier proposé passe par une révision, comme le code. Grace ou une deuxième personne vérifie chaque étiquette. L’équipe enregistre ensuite la référence de base sur les nouveaux cas (Établir une référence de base).

Des cadriciels le font pour vous (facultatif)

Plusieurs outils libres et payants recueillent des traces de production et en échantillonnent pour la révision. Ils transforment ensuite une trace révisée en cas de test en un clic. Ils sont utiles quand le volume devient important. Ils suivent les mêmes étapes que cette leçon : journaliser, échantillonner, réviser, ajouter à un jeu versionné. Si vous en utilisez un, vérifiez qu’il garde des données réservées figées à part des cas qu’il ajoute. Vérifiez aussi que chaque cas indique qui l’a étiqueté. Ce cours n’utilise aucun cadriciel, pour que vous voyiez chaque étape.

Quand utiliser chaque signal, et à quel coût

Signal	À utiliser pour	À ne pas utiliser pour	Coût
Pouces	Repérer les billets qui méritent d’être lus	Un taux de mauvaises réponses	Gratuit; peu de gens cliquent
Modifications des agents	Une tendance stable sur tous les billets	Une étiquette : une modification n’est pas toujours un échec	Gratuit si l’outil les journalise
Modification de needs_human	Les décisions erronées, une par une	Les problèmes de style	Gratuit; lire chaque billet
Révision aléatoire	Une estimation sans biais des problèmes courants	Les problèmes rares ou nouveaux	Le temps d’une personne, chaque semaine
Décomptes de dérive	Les nouveaux sujets et langues	Juger la qualité des réponses	Un champ de sujet ou de langue

Chaque signal répond à une question. Ensemble, ils indiquent où lire, puis le jeu d’évaluation mesure le problème.

Erreur courante

Les données réservées s'enrichissent avec la production

Symptôme : Tomás ajoute les 10 meilleurs billets de baisse de prix aux données réservées : « Le test de mise en production doit couvrir le nouveau sujet. » Le prochain rapport de mise en production indique que le candidat réussit mieux sur les données réservées que la référence de base du mois dernier.

Cause : les données réservées ont changé, donc les deux rapports comparent des cas différents. Pire, l’équipe a rédigé ces billets et en a discuté pendant qu’elle modifiait la requête. Les données réservées ne sont plus inédites. Le banc d’évaluation refuse une forme de ce problème : un texte déjà présent dans une autre partition. Par exemple, si Tomás copie T-81028, le billet d’égalisation de prix des données réservées, dans les données de développement :

harness.dataset.DatasetProblem: T-82002: the same text is in holdout (T-81028) and dev

Mais aucun code ne peut empêcher une personne de modifier volontairement les données réservées.

Correction : les nouveaux cas vont dans les données de développement. Si les données réservées doivent couvrir un nouveau sujet, créez volontairement une nouvelle version des données réservées. Faites-le avant tout ajustement à partir de ces billets, et enregistrez les deux systèmes sur cette version. Nommez la version des données réservées dans chaque rapport. Ne comparez jamais des rapports utilisant des versions différentes des données réservées.

Exercice du module : livrer le banc d’évaluation et son rapport

Cet exercice rassemble les éléments du module. Livrez le banc d’évaluation et le rapport de mise en production comme si vous les remettiez à Omar.

1. Assurez-vous que votre projet correspond à l’instantané end-of-m06. Sur macOS et Linux, diff -r -x .venv -x __pycache__ -x .pytest_cache -x report.md $S . affiche seulement des lignes Only in .: (seulement dans .) pour vos propres fichiers, comme rate.py et notes. python -m pytest affiche 106 passed, 1 deselected (106 tests réussis, 1 désélectionné).
2. Écrivez le rapport de mise en production sur les données réservées dans report-holdout.md.
3. Rédigez HANDOFF.md avec cinq courtes sections :
   • comment préparer l’environnement et exécuter les tests;
   • comment recréer le rapport, avec son SHA-256;
   • les identifiants d’exécution et les versions du jeu de données et des entrées qu’il utilise;
   • le plan de test : quoi exécuter et quand;
   • les signaux de production à surveiller et qui les lit chaque semaine.
4. Variante autonome : écrivez un deuxième rapport, report-practice.md, pour comparer baseline à practice. Quels blocages indique-t-il? Précisez dans HANDOFF.md que l’exécution d’exercice contient une réponse fabriquée.

Afficher un exemple de réponse

report-holdout.md est le fichier de Structure du banc d’évaluation : Ne pas mettre en production, blocage T-65663, décisions −0,112 [−0,184, −0,041].

Le rapport d’exercice, sur dev (par défaut), indique trois blocages : T-64740 no_answer_critical (absence de réponse critique), et T-81034 missed_access (accès manqué) et other_customer (autre client). Les deux blocages de T-81034 viennent de la réponse fabriquée.

Un court HANDOFF.md :

## Set up and test
python 3.12, python -m venv .venv, pip install -r requirements.txt; python -m pytest -> 106 passed, 1 deselected.
## Rebuild the report
python -m harness report baseline candidate --split holdout --out report-holdout.md
SHA-256 on macOS: d65dee9596dbf0b48aa17fc3e740e5199a554f55d272691a98544ae53764bb46
## Runs and versions
baseline-v2-chat-small-r1-b6a2b9, candidate-v3-chat-small-r1-31b45f; dataset d4c96eaa10c0, inputs 3f90ab808275.
practice-v3-chat-small-r1-31b45f: candidate run 1 with ONE CONSTRUCTED reply (T-81034). Practice only.
## Test plan
Every change: pytest. Before a release: record the candidate, 5 dev runs, decide and report on holdout once,
a person reads every blocker. pytest -m live when the provider or the model version changes.
## Production
Weekly: agent edit rate, changed needs_human (read each), drift by topic and language, 10 random tickets
read with the rubric. Thumbs only as pointers. New cases: to dev, labelled, new version; holdout frozen.

Vérification du module : reproduire le rapport et retracer chaque score

Montrez à un évaluateur que le rapport constitue une preuve, pas une affirmation.

1. Dans une nouvelle copie de l’instantané end-of-m06, avec un nouvel environnement .venv, recréez le rapport sur les données réservées. Comparez son SHA-256 au vôtre.
2. Pour chaque nombre du tableau Mesures du rapport (référence de base, candidat, meilleur et pire), listez les cas correspondants avec per_case(). Montrez que les totaux concordent.
3. Pour le blocage et deux cas de votre choix, affichez la sortie enregistrée avec show CASE --run RUN_ID. Dites si vous êtes d’accord avec le score.

Afficher le contenu d’une réponse complète

1. Le même SHA-256 dans les deux copies (sur macOS, d65dee95…64bb46).
2. Décisions : 94 et 83 sur 98; 12 cas pires et 1 meilleur (T-81052), donc 94 − 12 + 1 = 83. Critères : 96 et 87 sur 98; 11 pires et 2 meilleurs (T-64860, T-81022), donc 96 − 11 + 2 = 87. Chaque liste est affichée par per_case().
3. T-65663 : aucune réponse à un billet de soutien concernant la sécurité, un véritable blocage. Par exemple, T-64815 (critères pires) : la règle de formulation refund_after_receipt (remboursement après réception) ne reconnaît pas « confirmer d’abord la réception ». Un lecteur accepterait la réponse; le score vient donc d’une erreur du vérificateur. Une réponse complète indique au moins un désaccord de ce genre et explique ce qu’il change. Ici, l’écart des critères est un peu trop grand, et la décision ne change pas.

Vérification des connaissances

Vérifiez votre compréhension

Pendant le mois simulé, 36 % à 43 % des votes sont négatifs durant trois des quatre semaines. Pourtant, les agents modifient seulement environ 20 % des brouillons. Pourquoi ces deux nombres diffèrent-ils? Lequel présenteriez-vous pour indiquer « à quelle fréquence les brouillons ont besoin de corrections »?

Afficher la réponse

Seulement 14,3 % des clients votent, et les clients mécontents cliquent plus souvent. La proportion de votes négatifs reflète donc les personnes qui ont choisi de cliquer. Les agents lisent chaque brouillon; le taux de modification couvre donc tous les billets. Présentez le taux de modification comme tendance et précisez qu’une modification n’est pas toujours un échec. Utilisez les votes négatifs seulement pour repérer les billets qui méritent une lecture.

Vérifiez votre compréhension

L'examen aléatoire de 40 billets n'a trouvé aucune demande liée à une baisse de prix, mais le journal en comptait 88. Qu'est-ce que cela vous apprend sur l'examen par échantillonnage? Que feriez-vous à la semaine 3?

Afficher la réponse

Un petit échantillon aléatoire est sans biais, mais il ne trouve que les problèmes courants. Un échantillon aléatoire de 10 billets de la semaine 3 manque les 38 billets de baisse de prix environ 26 fois sur 100. Combinez-le aux décomptes de dérive. Quand un décompte révèle un nouveau sujet, lisez volontairement chaque billet de ce sujet. Ensuite, rédigez et étiquetez de nouveaux cas pour dev.

Vérifiez votre compréhension

Pourquoi les nouveaux cas de production vont-ils dans dev et jamais dans les données réservées? Qu'est-ce qui change dans le jeu de données quand vous ajoutez un cas?

Afficher la réponse

Les données réservées doivent rester inédites et fixes. Ainsi, les décisions de mise en production comparent les mêmes cas, sans que personne ait ajusté le système à partir d’eux. Les nouveaux cas ont été lus et discutés; leur place est donc dans dev. L’ajout d’un cas change la version du jeu de données et celle des entrées de dev. Vous devez donc enregistrer la référence de base sur ce nouveau cas avant de l’utiliser pour une comparaison. La version des entrées des données réservées reste la même; leurs résultats restent donc valides.

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 exécute toute la boucle sur des données ouvertes : deux versions, sous-groupes, intervalles, blocages et décision de mise en production reproductible.

Récapitulatif

• La rétroaction de la production comporte quatre signaux : votes, modifications des agents, examen aléatoire et dérive. Aucun ne fournit d’étiquettes; chacun a un angle mort.
• Pendant le mois simulé, seulement 14,3 % des clients ont voté. La proportion de votes négatifs (30 % à 43 %) surestime les mauvais brouillons. Le taux de modification des agents, environ 1 sur 5, constitue la tendance la plus stable.
• La dérive était le véritable fait nouveau : un nouveau sujet atteignait 16,2 % des billets à la semaine 4. Les billets en français ont presque doublé. L’échantillon aléatoire de 40 billets n’a trouvé aucun billet de baisse de prix.
• Les nouveaux cas vont dans dev, rédigés et étiquetés par une personne, avec une nouvelle version du jeu de données. Les données réservées restent fixes; la version de leurs entrées ne change pas.
• La boucle d’évaluation relie les vérifications hors ligne, la décision de mise en production, les observations en production et les nouveaux cas.
• Votre projet correspond à l’instantané end-of-m06, la fin du projet du cours : 106 passed, 1 deselected.

Les modèles changent vite, et les nombres de ce cours représentent un instantané d’un ensemble d’exécutions. La méthode demeure : cas fixes, exécutions enregistrées, blocages en premier et ensemble qui apprend de la production. Le cours Agents d’IA et orchestration des flux de travail s’appuie sur ce banc d’évaluation pour évaluer les étapes d’un agent. Avant cela, le travail final vous demande de construire le vôtre.

Leçon suivante : Travail final