Sélection automatique de commentaires utilisateurs pertinents

Par Yassine EL OUAHIDI, Justin GUIRAUTANE, Jean SAVARY, étudiants en Data Science à IMT Atlantique.

L’essor des « contenus utilisateurs »

Les opinions des utilisateurs quant aux services/biens proposés, par une plateforme prennent aujourd’hui une place de plus en plus importante lors de la phase de réservation ou d’achat. Selon une étude,94% des utilisateurs n’ont pas acheté un produit en ligne suite à la lecture d’avis négatifs. En parallèle, on constate une augmentation du nombre d’avis propres à un produit ou un service, ainsi qu’une grande diversité dans leur contenu.

Nombre de nouvelles reviews Google par trimestre
Nombre de nouvelles reviews Google par trimestre [https://searchengineland.com/googles-growth-in-online-local-reviews-continues-to-dominate-but-292571]
Pour un même produit, on peut observer divers axes de notations relatifs : pour des logements, on pensera notamment à la propreté, la conformité à l’annonce, etc. Les “reviews” apportent donc bien plus de détails et d’informations précises quant à l’avis vis-à-vis d’un produit/service que ne fournissent pas les notations (généralement une note de 1 à 5). Effectivement, plusieurs notes faibles peuvent correspondre à divers aspects très différents qui ont paru critiques aux utilisateurs. Par exemple, dans notre cas des logements, une personne peut être marquée par la très mauvaise localisation d’un logement alors qu’une autre peut porter une plus grande importance à la propreté. Dans les deux cas, il s’agira d’avis négatifs, dont les notes pourront être semblables, mais qui se perdront dans la masse de commentaires tous aussi disparates.
Il est d’autant plus décisif d’extraire de la valeur de ces “avis utilisateurs”. L’idée à retenir de ce projet est de générer de la valeur pour les utilisateurs à partir de données issues de ces utilisateurs, dans l’idée de construire une boucle vertueuse.

Exploiter les avis utilisateurs, oui … Mais comment ?

La difficulté première de ce projet est d’être en mesure de comparer la pertinence de deux commentaires entre eux au regard de l’intérêt d’un utilisateur. Sur quel aspect va-t-on mesurer la valeur d’un commentaire pour un potentiel acheteur ? Cette réflexion nous a naturellement amenés à la formulation de la problématique suivante :

“Comment définir une relation d’ordre au sein d’un ensemble d’avis utilisateurs relatifs à un produit donné, pour un utilisateur donné ?”

Notons l’importance de la mention « […] produit donné, pour un utilisateur donné ». L’ensemble de nos analyses et constructions de modèles porteront, comme nous le verrons par la suite, sur une simulation respectant le cadre : un produit donné pour une catégorie de produits donnée, pour un utilisateur spécifique.

Cas d’usage

« Archibald souhaite acheter un nouveau produit d’entretien ménager et réalise une recherche sur le site. À ce stade, nous recueillerons l’ensemble des produits disponibles sur la marketplace, répondant à la recherche d’Archibald. La marketplace lui proposera alors, selon son système de recommandation, un certain nombre de produits. À cet instant, après avoir analysé l’ensemble des commentaires disponibles, nous demanderons à Archibald d’indiquer par une phrase les caractéristiques, propres au type de produit qu’il recherche, auxquelles il est sensible. Suite à cela, nous calculerons via notre algorithme de machine learning, un score de similarité entre l’entrée d’Archibald et l’ensemble des commentaires disponibles pour chaque produit. Cette similarité, comme nous le verrons, prendra en compte des notions thématiques (par exemple, Archibald évoque l’odeur du produit d’entretien), mais aussi grammaticale et sémantique. À l’issue de cette brève phase, lorsque Archibald sélectionnera l’un des produits de la liste proposée, nous aurons sélectionné pour lui les 3 commentaires de ce produit les plus à même de satisfaire les critères qu’il a aura entré plus tôt. »

Avant d’être en mesure de réaliser cette « aide à la décision », via une sélection automatique de commentaires pertinents, nous devons satisfaire les besoins suivants : recueillir l’ensemble des commentaires relatifs à un produit, traiter ce texte de manière à appliquer des algorithmes de machine learning, définir une mesure sur laquelle nous comparerons deux commentaires (relation d’ordre).

Notre proposition de valeur

Une fois que nous serons en mesure de comparer divers commentaires au regard de l’intérêt d’un utilisateur, nous pourrons nous présenter comme un tiers de confiance, transparent, apportant une aide à la décision aux clients souhaitant acheter un produit. Notre apport de valeur du côté du site intégrant notre solution est l’augmentation de la satisfaction client via une navigation facilité par la lecture de commentaires sélectionnés spécifiquement. Les utilisateurs trouveront plus rapidement les informations qu’ils cherchent dans les reviews, et gagnerons du temps sur un site équipé de notre solution. Les clients seront plus fidèles au site et plus propices à consulter plus de pages. De cette satisfaction pourra suivre une hausse potentielle du taux de vente.

Plongée au cœur des reviews, l’incroyable récit de notre périple !

Choix du dataset…

Nous avons choisi notre dataset de manière à garantir l’universalité de notre produit, ie ayant pour objectif de pouvoir s’intégrer de manière rapide et simple sur tout type de site de e-commerce. Nous avons donc cherché un dataset contenant au moins les champs suivants : identifiant d’un avis utilisateur, identifiant du produit relatif à l’avis, contenu textuel de l’avis utilisateur. D’autres champs pourront être utilisés pour améliorer le produit, mais dans sa première version nous nous en tenons à cela.

Le prototype que nous avons construit est basé sur une base de données fournie par datafiniti.co.

La base de données utilisée pour mener à bien le prototype est constituée de 70260 commentaires utilisateurs relatifs à un ensemble de 600 produits différents vendus sur 14 sites.

… du site…

Étudions rapidement la distribution des commentaires en fonction du site.

On observe la nette prédominance des sites Walmart (~ 45% du total) et Bestbuy (~ 36% du total).

Étudions alors notre variable d’intérêt : le contenu textuel des commentaires : Walmart apparaît comme le site le plus intéressant pour la suite de notre projet. En effet, les commentaires sont deux fois plus longs, avec une médiane à 14 mots contre 7 pour Bestbuy. Ainsi que des catégories plus intéressantes, car plus propices à trouver des commentaires plus objectifs. Bestbuy contenant majoritairement des commentaires de produits liés à l’audiovisuel (films, musique, …) .

Pour la suite du prototype, nous avons donc uniquement sélectionné les commentaires utilisateurs relatifs aux produits vendus sur Walmart.

… de la catégorie…

Plus spécifiquement dans la catégorie des produits d’entretien ménager (« Household Essentials ») contenant environ 8 552 avis (en ayant retiré les avis en doublons).

… et enfin, du Produit !

En outre, pour l’évaluation du modèle, décrite par la suite, nous utiliserons le produit sélectionné ci-dessous. Pour rappel, comme mentionné dans la problématique, notre produit réalise une sélection de commentaires pour un utilisateur et un produit donnés.

Rentrons dans le cœur du projet : de la donnée brute à la sélection de commentaires !

Traitement des textes

La première étape, sur laquelle repose en grande partie l’efficacité des algorithmes évoqués plus tard, consiste au traitement des données textuelles des commentaires utilisateurs de sorte à les rendre « compréhensibles » par des modèles de machine learning. Pour cette phase, nous utiliserons la librairie de référence « Spacy » sous Python, connue pour ses modèles de traitements de textes certes complexes, mais bien plus performants que des modèles issus de l’autre librairie de référence « NLTK ».

Le pre-processing peut être résumé par le schéma suivant :

« Nous adorons tous la Data Science, mais encore plus les produits d’entretien ménagers » → « nous, adorons, tous, data, science, mais, plus, les, produits, d’entretien, ménagers ».

Passons ensuite à nos modèles. Dans le but énoncé plus haut – la similarité entre l’entrée utilisateur et notre base de commentaires

Comment quantifier la similarité entre deux textes ?

Une similarité entre deux textes peut-être de plusieurs types : sémantique, grammaticale, thématique ou autre. Dans notre cas, nous procédons en deux temps.

  1. D’abord en étudiant la similarité thématique. Nous extrayons les thèmes principaux de tous les commentaires du produit donné, pour ainsi pouvoir sélectionner les commentaires dont les thèmes principaux sont très proches des thèmes extraits de l’entrée utilisateur. Pour cette première étape, nous utilisons un LDA.
  2. Ensuite, en étudiant la similarité sémantique nous cherchons parmi les commentaires en sortie de notre LDA, les 3 étant le plus sémantiquement proches de l’entrée utilisateur. Pour cela, nous utilisons un doc2vec avec pour mesure de similarité, la similarité cosinus.
Etape 1. Extraction des thèmes principaux

Rapide explication du LDA (Latent Dirichlet Allocation). Le LDA fait parti des modèles d’extraction de topics ou « Topic modeling » . Ces algorithmes partent du postulat qu’il existe, au sein d’un corpus de textes, des thèmes latents. Ainsi, ces modèles attribuent à chaque texte un pourcentage d’appartenance à chacun des thèmes détectés au sein d’un corpus.

Nous appliquons donc notre meilleur modèle de LDA, entraîné sur un corpus de commentaires relatifs à la catégorie « Household Essentials », pour attribuer à chaque commentaire des coefficients d’appartenance aux 6 topics identifiés. Nous faisons de même pour l’entrée utilisateur. Les commentaires les plus similaires thématiquement (quantile 75%) sont envoyés en entrée du modèle suivant le doc2vec.

Cette étape, effectuée en amont de notre Doc2vec est primordiale dans notre calcul de similarité. Plutôt que de longues explications, voici un exemple pour mieux comprendre : (a) Si l’on utilise un Doc2vec (de même pour Word2vec) pour prédire les documents similaires à un texte contenant le mot « French », on obtiendra probablement des documents contenant « German » ou « English » , car ces mots sont utilisés dans des contextes grammaticaux similaires. (b) Si l’on utilise un LDA en amont et que l’on cherche à prédire les mots similaires à un texte contenant le mot « French » et évoquant le thème de la « nourriture », on obtiendra cette fois non plus des documents contenant « German » ou « English » mais plutôt « baguette », « vin », « boulangerie ».

Etape 2. Calcul de similarité sémantique entre textes

En sortie de l’étape précédente, nous avions donc plusieurs commentaires qui ont été sélectionnés. Ensuite parmi ces commentaires on sélectionne les 3 commentaires ayant les plus hauts scores de similarité sémantique.
Une fois que deux textes sont représentés sous forme de vecteur grâce au doc2vec, il est possible de calculer leur similarité cosinus.

Nous sommes donc à présent en possession d’une relation d’ordre !

Notre sélection actuelle n’est basée que sur ce score de similarité. Des améliorations ont bien entendu été envisagées, notamment l’ajout de features telle que la longueur du message, le nombre de verbes/adjectifs, etc. Nous avons également songé à entraîner un algorithme supervisé dont la variable à prédire est l’utilité d’un message (ie champ « ce commentaire vous a été utile ? »).

Comment évaluer notre sélection ?

Du non supervisé au supervisé

Notre modèle étant non supervisé, nous n’avons pas accès à une méthode directe permettant de l’évaluer. En effet, nous donnons un top 3 des commentaires les plus pertinents, mais il est impossible de garantir que ce sont bien ceux qu’il fallait choisir dans l’ensemble disponible. Pour pallier cela, une approche classique consiste à rendre le problème supervisé afin de pouvoir l’évaluer. Nous avons alors aléatoirement extrait 100 commentaires d’un produit donné, puis nous avons écrit 100 entrées utilisateurs. Nous avons ensuite associé à chacune des entrées les 3 commentaires que nous jugions les plus pertinents parmi ceux extraits. Grâce à cet « étiquetage » manuel, nous avons donc les entrées et les sorties du modèle qui devient alors supervisé. Finalement, nous comparons le résultat renvoyé par le modèle à celui que nous avons indiqué.

Qu’en est-il des résultats ?

21 % des commentaires sélectionnés par notre modèle sont jugés pertinents par les utilisateurs.

Comme on peut l’imaginer assez naturellement, les scores fournis plus haut peuvent être améliorés en ne considérant pas un top 3, mais un top 5 ou plus. On constate effectivement qu’en augmentant le nombre de commentaires à prédire, on a potentiellement plus de chances de choisir les bons.

Ces scores sont relativement faibles, mais il est difficile d’en conclure quoi que ce soit. En effet, la sélection de commentaires pertinents est un sujet très subjectif. Ainsi, notre test est biaisé par la personne qui a écrit et labellisé les entrées utilisateurs. De plus, notre procédure de test est appliquée sur un faible volume de données qui ne suffit pas à conclure.

Déploiement, commercialisation

Notre produit peut s’intégrer sous forme d’API au sein du site d’un partenaire. Pour faire ses preuves en utilisation, nous pouvons fournir un accès gratuit à nos services durant un période de 2 mois, période durant laquelle notre solution sera soumise à un A/B test dont l’objectif sera de quantifier l’augmentation d’indicateurs de performance utilisés par l’entreprise (le taux de conversion/vente semble pertinent). Après une période de tests, notre outil sera vendu sous forme d’abonnement mensuel, dont le tarif sera calculé sous forme d’un pourcentage du nombre de ventes réalisées.

Simulation de déploiement

Les gains potentiels grâce à notre solution sont aujourd’hui difficilement évaluables. Cependant, l’essor des plateformes d’achat en ligne nous garantit que de plus en plus de gens consommeront en ligne, et seront donc sensibles aux commentaires des autres utilisateurs. En considérant que notre modèle aura une influence sur le volume des ventes d’un produit donné, nous pouvons estimer le gain pour des plateformes à différentes échelles. Ci-dessous, un exemple avec le produit “Clorox wipes” vendu 5.99$ sur walmart.com.

Sur quels facteurs se concentrer pour réduire de manière efficace la criminalité ?

Par Victoire BONAUD, Auriane BORDENAVE, Mathura CHANDRAKUMAR et Guillaume LE GOFF, étudiants en Data Science à IMT Atlantique.

Depuis quelques années, le taux de criminalité global à New York a décliné, contrairement à d’autres grandes villes des USA. Pour autant, le taux de “hate crimes” (meurtres, viols, assauts graves) a beaucoup augmenté ces dernières années : 3,3 millions de victimes en 2018 contre 2,7 en 2015.

A la suite de ces constatations, le maire de New York, Monsieur Bill de Blasio, a lancé the office for the prevention of Hate Crimes, ou aussi appelé le MOCJ (Mayor’s office of Criminal Justice), en été 2019 afin d’empêcher ce type de crimes.

Il y a une réelle problématique concernant les stratégies à mettre en place dans le cadre de prévention contre les crimes violents.

Quel outil pour le Maire de New York ?

Pour aider le maire de New York, nous voulons créer un outil d’aide à la décision. Ce dernier permettrait de prédire l’impact de la modification de certains éléments, ou couples d’éléments, sur la criminalité pour chaque quartier de New York.

Quelles données utiliser ?

Nous avons cherché des données Open Data qui pourraient être liées à la criminalité, suite à la lecture de documents scientifiques traitant du sujet. Nous nous sommes ainsi concentrés, en premier lieu, sur des données socio-démographiques. Nous avons trouvé 7 variables d’intérêt comprenant le nombre d’habitants, le taux de personnes nées à l’étranger, le taux de pauvreté, le taux de chômage, le taux de diversité ethnique et le taux de jeunes déconnectés, par quartier de New York et par année entre 2000 et 2018.

Cependant, il est difficile pour le maire de mener des actions qui auront un impact direct sur ces variables. Comment avoir un impact direct sur la pauvreté ou le taux de chômage ?

Nous avons donc cherché d’autres sources de données qui permettaient d’avoir des renseignements notamment sur le nombre de commissariats, sur les infrastructures présentes dans différents quartiers et sur les évènements sociaux. Ce sont sur ces critères que le maire de New-York pourra influer.

Que faire de toutes ces données ?

Dans un premier temps, il s’agissait d’effectuer une préparation des données, qui a pris beaucoup de temps. En effet, le défi était de fusionner 11 bases de donnés puis de les regrouper en un seul dataset qui nous permette de répondre à notre problématique.

Le dataset final regroupe les données par quartiers et par années entre 2006 et 2018.

Pour fusionner les différents datasets, nous disposions des coordonnées GPS des événements et infrastructures. Il fallait donc faire correspondre ces coordonnées GPS aux Community District auxquels elles appartenaient. Cela a été effectué à l’aide d’une librairie Python de traitement des données géospatiales : geopandas. La ville de New-York met également à disposition des fichiers contenant les formes de chaque Community District, ce qui a permis d’effectuer l’opération.

Suite à ce travail nous nous sommes retrouvés avec le dataset suivant:

Mais la préparation des données ne s’est pas arrêtée là. En effet, notre problématique étant d’observer l’impact de certaines actions sur la variation de crime dans un quartier, nous avons décidé de faire d’autres modifications au dataset afin que notre étude soit plus adaptée à nos besoins.

Dans un second temps, nous avons donc décidé d’ajouter des colonnes qui expriment les variations de données d’une année sur l’autre plutôt que seulement les chiffres de l’année en cours. Par exemple, à partir de la colonne “Commissariats” on ajoute la colonne “Différence de commissariats” qui correspond au nombre de commissariats sur l’année étudiée moins le nombre de commissariats de l’année précédente.

Une fois toute cette base de données regroupée et afin d’avoir une première idée des influences de certaines variables, nous avons fait une première étude de corrélation. Nous avons retrouvé des corrélations plutôt intuitives et cohérentes. En temps normal ces études de corrélations permettent de supprimer les variables redondantes. Mais dans le cadre de notre modèle nous n’avons pas jugé utile d’en retirer, permettant à notre client d’avoir plus de choix de modification de données lors de la simulation de l’évolution du nombre de crimes dans un quartier.

La base de donnée finale est donc de 767 lignes par 55 colonnes.

Un problème de classification …

Plutôt que de prédire le nombre de crimes d’un quartier d’une année sur l’autre nous avons décidé de prédire la variation de crimes et de la regrouper en 3 classes : Augmentation, Diminution ou Stagnation du nombre de crimes par rapport à l’année précédente. La stagnation correspond à une variation du nombre de crime inférieure, en valeur absolue à 200.

Deux algorithmes nous intéressent tout particulièrement : l’arbre de décision et la régression logistique. En effet, ces deux algorithmes ont la particularité d’être facilement lisibles, ils ne sont pas des boîtes noires. Il est donc possible d’extraire les règles permettant de mener à la décision de l’appartenance à une catégorie ou à une autre.

Evaluation de nos modèles

Algorithme

Temps d’exécution

Précision

Aire ROC

Arbre de décision

< 1 seconde

55%

0.61

Random Forest (50 arbres)

~ 1 seconde

75.9%

0.77

Régression

Logistique

< 1 seconde

78.1%

0.51

Ainsi, l’algorithme de Random Forest est le plus performant dans notre étude (Aire ROC bien supérieur à 0.5, qui correspond à une classification faite au hasard).

De plus, il est toujours intéressant d’étudier l’arbre de décision sachant que cela nous permet d’identifier des associations de variables influençant la variation de crime dans le même sens pour aider à jouer sur les facteurs pour trouver les bonnes combinaisons de facteurs réduisant le crime.

Des scénarios prometteurs

Ainsi, nos modèles nous ont permis d’identifier des facteurs influençant la criminalité positivement et négativement. Nous avons donc simulé différents types de scénarios pour visualiser l’impact sur la criminalité.

Nous avons réalisé un premier scénario augmentant le nombre d’évènements sociaux de 30% : la criminalité diminuerait dans 3 quartiers.

Avec un deuxième scénario, nous avons cette fois augmenté le nombre d’événements sociaux de 10% et les infrastructures sociales de 2% : nous remarquons alors que la criminalité baisse dans 10 quartiers. Nous conseillons donc au maire de se concentrer en premier temps sur ces quartiers et d’y mettre en place d’avantage d’évènements sociaux.

Des améliorations sont tout à fait envisageables. Nous pourrions déterminer des associations de variables plus précis à l’avenir pour permettre la réalisation de scénarios encore plus efficaces pour la diminution du crime à New York. De plus, il serait intéressant de réaliser les modèles sur des groupes (clusters) de quartiers afin d’avoir des résultats encore plus précis selon le type de quartier. En effet, les variables n’influencent pas les quartiers de la même manière.

Mobiliser les montres connectées pour prévenir les accidents de la route liés à la somnolence

Par Faycal HAFID, Andy MÉRY, Mohamed MOUSSAOUI, Alla NOOR, étudiants en Data Science IMT Atlantique.

La somnolence au volant représente un véritable danger pour les automobilistes. En effet, une étude de l’American Automobile Association démontre que le risque est conséquent car plus d’un accident mortel sur six est lié à l’assoupissement au volant.

De plus, les conséquences économiques sont lourdes avec un préjudice estimé à plus de 30 milliards de dollars. C’est d’autant plus le cas pour les sociétés de transport routier dont les conducteurs sont confrontés à un haut facteur de risque puisqu’ils travaillent pendant de longues durées et souvent de nuit. Effectivement, une étude indique que près de 20% des conducteurs professionnels interrogés affirment s’être déjà endormis au cours du mois courant.

Une start-up imaginaire désireuse de sauver des vies

Pour être fidèles aux considérations business présentes en Data Science, nous nous sommes projetés dans le futur en start-upers, souhaitant mettre en pratique nos compétences pour répondre à des problèmes du quotidien. Ainsi, notre jeune start-up Rouse envisage-t’elle de développer une application mobilisant le Machine Learning pour exploiter les données d’un bracelet connecté porté par le conducteur qui surveillera ses constantes biologiques et l’alertera si jamais elle détecte un assoupissement.

Le business plan de Rouse est divisé en deux phases de déploiement. En effet, il s’agira dans un premier temps de concevoir un modèle sur des données académiques obtenues au cours d’étude sur le sommeil qui permettra de valider la faisabilité d’un tel projet. Dans un second temps, nous déploierons cette solution au sein d’un environnement de test représentatif du cas d’utilisation réel.

Des données pertinentes … issues d’Apple watches !

Le jeu de données utilisé provient de la banque de données open data en ligne PhysioNet, spécialisée dans les données physiologiques. Il a été collecté au département de Neurologie de l’université du Michigan via une étude sur le sommeil et se présente la forme de signaux de mesures de rythme cardiaque (battements par minute) et d’accélération (mesurées en g) ainsi que le nombre de pas. Ces données ont été collectées en faisant porter des Apple Watch à des participants qui les surveillaient pendant leur sommeil.

Le volume des données est assez grand pour permettre à la fois d’entraîner un modèle et de l’évaluer. En effet, les durées d’enregistrements sont de 7 heures en moyenne par patient, avec 75% des patients ayant au moins 8 heures d’enregistrement! Voici ci-dessous une visualisation des données à notre disposition sur une fenêtre de trente secondes :

Visualisation pour un patient
Visualisation pour un patient

Le patient s’endort, puis il y a un court épisode durant lequel il se réveille puis se rendort tout de suite après : on peut voir le changement dans le rythme cardiaque qui augmente puis revient à des valeurs précédentes. Cela indique que, dans une certaine mesure, les données sont pertinentes pour répondre à la problématique et sont suffisamment représentatives pour mettre en exergue une transition entre un état éveillé et un état de sommeil léger c’est-à-dire un assoupissement.

Passer le balai sur les mauvaises données

Allez hop ! Il est temps de nettoyer les données pour par la suite mettre en place notre modèle. Elles sont sous forme de fichiers .txt différents par patient et par attribut. Il a donc fallu assembler les données des différents attributs pour un même patient puis aussi rassembler les données de tous les patients confondus.

Ceci n’a pas été simple car les données ne sont pas toutes exactement de la même forme, ce qui est indispensable afin de faire une jointure et générer des attributs. L’idée est donc de mettre en forme les données du rythme cardiaque, leur attribuer le bon label, et de mettre les données d’accélérations sous la même forme pour permettre la jointure.

Place à nos algorithmes de Machine Learning

Des considérations liées à la nécessité de classifier en temps réel et ne pas avoir à traiter les flux entrants nous ont menés à implémenter un modèle de forêt aléatoire (RandomForest), et dans un deuxième temps des modèles de Naive Bayes et SVM.

Nous avons opté pour les deux critères d’évaluation suivants :

  • Précision : elle permet de qualifier les performances de la classification par le modèle
  • Rappel pour les labels 1 et 2 : il est crucial de maximiser la détection des vrais positifs qui correspondent à un état d’endormissement (passage de l’état 1 à 2).
Tableau comparatif des modèles
Tableau comparatif des modèles

Parmi les modèles de classifieurs entraînés, nous pouvons conclure avec certitude que Random Forest est le plus adapté. Comme nos données sont des signaux physiologiques collectés par un dispositif électronique, nous devons tester notre modèle face au bruit éventuel qui peut s’infiltrer. Nous avons donc classifié des données auquel on a ajouté du bruit, pour différents SNR (rapport signal à bruit) et nous avons comparé les performances obtenues par le modèle que nous avons sélectionné : le Random Forest. Les résultats illustrés ci-dessous sont des résultats auxquels on pouvait s’attendre : plus le SNR est bas (plus l’intensité bruit dépasse celle du signal) plus les performances du modèle faiblissent.

Évolution du rappel en fonction du SNR
Évolution du rappel en fonction du SNR

On se prépare pour la suite !

Ces résultats prometteurs nous permettent de suivre le déroulement prévu du projet et donc de planifier une phase de déploiement qui nous servira à suivre la performance du modèle dans des cas réels.

Il sera alors nécessaire de porter notre attention sur de nouvelles considérations, en particulier le fondement juridique. En effet, jusqu’alors nous avions utilisé une base de données sous la licence permissive OPEN DATA ODC-BY 1.0. Les personnes soumises à l’enregistrement de leurs données biologiques étaient Américaines ; conséquemment la conformité à la RGPD n’était pas requise.

Néanmoins, le cadre légal sera plus contraignant une fois le dispositif mis en place puisqu’il faudra respecter la RGPD. Plus spécifiquement, le signal physiologique qu’est la fréquence cardiaque possède un degré de protection supplémentaire en tant que donnée sensible par rapport aux données conventionnelles qui nécessite de mettre en place une solution de cryptographie adéquate.

Rouse se devra également de trouver un financement pour poursuivre un tel déploiement. Nous estimons que les résultats préliminaires encourageants permettront de convaincre des investisseurs de placer leur confiance en notre projet.

Comment le gouvernement indien peut-il réduire la mortalité infantile dans certaines régions de son pays ?

Par Nicolas HOULIER, Guillemette MASSOT, Guillaume MICHONNEAU et Aymeric MOULARD, élèves du parcours Data Science de l’IMT Atlantique.

Alors que l’Inde devrait se hisser à la troisième place des puissances économiques mondiales en 2020, le pays reste l’un des états qui compte le plus fort taux d’inégalité au monde. La pauvreté persiste dans le pays et environ 20% de la population indienne vit encore sous le seuil de pauvreté (fixé à 1,9 $/jour/personne), d’après la Banque Mondiale. Toutes les régions ne sont pas égales face à cela, et les principales touchées restent celles du Nord, tels que Chhattisgarh, Jharkhand et Odisha (anciennement Orissa). Cette situation se trouve renforcée par les faibles investissements de l’état indien dans le secteur de la santé. En effet, l’Inde se classe à la 159ème place sur 187 dans ce domaine en 2016, d’après la Banque Mondiale.

La pauvreté et les faibles investissements de l’état indien, entre autres, entraînent de graves problèmes sanitaires. Ainsi l’Inde a longtemps été le premier pays du monde en termes de mortalité infantile. Bien que celle-ci soit en fort recul depuis 10 ans, le taux reste élevé, avec plus de 39 bébés décédés dans leur première année pour 1000 naissances en 2017, d’après une étude du CIA World Factbook. L’Inde est désormais le 47e pays avec le taux de mortalité infantile le plus élevé au monde, d’après cette même étude, ce qui montre une amélioration limitée des conditions sanitaires en Inde.

Notre étude va donc porter sur la mortalité infantile en Inde, et particulièrement dans les régions les plus pauvres. Elle se basera sur la méthodologie CRISP-DM, qui se décompose en six phases distinctes.

Ces six phases, que sont la compréhension du besoin métier, la compréhension des données, la préparation des données, la modélisation, l’évaluation et le déploiement, permettront de comprendre les différentes étapes que nous avons suivies lors de ce projet. Nous allons les expliciter une à une dans la suite de l’article.

Diminuer la mortalité infantile, oui … Mais comment ?!

Cette phase de compréhension du besoin métier consiste à comprendre les problématiques métier que la Data Science tente de résoudre. Dans notre cas, nous constatons que malgré une forte croissance économique, l’Inde reste marquée par la pauvreté, notamment dans les régions du nord. La mortalité infantile est dans ces régions un véritable fléau. Il paraît donc primordial d’aider notre client, le gouvernement indien, à tirer parti des données qu’il possède en matière de santé publique. Notre objectif est de cibler les districts les plus touchés et les facteurs déterminants afin d’aider le gouvernement à investir correctement et aux endroits clés afin de diminuer la mortalité infantile.

Des fichiers, des variables et des individus !

Lors de la phase de la compréhension des données, nous nous intéressons aux données mises à notre disposition et à leur lien avec notre problématique. Notre jeu de données est un jeu de données de santé publique publié par le gouvernement indien sur leur plateforme opensource, faisant 3.24 GB.


Nos données concernent uniquement sept régions : Rajasthan, Bihar, Assam, Jharkhand, Odisha, Chhattisgarh et Madhya Pradesh, parmi les vingt-neuf existantes en Inde. Ces régions sont situées dans le nord du pays et correspondent d’après notre étude bibliographique aux régions les plus touchées par la pauvreté. Notre jeu de données se décompose en dix fichiers. Un fichier de description des variables, qui n’est cependant pas exhaustif, et ne permet pas toujours de comprendre la signification des données. Et neuf autres comportant les données d’environ un million de femmes chacun, réparties selon 197 variables. Deux régions possèdent en effet deux fichiers de données. Cette division en plusieurs documents a constituée une première contrainte, compliquant la compréhension du dataset dans les premières phases du projet.

Par ailleurs certaines colonnes ne sont pas directement en lien avec notre étude sur la mortalité infantile.

Fusion des fichiers et grand nettoyage !

La préparation des données est l’ensemble des étapes menées sur les données brutes pour créer un nouvel ensemble de données sur lequel appliquer les algorithmes.

Comme vu dans la partie précédente, notre jeu de données était divisé en plusieurs dossiers, la première étape de préparation a donc d’abord consisté à regrouper l’ensemble en un seul fichier.

Après une étude approfondie de nos données, nous nous sommes rendus compte que les questionnaires soumis aux femmes enceintes avaient évolués au cours des années, ainsi, certaines colonnes étaient composées en grande partie de NA. Nous avons donc effectué un tri des données, en supprimant les colonnes remplies entièrement ou en majorité de NA, ainsi que celles remplies de valeurs constantes.

Exemple de colonnes remplies majoritairement de NA dans le fichier Madhya Pradesh-Partie 1

Par ailleurs, comme nous l’avons souligné dans la partie précédente, le fichier descriptif ne nous permettait pas de comprendre la signification de certaines variables, nous avons donc dû les supprimer.

Les réponses aberrantes, comme un nombre total d’enfant de 68 pour une femme, ont aussi été éliminées pour permettre une étude cohérente. Ces données sont appelées des outliers.

Nous avons par ailleurs créé de nouvelles variables en agglomérant des variables existantes. Ainsi, la variable santé a été créée en pondérant les colonnes sur l’eau courante, les toilettes privatives, l’électricité et la présence d’un réfrigérateur. La colonne « mortalité infantile » a aussi dû être créée, car elle ne figurait pas directement dans nos données.

Alors, Big Data ou pas Big Data ?

La phase de modélisation résume le choix, le paramétrage et la mise en place des différents algorithmes sur notre jeu de données pour pouvoir répondre à notre objectif.

Dans un premier temps, nous avons envisagé de faire de la prédiction de mortalité infantile sur les individus. Cependant, la classe était minoritaire quelle que soit la tranche regardée, donc la prédiction donnait invariablement la classe majoritaire. Il n’y avait ainsi pas de gain d’information.

Ceci nous a mené à changer d’angle d’attaque. Nous nous sommes plutôt intéressés aux districts eux-mêmes, c’est-à-dire que nous avons adopté une approche plus statistique. Cette seconde approche est par ailleurs plus pragmatique : il est en effet peu probable que le gouvernement indien affecte ses moyens au cas par cas. Des investissements par district semblent plus raisonnables. Nous devons donc définir les districts cibles, en fonction de leur richesse, niveau d’éducation, de santé, de mortalité infantile. La détermination de ces districts doit être aisément comprise par le gouvernement indien, c’est pourquoi nous avons d’abord utilisé des arbres de décision.

Ainsi, en nous plaçant à l’échelle des districts, nous avons pu obtenir des arbres de décision de la forme de celui ci-dessus, qui nous ont apporté des premières informations sur les facteurs prépondérants de la mortalité infantile. On remarque bien que les noeuds supérieurs de l’arbre résultent du nombre de filles par famille, de la richesse moyenne et de la santé moyenne. L’éducation moyenne du district et le nombre de garçons par foyer étant des facteurs subalternes dans l’arbre.

De ce fait nous avons pu déduire, comme nous le supposions, que les feuilles de l’arbre après les noeuds impliquant une santé moyenne élevée avaient une plus faible mortalité infantile que les autres. Mais contrairement à l’idée reçue, dans cet arbre, la richesse et l’éducation ne vont pas de paire avec une mortalité infantile plus faible.

Cependant, cet arbre étant tronqué pour des raisons de lisibilité, et étant réduit sciemment aux variables que nous maîtrisons le mieux au moment de cette phase de modélisation, il ne nous donne pour l’instant qu’un aperçu des facteurs discriminants pour la mortalité infantile.

Nous avons alors construit un score pour classer les districts en fonction de la mortalité infantile, de son évolution dans le temps, de l’évolution du niveau de santé et de richesse. Beaucoup des districts avec les plus hauts scores de risque se trouvent au Rajasthan, ce qui sous-entend que c’est là que le gouvernement indien doit concentrer ses efforts.

Pour conclure sur l’utilisation du Big Data, le fait que nous ayons choisi d’œuvrer sur les districts a engendré une réduction considérable du dataset de travail. En effet, nous ne travaillons plus que sur un dataset de 201 individus (les districts) et une trentaine de colonnes. Dès lors, dans ce cas précis, employer des techniques d’analyse Big Data est inutile.

Du coup, quels sont les facteurs ?

L’étape d’évaluation vise à vérifier que l’étude menée dans la partie précédente apporte une réponse à la problématique métier.

Un premier traitement statistique des données nous a permis d’évaluer la proportion de mortalité infantile dans chaque état. On constate que ces chiffres sont particulièrement élevés, notamment pour le Jharkhand et le Rajasthan qui dépassent un taux de 10%. Il convient donc d’identifier les facteurs menant à de tels taux de mortalité infantile.

État

Assam

Bihar1

Bihar2

Chhattisgarh

Jharkhand

Madhya Pradesh1

Madhya Pradesh2

Odisha

Rajasthan

Total

Natalité

2 103 662

2 274 477

2 197 414

1 603 056

2 860 296

1 414 122

1 498 181

1 731 272

2 387 846

18 070 325

Mortalité infantile (%)

9,82

9,16

8,76

6,20

11,54

8,58

6,52

9,09

10,42

9,20

Pour cela, nous avons utilisé les algorithmes de fouille de données présentés dans la partie précédente. Il ressort de cette analyse que les facteurs les plus déterminants sont, par ordre d’importance : District; Nombre d’enfants; Groupe social; Éducation; Santé; Richesse.

La faiblesse de cette étude réside dans les constatations suivantes. Tout d’abord, les variables fournies ne sont pas toutes explicites, et nous ont ainsi empêché d’utiliser à fond le dataset. Secondement, l’anonymisation des districts a pour conséquence directe l’impossibilité d’enrichir les données comme nous l’aurions souhaité (en incluant le type d’industries implantées par exemple).

Ainsi, le classement que nous avons effectué demande encore de la part du gouvernement indien un travail afin de retrouver dans les districts bien classés les opérations menées, ce qui ouvrira la voie à une amélioration de la situation dans les moins bons districts.

Pour la suite des opérations …

Enfin lors de la phase de déploiement, l’objectif est de mettre à disposition la connaissance obtenue lors de la modélisation et de permettre l’utilisation de notre modèle.

Dans notre cas, nous allons mettre à la disposition de l’état indien notre code commenté ainsi qu’une documentation pour le détailler, afin qu’il puisse l’utiliser et déterminer quelles sont les régions à aider et quels sont les facteurs à améliorer dans ces régions.

Au niveau de la maintenance, notre documentation contiendra par ailleurs un résumé des données utilisées par notre modèle, afin que les questionnaires maintiennent ces questions et que le gouvernement indien ait conscience de l’importance d’obtenir une réponse à celles-ci. En outre, ce dernier n’aura aucun mal à continuer cette étude, notre travail étant codé sous R (logiciel libre).

Les data au service de la médecine pour combattre le diabète

Par : Alice Calliger, Ahmed Krichene et Pierre-Yves Mousset, élèves du Parcours Data Science de l’IMT Atlantique.

Le diabète, maladie souvent sous-estimée, touche aujourd’hui plus de 400 millions de personnes dans le monde et l’OMS prévoit plus de 600 millions de cas d’ici 2040. Cette progression est une réalité encore trop peu connue à l’heure actuelle, qu’il ne faut pas négliger. En effet, plus de 5 millions de personnes sont décédées du diabète en 2015 ce qui place cette maladie comme forte cause de mortalité dans le monde. De plus, il y a une réelle problématique concernant la connaissance de la maladie car 1 personne diabétique sur 2 ne sait pas qu’elle est atteinte. C’est pourquoi, il y a un véritable besoin de sensibilisation et de prévention de cette maladie, encore trop ignorée à ce jour.

Quelques chiffres clés

Source : International Diabetes Federation

Qu’est-ce-que le diabète ?

Le diabète est une maladie liée au mauvais traitement du sucre par l’organisme, qui conduit à une hyperglycémie et donc à un taux élevé de glucose dans le sang. Lorsqu’on mange des glucides, ils sont transformés en glucose. Les cellules du pancréas détectent alors une augmentation de glycémie et sécrète en conséquence des hormones (de l’insuline) qui permettent de réguler le taux de glycémie. Chez les diabétiques, ce système de régulation n’est pas présent. On considère qu’une personne a du diabète si son taux de glycémie dépasse 1.26 g/l à deux reprises dans la journée ou est égale ou supérieure à 2 g/l à n’importe quel moment. Il existe deux types de diabètes : un type I, maladie auto-immune qui apparaît dans la jeunesse et un type II qui apparaît plus tardivement, souvent après 40 ans et qui peut être lié à une mauvaise hygiène de vie. Le premier type, beaucoup plus rare, est souvent très rapidement diagnostiqué dès le plus jeune âge. A l’inverse, le second type de diabète représente plus de 90% des diabétiques et il est souvent inconnu des personnes atteintes. C’est donc le diabète de type II qui sera le sujet de notre étude.

Mais quelles sont les causes de cette maladie ?

De nombreux facteurs de risque sont souvent cités quand on parle de diabète. Le tabac, l’alcool, le cholestérol, l’alimentation, la pratique de sport, la sédentarité constituent un panel d’exemples de déclencheurs probables du diabète.

Notre projet, d’où proviennent nos données ?

Pour palier à ce manque de prévention et sensibilisation, nous avons voulu créer un outil permettant d’évaluer le risque d’une personne de développer le diabète.

A l’aide d’un questionnaire d’une dizaine de questions, nous pouvons prédire votre risque de devenir diabétique. Cette campagne de prévention permettra ainsi de sensibiliser les gens afin qu’ils changent si besoin leurs habitudes alimentaires, sportives, ou qu’ils prennent rendez-vous pour vérifier leur état de santé. En effet, comme pour de nombreuses maladies, un dépistage précoce permettra un meilleur traitement.

Afin de suivre et de détecter tout type de maladie, l’organisme américain Centers for Disease Control and Prevention met en place tous les ans un sondage auprès de ses citoyens qui renseigne de leur état de santé, de leur suivi médical ou encore de leur hygiène de vie. Le BRFSS (Behavioral Risk Factor Surveillance System), l’entité responsable de ces travaux, recueille des données dans les 50 États ainsi que dans le District de Columbia et dans trois territoires américains. BRFSS réalise plus de 400 000 entrevues avec des adultes chaque année, ce qui en fait le plus important système d’enquête sur la santé mené de façon continue au monde. C’est cette base de donnée que nous avons utilisée durant ce projet.

Nous tenons à préciser que les données utilisées dans le cadre de cette étude sont anonymisées afin de préserver la vie privée des gens. De plus, toutes les données produites par les agences fédérales sont dans le domaine public (cf section 105 of the Copyright Act), ce qui nous a permis d’utiliser librement et légalement ces informations.

Description de notre dataset

Les individus interrogés ont été sélectionnés au hasard. On obtient un échantillon assez représentatif de la population américaine notamment vis à vis du nombre de diabétiques. Ces graphes présentent la répartition des individus par genre et âge.

Nous avons donc développé plusieurs algorithmes basés sur ce dataset permettant d’évaluer le risque d’un individu de développer du diabète.

Pour mener à bien ce projet, nous avons suivi une démarche rigoureuse, commençant par la compréhension du besoin métier jusqu’à la mise en place de notre solution.

Ce schéma présente ainsi les différentes étapes de ce projet :

Préparation des données et analyse des données

La compréhension et la préparation des données a sûrement été le plus gros challenge de notre projet. En effet, les données brutes récupérées comportaient environ 330 variables encodées qui correspondent aux différentes réponses recueillies lors du questionnaire. Nous avons choisi de travailler sur les données de différentes années soit de 2011 à 2016. En agrégeant les données, nous obtenons un unique fichier de 2.821.503 lignes.

Nous avons en premier lieu étudier chaque colonne en utilisant une documentation d’explication des résultats du sondage, fourni par le BFRSS. La compréhension des variables nous a permis de sélectionner 100 colonnes. Les deux critères de sélection sont : Le nombre de valeurs manquantes pour la colonne concernée et la pertinence de la question. En effet, certaines variables avaient très peu de données ou n’apportaient rien à notre étude. Nous avons donc pu faire un premier tri.

Ensuite, nous avons étudié de plus près les relations existantes entre les différentes variables en utilisant une matrice de corrélation. Cela nous a permis d’affiner notre sélection. Nous avons utilisé 28 colonnes afin de construire des attributs pertinents.

Quels algorithmes ?

Nous nous sommes attaqués ici à un problème de classification, il s’agit de déterminer à l’aide de différents paramètres (taille, poids, fréquence de sport, etc…) si un individu risque d’être diabétique ou non.

Il existe de nombreux algorithmes de machine learning pour résoudre ce genre de problématique. Nous avons décidé de nous pencher sur 4 algorithmes qui sont en général particulièrement efficace pour ce type de classification binaire : la régression logistique, l’arbre de décision, le random forest et le support machine vector.

Comment évaluer nos modèles ?

Il existe plusieurs manières d’évaluer ce type de modèle.

Dans le cadre du machine learning et des algorithmes de type supervisé, on sépare souvent le dataset en deux parties (70%-30%), un qui servira à créer notre modèle (entraînement) et un deuxième à tester notre modèle.

Une première manière simple et efficace d’évaluer notre modèle est de regarder la matrice de confusion et ses métriques :

La courbe de ROC prenant en argument la sensibilité et la spécificité permet également d’évaluer un modèle à sortie binaire. On réalise la courbe de ROC de notre algorithme et on calcule ensuite l’aire sous la courbe (valeurs comprises entre 1 et 0.5). Plus l’aire est proche de 1 plus le modèle est pertinent, une aire proche de 0.5 sera équivalente à la probabilité de lancer une pièce et de deviner si le résultat sera pile ou face, autrement le hasard.

Voici un tableau récapitulatif des résultats des algorithmes réalisés avec le langage de programmation R (temps d’exécution obtenus sur une machine bureautique basique en 2018).

Algorithme

Temps d’exécution

Précision

Aire ROC

Régression logistique

7 minutes

91,69%

0,91

Arbre de décision

3 secondes

90,59%

0,5

Random Forest (250 arbres)

37 minutes

94,31%

0,92

Support Vector Machine

5 heures

90,58%

0,5

On constate donc que le Random Forest est l’algorithme le plus adapté à notre projet.

Une solution fiable et efficace

Afin de constituer le questionnaire de notre outil, nous avons cherché les variables qui influent le plus notre prédiction. Ces facteurs de risque sont présentés par ordre d’importance, ordre trouvé grâce à nos algorithmes.

Améliorer les résultats grâce à des technologies Big Data

L’exécution de certains algorithmes comme le Random Forest est assez coûteuse en temps, comme on peut le voir sur dans le tableau précédent. C’est pourquoi, nous nous sommes intéressés à l’utilisation d’une plateforme Big data pour réduire ce temps d’éxécution.

L’Institut Mines-Télécom et le GENES ont mis en place une plateforme de traitement de données massives : “Teralab”. Elle a une capacité de traitement importante avec une mémoire vive de plusieurs teraoctets et permet un traitement distribué des données: notre algorithme ne tourne plus sur une seul machine mais sur plusieurs à la fois d’où une réduction de son temps d’exécution.

Nous avons donc décidé d’utiliser cette plateforme pour notre projet. Pour cela, nous avons réécrit nos algorithmes en un autre langage : PySpark. Et le résultat est sans appel, nous obtenons un gain d’apprentissage de 9 !

Notre algorithme permet de prédire le risque d’avoir du diabète. Cette solution peut être utilisée afin de sensibiliser des individus au sein d’une population. Nous avons pensé développer une interface web permettant de recueillir les habitudes de vie d’une personne grâce à un questionnaire. Notre algorithme va ainsi pouvoir évaluer les probabilités que cette personne soit atteinte de cette maladie. Dans une version ultérieure, l’algorithme pourrait aussi faire des recommandations pour diminuer ce risque.

D’autres améliorations sont possibles. Il est probablement intéressant d’utiliser un dataset plus adéquat au problème pour l’apprentissage de l’algorithme. En effet, des informations sur l’hérédité pourraient améliorer la précision des résultats. Il pourrait aussi être judicieux de faire la distinction entre les différents types de diabètes.

La guerre contre les guerres d’édition dans Wikipedia

Par Amine AKKI, Hicham EL HAREM, Saad EL MAHFOUDI et Anas IRHBOULA, élèves du Parcours Data Science de l’IMT Atlantique.

Wikipedia est non seulement l’un des sites Web les plus visités, mais aussi l’une des plus grandes plateformes collaboratives du Web 2.0. Des millions d’éditeurs participent librement à l’élaboration et l’amélioration du contenu. Cependant, comme beaucoup d’autres choses dans la vie, la collaboration n’aboutit pas toujours de façon normale, surtout dans des articles plus controversés qui sont sujets à ce qu’on appelle les “Edit wars”.

Pour un visiteur de Wikipedia, Il est évident que par rapport à des pages comme “Pumpkin” et “Rivière” qui sont paisiblement développées, ils en existent d’autres qui sont très controversées : “Homosexualité” ou “Première guerre mondiale” à titre d’exemple. Or par souci de neutralité ces pages nécessitent d’être suivies et gérées par les administrateurs.

Notre intérêt est d’optimiser la détection de ces pages controversées afin de réduire les temps d’interventions, en mettant en œuvre un processus d’analyse de données.

Pour ce faire, nous avons travaillé sur un dataset de wikipedia où sont stockées les traces de révisions (modifications) des pages.

Chaque trace correspond à la version d’une page à un instant donné et contient des informations sur l’éditeur (nom ou adresse ip), la page (identifiant, titre, longueur en bytes …) et la modification qui a été faite (i.e. un code caractérisant de façon unique le contenu de la page après la révision qu’on notera dorénavant sha1).

Deux types d’actions sont possibles pour éditer une page wikipedia : 1) Faire sa propre modification en ajoutant/modifiant des passages du document ; 2) Faire un revert, c’est-à-dire annuler une ou plusieurs modifications faites sur un article pour revenir à une version antérieure.

