4.4 Simulations
4.4.1 Sélection des jeux de données
Avant de déployer les algorithmes de bandits-manchots en condition réelle, il est nécessaire
d’en réaliser une évaluation hors-ligne à partir de données collectées au préalable.
En effet, même si les algorithmes de bandits-manchots contextuels et non contextuels
pos-sèdent des garanties théoriques fortes de convergence, nous supposons que leurs
perfor-mances peuvent différer selon la nature du jeu de données employé (nombre de bras, nombre
d’instances, niveau de description du vecteur de contexte, répartition des probabilités de
ré-compense, etc.), comme cela pourra être le cas dans l’application finale que nous visons
c.-à-d., recommandation contextuelle de services dans la ville intelligente via l’application mobile
4.4. Simulations
scéno2. C’est pourquoi, dans cette étude préliminaire, nous observerons et analyserons la
performance des différents algorithmes de bandits-manchots sur différents jeux de données
de différentes natures en termes de : nombre d’instances (contextes observables), dimensions
contextuelles (de0 à80 dimensions catégorielles impliquant de 0à270dimensions binaires),
et de bras (de0à100classes).
Même si notre travail final se focalise sur les systèmes de recommandation, il est pertinent
d’éprouver nos solutions sur divers champs d’application afin de pouvoir les valider. Ainsi, nous
avons choisi douze jeux de données de domaines métiers variées issus de la classification
supervisée. Deux de ces jeux de données ont été générés de manière artificielle (Contrôleet
YSE). Ils seront donc pris en considération à des fins de simulation pour de la recommandation.
Après avoir rappelé comment nous préparons le contexte pour chaque jeu de données,
ainsi que la procédure que nous employons pour créer des cas de restriction sur le contexte
[Bou+17] (c.-à-d. en tronquant une partie du contexte), nous décrivons les jeux de données
que nous avons employés.
4.4.1.1 Préparation du contexte des jeux de données
Notons que, le contexte issu des jeux de données a été préparé afin d’être fourni aux
algorithmes en une représentation structurée de variables binaires (encodage one-hot). Ce
pré-traitement a consisté à transformer les variables continues des jeux de données originaux
en variables catégorielles en les divisant suivant leur plage de valeurs selon leurs quantiles,
c.-à-d., suivant la pertinence : en déciles, quintiles ou quartiles. Ensuite, nous avons binarisé
({0,1}) les variables catégorielles afin d’obtenir un vecteur de type «one-hot ». Notons que
ce type de traitement est habituel dans le domaine de l’apprentissage automatique et plus
particulièrement dans les bandits-manchots [All16 ; Li+10].
4.4.1.2 Créer de la restriction sur le contexte dans certains jeux de données
Concernant certaines expériences nous simulerons 2 cas différents : 1) Avec le vecteur de
contexte complet (vc) présent dans le jeu de données d’origine, 2) Avec une partie tronquée
du vecteur de contexte d’origine (vt) et ce afin d’observer l’impact d’un accès restreint aux
informations de contexte. Dans ces cas devt, nous rappellerons les modifications qui ont été
apportées aux jeux de données spécifiquement dans leur description.
4.4.1.3 Description des jeux de données
Chacun des douze jeux de données considéré est constitué d’un nombre d’instances,
s’ap-puie sur un contexte d’une dimensionddonnée (variables binaires) et propose un nombre défini
de bras (voir Tableaux 4.1 et 4.2).
Nous décrivons ci-dessous les jeux de données présentés en versionvcdans le Tableau 4.1
et en versionvt dans le Tableau 4.2 :
— Contrôle est un jeu de données généré artificiellement afin d’obtenir un vecteur de
contexte optimal x∗ et une distribution équiprobable des récompenses entre les quatre
bras. Il servira de jeu de données de contrôle. Nous avons également créé ce jeu de
données en versionvt, c’est à dire en tronquant le vecteur de contexte (c.-à-d., en
reti-rant la dernière dimension). Les versions vc etvt du jeu de donnéesContrôledoivent
être considérées comme des références : la version vc illustre le fonctionnement
opti-mal d’un algorithme (tenant compte du contexte) avec un x∗ (contexte optimal), tandis
que la version avec vecteur de contexte tronqué (vt) illustre l’effet d’une restriction (ou
parcimonie) du contexte sur les algorithmes deCMAB;
— YSE est un jeu de données que nous avons spécifiquement créé pour illustrer
l’ef-fet Yule-Simpson [Sim51 ; Yul03] sur les algorithmes de CMABs. Dans la version (vc)
présenté dans le tableau 4.1, nous proposons en premier lieu un jeu de données
consi-dérant l’ensemble des dimensions, ce qui permet d’éviter l’effet Yule-Simpson. Nous
créons ensuite une version (vt) qui quant à elle, permet de provoquer l’effetYule-Simpson
puisqu’on ne possède plus la dimension du vecteur permettant de le pallier. Ce jeu de
données est composé de1000instances d’hommes et de femmes travaillant dans deux
filiales d’une société quelconque, une en France et une en Inde. Cette société garantit
l’équité des salaires entre les deux sexes dans chacun des pays. Plus précisément, ce
jeu de données comporte deux classes de salaire (40 000euros pour les H/F travaillant
en France et20 000euros pour les H/F travaillant en Inde). Afin de créer un déséquilibre
amenant à un effetYule-Simpson, nous créons300hommes et200femmes en France,
et inversons cette tendance pour l’Inde (i.e, 200 hommes et 300 femmes en Inde) si
bien que cela aboutit à une moyenne de salaire pour les femmes inférieure à celle des
hommes si on ne prend pas en compte la dimension correspondante au pays. L’objectif
ici est d’observer les résultats obtenus par les algorithmes deCMABsdans le cas où on
ne leur fournit pas la dimension « pays » en tant que donnée du problème. Dans ce jeu
de données, le contexte de la version (vc) correspond alors au genre (H/F) et au pays
(France/Inde) alors que dans la version (vt) nous y retirons la dimension du pays ;
— Recommendation System for Angers Smart City (RS-ASM) est un jeu de données
spécifique à larecommandationque nous avons mis à disposition surKaggle3et que
nous utilisons dans [Gut+18a ; Gut+18b ; Gut+19a ; Gut+19d]. À l’aide d’un
question-naire en ligne, nous avons collecté des données de1076personnes dans deux contextes
environnementaux différents (été/hiver). Elles ont renseigné leurs données de profil
(âge, sexe, catégorie socioprofessionnelle, niveau de diplôme, spécialités, préférences,
ville). Ainsi, pour chaque utilisateur nous disposons de ses caractéristiques de contexte
(profil et contexte environnemental inclus). Ces personnes sondées ont ensuite
sélec-tionné, parmi un ensemble de 18 services, ceux pour lesquelles elles souhaiteraient
recevoir des recommandations de type notificationsur leur mobile et ce dans deux
dif-férents contextes donnés (été/hiver). Cela nous a permis de constituer une base de
connaissances indiquant l’évaluation donnée aux différents services par chaque
4.4. Simulations
teur pour chaque contexte. Nous évaluons ce jeu de données à la fois avec le vecteur
complet (vc) et avec le vecteur tronqué (vt). Afin d’obtenir un vecteur tronqué (vt) du
contexte, nous avons retiré du contexte les préférences et les centres d’intérêts des
utilisateurs. Cela permettra de comparer l’impact de la perte d’information contextuelle
induite entre ce jeu de données issu du monde réel (RS-ASM (vt)) et nos jeux de
don-nées artificielles (Contrôle (vt)etYSE (vt)). D’autre part, nous évaluerons également ce
jeu de données en version non-stationnaire (ns). Toutes les50 000itérations nous
modi-fions la distribution des récompenses pour chaque bras et ce en basculant de la version
«été» à la version «hiver» du jeu de données sans donner accès aux dimensions de
«saison» dans le vecteur de contexte ;
— Food4 est un jeu de données spécifiquement employé pour les systèmes de
recom-mandation, utilisé et distribué par Hideki Asoh [Ono+09].Foodest plus particulièrement
appliqué à de la recommandation de restaurant à des utilisateurs. Ce jeu de données et
originalement fourni avec de la parcimonie dans les retours utilisateurs c.-à-d., chaque
utilisateur n’a pas fait de retour sur l’ensemble des restaurants existants. Dans cette
étude préliminaire, pour des raisons de simulation et d’observation sur l’exhaustivité
du couple utilisateur-contexte et de son évaluation vis à vis de l’ensemble des classes
(restaurants), nous avons comblé ces informations manquantes via des techniques de
filtrage collaboratif et une mesure de similarité de cosinus utilisateur-utilisateur (voir le
détail de cette méthode à la Section 1.4) ;
— Covertype etPoker Hand provenant d’UCI Machine Learning Repository5sont quant
à eux des jeux de données permettant de monter à l’échelledans nos expériences tant
en termes de nombre d’instances que de nombre de variables de contexte. Covertype
associe des types de plantes et plus particulièrement des arbres à des variables
car-tographiques. En ce qui concerne les systèmes de recommandation, nous pourrions
considérer qu’il s’agit ici de recommander un type d’arbres à un emplacement selon
ses caractéristiques cartographiques. Poker Hand quant à lui est un jeu de données
associant des caractéristiques de mains de poker à la prédiction de la valeur de ces
mains (c.à.d., paire, brelan, suite, full, etc.). Les mains de poker sont décrites selon les
attributs des cartes qui la compose c.à.d., l’enseigne de chacune des 5 cartes (coeur,
pique, carreau, trèfle) et la valeur de chacune des5cartes (as, roi, dame, valet,10, etc.).
Il s’agit donc ici de recommander (prédire) la valeur d’une main de poker en fonction des
attributs des cartes qui la composent ;
— Jester provenant d’UC Berkeley6 est un jeu de données pour de la recommandation
de blagues et qui représente le cas non contextuel dans notre étude c.-à-d., aucune
information de contexte n’est disponible ;
— Enfin, les jeux de données Mushroom, Statlog, Yeast, Adult, et Students
Acade-mics Perf. provenant d’UCI Machine Learning Repository seront considérés pour de
4. AIST context-aware food preference dataset
5. Voir descriptions surhttp://archive.ics.uci.edu/ml/
la recommandation de type conseil à un tiers humain. Ces jeux de données sont
in-téressants à prendre en compte car la recommandation ne se fait pas directement à
l’utilisateur mais plutôt indirectement. Ainsi, dansMushroomil pourrait être question de
recommander à un pharmacien si un champignon est vénéneux ou comestible. Dans
Statlog il serait possible de recommander à un médecin si un patient a une
prédispo-sition ou non de pathologie cardiaque. DansYeast, il serait question de recommander
à un biologiste le site de localisation cellulaire spécifique d’une protéine selon ses
attri-buts. DansAdultnous pourrions imaginer recommander de potentiels prospects à une
entreprise de courtage recherchant des clients supposés, touchant un salaire suffisant
en considération d’un seuil pré-défini (ici 50 000 euros par an). Enfin dans Students
Academics Perf.il serait possible de recommander un étudiant à une école en fonction
de ses résultats et de la prédiction du niveau de réussite qu’il aurait dans cette école.
Jeux de Nombre Variables Variables Nombre Source Type de jeu
données d’instances catégorielles binaires de bras des données de données
Contrôle 1 000 4 4 4 Généré Artificiel
YSE 1 000 2 4 2 Généré Artificiel
RS-ASM 2 152 8 56 18 Kaggle Recommandation
Food 424 80 270 20 AIST Recommandation
Yeast 1 484 9 28 10 UCI M.L. Conseil
Adult 48 842 14 121 2 UCI M.L. Conseil
Mushroom 8 124 22 126 2 UCI M.L. Conseil
Statlog 270 13 46 2 UCI M.L. Conseil
Students Academics Perf. 131 22 73 3 UCI M.L. Conseil
Covertype 581 012 54 95 7 UCI M.L. Échelle
Poker Hand 1 025 010 11 85 9 UCI M.L. Échelle
Jester 24 983 0 0 100 UC Berkeley Recommandation
TABLE4.1 – Jeux de données de nos simulations (Versionsvc)
Jeux de Nombre Variables Variables Nombre Source
données d’instances Catégorielles Binaires de bras des données
Contrôle 1 000 3 3 4 Artificiel
YSE 1 000 1 2 2 Artificiel
RS-ASM 2 152 5 25 18 Kaggle
TABLE4.2 – Jeux de données de nos simulations (Versionsvt)
Dans le document
Recommandation contextuelle de services : application à la recommandation d'évènements culturels dans la ville intelligente
(Page 129-133)