H2O en pratique : un protocole combinant AutoML avec des approches de modélisation traditionnelles

H20 est livré avec de nombreuses fonctionnalités. La deuxième partie de la série H2O en pratique propose un protocole pour combiner la modélisation AutoML avec une approche traditionnelle de modélisation et d’optimisation. L’objectif est la définition du workflow que nous pourrions appliquer à de nouveaux cas d’utilisation pour gagner en performance et en délai de livraison.

En partenariat avec Laboratoire EDF et ENEDISnotre objectif commun est d’estimer la difficulté à embarquer avec la plateforme H2O, de comprendre son fonctionnement, et de trouver ses forces et ses faiblesses dans le cadre d’un projet réel.

Dans le premier article, une expérience réelle avec H2O, le défi était de construire un modèle à l’aide d’AutoML, et de le comparer à un modèle de référence, construit avec une approche traditionnelle. Pour le deuxième défi, nous avons reçu un jeu de données prêt à l’emploi à partir d’un problème métier différent (toujours lié à la maintenance préventive) et cinq jours pour produire le meilleur modèle avec H2O. Pour s’y préparer, nous avons élaboré un protocole opérationnel, que nous vous présentons dans cet article. Cela nous a aidés à former un modèle de base comparable à celui existant en seulement deux jours.

Ce protocole fournit des conseils sur la façon de combiner la modélisation AutoML avec des algorithmes de modèle individuels pour des performances accrues. La durée de la formation est analysée à travers deux exemples pour obtenir une image globale de ce à quoi s’attendre.

Environnement, ensembles de données et descriptions de projet

Projet 1, la détection de tronçons de câbles souterrains basse tension à remplacer : train et test set avaient un peu plus d’un million de lignes et 434 colonnes chacun. Pour ce cas d’utilisation, nous utilisions Eau pétillantequi combine H2O et Spark et qui répartit la charge sur un cluster Spark.

• H2O_cluster_version : 3.30.0.3
• H2O_cluster_total_nodes : 10
• H2O_cluster_free_memory : 88,9 Go
• H2O_cluster_allowed_cores : 50
• H2O_API_Extensions : XGBoost, Algos, Amazon S3, Extensions API REST Sparkling Water, AutoML, Core V3, TargetEncoder, Core V4
• Python_version : 3.6.10 final

Projet 2, maintenance préventive, confidentiel : train et test set avaient environ 85 000 lignes chacun. 605 colonnes ont été utilisées pour la formation. Pour ce cas, nous avons utilisé un version non distribuée de H2Os’exécutant sur un seul nœud.

• H2O_cluster_version : 3.30.1.2
• H2O_cluster_total_nodes : 1
• H2O_cluster_free_memory : 21,24 Go
• H2O_cluster_allowed_cores : 144
• H2O_API_Extensions : Amazon S3, XGBoost, Algos, AutoML, Core V3, TargetEncoder, Core V4
• Python_version : 3.5.2 final

Dans les deux cas, la tâche était une classification d’un ensemble de données fortement déséquilibré (< 0,5 % de la classe 1). L'AUCPR a été utilisé comme métrique d'optimisation pendant la formation. En tant qu'évaluation finale du modèle, deux mesures commerciales ont été calculées, toutes deux représentant le nombre de pannes sur deux longueurs cumulées différentes de départs. Une validation croisée quintuple a été utilisée pour valider les modèles. Le défi dans les deux projets était de comparer le meilleur modèle de H2O avec le modèle maison de référence, déjà optimisé.

Protocole de modélisation avec H2O

Nous avons combiné les fonctionnalités d’AutoML avec des algorithmes de modélisation individuels pour tirer le meilleur parti des deux mondes. Après avoir essayé différentes approches, nous avons trouvé le protocole proposé le plus concis et le plus simple.

1. Selon le temps disponible :

• Si vous disposez de suffisamment de temps, exécutez AutoML pour créer de nombreux modèles (plus de 30) sans limite de temps, afin d’obtenir l’entraînement le plus long et le plus précis (H2OAutoML: max_models).
• Si vous manquez de temps, ou si vous ne cherchez qu’un résultat approximatif pour estimer la performance de base, définissez le temps maximal d’entraînement (H2OAutoML: max_runtime_secs).

2. Calculez une métrique commerciale (et/ou les métriques supplémentaires) pour chaque modèle et collectez-les dans un classement personnalisé.

3. Fusionnez le classement AutoML et un classement personnalisé et inspectez :

• Quelle famille de modèles atteint le score le plus élevé ?
• Comment les mesures commerciales et statistiques sont-elles corrélées ?
• Y a-t-il des modèles qui fonctionnent si mal que nous ne voulons pas passer plus de temps à les optimiser ?

