Reproductibilité et projet de bout en bout : tout combiner

Gains :

• Capacité à assurer la reproductibilité avec quatre piliers (fixation des graines, versionnage des données, gel des supports, suivi des expériences) et à produire le même résultat en répétant la même analyse
• Capacité à combiner tous les arrêts du module (métriques, données, modèle, composants LLM, évaluation, équité, sécurité, distribution, surveillance) dans une chaîne de bout en bout
• Capacité à vérifier que la décision critique appartient à l'humain à chaque arrêt et à documenter le projet de manière vérifiable

L'échec le plus insidieux d'un projet ML n'est pas un crash ; "Je n'obtiens plus le même résultat." Si vous ne pouvez pas reproduire aujourd'hui la partition du modèle que vous avez mis en production il y a trois mois, vous ne contrôlez pas vraiment ce modèle. Dans cette unité de clôture, nous approfondissons la reproductibilité : la capacité d'obtenir de manière fiable le même résultat avec les mêmes entrées et de combiner l'ensemble du module dans une discipline de projet de bout en bout.

Pourquoi la reproductibilité est difficile

Dans un logiciel ordinaire, le même code donne le même résultat. En ML, il existe de nombreuses autres variables qui déterminent le résultat :

• Caractère aléatoire : le brassage des données, l'initialisation du poids, le fractionnement des données – tous reposent sur le caractère aléatoire.
• Données : le même code produit un modèle différent avec une version de données différente.
• Environnement : les versions de la bibliothèque, le matériel (CPU/GPU), même le système d'exploitation peuvent modifier le résultat.
• Cas caché : un hyperparamètre non enregistré, une étape de prétraitement manuel, une sélection non notée.

La reproductibilité n'est pas un « agréable » mais un impératif scientifique et technique. Un résultat qui ne peut être reproduit est une affirmation qui ne peut être prouvée.

Quatre piliers de la reproductibilité

1. Corrigez le caractère aléatoire. Placez toutes les graines aléatoires au même endroit : fractionnement des données, initialisation du modèle, brassage des données. La graine fixe est la base de la garantie « même résultat lorsque vous répétez la même analyse ».

2. Versionnez les données. Enregistrez avec quelle version de données chaque expérience a été réalisée (version des données dans l’unité 2). Les « dernières données » sont vagues ; "version de données v3, hachage abc123" est exact.

3. Congelez le support. Épinglez toutes les dépendances à leurs versions exactes (par exemple, des versions exactes comme numpy==1.26.4 dans Requirements.txt ou une image de conteneur). La "dernière version" va tout casser un jour.

4. Suivez tout (suivi des expériences). Enregistrez automatiquement pour chaque expérience : la version du code (git commit), la version des données, tous les hyperparamètres, métriques et structures de sortie. Les outils de suivi des expériences comme MLflow, Weights & Biases le font systématiquement. Sans inscription, la question « quel réglage était le meilleur » reste sans réponse.

Attention : « Je m'en souviendrai plus tard » est l'erreur la plus coûteuse. Deux semaines plus tard, vous ne vous souviendrez plus de quelle graine, quelles données, quel hyperparamètre vous avez utilisé. Le suivi automatique élimine le recours à la mémoire.

Approche faible / Approche forte

Faible : "J'ai trouvé le meilleur modèle, il est sur le portable, je pense que sa note était de 89 %."

Strong : "Exécutez #147 dans l'outil de suivi des expériences : git commit a3f9c, version des données v3 (hash abc123), graine 42, tous les hyperparamètres enregistrés, testez PR-AUC 0.887. Lorsque j'exécute à nouveau la même commande, j'obtiens le même résultat petit à petit. Le modèle dépend de cette exécution dans le registre. "

La différence : dans l'approche forte le résultat ne repose pas sur une mémoire, mais sur une chaîne fixe et surveillée. Tout le monde peut produire le même résultat à chaque fois.

Projet de bout en bout : combinaison de module

Combinons maintenant l'ensemble du module en un seul flux de projet. Un véritable système ML passe par ces arrêts, et chaque arrêt s'appuie sur le précédent :

