Réduction de l’espace de recherche de règles : réduc- réduc-tion de la fenêtre de mots autour du terme cible à laréduc-tion de la fenêtre de mots autour du terme cible à la

phrase

Afin de sélectionner la règle la plus performante, un algorithme d’apprentissage de règles doit d’abord tester et comparer un ensemble de règles qui constitue son espace de recherche de règles. Nous avons remarqué que la plupart des algorithmes d’apprentissage de règles d’EI comme (LP)2 et WHISK considèrent une fenêtre de mots autour du terme cible comme contexte d’apprentissage. Ce contexte est fixé à l’avance par l’utilisateur. Pour l’algorithme WHISKR par exemple, ce contexte est fixé par défaut à 5. Autrement dit, l’algorithme considère les 5 mots qui précèdent et les 5 mots qui suivent le terme cible lors de la création de l’ensemble des règles à tester.

Prenons un exemple concret. Considérons l’extrait de texte de la figure 6.8. En supposant que la règle la plus générale retenue par l’algorithme WHISKR

104^{Chapitre 6. Proposition : une approche interactive d’apprentissage}de règles d’extraction d’information

Figure 6.8 – Extrait du corpus BB BioNLP-ST 2013. est

Token{->MARKONCE(Habitat)};

les règles testées qui étendent cette règle pour essayer d’extraire le premier terme

intracellular sont représentées dans les figures 6.9, 6.10 et 6.11. Pour des questions

de simplicité, nous ne considérons pas dans cet exemple les règles qui s’appuient sur les termes mais uniquement celles qui s’appuient sur les Tokens. L’ensemble des règles testées peut être divisé en trois sous ensembles : l’ensemble des règles qui décrivent la cible (figure 6.9), l’ensemble des règles qui décrivent le contexte gauche de la cible (figure 6.10) et l’ensemble des règles qui décrivent le contexte droit de la cible (figure 6.11).

- Token{REGEXP("intracellular")->MARKONCE(Habitat)};

- Token{FEATURE("lemma", "intracellular")->MARKONCE(Habitat)}; - Token{FEATURE("postag", "JJ")->MARKONCE(Habitat)};

Figure 6.9 – Règles qui décrivent la cible.

Supposons que a est le nombre d’attributs ou propriétés (expression exacte, lemme, étiquette morpho-syntaxique) à considérer pour un mot du texte et c est le nombre de mots à considérer à gauche et à droite du terme cible. Dans notre exemple, a vaut 3 car nous évaluons à la fois les règles qui s’appuient sur les expres-sions exactes des mots, celles qui s’appuient sur leurs lemmes et celles qui s’appuient sur leurs étiquettes morpho-syntaxiques et c vaut 5 car l’algorithme WHISKR consi-dère, par défaut, 5 mots de part et d’autre du terme cible.

Le terme cible étant composé d’un seul mot dans notre exemple, il y a donc 3 (a) règles qui le décrivent. Concernant les règles de contexte gauche et les règles de contexte droit, en plus des règles les plus génériques (au nombre de 2), il y a a règles pour chaque mot de contexte (c mots). Il y a donc 2 + a ú c = 17 règles à tester pour chacun des contextes gauche et droit.

6.4. Stratégies proposées pour la construction de l’ensemble des

règles 105

- Token # Token{->MARKONCE(Habitat)};

- Token{REGEXP("to")} # Token{->MARKONCE(Habitat)};

- Token{FEATURE("lemma", "to")} # Token{->MARKONCE(Habitat)}; - Token{FEATURE("postag", "TO")} # Token{->MARKONCE(Habitat)}; - Token{REGEXP("mechanisms")} # Token{->MARKONCE(Habitat)};

- Token{FEATURE("lemma", "mechanism")} # Token{->MARKONCE(Habitat)}; - Token{FEATURE("postag", "NN")} # Token{->MARKONCE(Habitat)};

- Token{REGEXP("find")} # Token{->MARKONCE(Habitat)};

- Token{FEATURE("lemma", "find")} # Token{->MARKONCE(Habitat)}; - Token{FEATURE("postag", "VBP")} # Token{->MARKONCE(Habitat)}; - Token{REGEXP("in")} # Token{->MARKONCE(Habitat)};

- Token{FEATURE("lemma", "in")} # Token{->MARKONCE(Habitat)}; - Token{FEATURE("postag", "IN")} # Token{->MARKONCE(Habitat)}; - Token Token{->MARKONCE(Habitat)};

