Travail final

Ce que vous saurez faire

Remettez le service d’escalade à l’équipe qui l’exploitera, avec des preuves. Vous mettez en production une nouvelle version du modèle. Vous prouvez que le traitement par lots et le service en ligne donnent les mêmes scores pour les mêmes billets de soutien. Vous mesurez les besoins du service et prouvez que vous pouvez revenir à la version précédente.

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

Ce que vous devez savoir

• Vous avez terminé les modules 1 à 5. Chaque partie ci-dessous nomme les leçons utilisées.
• Les études de cas du module 6 ne sont pas nécessaires pour ce travail. Le certificat exige aussi au moins une de ces études.

Ce qu’il vous faut sur votre ordinateur

• Votre projet escalation-service à la fin de Retour en arrière et retrait : paquets escalation-1.0.0 et escalation-1.1.0, RELEASES.md, compose.yaml, .env, bench/bench.py, parity/check_parity.py, data/july_tickets.csv.
• Docker, comme dans Paramètres de ressources du conteneur.
• Si votre projet manque ou ne fonctionne plus, copiez l’instantané end-of-m05. Utiliser un instantané présente les étapes. Un instantané n’a pas de fichier .env : recréez-le à partir de .env.example.

Testé avec Python 3.14.6 et Docker Desktop (Docker Engine 29.6.1) sur macOS, avec une puce Apple. Les étapes pour Windows et Linux n’ont pas été testées.

La situation

Le service d’assistance de Grace dépendra du score d’escalade chaque jour. Avant d’accepter le service, l’équipe de la plateforme demande quatre choses :

1. Des artefacts compatibles. Le paquet exécuté est celui qui a été révisé, et il respecte le contrat du service.
2. La parité. Le traitement par lots nocturne et le service en ligne donnent le même score et le même indicateur pour chaque billet.
3. La latence et les ressources mesurées. Des chiffres provenant d’une charge de travail précisée, pas des estimations, et une conclusion qui respecte leurs limites.
4. Un plan de retour en arrière fonctionnel. Un exercice qui rétablit la version précédente et vérifie ensuite que tout fonctionne.

Règles pour chaque partie

• Créez un fichier evidence.md à l’extérieur du dossier du projet, par exemple ~/projects/c17-evidence.md. Après chaque partie, copiez-y les commandes et les sorties demandées.
• Ne copiez jamais de clé d’API dans les preuves.
• Chaque chiffre de vos preuves provient d’une commande que vous avez exécutée. Notez les conditions : l’ordinateur, les limites de CPU et de mémoire, et les autres programmes en cours d’exécution.

Partie 1 : mettre en production 1.1.0 avec des artefacts compatibles

Utilise Empaqueter les dépendances du modèle, Confiance et intégrité des artefacts et Versions et déploiement progressif.

1. Montrez que le paquet 1.1.0 n’a pas changé depuis sa création. Calculez son empreinte et comparez-la à celle de RELEASES.md.
2. Montrez que 1.1.0 et 1.0.0 ont le même contrat : les mêmes variables dans le même ordre et le même schéma. Seuls la version et le seuil peuvent différer. Écrivez une courte commande Python qui charge les deux fichiers contract.json et affiche les différences.
3. Faites de 1.1.0 la version en production : définissez MODEL_VERSION et MODEL_SHA256 dans .env, puis démarrez le service avec docker compose up -d --build --wait.
4. Affichez GET /v1/model. Ses valeurs model_version et bundle_sha256 doivent correspondre à votre entrée dans RELEASES.md.
5. Mettez à jour RELEASES.md : 1.1.0 est en production, et 1.0.0 est la version fiable à rétablir.

Ce que vous devriez voir

Les empreintes sont identiques. Les contrats diffèrent seulement par model_version et output.threshold (0,2 contre 0,19). /v1/model répond avec la version 1.1.0 et l’empreinte de RELEASES.md. Le conteneur est healthy (en bon état).

Partie 2 : comparer le service en ligne et le traitement par lots pour les mêmes billets

Utilise Inférence par lots, Inférence en ligne et Vérifier la parité.

Une journée au service d’assistance compte environ 45 billets. Utilisez les 200 premiers billets de juillet comme petite charge de travail fixe : environ quatre jours.

1. Créez le fichier : l’en-tête et les 200 premiers billets de data/july_tickets.csv, dans data/day.csv.

   head -n 201 data/july_tickets.csv > data/day.csv

   Sur Windows (PowerShell) : Get-Content data\july_tickets.csv -TotalCount 201 | Set-Content -Encoding utf8 data\day.csv.