Préparation à la guerre

Avant de commencer à élaborer des algorithmes complexes pour identifier les pages en conflit d’édition, découvrir les données et les préparer pour le traitement était une étape indispensable du projet.

Après avoir pris connaissance de la structure des traces de révisions et identifié le sens de chaque variable, nous avons procédé à une étape de préparation et sélection de données nécessaires pour la réalisation des objectifs de notre projet. En effet, Wikipedia fournit une base de données assez complète au niveau d’édition de pages Wiki où on trouve toutes les métadonnées de chaque page, e.g : taille de la page après chaque édition, titre, auteur/ éditeur, identifiant de la page, … etc.

Comme les données sont collectées de façon automatique, elles peuvent présenter des valeurs aberrantes (par exemple : identifiant de la page = 0). Il s’avérait donc nécessaire de commencer par vérifier et nettoyer le jeu de données avant d’appliquer une procédure analytique, en commençant tout d’abord par la suppression des données incomplètes (par exemple : Valeurs N/A ou NULL) et ensuite la création de nouvelles variables/indicateurs permettant de détecter les conflits éditoriaux sur une page Wiki.

Armes et munitions

La guerre éditoriale sur les articles de Wikipédia reste un sujet pour le moins… controversé et très subjectif. Une page sujette à une guerre éditoriale est difficile à définir et à identifier. Les avis diffèrent et les méthodes de détection se complètent comme s’opposent les unes aux autres.

