Structurer son Projet de machine learning

La technique est indispensable. C’est bien souvent par elle que commence le progrès. Ce n’est qu’après que les chercheurs interviennent en l’intellectualisant; c’est du moins ce que soutient Nicolas Nassim Taleb dans « antifragile »

Toutefois la technique n’est pas tout. Avoir une structure clair et bien pensée permet d’aller plus loin et plus vite sur le long terme.

Et en Datascience, on a la chance que CookieCutter s’en soit occuper en concevant une template auquel notre projet devrait s’efforcer de ressembler. Car suivre rigoureusement quelque chose sans se poser des questions n’est jamais une bonne chose; alors n’hésitez pas à prendre vos liberté et adapter la structure à votre cas!

Cookie Cutter - Qu’est-ce que c’est ?

Cookie Cutter est un cli qui permet de générer une structure pour les projets data science.

Il rajoute une grosse part de « sérieux » et donne enfin cet aspect « industrieux » qui manque tant à notre discipline.

On n’est plus au niveau d’un data-scientist qui crée 2-3 notebooks et de la data dans tous les sens. Avec qui on peut avoir quelques rapports et analyses bien jolis, mais les étapes pour l’obtenir sont ésotériques et brumeux. La reproductibilité du code est jeté aux oublis. Alors que c’est un point essentiel de la qualité du code.

Un code qui permet de retrouver des résultats corrects et reproductibles.

Cela se fait en 2 commandes :

pip install cookiecutter-data-science
ccds

On obtient alors la structure suivante , modulo quelques changement selon les paramètres de votre projet

Best Practices Machine learning :

et Pourquoi Cookie Cutter en est un condensé ?

1 .  L’analyse de données doit être vue comme un graphe orienté acyclique (DAG).

Les éléments les plus importants d'une analyse de données de qualité sont la justesse et la reproductibilité.

—> Toute personne doit pouvoir relancer votre analyse en utilisant uniquement votre code et les données brutes pour obtenir les mêmes résultats finaux.

Pour cela,  il faut considérer votre pipeline d'analyse comme un DAG, où chaque étape est un nœud dans un graphe orienté sans boucle.

Vous pouvez exécuter le graphe dans un sens pour recréer n'importe quel résultat d'analyse, ou le parcourir en sens inverse pour examiner la combinaison de code et de données qui a conduit à ce résultat

2. Les données brutes sont immuables

Dans une analyse de données vue comme un graphe orienté acyclique (DAG), les données brutes doivent rester immuables. Vous pouvez les lire et les copier pour créer de nouveaux résultats, mais ne les modifiez jamais directement.

À éviter :

• Ne modifiez jamais les données brutes, surtout pas manuellement ou dans Excel.
• Ne remplacez pas les données brutes par des versions traitées.
• Ne sauvegardez pas plusieurs versions des données brutes.

À noter, qu’il faut éviter des mettre sa donnée dans les sources control tels que git. Mettez les plutôt dans un cloud ( S3, Azure Blob storage …) ou dans un serveur on-prem.

Le folder « data/» devrait aller directement dans le .gitignore

3. Les notebooks sont pour l'exploration et la communication, le code source est pour la répétition

Les notebooks, comme Jupyter Notebook ou Apache Zeppelin, sont excellents pour l'exploration des données et la visualisation rapide des résultats. Cependant, ils sont moins adaptés pour reproduire une analyse. Le code source est supérieur pour la répétabilité car il est plus portable, plus facile à tester et à relire.

4. Refactorisez les bonnes parties dans du code source

Évitez de répéter le même code dans plusieurs notebooks.

‼️ Les signes que vous êtes prêt à passer du notebook au code source incluent :

• la duplication de notebooks pour en créer de nouveaux
• le copier-coller de fonctions entre notebooks
• la création de classes orientées objet dans des notebooks.

💡Tips : Exécuter cela dans la première cellule du notebook

%load_ext autoreload
%autoreload 2

Pour que les changements dans votre code source soient pris en compte dans votre notebook directement.

5. Ne pas négliger l’organisation des modèles

Documenter les expériences de modélisation est essentiel pour assurer la reproductibilité, l'apprentissage continu et l'amélioration. Vous devez mettre en place des procédures de documentation permettant d'identifier au minimum

• la provenance des données
• la version du code utilisée
• les métriques de performance.

Vous pouvez même utiliser des outils plus avancés tel que MLFlow.