- Token{REGEXP("other")} Token{->MARKONCE(Habitat)};

- Token{FEATURE("lemma", "other")} Token{->MARKONCE(Habitat)}; - Token{FEATURE("postag", "JJ")} Token{->MARKONCE(Habitat)};

Figure 6.10 – Règles qui décrivent le contexte gauche de la cible.

- Token{->MARKONCE(Habitat)} Token;

- Token{->MARKONCE(Habitat)} Token{REGEXP("bacteria")};

- Token{->MARKONCE(Habitat)} Token{FEATURE("lemma", "bacterium")}; - Token{->MARKONCE(Habitat)} Token{FEATURE("postag", "NN")}; - Token{->MARKONCE(Habitat)} # Token; - Token{->MARKONCE(Habitat)} # Token{REGEXP(".")}; - Token{->MARKONCE(Habitat)} # Token{FEATURE("lemma", ".")}; - Token{->MARKONCE(Habitat)} # Token{FEATURE("postag", ".")}; - Token{->MARKONCE(Habitat)} # Token{REGEXP("This")};

- Token{->MARKONCE(Habitat)} # Token{FEATURE("lemma", "this")}; - Token{->MARKONCE(Habitat)} # Token{FEATURE("postag", "DT")}; - Token{->MARKONCE(Habitat)} # Token{REGEXP("will")};

- Token{->MARKONCE(Habitat)} # Token{FEATURE("lemma", "will")}; - Token{->MARKONCE(Habitat)} # Token{FEATURE("postag", "MD")}; - Token{->MARKONCE(Habitat)} # Token{REGEXP("ultimately")};

- Token{->MARKONCE(Habitat)} # Token{FEATURE("lemma", "ultimate")}; - Token{->MARKONCE(Habitat)} # Token{FEATURE("postag", "RB")};

106^{Chapitre 6. Proposition : une approche interactive d’apprentissage}de règles d’extraction d’information Lors de la construction de son espace de règles, l’algorithme WHISKR considère une fenêtre de mots autour du terme cible indépendamment des limites de la phrase. La question que nous nous sommes donc posée est : est-il vraiment utile de sortir des limites de la phrase ? Plusieurs travaux dans la littérature se sont intéressés à la taille optimale de la fenêtre de contexte à considérer quand on cherche à désambiguïser un mot polysémique ou à mesurer une similarité distributionnelle. Plusieurs d’entre eux encouragent l’utilisation de contextes locaux courts (1 à 3 mots de part et d’autre du terme ou mot cible) (Choueka & Lusignan, 1985 ; Yarowsky, 1993) et certains recommandent de ne pas sortir de la phrase (Audibert, 2003). Nous trouvons plus prudent d’arrêter le contexte aux frontières de la phrase car les corpus de travail peuvent être construits de manière à supprimer ou déplacer certaines parties. Dans ce cas, sortir des limites des phrases peut impliquer l’utilisation d’informations de voisinage entre des phrases qui ne sont pas voisines à la base.

Nous décidons, par conséquent, d’utiliser les mots de la phrase apparaissant de part et d’autre du terme cible comme contexte à condition de ne pas dépasser 5 mots de chaque côté. Quand les phrases sont longues, l’algorithme d’apprentissage aura au pire le même nombre de règles à tester. Sur notre exemple, l’ensemble des règles de contexte droit se réduirait à l’ensemble présenté dans la figure 6.12.

- Token{->MARKONCE(Habitat)} Token;

- Token{->MARKONCE(Habitat)} Token{REGEXP("bacteria")};

- Token{->MARKONCE(Habitat)} Token{FEATURE("lemma", "bacterium")}; - Token{->MARKONCE(Habitat)} Token{FEATURE("postag", "NN")};

- Token{->MARKONCE(Habitat)} # Token;

- Token{->MARKONCE(Habitat)} # Token{REGEXP(".")};

- Token{->MARKONCE(Habitat)} # Token{FEATURE("lemma", ".")}; - Token{->MARKONCE(Habitat)} # Token{FEATURE("postag", ".")};

Figure 6.12 – Règles qui décrivent le contexte droit de la cible sans sortir des limites de la phrase.

3 mots ont été supprimés du contexte droit du terme cible. Par conséquent, 9 (3 ú a) règles ont été supprimées en total.

L’expérience décrite dans la section 8.3 montre que la réduction de la fenêtre de contexte autour du terme cible à la phrase permet de réduire le temps d’apprentis-sage.