Travail final

Après les études de cas
environ 5 h

Ce que vous saurez faire

Appliquez chaque module du cours à un système que vous construisez vous-même : un assistant de soutien simulé, fait de règles et de gabarits. Fournissez-lui des données d’évaluation étiquetées et versionnées. Mesurez ses résultats avec les bonnes métriques et les bons sous-groupes. Vérifiez ses réponses avec une grille et une deuxième personne qui les évalue. Enfin, comparez-le à la référence de base de Larkfield dans un rapport que tout le monde peut reproduire.

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

Vous avez terminé les modules 1 à 6. Chaque partie ci-dessous nomme les leçons qu’elle utilise.
Vous n’avez pas besoin des études de cas pour ce travail. Le certificat en exige au moins une.
Partez de votre propre eval-harness à la fin du module 6, ou copiez l’instantané end-of-m06, comme l’explique Utiliser un instantané. Exécutez d’abord python -m pytest : le résultat doit afficher 106 passed, 1 deselected (106 tests réussis, 1 désélectionné) avant toute modification. Faites un commit (enregistrement dans Git) de cet état, ou gardez-en une copie, pour pouvoir comparer.
Aucun compte ni aucune clé ne sont nécessaires. Un juge en direct (Ollama ou votre propre clé) est facultatif dans la partie 4, toujours avec le plafond.
Certains tests fixent les valeurs du jeu de données du cours, par exemple 271 cas. Ils échouent après la partie 1, comme prévu. Mettez-les à jour et indiquez dans votre rapport chaque test modifié et pourquoi.
Testé avec Python 3.12 et les versions de requirements.txt, sur macOS.

Le changement : un candidat sans aucun modèle

Après le mois en production, Omar a une nouvelle idée : « Le modèle est lent et il raisonne trop longtemps. Et si quelques règles choisissaient l’équipe et needs_human, puis qu’un gabarit fournissait la réponse? Ça ne coûterait rien et ça répondrait toujours. » Grace répond : « Alors montre-moi qu’il ne manque jamais un billet de soutien lié à la sécurité. Et que ses réponses restent utiles. »

Votre candidat est cet assistant de soutien simulé : du Python simple, sans modèle. C’est un vrai candidat, et le banc d’évaluation doit le juger comme les autres. Il vous donne aussi quelque chose que les exécutions enregistrées ne peuvent pas offrir : un système à modifier et à réexécuter en une seconde.

Le mois de production utilisé dans la partie 1 est simulé, tout comme chaque billet que vous écrivez. Dites-le dans votre rapport.

Partie 1 : enrichir et versionner les données d’évaluation

Utilise Choisir des cas représentatifs, Étiqueter et versionner, Éviter la contamination et Rétroaction de la production.

Écrivez au moins 10 nouveaux cas de développement pour couvrir ce que le mois simulé a révélé. Écrivez au moins 5 demandes de baisse de prix et au moins 3 billets supplémentaires en français. Parmi les demandes de baisse de prix, écrivez-en une en français, une qui mentionne aussi un problème de sécurité et une qui ne demande rien d’interdit par la politique. Donnez à chaque cas tous les champs présents dans les autres lignes. Étiquetez chacun selon la politique de Grace (data/policy.md) : équipe, needs_human et règle, prochaine étape, criteria.must et criteria.must_not, critical, et un label indiquant qui l’a étiqueté, comment et quand.
Ajoutez-les à data/cases.jsonl avec save_cases(), comme dans Ajouter de nouveaux cas de façon contrôlée. check() doit réussir. Montrez que la version des entrées du jeu réservé est toujours 1be23cc44ea9.
Consignez la nouvelle version du jeu de données et ajoutez une section à data/dataset.md : vos ajouts, leurs raisons, qui les a étiquetés et ce qui manque encore.
Demandez à une deuxième personne d’étiqueter 5 de vos cas sans voir vos étiquettes. Comparez et consignez la résolution de chaque désaccord. Si personne ne peut vous aider, dites-le et indiquez que les étiquettes ont été vérifiées par une seule personne.

Partie 2 : l’assistant simulé, sous forme d’exécution

Utilise Établir une référence de base, Expériences contrôlées et Structure du banc d’évaluation.

