3.1 Fouille de contexte (« Context Mining »)
3.1.2 Contribution & Impact
Dans le présent travail, réalisé essentiellement entre 2012 et 2014, d’abord dans le cadre du travail de master de Ali Jaffal [119], puis pendant le début de sa thèse [118], il a été proposé une méthodologie permettant d’associer l’usage d’un service à des situations caractéristiques, reconnues grâce aux éléments de contexte observés. On identifie ainsi, à partir des données issues de l’usage, des éléments de contexte permettant de caractériser l’utilisation d’un service. L’objectif ici est de pouvoir reconnaître l’influence d’un (ou plusieurs) élément(s) de contexte dans le choix d’un service par un utilisateur. Pour cela, cette méthodologie propose l’application de l’Analyse de Concepts Formels (ACF) [203,266], laquelle permet d’organiser les services en plusieurs clusters en fonction des éléments de contexte observés pendant leur usage.
L’Analyse de Concepts Formels (en anglais, Formal Concept Analysis) fournit une approche de structuration de connaissances à partir de données complexes. Elle permet de construire sur la base d’une relation binaire une hiérarchie de concepts traduisant une association forte entre un sous-ensemble d’objets et un sous-sous-ensemble d’attributs. Son objectif principal serait de déterminer des paires d’ensembles d’objets et d’ensembles d’attributs qui se définissent mutuellement et de manière unique, appelées concepts formels [119]. L’ACF est centrée sur cette notion de concept qui, de manière informelle, peut être vue comme un groupement d’objets et de leurs attributs communs. Un treillis de concepts traduit ensuite la relation d’ordre hiérarchique entre les concepts formels, et peut être utilisé à des fins de clustering, de classification, de prédiction ou d’approximation [118].
A travers l’ACF, on peut regrouper un ensemble d’objets en fonction des propriétés partagées entre eux. Les objets ici représentent les services, alors que les propriétés correspondent aux éléments de contexte communs observés pendant l’usage de ces services. Il en résulte plusieurs « classes », permettant de regrouper les services utilisés et les éléments de contexte observés pendant leur utilisation. La Figure 36, issue de [117], illustre des résultats obtenus à partir de l’analyse de données réelles correspondant à l’observation de l’usage d’une tablette Android pendant 69 jours. Plusieurs éléments de contexte ont pu être observés comme la localisation de l’utilisateur, les SSID des réseaux utilisés, ainsi que les applications utilisées à un instant t. La Figure 36 présente ainsi un treillis obtenu avec l’ACF montrant l’usage des applications en fonction du SSID réseau21. Cette analyse permet de classer ensemble les applications et les réseaux dans lesquels ces applications ont été utilisées, caractérisant ainsi des patterns d’usage de l’utilisateur. Par exemple, l’application « Alarm » n’a été utilisée qu’à partir du réseau « Network_4 ». L’analyse de ces classes offre une vue sur le comportement d’un utilisateur face aux services (représentés ici par les applications) proposés par un
20 Pour les travaux de fouille de contexte, nous traitons de manière indistincte les notions de service et d’application, puisque le focus ici sont simplement des unités dont l’exécution est sollicitée par l’utilisateur. 21 Pour des raisons de respect de la vie privée, les noms des réseaux ont été anonymisés.
81 système et permet ainsi de mieux comprendre l’impact que certains éléments de contexte pourraient avoir dans l’usage de certains services.
Figure 36. Application de l'ACF pour l'analyse du contexte d'usage d'applications mobiles [117].
Le choix de l’ACF est un élément particulièrement innovant dans ce travail. La plupart des travaux utilisant la fouille de contexte [206,229] le font à travers des méthodes statistiques, comme les Réseaux Bayésiens [206] ou les chaînes de Markov [161, 271]. L’usage de l’ACF était alors inédit au moment de l’apparition de ce travail (2012-2014). Par ailleurs, la plupart de ces travaux [206,229,161] font usage des techniques de fouille de données pour la reconnaissance des activités de l’utilisateur (e.g. courir, marcher, dormir, etc.), et non pour l’analyse de la pertinence d’un élément de contexte comme ici. Dans ce cadre, on peut citer [205, 206] comme une approche semblable, puisque ces auteurs cherchent à apprendre, à partir des données, des associations entre les éléments de contexte et des actions à prendre par le système (les actions prenant la place ici des services). L’adoption de l’ACF apporte une caractéristique particulièrement intéressante à ce travail : une classification « multi-classes ». En effet, contrairement à beaucoup des méthodes statistiques de clustering, l’ACF permet le chevauchement entre les différentes « classes » identifiées à partir des données. Autrement dit, un même service peut être placé simultanément dans différents concepts formels, identifiant ainsi plusieurs situations, reconnues à travers un ensemble d’éléments de contexte, où ce service a été invoqué. Par exemple, dans le treillis illustré par la Figure 37, issu de [116], l’application « Gmail » est associée à plusieurs de ces « classes » (i.e. à plusieurs concepts formels), représentant le fait que cette application est utilisée en plusieurs situations distinctes, caractérisées par différents éléments de contexte.
Google+, Skype, Youtube... Likewise, no access network has
been captured for the calculator application. Network_1 contexts, through the numerous intersections We notice a strong relationship between Location_1 and
between these context attributes in terms of related applications
(Maps, Gmail, Agenda, etc.), as shown on Figures 3 and 4.
This relationship has been validated by the user, who
confirmed that indeed Network_1 is physically located in
Location_1. Intersections like this one allow recovering
missing information, i.e., information that could not be
captured. We can, for instance, infer the access networks
associated to the calculator application (on the top of the lattice
in Figure 4), since it is often used in Location_1, which can be
associated with the Network_1 context.
C. Association Rules Extraction for Recommendation
During this step we have used an extended formal context
as an input, in which we have considered recent applications as
part of the user context, in addition to temporal, geographical
and network connection attributes. We have also discarded
very frequent applications, which do not bring relevant
information, such as system applications. The frequency
diagram of remaining applications is presented in Figure 5;
applications with high frequencies are used in a significant
proportion of contexts. This is the case for Chrome, with a
frequency equal to 0.65.
Figure 6 shows the frequencies of context elements. When
the frequency is high, the corresponding context element is
frequently associated to applications. For example, Location_1
( c e e s home) has a frequency of 0.65, which
means that many applications are used from there.
We have applied the Apriori algorithm [24] to the extended
and filtered applications and context elements. Apriori first
computes the set of frequent itemsets together with their
support measure, such as:
E1= [E-mail, Gmail, Rai.Tv, 20minute-android, t_Evening,
Network 1, Google+], supp:11.62%
E1 is a frequent itemset (both context elements and
applications) with a support equal to 11.62 %. E1 is a set of
context elements for the user.
We have obtained about a hundred frequent itemsets, such
as the ones shown in Table II. We have only kept the itemsets
with a support superior to 10% for the extraction of association
rules. The choice of a low support value allows considering a
large fraction of frequent itemsets (further filtering is made
later, as explained in the following). Among all generated
rules, user has rejected only a small set (about 23%), most of
Figure 5. Applications frequency diagram
Figure 3. Sub-lattice corresponding to the locations context.
Figure 4. Sub-lattice corresponding to the network context.
82 Figure 37. Treillis associant l'usage de certaines applications à leur contexte d'usage [116].
Cependant, l’impact le plus intéressant de ce travail ne se trouve peut-être pas dans ses résultats proprement dits, mais surtout dans les difficultés surmontées pour les obtenir. Pour valider ce travail, différentes expérimentations ont été conduites : d’abord une expérimentation avec des données réelles [117, 116], obtenues à l’aide d’un logiciel permettant le monitoring d’un dispositif mobile (des applications invoquées et de leur contexte d’exécution), puis une enquête auprès d’un groupe d’étudiants (dont les résultats sont mentionnées dans [120]). Ces expériences démontrent qu’il est possible d’établir un lien entre une application (ou un service) et des éléments de contexte, notamment lorsque l’utilisateur a des habitudes d’usage réguliers (c.a.d. qu’il a l’habitude d’utiliser certaines applications à des situations précises, comme par exemple, l’application réveil à la maison, les jeux pendant le temps de transport, etc.). Le processus d’analyse de ces données à travers la méthodologie proposée [119, 117] a également mis en lumière plusieurs limitations des méthodes de fouille de données par rapport aux données de contexte et à ses caractéristiques.
Tout d’abord, l’hétérogénéité des données de contexte apparaît comme un obstacle majeur pour une analyse généralisée et totalement automatisée de ces données. Bien souvent les méthodes de fouille de données s’appliquent à certaines « catégories » des données. Par exemple, la FFT (Fast Fourrier
Transformation) utilisée dans [206] est particulièrement adaptée aux données numériques, alors que
l’ACF appliquée dans ce travail s’adapte davantage aux données symboliques (i.e. des étiquettes). Les données de localisation démontrent particulièrement bien cette question. Un prétraitement a été nécessaire afin de traduire les données de localisation, extraites lors de la première expérimentation, vers des « étiquettes » (localisation_1, localisation_2, etc.) pouvant être plus facilement exploitées par l’ACF. Les données de coordonnées GPS ont ainsi dû être regroupées en plusieurs régions géographiques, auxquelles ces étiquettes ont été affectées. Étant donné l’hétérogénéité qui caractérise les données de contexte, difficile d’imaginer alors l’application d’une seule et unique technique pour l’analyse des données quel que soit l’élément de contexte considéré, et en même temps, difficile de ne pas considérer le risque de perte d’information relatives aux possibles liens existants entre les différents éléments de contexte à force de fractionner l’ensemble de données en fonction de leur nature.
Il paraît alors claire que les techniques de fouilles de données actuelles ne semblent pas encore assez adaptées pour gérer l’hétérogénéité des données de contexte sans une phase de prétraitement ou de
training conséquente. Or ces phases de prétraitement et de training peuvent aussi poser problème
dans le cadre de l’Informatique Pervasive. La plupart du temps, ces phases sont « off-lines »,
c’est-à-1045
Ali Jaffal et al. / Procedia Computer Science 52 ( 2015 ) 1040 – 1046
values of were not chosen randomly, we have begun with the value of zero for and then we increased the value
of slightly. Further on we analyzed the results after using the different values, stopping when the number of
relations was very limited to extract and interpret the results.
4.2.Comparison of frequency measures
We first compare the various strategies for the least restrictive refinement threshold, i.e.
high_threshold=low_threshold=average_frequency (for both frequency measures). Strategies using the same
frequency measure can be compared, i.e., strategies 1 and 3 on the one hand, and strategies 2 and 4 on the other
hand. As we could expect, the frequencies obtained with the measure that is based on the context ontology are more
relevant than the ones obtained from the one that relies on no semantic information. For example, the 3G context
element does not appear as very significant among all other context elements in strategy 1, whereas the ontology
indicates that it is indeed the only context element related to the type of network connection in this dataset, and
therefore it should not be neglected. However, our experiment shows that even without using an ontology-based
frequency measure, our methodology for building formal contexts that reflect the impact of context elements on
applications still provides interesting results with regard to resulting Galois lattices.
In the following, for space reasons, we focus only on ontology-based strategies (2 and 4), that have provided
optimal results.
4.3. Comparison of refinement strategies
With =0, both high and low strategies lead to larger Galois lattices; it means that the refined formal context
generates more concepts, as illustrated in Figure 3 for the high strategy. This lattice is more interesting than the
original lattice of figure 1 for recommendation and personalization purposes, as more clusters of applications and
context elements are generated, leading to a finer-grained classification. In Figure 1 for example, Flappy bird, SMS,
telephone, VDM and Youtube applications have in common the context elements 3G, home and morning, whereas
they are separated into 2 concepts in Figure 3: Gmail, VDM and Youtube are associated to 3G and morning, and
Flappy bird, telephone, VDM and Youtube are associated to 3G and home. It means that after the refinement
strategy, Flappy bird and telephone are no longer associated to the morning (and will therefore not be considered as
very likely to be used in the morning).
Fig. 3. Galois lattice obtained with strategy 3 (ontology-based frequency measure and high_threshold), with =0
We also notice that some context elements have disappeared from the lattice, as they have not sufficient impact
on the user applications: coffee break, restaurant, parents’ home and lunch break. It is interesting to remark that the
number of concepts in the lattice increases despite the disappearance of 4 context elements. This shows that the
precision of the obtained results has indeed increased significantly with regard to the initial lattice.
The formal contexts obtained with higher values of the parameter, i.e., with stronger refinement conditions,
generate smaller Galois lattices than the ones obtained with =0 (for both high and low strategies). For our
dire qu’elles doivent se réaliser en dehors de l’exécution normale d’une application et souvent sous l’œil attentif d’un expert. Il en résulte très souvent des modèles qui sont eux utilisés lors de l’exécution de l’application.
La question qui se pose alors est : peut-on envisager toujours ces phases de prétraitement et de
training ? Il paraît évident que ces phases ne peuvent pas être réalisées avec des données de chaque
utilisateur concerné. On peut donc imaginer l’application des techniques proposées sur des jeux de données prédéfinies, obtenues en laboratoire ou dans des phases de tests avec des utilisateurs choisis au préalable. Les modèles gérés suite à ces phases se présentent comme des modèles génériques appliqués à n’importe quel utilisateur. Or, la seconde expérience menée a démontré le caractère très personnel de cette relation entre une application et son contexte d’exécution habituel. En gros, le comportement d’un utilisateur pouvant être très particulier par rapport à d’autres, la pertinence d’un élément de contexte par rapport à une application peut être totalement différente entre un utilisateur et un autre. Même si l’échantillon utilisé pour la 2ème expérience ne comportait que des individus ayant un même profil (que des jeunes entre 20 et 25 ans, étudiants dans une même formation, particulièrement sensibilisés aux nouvelles technologies), ils ont présenté des comportements très distincts entre eux, et très souvent, distincts aussi de l’utilisateur ayant réalisé la 1ère expérience. La pertinence de localisation dans les services invoqués illustre bien cette différence : alors que la localisation permet de caractériser un bon nombre d’applications dans le cadre de la 1ère expérience, celle-ci paraît nettement moins pertinente pour les utilisateurs dans la seconde expérience.
Dans ces conditions, on peut alors se demander quelle pourrait être la pertinence d’un tel modèle générique. L’exemple des certains détecteurs de mouvement, comme les objets connectés commercialisés par Withings22, illustre bien ce cas : dans le modèle Pulse de Withings, le comptage de pas et de la distance parcourue peut s’avérer très différent (et pas forcément adapté à la réalité) en fonction de la taille de l’utilisateur et de sa foulée. On a observé, dans ce modèle, qu’une personne de plus petite stature avait systématiquement moins de pas au compteur qu’une personne de plus grande stature, alors que dans la réalité, c’était souvent l’inverse qui se passait. L’application d’algorithmes d’apprentissage comme le suggère [148, 271] semble alors inévitable, surtout ceux d’apprentissage non-supervisée. L’essor des techniques de Machine Learning [156], et notamment de Deep Learning, ouvre des nouvelles possibilités, même si ces techniques demeurent sensibles à la question de l’hétérogénéité des données ou de leur prétraitement/training, entre autres.
A partir de ces constats réalisés au cours de ces travaux, nous avons voulu analyser à quel point les difficultés que nous avons rencontrées avec l’application de l’ACF pouvaient également survenir lors de l’usage d’autres méthodes de Machine Learning. Ainsi, en 2019-2020, un travail de collaboration [23] a été mis en place visant étudier l’usage de techniques de Machine Learning (ML) avec des données de contexte. A travers une étude de la littérature sur différents domaines (notamment l’Informatique Pervasive, l’IoT et le Machine Learning), nous avons analysé comment les approches de ML sont utilisées pour la fouille de contexte et les conditions nécessaires pour que cette analyse puisse tenir compte des particularités propres aux informations de contexte. Combinant des mots clés tels que « context prediction », « context awareness », « machine learning », « data mining » ou encore « IoT », nous avons identifié 200 articles, dont 30 (tous postérieurs à 2013 et la moitié après 2016) ont été analysés en détail. Cette étude [23] nous a permis de souligner que plusieurs caractéristiques propres aux informations de contexte pouvaient impacter l’usage de techniques de ML. Tout d’abord, plusieurs auteurs, tels que [91, 207], reconnaissent l’importance de la qualité des données pour la réussite de ces techniques. Or les données de contexte sont, par définition, hétérogènes et incertaines [256, 52, 103]. Souvent issues de capteurs, ces données peuvent être erronées, disperses et incomplètes, ce qui peut avoir un impact négatif sur le temps d’exécution, la complexité ou même la qualité des modèles générés par le ML. De même, certaines techniques de ML vont demander une distribution plutôt équilibrée des données dans les classes disponibles, ce qui peut aussi poser
84 problème lors qu’on considère des données de contexte, dont une telle distribution n’est pas toujours possible, notamment en fonction du caractère dynamique et incertain de ces informations.
Tous ces problèmes liés à la qualité des données sont généralement traités par les différentes approches de Machine Learning dans leur phase de prétraitement (p.ex. [9,153]). En effet, l’étude que nous avons menée [23] a présenté des indices indiquant que les approches de ML reposent très fortement dans les phases de prétraitement. Nous avons également observé que ces approches considèrent le plus souvent les informations de contexte comme une donnée ordinaire, sans vraiment tenir compte des spécificités propres à la notion de contexte, reconnues par la littérature [52, 24, 103], comme l’extrême hétérogénéité, la dynamicité, l’incomplétude et son caractère incertain.
Ces limitations, que nous avons également observés lors de l’application de l’ACF, interrogent sur une possible généralisation de l’usage des techniques de ML pour la fouille de contexte à grande échelle, c.a.d. à l’échelle de tout un Système d’Information (SI). En effet, dans [23], nous avons soutenu une vision d’une « context mining facility », autrement dit, de la fouille de contexte comme un service proposé par un SI à toutes ses applications. Les informations de contexte sont aujourd’hui de plus en plus faciles à capturer. Elles ouvrent des multiples opportunités d’usage au sein des SI (adaptation au contexte, recommandation de services ou de contenu, prédiction / anticipation de besoins ou des actions des utilisateurs, prise de décision, etc.). On peut donc envisager la généralisation de ces comportements qu’on pourrait qualifier de « smart » ou « intelligent », en proposant le support à la fouille de contexte comme un service propre à un SI.
Or la clé de voûte de cette vision repose sur la possibilité d’offrir des mécanismes de raisonnement à l’échelle de tout un système pouvant ainsi évoluer avec celui-ci et exécuter de manière continue (pour être disponible à toutes les applications à tout moment), avec un minimum d’intervention humaine [23]. Ce changement d’échelle a un fort impact sur les mécanismes de ML et sur la gestion de contexte de manière générale : au lieu de penser ce support pour des applications précises, avec des objectifs et des données précis, il faut le penser pour tout un système, avec son écosystème d’utilisateurs (décideurs, employés, clients…) et d’applications supportant les différents processus et corps de métiers qui cohabitent dans une organisation. On ne peut pas forcément choisir un sous-ensemble précis de données à observer ou des méthodes à appliquer sans risquer de pénaliser les futures