Business : Comment la politique interne interfère avec la science des données

Comment les entreprises peuvent aider les scientifiques des données à faire leur travail

L’apprentissage automatique en production est un phénomène assez nouveau, et en tant que tel, le manuel de gestion des équipes de science des données qui construisent des pipelines ML de production est toujours en cours d’écriture. En conséquence, les entreprises bien intentionnées se trompent souvent et mettent accidentellement en place des politiques qui, bien que conçues pour améliorer les choses, gênent en fait leurs scientifiques des données.

Je travaille avec de nombreuses équipes de science des données (pour le contexte, je contribue à Cortex, une plate-forme de service de modèle open source) et j’entends constamment des histoires sur des politiques internes étranges qui, tout en étant conçues pour rendre les choses plus fluides, rendent leur quotidien plus difficile.

Des politiques comme…

Si votre équipe n’utilise pas de machines locales, presque toutes les opérations que vous effectuez nécessitent des ressources cloud. Traitement des données, formation et évaluation des modèles, expérimentation de blocs-notes, déploiement de modèles en production – tout nécessite un serveur.

J’ai travaillé avec plus d’une équipe dans laquelle tout la demande de ressources cloud devait être soumise officiellement pour approbation. Cela signifie que presque toute nouvelle opération liée au ML nécessite un processus de demande.

En règle générale, les entreprises adoptent cette configuration à des fins de sécurité et de contrôle. Moins les gens ont accès au cloud, la réflexion va, moins il y a d’erreurs. Le problème est que le développement ralentit à une analyse dans ces environnements. Au lieu d’explorer de nouvelles idées ou de construire de nouveaux modèles, les scientifiques des données passent des jours à parcourir la paperasse nécessaire pour obtenir une instance EC2.

Accorder aux scientifiques des données des privilèges cloud, au moins suffisamment pour qu’ils puissent effectuer indépendamment les opérations cloud de base requises pour leur travail, augmenterait considérablement la vitesse à laquelle les équipes se déplacent.

Une équipe de science des données avec laquelle nous avons travaillé avait en fait ses propres comptes AWS, un pour le développement et un autre pour la production. Leur compte de développeur, où ils ont fait de la formation sur modèle, avait accès aux GPU. Leur compte prod, où les modèles ont été déployés, ne l’a pas fait.

À un certain niveau, vous pouvez voir d’où vient l’équipe DevOps. Ils étaient tenus responsables des dépenses dans le cloud, et l’inférence GPU peut coûter cher. Si les scientifiques des données s’en sortaient auparavant, pourquoi en avaient-ils besoin maintenant?

Pour obtenir des GPU, l’équipe de science des données devrait prouver que les modèles qu’ils déployaient ne pouvaient pas générer de prédictions avec une latence acceptable sans GPU. Cela représente beaucoup de friction, en particulier lorsque vous réalisez qu’ils exécutaient déjà des instances de GPU en dev.

Une équipe de science des données avait des politiques étranges en ce qui concerne les ordinateurs portables.

Fondamentalement, le service informatique était très vigilant pour s’assurer qu’il n’y avait pas de dépenses inutiles, en particulier sur les instances de bloc-notes. Ils étaient agressifs pour s’assurer que les instances étaient supprimées dès que possible et devaient se déconnecter de toute nouvelle instance de bloc-notes.

En théorie, tenir quelqu’un responsable de la gestion des ressources est une bonne chose. Cependant, tenir quelqu’un responsable de la gestion une autre équipe les ressources sont clairement une recette pour un désastre. Au lieu de se retrouver avec une équipe de science des données maigre et financièrement responsable, ces entreprises dépensent de l’argent sur le temps perdu, car les scientifiques des données passent des heures à se tourner les pouces en attendant l’approbation du service informatique.

De plus, c’est terrible pour le moral. Imaginez-vous devoir déposer un ticket juste pour ouvrir un cahier? Ou devoir répondre à des questions approfondies sur une instance de bloc-notes de longue durée?

Aussi frustrantes et bizarres que ces politiques puissent paraître, elles sont toutes conçues à des fins légitimes. Les entreprises veulent mettre en place des sauvegardes pour contrôler les coûts, créer des responsabilités et garantir la sécurité.

L’erreur, cependant, est que ces garanties sont instituées par le biais de politiques de gestion alors qu’elles devraient être intégrées à l’infrastructure.

Par exemple, au lieu d’avoir une politique de demande de ressources cloud, certaines des meilleures équipes avec lesquelles nous travaillons donnent simplement des rôles IAM aux scientifiques des données avec des autorisations limitées. De même, au lieu d’avoir une autre équipe surveillant constamment les scientifiques des données, de nombreuses entreprises donnent à l’équipe de la science des données un bac à sable provisionné mais limité pour expérimenter.

Nous pensons à la façon de résoudre ces problèmes via l’infrastructure tout le temps lors de la construction de notre plateforme de service modèle. Par exemple, nous voulons réduire les coûts d’inférence, mais nous voulons également donner aux scientifiques des données la latitude d’utiliser le meilleur outil pour le travail. Au lieu d’imposer des limites à l’inférence GPU, nous avons développé la prise en charge des instances ponctuelles. Désormais, les équipes peuvent utiliser des instances GPU avec ~ 90% de remise.

Lorsque vous essayez d’appliquer ces protections via des stratégies de gestion, vous introduisez un réseau complexe de dépendances humaines et une hiérarchie d’autorité. Inévitablement, cela ralentit la progression et introduit des frictions.

Cependant, lorsque vous installez ces protections en tant que caractéristiques de votre infrastructure, vous permettez à votre équipe de se déplacer de manière indépendante et rapide, juste avec quelques garde-corps.