Vous êtes prêt à déployer le modèle de licorne qui prédit l'apparence d'une licorne. Lors du déploiement, votre pipeline de machine learning (ML) doit s'exécuter, se mettre à jour sont diffusées sans problème. Si seulement le déploiement d'un modèle était aussi simple un gros bouton Déployer. Malheureusement, un système de machine learning complet nécessite des tests pour:
- Validation des données d'entrée...
- Validation de l'ingénierie des caractéristiques...
- Valider la qualité des nouvelles versions du modèle
- Validation de l'infrastructure d'inférence...
- Tests de l'intégration entre les composants du pipeline.
De nombreux ingénieurs logiciels privilégient le développement piloté par les tests (TDD). Dans le traitement des maladies fondamentales, le logiciel les ingénieurs rédigent des tests avant d'écrire le "vrai" le code source. Toutefois, le TDD peut s'avérer délicat en machine learning. Par exemple, avant d'entraîner votre modèle, vous ne pouvez pas écrire de test pour valider la perte. Au lieu de cela, vous devez d'abord découvrir la perte réalisable développement et tester de nouvelles versions du modèle par rapport à la perte réalisable.
À propos du modèle licorne
Cette section fait référence au modèle unicorn. Voici les informations à retenir :
Vous utilisez le machine learning pour créer un modèle de classification qui prédit des licornes. Votre ensemble de données détaille 10 000 apparitions de licornes et 10 000 absences de licornes. Le jeu de données contient l'emplacement, heure de la journée, altitude, température, humidité, couvert forestier, présence d'une arc-en-ciel et plusieurs autres fonctionnalités.
Tester les mises à jour du modèle avec un entraînement reproductible
Vous souhaitez peut-être continuer à améliorer votre modèle licorne. Par exemple, supposons que une ingénierie supplémentaire des caractéristiques, réentraîner le modèle en espérant obtenir de meilleurs résultats (ou au moins des résultats identiques). Malheureusement, il est parfois difficile de reproduire l'entraînement d'un modèle. Pour améliorer la reproductibilité, suivez ces recommandations:
Injecter de manière déterministe le générateur de nombres aléatoires Pour en savoir plus, consultez la section Aléatoire dans les données génération
Initialisez les composants du modèle dans un ordre fixe pour vous assurer qu'ils obtiennent les le même nombre aléatoire du générateur de nombres aléatoires à chaque exécution. En général, les bibliothèques de ML gèrent cette exigence automatiquement.
Effectuer la moyenne de plusieurs exécutions du modèle
Utilisez le contrôle des versions, même pour les itérations préliminaires, afin de identifier le code et les paramètres lorsque vous examinez votre modèle ou votre pipeline.
Même après avoir suivi ces directives, d’autres sources de non déterminisme pourraient existent toujours.
Tester les appels à l'API de machine learning
Comment tester les mises à jour des appels d'API ? Vous pouvez réentraîner votre modèle, cela prend beaucoup de temps. Écrivez plutôt un test unitaire pour générer des données d'entrée aléatoires et effectuer un seul pas de descente de gradient. Si cette étape se termine sans s'affiche, cela signifie que les mises à jour de l'API n'ont probablement pas entraîné la destruction de votre modèle.
Écrire des tests d'intégration pour les composants du pipeline
Dans un pipeline de ML, les modifications d'un composant peuvent entraîner des erreurs dans d'autres composants. Vérifiez que les composants fonctionnent ensemble en écrivant une test d'intégration qui exécute l'ensemble du pipeline de bout en bout.
En plus d'exécuter des tests d'intégration en continu, vous devez exécuter des tests d'intégration lors de la publication de nouveaux modèles et de nouvelles versions logicielles. La lenteur d'exécution l'intégralité du pipeline rend les tests d'intégration continue plus difficiles. Pour exécuter l'intégration des tests plus rapides, entraîner le modèle sur un sous-ensemble de données ou avec un modèle plus simple. Détails dépendent de votre modèle et de vos données. Pour bénéficier d'une couverture continue, ajustez votre des tests plus rapides afin qu’ils s’exécutent avec chaque nouvelle version du modèle ou du logiciel. Pendant ce temps, vos tests lents seraient exécutés en continu en arrière-plan.
Valider la qualité du modèle avant l'inférence
Avant de déployer une nouvelle version de modèle en production, testez les deux types de dégradation de la qualité suivants:
Dégradation soudaine. Un bug dans la nouvelle version peut entraîner de moins bonne qualité. Valider les nouvelles versions en vérifiant leur qualité par rapport à la version précédente.
Faible dégradation. Votre test de dégradation soudaine risque de ne pas détecter une lenteur la dégradation de la qualité du modèle sur plusieurs versions. Assurez-vous plutôt que les prédictions du modèle sur un ensemble de données de validation atteignent un seuil fixe. Si votre l'ensemble de données de validation ne s'écarte pas des données actives, puis mettez à jour votre ensemble de validation ensemble de données et vous assurer que votre modèle atteint toujours le même seuil de qualité.
Valider la compatibilité du modèle-infrastructure avant l'inférence
Si votre modèle est mis à jour plus rapidement que votre serveur, il est possible que différentes dépendances logicielles de votre serveur, ce qui peut entraîner d'incompatibilités. Assurez-vous que les opérations utilisées par le modèle sont présentes le serveur en préproduisant le modèle dans une version du serveur en bac à sable.