Félicitations ! Vous avez déployé le modèle unicorn. Votre modèle devrait fonctionner 24h/24, 7j/7 sans aucun 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 vérifier en permanence par rapport aux les valeurs statistiques en écrivant les règles que les données doivent respecter. Cette collection de règles s'appelle un schéma de données. Définissez un schéma de données en procédant comme suit : procédez comme suit:
comprendre l'étendue et la répartition de vos caractéristiques ; Pour les données catégorielles les caractéristiques, comprendre 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 un texte en anglais) fonctionnalité).
- Vérifier que chaque caractéristique catégorielle est définie sur une valeur d'un ensemble fixe de valeurs possibles.
Testez vos données par rapport au schéma de données. Votre schéma doit collecter les données les erreurs suivantes:
- Anomalies
- Valeurs inattendues des variables catégorielles
- Distributions de données inattendues
Écrire des tests unitaires pour valider l'ingénierie des caractéristiques
Bien que vos données brutes puissent transmettre le schéma de données, votre modèle n'est pas entraîné à partir de données brutes. Il s'entraîne plutôt sur des données qui ont été présentées par des caractéristiques conçus. Par exemple, votre modèle est entraîné sur des caractéristiques numériques normalisées plutôt que des données numériques brutes. Comme les données conçues pour les caractéristiques différentes des données d'entrée brutes, vous devez vérifier les données d'ingénierie des caractéristiques séparément de vos vérifications sur les données d'entrée brutes.
Écrivez des tests unitaires basés sur votre compréhension des données de caractéristiques techniques. Par exemple, vous pouvez écrire des tests unitaires pour vérifier des conditions telles que suivantes:
- Toutes les caractéristiques numériques sont mises à l'échelle (entre 0 et 1, par exemple).
- Encodage one-hot les vecteurs ne contiennent qu'un seul zéro 1 et N-1.
- La distribution des données après la transformation est conforme aux attentes. Par exemple, si vous avez normalisé à l'aide de Z-scores, la moyenne du Les cotes z doivent être égales à 0.
- Anomalies sont gérées, par exemple par le scaling ou clipping.
Vérifier les métriques pour les tranches de données importantes
Un ensemble réussi masque parfois un sous-ensemble infructueux. Autrement dit, un modèle avec des métriques globales excellentes peut tout de même faire de très mauvaises prédictions dans certaines situations. Exemple :
Votre modèle licorne fonctionne globalement bien, mais ne fonctionne pas correctement faire des prévisions pour le désert du Sahara.
Si vous êtes le genre d'ingénieur satisfait avec un AUC globalement excellent, alors vous ne remarquerez peut-être pas les problèmes du modèle dans le désert du Sahara. Si vous créez qu'il est important d'obtenir des prédictions correctes pour chaque région, vous devez suivre des performances pour chaque région. Sous-ensembles de données, comme celui correspondant dans le désert du Sahara, sont appelées tranches de données.
Identifiez les tranches de données qui vous intéressent. Ensuite, comparez les métriques du modèle pour ces tranches de données aux métriques de vos ensemble de données complet. Vérifier les performances de votre modèle sur toutes les tranches de données permet d'éliminer les préjugés. Voir Équité: évaluer les biais pour en savoir plus.
Utilisez des métriques réelles
Les métriques du 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 le changement a-t-il eu une incidence sur l’expérience utilisateur ? Pour mesurer l'impact concret, vous avez besoin pour 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 a prédit le ferait.
Vérifier le décalage entraînement/inférence
Décalage entraînement/inférence signifie que vos données d'entrée lors de l'entraînement diffèrent à partir de vos données d'entrée lors de l'inférence. Le tableau suivant décrit les deux types d'asymétrie importants:
| Type | Définition | Exemple | Solution |
|---|---|---|---|
| Asymétrie du schéma | Les données d'entrée d'entraînement et d'inférence ne suivent pas le même schéma. | Le format ou la distribution des données d'inférence change tandis que l'entraînement du modèle continue sur d'anciennes données. | Utilisez le même schéma pour valider les données d'entraînement et d'inférence. Veillez à vérifier séparément les statistiques non vérifiées par à votre schéma, comme la fraction des valeurs manquantes, |
| Décalage de caractéristiques | Les données techniques diffèrent entre l'entraînement et l'inférence. | Le code d'ingénierie des caractéristiques diffère entre l'entraînement et l'inférence. différentes données techniques. | Comme pour le décalage du schéma, appliquez les mêmes règles statistiques à l'entraînement et l'inférence de données techniques. Suivre le numéro le nombre de caractéristiques asymétriques détectées et le ratio d'exemples asymétriques par caractéristique. |
Les causes du décalage entraînement/inférence peuvent être subtiles. Tenez toujours compte des données disponibles pour votre modèle au moment de la prédiction. Pendant l'entraînement, n'utilisez que les caractéristiques dont vous disposerez lors de l'inférence.
Exercice: tester vos connaissances
Imaginons que vous possédiez une boutique en ligne et que vous souhaitiez prédire combien d'argent vous allez gagner un jour donné. L'objectif du ML est d'effectuer des prédictions quotidiennes des revenus en utilisant le nombre de clients comme caractéristique.
Réponse:Le problème est que vous ne connaissez pas la de clients au moment de la prédiction, avant que les ventes du jour terminé. Cette fonction n'est donc pas utile, vos revenus quotidiens. De même, lorsque vous entraîner un modèle et obtenir des métriques d'évaluation incroyables (comme 0,99 AUC), recherchez ce type de caractéristiques qui peuvent figurer dans l'étiquette.
Rechercher une fuite d'étiquette
Les fuites de libellés signifient que les étiquettes de vérité terrain que vous ont été introduites par inadvertance dans vos caractéristiques d'entraînement. Libellé les fuites est parfois très difficile à détecter.
Exercice: tester vos connaissances
Supposons que vous créez un modèle de classification binaire pour prédire si un nouveau patient à l'hôpital est atteint d'un cancer. Votre modèle utilise des caractéristiques telles que:
- Âge du patient
- Genre du patient
- Problèmes de santé antérieurs
- Nom de l'hôpital
- Signes vitaux
- Résultats du test
- Hérité
L'étiquette est la suivante:
- Booléen: Le patient est-il atteint d'un cancer ?
Vous partitionnez les données avec soin pour vous assurer que l'ensemble d'entraînement de vos ensembles de validation et de test. Le modèle effectue que les ensembles de validation et de test sont correctement les métriques sont fantastique. Malheureusement, le modèle fonctionne terriblement 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 se spécialisent dans le traitement du cancer. Pendant l'entraînement, a rapidement appris que les patients affectés à certains hôpitaux ont probablement 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é assigné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 affecter le patient dans un hôpital approprié. Par conséquent, pendant l'inférence, La caractéristique "nom d'hôpital" n'était pas encore disponible et le modèle a été forcé de s'appuyer sur d'autres fonctionnalités.
Surveiller l'âge du modèle tout au long du pipeline
Si les données d'inférence évoluent avec le temps, mais que votre modèle n'est pas réentraîné régulièrement, vous constatez une baisse de la qualité du modèle. Suivre le temps écoulé depuis l'apparition du modèle est réentraîné sur de nouvelles données et définit un âge seuil pour les alertes. En plus de surveiller du modèle au moment de l'inférence, vous devez le surveiller tout au long du pipeline pour attraper les blocages du pipeline.
Vérifier que les pondérations et les résultats du modèle sont stables numériquement
Pendant l'entraînement du modèle, vos pondérations et les sorties de vos couches ne doivent pas être de type NaN (pas un nombre) ou Inf (infini). Écrivez des tests pour vérifier les valeurs NaN et Inf de vos pondérations et des sorties de 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 d'apparence de licorne a été plus populaire que prévu ! Vous êtes de nombreuses requêtes de prédiction et de données d'entraînement. Vous pensez tant que vous n'avez pas réalisé que le modèle prend de plus en plus de mémoire et du temps d'entraînement. Vous décidez de surveiller les performances de votre modèle procédez comme suit:
- Suivez les performances des modèles par version de code, de modèle et de données. Ce suivi vous permet d'identifier la cause exacte d'une dégradation des performances.
- Tester le nombre de pas d'entraînement par seconde pour une nouvelle version de modèle à 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. Réponse de l'API alors que peuvent échapper à votre contrôle, des réponses lentes peuvent potentiellement causer les mauvais indicateurs du monde réel.
- Surveillez le nombre de requêtes traitées par seconde.
Tester la qualité du modèle actif 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 "licorne", changer après l'enregistrement des données de validation ? Ensuite, la qualité de votre du modèle diffusé se dégradent. Toutefois, il est difficile de tester la qualité de l'inférence, les données du monde réel ne sont pas toujours étiquetées. Si vos données de diffusion ne sont pas étiquetées, envisagez ces tests:
Examinez les modèles qui présentent des biais statistiques significatifs dans les prédictions. Voir Classification: prédiction Biais.
Suivez des métriques réelles pour votre modèle. Par exemple, si vous classez de spam, comparez vos prédictions à celles du spam signalé par les utilisateurs.
Limiter les divergences potentielles entre les données d'entraînement et d'inférence en de publier une nouvelle version de modèle sur une petite partie de vos requêtes. Lors de la validation votre nouveau modèle d'inférence, transférez progressivement toutes les requêtes vers la nouvelle version.
À l'aide de ces tests, n'oubliez pas de surveiller les dégradations soudaines et lentes 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 une expérience juste, vos jeux de données doivent seront identiques, à l'exception de cette nouvelle fonctionnalité. Dans cet esprit, assurez-vous que toute randomisation lors de la génération des données peut être faite déterministe:
- Spécifiez vos générateurs de nombres aléatoires. L'injection garantit que la génération 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 un moyen courant de diviser ou des échantillons de données. Vous pouvez hacher chaque exemple et utiliser l'entier obtenu pour de décider dans quelle division placer l'exemple. Les entrées de votre fonction de hachage ne devrait pas changer à chaque fois que vous exécutez le programme de génération de données. N'utilisez pas les l'heure actuelle ou un nombre aléatoire dans votre hachage, par exemple, pour recréer vos hachages à la demande.
Les approches précédentes s'appliquent à la fois à l'échantillonnage et à la division de vos données.
Remarques concernant le hachage
Imaginez à nouveau que vous collectez des requêtes de recherche et utilisez le hachage pour inclure ou exclure des requêtes. Si la clé de hachage n'utilisait que la requête, puis, sur plusieurs jours de données, vous devez toujours inclure cette requête ou l'excluent toujours. Toujours inclure ou toujours exclure une requête est incorrecte pour les raisons suivantes:
- Votre ensemble d'entraînement verra un ensemble de requêtes moins varié.
- Vos ensembles d'évaluation seront artificiellement difficiles, car ils avec vos données d'entraînement. En réalité, au moment de l'inférence, ayant vu du trafic en temps réel dans vos données d'entraînement, l'évaluation doit le refléter.
En revanche, vous pouvez effectuer un hachage en fonction de la requête et de la date, ce qui entraînerait un hachage différent. chaque jour.
