Félicitations ! Vous avez déployé le modèle licorne. Votre modèle devrait s'exécuter 24h/24, 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. Cette collection de règles est appelée schéma de données. Définissez un schéma de données en procédant comme suit:
Comprendre la portée et la distribution de vos éléments géographiques Pour les caractéristiques catégorielles, comprenez l'ensemble des valeurs possibles.
Encodez votre compréhension dans le schéma de données. Voici des 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 apparaît le plus souvent (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.
Vérifiez que vos données correspondent 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. Votre modèle s'entraîne plutôt sur des données qui ont été conçues en fonction des caractéristiques. 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 de vos vérifications des données d'entrée brutes.
Écrivez 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 encodés en 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é à l'aide de scores Z, la moyenne des scores Z doit être de 0.
- Les valeurs aberrantes sont gérées, par exemple par mise à l'échelle ou clipping.
Vérifier les métriques pour les segments de données importants
Un ensemble réussi masque parfois un sous-ensemble ayant échoué. En d'autres termes, un modèle avec de bonnes métriques globales peut toujours faire de mauvaises prédictions pour certaines situations. Exemple :
Votre modèle de licorne fonctionne bien dans l'ensemble, mais ses performances sont médiocres lorsqu'il effectue des prédictions pour le désert du Sahara.
Si vous êtes le genre d'ingénieur satisfait d'un AUC global élevé, vous ne remarquerez peut-être pas les problèmes du modèle dans le désert du Sahara. Si vous souhaitez obtenir de bonnes prévisions pour chaque région, vous devez suivre les performances de chaque région. Les sous-ensembles de données, comme celui correspondant au désert du Sahara, sont appelés tranches de données.
Identifier les segments de données qui vous intéressent Comparez ensuite les métriques du modèle pour ces tranches de données aux métriques de l'ensemble de données complet. Vérifier que votre modèle fonctionne bien pour tous les segments de données permet d'éliminer les biais. Pour en savoir plus, consultez Équité: évaluer les biais.
Utiliser des métriques réelles
Les métriques du modèle ne mesurent pas nécessairement son impact réel. Par exemple, modifier un hyperparamètre peut augmenter l'AUC d'un modèle, mais en quoi ce changement a-t-il 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 un licorne lorsque le modèle a prédit qu'ils le feraient.
Rechercher un décalage entraînement/diffusion
Le décalage entraînement/diffusion signifie que vos données d'entrée lors de 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 |
|---|---|---|---|
| Asymétrie de 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 pendant que votre modèle continue à 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, telles que la fraction des valeurs manquantes. |
| Écart au niveau des caractéristiques | Les données d'ingénierie 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 d'ingénierie 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 publication 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 fonctionnalités qui seront disponibles lors de l'inférence.
Exercice: Vérifiez votre compréhension
Imaginons que vous possédiez une boutique en ligne et que vous souhaitiez prédire le montant que vous allez gagner 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évision, avant que les ventes de la journée ne soient terminées. Cette fonctionnalité n'est donc pas utile, même si elle permet de prédire fortement vos revenus quotidiens. Par ailleurs, lorsque vous entraînez un modèle et que vous obtenez des métriques d'évaluation exceptionnelles (comme un AUC de 0,99), recherchez ces types de fonctionnalités qui peuvent s'infiltrer dans votre étiquette.
Vérifier les fuites de libellés
La fuite d'étiquette signifie que les étiquettes de vérité terrain que vous essayez de prédire ont été introduites par inadvertance dans vos caractéristiques d'entraînement. La fuite de libellés est parfois très difficile à détecter.
Exercice: Vérifiez votre compréhension
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éritabilité
Le libellé est le suivant:
- Booléen: Le patient est-il atteint d'un cancer ?
Vous partitionnez soigneusement les données, en vous assurant que votre ensemble d'entraînement est bien isolé de votre ensemble de validation et de votre ensemble de test. Le modèle fonctionne très bien sur l'ensemble de validation et l'ensemble de test. Les métriques sont fantastiques. Malheureusement, le modèle fonctionne très mal avec les nouveaux patients dans le monde réel.
Réponse:L'une des caractéristiques du modèle est le nom de l'hôpital. Certains hôpitaux se spécialisent dans le traitement du cancer. Au cours de l'entraînement, le modèle a rapidement appris que les patients affectés à certains hôpitaux étaient très probablement atteints de 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, le but du modèle était de diagnostiquer la présence ou l'absence de cancer, puis d'utiliser ce diagnostic pour attribuer le patient à un hôpital approprié. Par conséquent, lors de l'inférence, la fonctionnalité "nom de l'hôpital" n'était pas encore disponible et le modèle a été contraint de s'appuyer sur d'autres fonctionnalités.
Surveiller l'âge du modèle tout au long du pipeline
Si les données de diffusion évoluent avec le 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 que le modèle a été réentraîné avec de nouvelles données et définissez un âge limite pour les alertes. En plus de surveiller l'âge du modèle au moment de la diffusion, vous devez surveiller son âge tout au long du pipeline pour détecter les blocages du pipeline.
Vérifier que les pondérations et les sorties du modèle sont numériquement stables
Pendant l'entraînement du modèle, vos poids et les sorties de la couche ne doivent pas être NaN (pas un nombre) ou Inf (infini). Écrivez des tests pour vérifier les valeurs NaN et Inf de vos poids et des sorties de la couche. Vérifiez également que plus de la moitié des sorties d'une couche ne sont pas nulles.
Surveiller les performances du modèle
Votre prédicteur de l'apparition des licornes a été plus populaire que prévu ! Vous recevez de nombreuses requêtes de prédiction et encore plus de données d'entraînement. Vous pensez que c'est génial, 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 procédant comme suit:
- Suivez les performances du modèle en fonction des versions de code, du modèle et des données. Ce suivi vous permet d'identifier la cause exacte de toute dégradation des performances.
- Testez les étapes d'entraînement par seconde d'une nouvelle version de modèle par rapport à la version précédente et par rapport à 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 percentiles. Bien que les temps de réponse de l'API ne soient pas sous votre contrôle, des réponses lentes peuvent entraîner de mauvaises métriques réelles.
- Surveillez le nombre de requêtes traitées par seconde.
Tester la qualité du modèle en direct sur les données diffusées
Vous avez validé votre modèle. Mais que se passe-t-il si les scénarios réels, comme le comportement d'un unicorne, changent après l'enregistrement de vos données de validation ? La qualité du modèle diffusé se dégradera alors. Toutefois, tester la qualité de la diffusion est difficile, car les données réelles ne sont pas toujours libellées. Si vos données de diffusion ne sont pas libellées, envisagez les tests suivants:
Examinez les modèles qui présentent un biais statistique significatif dans les prédictions. Consultez la section 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 de modèle sur une partie de vos requêtes. Lorsque vous validez votre nouveau modèle de diffusion, passez progressivement toutes les requêtes à la nouvelle version.
N'oubliez pas de surveiller la dégradation soudaine et lente de la qualité des prédictions lors de ces tests.
Randomisation
Rendez votre pipeline de génération de données reproductible. Imaginons que vous souhaitiez ajouter une fonctionnalité pour voir son impact sur la qualité du modèle. Pour un test équitable, vos ensembles de données doivent être identiques, à l'exception de cette nouvelle fonctionnalité. Dans cet esprit, assurez-vous que toute randomisation de la génération de données peut être rendue déterministe:
- Générez une valeur source pour vos générateurs de nombres aléatoires (GNA). Le forçage de la graine garantit que le générateur de nombres aléatoires génère les mêmes valeurs dans le même ordre à chaque exécution, en recréant votre ensemble de données.
- Utilisez des clés de hachage invariantes. Le hachage est une méthode courante pour diviser ou échantillonner des données. Vous pouvez hacher chaque exemple et utiliser l'entier obtenu pour décider dans quelle division placer l'exemple. Les entrées de votre fonction de hachage ne doivent pas changer à chaque exécution du 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 à la fois à l'échantillonnage et au fractionnement de vos données.
Éléments à prendre en compte pour le hachage
Imaginons à nouveau que vous collectiez des requêtes de recherche et que vous utilisiez le hachage pour les inclure ou les exclure. Si la clé de hachage n'a utilisé que la requête, vous l'inclurez toujours ou l'exclurez toujours sur plusieurs jours de données. Inclure ou exclure toujours une requête est une mauvaise pratique, car:
- Votre ensemble d'entraînement comportera un ensemble de requêtes moins diversifié.
- Vos ensembles d'évaluation seront artificiellement difficiles, car ils ne se chevauchent pas avec vos données d'entraînement. En réalité, au moment de la diffusion, vous aurez vu une partie du trafic en direct dans vos données d'entraînement. Votre évaluation doit donc le refléter.
Vous pouvez plutôt hacher la requête + la date, ce qui entraînera un hachage différent chaque jour.
