Le domaine de l’analyse des données est devenu un eldorado et une opportunité de développement pour beaucoup d’entreprises.
En particulier, la data a apporté des solutions techniques à des problèmes jusqu’ici insolubles sans une forte intervention manuelle (et donc souvent coûteuse). Il existe des cas d’applications dans de nombreux secteurs : financier, assurance, imagerie satellite, recherche médicale… En revanche, on parle moins des difficultés concrètes à sa mise en œuvre. Un écueil en particulier est de penser que le code écrit lors de projets machine learning est comparable au code écrit lors de développement logiciel classique (type software).
Par conséquent, il arrive d’appliquer en data des méthodes et des outils DevOps créés pour et adaptés au software. Or, c’est une erreur potentiellement dangereuse, pour des raisons que nous allons détailler dans cet article.
La force du machine learning est aussi sa grande faiblesse
Software vs machine learning : déterminisme contre adaptabilité
Un code software classique est très déterministe : on définit à la main un ensemble de règles adaptées au problème que l’on souhaite résoudre et produisant les résultats escomptés.
C’est tout l’inverse d’un algorithme de machine learning, pour lequel il est impossible d’expliciter des règles claires permettant de comprendre et/ou de prévoir un résultat. Le machine learning est souvent perçu comme une boîte noire, pour cette raison notamment.
En bref, dans du code software, la suite d’opérations permettant d’aller du point A au point B est traçable et compréhensible. Tandis qu’en machine learning, ce chemin ressemble plus à un sac de nœuds qu’il serait vain de vouloir analyser.
Le machine learning : du code très difficile à tester, débuguer et maintenir
C’est évidemment cela qui fait la force du machine learning : cette complexité permet d’agréger et d’analyser à la fois une multitude de signaux faibles pour leur donner de la cohérence et un sens.
C’est le cas en computer vision par exemple, où la valeur de chaque pixel est prise en compte pour déterminer si une image représente un chat ou un chien, sans pour autant qu’un seul de ces pixels n’ait été déterminant dans ce choix.
Cependant, si vous ne pouvez ni anticiper ni comprendre en détail les résultats, alors comment vous assurer qu’un code fonctionne comme prévu ?
Les outils et méthodes développés jusqu’alors dans le monde du software reposent beaucoup sur l’aspect déterministe du code pour s’assurer de son bon fonctionnement. C’est le cas des tests unitaires, par exemple, qui vérifient que le résultat renvoyé par un bout de code correspond bien à ce qu’on attend. Ce genre de test est très compliqué, voire impossible à mettre en place en machine learning…
Cette faiblesse est un obstacle majeur pour l’adoption plus vaste du machine learning.
La majorité du code dans un projet ML est du « glue code »
Dans ce papier de recherche publié en 2015 et s’intéressant aux difficultés rencontrées à différents stades du cycle de vie de projets data, les auteurs révèle que 95 % du code écrit est du « glue code ».
Le « glue code » est du code dont le seul objectif est de relier entre eux les éléments d’un programme. C’est en quelque sorte de la « plomberie » qui n’a pas de valeur intrinsèque, mais qui est malgré tout nécessaire.
Il s’avère que ce type de code est particulièrement présent en data. En réalité, cette proportion 5 % vs 95 % représente bien l’écart de travail qu’il existe entre un prototype et une version finale. Donc, lorsque votre équipe data vous annonce qu’elle a un modèle ML convaincant, 5 % du travail pour développer et déployer une application stable intégrant ce modèle a été effectué.
Ce code apparaît avec la nécessité de gérer tous les cas limites, de mettre en place une politique de logging et de monitoring, de rajouter une couche software pour l’intégration… Autant de tâches qui sont mises de côté au stade prototype.
Une dette technique encore mal gérée
Plus en amont, une autre raison à l’apparition de « glue code » est la forte tendance à utiliser des librairies ou outils externes en machine learning. Or, ces dépendances externes ont chacune leur standard et leur fonctionnement propre. Donc on se retrouve à coder dix fois plus de lignes pour les connecter ensemble que pour les utiliser à proprement parler.
Ce phénomène, associé aux problématiques propres au machine learning, génère une importante dette technique.
À terme, l’accumulation de cette dette technique est un frein majeur. En effet, le machine learning est exploratoire par nature : on essaye de nombreuses alternatives différentes. Or, une dette technique apporte de l’inertie au fur et à mesure qu’un projet avance, si bien qu’il devient trop coûteux d’explorer de nouvelles pistes. On devient petit à petit prisonnier des choix que l’on a faits précédemment.
La bonne nouvelle est qu’il existe des solutions pour prévenir ces problèmes. En particulier, on voit se développer ces dernières années de nouvelles méthodologies de travail, telles que le DataOps ou le MLOps, qui sont plus adaptées au machine learning et aux projets data plus généralement.