En raison de la confidentialité du projet, nous ne décrirons les résultats que pour illustrer l’exemple. La XGBoost family s’est bien mieux comporté que tout autre algorithme. L’apprentissage en profondeur a été le pire, ce qui n’est pas surprenant sur les données tabulaires. Par exemple, le meilleur modèle XGBoost a trouvé 3 à 4 fois plus d’incidents que le meilleur modèle d’apprentissage en profondeur, selon la métrique commerciale. La deuxième famille la plus performante était GBM, qui dans le meilleur des cas a trouvé environ 90 % des incidents de XGBoost. Dans les deux projets, les modèles avec l’AUCPR le plus élevé avaient les métriques commerciales les plus élevées, mais généralement, la corrélation n’était pas grande.

4. Exécutez une recherche par grille AutoML sur les familles d’algorithmes les plus efficaces (H2OAutoML: include_algos). Testez de nombreux modèles. Sélectionnez les modèles que vous souhaitez optimiser (modèles d’intérêt) et enregistrez-les.

5. Imprimez les paramètres réels des modèles d’intérêt (h2o.get_model(model_name).actual_params).

6. Utilisez ces paramètres comme base dans la définition manuelle du modèle. Définir les hyperparamètres pour la recherche de grille (H2OGridSearch). Si vous souhaitez en tester plusieurs ou si vous manquez de temps, utilisez la stratégie de recherche par grille aléatoire. Sinon, construire les modèles à partir de toutes les combinaisons des hyperparamètres (stratégie cartésienne).

7. Calculez des métriques supplémentaires sur les modèles de recherche de grille et inspectez éventuellement l’importance de la variable. Les modèles avec des scores similaires peuvent être basés sur un ensemble différent de variables, qui peuvent être plus importantes pour le contexte commercial que le score seul.

8. Sélectionnez le(s) meilleur(s) modèle(s) pour chaque famille et enregistrez-le.

9. Éventuellement, créez des ensembles empilés et recalculez les métriques supplémentaires.

Combien de temps cela prend-il?

Nous utilisions deux ensembles de données de tailles différentes (1 million de lignes x 343 colonnes et 85 000 lignes x 605 colonnes). Comme ils ont été traités dans deux environnements différents, nous ne pouvons pas comparer directement les temps de traitement. Avec les estimations approximatives de la durée de chaque phase, nous aimerions vous donner une idée de ce à quoi vous pouvez vous attendre.

Flux de travail dans le projet 1 :

• construire 40 modèles AutoML → ~ 8,5 h
• extraire les paramètres du meilleur modèle de chaque famille et définir les hyperparamètres pour l’optimisation (dans ce cas, XGB et GBM)
  • recherche aléatoire :
    • 56 modèles XGB → ~ 8 h (+ métriques commerciales → ~ 4,5 h)
    • 6 modèles GBM → ~ 1 h (+ métriques métiers → ~ 0,5 h)
• enregistrer les meilleurs modèles

Considérant que l’ensemble de données n’était pas très volumineux (< 200 Mo), nous avons été surpris qu'il ait fallu autant de temps à AutoML pour terminer 40 modèles. Peut-être qu'ils n'ont pas bien convergé, ou nous devrions optimiser les ressources du cluster. Notre solution préférée était de commencer les longs calculs en fin de journée et d'avoir les résultats le matin.

Flux de travail dans le projet 2 :

• exécuter AutoML pendant 10 min (durée fixe ; + métriques commerciales ~ 15 minutes)
• construire 30 modèles GBM avec AutoML → ~ 0,5 h (+ métriques commerciales → ~ 1 h)
• extraire les paramètres du meilleur modèle et définir les hyperparamètres pour la recherche de grille
• recherche aléatoire : 72 modèles GBM → ~ 1 h (+ métriques métiers → ~ 2 h)
• enregistrer le meilleur modèle

Le deuxième ensemble de données était plutôt petit et nous parvenons à exécuter toutes les étapes en un jour ouvrable.

Quelle était la qualité des modèles ?

La comparaison était basée uniquement sur les valeurs des mesures commerciales. Nous n’avons effectué aucun test statistique approprié sur les résultats, bien que nous ayons pris en compte la variance de nos résultats. Ainsi, ce n’est pas à prendre comme une référence mais comme un constat. Dans les deux cas, nous avons réussi à produire des modèles avec à peu près les mêmes performances que les références. Habituellement, nous avions plusieurs candidats avec des scores similaires. Plus important encore, nous y sommes parvenus en seulement une fraction du temps nécessaire pour le modèle de référence.

Conclusion

Nous avons montré sur deux problèmes concrets comment raccourcir le temps de construction d’un bon modèle de référence en tirant parti de l’apprentissage automatique avec H2O. Après avoir investi du temps pour comprendre les avantages et les limites de la plateforme, nous avons pu construire un modèle comparable au modèle de référence en quelques jours seulement. Il s’agit d’une accélération significative par rapport à l’approche traditionnelle. De plus, une API conviviale raccourcit le temps de codage et simplifie la maintenance du code.

Remerciements

Les collaborateurs qui ont contribué à ce travail sont :