Vous êtes prêt pour le déploiement. Si seulement le déploiement d'un modèle est aussi simple que d'appuyer sur un gros bouton rouge. Lors du déploiement, vous souhaitez que votre pipeline s'exécute, se mette à jour et se diffuse sans problème. Ces besoins engendrent les exigences et les solutions décrites sur cette page.
Tester les mises à jour de modèles avec l'entraînement reproductible
Vous souhaitez sans aucun doute améliorer votre prédicteur d'apparence licorne. Supposons que vous refactoriez le code d'extraction de caractéristiques pour la caractéristique "heure de la journée". Comment vérifier que le code est correct ? Vous décidez d'entraîner à nouveau votre modèle et de voir si vous obtenez le même résultat. Vous vous apercevez que l'entraînement de votre modèle n'est pas reproductible. Pour continuer à prédire l'apparence des licornes, vous allez approfondir vos recherches. Pour ce faire, procédez comme suit:
Injecter du générateur de nombres aléatoires dans le code déterministe Pour en savoir plus, consultez la section Aléatoire dans la génération de données du cours "Préparation des données et extraction de caractéristiques dans le ML".
Initialisez les composants du modèle dans un ordre fixe pour vous assurer qu'ils reçoivent le même nombre aléatoire du RNG à chaque exécution. Les bibliothèques de ML gèrent généralement cette exigence automatiquement.
Moyenne de plusieurs exécutions du modèle.
Utilisez le contrôle des versions, même pour les itérations préliminaires, afin de pouvoir identifier le code et les paramètres lorsque vous examinez votre modèle ou pipeline.
Même après avoir suivi ces étapes, vous pouvez avoir d'autres sources de non-déterminisme.
Tester les mises à jour des spécifications et des appels d'API
Après avoir mis à jour votre modèle vers Unicorn Predictor 2.0, vous devez tester l'exactitude de l'algorithme du nouveau modèle, ainsi que toute modification des appels d'API. Voyons comment procéder.
Tester les appels d'API
Comment tester les mises à jour des appels d'API ? Bien sûr, vous pourriez réentraîner votre modèle, mais cela prend du temps. À la place, écrivez un test unitaire pour générer des données d'entrée aléatoires et exécuter une seule étape de descente de gradient. Vous souhaitez que l'étape se termine sans erreur d'exécution.
Tester l'exactitude algorithmique
Un modèle doit non seulement prédire correctement, mais aussi le faire en raison de son algorithme, et non de sa chance. Par exemple, si 99% des e-mails ne sont pas du spam, classer tous les e-mails comme non-spam permet d'obtenir 99% de précision par hasard. Vous devez donc vérifier que votre modèle est correct. Procédez comme indiqué ci-dessous.
- Entraînez votre modèle à plusieurs itérations et vérifiez que la perte diminue.
- Entraînez votre algorithme sans régularisation. Si votre modèle est suffisamment complexe, il mémorisera les données d'entraînement et votre perte d'entraînement sera proche de 0.
- Testez des sous-calculs spécifiques de votre algorithme. Par exemple, vous pouvez tester qu'une partie de votre RNN s'exécute une fois par élément des données d'entrée.
Écrire des tests d'intégration pour les composants du pipeline
Dans un pipeline de ML, les modifications apportées à un composant peuvent entraîner des erreurs dans d'autres composants. Vérifiez que les composants fonctionnent ensemble en écrivant un test qui exécute l'ensemble du pipeline de bout en bout. Ce type de test est appelé test d'intégration.
En plus d'exécuter des tests d'intégration en continu, vous devez effectuer des tests d'intégration lorsque vous déployez de nouveaux modèles et de nouvelles versions de logiciels. La lenteur d'exécution de l'intégralité du pipeline rend les tests d'intégration continue plus difficiles. Pour exécuter des tests d'intégration plus rapidement, entraînez-vous sur un sous-ensemble de données ou avec un modèle plus simple. Les détails dépendent de votre modèle et de vos données. Pour obtenir une couverture continue, vous devez ajuster vos tests plus rapidement afin qu'ils s'exécutent avec chaque nouvelle version du modèle ou du logiciel. Pendant ce temps, les tests lents s'exécutaient en continu.
Valider la qualité du modèle avant inférence
Avant de déployer une nouvelle version de modèle en production, testez ces deux types de dégradation de la qualité:
Dégradation soudaine: un bug de la nouvelle version peut réduire considérablement la qualité. Validez les nouvelles versions en comparant leur qualité à celles de la version précédente.
Dégradation lente: il est possible que votre test de dégradation soudaine ne détecte pas une dégradation lente de la qualité du modèle sur plusieurs versions. Assurez-vous plutôt que les prédictions de votre modèle sur un ensemble de données de validation respectent un seuil fixe. Si votre ensemble de données de validation diffère des données en ligne, mettez-le à jour et assurez-vous que votre modèle respecte toujours le même seuil de qualité.
Valider la compatibilité de l'infrastructure de modèle avant l'inférence
Si votre modèle est mis à jour plus rapidement que votre serveur, il y aura différentes dépendances logicielles de votre serveur, ce qui pourrait entraîner des incompatibilités. Assurez-vous que les opérations utilisées par le modèle sont présentes sur le serveur en préparant le modèle dans une version en bac à sable du serveur.