Un choix doit être fait : quels signes pourraient nous permettre de reconnaître la présence de la guerre sur une page ?

Nous avons choisi six caractéristiques, en nous basant sur ce qui nous paraissait révélateur d’un conflit éditorial, et bien sûr, ce qu’on pouvait obtenir à partir des métadonnées à notre disposition, tout en nous appuyant sur les études publiées sur cette problématique (ici ou ).

Deux principaux indicateurs de la guerre éditoriale étaient bien sûr le nombre d’éditions et d’éditeurs sur la page. Ces deux informations à la fois faciles d’accès et assez révélatrices étaient le point de départ de notre fouille des pages. Elles ont d’ailleurs été prises en compte par l’étude faite par l’université de technologie et d’économie de Budapest : Characterization and prediction of Wikipedia edit wars.

Comme mentionné avant, les reverts (annuler une ou plusieurs modifications faites sur un article pour revenir à une version antérieure) ont leur importance. Quand le contenu d’une page est remis sans cesse à un état antérieur, l’avancement de l’écriture de celle-ci est clairement freiné par son caractère controversé ou par le fait qu’elle soit ciblée par des vandales, ce qui nous fait une transition directe à l’indice suivant : le degré de polémique. Le degré de polémique (measure of controversy) est un indice créé de toutes pièces et fortement inspiré de la recherche académique mentionnée un peu plus haut. On procède au calcul du nombre d’éditions confirmées (éditions ayant survécu pendant au moins 24 heures aux reverts) des utilisateurs impliqués dans les reverts et on l’utilise comme poids éliminant ainsi les vandales qui ont tendance à ne pas avoir d’éditions constructives.

