4.3 Modèles de récompenses utilisés . . . . 57 4.4 Représentations des messages . . . . 59 4.5 Jeux de données . . . . 59 4.6 Conclusion . . . . 61
Ce premier chapitre constitue le scocle commun à toutes les approches que nous proposons tout au long de ce manuscrit. Nous définissons dans un premier temps le processus de collecte d’informa-tion dynamique, puis nous le formalisons comme un instance particulière d’un problème de bandit. Nous présentons ensuite les différents jeux de données et modèles de récompense qui permettront d’évaluer les performances du processus de collecte.
4.1 Processus de collecte dynamique
Dans cette thèse, nous nous intéressons donc au problème de collecte de données en temps réel sur les réseaux sociaux, dans un cadre générique, tel que les approches définies puissent être valides pour divers types de collectes plus ou moins complexes. Comme mentionné précédemment, la plu-part des grands médias sociaux mettent à disposition des APIs dites de streaming, fournissant une portion plus ou moins restreinte de l’activité de leurs utilisateurs en temps réel. Dans cette thèse, les expérimentations sont menées dans le cadre du réseau Twitter, qui propose les APIs de streaming
sui-vantes1:
— API Sample Streaming : renvoie aléatoirement 1% des contenus en temps réel.
— API Follow Streaming : permet de suivre en temps réel les contenus produits par 5000 utilisa-teurs, dans la limite de 1% du volume total des contenus produits ;
— API Track Streaming : permet de suivre en temps réel les publications contenant au moins un mot parmi une liste de 400 mots-clés, dans la limite de 1% du volume total des contenus pro-duits ;
— API Geo Streaming : permet de suivre en temps réel les publications géolocalisées dans 25 zones, dans la limite de 1% du volume total des contenus produits ;
Ainsi, l’API Sample Streaming est très limitée et son utilisation seule pour une recherche de données particulière peut nous amener à être noyé sous les messages collectés, tout en passant complètement à côté des messages potentiellement pertinents (puisque l’on ne collecte que 1% de l’activité globale, rien ne garantit que ne serait-ce qu’un seul message collecté soit pertinent, malgré la publication de multiples messages répondant à nos besoins sur le réseau). Aucun suivi d’activité ciblé n’est possible avec cette API. Pour des recherches simples que l’on peut exprimer sous la forme d’une liste de mots-clés, l’API Track Streaming pourrait paraître le meilleur choix de prime abord, mais son utilisation se heurte à diverses limitations. Premièrement, en raison de son mode de filtrage disjonctif (modèle booléen : tous les messages contenant au moins un terme de la liste de filtrage peuvent être retour-nés), la présence d’un seul terme trop générique dans la liste amène à n’obtenir quasiment que des messages contenant ce terme uniquement, et donc risque de nous faire passer à côté de tous les mes-sages réellement intéressants. Les mesmes-sages contenant tous les termes de la liste ne sont en effet pas prioritaires par rapport aux autres, comme cela serait le cas dans des modèles d’ordonnancement dé-finis dans le cadre de la recherche d’information classique. Rien ne garantit alors d’avoir des messages pertinents dans l’ensemble retourné, car il est très probable que la taille de l’ensemble des messages candidats dépasse largement les 1% de l’activité globale si la liste de filtrage comporte un mot fré-quent. Une méthode automatique qui sélectionnerait les mots à suivre selon cette API risquerait de se heurter très rapidement à ce problème, en choisissant probablement des mots génériques trop fré-quemment. D’autre part, l’ensemble des recherches considérées dans cette thèse ne concerne pas uniquement des besoins pouvant s’exprimer sous la forme de listes de termes, et pour des recherches plus complexes cette API de filtrage par mots-clés peut paraître peu pertinente. Est-il possible de dé-finir une liste de mots-clés présents dans la majorité de messages pertinents ? Alors qu’une recherche
dynamique selon l’API Follow Streaming peut permettre d’identifier les utilisateurs du réseau les plus susceptibles de produire du contenu pertinent, une recherche par mots-clés se contenterait d’identi-fier les termes les plus souvent présents dans les messages pertinents, ce qui paraît bien plus limité. En outre, dans le cadre de problèmes de collecte où l’on souhaite obtenir des données relationnelles relativement denses, centrées sur une communauté d’utilisateurs retreinte afin d’en extraire diverses statistiques, ce genre d’API par filtrage sur mots-clés n’est pas du tout adapté. Il s’agit alors de s’inté-resser aux producteurs de contenu, plutôt qu’à des marqueurs particuliers de pertinence. L’API Follow
Streaming paraît alors bien plus adaptée, c’est l’approche étudiée dans cette thèse pour la collecte de
données dynamique (bien que l’ensemble des approches définies dans cette thèse pourrait être éga-lement appliquées dans le cadre de recherches par mots-clés). Notons enfin que chercher le contenu pertinent par sélection d’utilisateurs à suivre permet par ailleurs d’être plus générique par rapport au réseau social considéré, puisque, alors que des APIs de streaming filtrées selon des mots-clé ne sont pas toujours disponibles, les médias sociaux se voient dans l’obligation, en vue d’être promus par des acteurs externes et utilisés dans divers contextes à travers le Web, de proposer des mécanismes permettant à des applications tierces de récupérer l’activité en temps réel d’utilisateurs ciblés. Par exemple, Facebook ne propose pas d’API de streaming filtrant les informations selon les mots em-ployés, mais met à disposition un système d’abonnement à des pages d’utilisateurs, fournissant des rapports temps-réel de leur activité similaires à ce que produit l’API Follow Streaming de Twitter.
Le problème de la collecte dynamique de données sur les réseaux sociaux peut alors se voir comme un problème de sélection de sources à écouter : n’ayant pas la capacité de considérer la totalité de l’activité du réseau à chaque instant de la collecte (pour des raisons techniques liées aux ressources à disposition ou bien en raison des limitations), l’objectif est de définir un sous-ensemble d’utilisa-teurs susceptibles de produire du contenu pertinent pour le besoin spécifié. On se focalise ici sur la sélection de sources pertinentes dans un réseau social lorsque le nombre de comptes d’utilisateurs pouvant être écoutés simultanément est limité. Nous proposons de considérer ce problème dans le contexte des réseaux sociaux de grande taille, où le choix des sources ne peut être effectué manuel-lement en raison du trop grand volume de données produites et du trop grand nombre de sources à envisager. Bien que notre approche puisse être appliquée à bien d’autres réseaux sociaux (tous ceux qui offrent un accès temps réel à un sous-ensemble de leurs données), nous nous intéressons à la collecte de données sur Twitter, où le nombre d’utilisateurs total est supérieur à 313 millions, pour une limite de 5000 utilisateurs pouvant être écoutés simultanément. Dans ce contexte, choisir quel sous-ensemble d’utilisateurs suivre à chaque instant est une question complexe, qui requiert la mise en œuvre de techniques d’apprentissage permettant une exploration intelligente de l’ensemble des utilisateurs du réseau pour déterminer de manière efficace les meilleurs candidats à écouter pour la tâche considérée.
Étant donné un processus qui, à chaque instant de la collecte, permet de récupérer les contenus produits par un sous-ensemble d’utilisateurs d’un réseau social, et une fonction de qualité permettant de mesurer la pertinence d’un contenu publié par un utilisateur écouté dans un intervalle de temps, il s’agit de définir une stratégie de décision permettant au processus de se concentrer sur les utilisateurs les plus intéressants à mesure que le temps s’écoule. Cette stratégie, apprise de façon incrémentale, est définie de façon à maximiser le gain cumulé - évalué via la fonction de qualité - par les utilisateurs écoutés au cours du temps. Dans ce qui suit, cette stratégie de décision sera appelée de façon équi-valente politique de sélection. Sur Twitter par exemple, l’information capturée pourrait correspondre à l’ensemble des tweets publiés par les utilisateurs écoutés durant la période de temps considérée, et la fonction de qualité pourrait correspondre à un score évaluant le contenu par rapport à une thé-matique donnée ou bien sa popularité. Nous reviendrons sur les différentes fonctions de qualité que nous utilisons par la suite.
Dans notre contexte, une difficulté majeure provient du fait que l’on ne connaît rien a priori des utilisateurs du réseau ni des relations qui peuvent les relier : récupérer des profils utilisateurs ou la
liste des utilisateurs amis d’un utilisateur donné n’est bien souvent pas envisageable, car cela requiert le questionnement d’une API coûteuse ou restreinte (fréquence des requêtes possibles souvent très li-mitée) et se heurte parfois à des problèmes de confidentialité des données. Cela implique entre autres que nous ne pouvons pas nous baser sur le graphe du média social pour explorer les utilisateurs (ce qui interdit l’emploi de techniques utilisées pour des problèmes connexes de Crawling) et que nous ne connaissons pas a priori l’ensemble complet des utilisateurs du réseau. Ainsi, en plus de sélection-ner les utilisateurs les plus pertinents, à chaque itération, le processus doit alimenter l’ensemble des utilisateurs potentiellement écoutables. Par exemple, un nouvel utilisateur peut être référencé dans un message si l’utilisateur à l’origine du message le mentionne dans son contenu. Typiquement, sur Twitter, les utilisateurs peuvent se répondre entre eux ou republier des messages d’autres utilisateurs, ce qui nous offre la possibilité de découvrir de nouvelles sources. Le processus général de collecte, présenté dans la figure 4.1, opère de la façon suivante à chaque itération :
1. Sélection d’un sous-ensemble d’utilisateurs relativement à la politique de sélection considérée ; 2. Ecoute de ces utilisateurs pendant une fenêtre de temps donné ;
3. Alimentation de l’ensemble des utilisateurs potentiellement écoutable (par exemple en fonc-tion des nouveaux utilisateurs référencés dans les messages enregistrés) ;
4. Evaluation des données collectées en fonction de leur pertinence pour la tâche à résoudre ; 5. Mise à jour de la politique de sélection en fonction des scores obtenus.
Ensemble
d’utilisateurs Politique de sélection Utilisateurs à écouter
Messages
collectés Fonction de qualité
Mise à jour des scores Potentiellement: nouveaux utilisateurs
FIGURE4.1 – Processus général de la capture de données.