Découvrez le ML Engineering

Déjà, de quoi parle-t-on quand on utilise le terme ML Engineering ? Est-ce simplement un rebranding des compétences du Data Scientist ? On entend souvent parler de MLOps aussi. Est-ce que le ML Engineering et le MLOps sont de simples synonymes ?

Je peux d’ores et déjà vous dire que la réponse à ces deux questions est non. Toutefois, la Data Science, le ML Engineering et le MLOps s’intersectent beaucoup plus qu’ils ne diffèrent.

En outre, comme le ML Engineering est relativement récent, sa direction est encore changeante aujourd’hui dans le marché de la Data, surtout après le boom de la GenAI. Les définitions et les délimitations de ce domaine ne sont pas encore sèches et tout ne fait pas consensus. Je vais vous présenter mon retour d’expérience terrain, basé sur ma compréhension du marché et les sources que j’ai pu recueillir. Il y aura nécessairement une part de subjectivité.

Maintenant, essayons de clarifier tout cela ensemble ! 

Comprenez d’où a émergé ce rôle

Une chose est sûre, très peu de gens parlaient de ML Engineer en France en 2017-2018. Et comme on avait déjà des Data Scientists à l’époque, cela signifie que ce terme a dû émerger pour combler un manque dans les projets de ML.

Il y a à peu près une dizaine d’années, la quasi-totalité des entreprises (y compris les groupes du CAC 40) découvraient le ML, qui faisait partie de projets “Innovation”, ou R&D sans valeur métier nécessairement tangible. À cette époque, pour affirmer qu’un projet ML “Innovation” était un succès, il suffisait de démontrer que l’on arrivait à entraîner un modèle avec de bons scores (R2, MAE, Matrice de confusion) sur une extraction statique de données, au sein d’un Jupyter Notebook.

Le Data Scientist était alors la vedette, c’était le seul profil avec le socle de compétences nécessaire pour donner vie à ces projets d’innovation.

Les besoins du marché ont commencé à changer quand les projets ML sont devenus victimes de leurs succès. Les Data Scientists ont produit des modélisations convaincantes auprès des décideurs, ils voyaient le potentiel, ainsi que la valeur ajoutée métier, il fallait maintenant “juste” les industrialiser. Tout est dans le “juste”.

Les décideurs, et même parfois les Data Scientists, sous-estimaient l’effort nécessaire de sortir d’un Jupyter Notebook pour aller vers un système en production, et de passer d’un snapshot d’historique de données vers un flux dynamique, connecté au modèle ML. “Après tout, ça n’est que du code en plus” on pourrait se dire. En réalité, il faut des compétences en software engineering pour gravir cette marche assez haute. Le software engineering ne s’improvise absolument pas et c’est exactement pour cela que le ML Engineering a émergé.

Eh oui ! Le Data Scientist ne peut pas tout faire. S’il doit être responsable de toutes les tâches opérationnelles liées à l’analyse de données et à la modélisation ML, il est très difficile (surtout à l’époque) de lui demander également d’encaisser toute la complexité opérationnelle nécessaire pour industrialiser un modèle ML avec des compétences en software engineering.

Pour gagner en efficacité et passer plus rapidement à l’échelle, les entreprises ont opté pour un découpage des rôles et des responsabilités. La phase en amont de prototypage, d’exploration de la donnée et de modélisation est sous le périmètre du Data Scientist. Le nécessaire pour passer des modèles à l’échelle, va chez le ML Engineer.

Enfin, cette image, tirée de cet article, nous propose un visuel assez pertinent au niveau des délimitations entre Data Scientist et ML Engineer. Alors :

 

Encore une fois, plusieurs experts placent le curseur un peu différemment, mais dans les grandes lignes, on va venir séparer les choix de modélisations statistiques, des choix d’ingénierie pour déployer les modélisations conçues.

On sait maintenant que le ML Engineer a un versant “Stat” et un versant “Software”. Rentrons un peu plus dans le concret de ce que cela signifie !

Quels sont les enjeux “Software” en ML Engineering ?

L’approche de modélisation conçue par un Data Scientist reste au final… un ensemble de scripts purs et simples, le plus souvent en Python.

Pour déployer un script Python, quel que soit son contenu, il y a certaines étapes à suivre et certains outils phares à utiliser. Ce sont les mêmes outils qui sont employés par les développeurs Python, qui n’ont jamais touché au Machine Learning (Eh oui ! N’oublions pas que Python est largement utilisé pour bien d’autres problématiques que l’analyse de données !).

