Félicitations ! Vous avez déployé le modèle de licorne. Votre modèle doit fonctionner 24h/24 et 7j/7 sans problème. Pour vous en assurer, vous devez surveiller votre pipeline de machine learning (ML).
Écrire un schéma de données pour valider les données brutes
Pour surveiller vos données, vous devez les comparer en permanence aux valeurs statistiques attendues en écrivant des règles que les données doivent respecter. Cet ensemble de règles est appelé schéma de données. Définissez un schéma de données en procédant comme suit :
Comprendre la plage et la distribution de vos caractéristiques. Pour les caractéristiques catégorielles, comprenez l'ensemble des valeurs possibles.
Intégrez votre compréhension dans le schéma de données. Voici quelques exemples de règles :
- Assurez-vous que les notes envoyées par les utilisateurs sont toujours comprises entre 1 et 5.
- Vérifiez que le mot the est le plus fréquent (pour une fonctionnalité de texte en anglais).
- Vérifiez que chaque caractéristique catégorielle est définie sur une valeur issue d'un ensemble fixe de valeurs possibles.
Testez vos données par rapport au schéma de données. Votre schéma doit détecter les erreurs de données telles que :
- Anomalies
- Valeurs inattendues des variables catégorielles
- Distributions de données inattendues
Écrire des tests unitaires pour valider l'ingénierie des caractéristiques
Même si vos données brutes peuvent passer le schéma de données, votre modèle ne s'entraîne pas sur des données brutes. Au contraire, votre modèle s'entraîne sur des données qui ont été conçues. Par exemple, votre modèle s'entraîne sur des caractéristiques numériques normalisées plutôt que sur des données numériques brutes. Étant donné que les données d'ingénierie des caractéristiques peuvent être très différentes des données d'entrée brutes, vous devez les vérifier séparément.
Créez des tests unitaires en fonction de votre compréhension des données d'ingénierie des caractéristiques. Par exemple, vous pouvez écrire des tests unitaires pour vérifier des conditions telles que les suivantes :
- Toutes les caractéristiques numériques sont mises à l'échelle (par exemple, entre 0 et 1).
- Les vecteurs à encodage one-hot ne contiennent qu'un seul 1 et N-1 zéros.
- Les distributions de données après transformation sont conformes aux attentes. Par exemple, si vous avez normalisé les données à l'aide de scores Z, la moyenne des scores Z doit être égale à 0.
- Les valeurs aberrantes sont gérées, par exemple par mise à l'échelle ou écrêtement.
Vérifier les métriques pour les segments de données importants
Un ensemble réussi peut parfois masquer un sous-ensemble qui ne l'est pas. En d'autres termes, un modèle avec d'excellentes métriques globales peut toujours faire de mauvaises prédictions dans certaines situations. Exemple :
Votre modèle de licorne est globalement performant, mais il l'est moins lorsqu'il s'agit de faire des prédictions pour le désert du Sahara.
Si vous êtes le genre d'ingénieur satisfait d'une excellente AUC globale, vous ne remarquerez peut-être pas les problèmes du modèle dans le désert du Sahara. Si vous devez faire de bonnes prédictions pour chaque région, vous devez suivre les performances de chacune d'elles. Les sous-ensembles de données, comme celui correspondant au désert du Sahara, sont appelés tranches de données.
Identifiez les tranches de données qui vous intéressent. Comparez ensuite les métriques du modèle pour ces tranches de données à celles de l'ensemble de données complet. Vérifier que votre modèle fonctionne bien dans toutes les tranches de données permet d'éliminer les biais. Pour en savoir plus, consultez Équité : évaluer les biais.
Utiliser des métriques concrètes
Les métriques de modèle ne mesurent pas nécessairement l'impact réel de votre modèle. Par exemple, la modification d'un hyperparamètre peut augmenter l'AUC d'un modèle, mais comment cette modification a-t-elle affecté l'expérience utilisateur ? Pour mesurer l'impact réel, vous devez définir des métriques distinctes. Par exemple, vous pouvez interroger les utilisateurs de votre modèle pour confirmer qu'ils ont bien vu une licorne lorsque le modèle l'a prédit.
Vérifier le décalage entraînement/mise en service
Le décalage entraînement/service signifie que vos données d'entrée pendant l'entraînement diffèrent de vos données d'entrée lors de la diffusion. Le tableau suivant décrit les deux types de biais importants :
| Type | Définition | Exemple | Solution |
|---|---|---|---|
| Déséquilibre du schéma | Les données d'entrée d'entraînement et de diffusion ne sont pas conformes au même schéma. | Le format ou la distribution des données de diffusion changent alors que votre modèle continue de s'entraîner sur d'anciennes données. | Utilisez le même schéma pour valider les données d'entraînement et de diffusion. Assurez-vous de vérifier séparément les statistiques non vérifiées par votre schéma, comme la fraction des valeurs manquantes. |
| Écart au niveau des caractéristiques | Les données conçues diffèrent entre l'entraînement et la diffusion. | Le code d'ingénierie des caractéristiques diffère entre l'entraînement et la diffusion, ce qui produit des données conçues différentes. | Comme pour le décalage de schéma, appliquez les mêmes règles statistiques aux données d'entraînement et de diffusion. Suivez le nombre de caractéristiques biaisées détectées et le ratio d'exemples biaisés par caractéristique. |
Les causes du décalage entre entraînement et mise en service peuvent être subtiles. Tenez toujours compte des données disponibles pour votre modèle au moment de la prédiction. Lors de l'entraînement, n'utilisez que les caractéristiques qui seront disponibles lors de l'inférence.
Exercice : Vérifier que vous avez bien compris
Imaginons que vous possédiez une boutique en ligne et que vous souhaitiez prédire le montant des revenus que vous générerez un jour donné. Votre objectif de ML est de prédire les revenus quotidiens en utilisant le nombre de clients comme caractéristique.
Réponse : Le problème est que vous ne connaissez pas le nombre de clients au moment de la prédiction, avant que les ventes de la journée ne soient terminées. Cette fonctionnalité n'est donc pas utile, même si elle est fortement prédictive de vos revenus quotidiens. De même, lorsque vous entraînez un modèle et que vous obtenez des métriques d'évaluation exceptionnelles (comme une AUC de 0,99), recherchez ces types de caractéristiques qui peuvent se répercuter sur votre libellé.
Vérifier la fuite de libellés
La fuite d'étiquettes signifie que les étiquettes de vérité terrain que vous essayez de prédire ont été insérées par inadvertance dans vos caractéristiques d'entraînement. Il est parfois très difficile de détecter les fuites de libellés.
Exercice : Vérifier que vous avez bien compris
Supposons que vous créiez un modèle de classification binaire pour prédire si un nouveau patient hospitalisé est atteint d'un cancer. Votre modèle utilise des fonctionnalités telles que les suivantes :
- Âge du patient
- Genre du patient
- Problèmes de santé antérieurs
- Nom de l'hôpital
- Signes vitaux
- Résultats des tests
- Hérédité
Le libellé est le suivant :
- Booléen : le patient est-il atteint d'un cancer ?
Vous partitionnez soigneusement les données, en veillant à ce que votre ensemble d'entraînement soit bien isolé de votre ensemble de validation et de votre ensemble de test. Le modèle fonctionne extrêmement bien sur l'ensemble de validation et l'ensemble de test. Les métriques sont fantastiques. Malheureusement, le modèle obtient des résultats médiocres avec les nouveaux patients dans le monde réel.
Réponse : Le nom de l'hôpital est l'une des caractéristiques du modèle. Certains hôpitaux sont spécialisés dans le traitement du cancer. Lors de l'entraînement, le modèle a rapidement appris que les patients affectés à certains hôpitaux étaient très susceptibles d'avoir un cancer. Le nom de l'hôpital est donc devenu une caractéristique très pondérée.
Au moment de l'inférence, la plupart des patients n'avaient pas encore été affectés à un hôpital. Après tout, l'objectif du modèle était de diagnostiquer la présence ou l'absence de cancer, puis d'utiliser ce diagnostic pour orienter le patient vers un hôpital approprié. Par conséquent, lors de l'inférence, la caractéristique du nom de l'hôpital n'était pas encore disponible et le modèle a été contraint de s'appuyer sur d'autres caractéristiques.
Surveiller l'âge du modèle tout au long du pipeline
Si les données de diffusion évoluent au fil du temps, mais que votre modèle n'est pas réentraîné régulièrement, la qualité du modèle diminuera. Suivez le temps écoulé depuis le réentraînement du modèle sur de nouvelles données et définissez un seuil d'ancienneté pour les alertes. En plus de surveiller l'âge du modèle lors de la diffusion, vous devez le surveiller tout au long du pipeline pour détecter les blocages.
Tester la stabilité numérique des pondérations et des sorties du modèle
Pendant l'entraînement du modèle, vos pondérations et vos sorties de couche ne doivent pas être NaN (Not a Number) ni Inf (infini). Écrivez des tests pour vérifier les valeurs NaN et Inf de vos pondérations et sorties de couches. Testez également que plus de la moitié des sorties d'un calque ne sont pas nulles.
Surveiller les performances du modèle
Votre outil de prédiction de l'apparence de licorne a été plus populaire que prévu ! Vous recevez de nombreuses demandes de prédiction et encore plus de données d'entraînement. Vous pensez que c'est une bonne chose jusqu'à ce que vous vous rendiez compte que votre modèle prend de plus en plus de mémoire et de temps à entraîner. Vous décidez de surveiller les performances de votre modèle en suivant ces étapes :
- Suivez les performances du modèle en fonction des versions du code, du modèle et des données. Ce suivi vous permet d'identifier la cause exacte de toute dégradation des performances.
- Testez le nombre d'étapes d'entraînement par seconde pour une nouvelle version du modèle par rapport à la version précédente et à un seuil fixe.
- Détectez les fuites de mémoire en définissant un seuil d'utilisation de la mémoire.
- Surveillez les temps de réponse des API et suivez leurs centiles. Bien que les temps de réponse de l'API puissent être hors de votre contrôle, des réponses lentes peuvent potentiellement entraîner de mauvaises métriques réelles.
- Surveillez le nombre de requêtes auxquelles il est répondu par seconde.
Tester la qualité du modèle en production sur les données diffusées
Vous avez validé votre modèle. Mais que se passe-t-il si des scénarios réels, comme le comportement des licornes, changent après l'enregistrement de vos données de validation ? La qualité de votre modèle diffusé se dégradera alors. Toutefois, il est difficile de tester la qualité de la diffusion, car les données réelles ne sont pas toujours étiquetées. Si vos données de diffusion ne sont pas libellées, pensez à effectuer les tests suivants :
Examinez les modèles qui présentent un biais statistique important dans les prédictions. Consultez Classification : biais de prédiction.
Suivez les métriques réelles de votre modèle. Par exemple, si vous classifiez du spam, comparez vos prédictions au spam signalé par les utilisateurs.
Atténuez la divergence potentielle entre les données d'entraînement et de diffusion en diffusant une nouvelle version du modèle sur une fraction de vos requêtes. À mesure que vous validez votre nouveau modèle de diffusion, basculez progressivement toutes les requêtes vers la nouvelle version.
Lors de ces tests, n'oubliez pas de surveiller la dégradation soudaine et lente de la qualité des prédictions.
Randomisation
Rendez votre pipeline de génération de données reproductible. Imaginons que vous souhaitiez ajouter une caractéristique pour voir son impact sur la qualité du modèle. Pour que le test soit équitable, vos ensembles de données doivent être identiques, à l'exception de cette nouvelle fonctionnalité. Dans cet esprit, assurez-vous que toute randomisation dans la génération de données peut être rendue déterministe :
- Définissez une valeur source pour vos générateurs de nombres aléatoires (GNA). L'amorçage garantit que le générateur de nombres aléatoires génère les mêmes valeurs dans le même ordre chaque fois que vous l'exécutez, ce qui permet de recréer votre ensemble de données.
- Utilisez des clés de hachage invariantes. Le hachage est une méthode courante pour fractionner ou échantillonner des données. Vous pouvez hacher chaque exemple et utiliser l'entier obtenu pour décider dans quelle fraction placer l'exemple. Les entrées de votre fonction de hachage ne doivent pas changer chaque fois que vous exécutez le programme de génération de données. N'utilisez pas l'heure actuelle ni un nombre aléatoire dans votre hachage, par exemple si vous souhaitez recréer vos hachages à la demande.
Les approches précédentes s'appliquent à l'échantillonnage et à la division de vos données.
Remarques concernant le hachage
Imaginons à nouveau que vous collectiez des requêtes de recherche et que vous utilisiez le hachage pour inclure ou exclure des requêtes. Si la clé de hachage n'utilisait que la requête, vous incluriez ou excluriez toujours cette requête pour plusieurs jours de données. Inclure ou exclure systématiquement une requête est une mauvaise pratique, car :
- Votre ensemble d'entraînement verra un ensemble de requêtes moins diversifié.
- Vos ensembles d'évaluation seront artificiellement difficiles, car ils ne chevaucheront pas vos données d'entraînement. En réalité, au moment de la diffusion, vous aurez vu une partie du trafic réel dans vos données d'entraînement. Votre évaluation doit donc en tenir compte.
Vous pouvez plutôt hacher la requête et la date de la requête, ce qui générera un hachage différent pour chaque jour.