1. Définition du problème : Que résolvons-nous, comment mesurer le succès (unité 3 : bonne métrique, contexte commercial). La métrique et le seuil sont clairs dès le départ.
2. Pipeline de données : Collecte, validation, nettoyage, partitionnement sans fuite, versioning (unité 2).
3. Développement de modèles : formation, comparaison de référence, validation croisée, amorçage dur (unité 3 + cette unité).
4. Composantes LLM (le cas échéant) : RAG (unité 4) et/ou agents (unité 5) ; mise au point si nécessaire (unité 6).
5. Évaluation : cluster d'évaluation avec cas de périphérie et de sécurité, évaluation multicouche dans les systèmes LLM (unité 8).
6. Audit de justice et d'éthique : Analyse de sous-groupe, fiche modèle, explicabilité (unité 10).
7. Audit de sécurité : injection rapide, confidentialité, chaîne d'approvisionnement (unité 9).
8. Distribution : Packaging, distribution progressive, rollback, registre de modèles (unité 7).
9. Surveillance : Surveillance à trois niveaux, alarmes de dérive (unité 8).
10. Reproductibilité : suivi des semences, des versions des données, des médias et des expériences tout au long de la chaîne (cette unité).

Dans ce flux, l’IA est un accélérateur et un générateur de plans à chaque arrêt ; mais la sélection des mesures, les décisions en matière de données, la priorisation de l'équité, le seuil de déploiement et l'approbation de la version – les décisions critiques appartiennent à l'humain. C'est l'essence du module.

Documentation : l'avenir vous remerciera

Un bon projet ML se documente. Au minimum, les éléments suivants doivent être écrits : les critères de problème et de réussite, la source et la version des données, les sélections et justifications du modèle, les résultats de l'évaluation (y compris les sous-groupes), les limites et les risques connus, la procédure de déploiement et de récupération, le plan de surveillance. Ce document est le meilleur ami de la personne (c'est peut-être vous) qui revient sur le projet après six mois.

trois mini-cases

Cas 1 - Résultat perdu. Un ingénieur a formé un excellent modèle, mais il n'a pas corrigé la graine et n'a pas enregistré la version des données. Lorsqu’il a quitté son poste, personne n’a pu reproduire ce résultat ; le modèle est devenu une « légende de la boîte noire » et a finalement été construit à partir de zéro. Des semaines ont été perdues. Leçon : un résultat non reproductible est un résultat inexistant.

Cas 2 – Effondrement de l’environnement. Une équipe n'avait pas corrigé les dépendances. Lorsqu'une bibliothèque était automatiquement mise à jour, les résultats du modèle changeaient silencieusement et la production était interrompue. Il a fallu des jours pour trouver le problème. Lorsque les dépendances ont été gelées et conteneurisées avec les versions définitives, le problème ne s'est plus reproduit. Leçon : geler l'environnement.

Cas 3 – Le pouvoir de la surveillance. Une équipe a automatiquement surveillé chaque expérience. Trois mois plus tard, lors d'un audit réglementaire, ils ont répondu à la question « avec quelles données, avec quels paramètres, quelles performances a-t-il obtenu dans quels groupes ? avec un enregistrement complet en quelques minutes. L'inspection s'est bien déroulée. Leçon : la surveillance est un outil de conformité, pas seulement un outil d'ingénierie.

Modèles copiables

Effectuez un contrôle de reproductibilité pour ce projet ML.- Toutes les graines aléatoires sont-elles corrigées (fractionnement, initialisation, lecture aléatoire) ?- Les données sont-elles versionnées ?- Les dépendances sont-elles gelées en versions exactes ?- Chaque expérience (validation de code, données, hyperparamètre, métrique) est-elle suivie ? Écrivez des étapes concrètes sur la façon de résoudre ce problème pour chaque colonne manquante. Structure du projet : [description]

Produisez un squelette de plan pour ce projet ML de bout en bout. Problème : [description] Couvrez les arrêts suivants et marquez où se trouve la décision HUMAINE à chaque arrêt : problème/métrique, pipeline, modèle, (RAG/agent/ajustement ?), évaluation, équité, sécurité, distribution, surveillance, reproductibilité. Écrivez le principal risque et l’étape de vérification pour chaque arrêt.