Dans un niveau moindre, le temps qui s’écoule entre les éditions d’une page est important, si celui-ci est court, cela indique une activité dense et dynamique sur la page qui d’après nous peut indiquer qu’elle est en conflit. Ainsi nous avons rajouté la médiane de temps d’inter-éditions à nos indices.

Finalement, chaque article de Wikipédia peut contenir une page de Talk associée. Celle-ci regroupe les différentes discussions que peuvent avoir les utilisateurs sur le contenu de la page. Une page sous conflit éditorial est une page sur laquelle la discussion fait rage. La taille de la page Talk associée est quelque chose qu’on peut obtenir et qui renforcera notre pouvoir de détection de la guerre éditoriale.

Une fois ces indicateurs définis, il s’agit de sélectionner les pages qui se positionnent en tête selon un seuil défini en s’appuyant sur les histogrammes. À chaque page est donc attribué un score traduisant le nombre de critères validés (autrement dit l’indicateur vérifie le seuil prédéfini).

Et la guerre est déclarée à…

Le tableau suivant montre le top 15 des pages jugées en conflit.

Ce processus d’analyse est plus ou moins subjectif et dépend de la façon de choisir le seuil de chaque indicateur. Il était donc nécessaire de vérifier l’exactitude des résultats avant de valider l’ensemble de seuils.

