Choisir les niveaux d'évaluation

Ce que vous saurez faire

Choisissez où vérifier chaque critère : dans une fonction simple, dans une partie de l’assistant, sur un billet entier ou en production. Ensuite, configurez le projet du cours, eval-harness, et prouvez qu’il fonctionne.

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

Ce que vous devez savoir

• Ce qu’est un critère mesurable, expliqué dans Relier les objectifs aux preuves.
• Comment ouvrir un terminal et passer d’un dossier à l’autre, expliqué dans Les fichiers et le terminal du cours Python pour l’ingénierie de l’IA en pratique.
• Comment créer et activer un environnement virtuel, expliqué dans Isoler les dépendances.

Ce qu’il vous faut sur votre ordinateur

• Python 3.12 ou une version plus récente, selon Installer et vérifier Python.
• Le dossier ~/projects. S’il n’existe pas, exécutez d’abord mkdir ~/projects.
• Un éditeur comme VS Code et une connexion Internet pour télécharger le projet et ses deux paquets (environ 40 Mo avec l’environnement virtuel).
• Git est facultatif : vous pouvez plutôt télécharger un fichier ZIP.

Vous n’avez besoin d’aucun compte, d’aucune clé d’API et d’aucun paiement. Rien dans cette leçon n’appelle un modèle.

Testé sur macOS (Apple silicon) avec Python 3.12.13, pydantic 2.14.0 et pytest 9.1.1. Les commandes Windows et Linux suivent le cours de Python; elles n’ont pas été exécutées pour cette leçon.

Vérifier une voiture avant qu’elle prenne la route

Une usine automobile ne teste pas une voiture uniquement en la conduisant. Des machines vérifient chaque boulon pendant son installation : des milliers de vérifications par jour, chacune en une seconde. Chaque système de freinage passe un test sur banc avant son installation dans une voiture. Certaines voitures terminées roulent sur une piste d’essai, ce qui demande une heure et un conducteur. Après la vente, l’usine lit les rapports des garages et des propriétaires.

Chaque niveau détecte des problèmes que les autres ne peuvent pas détecter. Vérifier un boulon ne permet pas de savoir si la voiture est agréable à conduire. Un essai routier ne révèle pas lequel des 2 000 boulons est desserré. Aucun test avant la vente ne montre comment les gens conduisent dans la neige. L’usine utilise donc les quatre niveaux : beaucoup de vérifications peu coûteuses en bas, et quelques vérifications lentes en haut.

Le problème : un seul type de vérification ne suffit pas

Priya, la scientifique des données, est responsable de l’évaluation chez Larkfield. Sa première idée était simple. À chaque modification du projet, soumettre les 271 billets à l’assistant, puis demander à une personne de noter chaque réponse. C’est l’essai routier : il vérifie ce que le client reçoit vraiment.

Mais c’est lent et coûteux. Une nouvelle exécution de l’assistant sur 271 billets a pris environ 5 minutes et coûté 0,09 $ US avec chat-small. Un modèle qui note chaque réponse ajoute environ 0,004 $ US par réponse, et le temps d’une personne vaut beaucoup plus. Priya modifie le code dix fois par jour. Elle ne peut pas payer un essai routier chaque fois.

Pire encore, un essai routier peut manquer un bogue simple. Supposons qu’une modification du code fasse charger les cas réservés avec les cas de développement. Les cas réservés servent à la décision finale de mise en production, comme l’explique le module 2. Tous les scores semblent encore normaux, un peu plus élevés ou un peu plus bas. Rien dans les réponses ne révèle le bogue, mais une ligne de code de test le détecte en une milliseconde.

L’idée : des niveaux d’évaluation

Une évaluation comporte des niveaux, comme ceux de l’usine automobile. Chaque niveau vérifie une partie plus grande du système, avec moins de vérifications, mais à un coût plus élevé. On les représente habituellement par une pyramide.

La pyramide d'évaluation de l'assistant de Larkfield, des fonctions simples en bas à la production en haut. Les coûts sont les coûts réels du cours.

