Optimiser le Temps de Valeur des Projets de Data Science : Une Approche Structurée pour l'Expérimentation et le Développement

Réduire le Temps de Réalisation de la Valeur pour les Projets de Science des Données : Partie 1 Dans le cycle de vie d'un projet de science des données, la phase d'expérimentation et de développement est cruciale. C'est ici que les data scientists explorent différents traitements de données, combinaisons de caractéristiques, choix de modèles, etc., pour aboutir à une solution finale adaptée aux besoins de l'entreprise. Ces compétences techniques sont essentielles car elles permettent de tester et d'évaluer rigoureusement chaque élément. L'objectif est d'achever cette phase rapidement pour pouvoir mettre en production les solutions et ainsi commencer à apporter de la valeur à l'entreprise. Ce délai entre le début du projet et sa mise en production est appelé le « temps de réalisation de la valeur ». Toutefois, d'après mon expérience personnelle, la phase d'expérimentation peut rapidement devenir gourmande en temps et menacer la réussite du projet dès son démarrage. Plusieurs facteurs contribuent à ce problème, notamment l'utilisation excessive de Jupyter Notebooks, la parallélisation manuelle des expériments et une mauvaise mise en œuvre des meilleures pratiques de codage. Nous devons parler des Notebooks Les Jupyter Notebooks sont des outils incontournables pour les data scientists grâce à leur capacité d'exécuter du code de manière interactive, créer des visualisations et alterner entre du code et du texte Markdown. C'est généralement le premier choix lorsqu'on commence un nouveau projet ou qu'on explore un nouveau jeu de données. Malgré leurs avantages, les notebooks peuvent aussi conduire à des pratiques délétères : exécutions de blocs de code désynchronisées, fonctions définies à l'intérieur des blocs et clés API ou identifiants codés en dur. Ces habitudes nuisent à l'efficacité et à la maintenance du code. En particulier, définir des fonctions directement dans les notebooks pose plusieurs problèmes. Les tester pour vérifier leur correction et l'application des meilleures pratiques est difficile. De plus, ces fonctions ne peuvent être utilisées que dans le notebook où elles ont été créées, limitant ainsi leur polyvalence. Sortir de ce silo de codage est essentiel pour mener les expériences à grande échelle de manière efficiente. Fonctionnalité Locale vs Globale Certains data scientists sont conscients de ces mauvaises pratiques et optent pour de meilleures méthodes de codage, comme créer des répertoires locaux pour stocker des fonctions réutilisables. Bien que cette approche soit un progrès, elle présente encore des limitations. Au fur et à mesure que vous travaillez sur plusieurs projets, vous générer beaucoup de code avec lequel vous pouvez vouloir réutiliser certaines fonctions. La réutilisation du code en le copiant-collant dans différentes repositories crée des problèmes de maintenance. Si un bug est découvert dans une fonction, il faut consacrer beaucoup de temps pour le corriger dans toutes ses instances. En outre, les fonctions spécifiques à un projet sont souvent légèrement-modifiées lorsqu'elles sont réutilisées, créant des redondances avec peu d'apports supplémentaires. De même, conserver toutes les fonctionnalités dans un seul script devient rapidement ingérable car il se remplira de fonctions non cohérentes et sans lien entre elles. Prendre le temps de planifier l'emplacement et la structure du code peut grandement faciliter la gestion à long terme. Je suggère de créer un dépôt externe pour héberger tout code développé, afin de disposer de briques de construction réutilisables qui peuvent être assemblées pour répondre efficacement aux besoins de l'entreprise. Concentrez-vous sur la Création de Composants, Pas sur la Simple Fonctionnalité Par exemple, lors de l'application de techniques de préparation de données avant de les introduire dans un modèle, il faut considérer plusieurs aspects tels que la gestion des données manquantes, l'échelonnage numerique, l'encodage catégoriel, l'équilibrage des classes (pour la classification), etc. Pour la gestion des données manquantes, différentes méthodes existent : Suppr​ession des valeurs manquantes Imputation moyenne ou médiane Imputation basée sur des modèles Si vous souhaitez tester toutes ces méthodes lors de vos expériences, comment procédez-vous ? Modifier manuellement les blocs de code entre les expériences est simple mais pénible à gérer. Une meilleure approche consiste à utiliser des instructions conditionnelles pour facilement basculer entre les méthodes. Même dans ce cas, conserver ces instructions dans le notebook pose des problèmes de réutilisabilité. La solution recommandée est d'abstraire toutes ces fonctionnalités dans une fonction enveloppe avec un argument permettant de choisir la méthode à appliquer. Ainsi, aucune modification de code n'est nécessaire entre les expériences et la fonction est généralisée pour être réutilisée ailleurs. Ce processus d'abstraction des détails d'implémentation optimise le flux de travail en science des données. Au lieu de reconstruire des fonctionnalités similaires ou de recopier du code préexistant, un dépôt de code avec des composants généralisés permet une réutilisation simplifiée. Cela peut être appliqué à toutes les étapes de votre pipeline de transformation de données, formant une chaîne de traitement cohérente. Considérations de Conception Lors de la structuration d'un dépôt de code externe, de nombreuses décisions de conception doivent être prises. Bien que la configuration finale dépende de vos besoins, voici quelques éléments à considérer : Modularité : Chaque fonctionnalité doit être indépendante et testable. Documentations : Toutes les fonctions et classes doivent être bien documentées. Extensibilité : Le code doit être facilement extensible pour des ajouts futurs. Standardisation : Utiliser des conventions de codage standard. Configurabilité : Contrôler les options de fonctionnalité via un fichier de configuration. Un exemple de configuration qui a fonctionné pour moi : Un répertoire séparé pour chaque composant. Une classe contenant toutes les fonctionnalités nécessaires à un composant. Une méthode d'exécution unique pour orchestrer les étapes. L'accès aux méthodes de ce dépôt est simple. Vous pouvez facilement les importer et les exécuter. Par exemple : ```python from data_transform import DataTransformer transformer = DataTransformer() transformer.run(data, config_file_path='config.json') ``` Un Dépôt Centralisé et Neutre Permet une Collaboration Puissante Posséder une boîte à outils commune de techniques de science des données semble attrayant, mais pourquoi nécessite-t-il un dépôt distinct ? Cette question a été partiellement abordée avec l'idée de découpler les détails d'implémentation de l'application commerciale, favorisant ainsi de codes plus flexibles et réutilisables dans divers scénarios. La vraie force de cette approche réside cependant dans la collaboration entre les membres de votre équipe et vos collègues de l'organisation. Imaginez le volume de code généré par tous les data scientists de votre entreprise. Combien de ce code serait vraiment unique à leurs projets ? Certainement une partie, mais pas tout. Sans dépôt centralisé, une grande quantité de code serait redondante et constituerait une perte de ressources insidieuse. Avec un lieu centralized, les fonctionnalités courantes comme la qualité des données, la sélection de caractéristiques, l'optimisation des hyperparamètres, etc., seraient immédiatement disponibles. Cela accélérerait considérablement le démarrage des expériences. En tant qu'utilisateur d'un tel outil, il est possible que la fonctionnalité désirée ne soit pas dans le codebase. À la place de ne pas utiliser le dépôt centralisé, pourquoi ne pas y contribuer ? Travailler ensemble en équipe, voire en entreprise entière, pour actifement développer et enrichir un code base centralisé offre des possibilités multiples. En bénéficiant de l'expertise de chaque data scientist qui apporte les techniques qu'il utilise régulièrement, une situation de type open-source interne est créée, favorisant la collaboration et accélérant le processus d'expérimentation en science des données. Évaluation par des Professionnels de l'Industrie Les experts en science des données et les leaders d'opinion dans l'industrie saluent cette approche en raison de son impact positif sur la productivité et la qualité du code. La modularité et la réutilisabilité des composants réduisent significativement le temps de réalisation de la valeur, ce qui est crucial pour répondre rapidement aux besoins des entreprises. De plus, la collaboration via un code base centralisé améliore la fiabilité et la robustesse des outils, car plus d'utilisateurs les testent et les affinent. Les entreprises qui adoptent cette méthode voient non seulement une réduction du temps de développement, mais aussi une augmentation de la satisfaction des parties prenantes et une plus grande confiance dans les résultats des projets. Profil de l'Entreprise Cette série d'articles vise à partager des principes qui m'ont aidé à structurer et focaliser mes expérimentations en science des données. En adoptant une approche orientée composants et en créant un dépôt de code externe, j'ai pu optimiser ma capacité à exécuter des expériences à grande échelle. Ce changement de mentalité permet non seulement de rationaliser le workflow, mais aussi de libérer du temps pour des activités cruciales telles que la communication avec les parties prenantes, la collaboration avec les ingénieurs de données pour trouver de nouvelles sources de données et la préparation des étapes suivantes de la mise en production. En fin de compte, cela a permis de réduire le temps de réalisation de la valeur de mes projets, assurant une livraison rapide et fiable aux besoins de l'entreprise.