Avoir un jeu de données de référence contenant la labellisation des pages « page en conflit » ou « page sans conflit » aurait été le meilleur moyen pour valider nos résultats. Malheureusement, le dataset fourni ne contient pas cette information vitale.

Nous avons donc proposé de vérifier manuellement les résultats en jetant un œil sur l’historique des éditions de ces pages, ainsi que le contenu de la page de discussion. Une méthode, qui certes, se base entièrement sur le jugement humain, mais qui nous a permis de nous assurer de l’efficacité de notre modèle.

Dans l’exemple ci-dessus, nous voyons clairement que les reverts sont systématiques et immédiats après chaque révision. Ceci étant, sur cet exemple, nous avons mis en lumière probablement l’action de robots. Une étude plus poussée doit être menée pour identifier si les actions sont bienvenues ou pas.

L’implémentation de notre algorithme pour la détection des conflits au sein de Wikipédia peut donc réduire les temps d’intervention des administrateurs, voire améliorer la détection elle même (mais cela demande à être validé !!!). De plus, le fait qu’une grande partie du code est écrite en Pyspark (langage de parallélisation d’exécution) permettra le passage à l’échelle en l’appliquant sur les jeux de données des autres versions de Wikipedia (English Wikipedia à titre d’exemple).

Comment vivre une nouvelle expérience utilisateur sur Yelp

Par Houssame Berkia, Florian Caringi, Yann Feunteun, Toufik Laichaoui, élèves du Parcours Data Science de l’IMT Atlantique.

Yelp est une entreprise créée en 2004 sur le marché de la recommandation. Les utilisateurs de Yelp, nommés les Yelpers, peuvent laisser des commentaires et des notes sur les différents commerces présents dans l’application en se créant un compte sur l’application. Ainsi les Yelpers ont accès aux évaluations et aux descriptions via l’expérience d’autres Yelpers. Chaque gérant de commerce (ou dirigeant) peut créer un compte gratuit pour publier des photos et envoyer des messages à ses clients. Yelp gagne de l’argent en vendant des publicités aux commerces de proximité. Elles sont clairement identifiées « Annonces Yelp » sur le site. Il y a un peu plus de 121000 publicités sur la plateforme aujourd’hui. Les commerces-annonceurs ne peuvent ni modifier les avis ni changer leur ordre d’apparition. De plus, Yelp possède en son sein un logiciel automatisé pour recommander les avis les plus utiles et fiables pour sa communauté, parmi les millions d’avis existants.

Yelp fait face à la concurrence des géants du web (google et facebook avec des services pros), de Tripadvisor et aux différentes communautés ou plateforme sur la recommandation collaborative. Le nombre de clients n’augmentant pas aussi vite que la concurrence, Yelp veut tout d’abord fidéliser sa communauté existante. Le prix de la publicité vendu aux commerces dépend de la visibilité que Yelp peut proposer à ces commerces et donc du nombre de Yelpers actifs sur la plateforme. Yelp doit trouver le moyen de garder ses bénéfices malgré un coût d’acquisition de plus en plus élevé d’une nouvelle clientèle.

Une des solutions est une des stratégies de génériques de Porter : se différencier par rapport à la concurrence sur les services proposés. Pour se faire, Yelp a lancé la réalisation d’une étude par notre groupe.

Pour mener à bien cette étude nous avons décidé d’utiliser une méthode pour ce projet de data-mining nommée CRISP-DM (Cross-Industry Standard Process for Data Mining). En tant que méthodologie, CRISP-DM comprend des descriptions des phases typiques d’un projet et des tâches à réaliser lors de chaque phase, et une explication des relations entre ces tâches. En tant que modèle de processus, CRISP-DM offre un

aperçu du cycle de vie d’un projet de data mining. Il y a 6 phases distinctes dans cette méthode. Une phase de compréhension du besoin métier, puis une autre pour comprendre les données fournies, ensuite préparer les données pour les utiliser lors de la phase de modélisation, et enfin une phase d’évaluation par rapport aux besoins métiers avant la phase de déploiement. Ces phases vont être le vecteur de présentation du projet dans cet article !

Compréhension du métier

Des objectifs commerciaux ont été définis pour répondre à cette problématique de différenciation par rapport à la concurrence :

  • Sauvegarder la communauté de Yelpers
  • Rendre plus user friendly l’application
  • Augmenter la communauté de Yelpers

Pour pouvoir évaluer le projet des critères de réussite ont été définis :

  • Diminuer le taux de churn de 10%
  • Augmenter le taux d’acquisition de 5%
  • Respect délai et coût

Yelp est une société habituée à avoir dans son sein de l’expertise en data-mining pour améliorer la pertinence du contenu et cibler au mieux la publicité sur la plateforme. De même, l’entreprise a déjà lancé de nombreux concours sur des problématiques variées en data-mining. Nous allons travailler en collaboration avec les experts en data-mining de Yelp et le pôle marketing. Yelp ayant plus de 12 ans d’existence et une grande communauté de Yelpers et de business, notre équipe dispose de nombreuses données bien formalisées. Pour ce projet seulement une partie des données sera étudiée. Toutefois, le programme pourra être étendu aux autres données si l’étude est une réussite. Enfin, la société ne prend pas beaucoup de risques mis à part le temps consacré par les experts de Yelp à travailler en collaboration avec notre équipe. L’entreprise, ayant souvent recours à des compétitions en ligne avec des récompenses, pourra arrêter l’étude si le délai n’est pas respecté pour faire passer le projet en mode compétition.

Les objectifs commerciaux du projet en commun avec notre équipe et les experts de Yelp ont été traduits en objectifs Data-Mining :

  • Définir une sous-catégorie de commentaires pertinente pour vérifier la véracité des catégories choisies pour les labelliser avec labels: Food, Service, Worthiness, Ambiance
  • Puis labelliser des commentaires avec les labels définis
  • Puis appliquer des méthodes d’apprentissage supervisées (méthode qui apprend par rapport à un jeu de données et applique après ce qui a été appris) sur la sous-catégorie de commentaires, tester la performance de chacun pour choisir la meilleure
  • Bilan à réaliser avec la direction marketing pour savoir si on réitère le processus
  • Si bilan positif, réitération à d’autres sous-catégories

Pour aller plus loin, il nous faut maintenant comprendre les données fournies…

Compréhension des données

Nous avons pu travailler sur un dataset fourni par Yelp comprenant des données assez diversifiées. Il comprend plus de 8 millions de lignes qui concernent plus de 77000 commerces, avec des informations sur les caractéristiques de l’établissement comme l’ambiance, le service, la nourriture dans le cas des restaurants, etc.

Comme expliqué plus tôt, nous nous intéressons à classifier des commentaires. Pour cela une première étape est d’explorer les données sur les commentaires afin d’en juger la qualité. On retrouve alors 1980658 commentaires avec des informations sur le rating de chaque commentaire, à quel business il se rapporte, quel utilisateur l’a publié, etc.

Notre but est d’extraire des variables sur lesquels entraîner un modèle d’apprentissage (nous détaillerons cette partie-là par la suite). Il était donc nécessaire de savoir si nous disposons de commentaires de longueur suffisante.

Nous pouvons voir que la plupart des commentaires ont une longueur supérieure à 100 caractères. On peut en conclure que les commentaires sont de longueur suffisante pour pouvoir extraire une information pertinente.

Aussi, à la lecture des commentaires, il n’est pas évident de savoir pourquoi un utilisateur a préféré noter tel commentaire en quatre étoiles plutôt qu’en cinq, ou en deux étoiles plutôt qu’en une, c’est pour cela qu’on a préféré ne pas tenir compte du nombre d’étoiles attribuées à un commentaire pour notre démarche.