Description textuelle du diagramme

Quatre niveaux, de bas en haut.

Niveau 1, tests unitaires de fonctions simples. Du code avec une seule bonne réponse. Exemple : load_cases() renvoie 271 cas et ne charge jamais les données réservées sans demande explicite; les décomptes des décisions sur cinq cas inventés sont corrects. Ces vérifications prennent moins d’une seconde, ne coûtent rien et s’exécutent à chaque modification.

Niveau 2, évaluations de composants. Une partie de l’assistant sur de nombreux cas. Exemple : les réponses concernant l’équipe et needs_human d’une exécution enregistrée, sur les 102 cas de développement (prochaine leçon). Noter les sorties enregistrées prend quelques secondes. Une nouvelle exécution de l’assistant sur 271 billets prend environ 5 minutes.

Niveau 3, tâches de bout en bout. D’un billet entier à une réponse entière : le client obtient-il ce qu’il lui faut? Une personne avec une grille, ou un modèle utilisé comme juge, décide (module 4). Un juge modèle coûte environ 0,004 $ US par réponse; le temps d’une personne coûte plus cher.

Niveau 4, surveillance. De vrais billets après la mise en production : modifications des agents, pouces levés ou baissés, nouveaux sujets. Le module 6 utilise un journal simulé. Cela prend des semaines et vient en dernier.

Une flèche à gauche pointe vers le bas : plus de vérifications, plus rapides et moins coûteuses. Une flèche à droite pointe vers le haut : plus proche de ce que le client reçoit vraiment.

Niveau 1 : tests unitaires de fonctions simples. Un test unitaire vérifie un petit morceau de code à partir d’une bonne réponse connue. Il convient au code déterministe : la même entrée donne toujours la même sortie. Charger les cas, compter les billets détectés et construire une chaîne de version sont des opérations déterministes. Aucun modèle n’intervient, donc un test unitaire est exact, rapide et gratuit.

Niveau 2 : évaluations de composants. Un composant est une partie du système d’IA avec un rôle précis, comme choisir l’équipe, chercher ou répondre. Une évaluation de composant mesure cette partie sur de nombreux cas étiquetés. Le résultat n’est pas « réussite » ou « échec », mais un score, comme « l’équipe est correcte dans 97 cas sur 100 ». Un modèle intervient, donc chaque réponse peut être incorrecte. Seul un grand nombre de cas montre à quelle fréquence.

Niveau 3 : tâches de bout en bout. Une vérification de bout en bout donne au système entier une tâche entière, du billet à la réponse. Elle juge le résultat comme le ferait l’utilisateur. Le client a-t-il reçu la bonne prochaine étape, sur un ton aimable, sans rien d’inventé? Il faut une personne pour lire, ou un modèle qui joue ce rôle. C’est le niveau le plus proche de ce que les clients voient, et le plus coûteux.

Niveau 4 : surveillance en production. La production est le vrai service, avec de vrais clients. La surveillance consiste à l’observer après la mise en production : fréquence des modifications des agents, commentaires des clients, nouveaux sujets. Seul ce niveau voit les billets auxquels personne n’avait pensé. Mais il voit les problèmes après que les clients les ont rencontrés.

Pourquoi une pyramide? Le bas est large : beaucoup de vérifications rapides et peu coûteuses. Le haut est étroit : quelques vérifications lentes et coûteuses. À l’envers, chaque modification est lente et coûteuse, et les petits bogues se cachent dans les moyennes.

Un tout petit exemple : une fonction, un test

Voici un vrai test de niveau 1 du projet. La fonction load_cases() lit les données d’évaluation. Elle ne doit jamais renvoyer les cas réservés sans demande explicite :

harness/dataset.py (part)

def load_cases(path: Path = CASES, split: str | None = None) -> list[Case]:
    """All cases, or the cases of one split. The holdout set is never loaded by accident: ask for it."""
    cases = [Case.model_validate_json(line) for line in path.read_text(encoding="utf-8").splitlines() if line]
    if split is None:
        return [c for c in cases if c.split != "holdout"]
    if split == "all":
        return cases