Produire un modèle de documentation technique pour ce projet. Sections : problème+critères de réussite, données (source+version), sélections de modèles+justification, évaluation (y compris les sous-groupes), limites+risques connus, déploiement+rollback, plan de surveillance. Donnez les champs à remplir pour chaque section sous forme de questions.

Vérifiez la configuration de la surveillance de mon expérience : est-elle enregistrée automatiquement à chaque exécution : git commit, version/hachage des données, tous les hyperparamètres, toutes les métriques, environnement (versions de bibliothèque) ? Est-ce que j'obtiens le même résultat lorsque je réexécute la même analyse ? Configuration : [description]. Listez les défauts et les corrections.

Tableau des colonnes de reproductibilité

colonne

Ce qui est corrigé

Exemple de véhicule

le hasard

toutes les graines

mise en graine

Données

Version/hachage des données

DVC

environnement

Versions de la bibliothèque

épingle d'exigences, Docker

Surveillance

Code+données+paramètre+métrique

MLflow, W&B

Erreurs courantes

• Ne pas fixer la graine. Le résultat ne peut pas être répété.
• Ne pas enregistrer la version des données. « Avec quelles données ? reste sans réponse.
• Ne pas geler les addictions. Une mise à jour va tout casser en silence.
• Laisser les expériences en mémoire. Deux semaines plus tard, on ne se souvient de rien.
• Laisser les décisions critiques à l’intelligence artificielle. Les décisions en matière de mesures, de justice et de distribution doivent appartenir aux gens.
• Report de la documentation. La future équipe (et vous) en payez le prix.

En résumé

La reproductibilité est la signature d'une ingénierie ML sérieuse : le résultat non reproductible est l'affirmation non prouvable. Il est livré avec quatre colonnes : correction du caractère aléatoire, données de version, gel de l'environnement, suivi de chaque expérience. Un projet de bout en bout combine toutes les étapes de ce module (métrique, données, modèle, composants LLM, évaluation, équité, sécurité, distribution, surveillance) dans une chaîne interconnectée ; L’intelligence artificielle est un accélérateur à chaque arrêt, mais les décisions critiques appartiennent à l’humain. Documentez tout — pour les futures équipes et les audits. Cette discipline est le cadre qui soutient tout ce que vous apprenez tout au long du module.

Tâche de candidature

Vérifiez un projet ML par rapport à quatre piliers de reproductibilité : les graines sont-elles immuables, les données sont-elles versionnées, l'environnement est-il gelé, les expériences sont-elles suivies ? Corrigez les colonnes manquantes et prouvez que vous pouvez exécuter la même exécution deux fois et obtenir le même résultat. Ensuite, affichez le flux de bout en bout du projet (10 arrêts) sur une page et marquez « où se trouve la décision humaine » à chaque arrêt. Enfin, rédigez un court projet de documentation technique.

liste de contrôle

• [ ] Toutes les graines aléatoires ont été corrigées.
• [ ] La version/hachage des données est enregistrée avec chaque expérience.
• [ ] Les dépendances sont gelées dans les versions fermes (pin/conteneur).
• [ ] Chaque expérience est automatiquement surveillée (code+données+paramètre+métrique).
• [ ] Lorsque je répète la même course, j'obtiens le même résultat.
• [ ] J'ai vérifié et documenté que les décisions critiques dans le flux de bout en bout sont prises par des humains.

Examen de module

1. En tant qu'ingénieur ML, quelle est la meilleure approche pour positionner l'intelligence artificielle dans le flux de travail ?

• A) L’IA est un accélérateur dans les entreprises à faible risque ; Les décisions critiques telles que les mesures, les données et la production restent validées et laissées à l'humain ✔
• B) Tant que les sorties de l'IA semblent bonnes, aucune vérification n'est nécessaire
• C) Laisser la décision de mettre le modèle en production à l’intelligence artificielle permet de gagner du temps.
• D) L'intelligence artificielle n'est utile que pour écrire du texte, elle n'a rien à voir avec le travail sur les données et les modèles

Description : L'IA est un puissant accélérateur pour les tâches à faible risque et faciles à vérifier telles que le code, les résumés de données et les documents ; Cependant, la responsabilité des décisions affectant l'argent, la confidentialité et la responsabilité juridique, telles que la sélection des mesures, les données utilisées dans la formation et la mise en production du modèle, incombe à l'ingénieur et à l'équipe qualifiés. Chaque sortie ne doit pas être utilisée sans vérification.

