Automated Machine Learning: is it the end of the sexiest job of the 21st century ?

Le Harvard Business Review a défini le Data Scientist comme le poste le plus sexy du nouveau siècle.

Dans l’article on peut lire :

If “sexy” means having rare qualities that are much in demand, data scientists are already there. They are difficult and expensive to hire and, given the very competitive market for their services, difficult to retain. There simply aren’t a lot of people with their combination of scientific background and computational and analytical skills.

Cinq ans plus tard et malgré l’émergence de nombreux programmes de formation spécifiques en Data Science, l’offre n’arrive toujours pas à satisfaire la demande croissante en Data Scientist. De plus, j’entends parler de Machine Learning Automatique, des frameworks dont la promesse est d’automatiser des tâches typiquement exécutées par un Data Scientist.

Face à la pénurie de Data Scientists et à l’apparition de ce genre d’outils, je m’interroge : le Data Scientist est-il sur le point de perdre son sex appeal ? Est-ce vraiment une menace ou simplement un nouvel outil au service du Data Scientist ?

Je vous propose de répondre à ces questions à travers l’exploration de diverses solutions d’AutoML, ainsi que des mécanismes qui en permettent l’automatisation.

L’ABC pour comprendre où l’automatisation du Machine Learning trouve sa place

L’une des compétences clé d’un Data Scientist est la maîtrise des différentes techniques de Machine Learning pour répondre à des questions de prédiction comme par exemple :

• la prédiction du volume de vente d’un produit
• la classification de documents en catégories selon leur contenu

Quelle que soit la spécificité du contexte, dans le cadre d’une analyse prédictive, le Data Scientist est amené à exécuter des tâches répétitives :

• l’analyse exploratoire des données. Une analyse prédictive se base sur des données historiques que l’on utilise pour prédire un comportement futur. Par exemple, comment l’augmentation du prix du pétrole influence la vente des billets d’avion ? On va donc fouiller dans les données qui sont à notre disposition : l’idée est d’explorer l’existant pour le connaître et le maîtriser.
• le feature engineering. Cette étape consiste à nettoyer, modifier, combiner les données. Le résultat est un ensemble d’attributs, ou variables explicatives, qui sera utilisé pour prédire la variable cible.
• la sélection du modèle et le choix des paramètres. Une fois les données prêtes, un Data Scientist a à sa disposition une palette d’algorithmes de Machine Learning parmi lesquels il faut choisir le plus adapté au problème. En plus de cela, chaque modèle possède des paramètres qu’il faut chercher à optimiser.
• l’évaluation du modèle. Selon la tâche abordée (régression ou classification), il existe des métriques qui permettent d’évaluer les performances du modèle, c’est-à-dire sa capacité à prédire la variable cible.

C’est la répétitivité de ces tâches qui laisse de la place pour l’automatisation. Je l’admets, vu le temps que cela peut prendre en pratique, l’idée de pouvoir automatiser une partie de mon travail est séduisante. De plus, toute personne souhaitant se rapprocher du métier pourrait en bénéficier.

Dans ce cadre, les solutions open source à disposition sont nombreuses :

• tpot
• mlbox
• AutoML (H2O)
• auto-sklearn
• autoweka
• machineJS

J’ai essayé les deux premiers, le but étant de comprendre leur fonctionnement et de les évaluer en rajoutant le moins d’intelligence possible. Non pas par fainéantise, mais pour tester à quel point l’intervention d’un Data Scientist n’est pas nécessaire avec ce type d’approche, car un article publié par Airbnb parle franchement de changement de paradigme dans la pratique de ses Data Scientists.

J’ai envie d’essayer : Kaggle + AutoML

Quelle meilleure façon de tester un framework de Machine Learning si ce n’est en participant à un challenge Kaggle ? L’idée est de montrer à travers un exemple l’utilisation des frameworks d’Automated Machine Learning et expliquer leur fonctionnement plus en détail par la suite.

J’ai choisi un challenge de prédiction du prix de logements, que je vais aborder avec tpot et mlbox.

TPOT « your Data Science Assistant »

Tpot est une bibliothèque Python qui en est maintenant à la version 0.9 et qui est bien documentée. Comme d’autres frameworks d’AutoML cités auparavant, Tpot se base sur l’implémentation des algorithmes de Machine Learning de scikit-learn.