tests/test_first_run.py (part)

def test_holdout_is_not_loaded_by_default():
    assert all(c.split != "holdout" for c in load_cases())

Le test a une seule bonne réponse : aucun cas du groupe réservé ne figure dans la liste par défaut. Il n’a besoin d’aucun modèle, d’aucune étiquette et d’aucun jugement. Si quelqu’un supprime la ligne if split is None, le test échoue immédiatement et le message nomme le test.

Comparez maintenant avec une vérification de niveau 2. À la prochaine leçon, vous notez les réponses enregistrées de l’assistant. Le résultat est une ligne comme needs a person: caught 23/23, false alarms 9 (besoin d’une personne : 23/23 détectés, 9 fausses alertes). Ce n’est pas une réussite ou un échec. C’est une mesure de la performance d’un composant sur 102 cas. Décider si 9 fausses alertes sont acceptables demande les critères de la leçon précédente.

Quel niveau détecte quelle défaillance

La règle pour choisir un niveau est courte : vérifiez chaque défaillance au niveau le plus bas capable de la détecter. Un niveau inférieur est plus rapide et moins coûteux, et il indique la cause plus précisément. Montez seulement pour les défaillances qu’un niveau inférieur ne peut pas voir.

Quatre façons dont l'assistant ou le banc d'évaluation peut échouer, chacune avec le niveau le plus bas qui la détecte.

Description textuelle du diagramme

Quatre défaillances, chacune avec le niveau le plus bas qui la détecte.

Première : une modification du code fait aussi charger les données réservées par load_cases(). Un test unitaire la détecte : test_holdout_is_not_loaded_by_default échoue.

Deuxième : une nouvelle requête (prompt) n’attribue un billet de sécurité à personne. Une évaluation de composant la détecte : le nombre de billets détectés qui nécessitent une personne passe sous 23 sur 23.

Troisième : une réponse promet quelque chose que la politique ne prévoit pas. Une vérification de bout en bout la détecte : une personne note la réponse avec la grille.

Quatrième : les clients commencent à poser des questions sur un sujet absent des données d’évaluation. Seule la surveillance la détecte : un échantillon de vrais billets révèle le nouveau sujet.

Regardez la deuxième ligne. Une personne pourrait aussi repérer un billet de sécurité attribué à personne, au niveau 3. Mais needs_human est une donnée simple que le code peut comparer à l’étiquette, donc la vérification appartient au niveau 2. La troisième ligne est différente. Déterminer si une phrase promet trop demande quelqu’un qui comprend la phrase. Le code repère certains cas avec des règles sur les formulations (module 3), et une personne décide du reste.

Larkfield : les niveaux dans ce cours

Le cours construit les niveaux dans l’ordre, dans le projet eval-harness. Le projet n’exécute jamais l’assistant. Chaque sortie de l’assistant a été enregistrée une fois à partir du vrai modèle et sauvegardée avec le cours. Le niveau 2 ne vous coûte donc rien : le banc d’évaluation note les sorties enregistrées.

Niveau	Ce que le banc d’évaluation vérifie	Où dans le cours
1. Tests unitaires	Chargement des cas, décomptes, identifiants d’exécution, version du jeu de données, fonctions de notation sur de minuscules exemples inventés	Chaque module, dans tests/; tests de régression au module 6
2. Évaluations de composants	Décisions concernant l’équipe et needs_human; règles de réponse; résultats de recherche	Prochaine leçon de ce module; module 3
3. Tâches de bout en bout	Chaque réponse entière, notée avec une grille par vous et par un juge modèle	Module 4
4. Surveillance	Un journal de production simulé : rétroaction, modifications des agents, nouveaux sujets	Module 6

Configurer le projet

Le projet provient du dépôt de laboratoires du cours, sous forme d’instantanés : des copies du projet au début et à la fin de chaque module. Vous commencez avec start (début).

1. Ouvrez un terminal et allez dans votre dossier de projets :

   cd ~/projects

