Expérience 2 : écriture de règles

Dans un système interactif d’apprentissage de règles d’EI, l’utilisateur est amené à écrire des règles pour deux buts différents :

— Chercher des exemples dans le texte. On parle, dans ce cas, de règles pros-pectives.

— Enrichir ou modifier l’ensemble de règles. Les règles écrites, dans ce cas, par l’utilisateur sont jugées assez pertinentes par ce dernier et souhaite que le module d’apprentissage les conserve si elles font leurs preuves ou les améliore sans pour autant les supprimer si elles font des erreurs.

Nous nous intéressons bien évidemment, dans cette section, au deuxième type de règles.

Description

Le test que nous effectuons dans le cadre de cette expérience consiste à deman-der à un utilisateur qui a un minimum de connaissances en termes de biotopes de bactéries, d’énoncer des règles qui lui semblent évidentes que nous traduisons en

8.5. Etude expérimentale de la stabilité des règles 173 langage Ruta. Pour imposer le moins possible de contraintes, nous avons donné la li-berté à l’utilisateur d’utiliser n’importe quelles formes de mots (expressions exactes, lemmes, étiquettes morpho-syntaxiques).

Nous vérifions par la suite l’existence de ces règles ou de versions modifiées de ces règles dans l’ensemble des règles inférées par l’algorithme WHISKMotLemPos.

Résultats

En consultant de manière non approfondie quelques textes du corpus BB BioNLP-ST 2013, l’utilisateur énonce des règles dont quelques unes sont traduites par :

1-Token{FEATURE("lemma", "tsetse")} Token{FEATURE("lemma", "fly") ->MARKONCE(Habitat,1,2)};

2-Token{FEATURE("lemma", "insect")->MARKONCE(Habitat)}; 3-Token{FEATURE("lemma", "intestine")->MARKONCE(Habitat)}; 4-Token{FEATURE("lemma", "animal")->MARKONCE(Habitat)}; 5-Token{FEATURE("lemma", "human")->MARKONCE(Habitat)};

Ces règles ont du sens car quand on parle de mouches, d’insectes, d’animaux, d’intestins ou d’humains dans des textes qui parlent de biotopes de bactéries, c’est généralement pour faire référence à des hotes potentiels ou des lieux de prolifération de bactéries. Nous remarquons également que les règles que les utilisateurs ont ten-dance à écrire sont généralement des règles génériques car ils ont tenten-dance à penser au cas général et non aux cas particuliers qui sont plus rares dans des textes de domaine.

La figure 8.17 montre l’ensemble de règles produites par WHISKMotLemPos en apprenant sur l’ensemble du corpus.

Concernant la première règle de l’utilisateur, nous remarquons qu’il existe une règle plus spécifique que cette dernière dans cet ensemble et qui est la suivante :

Token{REGEXP("bacteria")} # Token{FEATURE("lemma", "tsetse") ->MARKONCE(Habitat, 3, 4)} Token{FEATURE("lemma", "fly")};

En effet, la règle de l’utilisateur n’a pas été gardée telle quelle car elle fait des erreurs. Elle permet, par exemple, d’annoter tsetse fly dans le terme blood-sucking

tsetse fly qui figure dans le texte présenté dans la figure 8.18 comme exemple positf

alors que c’est le terme en entier qui doit être annoté comme exemple positif. D’où l’inférence d’une règle plus spécifique. D’autres règles, en revanche, ont été inférées pour couvrir d’autres exemples relatifs aux tsetse flies auxquels il n’est pas intuitif de penser comme tsetse host cell, tsetse midgut, tsetse midgut and haemolymph, tsetse

immune system, gut of the tsetse fly ou encore les termes tsetse et fly utilisés parfois

seuls.

La deuxième règle de l’utilisateur est générique et fait des erreurs comme par exemple la couverture du terme insects dans dead insects ou le terme insect dans

haemolymph of the insect. Ces termes complexes doivent, en effet, être annotés en

entier comme des exemples positifs. La règle de l’utilisateur a donc été remplacée dans l’ensemble des règles apprises par WHISKMotLemPos par les règles suivantes :

174 Chapitre 8. Expérimentations

Figure 8.17 – Règles produites par WHISKMotLemPos en apprenant sur l’ensemble du corpus.

8.5. Etude expérimentale de la stabilité des règles 175 Figure 8.18 – Texte 4. 1-Token{REGEXP("insect")->MARKONCE(Habitat)}; 2-Token{FEATURE("lemma","insect")->MARKONCE(Habitat)} # Token{FEATURE("lemma","human")}; 3-Token{FEATURE("lemma","insect")->MARKONCE(Habitat)} # Token{REGEXP("In")};

La première règle permet de couvrir tous les mots insect au singulier car il n’y a pas d’erreurs sur ces mots. Les deuxième et troisième règles sont des versions plus spécifiques de la règle de l’utilisateur qui ne couvrent pas les erreurs faites par cette dernière. D’autres règles qui couvrent des termes complexes relatifs aux insectes ont été apprises à part.

La troisième règle de l’utilisateur a également remplacée par une règle plus spé-cifique qui fait moins d’erreurs et qui est la suivante :

Token{FEATURE("lemma","intestine")->MARKONCE(Habitat)} # Token{FEATURE("lemma","many")};

Pour couvrir des termes plus complexes comme animal intestines ou small

intes-tines qui font partie des exemples que l’utilisateur cherche à couvrir, d’autres règles

ont été inférées.

1-Token{FEATURE("lemma","animal")->MARKONCE(Habitat)} # Token{FEATURE("lemma","death")};

2-Token{REGEXP("bacteria")} # Token{FEATURE("lemma","animal") ->MARKONCE(Habitat)};