Au vu des belles promesses de l’AutoML et de Tpot dans ce cas, je me disais que tout ce que j’avais à faire était de lui fournir les données en entrée et qu’il allait me faire gagner la compétition, mais cela s’est révélé être trop beau pour être vrai. En lançant l’exécution, j’ai eu une erreur tout de suite. En plus, n’ayant pas pris connaissance des données, je ne comprenais pas à quoi correspondait le message d’erreur qui sortait. C’est dommage, j’y avais cru !

En effet, en prenant un peu de recul et en regardant le tutoriel proposé (le challenge Kaggle Titanic, pour changer), je me suis rendue compte que le nettoyage et la préparation de données ne font pas partie des tâches accomplies par Tpot.

Les choix plus importants à faire en amont de Tpot concernent le traitement des valeurs manquantes et la transformation de données catégorielles en numériques. Dans les deux cas, il faut garder en tête que Tpot va essayer plusieurs algorithmes de Machine Learning pour trouver le pipeline optimal. Selon l’algorithme, il y a des stratégies qui sont plus ou moins adaptées. Par exemple, prenons la variable LotShape (General shape of property) telle qu’elle est dans le dataset. C’est une variable catégorielle qui présente 4 valeurs différentes, comme montré dans la table suivante :

Les algorithmes que Tpot va tester sont divers et variés : de la simple régression aux méthodes basées sur les arbres de décision. Il y a ici deux problèmes :

1. La régression linéaire telle qu’elle est implémentée dans scikit-learn n’accepte que des variables explicatives numériques en entrée.
2. Les deux types d’algorithmes n’interprètent pas de la même façon les variables catégorielles.

La première étape consiste donc à transformer les valeurs originelles de la variable en valeurs numériques, en se disant qu’à chaque catégorie correspond un chiffre :

Maintenant, une régression linéaire va interpréter la valeur numérique de façon erronée, car elle va être considérée comme si la relation 1 < 2 était valable. Or ce n’est pas le cas, car il n’a pas de sens de dire Regular < Slightly irregular. La technique à utiliser consiste alors à générer des nouvelles variables binaires, une pour chaque catégorie (one hot encoding). On obtient :

L’inconvénient de cette technique est qu’elle n’est pas scalable : le nombre de variables augmente rapidement. Dans cet exemple, la variable est transformée en 4 colonnes, et dans un dataset comme celui-ci où il y en a déjà plein d’autres, un tel encodage va sûrement dégrader les performances du modèle.

Un discours similaire s’applique au traitement des valeurs manquantes : non seulement Scikit-learn n’accepte pas de valeurs manquantes dans les variables (les null), mais de plus, les techniques existantes pour le remplacement de valeurs manquantes peuvent être plus au moins adaptées selon l’algorithme de Machine Learning choisi par la suite.

Pour résumer, avant de pouvoir lancer Tpot, il faut préparer les données afin qu’elles soient propres, tout comme pour une tâche de Machine Learning non automatisée. En revanche, l’avantage de Tpot, et d’autre frameworks équivalents, est représenté par l’étape qui suit la préparation de données. En effet, Tpot et l’Automated Machine Learning, permet d’étendre le concept de grid search à la sélection des variables explicatives et au choix du modèle.

Dans le notebook Jupyter que j’ai créé pour l’exploration de Tpot, vous pouvez constater que le pipeline de traitement de données, du début à la fin de l’analyse, inclut les étapes suivantes :

• remplacement des valeurs manquantes à l’aide de la documentation sur les données fournie par Kaggle
• transformation de variables non-numériques (label binariser et one hot encoding)
• lancement de Tpot
• résultats de l’entraînement

Le secret dévoilé et les résultats fournis

La question la plus intéressante maintenant est de comprendre comment l’automatisation est rendue possible. En bref, Tpot implémente un algorithme d’optimisation et utilise les algorithmes de Machine Learning de scikit-learn.

Déjà, de cette image prise de l’article des auteurs de Tpot, on voit à quel niveau intervient l’automatisation. Comme je l’avais constaté en travaillant sur le challenge de prédiction des prix, il y a une partie d’exploration, nettoyage et préparation de données qui est exclue de l’automatisation. Cette phase est très importante car il faut mettre les données dans le bon format avant de pouvoir les utiliser dans Tpot. Le bon format étant une matrice numérique sans valeurs nulles.

