La planification de projets de ML diffère de celle de projets d'ingénierie logicielle classiques. Les projets de ML sont généralement non linéaires et présentent différents degrés d'incertitude. Elles nécessitent une approche itérative et un état d'esprit expérimental.
Incertitude du projet
La planification en phase précoce peut être difficile, car la meilleure approche n'apparaît généralement pas au début d'un projet. Cette incertitude inhérente rend l’estimation des délais difficile.
Un concours Kaggle récent illustre l'incertitude des projets de ML. Au cours des premières semaines d'une compétition, 350 équipes ont participé. Certaines équipes ont pu faire passer la qualité des prédictions de 35% à 65%. Au cours des deux semaines suivantes, le nombre d'équipes travaillant sur le problème est passé de 350 à 1 400. Toutefois, le meilleur modèle n'a atteint qu'une qualité de prédiction de 68%.
La figure 3 illustre l'incertitude du développement du ML en montrant l'augmentation significative des efforts, mais seulement des gains minimes dans la qualité du modèle.
Image 3. Sur une période de deux semaines, le nombre d'équipes travaillant sur le problème a été multiplié par quatre, mais la qualité du modèle est restée presque la même, ce qui a mis en évidence la difficulté à estimer l'effort d'une solution de ML.
En d'autres termes, plus d'un millier d'équipes, chacune expérimentant une variété de transformations de données, d'architectures et d'hyperparamètres, ne sont parvenues qu'à produire un modèle avec une qualité de prédiction de 68 %.
Un exemple du secteur illustre la non-linéarité des projets de ML, où la sortie n'est pas proportionnelle aux entrées. Deux équipes ont mis plusieurs mois à entraîner un modèle avec une qualité de prédiction de 90 %. Cependant, il a fallu plus de cinq ans à plusieurs équipes pour préparer le modèle à la mise en production et obtenir une qualité de prédiction de 99,9 %.
Ces exemples montrent que le ML prêt pour la production est un processus exploratoire, qui nécessite à la fois un état d'esprit scientifique et d'ingénierie.
Approche expérimentale
Dans la plupart des cas, le développement du ML ressemble davantage à des tests que l'ingénierie logicielle traditionnelle. Le ML nécessite de tester différentes caractéristiques, d'essayer plusieurs architectures et de régler précisément les hyperparamètres. Par définition, les tests ne sont pas forcément concluants. Pour cette raison, il est préférable de planifier l'utilisation d'un framework expérimental.
Examinons les différences entre un plan d'ingénierie logicielle et un plan de projet de ML.
Planifier des projets d'ingénierie logicielle
Dans un plan d'ingénierie logicielle classique, vous définissez les exigences, décrivez les composants, estimez l'effort et planifiez le travail. Il y a un chemin clairement défini vers une solution. Par exemple, les ingénieurs connaissent souvent avec un haut degré de certitude les tâches à effectuer pour créer une application conforme aux spécifications de conception.
Lorsqu'il prévoit le temps nécessaire pour accomplir une tâche, il peut estimer le travail sur la base de projets similaires. Bien que des défis surviennent invariablement, tels que des dépendances inconnues ou l'évolution des exigences, ce qui peut rendre l'estimation parfois difficile, il existe généralement un chemin clair vers la solution.
En revanche, les projets de ML n'ont généralement pas une voie claire vers la réussite.
Planifier des projets de ML
Pour la plupart des projets de ML, vous trouverez la meilleure solution en testant plusieurs approches dans un processus d'essais et d'erreurs. Vous ne connaîtrez généralement pas la solution optimale à votre problème avant d'essayer de le résoudre. Par exemple, l'architecture de la solution optimale peut être un modèle linéaire simple, un réseau de neurones ou éventuellement un arbre de décision. Ce n'est qu'en essayant chaque approche que vous pourrez découvrir la meilleure solution.
Cette ambiguïté rend la planification difficile. Comme nous l'avons vu précédemment, il est difficile de prédire les efforts nécessaires d'un projet de ML. Ce n'est qu'en essayant de résoudre le problème que vous pourrez avoir une meilleure idée du temps et des ressources nécessaires à une solution.
Voici les stratégies recommandées pour planifier les tâches de ML:
Définissez une zone de temps pour le travail. Définissez des délais clairs pour effectuer des tâches ou essayer une solution particulière. Par exemple, vous pouvez allouer deux semaines pour déterminer si vous pouvez accéder au bon type de données. Si vous pouvez obtenir ces données, vous pouvez ensuite prévoir deux semaines supplémentaires pour voir si un modèle simple indique qu'une solution de ML est réalisable. Si un modèle simple échoue, vous pouvez désigner deux semaines supplémentaires pour tester un réseau de neurones. À la fin de chaque période, vous disposerez de plus d'informations pour déterminer s'il est utile de continuer à appliquer des ressources au problème.
Réduisez les exigences du projet. Si une solution de ML semble prometteuse, mais qu'elle n'est pas une fonctionnalité essentielle pour votre produit ou service, limitez-vous à ses exigences. Par exemple, lors de la planification des travaux du prochain trimestre, vous pouvez prévoir d'essayer une solution très simple. Ensuite, au cours des trimestres suivants, vous pourrez prévoir d'améliorer la solution de manière itérative. De nombreuses équipes sont parvenues à obtenir des solutions de ML efficaces grâce à la mise en œuvre d'une solution de ML en apportant des améliorations progressives sur une période plus longue.
Projet interne ou Noogler Diriger et guider un stagiaire ou un Noogleur qui tente d'adopter une solution de ML peut être un bon moyen d'explorer un nouvel espace aux résultats inconnus. Une fois le projet terminé, vous aurez une meilleure idée de l'effort que nécessitera une solution de ML et des approches potentiellement prometteuses à mettre en œuvre, ou si les ressources doivent être placées ailleurs.
Quelle que soit la stratégie choisie, il est judicieux d'échouer rapidement. La méthode de tentative a les coûts les plus bas, mais potentiellement le rendement le plus élevé, en premier. Si l'approche fonctionne, vous avez trouvé une bonne solution. Si ce n'est pas le cas, vous n'avez pas perdu beaucoup de temps et de ressources.
À mesure que les équipes acquièrent de l'expérience et se familiarisent avec l'exécution de tests, elles sont en mesure d'estimer plus précisément l'effort que pourrait nécessiter un test, ce qui rend la planification plus prévisible. Cependant, les résultats d'un test seront presque toujours inconnus. Par conséquent, le nombre de tests nécessaires pour trouver la meilleure solution ne peut pas être estimé à l'avance.
Les approches de planification dans un état d'esprit expérimental contribuent à la réussite de votre équipe. Lorsqu'une approche conduit à une impasse, au lieu d'être découragés, les membres de l'équipe comprennent que cela fait partie du processus de recherche d'une solution de ML. Plus important encore, en discutant avec les personnes concernées de l'incertitude inhérente au développement du ML, vous êtes en mesure de définir des attentes plus réalistes.
À retenir
Apprendre à planifier plusieurs approches de ML de manière probabiliste prend du temps et prend du temps. Le plan de votre projet peut nécessiter des mises à jour fréquentes. Considérez-le comme un document dynamique en constante évolution, à mesure que votre équipe expérimente plusieurs approches. En vous concentrant sur les idées clés suivantes, vous augmenterez vos chances de réussite:
- Estimer le coût et les chances de réussite de chaque approche.
- Essayez un portfolio d'approches.
- Identifier les leçons apprises et essayer d'améliorer le système une chose à la fois.
- Anticipez les défaillances.
Il arrive parfois qu'une approche précoce permette de percer. Quelqu'un peut découvrir un bug dans le pipeline de génération de données ou la division entraînement/validation. Grâce à une planification efficace et à une documentation exhaustive, vous augmentez la probabilité de trouver un modèle capable de résoudre votre problème métier plus tôt que prévu.