4. Des pipelines et des promotions robustes

Les pipelines offrent de nombreuses options pour le réglage des hyperparamètres, l'AutoML et les routines de traitement. Les pipelines sont enregistrés de bout en bout. Des pipelines robustes peuvent exécuter des formations en parallèle sur plusieurs instances et frameworks, en adaptant la taille des charges selon les besoins. Des pipelines robustes peuvent promouvoir la mise en production, le déploiement en temps réel, le streaming et le traitement par lots des modèles. Ces déploiements peuvent prendre en charge l'inférence à modèle unique ou multimodèle.

4.1 Formation distribuée et à grande échelle	Un système ML mature permet d'exécuter des formations sur de grandes instances optimisées pour le calcul en parallèle. Il dispose des outils nécessaires pour garantir que ces ressources sont pleinement utilisées et que la formation s'étale de manière uniforme sur l'ensemble du cluster de calcul.
4.2 Support pour plusieurs frameworks	Les développeurs peuvent porter différents frameworks de plateforme, tels que PyTorch Flax, pour exécuter des tâches de formation et d'inférence. De même, différentes langues et versions sont prises en charge et utilisables. Le passage à un autre framework ne cassera pas le système.
4.3 Réglage des hyperparamètres	Une étape de réglage des hyperparamètres fait partie du pipeline de formation. Les hyperparamètres des modèles déployés sont ajustés. Plusieurs options sont disponibles pour régler les hyperparamètres. Pour améliorer la précision, au moins l'une des options de réglage doit comporter une inférence ou une approche bayésienne.
4.4 Option AutoML	Pour réduire les expérimentations et les comparaisons manuelles, un système ML mature prend en charge l'exécution d'AutoML, qui sélectionne automatiquement le meilleur pipeline de fonctionnalités, les meilleurs hyperparamètres et le meilleur modèle. Notez qu'AutoML est une fonctionnalité à utiliser de manière pragmatique, mais ce n'est pas une panacée.
4.5 Support d'inférence : en temps réel	C'est ce que l'on appelle communément le modèle en tant que service (MaaS). Le système prend en charge l'inférence en temps réel avec les opérations de l'API REST, pour les demandes d'inférence à la demande. Il est capable de fournir une infrastructure MaaS sur laquelle le modèle peut évoluer à la fois horizontalement et verticalement en tant qu'API autonome ou en tant que point de terminaison associé à d'autres applications. Il est également possible de déployer en utilisant la technologie sans serveur.
4.6 Support d'inférence : diffusion en continu	Les modèles peuvent être promus vers un format d'inférence en temps réel tel qu'Amazon Kinesis ou Amazon Managed Streaming pour Apache Kafka, dans lequel l'inférence est exécutée en mode streaming sur le modèle. Cela nécessite qu'au moins 90 % de la liste de contrôle soit complète, car les garde-fous, l'observabilité et la surveillance sont essentiels pour l'inférence en temps réel.
4.7 Support d'inférence : batch	Le système prend en charge le déploiement par lots de modèles sous forme de tâches planifiées ou initiées. Le système peut exécuter des modèles dans le cadre d'un processus d'extraction, de transformation et de chargement (ETL) ou de manière isolée. Les tâches Batch enregistrent l'état de chaque étape et s'exécutent selon un schéma ordonné, tel qu'un graphe acyclique orienté. Les tâches peuvent également écrire dans une base de données, qui joue le rôle de serveur d'inférence du modèle.
4.8 Routines de prétraitement et de post-traitement	Lorsque cela est nécessaire, les données sont présentées dans le cadre du processus d'admission du modèle ou des tâches par lots. Si plusieurs modèles ou plusieurs étapes sont en jeu, les routines de post-traitement se chargent de présenter les données.
4.9 Possibilité d'invoquer des modèles hiérarchiques ou simultanés	Le système ML peut déployer plusieurs modèles ensemble ou les exécuter de manière séquentielle. Dans le premier cas, il s'agit d'héberger sur un seul modèle de point de terminaison au sein d'un parc de ressources. Ce dernier implique que plusieurs modèles doivent fonctionner de manière enchaînée les uns après les autres. Le système peut gérer ces deux types de complexité de manière résiliente.
4.10 Stratégies de mise à l'échelle horizontale et verticale	Un pipeline doit être capable de prendre en charge les deux types de stratégies de mise à l'échelle pour la formation et l'inférence. Le système ML peut augmenter sa taille et répartir le trafic sur plusieurs machines lorsque la latence ou le débit augmentent. Les politiques relatives à ce type de comportement sont définies et tiennent compte de l'allocation optimale des ressources.
4.11 journalisation End-to-end	L'équipe de développement doit avoir défini la journalisation dans tout le code du pipeline afin que la journalisation puisse capturer les entrées, les sorties et les étapes intermédiaires du système. La journalisation doit prendre en charge le suivi des exécutions dans le pipeline et les erreurs de débogage.