2. Si vous avez Git, clonez le dépôt de laboratoires. Si vous l’avez cloné pour un cours précédent, exécutez plutôt git -C nextia-learning-labs pull.

   git clone https://github.com/Nextia-Intelligence/nextia-learning-labs.git

   Sans Git, téléchargez le fichier ZIP du dépôt. Décompressez-le dans ~/projects. Son dossier est nextia-learning-labs-main : utilisez ce nom dans les prochaines étapes.

3. Copiez l’instantané start dans un nouveau dossier, eval-harness :

   macOS

   cp -R nextia-learning-labs/C11/snapshots/start eval-harness

   Windows

   Copy-Item -Recurse nextia-learning-labs\C11\snapshots\start eval-harness

   Linux

   cp -R nextia-learning-labs/C11/snapshots/start eval-harness

4. Allez dans le projet et ouvrez-le dans votre éditeur :

   cd eval-harness
   code .

   Si code est introuvable, ouvrez le dossier depuis le menu File (fichier) de l’éditeur.

Vous travaillez dans votre copie, eval-harness. Le dossier de laboratoires reste intact pour vous permettre de recopier un instantané à tout moment.

Ensuite, l’environnement virtuel. Le projet nécessite deux paquets à des versions précises : pydantic vérifie les champs de chaque cas et pytest exécute les tests.

1. Créez et activez l’environnement :

   macOS

   python3 -m venv .venv
   source .venv/bin/activate

   Windows

   python -m venv .venv
   .venv\Scripts\Activate.ps1

   Linux

   python3 -m venv .venv
   source .venv/bin/activate

   L’invite commence maintenant par (.venv). À partir d’ici, tapez python sur tous les systèmes.

2. Installez les paquets à partir de requirements.txt :

   python -m pip install -r requirements.txt

   La dernière ligne de la sortie :

   Successfully installed annotated-types-0.8.0 iniconfig-2.3.1 packaging-26.3 pluggy-1.6.0 pydantic-2.14.0 pydantic-core-2.50.0 pygments-2.21.0 pytest-9.1.1 typing-extensions-4.16.0 typing-inspection-0.4.4

   Vous avez demandé deux paquets, et pip a aussi installé les paquets dont ils ont besoin. Vous pouvez ignorer sans risque l’avis concernant une nouvelle version de pip.

La première exécution au résultat connu

Deux vérifications prouvent que la configuration fonctionne : les tests, puis les données d’évaluation.

1. Exécutez les tests :

   python -m pytest

   La sortie (le chemin de votre dossier diffère) :

   ============================= test session starts ==============================
   platform darwin -- Python 3.12.13, pytest-9.1.1, pluggy-1.6.0
   rootdir: /Users/priya/projects/eval-harness
   configfile: pytest.ini
   testpaths: tests
   collected 3 items
   
   tests/test_first_run.py ...                                              [100%]
   
   ============================== 3 passed in 0.32s ===============================

   Chaque point représente un test réussi. Ce sont des tests de niveau 1 : ils ont pris un tiers de seconde.

2. Comptez les cas :

   python -m harness cases

   La sortie :

   271 cases, dataset version d4c96eaa10c0
     dev            102   needs a person:  23   French: 10
     holdout         98   needs a person:  24   French: 10
     contaminated    71   needs a person:  10   French:  1

Votre sortie doit être identique, caractère par caractère. d4c96eaa10c0 est la version du jeu de données : une empreinte du fichier data/cases.jsonl. Si un caractère du fichier change, la version change. Un score qui nomme cette version indique donc les cas exacts qui le sous-tendent. Les trois groupes s’appellent des partitions, et le module 2 les explique. dev (développement) sert au travail quotidien, et holdout (réservé) sert à la décision de mise en production. contaminated (contaminé) contient les billets utilisés pour rédiger la requête.

La vérification de la configuration. Trois tests réussis et la première ligne attendue signifient que vous êtes prêt.

Description textuelle du diagramme

