MLOps : sécurité et gouvernance intégrées

MLOps est la pratique qui mène un modèle d'apprentissage automatique d'une expérience sur l'ordinateur portable d'une personne à un parcours que votre équipe peut rejouer : entraînement versionné, mise en production contrôlée, surveillance et trace de ce qui s'est exécuté et de qui l'a approuvé. SEYA Group construit ce parcours pour les modèles et la plateforme que vous désignez, afin qu'un modèle en production soit maintenu comme tout autre logiciel.

À qui s'adresse ce service

Aux DSI et responsables data dont les modèles fonctionnent dans un notebook et dont l'entreprise en dépend désormais. Aux responsables informatiques à qui l'on a demandé de « industrialiser » un modèle sans cadre convenu pour le faire. Aux responsables data science dont l'équipe réentraîne à la main et ne peut pas dire quelle version est en production. Aux architectes solutions qui conçoivent la plateforme sur laquelle ces modèles tourneront et veulent concevoir en parallèle le parcours de mise en production.

Si les données dont les modèles ont besoin ne sont pas encore regroupées en un seul endroit, commencez par plateformes de données et analytique. Cette page suppose que les données existent et que les modèles posent problème.

Les problèmes que nous résolvons

• Un entraînement qui ne tourne que sur une machine, avec des dépendances que personne d'autre ne peut reproduire.
• Aucune façon convenue de promouvoir un modèle de l'expérimentation à la production, si bien que cela se fait en copiant des fichiers.
• Aucune trace de la version de modèle en service, des données sur lesquelles il a été entraîné, ni de qui peut le modifier.
• Des modèles qui se dégradent discrètement parce que personne ne surveille leurs entrées ni leurs sorties.
• Des data scientists qui passent leur temps sur l'infrastructure plutôt que sur les modèles.

Ce que vous obtenez

• Évaluation. Une revue de la façon dont les modèles sont entraînés, revus et mis en production aujourd'hui, et une première phase recommandée pour combler les lacunes qui bloquent une mise en production reproductible.
• Recommandation de plateforme. Quels services managés ou outils open source votre équipe exploiterait pour le suivi des expérimentations, le registre de modèles, les pipelines et le serving, et ce qui reste hors de la première phase.
• Construction du pipeline. Les étapes d'entraînement, de validation et de déploiement convenues, en tant que code, avec des environnements séparés et une promotion contrôlée par les vérifications que vous définissez.
• Surveillance. Suivi des entrées, des sorties et des performances du modèle selon les indicateurs que votre équipe choisit, avec des alertes acheminées vers les personnes responsables du modèle.
• Notes de passation. La documentation dont vos ingénieurs et data scientists ont besoin pour exploiter, étendre et auditer le pipeline sans nous.

Déroulement d'une mission

• Appel de cadrage. Vous décrivez les modèles, la plateforme sur laquelle ils tournent et le problème de mise en production que vous voulez surtout résoudre.
• Évaluation. Nous étudions le flux actuel avec vos data scientists et ingénieurs et documentons les lacunes et la première phase.
• Construire le premier parcours. Un modèle traverse le nouveau pipeline de bout en bout, en binôme avec votre équipe.
• Étendre. D'autres modèles suivent le même schéma, et les vérifications ainsi que la surveillance sont ajustées avec votre équipe.
• Passation. Votre équipe exploite le pipeline. Un accompagnement continu n'intervient que si le cahier des charges le prévoit.

Périmètre technique

Le pipeline peut s'exécuter sur AWS, Microsoft Azure ou Google Cloud au moyen des services managés d'apprentissage automatique de la plateforme, ou sur des outils open source, selon ce que votre équipe exploite déjà et ce que le cahier des charges retient. L'infrastructure est définie en tant que code et les modèles sont empaquetés dans des conteneurs lorsque le serving l'exige. SEYA travaille avec le cloud et les outils que vous avez choisis et recommande des options open source lorsqu'elles conviennent.

Ce dont vous avez besoin au départ

Au moins un modèle important pour l'entreprise, les données sur lesquelles il s'entraîne dans un emplacement accessible, et des data scientists et ingénieurs qui prendront en charge le pipeline ensuite. Un compte cloud ou un cluster d'exécution, dont vous êtes propriétaire. Lorsque la plateforme de données n'existe pas encore, il s'agit d'un cahier des charges distinct sous plateformes de données et analytique, et l'analyse de sécurité du pipeline est conçue dans le cadre de sécurité et DevSecOps.

Hors périmètre ici : construire les modèles eux-mêmes, sauf si le cahier des charges l'inclut ; une certification de conformité ; et l'exploitation de la plateforme pour vous après la passation, sauf accord contraire. Lorsque le travail consiste à construire les modèles, notre société sœur Mars Innovation Technology prend en charge cette construction. Le périmètre de SEYA sur cette page est la façon dont ces modèles sont mis en production, surveillés et gouvernés.

Travaux connexes

• Parcourir les études de cas SEYA sur les fondations cloud, la migration et les pipelines de livraison

Questions fréquentes

Faut-il changer les outils que nos data scientists utilisent ?

En général non. Le pipeline enveloppe le code d'entraînement qu'ils écrivent déjà ; les changements portent sur la façon dont il est versionné, exécuté et promu. Lorsqu'un changement d'outil est recommandé, l'évaluation en explique la raison.

À qui appartiennent le pipeline et les modèles ?

À vous. Le code est dans vos dépôts, les modèles dans votre registre et le pipeline s'exécute sur votre compte cloud.

Comment travaillez-vous avec notre équipe data science ?

En tant qu'ingénieurs qui s'intègrent à leur flux de travail. Le premier modèle traverse le pipeline avec eux, de sorte que les conventions soient celles qu'ils ont choisies.

Combien de temps prend l'évaluation ?

Cela dépend du nombre de modèles et d'équipes dans le périmètre et de la qualité de la documentation du flux actuel. Nous convenons du périmètre lors du premier appel et signalons tôt si une extension s'impose.

Pouvez-vous nous aider aussi sur la plateforme de données ?

Oui, dans un cahier des charges distinct. Beaucoup de conversations MLOps commencent par un problème de données, et nous vous le dirons si c'est le cas avant de démarrer le travail sur le pipeline.

Si un modèle dont votre entreprise dépend est encore mis en production à la main, réservez un appel d'évaluation MLOps et décrivez comment il atteint la production aujourd'hui.