Pour nous atteler à la création d’un modèle d’apprentissage, nous devons préparer les données pour réaliser l’apprentissage sur un choix de données pertinent et ainsi réaliser des itérations sur le projet de manière intelligente…

Préparation des données

Les données sur lesquelles on a travaillé durant ce projet proviennent d’un dataset que Yelp a mis à disposition pour le challenge. On s’est proposé, dans un premier temps, de restreindre notre étude à une seule des catégories de restaurants présents dans nos données. Dans notre cas, la catégorie ayant le plus de commentaires est la catégorie des restaurants mexicains; notre étude s’est donc portée sur cette partie-là du dataset.

Afin d’avoir notre dataset pour l’étude, il nous a fallu faire une jointure entre les tables businesses et reviews du dataset. Nous avons ensuite conservé uniquement les attributs sur lesquels on va faire notre apprentissage (les commentaires) et on a créé quatre variables de sortie pour la catégorisation (nourriture, service, ambiance et rapport qualité-prix).

Dans le but d’avoir des données sur lesquelles on peut entraîner notre modèle, on devait labelliser à la main un minimum de reviews. Cependant, sachant que cette partie de notre étude peut être vraiment longue et n’ayant pas beaucoup de temps pour mener à bien le projet, il nous fallait trouver une autre solution. Nous avons donc trouvé un dataset labélisé de Yelp qui convenait très bien à ce qu’on voulait faire. En effet, il était constitué en prenant 10.000 commentaires aléatoirement dans le dataset pour avoir finalement, après nettoyage, 9.000 commentaires labellisés. Les mots les plus fréquents dans tous les commentaires ont été pris afin de tester leur présence ou non dans les commentaires à labelliser afin de constituer nos attributs en entrée. Nos attributs de sorties sont les catégories listées auparavant. Tous nos attributs dans notre table finale sont des attributs booléens (1 ou 0).

Avec la récupération d’un dataset pertinent, nous pouvons nous atteler à tester des modèles paramétrables ou non…

Modélisation

Après avoir vérifié quelques hypothèses lors de l’étape précédente (pas de données manquantes et encodage binaire des features) il convenait de déterminer le type de problème que nous devions résoudre. Ici il s’agit d’un problème de classification multi label. En effet, une review peut être classée dans plusieurs catégories différentes en même temps. Ainsi nous avons choisi les algorithmes les plus performants et les plus utilisés pour ce type de situation. Il s’agit du Random Forest, Gradient Boosting, Support Vector Machine et Naive Bayes.

Dans l’optique de simplifier le problème initial, nous avons choisi d’entraîner des classifieurs binaires, un pour chacune des catégories. Ainsi une review pourrait bien appartenir à plusieurs catégories. Nous avons répété cette opération sur les quatre algorithmes sus-cités afin de les comparer.

Nous avons choisi séparé le dataset d’origine comme suit: 80% des données pour l’entraînement des modèles et 20% pour le test.

Nous avons choisi la précision comme mesure de performance des modèles. La précision sera définie comme le pourcentage du nombre de reviews correctement classées sur le nombre de reviews évaluées. La figure suivante présente les résultats obtenus sur les données de test, après entraînement.

Algorithme Random Forest Gradient Boosting SVM Naive Bayes
Précision 71% 75% 62% 54%

Nous retiendrons le Gradient Boosting, ses performances sur le critère mesuré étant plus élevées.

Deux étapes sont primordiales pour terminer cette première itération …

Évaluation

Pour réaliser l’évaluation de la première itération du projet, nous avons pensé à un test sur groupe de population pour voir un changement de comportement par rapport à la plateforme sans et avec. Cette méthode se nomme l’A/B testing. De plus, nous pensons à un autre test en gardant pendant 1 mois une plateforme différente pour les utilisateurs anglophones pour évaluer le taux d’acquisition. Yelp est une société ayant l’habitude des projets de Data-Mining avec la méthode CRISP-DM. Notre équipe a dû se familiariser avec cette nouvelle méthode. Nous avons été hésitants au début sur les “retours arrière” possibles dans le processus. Par contre, comme toute méthode agile, nous avons bien compris l’intérêt d’un processus cyclique pour pouvoir fonctionner en itération du modèle sur des sous-catégories du dataset. Cette méthode a permis à notre équipe et à Yelp de comprendre les points suivants :

  • l’exploration des données est une étape primordiale pour pouvoir choisir correctement les sous-catégories utilisées pour la modélisation
  • la préparation des données n’a pas été simple, mais cette étape est primordiale pour pouvoir avoir les données choisies dans la modélisation
  • le besoin métier ne doit pas être éclipsé à cause des difficultés techniques et le travail sur les données
  • la phase de test à la fin de la première itération doit être menée rigoureusement pour savoir si notre première idée répond aux objectifs commerciaux.

Si l’évaluation est positive, nous nous devons de déployer la solution en collaboration avec les métiers nécessaires…

Déploiement

Pour réussir un déploiement, nous devons collaborer et donner les informations nécessaires aux personnes concernées dans le projet.

  • Les décideurs devront être informés des changements sur la plateforme web, sur l’application mobile et le changement dans la structure de la base de données. En plus de l’utilité de ces changements. Si les résultats de l’étude sont jugés concluants, nous devons collaborer et informer le personnel suivant :
  • Les experts en Data-Mining devront mettre en place le modèle de catégorisation des commentaires en fonctionnement pour les nouveaux commentaires
  • Les experts en base de données devront être informés du changement de la base de données pour mettre en place la nouvelle base.
  • Les développeurs web devront incorporer la nouvelle organisation des commentaires pour les commerces sur la plateforme web et récupérer les nouvelles infos de la base.
  • Les développeurs de l’application mobile devront incorporer la nouvelle organisation des commentaires sur les commerces et récupérer les nouvelles données de la base.
  • Le pôle communication et marketing devront informer les Yelpers des changements apportés et mettre en avant cette différenciation verticale par rapport aux applications concurrentes

Au niveau surveillance, les tâches seront :

  • Surveillance de la plateforme web et de l’application mobile pour vérifier que les utilisateurs ont les commentaires catégorisés pour les commerces.
  • Vérifier que les nouveaux commentaires sont correctement labellisés

Au niveau de la maintenance, les tâches seront :

  • relancer le modèle avec les données récentes régulièrement avec une fréquence à définir.

Ainsi, la première itération s’achève. Si le résultat est probant, les décideurs peuvent décider de relancer d’autres itérations sur un autre jeu de données ou même changer la stratégie de data mining. Le but de la méthode CRISP-DM est de pouvoir adapter le projet et apprendre de chaque itération pour aller plus vite.

Yelp CityHeartbeat, quelles sont les tendances dans mon quartier ?

Par Arthur Bourgeois, Lucie Crucq, Célia Hocine et Jonathan Pathmanathan, élèves du Parcours Data Science de l’IMT Atlantique.

Permettre à ses utilisateurs de trouver le meilleur restaurant, coiffeur ou garagiste dans une ville, c’est la mission de Yelp. Créé en 2004, Yelp rassemble aujourd’hui plus de 115 millions d’avis sur son site et attire toujours plus de visiteurs par mois, principalement aux Etats-Unis où il se positionne en leader en matière de recommandations.

Comme d’autres avant eux, Yelp fait aujourd’hui appel à des personnes extérieures à son équipe pour développer de nouvelles idées afin de mieux répondre aux besoins de ses utilisateurs. L’entreprise a lancé le “Dataset Challenge” : un échantillon des données collectées par Yelp est mis à disposition des internautes, qui ont pour défi de trouver une façon innovante de les utiliser.

Dans le cadre de notre parcours “Data Science” à l’IMT Atlantique, nous avons eu pour mission de proposer un projet innovant basé sur les données du Dataset Challenge. Encadré par une équipe de professeurs experts dans les domaines de l’informatique, de l’analyse des données et de l’économie, nous nous sommes donc lancés dans la valorisation des données de Yelp.

CityHeartbeat : vers un nouveau service B2B

Très tôt dans notre réflexion, nous avons décidé de nous orienter vers un service à destination non pas des consommateurs, mais plutôt des commerçants. En effet, Yelp propose déjà de nombreux services aux consommateurs : recherche d’un business avec plusieurs filtres, écriture d’avis, système de notations sur de nombreux aspects du commerce…

En ce qui concerne les commerçants, Yelp offre des services pour attirer plus de clients : mise en avant du business sur le site (Yelp Ads) et proposition de bons de réductions type Groupon (Yelp Deals). Mais il manque selon nous des services pour aider les commerçants qui ne sont pas encore installés.

Elèves rigoureux et bien organisés que nous sommes, nous avons appliqué la méthode CRISP-DM pour structurer notre projet. Cette méthode est un pilier indispensable pour la réussite d’un projet de fouilles de données. Pour rappel, la méthode CRISP consiste en plusieurs phases :

  1. La compréhension du business qui permet de fixer les objectifs du projet en se posant les questions métiers
  2. La compréhension des données qui consiste en la découverte des données à notre disposition ainsi qu’à leur exploration
  3. La préparation des données qui est une phase de nettoyage et réorganisation des données, et si nécessaire de création de nouvelles valeurs calculées à partir d’autres données
  4. La modélisation pour la sélection du modèle de fouille de données ainsi que ses paramètres
  5. L’évaluation qui consiste à juger les performances du modèle et comparer les résultats produits avec les objectifs à atteindre
  6. Le déploiement à la fin du projet, phase pendant laquelle la solution est installée et de nouvelles pratiques sont mises en place suite aux conclusions tirées du projet.

En utilisant cette méthodologie, nous avons ainsi abandonné notre idée initiale : aider des commerçants à trouver la “recette” d’un business qui fonctionne était certes une belle idée, mais la phase de compréhension des données nous a permis de nous rendre compte que nous ne disposions pas des bonnes informations pour répondre à cette problématique. De plus, il était assez complexe de définir ce qu’était un commerce qui “fonctionne”, un critère trop subjectif.

Aidés par nos tuteurs, nous avons finalement pivoter et fait émerger une problématique un peu différente. Nous cherchons à exploiter les données pour répondre à une demande centrée sur le gérant d’un commerce. Un nouvel entrant qui souhaite s’installer dans un quartier a besoin d’informations sur les commerces de ce quartier, la fréquentation de ceux-ci, leur type, leurs notes et commentaires ainsi que leur catégorie de prix.

Notre future solution permettrait donc l’exploration d’un quartier pour permettre à un gérant de prendre mesure de la concurrence et d’observer les caractéristiques des business avec le plus de succès sur Yelp. Notre produit CityHeartbeat est né.

Nous avons passé un long moment à réfléchir sur les questions auxquelles devait répondre notre produit. Selon nous, deux questions principales intéressent un business qui souhaite s’installer : qui sont les concurrents déjà installés et qui sont les consommateurs qui viennent dans ce quartier ?

Quelles données pour une étude de marché ?

Après avoir défini nos objectifs, nous sommes passés à la phase 2 de la méthode : la compréhension des données.

Nous avions à notre disposition plusieurs tables regroupant des données par thème : la table business qui regroupe de très nombreuses données sur les commerces : leurs horaires d’ouverture, leur localisation, leur catégorie, leur note et des informations sur les services proposés ; la table checkin qui regroupe le nombre de visiteurs par période de temps pour chaque business ; la table reviews qui regroupe les avis des visiteurs ; la table users qui regroupe des informations sur les visiteurs.

Une première exploration de ces données nous a permis de nous rendre compte de plusieurs choses.

Premièrement, la table users n’est pas très utile dans notre cas car elle ne regroupe que des informations relatives à la communauté Yelp (nombre d’amis, commentaires des autres Yelpers…) et non pas des informations démographiques qui nous aideraient à qualifier les visiteurs d’un quartier… mais c’est un peu normal, non ?

Deuxièmement, la table des reviews nous paraît difficilement exploitable dans un premier temps, mis à part pour calculer le nombre d’avis par business. De plus, la date de l’avis ne veut pas dire grand chose car un utilisateur peut donner son avis plusieurs jours après sa visite.

Troisièmement, la table business, mise à plat, contient plus de 1000 informations différentes pour caractériser un business, ce qui rend sa manipulation difficile.