2. Exécutez le traitement par lots avec le même paquet que le service, et placez les résultats dans out/day. Utilisez les mêmes MODEL_BUNDLE et MODEL_SHA256 que dans .env.

3. Écrivez compare_paths.py dans le dossier du projet. Il doit envoyer chaque billet de data/day.csv à POST /v1/score, un à la fois. Il doit comparer chaque score en ligne au score par lots du même billet dans out/day/scores.csv. Il doit afficher : le nombre de billets, les versions du modèle observées, la plus grande différence entre scores, le nombre d’indicateurs différents et le temps pris par chaque mode.

4. Exécutez-le avec le service en cours d’exécution. Exécutez ensuite parity/check_parity.py avec ce service aussi.

Conseil

Lisez scores.csv avec pd.read_csv(..., float_precision="round_trip"). Le lecteur par défaut peut supprimer le dernier chiffre d’un nombre long. Vous mesureriez alors le lecteur plutôt que le service.

Ce que vous devriez voir

Avec 1.0.0, l’exécution du cours a affiché :

200 tickets. Model versions: 1.0.0.
Largest score difference: 1.1e-16 (tolerance 1e-09). Flags that differ: 0.
Online, one request at a time: 0.79 s. Batch job: 1.52 s.
The two paths agree.

Vos temps seront différents. Attendez-vous à une seule version du modèle, à une différence maximale bien inférieure à 1e-9 et à aucun indicateur différent.

Expliquez les temps. Ici, le mode en ligne était plus rapide. Pourtant, le module 2 montrait que traiter tous les billets en un appel est environ 350 fois plus rapide par billet. Exécutez le traitement par lots quelques fois sur les deux fichiers. Sur l’ordinateur du cours, il prenait de 0,67 à 1,05 s pour les 200 billets. Il prenait de 0,60 à 0,77 s pour les 1 400 billets (la première exécution du jour est la plus lente). La taille du fichier compte peu, car presque tout le temps passe au démarrage : importer scikit-learn, puis charger et vérifier le paquet. Le calcul des scores lui-même prend des millisecondes. Le service en ligne a payé son coût de démarrage une seule fois, à son lancement. Chaque requête ne prend donc que quelques millisecondes : environ 0,8 s pour 200 billets, mais 5 à 6 s pour 1 400. Vos preuves doivent expliquer vos propres chiffres de cette façon.

Partie 3 : latence et ressources mesurées

Utilise Paramètres de ressources du conteneur et Mesurer la performance du service.

1. Utilisez la configuration de votre docs/infrastructure.md (processus, CPU, mémoire). Notez-la dans vos preuves.
2. Exécutez bench/bench.py deux fois avec les mêmes paramètres : 1 000 requêtes avec une concurrence de 1, puis de 4. Copiez les deux lignes de résultats.
3. Pendant la deuxième exécution, lancez docker stats --no-stream et copiez les colonnes de mémoire et de CPU.
4. Mesurez un démarrage à froid : arrêtez le conteneur, puis chronométrez docker compose up -d --wait.
5. Écrivez quatre phrases : le p95 respecte-t-il le budget de 50 ms avec la charge de Larkfield? Où passe le temps? Quel est le goulot d’étranglement sous charge? Qu’est-ce que vous n’avez pas mesuré (par exemple, le réseau vers un nuage ou un deuxième ordinateur)?

Ce que vous devriez voir

Sur l’ordinateur du cours, un processus avec 1 CPU donnait un p95 d’environ 6 ms avec une concurrence de 1. Il utilisait environ 150 Mio de mémoire. Avec une concurrence de 4, le p50 augmente parce que les requêtes attendent le seul CPU disponible. Le débit reste à peu près le même. Un démarrage à froid local prend quelques secondes. L’exécution réelle dans le nuage de Mesurer la performance du service prenait environ 24 à 26 secondes, à partir de zéro réplique. N’attribuez pas les chiffres de votre portable à un nuage.

Partie 4 : un exercice de retour en arrière

Utilise Surveiller la santé du modèle et Retour en arrière et retrait.

