Data science, Big Data et Machine Learning sont des termes populaires ces dernières années. Toutefois, les périmètres qu’englobent chacun de ces termes se chevauchent, tout en signifiant des choses différentes. Ce qui pourrait prêter à confusion !

Dans cet article, je vais décrire le flux de travail (workflow) d’un data scientist pour construire un Data product. Typiquement, j’expliquerai comment s’imbrique le Machine Learning et le Big Data dans la data science en général.

C’est parti !

Qu’est ce que la Data Science

La Data Science (la science des données) est un terme récent dans le monde informatique. Cette discipline permet aux entreprises de tirer parti de leurs données internes et externes (sur internet) pour faire de meilleures décisions stratégiques.

Les champs d’application de cette discipline peuvent être divers. Notamment la recommandation de produits, détection de comportements frauduleux,  aide aux pricing etc…

Ces systèmes « intelligents » qu’on appelle des « Data Product » sont des modèles prédictifs. Ces derniers sont des modèles statistiques construits à l’aide d’algorithmes de Machine Learning.

Construire un Data Product

Pour qu’un « Data Product » voit le jour, tout un workflow de travail se déroule, notamment :

• Définir le besoin métier et le formaliser
• Récupérer les données utiles qui serviront pour répondre à ce besoin
• Nettoyer et préparer les données
• Modéliser un modèle prédictif
• Tester les performances du modèle obtenu
• Optimisation du modèle
• Mise en production

De part son côté « experimental », le data scientist déroulera de façon empirique ce workflow. De ce fait, ce mode de travail experimental n’est pas linéaire, mais itératif : Le data scientist définira une hypothèse, l’implémentera, et l’affinera par la suite.

Définition du besoin métier

Aux prémisses d’un projet de Data Science, le data scientist se rapproche des équipes métier pour comprendre leurs besoins. A l’issu de discussions avec ces équipes, le Data Scientist aura une vision de ce que cherche à accomplir le métier.

A ce stade, il va « traduire » le besoin dans un formalise plus rigoureux. De prime abord, il aura une idée plus ou moins fine des données susceptibles à la résolution du problème.

Définir rigoureusement un besoin à résoudre par la Data Science revient à définir les variables prédictives ainsi que ce qu’on cherche à prédire : la variable Cible. La définition de cette dernière, prendra en compte les différentes contraintes métier que seules les équipes métier sauront statuer.

A titre d’exemple, si on veut développer un système de détection de « désabonnement d’un abonné à un service en ligne« , il faudra définir la notion de « désinterer » d’un abonné à ce service en ligne. A ce titre, les équipes métier pourront émettre les hypothèses suivantes :

• Si l’abonnée se connecte à des intervalles de plus en plus espacés, cela veut dire que son intérêt au service en ligne faiblit
• Si les sessions de connexion au service sont de plus en plus courtes, on pourra en déduire qu’il commence à se désintéresser au service en ligne.

A la lumière de ces hypothèses, le data scientist pourra déduire les bonnes « hypothèses » à son tour, notamment, sur les données qui pourront l’aider à modéliser le phénomène de désinteret. Il pourra à titre d’exemple, décider de s’intéresser aux données historiques de connexion au site (durée, localisation…) ainsi que les activités des abonnés lors de ces connexions.

Récupération des données

Après la modélisation en formalisme rigoureux du besoin métier, vient la phase de récupération des données. Comme la Data Science est justement axée sur la « Data », cette dernière reste le nerf de guerre de ce domaine.

En fonction des hypothèses métiers que le Data Scientist se serait fait sur le problème, ce dernier va chercher au sein de l’entreprise et en dehors de ses murs les données qui seront pertinentes pour appuyer son hypothèse.

Données internes à l’entreprise

Les données internes de l’entreprise, sont les données que cette dernière possède. Cela peut être les bases de données, les différents fichiers numériques, les mails, les fichiers de logs, photos, archives etc..

Le Data Scientist cherchera dans ces sources de données pour retrouver les données qui l’intéressent. Généralement, les données de l’entreprise rescellent beaucoup d’informations. En effet, cela parce qu’elles concernent le métier de la boite.

Parmi ces sources de données, on retrouve : les bases de données, les CRM (Customer Relation Management), les ERP (Entreprise Resource Planning), les fichiers de logs, les plats (pdf, Excel, CSV….), les API Web…

Données externes à l’entreprise

Couplées aux données internes de l’entreprise, les données externe peuvent avoir une vraie valeur ajoutée. Les données externes à l’entreprise sont l’ensemble des données qui ne sont pas produites par l’entreprise elle même.

