Approches de test pour les modèles Amazon SageMaker ML

Cet article a été co-écrit avec Tobias Wenzel, responsable de l'ingénierie logicielle pour la plateforme d'apprentissage automatique Intuit.

Nous apprécions tous l’importance d’un modèle d’apprentissage automatique (ML) fiable et de haute qualité lors de l’utilisation de la conduite autonome ou de l’interaction avec Alexa, par exemple. Les modèles ML jouent également un rôle important de manière moins évidente : ils sont utilisés par les applications professionnelles, les soins de santé, les institutions financières, amazon.com, TurboTax, etc.

À mesure que les applications compatibles ML deviennent essentielles à de nombreuses entreprises, les modèles doivent suivre la même vigueur et la même discipline que les applications logicielles. Un aspect important de MLOps est de fournir en production une nouvelle version du modèle ML précédemment développé en utilisant des pratiques DevOps établies telles que les tests, la gestion des versions, la livraison continue et la surveillance.

Il ya plusieurs Prescriptif lignes directrices autour de MLOps, et cet article donne un aperçu du processus que vous pouvez suivre et des outils à utiliser pour les tests. Ceci est basé sur des collaborations entre Intuit et AWS. Nous avons travaillé ensemble pour mettre en œuvre les recommandations expliquées dans cet article dans la pratique et à grande échelle. L’objectif d’Intuit de devenir un Plateforme experte basée sur l'IA dépend fortement d'une stratégie visant à accélérer le développement du modèle initial ainsi que les tests de nouvelles versions.

Exigences

Voici les principaux domaines à prendre en compte lors du déploiement de nouvelles versions de modèle :

1. Performances de précision du modèle – Il est important de garder une trace des métriques d'évaluation du modèle telles que l'exactitude, la précision et le rappel, et assurez-vous que les métriques objectives restent relativement les mêmes ou s'améliorent avec une nouvelle version du modèle. Dans la plupart des cas, déployer une nouvelle version du modèle n’a pas de sens si l’expérience des utilisateurs finaux ne s’améliore pas.
2. Tester la qualité des données – Les données dans des environnements hors production, qu'elles soient simulées ou copiées à un moment donné, doivent être représentatives des données que le modèle recevra une fois entièrement déployé, en termes de volume ou de distribution. Sinon, vos processus de test ne seront pas représentatifs et votre modèle pourrait se comporter différemment en production.
3. Importance et parité des fonctionnalités – L’importance des fonctionnalités dans la version la plus récente du modèle devrait être relativement comparable à celle de l’ancien modèle, bien que de nouvelles fonctionnalités puissent être introduites. Il s’agit de garantir que le modèle ne devienne pas biaisé.
4. Tests de processus métier – Il est important qu’une nouvelle version d’un modèle puisse atteindre vos objectifs commerciaux requis dans des paramètres acceptables. Par exemple, l’une des mesures commerciales peut être que la latence de bout en bout d’un service ne doit pas dépasser 100 millisecondes, ou que le coût d’hébergement et de recyclage d’un modèle particulier ne peut pas dépasser 10,000 XNUMX $ par an.
5. Prix – Une approche simple des tests consiste à répliquer l’ensemble de l’environnement de production en tant qu’environnement de test. Il s'agit d'une pratique courante dans le développement de logiciels. Cependant, une telle approche dans le cas des modèles ML pourrait ne pas générer le bon retour sur investissement en fonction de la taille des données et peut avoir un impact sur le modèle en termes de problème commercial qu'il résout.
6. Sécurité – On s'attend souvent à ce que les environnements de test contiennent des exemples de données au lieu de données client réelles et, par conséquent, les règles de traitement et de conformité des données peuvent être moins strictes. Tout comme le coût, si vous dupliquez simplement l’environnement de production dans un environnement de test, vous pourriez introduire des risques en matière de sécurité et de conformité.
7. Évolutivité du magasin de fonctionnalités – Si une organisation décide de ne pas créer de magasin de fonctionnalités de test distinct pour des raisons de coût ou de sécurité, des tests de modèle doivent alors être effectués sur le magasin de fonctionnalités de production, ce qui peut entraîner des problèmes d'évolutivité car le trafic est doublé pendant la période de test.
8. Performances du modèle en ligne – Les évaluations en ligne diffèrent des évaluations hors ligne et peuvent être importantes dans certains cas comme les modèles de recommandation car elles mesurent la satisfaction des utilisateurs en temps réel plutôt que la satisfaction perçue. Il est difficile de simuler des modèles de trafic réels hors production en raison de la saisonnalité ou d'autres comportements des utilisateurs. Les performances des modèles en ligne ne peuvent donc être réalisées qu'en production.
9. La performance opérationnelle – À mesure que les modèles grossissent et sont de plus en plus déployés de manière décentralisée sur différents matériels, il est important de tester le modèle pour déterminer les performances opérationnelles souhaitées, telles que la latence, le taux d'erreur, etc.

