Zelros, l'accès simplifié à des modèles de Machine Learning

Zelros est une start-up fondée en 2015, spécialisée dans la création  d’agents conversationnels (aussi connus sous le nom de chatbots)  destinés à des clients grands comptes dans  l’assurance et les énergies.

L’idée est née d’un constat issu de l’expérience des co-fondateurs : trop peu de modèles de Machine Learning, même une fois mis en  production, sont au final utilisés par les  opérateurs métiers. Souvent,  l’accès à ces modèles est trop  complexe ; il faut accéder à un intranet  et naviguer à travers plusieurs pages pour trouver la réponse à sa question.

En mettant à disposition un assistant virtuel à qui l’on peut directement poser sa question, Zelros répond à ces problématiques. De plus, il est plutôt simple d’intégrer de tels agents  directement dans les outils de discussion des entreprises comme Slack, Skype, etc… Zelros offre aussi une prestation de Data Science intégrée dans l’agent conversationnel pour  des visualisations/études sur les bases de données et les systèmes de l’entreprise.

Christophe Bourguignat est co-fondateur et data scientist chez Zelros. Autodidacte, il a appris le métier de data scientist en partie par des compétitions Kaggle, c’est  pourquoi nous avons, lors de cette réunion, confronté les études de données que l’on peut mener dans une compétition Kaggle et ce qui ce fait dans le « vrai monde » de  l’entreprise.

« Machine Learning isn’t Kaggle competitions »

Bien que les résultats obtenus aux compétitions Kaggle soient aujourd’hui considérées comme l’une des métriques permettant de juger des compétences d’un data scientist, il est fondamental de remettre cet exercice dans son contexte et de bien comprendre qu’il ne correspond en rien à la réalité du monde de l’entreprise.

L’interprétation des résultats

En contexte réel, lorsque l’on construit un modèle prédictif, il est important de prendre en compte son interprétabilité. Souvent les modèles les plus puissants sont les plus opaques, or cette opacité est une cause de rejet majeur auprès des utilisateurs finaux qui n’acceptent pas ce côté black box, même si les résultats obtenus s’avèrent pertinents.

Chez l’un des clients de Zelros appartenant au monde de l’assurance, il existe de nombreux modèles ; certains décrivent les appétences produit, d’autres calculent le churn rate, etc... Or lors de l’implémentation de ces modèles, les différents services impactés se sont montrés particulièrement difficiles à convaincre. Il était donc nécessaire de donner des arguments solides permettant de prouver la validité de ces modèles.

Progressivement, la règlementation en vigueur dans les États membres de l’Union européenne s’oriente vers davantage de transparence sur le sujet des données personnelles et des algorithmes :

• En septembre 2014, l’étude annuelle du Conseil d’État sur le numérique et les droits fondamentaux proposait à l’Union européenne d’imposer aux auteurs de décisions s’appuyant sur la mise en œuvre d’algorithmes une obligation de transparence sur les données personnelles utilisées par l’algorithme et le raisonnement général suivi par celui-ci.
• En mars 2017, le décret n°2017-330 précisait les modalités de la demande et de la communication des règles définissant un traitement algorithmique lorsque celui-ci a participé au fondement d’une décision individuelle.
• Enfin, à compter de mai 2018, les dispositions du Règlement Général sur la Protection des Données seront applicables dans l’ensemble des États membres de l’Union européenne, avec des sanctions financières pouvant atteindre 4% du chiffre d’affaires mondial annuel d’une entreprise.

Ces dispositifs visent notamment à contrer les GAFA en Europe. Toutefois, la transparence dont il est question ici correspond-elle à l’ouverture des données utilisées ou bien à celle des outils employées ? De l’avis des GAFA, il s’agirait plutôt de celle des outils, or plus les algorithmes deviennent complexes, plus il devient difficile, voire impossible de les expliquer aux citoyens.