Parmi ces données, on peut distinguer : les réseaux sociaux, les vidéos sur les plateformes comme Youtube, les tweets, les « Likes » Facebook etc…

Ces données sont généralement peu chères pour l’entreprise car elle n’en est pas la productrice. On parle de Cheap Data. Par ailleurs ces données brutes contiennent beaucoup de bruit et sont généralement plus difficilement exploitables.

Ce type de données permet de mieux comprendre l’interaction d’une entreprise avec le monde extérieur. Notamment, une entreprise pourra utiliser sa présence sur les réseaux sociaux comme Facebook et Twitter pour mieux mesurer l’adhérence et la satisfaction de son audience ainsi que sa clientèle. Une telle mesure est généralement possible grâce aux techniques NLP (Natural Language Processing), de Sentiment Analysis (Analyse de sentiments) et de Machine Learning.

Nettoyer et préparer les données

Tirer profit de toutes ces données peut être un vrai challenge pour le data scientist. Certaines données seront simples à exploiter, comme celles en provenance des bases de données relationnelles. Dans ce cas, on parle de données structurées ou semi structurées.

D’autres données (dites brutes), comme les sons, les images, les signaux sociaux (commentaires, tweets, etc) sont plus compliquées à traiter. Notamment, il faudra leur appliquer des traitements spécifiques pour en tirer des indicateurs intéressants.

Le nettoyage des données comprend plusieurs points, notamment :

• Supprimer les données manquantes
• Suppression les valeurs abbérantes (outliers en anglais)

Supprimer les données manquantes

La suppression des données manquantes permet d’enlever les données incomplètes et inconsistantes dans un jeu de données. Leur suppression permettra d’avoir une meilleure performance du modèle prédictif.

Quand on souhaite enlever les données manquantes, on a deux choix :

• Les supprimer tout simplement
• Remplacer les valeurs manquantes par des valeurs « par défaut ».

Supprimer tout simplement des données manquantes peut intervenir quand l’absence de certaines valeurs ne permet pas d’avoir une observation tangible. Dans ce cas, on supprime toute l’observation vu qu’elle n’apporte pas une vraie valeur ajoutée.

 

Supprimer les données manquantes permet de garder des observations complètes dans le Training Set

 

Dans certains cas, il est tout à fait possible de « rattraper le coup » en réparant une observation ayant des données manquantes. Ceci est possible en remplaçant ces dernières par des valeurs par défaut. Par exemple, pour un Data Set d’observations sur les français, on peut avoir plusieurs caractéristiques (features). Notamment, le poids, la taille, statut marital, salaire, etc. Si pour une observation, il manque la feature  « taille », on pourra attribuer une valeur par défaut qui sera « la taille moyenne des Français » par exemple.

Ce type de traitement sur les données requiert une compréhension du métier pour attribuer des valeurs « par défaut » logiques et adéquates au phénomène à modéliser. Cela évitera d’introduire un biais qui faussera notre modèle.

Supprimer les valeurs aberrantes (outliers)

Un Outlier (valeur aberrante) est une valeur disproportionnée et qui sort d’un certain intervalle pour les observations du Data Set.

Supposons qu’on a un jeu de données où on a le salaire de plusieurs personnes en France. Admettons que dans ce jeu de données, on observe une moyenne de salaire à 2000 € / mois, et que la variation de ces derniers est entre 1500€ et 4000 € mensuelle. Si on observe pour une personne qu’elle a un salaire de 30.000 € mensuel (une célébrité de football par exemple), on peut dire qu’il s’agit d’un outlier.

 

Un outlier est toute donnée anormalement différente des valeurs observées dans le Training Set

 

Par ailleurs, les valeurs aberrantes concernent aussi les valeurs anormalement basses. En fin de compte un « outlier » est toute valeur anormalement différente de l’ensemble des observations.

Enlever ces outliers, avant d’appliquer les algorithmes de machine Learning, est primordial. En effet, cela permet de ne pas biaiser le modèle prédictif obtenu. En effet, le but du jeu est d’obtenir un modèle statistique qui se généralise bien à la situation réelle. Et non pas un qui s’adapte aux valeurs aberrantes.

Exploration des données

La phase d’exploration de données permet la compréhension de ces dernières. Comprendre les données revient à en comprendre la composition, la répartition et leurs intéractions.

L’un des procédés les plus simples pour explorer les données consiste à utiliser les outils de la statistique descriptive. Notamment, les indicateurs comme la moyenne, la médiane, les quantiles, la variance et l’écart-type. Ces indicateurs donnent une vision concise sur la répartition d’une caractéristique (feature).