La plupart des équipes ML ont une approche à plusieurs volets des tests de modèles. Dans les sections suivantes, nous proposons des moyens de relever ces défis au cours des différentes étapes de test.

Test de modèle hors ligne

Le but de cette phase de tests est de valider les nouvelles versions d'un modèle existant du point de vue de la précision. Cela doit être effectué hors ligne afin de ne pas affecter les prédictions du système de production qui fournissent des prédictions en temps réel. En garantissant que le nouveau modèle fonctionne mieux pour les mesures d'évaluation applicables, ces tests répondent au défi 1 (performances de précision du modèle). De plus, en utilisant le bon ensemble de données, ces tests peuvent relever les défis 2 et 3 (qualité des données de test, importance et parité des fonctionnalités), avec l'avantage supplémentaire de relever le défi 5 (coût).

Cette phase se déroule dans l'environnement de préparation.

Vous devez capturer le trafic de production, que vous pouvez utiliser pour rejouer lors de back-tests hors ligne. Il est préférable d’utiliser le trafic de production passé plutôt que des données synthétiques. Le Moniteur de modèle Amazon SageMaker fonction de capture de données vous permet de capturer le trafic de production pour les modèles hébergés sur Amazon Sage Maker. Cela permet aux développeurs de modèles de tester leurs modèles avec des données provenant des jours ouvrables de pointe ou d'autres événements importants. Les données capturées sont ensuite relues par rapport à la nouvelle version du modèle par lots à l'aide de Transformation par lots Sagemaker. Cela signifie que l'exécution de la transformation par lots peut tester en quelques heures seulement des données collectées sur des semaines ou des mois. Cela peut considérablement accélérer le processus d'évaluation du modèle par rapport à l'exécution côte à côte de deux versions ou plus d'un modèle en temps réel et à l'envoi de requêtes de prédiction en double à chaque point de terminaison. En plus de permettre de trouver plus rapidement une version plus performante, cette approche utilise également les ressources de calcul pendant une durée plus courte, réduisant ainsi le coût global.

Un défi avec cette approche de test est que l'ensemble des fonctionnalités change d'une version de modèle à l'autre. Dans ce scénario, nous vous recommandons de créer un ensemble de fonctionnalités avec un sur-ensemble de fonctionnalités pour les deux versions afin que toutes les fonctionnalités puissent être interrogées en même temps et enregistrées via la capture de données. Chaque appel de prédiction peut alors fonctionner uniquement sur les fonctionnalités nécessaires à la version actuelle du modèle.

En prime, en intégrant Amazon SageMaker Clarifier lors de vos tests de modèle hors ligne, vous pouvez vérifier le biais de la nouvelle version du modèle et également comparer l'attribution des fonctionnalités avec la version précédente du modèle. Avec les pipelines, vous pouvez orchestrer l'ensemble du flux de travail de telle sorte qu'après la formation, une étape de contrôle de qualité puisse avoir lieu pour effectuer une analyse des métriques du modèle et de l'importance des fonctionnalités. Ces métriques sont stockées dans le Registre de modèles SageMaker pour comparaison lors de la prochaine session de formation.

