A la croisée de plusieurs disciplines, la Data Science s’appuie sur des méthodes et des algorithmes pour tirer des informations et de la connaissances à partir de données structurées et non structurées. Encore inconnu il y a quelques années, les métiers de la Data Science et du Machine Learning évoluent très vite. Compétences, méthodes, outils… dans cette série d’entretiens, nous confrontons notre expérience à celle du marché, avec la participation de Data Scientists et ingénieurs Machine Learning externes à Devoteam Revolve.

Damien Matias est Lead Machine Learning Engineer au sein du Datalab d’Euler Hermes.

Comment es-tu devenu ingénieur ML ?

J’ai un master en informatique de l’ECE Paris où je me suis spécialisé en Data&Analytics lors de la dernière année. En sortant de l’école, j’avais l’envie d’être Data Scientist, mais je n’avais pas exactement le profil. Le profil de Data Scientist est très orienté sciences, théorie, recherche alors que mon profil tendait plutôt vers le développement, avec une appétence pour la Data Science et le Machine Learning. Lors de mon stage de fin d’étude, j’avais un rôle très hybride : un peu de data science, du développement, du Cloud, le tout orienté vers la Data. En fait, j’étais un peu entre le data engineer et la data science, et de fait j’ai postulé pour des offres de ML Engineer.

C’est donc un rôle plus orienté vers le Dev ?

Comparé au rôle de Data Scientist, de mon point de vue oui. La grosse différence est le fait qu’un Data Scientist essaie de résoudre une problématique sans savoir s’il existe une solution tandis qu’un MLE implémente des solutions en assemblant plein de briques entre elles (dont des briques potentiellement implémentées par le DS). On est capable d’estimer plus ou moins le temps de travail d’un MLE mais cela est impossible pour un Data Scientist. C’est la différence entre de la recherche et du développement de solution.

Quelles compétences utilises-tu ?

Les connaissances ML dont j’ai besoin sont générales : comment on utilise le ML, dans quels cas c’est judicieux, quels sont les outils/frameworks utilisés, quels sont les besoins d’un DS, quel type de modèle utilisé dans quel cas, etc. Je n’ai donc pas vraiment besoin de connaître le détail de chaque modèle ni d’avoir les compétences mathématiques ou statistiques pour tout comprendre. Au quotidien, ce sont les compétences en Python qui me sont utiles dans l’industrialisation des modèles.

J’aide les Data Scientists à industrialiser leur travail, car la recherche se fait dans les notebooks, mais ce ne sont pas des outils d’industrialisation. Mon travail consiste donc à aider les Data Scientists à préparer leur code Python pour l’industrialiser : packager le code, le mettre dans une image Docker, écrire des tests, écrire de la documentation, développer une API, etc.

Des compétences Cloud également ?

Oui, il y a également tout un volet de compétences Cloud / DevOps, AWS dans notre cas. Une fois notre modèle packagé, il faut définir une infrastructure Cloud, l’implémenter puis le monitorer. Une importante partie de mon travail consiste à écrire du code Terraform.

Quels sont les outils au quotidien ?

Pour le code, j’utilise des IDE comme VSCode ou PyCharm (pour le Python).

Nous utilisons aussi Gitlab-CI, Terraform et Docker. Côté monitoring nous avons Prometheus/Grafana et Sentry. Nous avons également des outils de gestion de projet et de collaboration.

Est-ce que vous utilisez des outils AWS spécifiques Machine Learning ?

Nous utilisons surtout les services “classiques” AWS : EC2, Lambda, ECS, RDS, s3, DynamoDB, EMR pour du Spark… Comme le Datalab a été lancé en 2016, nous avons construit notre plateforme sans AWS Sagemaker. C’est un très bon outil quand on part de zéro, il permet d’avoir rapidement des modèles en production, mais dans notre cas d’autres services AWS sont plus adaptés à la spécificité de nos besoins.

L’usage de Sagemaker dépend de la maturité des équipes : il peut être intéressant surtout si on utilise l’ensemble de l’écosystème Sagemaker; dans le cas contraire, il entraîne un surcoût par rapport à l’usage d’un service AWS plus généraliste. Néanmoins, si demain je devais lancer un projet avec une nouvelle équipe, je partirai sur une solution autour de Sagemaker, car disposer de nombreux services prêts à l’emploi permet de gagner beaucoup de temps.

Quels outils ou fonctionnalités vous manquent dans le ML ?

L’industrie a fait un gros focus sur la partie des modèles, c’est-à-dire comment trouver le meilleur modèle avec un jeu de données. On dit souvent qu’un data scientist passe 80% de son temps sur les données, 20% sur les modèles et c’est totalement vrai chez nous. Nous avons beaucoup d’outils à notre disposition consacrés aux modèles et l’entraînement, et beaucoup moins sur la phase précédente, qui est le feature engineering, et qui pourtant occupe 80% du temps. J’aurai tendance à dire qu’un DS aimerait plus passer du temps sur la partie modeling d’où l’intérêt du Feature Store.

Qu’est-ce que le Feature Store ?

