Adaptation aux changements de concepts

80 90 100 Nombre de données T aux de reconnaissance (%) Evolve Evolve infinity

(a) Base de données LaViola.

0 2000 4000 6000 8000 10000 12000 70 75 80 85 90 95 100 Nombre de données T aux de reconnaissance (%) Evolve Evolve infinity

(b) Base de données NicIcon.

0 2000 4000 6000 8000 70 75 80 85 90 95 100 Nombre de données T aux de reconnaissance (%) Evolve Evolve infinity

(c) Base de données Japanese-Vowels (UCI).

0 2000 4000 6000 8000 70 75 80 85 90 95 100 Nombre de données T aux de reconnaissance (%) Evolve Evolve infinity

(d) Base de données Pen-Digits (UCI). Figure 7.9 – Inertie du système lors de l’ajout de 30% des classes après l’apprentissage de 50% des données de la base de données. L’intégration d’oubli dans le processus d’apprentissage d’Evolve ∞ lui permet d’être réactif même après une longue période d’apprentissage. La différence de performance lorsque l’environnement est stationnaire reste minime.

7.5 Adaptation aux changements de concepts

Cette section présente les résultats expérimentaux obtenus avec Evolve ∞ lors de l’ap-parition de changements de concepts. Nous allons voir le comportement d’Evolve ∞ lors de l’évolution progressive des concepts appris. Nous allons en particulier montrer le peu d’impact de la taille de la fenêtre utilisée par l’algorithme d’oubli directionnel différé, contrairement au cas du désapprentissage. Enfin, la nécessité de l’utilisation d’oubli sera mise en évidence lors de la présence de changements de concepts brusques.

Pour évaluer la capacité d’Evolve ∞ à suivre les changements de concepts, nous avons utilisé la bases de données ILGDB, avec le jeu de caractéristiques HBF49 (voir section 7.2). Nous avons ensuite mis les données des différents scripteurs à la suite. De cette manière, nous obtenons un flux de données de plus grande taille, et avec des changements de concepts à chaque changement de scripteur.

Chapitre 7. Évaluation du classifieur évolutif en-ligne Evolve ∞ 139

En utilisant les scripteurs du groupe 3, dont le jeu de symboles était imposé, les change-ments de concepts entre les scripteurs sont légers, car ils sont seulement dûs aux différences de style d’écriture. En utilisant les scripteurs du groupe 1, qui ont choisi librement leur jeu de symboles, les changements de concepts sont alors très abrupts, car les symboles associés à chaque classe changent complètement lors des changements de scripteur.

7.5.1 Changements de concepts progressifs

Nous avons testé Evolve ∞ sur un scénario simulant des changements de concepts pro-gressifs, en utilisant les 11 scripteurs du groupe 3 d’ILGDB, dont les jeux de symboles sont identiques. Nous avons mis ces 11 scripteurs à la suite, ce qui crée des légers change-ments de concepts lors du passage du style d’écriture d’un scripteur à celui du suivant. La figure 7.10 présente les résultats moyens sur 30 ordres des scripteurs différents.

En présentant les 11 scripteurs du groupe 3 à la suite, les scripteurs et leur style d’écriture changent, mais le jeu de symboles reste constant. Ce scenario de test est ainsi légèrement changeant, mais ne nécessite pas forcement l’utilisation d’oubli. Le système de référence Evolve obtient de bons résultats, même sans oubli. Les changements de concepts ne suivent pas une évolution logique, mais alternent entre les styles des différents scripteurs, dont certains se ressemblent. Sans oubli, le système apprend de tous les scripteurs et construit un modèle multi-scripteurs qui lui permet d’obtenir de bonnes performances dans ce scénario où l’évolution est aléatoire.

Evolve ∞ obtient quant à lui un taux de reconnaissance très proche de celui d’Evolve. L’intégration d’oubli dans le processus d’apprentissage permet de maintenir un système quasiment mono-scripteur. Evolve ∞ est alors limité par le petit nombre de données d’ap-prentissage disponible pour chaque scripteur, mais obtient néanmoins de bon résultats.

L’oubli limite ici le poids des anciennes données, ce qui permet de conserver la connais-sance préalablement acquise jusqu’à ce qu’elle soit remplacée. Cela permet au système de suivre les changements de concepts, mais ce n’est pas plus intéressant que de construire un modèle multi-scripteurs dans ce scénario où les changements de concepts ne suivent pas une progression logique.

7.5.2 Impact de la longueur de la fenêtre

Le choix de la longueur de la fenêtre glissante utilisée par l’algorithme d’oubli direc-tionnel différé DDF, qui est utilisé pour l’apprentissage décrémental des conclusions, est sujet au compromis précision/réactivité. De la même manière, le choix du facteur d’oubli utilisé pour la mise à jour des prémisses implique une fenêtre de données implicite, et est sujet au même compromis précision/réactivité.

Plus la fenêtre est longue, meilleure est la précision du système car plus le système a de données à sa disposition pour optimiser son modèle de connaissance. En revanche, ce plus grand nombre de données crée de l’inertie qui réduit la réactivité du système en cas d’ajout de classes ou de changements de concepts. Inversement, plus la fenêtre est courte, meilleure est la réactivité du système car les nouvelles données ont un poids plus important dans le processus d’optimisation du modèle de connaissance. Par contre, une petite fenêtre peut

