MLOps : les entreprises répètent-elles les mêmes erreurs de bricolage ?

​Traducteur | Cui Hao

Critique | Sun Shujuan

Ouverture

De manière générale, il y a une raison pour laquelle les entreprises ne prennent pas l'initiative de construire leur propre infrastructure de cloud computing. Au cours de la dernière décennie, les équipes d'infrastructure informatique ont tenté de créer leurs propres cloud privés, car elles pensaient qu'ils soutiendraient leur entreprise de manière plus rentable que les cloud publics. Mais contrairement aux attentes, le temps et le coût consacrés au cloud privé ont dépassé les attentes. Une fois le cloud privé créé, davantage de ressources étaient nécessaires pour le maintenir, et il était légèrement inférieur au cloud public en termes de sécurité et d'extension. En conséquence, les entreprises qui construisent leurs propres cloud privés finissent par ne pas disposer de plus de ressources pour investir dans leurs activités principales, mais investissent plutôt beaucoup de temps et de personnel dans une infrastructure qui ne peut pas répondre aux besoins de leur entreprise.

De nos jours, de nombreuses entreprises génèrent des solutions via divers outils open source (tels qu'Apache Spark), mais la plupart des actions MLOps nécessitent des opérations manuelles répétées.

Cela se traduit par des déploiements de modèles prenant des semaines, voire des mois, des temps d'exécution inefficaces (mesurés par le calcul et l'inférence prenant du temps à s'exécuter) et un manque d'observations pour les tests et la surveillance des modèles. En outre, l'approche utilisée était trop personnalisée pour fournir des processus métier évolutifs et réutilisables pour plusieurs cas d'utilisation dans différentes parties de l'entreprise.

Un cas de problème mal diagnostiqué

De plus, des conversations avec les dirigeants des secteurs d'activité et les responsables de l'analyse des données ont conduit à la conclusion que même si l'organisation a embauché de nombreux data scientists, elle n'a vu aucun retour. Au fur et à mesure que la recherche s'approfondit, ils continueront à poser diverses questions et à utiliser ces questions pour identifier les difficultés et les obstacles rencontrés par l'intelligence artificielle. Ils ont rapidement compris que le problème clé résidait dans le « dernier kilomètre » : déployer les modèles et les appliquer aux données en temps réel, en les exécutant efficacement afin que les avantages dépassent les coûts et ainsi mieux mesurer leurs performances.

Pour résoudre les problèmes commerciaux et prendre des décisions commerciales, les data scientists transforment les données en modèles. Ce processus nécessite deux ensembles de compétences : premièrement, l'expertise et les compétences nécessaires pour créer de bons modèles ; deuxièmement, les compétences nécessaires pour utiliser le code pour piloter le modèle dans le monde réel, tout en surveillant et en mettant à jour le modèle. Or, ces deux types de compétences sont complètement différentes.

C'est précisément à cause de cette différence que les ingénieurs ML entrent en jeu. Les ingénieurs ML intègrent des outils et des cadres pour garantir que les données, les pipelines et l'infrastructure fonctionnent ensemble pour produire des modèles ML à grande échelle.

Alors, que faire maintenant ? Embaucher davantage d’ingénieurs en apprentissage automatique ?

Même avec les meilleurs ingénieurs ML, les entreprises sont toujours confrontées à deux problèmes majeurs lors du développement de l'IA :

• Incapacité d'embaucher rapidement des ingénieurs ML : la demande d'ingénieurs ML est devenue si forte que les offres d'emploi d'ingénieurs ML augmentent plus rapidement que les services informatiques. une croissance 30 fois plus rapide. Devant parfois attendre des mois, voire des années, pour que les postes soient pourvus, les équipes MLOps doivent trouver un moyen efficace de prendre en charge davantage de modèles et de cas d'utilisation ML sans augmenter le nombre d'ingénieurs ML pour répondre à la demande d'applications ML. Mais cette mesure introduit un deuxième goulot d'étranglement...
• Manque de bonnes pratiques reproductibles et évolutives pour déployer des modèles, quels que soient l'endroit et la manière dont ils sont construits : l'état actuel de l'écosystème de données d'entreprise moderne est le suivant : différentes unités commerciales utiliseront différentes plates-formes de données. en fonction de leurs exigences en matière de données et de technologie (par exemple, les équipes produit peuvent avoir besoin de prendre en charge le streaming de données, tandis que la finance doit fournir une interface de requête simple pour les utilisateurs non techniques). En outre, la science des données nécessite également de décentraliser les applications entre les unités commerciales plutôt que de les centraliser. En d'autres termes, différentes équipes de science des données disposent d'un ensemble unique de cadres de formation modèles pour les cas d'utilisation (domaines) sur lesquels elles se concentrent, ce qui signifie qu'un cadre de formation unique ne peut pas être établi pour l'ensemble de l'entreprise (y compris plusieurs départements/domaines) de.

Comment tirer le meilleur parti de l'intelligence artificielle

Afin d'améliorer les capacités d'automatisation ; afin de fournir des expériences personnalisées à grande échelle aux utilisateurs afin de tenir les promesses des utilisateurs plus précises, plus granulaires et prévisibles, les entreprises ont investi ; en intelligence artificielle. Mais jusqu’à présent, il existe un énorme écart entre les promesses de l’IA et ses résultats, puisque seulement 10 % environ des investissements dans l’IA génèrent un retour sur investissement significatif.

Enfin, afin de résoudre le problème du MLOps, les responsables de l'analyse des données doivent développer leurs propres capacités autour de la science des données au cœur de l'entreprise, tout en investissant également dans d'autres technologies liées à l'automatisation du MLOps. Il s’agit d’un dilemme courant « construire ou acheter ». Il n’est pas seulement considéré d’un point de vue opérationnel (coût-bénéfice), mais doit également tenir compte de la rapidité et de l’efficacité des investissements en IA dans toute l’entreprise, et de la possibilité de nouvelles méthodes. mieux générer des revenus, des produits et une clientèle, ou réduire les coûts en augmentant l'automatisation et en réduisant les déchets.

Présentation du traducteur

Cui Hao, rédacteur de la communauté 51CTO, architecte senior, a 18 ans d'expérience en développement de logiciels et en architecture, et 10 ans d'expérience en architecture distribuée. Anciennement expert technique chez HP. Il est prêt à partager et a écrit de nombreux articles techniques populaires avec plus de 600 000 lectures. Auteur de "Principes et pratique de l'architecture distribuée".

Titre original :​​MLOps | L'entreprise répète-t-elle les mêmes erreurs de bricolage​​ ?​

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!