Tests d'intégration et de performances

Des tests d'intégration sont nécessaires pour valider les processus métier de bout en bout du point de vue des performances fonctionnelles et d'exécution. Dans le cadre de ce processus, l'ensemble du pipeline doit être testé, y compris la récupération et le calcul des fonctionnalités dans le magasin de fonctionnalités et l'exécution de l'application ML. Cela doit être fait avec une variété de charges utiles différentes pour couvrir une variété de scénarios et de demandes et obtenir une couverture élevée pour toutes les exécutions de code possibles. Cela répond aux défis 4 et 9 (tests des processus métier et performances opérationnelles) pour garantir qu'aucun des processus métier n'est interrompu avec la nouvelle version du modèle.

Ces tests doivent être effectués dans un environnement de test.

Les tests d'intégration et les tests de performances doivent être mis en œuvre par des équipes individuelles à l'aide de leur pipeline MLOps. Pour les tests d'intégration, nous recommandons la méthode éprouvée consistant à maintenir un environnement de pré-production fonctionnellement équivalent et à tester avec quelques charges utiles différentes. Le flux de travail de test peut être automatisé comme indiqué dans cet atelier. Pour les tests de performances, vous pouvez utiliser Outil de recommandation d'inférence Amazon SageMaker, qui constitue un excellent point de départ pour déterminer quel type d'instance et combien d'instances utiliser. Pour cela, vous devrez utiliser un outil générateur de charge, tel que les projets open source perfsizesagemaker ainsi que taille perf qu'Intuit a développé. Perfsizesagemaker vous permet de tester automatiquement les configurations de points de terminaison de modèles avec une variété de charges utiles, de temps de réponse et d'exigences de pic de transactions par seconde. Il génère des résultats de tests détaillés qui comparent différentes versions de modèles. Perfsize est l'outil compagnon qui essaie différentes configurations en fonction uniquement du pic de transactions par seconde et du temps de réponse attendu.

Le test A / B

Dans de nombreux cas où une réaction de l’utilisateur au résultat immédiat du modèle est requise, comme dans le cas des applications de commerce électronique, l’évaluation fonctionnelle du modèle hors ligne n’est pas suffisante. Dans ces scénarios, vous devez tester A/B les modèles en production avant de prendre la décision de mettre à jour les modèles. Les tests A/B comportent également des risques car ils pourraient avoir un réel impact sur le client. Cette méthode de test sert de validation finale des performances ML, un contrôle de cohérence technique léger. Cette méthode répond également aux défis 8 et 9 (performance du modèle en ligne et excellence opérationnelle).

Les tests A/B doivent être effectués dans un environnement de production.

Avec SageMaker, vous pouvez facilement effectuer des tests A/B sur des modèles ML en exécutant plusieurs variantes de production sur un point final. Le trafic peut être acheminé par incréments vers la nouvelle version afin de réduire le risque qu'un modèle qui se comporte mal pourrait avoir sur la production. Si les résultats du test A/B semblent bons, le trafic est acheminé vers la nouvelle version, prenant finalement plus de 100 % du trafic. Nous vous recommandons d'utiliser des garde-fous de déploiement pour passer du modèle A au modèle B. Pour une discussion plus complète sur les tests A/B utilisant Amazon Personnaliser modèles à titre d'exemple, reportez-vous à Utilisation des tests A / B pour mesurer l'efficacité des recommandations générées par Amazon Personalize.

Tests de modèles en ligne