1. Avant l’exercice, sauvegardez le journal du service : docker compose logs --no-log-prefix > predictions-1.1.0.log. Le remplacement du conteneur le supprime.
2. Revenez à 1.0.0 : définissez ses valeurs MODEL_VERSION et MODEL_SHA256 de RELEASES.md dans .env. Chronométrez ensuite docker compose up -d --wait.
3. Vérifiez après le retour en arrière : /v1/model (version et empreinte), parity/check_parity.py pour le paquet 1.0.0 (14 sur 14), un billet valide (200) et un billet invalide (422 avec ses fields, ou champs).
4. Exécutez le traitement par lots avec 1.0.0 dans un nouveau dossier, puis exécutez de nouveau compare_paths.py. Les deux modes doivent encore donner les mêmes résultats.
5. Écrivez le plan de retour en arrière dans RELEASES.md : quand revenir en arrière (les signaux du module 5 et leurs limites), les étapes exactes, la durée mesurée et les vérifications.

Ce que vous devriez voir

L’exercice prend quelques secondes sur votre ordinateur. Le cours a mesuré 6 à 7 s pour atteindre healthy, dont environ 2 s sans aucune réponse. Ensuite, /v1/model affiche 1.0.0 et son empreinte, et la parité est de 14 sur 14. Le billet valide reçoit 200 et le billet invalide, 422. compare_paths.py affiche « The two paths agree. » (les deux modes donnent les mêmes résultats), avec seulement la version 1.0.0.

Vérifiez votre travail

Révisez vos preuves avec ce tableau, ou demandez à un collègue de l’utiliser. Marquez chaque élément comme démontré, partiellement démontré ou pas encore démontré, avec une raison. Le cours est terminé lorsque chaque élément est démontré. Vous pouvez améliorer un élément et le réviser autant de fois que nécessaire.

Preuve requise	Démontré lorsque
Artefacts compatibles du modèle et du prétraitement	L’empreinte du paquet exécuté correspond à l’empreinte révisée; les deux contrats diffèrent seulement par la version et le seuil; /v1/model affiche la version et l’empreinte de RELEASES.md.
Tests de parité entre l’entraînement et le service	check_parity.py donne 14 sur 14; compare_paths.py affiche une seule version du modèle, une différence maximale inférieure à 1e-9 et aucun indicateur différent, pour 200 billets.
Latence et utilisation des ressources mesurées	Deux lignes de banc d’essai avec leurs paramètres, la mémoire et le CPU de docker stats, un démarrage à froid chronométré et quatre phrases qui respectent les limites de vos mesures.
Plan de retour en arrière fonctionnel	L’exercice est chronométré; ensuite, la version, l’empreinte, la parité et le contrat (un billet valide et un invalide) sont vérifiés; RELEASES.md contient le plan et le compte rendu.

Un scénario normal qui fonctionne ne suffit pas. Si le traitement par lots et le service utilisent des paquets différents, l’élément est pas encore démontré. Il en va de même si une vérification réussit seulement parce qu’elle n’a pas visé le service en cours d’exécution. Ou si le retour en arrière est décrit, mais pas effectué.

Erreur courante

Les deux modes ne donnent pas les mêmes résultats

Symptôme : compare_paths.py affiche deux versions du modèle, ou des indicateurs différents, et « The two paths do NOT agree. » (les deux modes ne donnent PAS les mêmes résultats).

Cause : le traitement par lots et le service ont utilisé des paquets différents. Le plus souvent, .env indique 1.1.0 pour le service. Mais l’interpréteur de commandes du traitement par lots avait encore le MODEL_SHA256 de 1.0.0, ou l’inverse. Le fichier summary.json du traitement par lots indique le paquet utilisé.

Solution : exécutez le traitement par lots avec les mêmes MODEL_BUNDLE et MODEL_SHA256 que le service, puis comparez de nouveau. Dans un vrai système, un seul registre de mise en production définit les deux pour éviter toute divergence.

Récapitulatif

• Une mise en production comprend une version et une empreinte. Vérifiez les deux là où le modèle s’exécute.
• Les mêmes billets traités selon deux modes doivent donner les mêmes scores, selon une tolérance précisée, et les mêmes indicateurs.
• Un traitement par lots paie son coût de démarrage à chaque exécution; un service le paie une seule fois. Le mode le plus rapide dépend de la taille du fichier.
• Un banc d’essai constitue une preuve seulement avec sa charge de travail et ses conditions, et seulement pour ce qu’il mesure.
• Seuls un exercice et les vérifications qui suivent prouvent qu’un plan de retour en arrière fonctionne.

Les études de cas du module 6 appliquent le cours à de nouveaux modèles. Le certificat exige au moins une de ces études : Prédire le défaut de crédit par lots et en ligne, Mettre en production un nouveau modèle de prix des maisons ou Prédire les réadmissions à l’hôpital de façon asynchrone.