Une fois les données prêtes, on peut instancier l’estimator qui peut être un classifier ou un regressor, selon l’objectif de l’analyse. L’objet ainsi créé a une méthode fit qui exécute l’entraînement des modèles. Cela se fait littéralement en 3 lignes de code et c’est très similaire à la syntaxe de Scikit-learn.

# random split
X_train, X_test, y_train, y_test = train_test_split(train_array, train_df['class'], train_size=0.95, test_size=0.05)

# regressor instanciation
tpot = TPOTRegressor(generations=100, population_size=10, verbosity=2, scoring=log_rmse, n_jobs=-1, random_state=26)

# fit regresson on train set
tpot.fit(X_train, y_train)

Si quant au code ce n’est pas grand chose, du point de vue du temps c’est une toute autre histoire ! Voyons pourquoi.

À la base de Tpot, il y a un algorithme génétique. Un algorithme génétique est une technique d’optimisation qui sélectionne les inputs donnant les meilleurs résultats en output. Dans les paramètres de l’estimateur, on reconnaît le nombre d’itérations (generations), le nombre de pipelines à utiliser (population_size), le nombre de pipelines générés (offspring_size, par défaut égal à la population_size), des termes aléatoires (mutation_rate, crossover_rate) et le critère de scoring. Plus l’espace des possibilité est grand, meilleurs sont les résultats, et comme attendu, le plus de temps il faut ! Tpot au total va évaluer l’équivalent de population_size + generations x offspring_size pipelines. Dans mon exercice j’ai dû reduire largement tous ces paramètres pour que l’algorithme converge.

Une fois l’entraînement terminé, on peut récupérer le meilleur pipeline et un fichier Python avec le code correspondant.

MLBOX : your more developed Data Science Assistant

Le deuxième framework que j’ai essayé est Mlbox : une autre bibliothèque Python qui pour l’instant n’est disponible que pour les systèmes d’exploitation Linux. Ceci a été un inconvénient au début pour pouvoir commencer l’utilisation, j’ai dû créer un conteneur docker à partir d’une image existante avec mlbox installé. Le notebook est disponible sur mon Github, ainsi que le Dockerfile.

La promesse de Mlbox est d’inclure aussi toute la partie de preprocessing qui n’est pas inclue dans tpot. En effet, ils nous proposent :

• le nettoyage de données à la lecture (l’enlèvement de doublons, conversion de données au bon type, gestion de dates, enlèvement des colonnes pas nommées)
• la détection et suppression de variables susceptibles de dériver (drift variables)
• différentes possibilités d’encodage de valeurs manquantes
• différentes possibilités d’encodage de variables catégorielles
• différentes possibilités de sélection de variables

Les différences les plus importantes avec Tpot sont : l’exhaustivité de la phase de preprocessing, une technique d’encodage des variables catégorielles telle que l’entity embedding et la technique d’optimisation.

L’entity embedding est une technique qui utilise un réseau de neurones pour rapprocher les variables catégorielles par rapport au sens des catégories mêmes, d’une façon similaire à word2vec. Si word2vec permet d’identifier des relations de type King – Man ~ Queen – Woman ou Paris – France ~ Rome – Italy dans un corpus de texte, l’entity embedding permet, par exemple, de bien positionner les villes allemandes avec un sens géographique correct à partir d’une variable qui contient les noms des villes, comme montré dans l’image suivante. Par rapport au one-hot-encoder vu auparavant, c’est scalable et permet aussi la réduction de dimension.

Pour ce qui concerne l’optimisation, Mlbox utilise un package Python, hyperopt, qui implémente des techniques d’optimisation pensées pour l’optimisation de hyperparamètres des modèles. Dans ce cas, c’est la tree parzen optimisation qui est utilisée par Mlbox.

Prenons un peu de recul pour comprendre ce que cela engendre. L’optimisation des hyper-paramètres revient à optimiser une fonction de coût sur un espace de paramètres de configuration. Sous l’hypothèse que cet espace ait une structure à arbre, les paramètres feuilles sont définis seulement après les paramètres nœuds. En effet, il faut définir d’abord un modèle pour pouvoir optimiser ses paramètres spécifiques. Une catégorie d’algorithmes apte à résoudre ce genre de problème est la Sequential Model-Based global Optimization (SMBO) qui utilise des distributions de probabilité a priori et de fonctions objectif simplifiées pour optimiser itérativement la vraie fonction objectif. Tree parzen optimisation est un type spécifique de SMBO à complexité linéaire par rapport au nombre de paramètres et à l’historique de paramètres essayés. C’est beaucoup moins intuitif qu’un algorithme génétique, mais cette technique permet d’avoir des performances très compétitives et, de facto l’entraînement de modèle n’a pas pris longtemps : quelques dizaines de minutes seulement (contre les quelques heures de Tpot).

