Pourquoi exécuter une formation ML sur une machine locale, puis une exécution régulière sur un serveur?

Auteur: Roger Morrison
Date De Création: 28 Septembre 2021
Date De Mise À Jour: 1 Juillet 2024
Anonim
Pourquoi exécuter une formation ML sur une machine locale, puis une exécution régulière sur un serveur? - La Technologie
Pourquoi exécuter une formation ML sur une machine locale, puis une exécution régulière sur un serveur? - La Technologie

Contenu

Q:

Pourquoi exécuter une formation en apprentissage machine (ML) sur une machine locale, puis une exécution régulière sur un serveur?


UNE:

La question de savoir comment structurer un projet d’apprentissage automatique et ses phases de formation et d’essais a beaucoup à voir avec la façon dont nous évoluons dans le «cycle de vie» du ML et passons du programme d’un environnement de formation à un environnement de production.

L'une des raisons les plus simples d'utiliser le modèle ci-dessus consistant à mettre en place une formation ML sur une machine locale puis à déplacer l'exécution vers un système basé sur serveur est l'avantage de la séparation essentielle des tâches. En règle générale, vous souhaitez que l'ensemble de la formation soit isolé, afin que vous ayez une idée précise du début et de la fin de la formation et du début des tests. Cet article de KDNuggets explique le principe de manière grossière tout en passant en revue certaines des autres raisons d'isoler les ensembles de formation sur une machine locale. Une autre proposition de valeur fondamentale pour ce modèle est que, avec les ensembles de formation et de test basés sur des architectures très différentes, vous ne serez jamais confus quant à l’allocation conjointe train / test!


Un autre avantage intéressant concerne la cybersécurité. Les experts soulignent que si vous avez les processus de train initiaux sur une machine locale, celle-ci ne doit pas nécessairement être connectée à Internet! Cela élargit la sécurité de manière fondamentale en «incubant» le processus jusqu'à ce qu'il atteigne le monde de la production, où vous devez ensuite intégrer une sécurité adéquate au modèle de serveur.

En outre, certains de ces modèles "isolés" peuvent aider à résoudre des problèmes tels que la dérive de concept et les inconvénients cachés - le principe de "non-stationalité" avertit les développeurs que les données ne "restent pas les mêmes" dans le temps (en fonction de ce qui est mesuré) et Il faut beaucoup d’adaptabilité pour faire correspondre une phase de test à une phase de train. Ou, dans certains cas, les processus de train et de test se mélangent, créant de la confusion.


Le déploiement de la phase de test sur un serveur pour la première fois peut faciliter la tâche de divers modèles de «boîte noire» dans lesquels vous résolvez le problème de l’adaptabilité des données. Dans certains cas, cela élimine le processus redondant consistant à passer des ordres de modification sur plusieurs plates-formes.

Ensuite, l’environnement de serveur sert évidemment aux processus en temps réel ou dynamiques dans lesquels les ingénieurs voudront accéder aux modèles de transfert de données et de code qui fonctionnent le mieux pour une production en mode ML. Par exemple, AWS Lambda peut être une option attrayante pour gérer les microfonctions de la production (ou une combinaison de stockage d’objets Lambda et S3) et sans connectivité (sans serveur), ce qui devient impossible.

Voici quelques-uns des problèmes auxquels les développeurs peuvent penser lorsqu'ils envisagent de partitionner les phases de formation ML à partir des tests et de la production.