Exécutez d’abord python -m pytest. Si vous ne voyez pas « 3 passed » (3 tests réussis), vérifiez que l’invite commence par (.venv) et que vous êtes dans le dossier eval-harness. Réinstallez les dépendances et relancez les tests. Quand vous voyez « 3 passed », exécutez python -m harness cases. Si la première ligne est « 271 cases, dataset version d4c96eaa10c0 » (271 cas, version du jeu de données d4c96eaa10c0), la configuration fonctionne. Sinon, recommencez : recopiez l’instantané start dans un nouveau dossier, créez un nouvel environnement .venv et recommencez les vérifications.

Ce que contient le projet

Chemin	Son rôle
data/cases.jsonl	Les données d’évaluation : 271 cas, un par ligne, chacun contenant un billet avec ses étiquettes
data/policy.md	La politique de soutien de Grace, identique à celle du cours Créer des applications fiables avec les API de LLM
data/dataset.md	La fiche du jeu de données : origine des cas et ce qu’ils ne peuvent pas vous dire
harness/dataset.py	Charge les cas, vérifie leurs champs et calcule la version du jeu de données
harness/__main__.py	La ligne de commande : python -m harness cases et show (afficher)
tests/	Les trois tests de niveau 1 que vous avez exécutés

Examiner un cas

Chaque critère de la leçon précédente demande des preuves tirées d’un cas. Examinez un billet de soutien concernant la sécurité :

python -m harness show T-64740

La sortie :