Enfin, nous remarquons que beaucoup d’informations, car non obligatoires, ne sont pas remplies : par exemple tous les restaurants n’ont pas rempli le champ “drive-thru” pour indiquer s’ils offrent ou non ce service. “Seulement 1% des business renseignent la case restrictions diététiques, ce qui la rend impossible à analyser” nous confie Célia, Data Quality Manager.

Suite à cette exploration, nous prenons deux décisions : utiliser uniquement les informations avec un taux de remplissage élevé pour garantir des informations pertinentes et partitionner la table business en sous-tables ne contenant que quelques colonnes pour faciliter et accélérer la manipulation des données.

Nous pouvons maintenant établir la liste des indicateurs que nous souhaitons suivre dans notre outil. CityHeartbeat permettra de visualiser :

  • la répartition des business en fonction de leurs coordonnées GPS sur une carte ;
  • leur nombre de checkins, leur nombre de reviews et leur note moyenne pour comprendre si ces business sont “performants” au sens de Yelp ;
  • des données sur les catégories de business et leur gamme de prix ;
  • des données sur les services proposés par les business (par exemple la livraison) et leurs horaires d’ouverture .

En ce qui concerne les consommateurs, nous ne pouvons rien afficher pour le moment mis à part leur nombre (grâce aux checkins).

Un POC interactif

Afin de réaliser notre tableau de bord, nous avons choisi l’outil Tableau Software, d’une part car nous connaissions déjà cet outil et d’autre part car c’est un outil puissant qui permet d’effectuer des calculs et d’en visualiser les résultats en temps réel. Il permet également une grande liberté dans la manipulation des données, les différents types de graphiques ainsi que les filtres. Dans un premier temps, par souci de simplification, notre première version de CityHeartbeat ne permet que d’observer les restaurants de la ville de Phoenix.

Le tableau de bord est très facile à prendre en main et la navigation y est intuitive. Il permet de répondre aux objectifs métiers que nous nous étions fixés et toute l’information capitale est synthétisée et présentée de la façon la plus parlante possible.

L’utilisateur peut rapidement visualiser où se trouvent les restaurants grâce à une carte de la ville observée. En fonction de la taille du point représentant le restaurant, l’utilisateur peut connaître sa fréquentation, et en fonction de la couleur allant du rouge au vert, il peut connaître la note donnée par les Yelpers. Un panel de filtres sur le côté de la carte permet de filtrer les restaurants de la zone : par leur catégorie, leurs horaires d’ouvertures et leur distance au point central de la zone étudiée.

L’outil permet également à l’utilisateur d’avoir une description globale des restaurants présents dans la zone choisie : comment sont réparties les enseignes en fonction de leur prix et de leur catégorie, combien de restaurants proposent certains services.

L’utilisateur peut aussi évaluer le poids du quartier par rapport à la ville entière : en effet, il peut voir quel pourcentage des checkins et des avis de la ville sont contenus dans la zone étudiée.

L’outil n’en est pour l’instant qu’à un stade de premier prototype. Nous avons plusieurs idées pour l’améliorer.

Premièrement, nous ne sommes pas totalement satisfaits de la façon dont la zone à explorer est définie. Aujourd’hui, nous utilisons une ville, un point de cette ville et nous calculons la distance entre chaque business de la ville et ce point central. L’utilisateur peut ensuite décider de réduire le rayon de la zone à explorer en diminuant la distance maximum au point choisi. Ce n’est pas la solution la plus pratique d’un point de vue utilisateur. La solution idéale serait de choisir une ville, puis un quartier de cette ville. Cela pose cependant plusieurs problèmes : les quartiers sont de taille très différente selon les villes (un “zoom” à l’intérieur du quartier serait alors nécessaire), de forme peu pratique à manier, et l’information du quartier n’est pas toujours disponible dans les données de Yelp.

Ensuite, comme cet outil est destiné à un commerçant qui cherche à s’installer, nous pourrions proposer plus d’options visant à lui permettre de comprendre pourquoi un business attire plus de personnes qu’un autre, en plus des checkins et de sa note. Entre autres, nous pourrions afficher une sélection d’avis : par exemple ceux qui sont notés les plus utiles, cools et drôles.

Nous pensions également indiquer quels sont les business qui ont souscrit à Yelp Ads ou Yelp Deals dans la zone observée, l’idée étant que de tels business devraient avoir une plus grande fréquentation, grâce à l’augmentation de leur visibilité. Cela pourrait idéalement inciter l’utilisateur de CityHeartbeat à souscrire lui-même à ces offres.

Dans tous les cas, nous sommes limités par les données en notre possession : certaines informations qui nous paraîtraient intéressantes ne sont pas assez remplies pour être exploitables, nous manquons d’informations sur la démographie des consommateurs… Nous devons également faire attention à ne pas montrer trop d’informations différentes sur notre tableau de bord, ce qui gênerait la lisibilité de l’outil.

Comment garantir nos revenus

En tant que membres de l’équipe Dynamic Solutions and Optimization de Yelp, notre mission n’est pas seulement d’améliorer le produit Yelp mais également de garantir des revenus. C’est la raison pour laquelle il est important de trouver un bon business model à notre projet.

Nous avons adopté un mode de vente en mensualités, avec une période d’essai où les interactions avec le tableau de bord seraient limitées pour donner envie à l’utilisateur d’acheter la version complète.

Notre produit pourrait en fait intéresser à la fois les commerçants qui souhaitent s’installer mais également des commerçants déjà implantés qui aimeraient se comparer facilement à leurs concurrents. Cela représente un nombre conséquent d’utilisateurs potentiels, sachant que rien qu’à Paris, 3 restaurants ouvrent chaque jour !

Ce que nous retenons de ce projet

Ce projet nous a permis de nous rendre compte de plusieurs choses.

Premièrement, ce n’est pas une légende : dans un projet de manipulation de données, ce n’est pas la modélisation ou la visualisation qui prennent le plus de temps.

Ici nous avons passé la majorité de notre temps à définir les objectifs de notre projet, puis à préparer les données. Une fois ces étapes passées, visualiser les données avec Tableau nous a semblé presque facile !

Ensuite, nous avons été confrontés au problème du big data, et là non plus, ce n’est pas une légende : la solution classique, mono serveur, que nous avions choisie pour la manipulation des données en Python, s’est heurtée à la quantité des données à manipuler (surtout le nombre de colonnes dans les datasets). En effet, nous n’avons pas utilisé d’architecture Big Data, et nous avons vite compris que le nombre important de calculs demandés nécessitait de changer de paradigme ! Faute de temps, nous avons donc contourné le problème en divisant les tables en sous-tables plus petites et donc faciles à manipuler, mais nous aurions cependant pu nous tourner vers des outils dédiés au Big Data comme Spark sur la plateforme Big Data TeraLab mise à notre disposition.

En conclusion, notre première version de CityHeartbeat s’est avérée fonctionnelle, facile à utiliser et pertinente. Pour évaluer sa performance, nous soumettrons un questionnaire de satisfaction à nos clients qui participeront bien entendu à l’évolution continuelle de la solution.

Affaire à suivre…

Qui se cache derrière les contributions Wikipédia ?

Par Mariam Thiam, Frédéric Tamagnan et Sébastien Guillon, élèves du Parcours Data Science de l’IMT Atlantique

Wikipédia, la plus célèbre encyclopédie du monde, compte plus de 30 millions d’articles. Sur cette plateforme, 25 000 articles sont créés quotidiennement dans plus de 280 langues. Les articles sont constamment édités, corrigés, et étoffés : il y a plus de 10 000 modifications par mois.

Mais quelle communauté se cache derrière ces contributions ? Peut-on identifier différents rôles chez les contributeurs ? Quelles sont les interactions entres les contributeurs ?

Dans cet article nous vous présenterons dans une première partie quelques statistiques sur notre dataset. Dans une deuxième partie nous étudierons les rôles des contributeurs. Enfin dans une troisième partie, en définissant comme lien social la coédition de pages (plusieurs personnes qui éditent la même page) nous découvrirons les interactions entre les contributeurs.

Quelques chiffres

Le dataset utilisé est Wikipédia simple, une version très allégée du dataset anglophone (de 2001 à 2016). Le dataset se présente comme une liste des contributions (ici nous faisons le focus sur les révisions)  : identifiant de la révision, date et heure de la révision, identifiant de la page sur laquelle porte la révision, taille de la contribution, numéro identifiant de l’utilisateur, etc. La seule information que nous avions sur l’auteur de la révision était s’il était enregistré ou non. Voici quelques chiffres sur ce dataset :

Nombre de révisions 4 936 382
Nombre d’articles 167 671
Nombre de pages total (articles, pages d’aide, etc) 391 930
Nombre de contributeurs enregistrés 49 037
Nombre de contributeurs non enregistrés 10 477

Nous travaillerons maintenant uniquement sur un dataset simplifié en ne prenant en compte que les révisions effectuées par des contributeurs enregistrés.

Détection des rôles

Namespace Majoritaire

Chaque révision -contribution- appartient à un « namespace » . Un namespace indique la catégorie dont fait partie la page de la révision. Une page peut être un article de l’encyclopédie, mais aussi une page de chat entre différents utilisateurs ou encore une page d’entraide.

Afin de déterminer les rôles des contributeurs, nous nous sommes intéressés aux namespaces utilisés par chacun d’entre eux et à leur quantité de participation.

Ci-dessous la liste  des différents namespaces et définition des namespaces que nous utiliserons :

ID

Subject Namespace

Talk Namespace

ID

Description

-2

Media

-1

Special

Pages sans wikitext

0

Main/Article

Talk

Article

2

User

User Talk

3

Utilisateurs

4

Wikipedia

Wikipedia Talk

5

Process & politique de wikipedia

6

File

File Talk

7

Wikipedia Content

8

Mediawiki

Mediawiki Talk

9

Espace d’édition pour les administrateurs

10

Template

Template Talk

11

Template d’articles

12

Help

Help Talk

13

Aide

14

Category

Category Talk

15

Regroupement de pages

Pour une description plus précise : https://en.wikipedia.org/wiki/Help:Files

A chaque subject namespace correspond un talk namespace. Par exemple Main va concerner les pages qui sont des articles en eux-mêmes alors que Talk (le talk namespace correspondant) va concerner les discussions autour de l’édition de ces articles.

Nous vous proposons de jeter un coup d’oeil sur la répartition des révisions du jeu de données par namespace. 71% des contributions concernent directement les articles (correction orthographique, ajout de contenu …).

Nous estimons que les namespaces majoritaires utilisés sont le reflet d’une activité de spécialisation pour chaque contributeur. Nous avons défini un namespace majoritaire pour un contributeur comme la catégorie de namespace où figurent plus de 30% de ses révisions. Un contributeur peut donc avoir entre 0 et 3 namespace majoritaires.

Un individu qui a 0 namespace majoritaire se disperse donc beaucoup entre les différentes catégories (ou alors n’a aucune révision à son actif) tandis qu’un individu avec 3 namespaces majoritaires se concentre sur 3 activités bien précises comme l’édition d’article, l’aide entre les membres, ou la discussion autour de certains articles (ou bien a fait très peu de révisions). Les namespaces majoritaires sont calculés de manière ordonnée. Pour un contributeur, son namespace majoritaire #1 contiendra plus de révisions que son namespace majoritaire #2 par exemple.

Cependant, une personne qui n’aurait fait que 3 révisions dans 3 namespaces différents, se verrait attribuer 3 namespaces majoritaires. Or cette personne a un impact mineur sur le site Wikipédia, on ne peut donc pas parler d’activités à proprement dit.

Score de participation

Afin de corriger le biais cité précédemment, nous avons défini un score de participation. Seul les individus avec un score de participation minimum jugé significatif pourront se voir attribuer un rôle.

Un attribut de notre dataset “minor” nous permet de savoir si une révision est mineure (le contributeur a écrit peu de texte) ou majeure (le contributeur a écrit beaucoup de texte).

Nous avons donc défini le score de participation :

Score de participation = Nombre total de révisions majeures (peu importe le namespace)

Définition des rôles

Nous vous proposons de lire notre matrice, qui définit des rôles pour la population de notre dataset.

Rôles

Score de participation

Namespace majoritaires