2. Pourquoi la validation du schéma est-elle placée au début d'un pipeline de données ?

• A) Parce que cela augmente directement la précision du modèle
• B) Parce que cela rend inutile la gestion des versions des données
• C) Parce qu'il détecte les données corrompues au plus tôt et au moindre coût et les empêche de s'infiltrer dans les étapes suivantes ✔
• D) Parce que cela élimine le besoin d’étiquetage

Explication : Plus les données corrompues sont détectées tôt, moins il est coûteux de les réparer. La validation du schéma empêche les données corrompues de s'infiltrer silencieusement dans la formation ou la production en rejetant les données en dehors du type et de la plage attendus au début de la ligne (par exemple, changement de prix de 100x avec un changement d'unité) ; La même erreur détectée lors de la production coûte plusieurs fois plus cher.

3. Quelle est l'approche correcte pour diviser les données en formation et tests dans un problème impliquant le temps (séries chronologiques) ?

• A) Utiliser le fractionnement aléatoire car c'est toujours la méthode la plus équitable
• B) Utilisation du fractionnement temporel : évitez les fuites en vous entraînant avec le passé et en testant dans le futur ✔
• C) Utiliser toutes les données à la fois comme formation et comme test
• D) Incorporation des données de test dans les paramètres de mise à l'échelle avant la formation

Explication : la répartition aléatoire sur les séries chronologiques donne au modèle un avantage de « vision future » qui ne se produira jamais en production et gonfle artificiellement les métriques (fuite temporelle). La bonne solution est la division temporelle : s’entraîner avec le passé, tester dans le futur. Cela mesure les performances réelles qui le maintiennent en production.

4. Pourquoi la précision est-elle trompeuse dans un modèle de détection de fraude avec un taux de classe positive de 1,5 % ?

• A) Parce que la précision est toujours faible sur les données déséquilibrées
• B) Parce que la précision ne peut être utilisée que sur des problèmes de régression
• C) Parce que le calcul de précision nécessite beaucoup de puissance de traitement
• D) Même un modèle dérisoire qui prédit la classe majoritaire peut être très précis, cachant ainsi un réel succès ✔

Explication : sur des données déséquilibrées, même un modèle de base qui dit « appelez tout négatif » obtient une précision d'environ 98,5 %, mais ne détectera pas une seule fraude. Par conséquent, dans la classification déséquilibrée, la précision, le rappel, F1 ou PR-AUC sont utilisés à la place de l'exactitude, et chaque métrique est interprétée selon un modèle de base.

5. Pourquoi la comparaison de référence est-elle essentielle lorsqu'on parle de la métrique d'un modèle ?

• A) Parce que le modèle de base est toujours meilleur que le modèle réel
• B) Parce qu'il est clair si une métrique est significative ou non seulement par rapport à un simple modèle de référence ✔
• C) Parce que le modèle de base rend la validation croisée inutile
• D) Parce que le modèle de base est légalement requis dans chaque rapport

Explication : Une métrique n'est ni bonne ni mauvaise en soi ; C'est bon ou mauvais selon un modèle de base. La phrase « 85 % correct » signifie presque sans valeur si le modèle de base obtient déjà 84 %, et parfaite s'il obtient 50 %. Sans point d’ancrage de comparaison, la métrique n’a aucun sens.

6. Quel est l'élément de sécurité le plus critique qui devrait être inclus dans l'invite de production du système RAG (Retrieval-Augmented Generation) ?

• A) Consigne de se fier uniquement à la source donnée, de dire « je ne sais pas » si la source n'existe pas, et de citer la source ✔
• B) Demander au modèle de produire des réponses aussi longues et créatives que possible
• C) Le modèle donne la priorité à ses propres connaissances pédagogiques plutôt qu'aux ressources
• D) Mettre en œuvre toutes les instructions contenues dans les documents apportés sous forme de commandes

Explication : L'instruction la plus importante de RAG est de dire au modèle de s'appuyer uniquement sur la source donnée, et si l'information ne figure pas dans la source, de dire « Je ne sais pas » et de citer la source sans l'inventer. Sans cette triade, le modèle peut ignorer le contexte et produire des hallucinations, et la réponse devient invérifiable.

