Gains :
- Capacité à reconnaître les défis particuliers du ML liés au trio et au package code-données-modèle et à présenter le modèle en ligne ou par lots selon les besoins de l'entreprise.
- Capacité à mettre en œuvre des modèles de déploiement progressif et de restauration (shadow, canary, A/B, rollback) et à ajouter un plan de restauration testé à chaque déploiement
- Capacité à conserver la traçabilité du lien données-code-métrique du modèle mis en production avec un CI/CD contrôlé par seuil d'évaluation et un registre de modèles
Obtenir un modèle permettant d'atteindre une précision de 95 % dans le cahier ne représente que la moitié de l'histoire. L’autre moitié – souvent la partie la plus difficile – consiste à transmettre ce modèle aux utilisateurs réels de manière fiable, évolutive et maintenable. MLOps (Machine Learning Operations : la discipline de mise en production, d'exploitation et de maintenance de modèles ML) combine les pratiques DevOps de l'ingénierie logicielle avec les défis uniques du ML. Dans cette unité, nous couvrons les étapes de passage du modèle à la production et la manière dont l'intelligence artificielle contribue à ce processus.
Pourquoi le ML est-il différent des logiciels classiques ?
Dans un logiciel ordinaire, le comportement est dans le code ; Si le code ne change pas, le comportement ne change pas. En ML, le comportement dépend à la fois du code, des données et du modèle. Ces trois dimensions créent les défis supplémentaires du MLOps :
- Dérive des données : les données en production s'éloignent des données en formation au fil du temps ; le modèle devient obsolète.
- Vous devez versionner trois éléments : le code, les données et le modèle, tous les trois.
- Échec silencieux : un modèle peut échouer sans planter, sans donner d’erreurs, simplement en produisant des prédictions incorrectes. Attraper cela nécessite une surveillance.
C'est pourquoi il existe une grande différence entre un « modèle fonctionnel » et un « modèle prêt pour la production ».
Conditionnement et présentation du modèle
La première étape de la mise en production du modèle consiste à le regrouper : le fichier modèle, les bibliothèques nécessaires, le code de prétraitement et les informations de version ensemble dans un tout reproductible. La conteneurisation (ex. Docker : mettre l'application dans une boîte isolée avec toutes ses dépendances) est ici standard ; Cela élimine le problème « cela fonctionnait sur ma machine ».
Deux modèles de base pour servir le modèle :
- En ligne/temps réel (en ligne) : le modèle se trouve derrière une API, renvoyant une prédiction instantanée pour chaque requête entrante. Une faible latence est essentielle.
- Lot : le modèle traite périodiquement de grands ensembles de données (par exemple, il génère des scores pour tous les clients la nuit). La latence n'a pas d'importance, l'efficacité est importante.
La solution qui convient dépend des besoins de l'entreprise : recommandation instantanée en ligne, score de risque mensuel par lots.
Astuce : Le "temps réel" est un coût et non la valeur par défaut. Le traitement par lots est beaucoup moins cher et plus simple si le résultat est utilisé en quelques heures. Avez-vous vraiment besoin d'une réponse instantanée ? Demandez-le d’abord.
Stratégies de distribution sécurisées
Ouvrir un nouveau modèle directement à tout le trafic est risqué ; Si c’est faux, tout le monde est concerné. Modèles de distribution sûrs :
- Déploiement fantôme : le nouveau modèle reçoit du trafic de production, mais ses prédictions ne sont pas présentées à l'utilisateur, mais uniquement enregistrées. Il est comparé à l'ancien modèle pour voir s'il est sûr dans les données réelles.
- Déploiement Canary : le nouveau modèle est d'abord déployé sur un petit pourcentage du trafic (par exemple 5 %) ; S’il n’y a pas de problème, on l’augmente progressivement.
- Tests A/B : deux modèles sont présentés en parallèle à l'utilisateur réel et les métriques commerciales (conversion, clics) sont comparées.
- Rollback : Possibilité de revenir rapidement à l’ancienne version si le nouveau modèle s’avère mauvais. Chaque déploiement doit avoir un plan de restauration.
Attention : Un déploiement sans plan de restauration n'est pas complet. La possibilité de revenir à l'ancienne version en quelques minutes protège l'utilisateur lorsque le nouveau modèle se comporte de manière inattendue en production. Testez ceci avant le déploiement.
Approche faible / Approche forte
Faible : "Le modèle s'est bien passé lors des tests, nous l'avons mis en ligne, nous l'avons ouvert à tout le monde."
Güçlü : "Nous avons conteneurisé le modèle, l'avons étiqueté comme version. Tout d'abord, nous l'avons exécuté en mode fantôme avec le trafic de production pendant 3 jours, en comparant les prédictions avec l'ancien modèle - l'écart était acceptable. Ensuite, nous l'avons ouvert avec 5 % de Canary, surveillé les mesures de débit et la latence. Lorsqu'il n'y a eu aucun problème, nous l'avons progressivement augmenté à 100 %. Nous avions préalablement testé la commande rollback."
La différence : l’approche forte est progressive, mesurée et réversible. Le risque est limité à chaque étape.
CI/CD et automatisation
CI/CD (Intégration continue / Déploiement continu : pipeline de tests et de publication automatiques des modifications de code) dans ML couvre non seulement le code mais également les étapes de données et de modèle. Un bon pipeline ML CI/CD : exécute des tests lorsque le code change, effectue la validation des données, recycle le modèle (si nécessaire), vérifie les seuils d'évaluation et ne fait avancer le déploiement que si les seuils sont respectés. Le principe « la formation est automatique, le déploiement est basé sur des seuils » empêche qu'un mauvais modèle ne s'infiltre silencieusement dans la production.
L'IA est très utile lors de la configuration de ces pipelines : rédaction de brouillons de fichiers de configuration (YAML), de scénarios de test, de scripts de déploiement. Mais vous déterminez les seuils de distribution (quelle que soit la mesure dépassant la valeur publiée) et la politique de restauration ; ce sont des décisions liées aux risques commerciaux.
Infrastructure de reproductibilité
Afin de reproduire le comportement d'un modèle en production, registre de modèles : un enregistrement qui conserve quel modèle a été formé avec quelles données et quel code, et quelles métriques il a reçu. Pour chaque modèle de production, les éléments suivants doivent être traçables : la version des données de formation, la version du code (git commit), les hyperparamètres, les scores d'évaluation et la date de déploiement. Lorsqu'un problème survient, vous devriez être capable de répondre à la question « quel modèle a produit cette prédiction, avec quelles données ? en quelques minutes. Nous approfondirons cela dans l’unité 11.
trois mini-cases
Cas 1 - Problème détecté par la distribution des ombres. Un modèle de recommandation a battu l'ancien lors des tests. L’exécution avec du trafic de production en mode fantôme s’est avérée produire de très mauvaises recommandations pour un segment particulier d’utilisateurs (nouveaux utilisateurs) – les données de test étaient sous-représentatives de ce segment. Le modèle a été corrigé sans jamais être affiché à l'utilisateur. S’il était ouvert directement, la nouvelle expérience utilisateur serait perturbée.
Cas 2 – Distribution irrévocable. Une équipe a déployé un nouveau modèle de tarification pour tout le trafic, sans plan de restauration. De manière inattendue, le modèle proposait certains produits à un prix très bas. Le retour à l'ancienne version a pris des heures car le processus n'était pas prêt. Il y a eu une grave perte de revenus. Par la suite, des tests de restauration obligatoires ont été ajoutés à chaque déploiement.
Cas 3 – Dérive silencieuse des données. Un modèle de fraude est apparu pendant des mois sans aucune erreur. Mais les tactiques des fraudeurs ont changé (dérive des données) et le rappel du modèle a diminué silencieusement. Personne ne l’a remarqué car il n’y avait aucune surveillance. Une fois qu’un comité de surveillance de la répartition des prévisions a été établi, la dérive est devenue visible très tôt. Nous aborderons la surveillance dans l’unité 8.
Modèles copiables
Rédigez un projet de plan de déploiement pour ce modèle. Modèle : [ce qu'il fait], utilisation : [en ligne ou par lots ?] Doit inclure : 1) Emballage (conteneur, gestion des versions) 2) Stratégie de déploiement incrémentiel (shadow/canary/A-B) et pourquoi 3) Métriques à suivre (métier + technique + latence) 4) Plan de restauration et comment tester 5) Seuils de déploiement (quelle métrique doit dépasser quelle valeur)
Vérifiez ce pipeline ML CI/CD : 1) La validation des données est-elle dans la ligne ? 2) Le déploiement peut-il se poursuivre sans maintenir le seuil d'évaluation (ne devrait-il pas) ?
Aidez-moi à décider si la présentation en ligne ou par lots convient à ce modèle. Combien de temps le résultat sera-t-il utilisé : [instant/minute/heure/jour]Volume de requête attendu : [nombre]Y a-t-il une contrainte de délai : [ms]Laquelle recommanderiez-vous en termes de coût et de complexité et pourquoi ?
Écrivez une procédure de restauration pour ce modèle.- Quelle métrique/seuil déclenche de mauvaises performances ?- Quelles sont les étapes de restauration ?- Combien de temps la restauration doit-elle prendre (cible) ?- Comment tester cette procédure avant la production ?
Tableau des modèles de présentation
critère
En ligne (en temps réel)
Lot
retard
Critique (ms)
insignifiant
Utilisation
Réponse instantanée requise
Score périodique
Coût
haut
faible
complexité
haut
faible
exemple
Recommandation en direct, arnaque
Score de risque mensuel
Erreurs courantes
- Distribuer sans plan de récupération. Un mauvais modèle touche l’ensemble de l’utilisateur.
- Ouverture directe au 100% trafic. Limitez les risques grâce à une distribution échelonnée.
- Ne pas établir de surveillance. Le modèle produit des erreurs silencieusement, sans erreur.
- Présentation redondante en temps réel. Même si le traitement par lots est suffisant, le coût et la complexité augmentent.
- Ne pas lier les versions modèle-données-code. Vous ne pouvez pas reproduire le problème.
- Libération automatique sans seuil de distribution. Le mauvais modèle se faufile silencieusement.
En résumé
Déplacer le modèle vers la production est une tâche d'ingénierie différente et souvent plus difficile que sa formation. Le ML nécessite une discipline supplémentaire car il dépend du trio code-données-modèle : packaging et versioning, modèle de livraison (en ligne/batch) adapté aux besoins de l'entreprise, déploiement progressif et réversible, CI/CD contrôlé par seuil et enregistrement du modèle. L’intelligence artificielle est une aide puissante pour générer le code et la configuration de cette infrastructure ; mais les seuils de distribution, la politique de récupération et les décisions en matière de risque vous appartiennent. Une distribution sans plan de restauration n'est pas complète.
Tâche de candidature
Conteneurisez (Docker) un modèle et étiquetez-le version. Décidez si vous proposez en ligne ou par lots en fonction des besoins de votre entreprise et rédigez votre justification. Documentez un plan de déploiement par étapes (shadow ou canary) et une procédure de restauration testée. Assurez-vous d'enregistrer la version des données, la validation du code et les scores d'évaluation dans le registre des modèles.
liste de contrôle
- [ ] Le modèle est packagé et versionné (conteneur + étiquette).
- [ ] Le modèle de présentation (en ligne/batch) a été choisi en fonction des besoins de l'entreprise.
- [ ] Stratégie de déploiement par étapes (shadow/canary) mise en œuvre.
- [ ] Procédure de rollback écrite et testée.
- [ ] CI/CD n'avance pas le déploiement avant que le seuil d'évaluation ne soit atteint.
- [ ] Le registre des modèles contient le lien données+code+métrique.