Contributeur Érudit

> 100 révisions majeures 

Article en #1

Contributeur dispersé

> 25

Pas de namespace majoritaire

Dépanneur

> 25

Help ou Help_Talk en #1 OU #2

Talker

> 25

N’importe quel talk namespace en #1 OU  #2

Social Networker

> 25

N’importe quel talk namespace en #1 ET #2

Catégoriseur

> 25

Category en #1

Template Creator

> 25

Template ou Template Talk en #1

Exemple : Supposons que Pierre ait effectué 300 révisions sur Wikipédia depuis 2001 dont :

  • 162 dans le namespace Article (soit 54%)
  • 120 dans le namespace Talk (soit 40%)
  • 18 dans le namespace (6%)

Grâce à  notre méthode, nous lui avons attribué 2 namespaces majoritaires (#1 = Article et #2 = User Talk). De plus, il a réalisé 150 révisions majeures parmi les 300 (donc le score de participation est assez significatif pour être validé). Par conséquent, Pierre endosse 2 rôles distincts chez Wikipédia : le premier de Contributeur Érudit (forte participation pour enrichir le contenu des articles) et le second de Talker !

Nos résultats

Rôles

Description

Population

Proportion parmi les rôles détectés

Contributeur Érudit

Membre qui contribue fortement à l’enrichissement d’articles

 722

41%

Contributeur dispersé

Membre qui n’est pas vraiment spécialisé dans une tâche

3

0%

Dépanneur

Membre qui aide les autres

4

0%

Talker

Membre qui passe son activité principale à discuter

844

47%

Social Networker

Version encore plus bavarde du Talker

3

0%

Catégoriseur

Membre qui contribue au regroupement d’articles

8

0%

Template Creator

Membre qui s’occupe de créer des canvas d’articles en amont de la création.

217

12%

TOTAL 

1801

 100%

Remarque 1 : Chaque membre peut se voir attribuer jusqu’à 2 rôles.

Remarque 2 : Nous avons identifié des rôles pour 1801 membres soit 3,6% des membres enregistrés de ce dataset.

Nous pouvons voir que les rôles majoritaires détectés concernent les articles, édition et discussion, ainsi que l’édition des canvas ou template d’articles.

La contrainte des 30% du namespace majoritaire est peut-être trop limitante pour la détermination des rôles plus subtils comme Social Networker ou Catégoriseur.

Détection des interactions

Nous avons ensuite cherché à déterminer les interactions entre contributeurs. Sur Facebook ou Twitter, les interactions sont explicites avec les likes, les liens d’amitiés ou de following. Sur Wikipédia, nous avons défini le lien social comme étant la co-édition de pages. Ainsi deux contributeurs se trouvent reliés s’ils ont contribué à la même page (article, page d’aide, etc).

Pour cette partie, nous avons travaillé sur un dataset allégé  de 10 000 contributeurs. Nous avons associé dans une structure de données (dictionnaire Python)  les groupes de contributeurs avec les pages qu’ils avaient co-édités.

Ainsi nous pouvions lire dans notre structure de données de manière : “Pierre et Jacques ont tous les deux contribués à la page sur Napoléon et à la page de discussion d’Obama. Pierre, Martin et Paul ont contribués tous les 3 au template de pages artistiques musicales”.

Nous avons ensuite extrait quelques statistiques de ces groupes de co-contribution.

Graphique du nombre de couples de contributeurs en fonction du nombre de page en commun

Voici maintenant quelques statistiques sur la distribution de la taille des couples de co édition :

Taille moyenne des groupes de co-édition

3

Ecart type de la taille des groupes de co-édition

3

Taille minimum des groupes de co-édition

2

Taille maximum des des groupes de co-édition

132

1er quartile de la distribution des tailles

2

médiane de la distribution des tailles

2

3ème quartile de la distribution des tailles

3

Conclusion

Dans cet article nous avons donc identifié avec un modèle très simpliste les rôles dans le dataset Wikipédia que nous avons utilisé. Nous avons également mis en valeur les interactions entre les différents membres au travers du lien de co-édition.

Nous pourrions imaginer, pour améliorer le modèle des rôles, de prendre en compte plus de paramètres afin d’avoir une détection plus fine : faire une détection par année ou par mois, prendre en compte les révisions mineures associées à chaque namespace et les reverts. De plus, nous pourrions mettre ça en lien avec la co-édition afin de regarder comment les rôles et le graphe de communauté se superposent.

Retour d’expérience d’un projet d’étudiant

Par Quentin MARINIE et Fabien VIOSSAT, étudiants 3A Telecom Bretagne.

social network concept

Sur Facebook, ce sont près de 10 milliards de messages et 4,75 milliards de partages qui sont enregistrés chaque jour. Sur Twitter, le maximum de tweets par seconde est de 143 199. Si l’on rapporte ces chiffres à la courte durée de vie de ces entreprises (respectivement 12 et 10 ans) on se rend compte de l’importance croissante des réseaux sociaux dans notre vie de tous les jours. Mais très certainement vous-même appartenez à d’autres réseaux sociaux ou communautés telles que Wikipédia, Copains d’avant, Instagram, LinkedIn ou encore la communauté de votre fournisseur de forfait téléphonique.

Ces nouvelles solutions de communication ont un potentiel énorme mais les entreprises font alors face à de nouvelles problématiques : Comment gérer des millions d’individus ? Comment savoir si un forum ou une communauté est en « bonne santé » ?

Ce sont les questions auxquelles Standing On Giants, fournisseur de plate-formes pour communautés et filiale de Telefonica (UK), tentent de répondre en collaboration avec le département LUSSI de Télécom Bretagne. Il nous a donc été proposé (Quentin MARINIE et Fabien VIOSSAT) dans le cadre du Projet Ingénieur de la filière ISA de mener une phase de cadrage de cette mission. Encadrés par Mme Cécile Bothorel et M. Laurent Brisson, tous deux enseignants-chercheurs dans ce même département, nous avons pu entamer la phase préliminaire du projet. Cet article constitue notre retour d’expérience sur notre mission intitulée « Mise à disposition d’une boîte à outils pour Data Scientist ».

Ancrer son travail dans la durée…

Présents sur les réseaux sociaux depuis plusieurs années, nous nous sommes aperçus que nous étions purement et simplement novices dans l’analyse de leur utilisation. Guidés par nos tuteurs, nous nous sommes intéressés aux statistiques ainsi qu’à la théorie des graphes qui, comme dans de nombreux cas, permettent de solutionner nombre de problèmes. Lecture de thèses, recherche d’ouvrages ou d’articles sur internet mais encore prise en main d’un serveur, découvertes de packages sur différents langages ont été notre quotidien. Les premiers instants s’apparentaient donc à un état de l’art du domaine, nous avons ainsi pu donner une orientation initiale au projet.

Cette démarche s’inscrivant dans une mission durable, nous devions constamment donner une traçabilité à nos recherches, rédiger des documents présentant nos résultats ou encore proposer des tutoriels sur l’utilisation de méthodes.

En effet, un des points importants était la pérennité des résultats : notre étude ne durant que 6 mois et la mission étant destinée à durer plus longtemps, nous nous devions de laisser des traces pour garantir la bonne compréhension de nos travaux.

Où chercher ? Que chercher ?

Un des intérêts d’une telle mission est que d’une semaine à l’autre, avec l’obtention de résultats, il est nécessaire de réorienter les recherches. Des réunions étaient donc prévues avec nos tuteurs de manière à présenter ces résultats, discuter de ceux-ci et enfin fixer les prochains objectifs.

S5_2016_Mission

Il a par conséquent fallut effectuer de nombreux tests sans savoir s’ils allaient être concluants. Comme prévu, nombres d’entre eux se sont révélés peu intéressants pour la poursuite de l’étude. Cet aspect peu motivant était pourtant nécessaire.

Nous avons certainement autant appris de nos échecs que de nos découvertes.

La présence de nos encadrants était bien évidemment essentielle, dotés d’une plus grande expérience dans ces domaines, leurs intuitions se sont souvent révélées utiles et vraies. Cet appui nous a permis d’avancer bien plus vite que par nos simples recherches et, avec plus de recul, nous réalisons que le projet final a très peu à voir avec l’idée initiale que nous en avions.

Le bon outil pour le bon usage !

Neo4J, Python, R, NetworkX voici les premières pistes que nous avions pour explorer les graphes. Après une première prise en main de certains et une recherche sur d’autres logiciels, langages ou packages, nous avons sélectionnés ceux qui nous paraissaient à première vue les plus adaptés. Par la suite, nous avons dû approfondir nos recherches sur ces solutions.

Quelle solution convient la mieux à nos objectifs ? Un package présent sur Python et R est-il mieux documenté ou plus efficace sur l’un ou l’autre des langages ? Là encore de nombreux tests ont été réalisés sur nos propres machines avec à nouveau des tentatives non concluantes mais permettant de comparer les différentes solutions.

Cependant, nous avons assez rapidement fait face aux limites de nos ordinateurs. N’étant pas en possession des datasets de Standing On Giants, nous avons testés différents algorithmes classiques d’études de graphes (clustering, proximité, centralité, taille de cliques…) sur des s5_2016_Scalabitydatasets trouvés sur internet et aux caractéristiques bien différentes (de 4000 individus à près de 10 millions). En concertation avec nos encadrants, nous nous sommes alors vus attribuer un serveur de calcul du département LUSSI. L’idée étant de tester la scalabilité des packages sur des graphes de dimensions semblables à ceux susceptibles d’être fournis par Standing On Giants. Nous voulions ainsi tenter de trouver des liens ou des généralisations entre le temps d’exécution de certains algorithmes gourmands en ressources et les paramètres même du graphe. Tout cela ayant pour finalité de pouvoir donner une évaluation du temps d’exécution d’un algorithme sur un graphe uniquement en fonction de ses paramètres (cf. notre article sur ce même blog). Un serveur de 128 Go de RAM et 32 cœurs a alors été mis à notre disposition pour la durée du projet.

De l’art d’utiliser un serveur !

L’utilisation de ce serveur nous a réservé quelques surprises. Entre les problèmes de connexion au serveur lui-même, les problèmes de connexion internet via tunnel SSH, les mises en place problématiques de nos environnements R et Python ou encore les scripts qui semblent tourner sans fin, il nous a fallu nous accrocher. Initialement, cela nous semblait tout aussi simple que de prendre en main un terminal sous Ubuntu mais nous nous sommes alors rendu compte qu’une tâche aussi banale qu’importer un fichier s’avérait compliquée. ferme_serveursUne fois le serveur et ses configurations mieux maîtrisées, les scripts ont pu être lancés (en tout une trentaine entre R et Python) dont certains ont été abandonnés car trop longs. De plus, une partie des résultats était à nouveau inexploitable ou n’apportaient pas d’informations quant aux relations entre temps d’exécution et paramètres du graphe (diamètre, densité, réciprocité…). Un serveur n’est pas aussi transparent qu’un ordinateur physique et cela implique pour son utilisation une grande maîtrise de ce dernier et des compétences d’administrateur système !

Ce qu’on en retient

Il y a donc différents aspects qui ressortent de ce projet.

Tout d’abord, il fut très intéressant de travailler sur une mission concrète d’entreprise d’autant plus lorsqu’elle a trait à des problématiques actuelles.

En effet, l’utilisation de la théorie des graphes pour décrire les réseaux sociaux est en pleine expansion et avoir pu en apprendre un peu plus auprès d’enseignants-chercheurs a été très enrichissant.

Cette approche assez exploratoire nous a également apporté un aperçu du travail effectué en recherche dans les différents laboratoires de Télécom ou même d’ailleurs.

Il n’est pas simple de devoir remettre souvent ses résultats en question et d’accepter que certaines tâches effectuées n’auront pas d’utilité pour la suite du projet. Enfin, et plus personnellement, cela nous a permis d’élargir notre domaine de connaissance : théorie des graphes, utilisation d’un serveur de calcul, découvertes de packages, lecture des thèses. Tous ces éléments ont fait de ce projet une expérience réellement intéressante et nous souhaiterions remercier nos deux encadrants, Cécile Bothorel ainsi que Laurent Brisson, de nous avoir soutenus, supportés et guidés lors de cette mission.