Écrivez mock_assistant.py : une fonction qui reçoit le texte d’un billet et renvoie team, needs_human, reason et reply. Utilisez des règles par mots-clés pour l’équipe et les règles H1 à H5, puis un gabarit de réponse par prochaine étape. Restez sous environ 100 lignes : l’objectif est l’évaluation, pas l’assistant.
Enregistrez ses sorties comme une exécution, au format des exécutions sauvegardées. Écrivez une ligne par cas dans outputs/<run ID>.jsonl, avec tous les champs de Output (coût 0, latence 0, finish_reason à stop). Ajoutez une entrée dans outputs/runs.json, avec tous les champs de Run. Construisez l’identifiant avec make_run_id(), en utilisant le SHA-256 de votre script comme empreinte de la requête.
Exécutez-le deux fois et montrez que les deux fichiers de sortie sont identiques : un système déterministe nécessite une exécution, pas cinq. Expliquez pourquoi en une phrase.
Utilisez l’identifiant complet de l’exécution dans chaque commande. Si vous enregistrez une deuxième exécution du même système avec la répétition 1, le nom court cesse volontairement de fonctionner (No run 'rules', aucune exécution « rules »).

Partie 3 : métriques et sous-groupes

Utilise Métriques de prédiction, Métriques des sorties générées et Incertitude et sous-groupes.

Évaluez votre exécution sur les données de développement avec score, --by slice et --by criterion : réponses valides, équipe, besoin d’une personne (cas détectés, fausses alertes, précision et rappel), critères de réponse.
Expliquez quelle mesure compte le plus pour ce candidat, et pourquoi. Un billet de sécurité manqué et une question de livraison mal acheminée n’ont pas le même coût.
Trouvez un échec que le score global masque, par sous-groupe ou par critère, et montrez les cas concernés.
Lisez chaque échec d’une règle d’interdiction et chaque cas manqué nécessitant une personne avec show. Indiquez pour chacun s’il s’agit d’un vrai échec ou d’une erreur du vérificateur.

Partie 4 : un processus de jugement vérifié par des humains

Utilise Rédiger une grille d’évaluation utilisable, Calibrer les évaluateurs, Le jugement par modèle et Le jugement par modèle (suite).

Préparez une feuille d’évaluation à l’aveugle de 20 réponses : 10 de la référence de base et 10 de votre assistant simulé, sur les mêmes cas de développement. Mélangez-les et retirez le nom du système. Gardez le corrigé dans un fichier distinct.
Notez chaque réponse avec la grille de Grace (harness/prompts/rubric.md), avec une note explicative d’une ligne chacune.
Obtenez une deuxième évaluation des mêmes 20 réponses : une deuxième personne (de préférence), ou un juge en direct avec le plafond. Comparez avec python -m harness agree et discutez de chaque paire dont l’écart atteint 2 points ou plus.
Essayez le juge enregistré sur les réponses de votre assistant simulé avec python -m harness judge <your run ID>. Expliquez le résultat : il répond No recording for this request (aucun enregistrement pour cette requête), car le juge simulé peut seulement rejouer des requêtes enregistrées.
Écrivez la règle de votre processus. Quelles réponses une personne doit-elle toujours lire? Par exemple : chaque cas critique et chaque cas où le juge ne donne aucun verdict, comme T-81040. Quelles réponses un juge peut-il noter seul, s’il y en a?

Partie 5 : une comparaison reproductible pour la mise en production

Utilise Compromis et régressions, Structure du banc d’évaluation et Vérifications de régression.

La référence de base n’a aucune sortie pour vos nouveaux cas. Exécutez report et compare sur les données de développement et trouvez la différence. report compte une sortie manquante de la référence de base comme un échec (n = 103 avec un nouveau cas). compare utilise seulement les cas présents dans les deux exécutions (n = 102). Modifiez report.py pour qu’il compare seulement les cas présents dans les deux exécutions. Ses premières lignes doivent indiquer combien de cas il a exclus, et pourquoi. Ajoutez un test pour cela.
Corrigez les tests que vos nouveaux cas ont fait échouer (par exemple, les vérifications de régression cherchent une sortie inexistante de la référence de base). Gardez les règles; changez seulement la façon dont elles trouvent leurs cas. Énumérez chaque modification.
Ajoutez au moins une vérification de régression pour votre assistant simulé : par exemple, chaque billet de sécurité est transmis à une personne. Elle doit réussir sur votre exécution finale.
Prenez la décision sur les données de développement avec decide, modifiez l’assistant simulé et réexécutez-le. Consignez chaque tentative comme une nouvelle exécution avec son propre identifiant. Arrêtez quand vous êtes satisfait ou après avoir essayé trois modifications.
Prenez ensuite la décision sur le jeu réservé, une seule fois, avec votre exécution finale, et écrivez le rapport dans report-holdout.md.
Reproduisez le rapport dans une nouvelle copie de votre projet et comparez les valeurs SHA-256. Reliez chaque nombre du tableau des mesures aux cas dont il provient.

