Automatiser votre cycle de vie Machine Learning

Dans le cadre de la mise en place d’un système de détection de fraude sur le site La Centrale, un système de Machine Learning a été conçu pour entraîner des modèles de détection de fraude.

Comme on aime les choses bien faites chez Groupe La Centrale, on cherche toujours à automatiser les tâches : faire de l’infrastructure as code.

En général, pour automatiser les déploiements, on utilise des services AWS : CloudFormation, Serverless et AWS CDK.

Ce qu’on attend de ce pipeline est de nous permettre de :

  • Récupérer les datasets nécessaires pour nos trainings
  • Préparer ces données pour qu’elles soient exploitables par AWS SageMaker
  • Faire les trainings
  • Extract du meilleur modèle
  • Évaluer les performances de notre modèle

Pour cela :

  1. on a pensé à mettre en place une pipeline pour faciliter l’entraînement de nos modèles 
  2. celle-ci pouvait alors servir comme exemple de pipeline de Machine Learning pour Groupe La Centrale
  3. est-ce que ça sera un pipeline classique via les outils AWS Codestar : codebuild + codepipeline ?

Première itération : codebuild, codepipeline

Le premier test a été à base de codebuild et codepipeline. On déploie ça avec AWS CDK, classique. Comment s’est déroulé ce test ?  

On s’est tout de suite posé la question du versionning. Est-ce que on se base sur les commit de git ou on utilise les tags git ?

Pour faire simple, on s’est basé sur les tags car on ne voulait pas lancer des trainings à chaque commit. Ça coûterait trop cher ( 😉 notre CTO FE)

A chaque tag Git, le pipeline lance un codebuild. Ce dernier a juste besoin de quelques (trop en vrais) libs python. La mise en place de toutes ces libs a demandé plusieurs itérations, qui nous annonçaient chaque fois qu’il manquait une nouvelle dépendance.

On avait 2 scripts à lancer

  • Le premier fait du feature engineering (qui rend nos données jolies et belles pour les exploiter par SageMaker)
  • Le second lance notre training sur SageMaker.

Les surprises

Les problèmes qu’on a rencontré :

  • Les trainings pour optimiser les hyperparamètres durent plus de deux heures. On ne peut pas monopoliser des ressources codebuild simplement pour attendre la fin des trainings et l’extract du one and only best model. Cela coûte de l’argent et au bout d’une heure, le codebuild timeoutait (valeur par défaut).
  • Le deuxième problème c’est qu’on maîtrise pas du tout python oops. Heureusement, on a un data scientist qui maitrise ce langage (👋🏻 Assvin).

Back to the drawing board alors.

Deuxième itération : template StepFunction

Comment peut-on avoir un CI/CD qui fait la préparation des datasets, l’entraînement, attend, fait l’extract du best job et le publie dans un s3 sans monopoliser des ressources AWS ?

Commençons par séparer les tâches. On devrait avoir des blocs différents qui s’occupent chacun d’une partie spécifique.  On a directement pensé à StepFunction et à faire des lambdas, en utilisant Serverless bien sûr!

Et pourquoi pas faire l’extract des données d’entraînement (comme si on ne lui demande pas assez 😉) ?

Le service StepFunction AWS propose un template « Tune a machine learning model » pour faire l’entraînement d’un modèle de Machine Learning. 

Les surprises

Cool, on va se baser sur ce template : ça va nous faciliter la tâche de mettre en place ce pipeline. En testant ce template, on s’est rendu compte qu’on avait pas trop la main sur le format des données entre les steps. Par exemple, on reçoit les outputs tels que nous les fournissent les services AWS. Par ailleurs, avec ce template, les paramètres sont dans la définition de la stepfunction, ce qui complexifie l’appel.

Troisième itération : Notre Solution

C’est bon on est grand, on va s’inspirer du template pour faire le nôtre.

C’est comme ça que notre solution CI/CD a été mise en place.

Voilà notre fameux pipeline. Une solution qui peut être utilisée pour entrainer plusieurs modèles en parallèles, selon  différentes catégories de véhicule. Dans le cas du Groupe La Centrale les catégories sont auto, moto et loisir, mais ça peut changer.

Pipeline Machine Learning

Cette CI/CD nous permet de récupérer les datasets nécessaires pour l’entraînement via Athena.

Avant de pouvoir les utiliser, ces données ont besoin d’être modifiées et préparées pour l’entraînement. Cette préparation des données se fait via un script python qui se lance avec un CodeBuild mais ça peut être aussi une lambda qui fait la même tâche.

La prochaine étape, c’est de lancer nos trainings via une lambda qui fait un appel SDK pour déclencher les jobs d’hyperparameter tuning.

L’entraînement peut durer des heures.

Lorsqu’il est fini, on a une autre step qui récupère le best model entraîné et qui le push vers un bucket d’artefacts. Ces modèles seront utilisés après pour détecter les fraudes.

On en profite aussi pour calculer les performances de notre modèle ainsi que différentes métriques sur le dataset d’entraînement, pour pouvoir comparer le nouveau modèle aux anciens.

Performance d’un modèle

Conclusion


Cette CI/CD n’est pas le modèle absolu et unique à mettre en place pour tous les projets de Machine Learning.

Dans le cas de l’équipe antifraude, elle a permis d’entraîner automatiquement les modèles. Elle nous a permis aussi d’éviter de faire des tâches à la main comme lancer les entraînements , extraire les modèles…

Cette expérience va permettre aux équipes du groupe La Centrale de gagner du temps sur la conception d’une CI/CD pour leurs projets de Machine Learning et profiter de notre expérience en ne passant pas par nos différentes itérations.

La stack n’est pas parfaite mais elle est désormais stable et fonctionnelle. D’autres solutions existent mais chez Groupe La Centrale, on essaye d’utiliser au maximum les services AWS. Ces derniers ne nécessitent pas d’administration, particulièrement ceux qui sont managés. Si vous avez la même problématique, j’espère que ce retour d’expérience vous permettra de gagner du temps. 

Prochaines étapes

On travaille actuellement sur différents tests que on souhaite mettre en place sur nos modèles de Machine Learning. On va donc intégrer du differential testing ainsi que des tests unitaires et des tests d’intégration afin de monitorer la qualité de nos modèles.

Et vous, comment faites-vous ?

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s