Ernst & Young - 2016#

Le hackathon était proposé et organisé par Ernst & Young (sponsor), ENSAE, Genius, Croix-Rouge, Cresus.

Les données seront fournies au début de l’événement et doivent être détruites à la fin de l’événement. Elles sont accompagnées de documents qui permettent d’interpréter certains variables au regard des activités de chaque association.

Site : hackathon-geniusensae.fr.

Challenge créatif - La Croix-Rouge #

La Croix-Rouge souhaite comprendre un peu mieux la population de bénévoles qu’elle emploie.

Qui est un bénévole fidèle ?
Qui est un futur responsable bénévole ?
Comment réagit un bénévole face à des événements de société imprévus (tels que des attentats) ?

L’objectif est de déterminer ce qui motive les bénévoles selon trois axes principaux afin de proposer le meilleur parcours :

L’activité : dans quelle activité un bénévole s’épanouira-t-il le plus ?
L’implication : quel pourcentage de son temps doit-il y consacrer ?
Le niveau de responsabilité : quel niveau de responsabilité lui conviendrait le mieux ?

Les données incluent une vue globale sur 40 ans et une vue détaillée pour un secteur de La Croix-Rouge sur les deux dernières années.

Je veux être bénévole, que me recommandez-vous ?

Une des bases de données fournies par la Croix-Rouge était similaire au jeu de données mis à disposition sur data.gouv.fr : Liste des bénévoles actifs de la Croix-Rouge française.

Challenge prédictif - Crésus #

Crésus accompagne les personnes en situation de surendettement. Les personnes en situation financière difficile commencent par envoyer un dossier qui précisent les éléments principaux de leur situation. C’est ce que contiennent les bases dossier, budget. Un ou plusieurs rendez-vous téléphonique suit pour renseigné les tables agenda et crédit. Deux colonnes sont utilisées pour qualifier la nature de la situation (diagnostic) et l’orientation donnée au dossier. Ce sont les deux informations qu’il faut prédire. Pour ce faire, les tables sont été divisés en apprentissage et test selon deux ensembles disjoints dans le temps de dossiers. La base de dossier ne contient pas d’historique. C’est une vue de la situation au moment où le dossier est orienté.

Mode d’emploi

Les différents fichiers sont un dump des différentes tables du système d’information de l’association. Elles sont liées par des identifiants. L’identifiant dossier est celui qui permet de lier les données de la table principale dossier aux autres.

La table dossier est scindée en deux parties :

X : ensemble des colonnes saisies à la réception d’un dossier
Y : ensemble des informations renseignées manuellement après l’étude d’un dossier.

La partie Y contient deux colonnes :

nature : un diagnostique, une raison qui explique le surendettement
orientation : la suite donnée au dossier par l’association Crésus

Il faut prédire ces deux colonnes. Il ne faut pas utiliser la colonne etat qui est renseignée manuellement après nature et orientation.

Compétition #

La compétition est accessible sur codalab : Hackathon ENSAE - EY - Challenge Crésus - 1.5. C’est un problème de classification multi-classes.

données du challenge

Les réponses doivent être données dans le même ordre que les lignes de la table tbl_dossier.test.X.txt dans un fichier texte sans en-tête answer.txt. Soumettre une solution consiste à envoyer à fichier answer.zip qui contient un fichier answer.txt au format suivant :

0  endettement  0.9144635693307518  0.7446166038448464
0  endettement  0.9058230082126213  0.5672372371792938
0  credits renouvelables recurrents  0.963522847810654  0.4201954811133858
0  difficultes de gestion  0.6700924948192609  0.5024330719247078
0  microcredit social  0.33637962518435127  0.5765688167949408
0  impayes  0.2746943724528652  0.16503183971336655
0  microcredit personnel  0.695436159178639  0.7331150383369753

Avec quatre colonnes :

prédiction pour l’orientation
prédiction la nature
score orientation pour la prédiction de l’orientation
score nature pour la prédiction de la nature