0 500 1000 1500 2000 75 80 85 90 95 100 Nombre de données T aux de reconnaissance (%) Evolve Evolve infinity

Figure 7.10 – Base de données ILGDB groupe 3 (symboles imposés) – Adaptation aux changements de concepts légers créés par les changements de style d’écriture entre les différents scripteurs. L’utilisation d’oubli dans Evolve ∞ fait que son modèle est mono-utilisateur, mais cela ne l’empêche pas d’obtenir d’aussi bonnes performances qu’Evolve qui construit un modèle multi-utilisateur.

limiter les performances du classifieur lorsque l’environnement est stationnaire, et qu’il dispose d’un nombre insuffisant d’exemples pour construire un modèle de connaissance suffisamment précis.

Dans le contexte applicatif des commandes gestuelles, l’environnement est intrinsè-quement dynamique, mais il ne faut pas pour autant limiter la précision du modèle de connaissance que construit le classifieur. Il faut donc limiter le poids des anciennes don-nées, pour améliorer les performances en environnement dynamique, mais sans dégrader les performances en environnement stationnaire. C’est pourquoi nous choisissons une longueur de fenêtre suffisamment grande pour ne pas limiter la précision du modèle de connaissance du classifieur. Même une taille de fenêtre plus grande que nécessaire est quand même suf-fisante pour maintenir le caractère évolutif du classifieur. Le principal inconvénient d’une fenêtre trop grande est la nécessité de mémoriser plus d’exemples qu’il n’est obligatoire. En pratique nous utilisons une taille de fenêtre choisie empiriquement de dix fois le nombre de classes.

La figure 7.11 montre l’impact de la longueur de la fenêtre de l’algorithme d’oubli d’Evolve ∞ sur ses performances en environnement stationnaire.

Chapitre 7. Évaluation du classifieur évolutif en-ligne Evolve ∞ 141 0 500 1000 1500 2000 75 80 85 90 95 100 Nombre de données T aux de reconnaissance (%) Evolve Evolve infinite

Figure 7.11 – Base de données ILGDB groupe 3 (symboles imposés) – Impact de la longueur de la fenêtre de l’algorithme d’oubli d’Evolve ∞ sur les performances, et comparaison à l’impact de la taille de la fenêtre en cas de désapprentissage (Evolve Unlearning)). La taille de fenêtre est indiquée en nombre d’exemples par classe.

7.5.3 Changements de concepts brusques

Nous avons également testé Evolve ∞ dans un scénario simulant des changements de concepts abrupts. Pour cela, nous avons utilisé les 21 scripteurs du groupe 1 d’ILGDB dont les jeux de symboles sont différents. En mettant ces 21 scripteurs à la suite, nous avons simulé des changements de concepts brusques car les symboles associés à chaque classe changent complètement à chaque changement d’utilisateur. La figure 7.12 présente les résultats moyens sur 30 ordres de présentation des scripteurs différents.

Ce scénario de test est très difficile car les symboles associés à toutes les classes changent complètement d’un scripteur à l’autre. Par conséquent, le taux de reconnaissance s’effondre à chaque changement de scripteur. Nous nous intéressons ici à la capacité du système à évoluer pour s’adapter aux nouvelles données, et à remonter son taux de reconnaissance entre les changements de concepts. L’utilisation d’oubli est donc indispensable dans ce scénario fortement dynamique.

Les résultats obtenus pour ce scénario sont très contrastés. Sans capacité d’oubli, Evolve n’est pas capable d’adapter son modèle aux changements du flux de données et finit avec un taux de reconnaissance maximum qui ne dépasse plus 50% (courbe rouge). Evolve ∞ parvient à maintenir de bonnes performances maximales (courbe verte), malgré la diffi-culté du scénario, en faisant remonter son taux de reconnaissance au dessus de 90% à la

0 500 1000 1500 2000 2500 3000 40 60 80 100 Nombre de données T aux de reconnaissance (%) Evolve Evolve infinity

Evolve (taux max) Evolve infinity (taux max)

Figure 7.12 – Base de données ILGDB groupe 1 (symboles différents) – Adaptation aux changements de concepts abrupts créés par les changements de jeu de symboles entre les différents scripteurs. L’utilisation d’oubli est ici fondamentale pour oublier les données lorsqu’elles deviennent obsolètes. Evolve ∞ conserve de bonnes performances maximales (courbe verte) alors que celles d’Evolve s’effondrent (courbe rouge), car il n’est pas possible de construire un modèle multi-utilisateur avec des jeux de symboles différents.

fin des données de presque tous les scripteurs. L’intégration d’oubli dans le processus d’ap-prentissage permet à Evolve ∞ d’oublier les données obsolètes après les changements de concepts, pour reconstruire son modèle de connaissance sur le nouveau jeu de symboles du nouveau scripteur. Evolve ∞ conserve ainsi un modèle mono-utilisateur, contrairement à Evolve qui ne peut que construire un modèle multi-utilisateur qui regroupe alors des jeux de symboles différents. Maintenir un modèle mono-utilisateur, et donc l’utilisation d’oubli, est indispensable dans ce scénario fortement dynamique.