Bien que l’optimisation se soit terminée rapidement, il est difficile de récupérer les détails du pipeline optimal dans les fichiers générés.

TPOT vs MLBOX

Pour résumer, si je compare les deux systèmes :

• en terme de vitesse de computation Mlbox dépasse largement Tpot
• en terme de documentation fournie Tpot est plus avancé, c’est plus facile de retrouver les informations cherchées
• en terme d’interprétabilité, Tpot est préférable grâce à la génération du code en sortie
• en terme de complétude Mlbox est gagnant car il inclut la partie de preprocessing
• en terme de classement dans la compétition Kaggle, Tpot arrive à 2126/2146 avec un score de 2.46 alors que Mlbox avec un score de 0.26 se classifie 1972/2146 (les résultats datent d’octobre 2017)

Ceux-ci sont les résultats en essayant de faire le moindre effort possible de ma part, pour tester à quel point un tel système demande les connaissances d’un Data Scientist pour être utilisé. Un exercice dans le même sens a été fait avec Mlbox sur le même challenge Kaggle, et les résultats se ressemblent.

Au chômage ? Pas encore !

Enfin, l’aspect principal que je remarque est qu’on ne peut pas faire du Machine Learning sans un Data Scientist, ou au moins quelqu’un avec la connaissance de la donnée et des différents algorithmes. Il est vrai qu’avec relativement peu d’efforts supplémentaires, on arrive quand même à des résultats plus au moins acceptables, cependant la compréhension des données et du processus restent indispensables. En fait, la première fois que j’ai entendu parler d’AutoML, le message que j’ai perçu était presque une menace. Maintenant que j’ai creusé et que j’ai compris ce qu’il y a derrière, je vois l’AutoML comme un instrument qui peut aider un Data Scientist à tester plusieurs solutions plus rapidement. Néanmoins, il reste des points d’interrogation sur les aspects suivants :

• on perd en interprétabilité des résultats
• comment s’y prendre pour la mise en production, ou, autrement dit, comment s’assurer de la reproductibilité des résultats.

De la page d’introduction au framework d’AutoML de H2O, je me permets de souligner ce qui pour moi résume parfaitement l’AutoML :

In recent years, the demand for machine learning experts has outpaced the supply, despite the surge of people entering the field. To address this gap, there have been big strides in the development of user-friendly machine learning software that can be used by non-experts. The first steps toward simplifying machine learning involved developing simple, unified interfaces to a variety of machine learning algorithms (e.g. H2O).

Although H2O has made it easy for non-experts to experiment with machine learning, there is still a fair bit of knowledge and background in data science that is required to produce high-performing machine learning models. Deep Neural Networks in particular are notoriously difficult for a non-expert to tune properly. In order for machine learning software to truly be accessible to non-experts, we have designed an easy-to-use interface which automates the process of training a large selection of candidate models. H2O’s AutoML can also be a helpful tool for the advanced user, by providing a simple wrapper function that performs a large number of modeling-related tasks that would typically require many lines of code, and by freeing up their time to focus on other aspects of the data science pipeline tasks such as data-preprocessing, feature engineering and model deployment.

Un aspect extrêmement intéressant de l’AutoML est sûrement celui suggéré par Google qui propose de l’utiliser pour l’optimisation de l’architecture d’un réseau de neurones. De toute façon, l’interpretabilité n’est pas ce qui caractérise ce type d’algorithmes ! Les deux articles qui en parlent sont :

• Using Machine Learning to explore neural network architecture
• AutoML for large scale image classification and object detection
• Cloud AutoML: Making AI accessible to every business

Enfin, il ne faut pas oublier que l’Automated Machine Learning intervient dans le cadre du Machine Learning supervisé, c’est-à-dire l’apprentissage par rapport au passé. Le Machine Learning non-supervisé, par exemple, constitue une autre partie des compétences d’un Data Scientist qui n’est pas comprise dans les frameworks automatisés existants.

Sujet à suivre mais Long live the Data Scientist !