Cas #data réel

Comme beaucoup, OceanData a travaillé cet été. Malgré l’Euro et les JO. Qui plus est sur un projet que je trouve très représentatif du type de projets data que je mène. Je vais donc essayer de vous le décrire. Ce qui me permettra d’ailleurs de présenter le schéma d’analyse que j’utilise depuis bientôt deux ans.

Un projet #data rentre dans la typologie des projets de prestation informatique classique ; une grande partie du déroulement est probablement similaire.

Expression du besoin

La première prise de contact était téléphonique. L’entreprise développe et commercialise un service auquel ses utilisateurs accèdent via une plateforme web ou un client local. Deux besoins dans l’immédiat : un premier lié à de la récupération automatisée d’informations non structurées (scraping), plutôt centré sur de la formation technique, et un second lié à un projet innovant relatif à l’expérience utilisateur (UX). Le second besoin implique de traiter une grosse base de données ; ce qui tombe plutôt bien. C’est celui que je détaillerai ici.

L’expression exacte du besoin tient en une phrase, que je vous donne donc tout de go: “nous aimerions être capable d’attribuer automatiquement des étiquettes (tags) aux lignes qui n’en ont pas”. Clair et net. La bonne nouvelle, c’est qu’un tiers des lignes de la base sont déjà étiquetées.

Avant projet

Le but de l’avant projet est d’avoir des éléments de réponses sur cette question : sera-t-il possible de traiter problématique en un temps correct ? A partir de là, on entre dans le dur. Je vais devoir récupérer la base de données, ou au moins un aperçu représentatif, et observer les données proprement dites : quelles sont-elles ? combien de champs ? quelle typologie ? quel formatage ? quelle cohérence ? y a-t-il des trous, des données manquantes ? etc. Me faire une idée de la difficulté du projet, puis travailler sur un chiffrage. S’ils ont de la chance, j’aurais déjà eu l’occasion de me frotter à des problèmes similaires : ce qui est le cas sur ce projet, puisque la classification automatique est un grand classique du machine learning, et les méthodes abondent. Si j’ai de la chance, il faudra débroussailler un nouveau domaine, ce qui sera probablement à la fois complexe, long et sympa — car inconnu.

ETL

Cette phase d’analyse est une double phase de découverte : découverte des données, découverte des interlocuteurs. Je commence toujours par écrire du code spécifique permettant de traduire ces données (csv, *sql) dans des formats que savent traiter mes outils de développement habituels. En ce moment, je suis assez fan de pandas et de ses DataFrames. Cette phase que les gens sérieux appellent ETL (Extract/Transform/Load) est spécifique à tout projet, et est parfois fatigante : le texte peut changer de langue après la 17098061eme ligne, le format des dates peut être aléatoire, le formatage du fichier de données peut être foireux etc. Facile de s’en rendre compte à l’oeil sur quelques centaines de lignes, mais impossible de le faire à partir de la centaine de milliers d’éléments. Évidemment, on peut ne se rendre compte d’erreurs d’import que lors du traitement, par des comportements
aberrants ou des plantages complets, ou lors de l’analyse de résultats ; on peut aussi laisser le client s’en rendre compte, mais je déconseille cette méthode.

J’ai du, une fois, monter un serveur de base de données noSQL pour pouvoir regarder les données dans leur ensemble. Un prospect m’avait fait passer 700Go de données textuelles, soit l’équivalent d’un demi million de Guerre et Paix.

Choix techniques

Une fois les données intégrées, les besoins clients défrichés, parfois même déchiffrés, je me mets en quête d’un algorithme qui permet de répondre au problème posé dans un temps acceptable.

En accord avec le client, cinq champs parmi trente sept ont été choisis pour représenter chaque ligne, sous forme de texte, de chiffres et d’indicateurs binaires. Trois champs en sortie, à prédire, avec chacun entre quelques classes et plusieurs centaines.

Sur ce projet, j’ai testé différents moteurs de classement. Trois donnent des résultats assez proches, avec des temps de calcul allant du simple au triple et des complexité linéaires ou pseudo-linéaires : gradient stochastique, classeur bayesien ou machine à vecteurs de support. La mise en forme des données passe par des analyses statistiques sur les mots, ainsi que des méthodes de seuillage sur les valeurs chiffrées.

Au final, les cinq champs initiaux choisis permettent de construire une modélisation des données avec quelques centaines de dimensions, ce qui permet de réaliser les étapes entraînement des moteurs de classification sur un simple laptop.

Résultats d’un classeur SGD sur données réelles.

Du prototype à la production

Une fois que le moteur tourne sur un subset du jeu de données total, j’attaque la phase de tests sur la base totale. Soit, sur ce projet, passer de quelques dizaines de milliers de lignes à plus de 3 millions … et parfois bien plus. Ce qui permet de se rendre compte qu’un des moteurs de classification ne sera pas adapté au cas complet — trop long ! Dommage, il donnait des résultats un peu meilleurs que les deux autres. On s’en passera pour le moment, mais le client aura toujours la possibilité de l’utiliser s’il le désire.

J’obtiens tout de même des performances de l’ordre de 70–75% de prédictions de classement correctes, malgré des hypothèses restrictives sur la modélisation des données et l’utilisation de moteurs classiques. J’estime que c’est suffisant vu la modélisation choisie, puisque ces performances sont celles que le client attend.

Avec les bonnes librairies, les parties effectives du code du prototype tient en moins de 1000 lignes, dont plus de 90% sont spécifiques au projet; le reste est factorisé. C’est un ordre de grandeur que j’apprécie car je peux le faire tenir totalement dans ma mémoire vive personnelle.

Si on ajoute les routines de debuggage, de représentation des données d’entrées et des résultats (ce que les communicants appellent #dataviz) ainsi que les routines d’export, on peut facilement doubler ce chiffre.

La suite ?

Le packaging du source est immédiat. Le déploiement peut être complexe, s’il n’y a pas de geek chez le client, ou si son data scientist n’est pas à l’aise avec les systèmes GNU/Linux. Le plus simple est de récupérer un serveur virtuel chez le client et d’assurer l’installation des routines. La communication peut se faire par exports de fichiers résultats ou base de données.

Des questions ?

Les coms servent à ça.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.