La question de savoir comment structurer un projet d'apprentissage automatique et ses phases de formation et de test a beaucoup à voir avec la façon dont nous avançons dans le « cycle de vie » du ML et faisons passer le 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 à placer la formation ML sur une machine locale puis à déplacer l'exécution vers un système basé sur un serveur est l'avantage d'une séparation essentielle des tâches. En général, vous souhaitez que l'ensemble de formation soit isolé, afin que vous ayez une idée claire du début et de la fin de la formation, ainsi que du début des tests. Cet article de KDNuggets aborde 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 sur des architectures très différentes, vous ne serez jamais confus quant à l'allocation conjointe d'entraînement et de 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, il n'est pas nécessaire qu'elle soit 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 dans le modèle de serveur.
De plus, certains de ces modèles « isolés » peuvent aider à résoudre des problèmes tels que la dérive des concepts et les contextes cachés : le principe de « non-stationnalité » avertit les développeurs que les données ne « restent pas les mêmes » au fil du temps (en fonction de ce qui est mesuré) et qu'il peut falloir beaucoup d'adaptabilité pour faire correspondre une phase de test à une phase de train. Ou, dans certains cas, les processus de formation et de test se mélangent, créant ainsi une confusion.
Déployer la phase de test sur un serveur pour la première fois peut faciliter 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 à transmettre les ordres de modification sur plusieurs plates-formes.
Ensuite, l'environnement serveur sert évidemment les processus en temps réel ou dynamiques dans lesquels les ingénieurs voudront accéder au transfert de données et aux modèles de code qui fonctionnent le mieux pour la production en ML. Par exemple, AWS Lambda peut être une option intéressante pour gérer les microfonctions de production (ou une combinaison de stockage d'objets Lambda et S3) et sans connectivité (sans serveur) cela devient impossible.
Ce sont quelques-uns des problèmes auxquels les développeurs peuvent réfléchir lorsqu'ils réfléchissent à la manière de séparer les phases de formation ML des tests et de la production.