Toujours lors de l’étude uni-variée des features, la visualisation des données à l’aide d’outils comme les histogrammes, les diagrammes camemberts, et les boîtes à moustache (box plot).

 

La visualisation des données permet de mieux comprendre les données

 

Croiser les features entre elles lors des visualisations permet d’entrevoir des relations moins évidentes à observer à première vue. Les diagrammes 2D sous forme de nuages de points voire les diagrammes 3D permettent de voir la répartition des données dans un espace multi-dimensionnelle.

Finalement, le but de la visualisation et de l’exploration des données est de comprendre les données. Un autre but de ces procédés est de valider que notre jeu de données est bien nettoyé et prêt à être utilisé par des algorithmes de Machine Learning.

Modéliser un modèle prédictif

Après la phase d’exploration, de nettoyage et de préparation de données, vient la phase de modélisation. Le but de cette étape est de construire un modèle statistique capable de « prédire » le résultat d’un phénomène donné.

Ce modèle se basera sur un jeu de données représentatif du phénomène qu’on cherche à modéliser. Le Machine Learning apprendra de ces données pour construire un modèle statistique. Ce dernier sera utilisé pour prédire le résultat sur une observation qu’il n’a pas encore « vu ».

Le but de cette phase est de construire un modèle qui soit une bonne approximation du phénomène réel qu’on cherche à modéliser.  Pour cette raison, le data scientist va essayer plusieurs hypothèses et les testera pour produire le meilleur modèle possible.

Tester le modèle en terme de performance

Après l’entrainement et l’obtention d’un modèle statistique, la question de performance du modèle obtenu se pose. En effet, on souhaite savoir à quel degré le modèle prédictif se généralise sur des données qu’il n’a pas encore vues.

Pour cela, le Data Scientist utilisera un Testing Set qu’il servira à tester les performances du modèle prédictif sur des données non vues lors de la phase d’apprentissage.

Le calcul des performances doit permettre de quantifier à quel point notre modèle se comporte. L’idée est que cette métrique soit une valeur concise et facilement interprétable pour que le data scientist sache comment le modèle réagit.

L’optimisation du modèle prédictif

Trouver un modèle prédictif cohérent qui se généralise bien est un processus itératif et empirique. Le Data scientist fera des aller/retour entre la phase de modélisation du système prédictif et celle de mesure de performance de ce dernier. Lors de ces itérations, il affinera davantage ses hypothèses sur les données, ainsi que les features qui entrent en jeu dans la prédiction.

Lors de cette phase, le Data Scientist pourra être amené à rechercher plus de données s’il se rend compte qu’il en n’a pas assez.  Dans ce cas, les phases de préparation et exploration de données s’imposent pour intégrer les nouvelles données obtenues dans le modèle.

Déploiement en production

Après l’obtention d’un modèle satisfaisant, vient la phase de déploiement de ce système. Lors des phases précédentes, généralement, les data scientists travaillent sur des jeux de données relativement petits. Afin de tester rapidement leurs idées, ils utiliseront des langages de scripting comme Python ou R.

Ces langages montrent leurs limites quand il faut traiter de larges quantités de données. Cela concerne notamment, les environnements de production. Dans ce cas, une réécriture du modèle de Machine Learning obtenu dans un langage et une infrastructure logicielle plus robuste s’impose.

Le déploiement en production consiste à lancer ce modèle en live après adaptation dans une infrastructure Big Data

Généralement, pour les systèmes en production, ce sont des architectures Big Data qui sont en place. Les modèles prédictifs sont écrits à l’aide de librairies Java ou .NET comme Apache Spark ou Apache Mahout.

Ce travail de réécriture peut être confié à des data engineers qui seront mieux placés que les data scientist pour maîtriser les rouages du Big Data.

Après la phase de réécriture et de déploiement en production sur des infrastructures Big Data, le Data Scientist pourra observer les performances du système dans une situation réelle. Cela pourra lui donner, éventuellement, de nouvelles pistes d’amélioration.

Conclusion

On vient de passer en revue le workflow d’un Data scientist et comment ce dernier procède pour construire un Data product basé sur des techniques de Machine Learning.

Ce workflow est itératif et peut se résumer en cinq grandes étapes :

1. Compréhension et formalisation du besoin métier
2. Récupération et nettoyage des données
3. Exploration des données
4. Phase de modélisation à l’aide du Machine Learning
5. Test de performance du modèle
6. Déploiement à grande échelle du Data product

Ce workflow est empirique et l’amélioration d’un data product se fait d’itération après itération.

Si vous avez des questions ou des remarques sur ce workflow, posez les en commentaires, je ferai de mon mieux pour répondre à vos questions.