Dans la pratique, lorsqu’on utilise des modèles difficiles à interpréter comme les forêts aléatoires, il peut être utile d’analyser a posteriori la phase d’entraînement afin de repérer les cas particuliers de prédictions qui seraient en désaccord avec la réalité.

Référence bibliographique :
Understanding Random Forests : From Theory to Practice - Gilles Louppe

Sur Airbnb, il arrivait parfois que l’algorithme affiche des tarifs de nuitées sur le week-end moins élevés qu’en semaine, ce qui n’avait pas de sens. Par ailleurs, cela aurait pu étonner les utilisateurs et entraîner une perte de confiance en la politique tarifaire pratiquée. Par conséquent, l’algorithme de calcul a été revu afin que les tarifs des nuitées sur le week-end soient toujours supérieurs aux tarifs de semaine.

L’une des méthodes afin d’analyser une forêt aléatoire consiste à comparer deux prédictions équivalentes, puis à examiner les feature contributions.

« Prédire, c’est se tromper. »

Une autre bonne pratique consiste à estimer la marge d’erreur, en traçant par exemple la répartition des prédictions réalisées par les arbres.

Dans l’article Why Should I Trust You ? Explaining the Predictions of Any Classifier, trois chercheurs de l’Université de Washington expose une méthode dont le but est d’expliquer les prédictions de n’importe quel modèle de classification/régression en l’approximant localement à l’aide d’un modèle qui soit interprétable. C’est ainsi qu’ils ont pu détecter un phénomène de fuite de données sur une étude effectuée à l’aide d’une SVM.

Toujours chez un client de Zelros du monde de l’assurance, un modèle utilisé pour prédire le churn rate s’est révélé biaisé. En effet, la présence de l’adresse électronique était un paramètre présentant une forte corrélation avec le taux d’attrition, or il s’est avéré que les clients devaient renseigner leur adresse électronique lors de la procédure de résiliation, ce qui faussait par conséquent les données d’apprentissage.

Finalement, dans une certaine mesure, tous les modèles sont biaisés. Il faut toujours garder à l’esprit que le Machine Learning cherche des corrélations, pas des causalités.

Référence bibliographique :
The Mythos of Model Interpretability – Zachary C. Lipton

Mise en production

Un challenge Kaggle commence bien tard si l’on considère la chaine classique du traitement des données. En production, il est très souvent nécessaire de procéder à des extractions pour obtenir les données, avec souvent à la clé des ennuis et des dissonances entre les différentes équipes. Ensuite, il faudra procéder à un travail de compréhension des données, une explication détaillée de chaque variable par le métier. Dans Kaggle, les données sont déjà disponibles et les variables expliquées proprement une à une. Enfin, une similarité entre les deux types d’études est le nettoyage des données ; cependant, les données issues de l’entreprise sont bien plus souvent peu exploitables et nécessitent un travail de préparation plus important.

Une autre différence est la problématique : dans un challenge Kaggle, elle est claire et définie dès le départ, tandis que dans un contexte de production, une phase de cadrage est nécessaire et celle-ci peut être longue selon les problématiques.

Il existe un autre problème que l’on rencontre en production mais pas dans l’univers Kaggle : les échecs rencontrés par les modèles.

Le premier type d’échec est la rencontre, pour le modèle en production depuis un certain temps, d’une nouvelle catégorie sur laquelle il n’a pas été entrainé. Toutes les données de cette nouvelle catégorie seront donc affectées à tort à une autre.

Le second type d’échec que peut rencontrer un modèle est sa dégradation au fil du temps. En effet, plus le temps depuis l’entrainement augmente, plus les performances de prédiction de notre modèle se réduisent. Il faut donc le surveiller pour pouvoir pallier à ce problème.

En savoir plus : http://www.zelros.com/

Compte rendu rédigé par les étudiants du Mastère Spécialisé® Big Data : Jean-Marc Sevin et Rémi Ferreira