Bien que le Machine Learning ait clairement ces spécificités, et nous reviendrons là-dessus tout au long de ce cours, nous n’avons pas à réinventer la roue sur plusieurs aspects pour déployer un modèle.

Cela signifie : S’assurer que tout le code nécessaire embarquant le ML fonctionne correctement, sous une infrastructure adaptée, à chaque fois que l’on en a besoin, et la capacité de modifier le tout sans régresser en qualité.

Décomposer cette phase, nous aidera à comprendre chaque facette technique à prendre en compte dans le déploiement. 

Commençons par “sous une infrastructure adaptée”. La première différence fondamentale entre un projet ML en production et un autre qui ne l’est pas, c’est que ce dernier ne peut fonctionner que dans l’ordinateur du Data Scientist qui a conçu la modélisation. Implicitement, déployer un modèle revient à se donner les moyens de faire tourner ce code dans un autre PC, qui est le plus souvent une machine virtuelle louée à distance, via un Cloud Provider.

En fonction des besoins du projet, il nous faut une machine plus ou moins puissante (nombre de GPU et de CPU, RAM, stockage, etc.), cela fait partie de ce que l’on appelle, une infrastructure adaptée. On en reparlera brièvement lors du dernier chapitre du cours.

Passons à “tout le code nécessaire”. Comme dit tout à l’heure, un code de ML n’est pas juste un script où l’on entraine un modèle et où on réalise des inférences. Il faut charger la donnée, la pré-processer, calculer des features, entraîner un modèle et l’évaluer ou l’utiliser en inférence, puis éventuellement post-processer la donnée et réaliser des analyses complémentaires. Tout cela signifie plusieurs scripts Python, plusieurs packages Python et plusieurs configurations systèmes (comme des login/passwords à des bases de données, ou à un Cloud Provider) !

Dans “fonctionne correctement”, il y a deux volets :

• Ne pas avoir de bugs qui stoppent le code en production, l’empêchant ainsi d’aller au bout de son exécution.

• Ne pas avoir un code qui tourne de bout en bout, mais qui produit des résultats incohérents.

Les tests unitaires et les tests d’intégration sont nos amis, nous les verrons au fil du cours.

“À chaque fois que l’on en a besoin” soulève des questions intéressantes. Devons-nous avoir une infrastructure (pour faire simple, un PC à distance) qui est active 24h/24 et 7j/7 ? Si ce n’est pas le cas, comment activer l’infrastructure, uniquement quand on en a besoin ? Comment est-ce qu’un utilisateur non-technique et qui ne sait pas coder va interagir avec le modèle pour obtenir une prédiction ?

Les deux prochains chapitres vont répondre à ces questions. Nous allons découvrir ensemble l’outil FastAPI, acteur incontournable dans le monde du ML Engineering !

Ensuite “Modifier le tout sans régresser en qualité”. Comme dans n’importe quel projet, nous avons rarement toutes les réponses avant de déployer un modèle, et nous devons souvent faire des modifications, bien après que le modèle soit déployé. En plus des tests unitaires, comment est-ce qu’on se donne les moyens de livrer des modifications, tout en s’assurant de n’avoir rien cassé par inadvertance,sans y passer des heures de débugging manuel ?

C’est une problématique partiellement adressée par les pipelines CI/CD que nous allons également découvrir dans la partie 2 de ce cours !

Je comprends beaucoup mieux les étapes techniques ! Mais rien de tout ça ne m’apprend QUAND est-ce qu’il est nécessaire de remplacer un modèle de ML déjà en production par un nouveau ?

C’est la transition parfaite vers la partie suivante. 

Et la partie “Stat” ?

Certes, il faut des compétences en software engineering pour déployer un modèle de Machine Learning. En revanche, un modèle ML ne peut pas être complètement traité comme n’importe quel autre software.

La différence principale entre un software classique et un script avec du ML, réside dans le côté non déterministe du ML.

Là-dessus, je ne vous apprends rien.Un modèle ML est statistique, il distille la donnée qu’on lui fournit en apprentissage, et se sert de cette distillation pour produire des prédictions sur de nouvelles données.

En cas de drift, nous devons souvent (mais pas toujours) ré-entraîner notre modèle de ML. Mais une fois qu’on a dit ça, on n’a pas dit grand-chose :

