Guide

Besoin d'une plateforme centralisée et collaborative pour l'ensemble du cycle de vie de l'apprentissage automatique, de la préparation des données au déploiement et à la surveillance.

→Espace de travail Azure Machine Learning.

Pourquoi: C'est le service fondamental qui intègre tous les composants requis : calcul, magasins de données, environnements, suivi des expériences, registre de modèles et points de terminaison.

Référence↗

Exiger que tout le trafic de l'espace de travail ML, y compris vers des ressources dépendantes comme Storage et ACR, reste sur le réseau privé Azure et ne soit pas exposé à l'internet public.

→Configurer l'espace de travail Azure ML avec un réseau virtuel géré et utiliser des points de terminaison privés pour l'espace de travail et toutes ses ressources dépendantes (Storage, Key Vault, ACR).

Pourquoi: Les points de terminaison privés offrent une connectivité sécurisée et privée aux services Azure, garantissant que le trafic ne traverse pas l'internet public. Un réseau virtuel géré (VNet) simplifie cette configuration pour le calcul ML.

Référence↗

La solution ML doit respecter des règles strictes de résidence des données, garantissant que toutes les données et le calcul restent dans une région géographique spécifique (par exemple, l'Union Européenne).

→Créer l'espace de travail Azure ML, tous les comptes de stockage associés et les ressources de calcul dans une région de la géographie requise. Utiliser l'isolation réseau pour prévenir l'exfiltration de données.

Pourquoi: Les ressources Azure sont liées à la région dans laquelle elles sont créées. Cela garantit la conformité de l'emplacement physique des données. L'isolation réseau (VNet géré) empêche le traitement des données en dehors de cette limite.

Appliquer les normes organisationnelles à tous les espaces de travail ML, telles que l'exigence de balises d'allocation de coûts, la restriction des tailles de VM ou l'obligation d'expédition des journaux de diagnostic.

→Utiliser Azure Policy pour appliquer et faire respecter les règles de création et de configuration des ressources.

Pourquoi: Azure Policy offre une gouvernance évolutive et centralisée. Il empêche la création de ressources non conformes, garantissant des normes cohérentes sans supervision manuelle.

Référence↗

Accéder aux données dans Azure Storage depuis un espace de travail ML sans stocker les informations d'identification (clés de compte, jetons SAS) dans le code ou la configuration.

→Créer la connexion au magasin de données en utilisant l'authentification basée sur l'identité. Accorder l'identité gérée de l'espace de travail (ou l'identité de l'utilisateur/calcul) le rôle RBAC approprié (par exemple, Lecteur des données de blob de stockage) sur le compte de stockage.

Pourquoi: Il s'agit d'un modèle sans informations d'identification et de confiance zéro qui utilise Azure AD pour l'authentification, améliorant la sécurité et simplifiant la gestion des informations d'identification.

Plusieurs équipes travaillent sur des projets avec différents niveaux de sécurité (par exemple, PII versus données anonymisées). Nécessité de fournir une isolation des ressources.

→Créer des espaces de travail Azure ML distincts pour chaque limite de sécurité. Un espace de travail pour les projets PII devrait avoir une isolation réseau plus stricte que celui pour les projets non sensibles.

Pourquoi: L'espace de travail est la principale limite de sécurité et d'isolation. La séparation par niveau de sécurité est une bonne pratique pour prévenir les fuites de données et appliquer des contrôles appropriés.

Nécessité de séparer les activités de développement/expérimentation de l'entraînement et du déploiement de modèles de qualité production pour éviter les interférences et assurer la stabilité.

→Utiliser des espaces de travail Azure ML distincts pour les environnements de développement et de production.

Pourquoi: Cela isole les ressources de production, les données et les modèles du travail expérimental, offrant stabilité et gouvernance claire pour les pipelines MLOps de production.

Provisionner des ressources de calcul pour les tâches d'entraînement ML qui s'exécutent par intermittence, avec une priorité élevée sur la minimisation des coûts.

→Utiliser un cluster de calcul Azure ML avec des VM à faible priorité, un nombre minimal de nœuds de 0 et une mise à l'échelle automatique configurée.

Pourquoi: Les VM à faible priorité permettent des économies significatives pour les charges de travail interruptibles. Un minimum de 0 nœud garantit que vous ne payez rien lorsque le cluster est inactif.

Référence↗

Nécessité de provisionner des ressources de calcul à la fois pour le développement interactif de notebooks par des data scientists individuels et pour l'exécution de tâches d'entraînement plus importantes et sans surveillance.

→Provisionner des instances de calcul (Compute Instances) pour le développement interactif (une par utilisateur). Provisionner des clusters de calcul (Compute Clusters) pour les tâches d'entraînement par lots.

Pourquoi: Les instances de calcul sont des VM mono-utilisateur, persistantes, optimisées pour le travail interactif. Les clusters de calcul sont des ressources multi-nœuds, auto-évolutives, optimisées pour les tâches par lots.

Assurer que les exécutions d'entraînement ML sont reproductibles en capturant toutes les dépendances logicielles, y compris les versions spécifiques des packages Python.

→Définir un environnement Azure ML à l'aide d'un fichier YAML d'environnement conda ou d'un Dockerfile. Enregistrer et versionner cet environnement pour l'utiliser dans les tâches d'entraînement.

Pourquoi: Les environnements sont des spécifications versionnées et réutilisables d'un runtime. Cela découple l'environnement du calcul, garantissant que toute exécution avec cette version d'environnement est identique.

La logique d'ingénierie des caractéristiques doit être cohérente entre l'entraînement et l'inférence, et les caractéristiques doivent être réutilisables sur plusieurs modèles et équipes.

→Utiliser Azure ML Managed Feature Store pour définir, calculer et servir les caractéristiques.

Pourquoi: Un magasin de caractéristiques assure la cohérence (empêchant l'écart entraînement-service), permet la découverte et la réutilisation des caractéristiques, et fournit un stockage à la fois hors ligne (pour l'entraînement) et en ligne (pour l'inférence à faible latence).

Suivre systématiquement toutes les expériences ML, y compris les versions de code, les hyperparamètres, les métriques et les artefacts de modèle, pour la comparaison et la reproductibilité.

→Utiliser MLflow, qui est nativement intégré à Azure ML. Activer l'autologging ou utiliser des commandes `mlflow.log_*` explicites dans le script d'entraînement.

Pourquoi: MLflow fournit un cadre standardisé et open-source pour le suivi des expériences. Azure ML agit comme un serveur de suivi MLflow géré, offrant une interface utilisateur pour comparer les exécutions.

Référence↗

Entraîner un modèle de classification sur un ensemble de données présentant un déséquilibre de classe sévère (par exemple, détection de fraude), entraînant des performances médiocres sur la classe minoritaire.

→Appliquer des techniques comme SMOTE (Synthetic Minority Over-sampling Technique) aux données d'entraînement. Évaluer le modèle en utilisant des métriques insensibles au déséquilibre, telles que l'AUC Précision-Rappel ou le score F1.

Pourquoi: Utiliser simplement la précision est trompeur. SMOTE crée des échantillons synthétiques de la classe minoritaire pour aider le modèle à apprendre, et l'AUC PR/score F1 mesure correctement les performances sur la classe positive.

Nécessité de trouver les hyperparamètres optimaux pour un modèle avec un temps d'entraînement long et un budget de calcul limité.

→Utiliser une tâche de balayage (sweep job) avec un échantillonnage bayésien et une politique d'arrêt anticipé (par exemple, Bandit ou Median Stopping).

Pourquoi: L'échantillonnage bayésien explore intelligemment l'espace de recherche, se concentrant sur les régions prometteuses. L'arrêt anticipé met fin aux exécutions peu performantes plus tôt, économisant un temps de calcul et des coûts significatifs.

Construire un modèle de prévision de séries chronologiques à l'aide d'AutoML.

→Configurer la tâche AutoML avec `task='forecasting'`, spécifier le `time_column_name`, et définir le `forecast_horizon`.

Pourquoi: Spécifier la tâche comme "forecasting" permet à AutoML d'appliquer des techniques spécifiques aux séries chronologiques comme la génération de caractéristiques de décalage, la détection de saisonnalité et la validation croisée sensible au temps.

Entraîner un grand modèle d'apprentissage profond sur plusieurs GPU et plusieurs nœuds de calcul pour réduire le temps d'entraînement.

→Utiliser un cluster de calcul avec des nœuds compatibles GPU. Dans la tâche de commande, configurer la propriété `distribution` (par exemple, `type: "PyTorch"`, `process_count_per_instance: <# GPUs>`).

Pourquoi: Azure ML simplifie l'entraînement distribué en gérant la configuration des nœuds et la communication. La configuration `distribution` indique à Azure ML comment lancer les processus d'entraînement distribués.

Référence↗

Automatiser un flux de travail ML multi-étapes (par exemple, préparation des données, entraînement, évaluation) qui peut être réutilisé avec différents paramètres.

→Définir un pipeline Azure ML en utilisant des composants pour chaque étape. Utiliser les entrées du pipeline pour paramétrer le flux de travail.

Pourquoi: Les pipelines basés sur des composants favorisent la modularité et la réutilisabilité. Ils prennent également en charge la mise en cache automatique des étapes (réutilisation), ce qui permet de gagner du temps en ne réexécutant pas les étapes dont les entrées n'ont pas changé.

Un modèle fonctionne très bien sur l'ensemble d'entraînement mais mal sur l'ensemble de validation, comme l'indique une courbe de perte d'entraînement et de validation divergente.

→C'est un signe classique de surapprentissage. Atténuer en appliquant une régularisation (par exemple, dropout, L2), en utilisant l'augmentation des données, en implémentant l'arrêt anticipé ou en réduisant la complexité du modèle.

Pourquoi: L'écart entre les performances d'entraînement et de validation montre que le modèle a mémorisé les données d'entraînement au lieu de généraliser. Les techniques de régularisation pénalisent la complexité pour améliorer la généralisation.

Une tâche d'entraînement de longue durée sur des VM à faible priorité (spot) risque d'être préemptée et de perdre sa progression.

→Implémenter la journalisation des points de contrôle (checkpointing) dans le script d'entraînement pour sauvegarder périodiquement l'état du modèle et de l'optimiseur dans le répertoire `./outputs`.

Pourquoi: Le répertoire `./outputs` est automatiquement persisté par Azure ML. La sauvegarde des points de contrôle permet de reprendre la tâche à partir du dernier état enregistré en cas de préemption, préservant la progression et économisant des coûts.

Une organisation a une politique selon laquelle seuls certains algorithmes ML peuvent être utilisés en production. Nécessité de l'appliquer lors des exécutions AutoML.

→Dans la configuration AutoML, utiliser le paramètre `blocked_models` pour exclure explicitement les algorithmes non approuvés de l'espace de recherche.

Pourquoi: Cela offre un moyen direct et applicable d'aligner AutoML sur les politiques de gouvernance, empêchant la sélection de modèles non conformes.

Déployer un modèle pour des prédictions en temps réel, à faible latence (<100ms) et avec une haute disponibilité.

→Déployer le modèle vers un point de terminaison en ligne géré Azure ML (Managed Online Endpoint).

Pourquoi: Les points de terminaison en ligne gérés sont un service entièrement géré optimisé pour l'inférence en temps réel, offrant l'auto-scaling, l'équilibrage de charge, les déploiements bleu-vert et la surveillance intégrée.

Référence↗

Scorer un grand volume de données (millions d'enregistrements) de manière asynchrone, l'efficacité des coûts étant une priorité.

→Déployer le modèle vers un point de terminaison de lot Azure ML (Batch Endpoint).

Pourquoi: Les points de terminaison de lot sont conçus pour le scoring asynchrone et à haut débit de grands ensembles de données. Ils peuvent utiliser des clusters de calcul évolutifs qui se réduisent à zéro lorsqu'ils sont inactifs, optimisant ainsi les coûts.

Déployer une nouvelle version de modèle tout en minimisant les risques. Nécessité de basculer progressivement le trafic vers la nouvelle version et de permettre un retour arrière facile.

→Utiliser un seul point de terminaison en ligne géré avec deux déploiements (par exemple, "bleu" pour l'ancien modèle, "vert" pour le nouveau). Utiliser la répartition du trafic pour contrôler le pourcentage de requêtes allant à chaque déploiement.

Pourquoi: Ce modèle de déploiement bleu-vert permet des déploiements sûrs et sans interruption. Vous pouvez valider le nouveau modèle sur une petite partie du trafic en direct avant de vous engager dans un basculement complet.

Empaqueter un modèle avec ses dépendances et artefacts de manière standardisée et indépendante du cadre pour le déploiement.

→Utiliser le format de modèle MLflow. Lors de l'enregistrement du modèle, inclure le fichier conda.yaml ou requirements.txt et tous les artefacts de code nécessaires.

Pourquoi: MLflow fournit une convention de packaging de modèles standard qu'Azure ML comprend nativement. Cela simplifie le déploiement car Azure ML peut construire automatiquement l'environnement requis.

Un modèle déployé a une latence élevée car il charge de grands fichiers auxiliaires (par exemple, un grand featurizer) à chaque requête de prédiction.

→Déplacer la logique de chargement des fichiers de la fonction `run()` vers la fonction `init()` dans le script de scoring.

Pourquoi: La fonction `init()` ne s'exécute qu'une seule fois au démarrage du conteneur. Charger les actifs ici les rend globalement disponibles pour tous les appels à `run()`, évitant ainsi un chargement redondant à chaque requête.

Un point de terminaison en temps réel connaît un trafic variable (pics élevés, creux bas). Nécessité de maintenir les performances de manière rentable.

→Configurer l'auto-scaling sur le déploiement du point de terminaison en ligne géré. Définir un nombre minimum et maximum d'instances et une règle de mise à l'échelle basée sur l'utilisation du CPU ou la latence des requêtes.

Pourquoi: L'auto-scaling ajuste automatiquement le nombre d'instances de calcul pour correspondre à la charge de trafic, garantissant les performances pendant les pics et économisant des coûts pendant les accalmies.

Un déploiement de modèle nécessite des bibliothèques système spécifiques, des versions CUDA personnalisées ou un serveur d'inférence personnalisé non présents dans les images Azure ML par défaut.

→Créer un Dockerfile personnalisé qui étend une image d'inférence de base Azure ML, ajouter les dépendances requises, la construire et la pousser vers Azure Container Registry. Référencer cette image dans l'environnement de déploiement.

Pourquoi: L'extension d'une image de base offre un contrôle total sur l'environnement d'exécution tout en maintenant la compatibilité avec l'infrastructure de service d'Azure ML.

Automatiser le cycle de vie ML de bout en bout, y compris le réentraînement, l'évaluation et le déploiement, déclenché par des changements de code ou de données.

→Utiliser Azure DevOps ou GitHub Actions intégrés à l'interface CLI v2 d'Azure ML pour créer un pipeline CI/CD. Le pipeline doit inclure une porte de qualité qui compare le nouveau modèle à une référence avant le déploiement.

Pourquoi: Ce modèle MLOps automatise le flux de travail ML, garantissant cohérence, qualité et itération rapide. La porte de qualité empêche les régressions de performance du modèle.

La performance d'un modèle en production se dégrade en raison de changements dans la distribution des données d'entrée. Le modèle doit être réentraîné automatiquement lorsqu'une dérive significative est détectée.

→Configurer un moniteur de dérive des données Azure ML sur le point de terminaison. Mettre en place une alerte qui déclenche une Azure Logic App ou une Azure Function, qui à son tour démarre le pipeline de réentraînement.

Pourquoi: Cela crée un système MLOps en boucle fermée qui maintient automatiquement la pertinence du modèle en réponse aux changements des schémas de données, sans intervention manuelle.

Une version de modèle nouvellement déployée s'avère défectueuse en production. Nécessité de revenir rapidement à la version stable précédente.

→Si vous utilisez un déploiement bleu-vert, basculez 100 % du trafic vers le déploiement stable. Alternativement, mettez à jour le point de terminaison pour redéployer la version précédente du modèle à partir du registre de modèles.

Pourquoi: Le basculement du trafic offre un retour arrière instantané. Redéployer une version du registre est également un moyen rapide et fiable de restaurer un état connu et fonctionnel.

Nécessité de surveiller à la fois la santé opérationnelle (latence, erreurs) et la qualité prédictive (dérive des données, précision) d'un modèle déployé.

→Activer l'intégration d'Application Insights sur le point de terminaison pour les métriques opérationnelles. Configurer la collecte de données Azure ML et la surveillance de la dérive des données pour les métriques de qualité du modèle.

Pourquoi: Cette approche à deux volets offre une vue complète de la santé du modèle. App Insights suit les performances du système, tandis que la collecte de données/la surveillance de la dérive suit les performances prédictives du modèle.

Le point de terminaison du modèle échoue en raison de données d'entrée mal formées ou inattendues de la part des clients.

→Implémenter une logique de validation des entrées dans la fonction `run()` du script de scoring. Vérifier les types de données, les plages et les structures, et retourner une erreur significative (par exemple, HTTP 400) pour les requêtes invalides.

Pourquoi: La validation côté serveur protège le modèle des plantages et fournit un feedback clair et immédiat aux consommateurs d'API, rendant le service plus robuste.

Nécessité de comprendre pourquoi un modèle complexe de "boîte noire" fait certaines prédictions, à des fins de débogage, de conformité ou de confiance des parties prenantes.

→Utiliser le tableau de bord Responsible AI dans Azure ML pour générer des explications de modèle. Utiliser SHAP pour les explications locales (prédiction individuelle) et l'importance globale des caractéristiques pour le comportement général du modèle.

Pourquoi: Les valeurs SHAP fournissent un moyen robuste et agnostique du modèle pour attribuer l'impact de chaque caractéristique sur une prédiction spécifique, ce qui est crucial pour les scénarios réglementaires et de débogage.

Un modèle utilisé pour des décisions comme l'approbation de prêts doit être équitable et ne pas discriminer les groupes démographiques protégés.

→Utiliser l'évaluation de l'équité du tableau de bord Responsible AI pour analyser les métriques d'équité (par exemple, parité démographique, cotes égalisées) sur les caractéristiques sensibles. Appliquer des techniques d'atténuation comme les ajustements de seuil post-traitement si des disparités sont trouvées.

Pourquoi: L'évaluation de l'équité fournit des preuves quantitatives du comportement d'un modèle à travers les groupes. Les techniques d'atténuation aident à corriger les biais pour garantir des résultats équitables.

Un LLM doit répondre à des questions basées sur des documents d'entreprise spécifiques et privés sans halluciner des faits.

→Implémenter un modèle de Génération Augmentée par Récupération (RAG). Utiliser Azure AI Search pour créer un index vectoriel des documents. Au moment de la requête, récupérer les fragments de document pertinents et les transmettre au LLM comme contexte dans l'invite.

Pourquoi: Le RAG ancre la réponse du LLM dans des informations factuelles et à jour, réduisant considérablement les hallucinations et lui permettant d'utiliser des connaissances non présentes dans ses données d'entraînement originales.

Un LLM doit suivre de manière cohérente des directives spécifiques, un ton et des formats de sortie (par exemple, générer du JSON).

→Utiliser une ingénierie d'invites système détaillée. Fournir un persona clair, des règles et contraintes explicites, et des exemples "few-shot" de paires entrée/sortie souhaitées.

Pourquoi: Une invite système bien conçue est le moyen le plus direct et le plus efficace d'orienter le comportement d'un LLM sans le coût et la complexité du fine-tuning.

Nécessité de mesurer la qualité d'une application LLM basée sur le RAG.

→Utiliser des métriques d'évaluation spécifiques au RAG, telles que la Fondement (la réponse est-elle étayée par le contexte ?) et la Pertinence (la réponse répond-elle à la question de l'utilisateur ?).

Pourquoi: Les métriques NLP standard comme ROUGE sont insuffisantes. La Fondement et la Pertinence mesurent directement les défis fondamentaux du RAG : prévenir l'hallucination et fournir des réponses utiles.

Une application LLM est trop lente ou coûteuse pour une utilisation en production.

→Implémenter un routeur pour utiliser des modèles plus petits et moins chers (par exemple, GPT-3.5-Turbo) pour les tâches simples. Activer la mise en cache des réponses pour les requêtes répétées. Optimiser la longueur de l'invite.

Pourquoi: Utiliser un modèle de taille appropriée pour la tâche est la mesure la plus efficace pour réduire les coûts. La mise en cache élimine les appels API redondants, réduisant directement les coûts et la latence.

Une application LLM traite des données sensibles qui ne doivent pas quitter le réseau d'entreprise ni être utilisées pour l'entraînement du modèle.

→Déployer le service Azure OpenAI avec un point de terminaison privé. Configurer la ressource pour ne pas journaliser les données d'invite/achèvement.

Pourquoi: Les points de terminaison privés garantissent l'isolation du réseau. L'option de non-journalisation offre une couche supplémentaire de confidentialité des données, répondant aux exigences strictes de conformité.

Un flux d'invite développé dans Azure AI Studio doit être déployé comme un point de terminaison de production hautement disponible et évolutif.

→Déployer le flux d'invite en tant que point de terminaison en ligne géré Azure ML.

Pourquoi: Cela offre un chemin transparent du développement à la production, en tirant parti de la même infrastructure robuste (auto-scaling, équilibrage de charge, surveillance) utilisée pour les modèles ML traditionnels.

Une application d'IA générative destinée aux utilisateurs doit être protégée contre la génération ou le traitement de contenu nuisible, offensant ou dangereux.

→Utiliser à la fois les filtres de contenu intégrés d'Azure OpenAI et le service Azure AI Content Safety pour une modération approfondie des invites et des achèvements.

Pourquoi: La sécurité en couches est essentielle. Les filtres intégrés fournissent une base, tandis que le service dédié Content Safety offre un contrôle plus granulaire et des capacités multi-modales.

Un chatbot d'IA conversationnel doit maintenir le contexte sur plusieurs tours d'utilisateur.

→Les LLM sont sans état. L'application doit gérer l'historique de la conversation (par exemple, dans une session ou une base de données) et inclure les parties pertinentes de l'historique dans chaque nouvelle invite au LLM.

Pourquoi: Fournir explicitement le contexte dans chaque appel API est le seul moyen pour un LLM sans état de "se souvenir" de la conversation.

Nécessité de tester systématiquement différentes invites pour trouver celle qui offre les meilleures performances LLM.

→Utiliser les variantes de flux d'invite (prompt flow Variants). Définir plusieurs versions d'invite pour un nœud et exécuter un test en bloc sur un ensemble de données d'évaluation pour comparer les métriques de performance.

Pourquoi: Les variantes offrent une approche structurée et basée sur les données pour l'ingénierie des invites, allant au-delà de l'essai-erreur manuel vers l'optimisation systématique.

Nécessité de surveiller une application LLM en production à la fois pour la santé opérationnelle et la qualité des réponses.

→Combiner Application Insights pour la télémétrie opérationnelle (latence, taux d'erreur, utilisation des jetons) avec des tâches d'évaluation par lots périodiques utilisant un flux d'évaluation pour évaluer la qualité des réponses (fondement, pertinence).

Pourquoi: La surveillance des LLM nécessite le suivi des performances du système et de la qualité du contenu généré. Cette combinaison offre une vue holistique de la santé de l'application.