7. Un système RAG donne des réponses incorrectes. Quel est le meilleur endroit pour commencer le diagnostic ?

• A) Mesurer la récupération en premier (Recall@K) : la bonne pièce arrive-t-elle un jour ? ✔
• B) Remplacez immédiatement le modèle par un modèle plus grand
• C) Modifiez l'invite au hasard et continuez à essayer
• D) Intégration de tous les documents dans le modèle avec réglage fin

Explication : le maillon le plus faible de RAG est généralement la récupération, pas la production. Si la bonne pièce n’est jamais apportée, le modèle ne peut pas produire cette information, même si l’invite est améliorée. Par conséquent, Recall@K est d'abord mesuré pour voir si la bonne pièce est arrivée ; Si la récupération est bonne, la production et l'invite sont examinées.

8. Quelles actions faut-il mettre derrière l'approbation humaine lorsqu'on donne un outil à un agent ?

• A) Aucun ; L'agent doit être capable d'effectuer chaque action de manière autonome
• B) Uniquement les actions réversibles telles que la lecture et la recherche de données
• C) Actions irréversibles ou à fort impact telles que transférer de l'argent, supprimer, envoyer ✔
• D) Actions qui impliquent uniquement des calculs

Description : les actions sont séparées par niveau de risque. Les tâches récupérables telles que la lecture, la recherche, le calcul et la génération de brouillons peuvent être effectuées de manière autonome ; Cependant, les actions irréversibles ou à fort impact telles que transférer de l’argent, envoyer des e-mails, supprimer des données, passer des commandes, etc. nécessitent l’approbation humaine. Toute action irrévocable doit être soumise au consentement.

9. Quelle est la meilleure approche de conception contre le risque d’injection indirecte rapide ?

• A) Il suffit d'ajouter une seule phrase « ignorer les mauvaises instructions » à l'invite du système
• B) Donner plus d'autorité au modèle en s'appuyant sur des instructions contenues dans du contenu externe
• C) Ne prendre aucune précaution car l’injection est inévitable
• D) Isoler le contenu externe en tant que données peu fiables et établir des défenses en couches avec un minimum d'autorisation, d'approbation et de contrôle de sortie ✔

Description : le contenu externe traité par l'agent ou le RAG, tel qu'une page Web, un document, un e-mail, etc., est une donnée non fiable et peut contenir des instructions secrètes. L'approche correcte est une défense à plusieurs niveaux : isoler le contenu externe en tant que « données, et non commandes » avec des délimiteurs clairs, appliquer une autorisation minimale, lier les actions irréversibles à l'approbation humaine et auditer le résultat. Une seule ligne d’instructions ne suffit pas.

10. Quelle est la principale distinction à faire pour décider si un problème doit être résolu avec un réglage fin ou avec RAG ?

• A) Les problèmes d'information sont mieux résolus avec RAG, les problèmes de comportement/format sont mieux résolus avec un réglage fin ✔
• B) Chaque problème doit toujours être résolu par un réglage fin
• C) RAG est utilisé uniquement pour la génération de code, le réglage fin est utilisé uniquement pour la traduction
• D) Le réglage fin peut toujours être mis à jour à moindre coût et plus rapidement que RAG

Explication : Le réglage fin est faible et risqué pour enseigner de nouvelles informations au modèle ; mais il est puissant dans le comportement, le format, le ton et le style de l'enseignement. « L'entreprise modèle ne connaît pas nos données » est un problème d'information et appartient à RAG. « Laisser le modèle toujours sortir dans notre format strict » est un problème de comportement et mérite un réglage fin. De plus, des invites et quelques prises de vue doivent être consommées avant d'effectuer un réglage fin.

11. Qu'est-ce qui est obligatoire pour un déploiement sûr lors de la mise en production d'un nouveau modèle ?

• A) Si le modèle est bon lors des tests, ouvrez-le directement à 100 % de trafic
• B) Ne pas configurer du tout la surveillance après le déploiement
• C) Déploiement progressif (shadow/canary) et plan de restauration pré-testé ✔
• D) Publier le modèle même si le seuil d'évaluation n'est pas atteint