Dans ce scénario, la nouvelle version d'un modèle est très différente de celle qui dessert déjà le trafic réel en production, de sorte que l'approche de test hors ligne n'est plus adaptée pour déterminer l'efficacité de la nouvelle version du modèle. La raison la plus importante en est un changement dans les fonctionnalités requises pour produire la prédiction, de sorte que les transactions précédemment enregistrées ne peuvent pas être utilisées pour tester le modèle. Dans ce scénario, nous vous recommandons d'utiliser des déploiements fantômes. Les déploiements fantômes offrent la possibilité de déployer un système fantôme (ou provocateur) modèle parallèlement à la production (ou champion) modèle qui sert actuellement des prédictions. Cela vous permet d'évaluer les performances du modèle fantôme dans le trafic de production. Les prédictions du modèle fantôme ne sont pas transmises à l’application demandeuse ; ils sont connectés pour une évaluation hors ligne. Avec l'approche fantôme pour les tests, nous relevons les défis 4, 5, 6 et 7 (tests des processus métier, coût, sécurité et évolutivité du magasin de fonctionnalités).

Les tests de modèles en ligne doivent être effectués dans des environnements de test ou de production.

Cette méthode de test des nouvelles versions de modèles doit être utilisée en dernier recours si toutes les autres méthodes ne peuvent pas être utilisées. Nous le recommandons en dernier recours, car le duplexage des appels vers plusieurs modèles génère une charge supplémentaire sur tous les services en aval de la production, ce qui peut entraîner des goulots d'étranglement en termes de performances ainsi qu'une augmentation des coûts de production. L’impact le plus évident que cela a concerne la couche de diffusion de fonctionnalités. Pour les cas d'utilisation qui partagent des fonctionnalités d'un pool commun de données physiques, nous devons être capables de simuler plusieurs cas d'utilisation accédant simultanément à la même table de données pour garantir qu'il n'existe aucun conflit de ressources avant de passer à la production. Dans la mesure du possible, les requêtes en double vers le magasin de fonctionnalités doivent être évitées et les fonctionnalités nécessaires aux deux versions du modèle doivent être réutilisées pour la deuxième inférence. Magasins de fonctionnalités basés sur Amazon DynamoDB, comme celui qu'Intuit a construit, peut implémenter Accélérateur Amazon DynamoDB(DAX) pour mettre en cache et éviter de doubler les E/S vers la base de données. Ces options de mise en cache, ainsi que d’autres, peuvent atténuer le défi 7 (évolutivité du magasin de fonctionnalités).

Pour relever le défi 5 (coût) ainsi que 7, nous proposons d'utiliser des déploiements fantômes pour échantillonner le trafic entrant. Cela donne aux propriétaires de modèles un autre niveau de contrôle pour minimiser l'impact sur les systèmes de production.

Le déploiement fantôme doit être intégré au Moniteur de modèle offres tout comme les déploiements de production réguliers afin d'observer les améliorations de la version challenger.

Conclusion

Cet article illustre les éléments de base permettant de créer un ensemble complet de processus et d'outils permettant de relever divers défis liés aux tests de modèles. Bien que chaque organisation soit unique, cela devrait vous aider à démarrer et à affiner vos considérations lors de la mise en œuvre de votre propre stratégie de test.

---

À propos des auteurs

Tobias Wenzel est responsable de l'ingénierie logicielle pour la plateforme d'apprentissage automatique Intuit à Mountain View, en Californie. Il travaille sur la plateforme depuis sa création en 2016 et a contribué à sa conception et à sa construction à partir de zéro. Dans son travail, il s’est concentré sur l’excellence opérationnelle de la plateforme et sur sa réussite grâce aux activités saisonnières d’Intuit. De plus, il est passionné par l’expansion continue de la plateforme avec les dernières technologies.

Shivanshu Upadhyay est architecte de solutions principal au sein du groupe AWS Business Development and Strategic Industries. Dans ce rôle, il aide les utilisateurs les plus avancés d'AWS à transformer leur secteur en utilisant efficacement les données et l'IA.

Alan Tan est chef de produit senior chez SageMaker, dirigeant les efforts sur l'inférence de grands modèles. Il est passionné par l'application de l'apprentissage automatique au domaine de l'analyse. En dehors du travail, il aime le plein air.