Quoi remettre

Votre dossier eval-harness (sans .venv ni .env), avec les nouveaux cas, l’assistant simulé, ses exécutions, vos feuilles d’évaluation et REPORT.md :

# A mock support assistant, evaluated
## Evaluation set          (Part 1: new cases, labels and who made them, versions, the second labeller, what is missing)
## The mock assistant      (Part 2: what it does, its run IDs, why one run is enough)
## Measures and slices     (Part 3: the measures, the one that matters most, the failure the overall score hides)
## Judging                 (Part 4: the rubric ratings, the second rating and agreement, where a person must read)
## Release comparison      (Part 5: the report change, the tests changed and added, dev attempts, the holdout decision)
## Reproduce and trace     (the SHA-256 in two copies; every number of the Measures table traced to its cases)
## Limits                  (simulated tickets, one or two raters, what you did not test)

Vérifiez votre travail

La personne qui révise marque chaque élément démontré, partiellement démontré ou pas encore démontré, avec une raison. Pour terminer le cours, vous devez démontrer les quatre éléments obligatoires. Aucun point fort ailleurs ne compense l’échec d’une vérification de sécurité ou d’accès. Si votre rapport dit « mettre en production » alors qu’un billet de sécurité n’est transmis à personne, l’élément de comparaison n’est pas démontré.

Jeu de données versionné et étiquettes (obligatoire). Démontré : au moins 10 nouveaux cas de développement avec étiquettes complètes et provenance; check() réussit; une nouvelle version du jeu de données est consignée; la version des entrées du jeu réservé reste inchangée; la fiche du jeu de données indique les ajouts et leur auteur; un deuxième étiquetage, ou son absence, est consigné. Partiellement : les cas sont présents, mais les étiquettes n’ont pas de provenance, le jeu réservé a changé ou la version n’est pas consignée.
Métriques et sous-groupes appropriés (obligatoire). Démontré : décisions, précision et rappel du besoin d’une personne, et critères de réponse, avec un choix justifié de la mesure la plus importante; un échec masqué par le score global, illustré par ses cas; chaque échec d’une règle d’interdiction a été lu. Partiellement : seulement des nombres globaux, ou aucun échec masqué trouvé.
Processus de jugement vérifié par des humains (obligatoire). Démontré : 20 évaluations à l’aveugle avec la grille et des notes explicatives; une deuxième évaluation et son accord (exact, à un point près, kappa de Cohen); les grands désaccords sont discutés; une règle écrite précise quand une personne doit lire, avec une raison tirée du cours. Partiellement : des évaluations sans deuxième évaluateur ou sans règle.
Comparaison reproductible entre référence de base et candidat (obligatoire). Démontré : le rapport compare seulement les cas communs et le précise; des tests couvrent ce comportement et votre vérification de régression; les tentatives de développement sont des exécutions distinctes avec leurs propres identifiants; le jeu réservé est utilisé une fois; le rapport est identique dans une nouvelle copie; chaque nombre du tableau des mesures est relié à ses cas. Partiellement : la décision est juste, mais le rapport ne peut pas être reproduit, ou un nombre ne peut pas être relié à ses cas.

Il n’y a pas de nombres de référence à comparer : vos cas et votre assistant simulé sont les vôtres. Les nombres du cours pour les exécutions enregistrées se trouvent dans Compromis et régressions et Structure du banc d’évaluation.

Récapitulatif

Vous avez construit ce dont une équipe a besoin avant de faire confiance à un changement. Le jeu de données apprend de la production, tandis que son jeu réservé reste figé. Les mesures vont au-delà de la moyenne, et une deuxième personne vérifie les évaluations. Tout le monde peut reproduire le rapport de mise en production et le relier à ses cas. Si vous n’en avez pas encore fait, choisissez une étude de cas pour le certificat : Calibrer un juge modèle par rapport à des notes humaines, Évaluer des résumés par rapport aux notes d’experts ou Tester la régression d’une nouvelle version d’un classificateur, par sous-groupe.