Le nerf de la guerre, c’est la data, et les features qu’un modèle prend en entrée. Une feature est une transcription des données brutes en quelque chose de lisible par un modèle. Prenons par exemple la date de création d’une société : pour un modèle une date ne veut rien dire, mais on peut ajouter une feature “âge de la société” qui est égale à la date d’aujourd’hui moins la date de création. On transforme les données brutes en données que le modèle peut exploiter.

La difficulté est que les DS utilisent des données brutes en provenance d’une ou plusieurs data sources, et au moment où on part en production, les data sources ont changé, et le code n’est plus forcément compatible. Il faut alors réécrire du code : une nouvelle API, adresser une autre base de données…et on se retrouve à devoir maintenir du code pour l’entraînement et du code pour la production. Pourtant on veut que les 2 soient synchronisés parfaitement sinon le modèle peut drifter ou du moins ne pas renvoyer les résultats attendus.

Autre sujet : plusieurs Data Scientists peuvent travailler sur les mêmes data sources pour des modèles différents. Chacun développera ses propres features, ce qui pose la question de la ré-utilisation des features. C’est aujourd’hui assez compliqué. On peut se partager du code mais il faut être hyper méticuleux dans l’implémentation car le code doit être assez généralisable pour être réutilisé ailleurs.

Le Feature Store répond à l’ensemble de ces problématiques, en proposant des features pré calculées, stockées, et disponibles aussi bien pour l’entrainement que la production. Ce qui permet d’assurer des données iso entre entraînement et production. Le partage des features entre DS est également possible.

Le Feature Store permet aussi de garder un historique – on va pouvoir revenir dans le temps pour certaines features, avec un store offline pour l’historique, et un store online pour la dernière version. Un accès “low-latency” à la dernière version d’une feature permet de maintenir un haut niveau de performance pour les modèles en production. Le Feature Store permet de résoudre ces différents pain points des DS, surtout quand l’équipe grandit car il devient de plus en plus crucial de partager le travail de tout le monde. C’est un pas dans le sens de l’industrialisation, mais il aide aussi à la recherche grâce à un accès plus aisé aux features.

Quels sont vos cas d’usages métier ?

Nous avons des sujets assez classiques, liés à la gestion du risque et à la détection de fraudes par exemple. Nos projets de Machine Learning concernent l’ensemble de la chaîne de valeur de l’entreprise. Le plus souvent nous travaillons avec des données structurées, issues de bases de données, mais nous avons aussi des nouveaux projets avec des données non structurées, par exemple issues de PDF. 

Comment le Datalab est-il organisé ?

Nous avons trois profils : les Product Managers, les Data Scientists, et les Machine Learning Engineers. En termes d’organisation, ce sont les DS et/ou les PMs qui sont en relation avec le métier; les PMs recueillent les besoins, et le reste de l’équipe essaie d’y répondre. L’idée c’est que sur chaque projet, une ou plusieurs personnes de chaque rôle sont associées. Dans le même temps, tout le monde est associé à un ou plusieurs projets ce qui permet de faire monter tous les membres en compétences. 

On peut remarquer qu’il n’y a pas de Data Engineer dans l’équipe car ce rôle est souvent occupé par un MLE selon les projets et les appétences de chacun.

Combien de modèles avez-vous en production ?

Nous avons environ une vingtaine de modèles en production, ce qui est plutôt conséquent pour une société comme la nôtre. Nous avons un peu d’avance car nous avons commencé il y a 5 ans. Le premier modèle a été mis en production en 2017, nous avons ensuite pu capitaliser sur cette expérience. 

Comment se déroulent tes journées en tant que ML Engineer ?

L’équipe MLE commence la journée par un daily meeting pour faire le point sur les tâches de la veille, celles du jour et les problèmes en cours, ensuite je travaille sur mes sujets. Le plus souvent, je code. Je prends un ticket dans mon outil de project management puis je le traite, ce qui revient souvent à écrire le code, le tester, créer une branche, une pull request, et je la fais valider par les collègues. Comme je suis passé Lead et que je suis chargé d’un nouveau projet, je passe moins de temps à coder car j’ai plus un rôle de suivi et d’animation de projet.

Le mot de la fin ?

Il est intéressant de voir que la réalité des métiers de la data varie beaucoup en fonction des entreprises.

C’est un sujet qui change rapidement, et chacun a une vision différente du métier; le poste de Machine Learning Engineer recouvre une autre réalité dans d’autres sociétés, parfois il développe des modèles, ce qui n’est pas mon cas aujourd’hui. Cependant, au-delà des titres, il me semble important de parler du concept de ML Ops, qui se base sur les principes du DevOps, pour les appliquer à la data.

Le ML Ops ajoute cependant une notion importante : on ne versionne pas uniquement du code, mais aussi des données et des modèles. Cela ajoute une couche de complexité, qui n’est pas toujours visible de l’extérieur. En effet un nouveau déploiement d’un modèle peut venir de plusieurs éléments déclencheurs : un commit, des nouvelles données, un nouvel entraînement, etc. Ce qui amène énormément de questions concernant le cycle de vie d’un modèle. Nous sommes encore aux débuts du ML Ops, il y a peu de littérature sur le sujet, et les façons de faire dépendent beaucoup du contexte de l’entreprise et des contraintes métier.