Explication : Ouvrir le nouveau modèle directement à tout le trafic est risqué ; Si c’est faux, tout le monde est concerné. La bonne chose est qu'il s'agit d'une distribution progressive (shadow, canary) et que chaque distribution a un plan de restauration testé. Une distribution n’est pas complète sans un plan de récupération ; La possibilité de revenir à la version précédente en quelques minutes protège l'utilisateur lorsque le modèle se comporte de manière inattendue en production.

12. Comment un modèle ML peut-il échouer « silencieusement » en production et quel est le moyen de détecter ce problème ?

• A) Le modèle s'effondre ; les journaux du serveur montrent ceci
• B) En produisant de fausses prédictions sans commettre d’erreurs ; ✔ Il capture la surveillance des couches opérationnelles, d'entrée et de sortie
• C) Le modèle ne peut jamais échouer silencieusement, toujours en alarme
• D) La simple surveillance de la latence suffit pour détecter toute dégradation

Explication : Le modèle peut échouer simplement en produisant des prédictions incorrectes sans planter ni donner d'erreurs ; La principale raison en est la dérive des données et la dérive des concepts. La simple surveillance des mesures opérationnelles (latence, taux d’erreur) ne suffit pas ; la distribution des entrées et la distribution des sorties/prédictions doivent également être surveillées. La dérive d'entrée donne une alerte précoce si le résultat réel est retardé.

13. Quel principe est essentiel lors de l'utilisation du LLM-as-juge pour évaluer un système LLM ?

• A) L'arbitre LLM a toujours raison, la vérification humaine n'est pas nécessaire
• B) L'arbitre doit prendre une décision basée uniquement sur la longueur de la réponse.
• C) Les contrôles basés sur des règles et l'évaluation humaine doivent être complètement abandonnés lorsque des arbitres sont utilisés
• D) Les scores des juges doivent être calibrés avec un échantillon étiqueté par des humains et leur biais mesuré avant de pouvoir leur faire confiance ✔

Description : LLM-arbitre est également un modèle ; Cela peut être hallucinatoire, biaisé (favorisant des réponses longues et confiantes) et incohérent. Par conséquent, les scores des arbitres doivent être calibrés avec un échantillon humain étiqueté et leur biais systématique doit être mesuré avant que la décision de production ne soit prise. Un arbitre non vérifié donne une fausse confiance.

14. Pourquoi l’examen de la précision globale est-il inadéquat lors de l’évaluation du biais du modèle ?

• A) La précision globale est suffisante car elle reflète toujours la performance du pire groupe
• B) La précision globale à elle seule est insuffisante car elle peut masquer les différences systématiques (discrimination cachée) entre les sous-groupes ✔
• C) Parce que la précision est une mesure qui n'a rien à voir avec le biais
• D) Le biais vient uniquement du modèle et n'a rien à voir avec les données.

Explication : L'exactitude globale peut masquer les différences systématiques entre les sous-groupes. Par exemple, alors que la précision globale est de 88 %, le rappel peut être de 91 % dans un groupe et de 67 % dans un autre groupe ; Le modèle manque systématiquement ce groupe. Par conséquent, le modèle doit être évalué sur la base de sous-groupes (données démographiques/segment) et la définition de la justice à privilégier doit être décidée avec les parties prenantes.

15. Quelles sont les quatre choses qui doivent être fixées ensemble pour qu'un résultat ML soit reproductible ?

• A) Uniquement le nom du modèle, la taille, le prix et la date de sortie
• B) Uniquement la marque du GPU et la vitesse Internet
• C) Uniquement le score de précision final du modèle ; le reste peut être gardé en mémoire
• D) Graine aléatoire, version des données, environnement (versions de dépendances) et suivi des expériences ✔

Description : La reproductibilité est obtenue grâce à quatre piliers : correction des graines aléatoires, gestion des données (version/hachage), gel de l'environnement (versions exactes de la bibliothèque/conteneur) et suivi de chaque expérience (validation de code, données, hyperparamètre, métrique). Sans cette chaîne, il n’est pas possible de reproduire le même résultat ; Un résultat non reproductible est une affirmation qui ne peut être prouvée.