T-64740 | split dev | slice needs_person | source c06-valid
Text: Hi there. I logged in without trouble this morning and the refund from my last order went through, so that part is fine. I'm writing about my folding parasol, order LK-774120. The pole joint cracked while I was opening it on the patio and the canopy dropped toward my daughter's head. Could you tell me how to report this as a safety problem and what happens next? Thank you.
Expected: team warranty | needs_human true (H1) | next step none
Reply must: person_will_contact, stop_using | must not: claims_action, asks_secret
Labelled by: course author, 2026-10-09; Grace's policy (teams, H1-H5) applied by reading; team: the deep learning course's label (two models agreed), read again by the course author; next_step: warranty_claim -> none on review (on a safety ticket the next step is to stop using it and wait for a person; the warranty route is that person's decision)

Lisez-la ligne par ligne. Le billet commence par deux sujets sans importance : une connexion et un remboursement. La vraie demande concerne un parasol qui est tombé vers un enfant. La règle H1 dit qu’un problème de sécurité nécessite toujours une personne. Les étiquettes indiquent donc : équipe warranty (garantie), needs_human vrai, et une réponse demandant au client d’arrêter l’utilisation et annonçant un contact humain.

La dernière ligne indique qui a étiqueté le cas. L’auteur du cours a rédigé les étiquettes en appliquant la politique écrite de Grace, et des scripts les ont vérifiées. C’est l’interprétation d’une seule personne. Le module 2 montre ce travail, et au module 4, vous êtes le deuxième évaluateur.

Chaque ligne du cas alimente un niveau différent. needs_human true (intervention humaine nécessaire) est une donnée simple : une évaluation de niveau 2 la compare donc à la réponse de l’assistant. « Reply must : stop_using » (la réponse doit demander d’arrêter l’utilisation) relève en partie du niveau 2, avec des règles sur les formulations dans le code. Déterminer si la réponse est calme, claire et aimable relève du niveau 3 : il faut une personne pour la lire.

Quand utiliser chaque niveau et à quel coût

• Tests unitaires : pour tout le code ordinaire, à chaque changement. Les écrire prend quelques minutes; les exécuter ne coûte rien. Ils ne disent pas si le modèle est bon.
• Évaluations des composants : pour chaque décision ayant une étiquette, à chaque nouvelle requête ou nouveau modèle. Elles sont gratuites sur les sorties enregistrées; une nouvelle exécution coûte de l’argent et prend quelques minutes. Elles ne disent pas si une réponse complète est utile.
• Tâches de bout en bout : sur un échantillon de réponses complètes, avant une mise en production. Le temps du lecteur est le principal coût. Il faut d’abord vérifier un juge modèle (module 4).
• Surveillance : après chaque mise en production. Elle trouve ce qu’aucun jeu de données de test ne contient, comme de nouveaux sujets. Mais les clients ont déjà rencontré le problème.

Exercice guidé : placer cinq vérifications

Pour chaque vérification, choisissez le niveau le plus bas qui peut la faire. Écrivez vos réponses, puis ouvrez les nôtres.

1. python -m harness cases affiche 271 cas.
2. Pour les cas de développement en français, la réponse est en français.
3. La réponse à T-64740 est calme et claire, et le client saurait quoi faire.
4. La proportion de brouillons que les agents réécrivent augmente durant la deuxième semaine après une mise en production.
5. Pour les 23 cas de développement qui nécessitent une personne, needs_human vaut vrai.

Afficher les réponses

1. Niveau 1. Compter des lignes relève du code ordinaire, avec une seule bonne réponse. Un test dans tests/test_first_run.py le vérifie.
2. Niveau 2. Le code peut vérifier la langue de chaque réponse enregistrée par rapport à l’étiquette, sur 10 cas. Un lecteur intervient seulement quand le code ne peut pas trancher.
3. Niveau 3. « Calme, claire, et le client saurait quoi faire » nécessite un lecteur avec une grille.
4. Niveau 4. Seule la production comporte des agents et de vrais brouillons. Aucun test avant la mise en production ne montre cela.
5. Niveau 2. needs_human est un champ : le code le compare à l’étiquette de chaque cas.

À vous de jouer : placer vos critères

Ouvrez success-criteria.md de la dernière leçon. À côté de chaque critère, écrivez le niveau le plus bas qui peut le vérifier. Ensuite, trouvez un critère qui nécessite deux niveaux. Par exemple, le code trouve la plupart des échecs, et un lecteur tranche pour le reste.

Afficher un exemple de réponse

• Bonne équipe pour 95 cas sur 100 : niveau 2.
• Chaque billet de soutien visé par les règles H1 à H5 est envoyé à une personne : niveau 2. La fonction qui les compte est testée au niveau 1, sur un tout petit exemple inventé.
• La réponse contient la prochaine étape : niveau 2 avec des règles sur les formulations. Le niveau 3 couvre les réponses pour lesquelles les règles ne peuvent pas trancher.
• Aucune réponse ne dit qu’un remboursement a été effectué : niveau 2 avec des règles sur les formulations, et niveau 3 pour le reste. Ce critère nécessite deux niveaux.
• Temps p95 et coût par 1 000 billets : niveau 2, à partir du temps et du coût enregistrés avec chaque sortie. Après la mise en production, le niveau 4 les mesure sur le trafic réel.
• Chaque billet reçoit une réponse valide : niveau 2.

Erreur courante

Aucun module nommé harness

Symptôme : vous exécutez python -m harness cases et voyez :

/Users/priya/projects/eval-harness/.venv/bin/python: No module named harness

Cause : le terminal n’est pas dans le dossier du projet. python -m harness cherche le paquet harness dans le dossier courant. Ici, la commande a été exécutée depuis ~/projects. Un message différent indique une cause différente :

ModuleNotFoundError: No module named 'pydantic'

Ce message signifie que l’environnement n’est pas actif : le Python de l’ordinateur n’a pas pydantic.

Solution :

1. Allez dans le projet : cd ~/projects/eval-harness.
2. Vérifiez que l’invite commence par (.venv). Sinon, activez de nouveau l’environnement.
3. Exécutez de nouveau la commande.

Sous Windows, si PowerShell indique que l’exécution des scripts est désactivée, suivez le cas d’échec « Exécution des scripts désactivée » dans Isoler les dépendances. Si le projet ne fonctionne toujours pas, réinitialisez-le.

Réinitialiser le projet

Si le projet cesse de fonctionner et que vous ne trouvez pas pourquoi, repartez de l’instantané. Votre ancien dossier reste, avec un nouveau nom. Vous ne perdez donc rien.

1. Désactivez l’environnement et allez dans votre dossier de projets :

   deactivate
   cd ~/projects

2. Renommez votre projet :

   macOS

   mv eval-harness eval-harness-old

   Windows

   Rename-Item eval-harness eval-harness-old

   Linux

   mv eval-harness eval-harness-old

3. Copiez de nouveau l’instantané, comme à l’étape 3 de Configurer le projet.

4. Créez un nouvel environnement et installez les paquets.

5. Exécutez les deux vérifications de la première exécution dont les résultats corrects sont connus.

Les modules suivants utilisent les mêmes étapes avec leur propre instantané. Par exemple, le module 2 peut commencer à partir de end-of-m01.

Vérification des connaissances

Vérifiez votre compréhension

Dans vos mots : pourquoi la pyramide d'évaluation est-elle large à la base et étroite au sommet?

Afficher la réponse

Les niveaux du bas sont rapides et peu coûteux. Vous pouvez donc multiplier les vérifications et les exécuter à chaque changement. Les tests unitaires de fonctions ordinaires prennent quelques millisecondes et ne coûtent rien. Les niveaux du haut sont lents et coûteux : un lecteur pour chaque réponse, ou des semaines de production. Vous en avez donc moins et les utilisez seulement pour ce qu’un niveau inférieur ne peut pas vérifier. Un niveau inférieur indique aussi la cause plus précisément.

Vérifiez votre compréhension

Prédisez : quelqu'un modifie load_cases() pour qu'elle retourne aussi les cas réservés par défaut. Quelle commande le montre en premier, et que voyez-vous?

Afficher la réponse

python -m pytest le montre en premier : test_holdout_is_not_loaded_by_default échoue. Le résumé indique 1 failed, 2 passed (1 échec, 2 réussites). Ce test de niveau 1 détecte donc le bogue en moins d’une seconde, avant tout calcul de score. python -m harness cases afficherait encore 271 cas, car cette commande demande volontairement toutes les partitions.

Vérifiez votre compréhension

Grace veut savoir si les réponses de l'assistant aux billets concernant la sécurité sont assez bienveillantes. Quel niveau le vérifie, et pourquoi pas un niveau inférieur?

Afficher la réponse

Le niveau 3, les tâches de bout en bout : un lecteur note chaque réponse complète à l’aide d’une grille. Le code peut vérifier qu’une réponse dit « cessez d’utiliser » et qu’une personne contactera le client (niveau 2). Mais le caractère « assez bienveillant » dépend de la lecture de la réponse complète. Il faut une personne qui comprend les phrases, et une grille pour que deux lecteurs notent de la même façon.

Récapitulatif

• Une évaluation comporte quatre niveaux. Les tests unitaires vérifient des fonctions ordinaires et déterministes. Les évaluations des composants vérifient une partie sur de nombreux cas étiquetés. Les tâches de bout en bout sont jugées telles que l’utilisateur les voit. La surveillance observe la production.
• La pyramide d’évaluation comporte beaucoup de vérifications rapides et peu coûteuses à la base. Au sommet, elles sont peu nombreuses, lentes et coûteuses. Vérifiez chaque échec au niveau le plus bas qui peut le détecter.
• Le projet eval-harness provient de l’instantané start des exercices pratiques. Pour la première exécution aux résultats corrects connus, python -m pytest donne 3 passed (3 réussites). La commande python -m harness cases affiche 271 cases, dataset version d4c96eaa10c0 (271 cas, version du jeu de données d4c96eaa10c0).
• python -m harness show CASE affiche un cas et ses étiquettes : les preuves nécessaires aux critères.
• Si une vérification échoue, vérifiez d’abord le dossier et l’invite (.venv). Si elle échoue encore, renommez votre projet et copiez de nouveau l’instantané.

Ensuite, vous ajoutez au projet les réponses enregistrées de l’assistant actuel et vous les notez. Elles deviennent la référence de base que chaque nouvelle version doit dépasser.

Leçon suivante : Établir une référence de base