176 Chapitre 8. Expérimentations

3-Token{FEATURE("postag","DT")} # Token{REGEXP("animal") ->MARKONCE(Habitat)};

4-Token{FEATURE("lemma", ",")} # Token{FEATURE("lemma", "animal") ->MARKONCE(Habitat)} # Token{FEATURE("lemma", "find")};

5-Token{FEATURE("lemma","animal")->MARKONCE(Habitat)} # Token{REGEXP("diseases")};

6-Token{FEATURE("lemma", "for")} # Token{FEATURE("lemma", "animal") ->MARKONCE(Habitat)} # Token{FEATURE("lemma", "strain")};

7-Token{FEATURE("lemma","plant")} # Token{FEATURE("lemma","animal") ->MARKONCE(Habitat)}; 8-Token{FEATURE("lemma","into")} # Token{FEATURE("lemma","animal") ->MARKONCE(Habitat)}; 9-Token{REGEXP("tract")} # Token{FEATURE("lemma","animal") ->MARKONCE(Habitat)}; 10-Token{FEATURE("lemma",",")} # Token{FEATURE("lemma","animal") ->MARKONCE(Habitat)} # Token{FEATURE("lemma","have")} # Token{FEATURE("lemma","in")};

Le terme animal est un terme très fréquent dans le corpus. Il est aussi bien utilisé dans des termes simples (animal, animals) que dans des termes complexes (animal intestines, respiratory tract of animals, intestinal tract of animals, etc.). Dans un corpus beaucoup plus volumineux, la règle de l’utilisateur aurait été gardée comme telle car le nombre d’erreurs qu’elle ferait serait négligeable devant le nombre d’exemples positifs qu’elle couvre. Seulement, dans notre corpus cette règles fait beaucoup d’erreurs. Le nombre élevé des versions spécifiques de cette règle apprises par WHISKMotLemPos s’explique par les différentes manières d’emploi du terme et l’absence d’un contexte commun à ces emplois.

Nous remarquons que la cinquième règle de l’utilisateur a été gardée comme telle. En effet, malgré les erreurs que cette règle fait, c’est négligeable devant les exemples positifs qu’elle couvre (3 négatifs pour 95 positifs) sachant que l’algorithme WHISKMotLemPos tel que nous l’avons paramétré autorise 1 négatif pour 20 positifs. Pour conclure, nous remarquons qu’aucune des règles de l’utilisateur n’a été ignorée. Elles ont été soit gardées comme telles soient améliorées en en créant des versions plus spécifiques et plus précises.

Nous pouvons constater, d’après les deux expériences réalisées, que la stabilité des règles est intrinsèquement assurée par l’algorithme WHISK que ce soit dans le cas où l’utilisateur ajoute de nouveaux exemples ou dans le cas où il introduit des règles. Nous pensons que cette stabilité est due aux facteurs suivants :

— L’algorithme WHISKMotLemPosfavorise les règles qui couvrent le plus d’exemples positifs. Dans le cadre de cette politique, pour chaque nouvel exemple intro-duit, l’algorithme essaie de le couvrir en favorisant les règles qui couvrent également d’autres exemples. Par conséquent, si cet exemple ressemble à des exemples déjà couverts, il risque d’apprendre la même règle qui couvrait ces derniers ou une version un peu plus spécifique mais pas complètement diffé-rente. Si, en revanche, le nouvel exemple ne ressemble à aucun autre exemple couvert, l’algorithme apprend une nouvelle règle qui couvre uniquement cet exemple.

8.5. Etude expérimentale de la stabilité des règles 177 — De la même manière que l’algorithme WHISK, l’utilisateur, par son esprit synthétique, essaie d’introduire des règles qui couvrent beaucoup d’exemples positifs et non un seul exemple particulier. C’est la raison pour laquelle ses règles s’expriment d’une manière très proche pour ne pas dire similaire à celle des règles apprises.

Conclusion

Nous avons présenté dans ce chapitre une étude expérimentale (sur les corpus BioNLP-ST 2013 et SyntSem) qui a pour but d’évaluer les différentes propositions détaillées dans les deux chapitres précédents. Une étude de différentes combinai-sons d’informations linguistiques utilisées dans l’expression des règles inférées par nos différentes versions étendues de WHISKR ont permis d’évaluer l’impact de ces informations sur les performances des règles et sur leur nombre. En effet, l’utilisa-tion de l’expression exacte des mots dans les règles (WHISKMot) a permis d’obtenir les meilleures valeurs de précision alors que l’utilisation à la fois des lemmes et des étiquettes morpho-syntaxiques (WHISKLemPos) a permis d’obtenir les meilleures valeurs de rappel ainsi que le nombre le plus réduit de règles. L’utilisation de la stratégie d’apprentissage sur un corpus réduit a permis non seulement la non discri-mination des exemples positifs non encore annotés par l’utilisateur à une itération donnée mais aussi un gain considérable dans le temps d’apprentissage. Le module d’apprentissage actif proposé (IAL4Sets) a également permis d’améliorer significati-vement les performances du module d’apprentissage de base de l’algorithme WHISK grâce à l’introduction de la notion de similarité distributionnelle qui permet de pro-poser à l’utilisateur des exemples sémantiquement proches des exemples positifs déjà couverts. Même si nous n’avons pas fait de propositions pour assurer la stabilité de l’ensemble des règles, nous avons montré expérimentalement dans ce chapitre que ni l’ajout de nouveaux exemples ni l’écriture de nouvelles règles ne cause des modifi-cations majeures sur les règles. Ceci est essentiellement dû à la stabilité intrinsèque de l’algorithme WHISK.

Chapitre 9