• Dois-je ré-entraîner sur tout l’historique précédent, en y ajoutant simplement la donnée récente ?

• Dois-je pondérer l’importance de mes observations, ou appliquer un rééchantillonnage ?

• Est-ce que mes features les plus importantes le resteront toujours avec mes nouveaux changements ?

Et j’en passe et des meilleures ! Toutes ces problématiques n’existeraient pas si la donnée était déterministe au lieu de statistique, si elle traduisait un contexte constant et pas changeant. Les compétences en software engineering ne suffisent pas.

Ajoutons à cela le fait qu’un “ancien” modèle et un nouveau modèle peuvent coexister. En effet, il est habituellement difficile d’obtenir un modèle de ML qui est meilleur que dans l'absolu et à tous les niveaux de son prédécesseur. Le plus souvent, on arrive à une amélioration en agrégé, à savoir une métrique plus élevée au global (comme une MAE ou un R2). En regardant de plus près, on a un nouveau modèle qui est meilleur dans la majorité des cas, mais moins bon concernant une minorité. Si celle-ci est non négligeable, il est pertinent de ne pas jeter à la poubelle l’ancien modèle.

C’est un socle de compétences fondamentalement différent de celui du software engineering. Devenir un ML Engineer doué sur la partie Stat ET la partie Soft vous rendra un profil extrêmement rare !

Si vous allez lire des fiches de postes de ML Engineer, vous observerez une certaine hétérogénéité. Des fois, on exige beaucoup plus la partie “Software” et très peu la partie “Stat”. D’autres fois, les fiches de postes demandent en réalité Data Scientist, mais avec suffisamment de compétences en “Software” pour déployer de temps en temps des modèles et en garantir la fiabilité.

Comparez ML Engineering et ML Ops 

La confusion entre ML Engineering et MLOps est fréquente, et pour cause : ces deux disciplines se chevauchent considérablement. Cependant, comprendre leurs nuances vous aidera à mieux naviguer dans l'écosystème professionnel actuel. Ce point fait particulièrement partie de ceux qui ne font pas consensus dans le marché aujourd’hui, au point où certains disent qu’il s’agit de la même chose.

Déjà, prenons toutes les briques mentionnées dans la partie Software et Stat des sections précédentes. En principe et sauf cas particulier, tous les projets MLs de l’entreprise doivent partager le même tooling, les mêmes bases de données de départ, les mêmes structures de repository Git et ainsi de suite.

L’objectif du MLOps est alors de standardiser les pratiques tout en donnant assez de liberté pour prendre en compte les spécificités des projets. On évite ainsi de réinventer la roue et on rend la boîte à outils du ML Engineering encore plus efficace à utiliser.

L’interview est accompagnée de mes commentaires, qui distillent les points saillants de mon échange avec lui. Pour éviter de paraphraser le cours, je vous résume en un paragraphe son point de vue complémentaire à celui de Maria :

Le MLOps n’est pas qu’un ensemble de process et d’outils standardisés. Une approche MLOps va plus loin et épouse la culture de l’entreprise, sa structure organisationnelle et le niveau technique des profils Data. Le MLOps est avant tout un mindset, qui vise à créer de la valeur plus rapidement, même si cela passe par un outillage moins idéal, mais qui sera plus facilement adopté par les équipes.

Maintenant, il est vrai que quand on est dans une petite équipe, avec peu de projets ML, dont certains sont en production et d’autres qui ne le sont pas encore, alors la distinction entre MLOps et ML Engineering fait moins de sens. En effet, on n’a pas encore généré assez de complexité pour que les différences entre MLOps et ML Engineering se fassent ressentir. La priorité sera de donner vie aux projets avant de gérer leur cycle de vie.

En résumé

• Distinguez le rôle du ML Engineer de celui du Data Scientist : le premier industrialise, le second modélise.

• Comprenez que le ML Engineering repose sur deux piliers : compétences en software engineering et maîtrise des enjeux statistiques.

• Utilisez les bons outils pour déployer : Docker, UV, FastAPI, tests, CI/CD, etc.

• Adaptez l’infrastructure à la production : environnement cloud, code portable, reproductibilité.

• Ne confondez pas ML Engineering et MLOps : le premier agit à l’échelle d’un projet, le second à l’échelle d’une plateforme.

Voyons maintenant comment exposer un modèle ML en ligne grâce à une API, et découvrir les fondations de FastAPI !