Un exemple de soumission est disponible (réponse aléatoire)

Les métriques produites pour chaque colonne :

ERR - taux d’erreur : c’est la proportion de mauvaises prédictions, la classe prédite n’est pas la classe attendue.
AUC - aire sous la courbe ROC : ce chiffre correspond à la probabilité pour le score d’une bonne prédiction d’être supérieur au score d’une mauvaise prédiction - Courbe ROC.

Une bonne AUC indique que le score de la prédiction est fiable. Autrement dit, même si le taux d’erreur est élevé, cela signifie que celui qui utilise le modèle de prédiction peut plus facilement croire la prédiction quand celle-ci est élevée. Cette métrique a été choisie pour permettre à l’utilisateur d’automatiser une partie du traitement avec fiabilité et de continuer à gérer les autres dossiers manuellement lorsque la prédiction n’est pas assez fiable. La fonction de calcul AUC est implémentée : AUC_multi et le fichier d’évaluation fonctionne en Python 2 ou 3 : evaluate.py.

Résultats du challenge prédiction #

Team Name	orientation_ERR	orientation_AUC	nature_ERR	nature_AUC
3	0.7503	0.7125	0.8707	0.4744
7	0.5272	0.6403	0.6936	0.4902
7	0.5245	0.6750	0.9270	0.5339
5	0.5202	0.6349	0.7084	0.5330
10	0.5146	0.6109	0.7138	0.5459
11	0.4797	0.6652	0.7282	0.5000
1	0.4058	0.6499	0.6455	0.5544

La compétation est terminée. Les prédictions attendues sont disponibles zippées : reference.zip.

Autres données #

Cheat Sheets #

Rappel de ce que vous savez déjà mais avez peut-être oublié

Après la compétition #

Take Away #

événements

La qualité des données a un gros impact sur la performance et on découvre les données trop souvent sous la forme de tableau de bord alors que ceux-ci sont la conséquence d’une succession d’événements.

Si un système d’information ne conserve que l’état d’une situation, d’une association, il ne représente que le présent, perd toute notion d’historique et met côte à côte des informations qui n’ont pas été renseignées à la même date.

C’est pourquoi il est beaucoup plus intéressant de construire un système qui enregistre des événements, des mises à jour. Il est facile de reconstruire l’état du système à partir de cette séquence. Cela permet pour un datascientist de comprendre l’évolution des données, de déterminer quelles données étaient disponibles à chaque instant surtout si elles ont servi de base à une décision. Ce procédé notamment de repérer qu’une variable est renseignée après une autre et qu’elle en dépend.

id_dossier

Certains participants ont noté que la variable id_dossier avait un impact positif sur la qualité de la prédiction. Faut-il s’en passer sachant qu’elle n’a pas de sens particulier ? Dans l’idéal, oui ! Mais avant de prendre une décision hâtive, il faut s’interroger sur le fait que cette variable ait un impact. Tout d’abord, le numéro de dossier est croissant. Il est donc plus ou moins corrélé avec la date à laquelle le dossier est ouvert. On peut remplacer id_dossier par la date et mesurer la différence de prédiction. Toutefois, on peut se demander pourquoi la date aurait un impact sur la prédiction. Cela signifie probablement que la distribution de la variable orientation évolue avec le temps et que la base de test n’est probablement pas tout à fait homogène avec la base d’apprentissage puisque le découpage a eu lieu par rapport au temps. On peut utiliser une astuce pour vérifier : Les bases de train et test sont-elles homogènes ?.

données aberrantes

Il n’existe pas toujours de mode d’emploi. Lorsqu’on voit une valeur 2010-2110 avec une colonne qui porte la mention début-fin, cela signifie sans doute que le début est bien 2010 mais que la fin n’est pas déterminée. Mais comme le système d’information la demande, la personne qui a renseigné l’information en donne une plus ou moins aberrante. Plus les gens se servent d’une base de données, meilleure elle est.