• Aucun résultat trouvé

Reconnaissance d’Entités Nommées

La configuration découlant de l’approche proposée ici pour l’identification automatique d’entités implique qu’un certain nombre de décisions concernant le niveau de segmentation du texte d’entrée en mentions d’entités soient reportées à l’étape de Liage. L’analyse en termes de REN est alors envisagée sous une forme non déterministe, dans laquelle certaines ambiguïtés usuellement levées dans le résultat final des systèmes de REN sont maintenues.

Des résultats de cette forme peuvent être obtenus par l’utilisation d’un système formalisant de façon inhérente ou indirecte l’ambiguïté, ou par l’emploi combiné de plusieurs systèmes. Leurs sorties sont dans ce cas regroupées par les opérations d’union — tous les résultats étant alors considérés — ou d’intersection — seuls les résultats commun aux différents systèmes sont pris en compte dans la suite des traitements. L’intersection peut ici être envisagé comme un premier filtrage de faux positifs, le consensus de plusieurs procédures distinctes étant vu en relation avec la probabilité de correction du résultat en question.

Le choix des systèmes adoptés repose également sur leur caractère libre et disponible, en association avec les possibilités d’adaptation qu’ils présentent en termes de paramétrage et de configuration relativement à un cadre applicatif déterminé.

Les deux systèmes faisant l’objet d’une intégration au module de reconnaissance pour la tâche d’identification répondent à ces critères, l’un faisant usage de techniques symboliques, l’autre reposant sur des techniques numériques et d’apprentissage automatique. Ces deux orientations sont considérées comme performantes dans le cadre de la REN, les approches symboliques faisant montre d’une plus grande efficacité en termes de précision, à l’inverse des approches numériques qui s’avèrent plus robustes relativement à des données bruitées et meilleures en termes de rappel, comme cela nous l’avons souligné dans [BSS11].

3.1.1 SxPipe/NP

Le premier système intégré au module de reconnaissance, SxPipe/NP, repose sur une approche symbolique de la REN et fait partie de la chaîne d’analyse linguistique de surface SxPipe8. L’ana-

8. SxPipe, comme l’ensemble des outils développés dans le cadre de la chaîne de traitement linguistique de l’équipe-projet Alpage, est disponible sous licence Cecill-C, compatible avec LGPL et accessible via le projet lingwb

3. Ressources : Outils 179 lyse de données par SxPipe vise les corpus textuels bruts, dans l’objectif d’un prétraitement utile à des modules d’analyse plus profonde tels que les analyseurs syntaxiques. Les principes, l’archi- tecture ainsi que le fonctionnement de SxPipe sont décrits par Sagot et Boullier [SB08]. La chaîne SxPipe est de type modulaire et présente trois aspects principaux de traitement des données textuelles : segmentation en phrases et mots, correction orthographique et reconnaissance d’en- tités nommées, celles-ci étant entendues en un sens très large (dates, heures, quantités, adresses email et URL, etc.). La modularité de SxPipe correspond à l’application séquentielle de traitements à plusieurs niveaux, les décisions prises par chaque module pouvant affecter les suivants. Afin d’éviter des analyses erronées pouvant se propager à l’ensemble de la chaîne, plusieurs modules, dont le module de REN, sont capables de produire des sorties ambigues, ainsi que de lire des entrées du même type.

Les trois aspects de traitement pris en charge par SxPipe se traduisent par les groupes de modules correspondant :

• Un premier ensemble de modules transforme l’entrée sous forme textuelle en flux de tokens, ceux-ci étant définis comme des séquences de caractères séparés des autres par l’espace ou un signe de ponctuation ; cette segmentation, qui concerne également les frontières de phrases, attribue à chaque token un identifiant de position unique et est déterministe. Cette première phase de traitement est également chargée de la reconnaissance des entités nommées entendues au sens large et dont les caractéristiques peuvent être définies au niveau des caractères ; il s’agit notamment des URL, adresses postales et électroniques, dates, horaires, nombres, etc.

• Le flux de tokens issu de la segmentation est transformé en graphe de formes, celles-ci étant définies comme des unités linguistiques syntaxiquement atomiques ou élémentaires, c’est-à- dire non analysables syntaxiquement ; la définition des formes, complexe et discutable selon les contextes, peut être ramenée par convention à un critère de présence ou d’absence de l’unité considérée dans une ressource lexicale de référence pour la question. Les formes sont simples ou composées selon qu’elles correspondent à un token unique ou à plusieurs tokens, respectivement. Des formes spéciales peuvent être définies dès lors qu’elles ne doivent pas faire l’objet d’une analyse syntaxique ou qu’elles constituent un élément informatif en tant que telles pour l’analyse syntaxique. Le graphe produit par SxPipe, qui modélise les ambiguïtés de reconnaissance des formes composées ainsi que des formes issues de la correction orthographique, se présente sous la forme d’un DAG (directed acyclic graph, graphe orienté acyclique) de formes, qui peut être écrit en tant qu’expression régulière :

({pomme} pomme {de} de {terre cuite} terre_cuite | ({pomme de terre} pomme_de_terre | {pomme} pomme {de} de {terre} terre) {cuite} cuite)

ou sous une forme dépliée avec identification des transitions entre formes9 : ##DAG BEGIN

1 {pomme} pomme 2

1 {pomme de terre} pomme_de_terre 4

2 {de} de 3

3 {terre} terre 4

3 {terre cuite} terre_cuite 5

4 {cuite} cuite 5

##DAG END

sur INRIAGforge. Sources du projet lingwb : https://gforge.inria.fr/projects/lingwb/. Site internet : http:

//lingwb.gforge.inria.fr/.

9. Des identifiants uniques sont associés à chaque token distinct, permettant de distinguer les tokens de contenu identique. Ils ne figurent pas dans ces exemples afin d’alléger la reproduction du format.

• À partir des DAG de formes, SxPipe permet la reconnaissance de motifs définis par l’utili- sateur sous la forme de grammaires locales non contextuelles, produisant elles-mêmes des DAG de formes, possiblement ambigus. Chaque type de motifs à reconnaître fait l’objet d’un module du groupe nommé dag2dag et définit une grammaire ainsi qu’un analyseur lexical ou un lexique destinés à une analyse syntaxique réalisée par l’analyseur Syntax [BD88]. SxPipe peut être configuré, par activation et paramétrage sélectifs des modules des différents niveaux de traitement, selon les besoins particuliers au traitement d’un corpus donné, la langue concernée par les données et l’ensemble des modules de reconnaissance de motifs non contex- tuels définis. L’application de SxPipe pour une langue donnée requiert cependant l’installation du lexique Alexina correspondant10, tel que le Lefff [Sag10] pour le français.

La REN intégrée à SxPipe se présente sous la forme d’un module, nommé NP, au sein de dag2dag, autrement dit d’une grammaire locale associée à un lexique spécialisé. Celui-ci consiste en une dérivation de la base d’entités Aleda, présentée précédemment (chapitre 3, section 1.3 et infra, section 2.2), plus précisément de l’ensemble des variantes lexicales définies dans Aleda pour les entités recensées. Il s’agit donc d’un lexique typé, chaque forme étant associée à une ou plusieurs étiquettes parmi person, organization et location. Une centaine de règles, pour certaines munies d’indications de priorité, sont définies dans la grammaire et se répartissent en trois catégories :

• correspondance exacte avec un terminal typé du lexique, • indices contextuels autour d’un terminal typé du lexique,

• indices contextuels autour d’une forme non recensée dans le lexique et présentant des indices internes pertinents.

La REN fournie par NP est ainsi centrée sur les entités nommées sous la forme de noms propres en adéquation avec les types sémantiques visés dans la tâche d’enrichissement des contenus textuels de l’AFP. Le troisième type de règles permet en outre d’obtenir des analyses en termes de mentions d’entités correspondant à des variantes non recensées par Aleda. Cette fonctionnalité joue un rôle important dans la prise en charge du cas spécial de dénotation NIL et illustre l’importance, dans une tâche telle que l’Annotation Sémantique, d’un outil relevant de l’Extraction d’Information et non limité à l’application directe de lexiques sur les données à traiter.

Les résultats de l’analyse réalisée par Syntax consistent en une forêt partagée, dans lesquelles plusieurs analyses concurrentes, notamment en termes d’imbrication, de croisement et d’ambiguïté sont représentées indépendamment les unes des autres. La forêt peut être filtrée :

• par élimination des analyses ne comportant aucun motif reconnu, si d’autres analyses concurrentes comportent un motif reconnu,

• par retenue des analyses correspondant à l’application de règles prioritaires en cas de concurrence entre plusieurs empans de texte de même longueur en termes de formes, • par retenue des analyses de longueur maximale entre plusieurs motifs reconnus entre un

état en et différents états em1, . . . , emN,

• par élimination des analyses faisant intervenir des sous-motifs relativement aux analyses concurrentes.

10. Alexina est une architecture linguistique et informatique pour le développement de lexiques morphologiques et syntaxiques. Site internet http://alexina.gforge.inria.fr/

3. Ressources : Outils 181 Un DAG de formes est alors construit par extraction des séquences de feuilles de la forêt filtrée, puis est minimisé. Les informations relatives aux noms propres reconnus et typés sont indiquées au niveau des formes du DAG, comme l’illustre la figure 5.8.

La secrétaire d'État Hillary Clinton devrait quitter ses fonctions en janvier, selon les déclarations faites à Washington.

1 2 {La} la 3 {secrétaire} secrétaire 4 {d'} d' 5 {Etat} Etat 6 {Hillary} Person 7 {Hillary Clinton} Person {Clinton} Person 8 {devrait} devrait 9 {quitter} quitter 10 {ses} ses 11 {fonctions} fonctions 12 {en} en 13 {janvier} janvier 14 {,} , 15 {selon} selon 16 {les} les 17 {déclarations} déclarations 18 {faites} faites 19 {à} à 20 {Washington} Person {Washington} Location {Washington} Organization 21 {.} . 1 2 {La} la 3 {secrétaire} secrétaire 4 {d'} d' 5 {Etat} Etat 6 {Hillary} Person 7 {Hillary Clinton} Person {Clinton} Person 8 {devrait} devrait 9 {quitter} quitter 10 {ses} ses 11 {fonctions} fonctions 12 {en} en 13 {janvier} janvier 14 {,} , 15 {selon} selon 16 {les} les 17 {déclarations} déclarations 18 {faites} faites 19 {à} à 20 {Washington} Person {Washington} Location {Washington} Organization 21 {.} . 1 2 {La} la 3 {secrétaire} secrétaire 4 {d'} d' 5 {Etat} Etat 6 {Hillary} Person 7 {Hillary Clinton} Person {Clinton} Person 8 {devrait} devrait 9 {quitter} quitter 10 {ses} ses 11 {fonctions} fonctions 12 {en} en 13 {janvier} janvier 14 {,} , 15 {selon} selon 16 {les} les 17 {déclarations} déclarations 18 {faites} faites 19 {à} à 20 {Washington} Person {Washington} Location {Washington} Organization 21 {.} .

Figure 5.8 : DAG de formes produit par SxPipe/NP.

On peut noter que l’on obtient, en sortie de SxPipe, un format de représentation des don- nées équivalent au format décrit précédemment pour l’approche modulaire jointe (cf. supra, section 1.2.1) : seules les ambiguïtés d’analyses issues du module NP sont considérées, à l’exclu- sion de celles concernant les autres formes des DAG11, et les zones d’ambiguïté des DAG sont

normalisées en disjonction de chemins de même longueur, avec un seul état initial et un seul état final. La configuration de SxPipe élaborée pour la présente tâche fait donc appel aux composants suivants :

sélection du français comme langue d’analyse, en association avec le lexique Lefff , • segmentation en phrases et en tokens,

• formation des DAG de formes, éventuellement ambigus,

• reconnaissance des noms propres de type person, organization et location par le module de dag2dag NP

puis élimine les analyses relatives aux formes en dehors des analyses retournées par NP. Le format final consiste ainsi en un DAG de tokens et de formes, celles-ci ne concernant que les noms propres reconnus par NP et conservant les informations relatives aux tokens qui les constituent.

En tant que module intégré à SxPipe, NP ne présente pas de fonctionnalité de désambiguïsa- tion. Dans le cadre de travaux initiaux réalisés à partir de ce module de REN pour le traitement de corpus de l’AFP, un module spécial, npNormalizer, a été développé afin de retourner une analyse univoque en termes de REN à la suite de NP ; il est décrit ci-après, dans la section 3.2.

11. Les autres ambiguïtés à ce niveau concernent notamment la segmentation en unités lexicales, où la séquence de tokens de la peut être segmentée de façon ambigüe, la lecture de_la (déterminant partitif) étant en concurrence avec la lecture de la (préposition suivie d’un déterminant défini).

3.1.2 LIAne

Le système de REN LIAne [BC10], développé dans le cadre de la campagne d’évaluation ESTER (cf. chapitre 2, section 3.1), repose sur une approche hybride avec l’emploi de deux modèles, génératif et discriminant, pour l’apprentissage automatique à partir du corpus ESTER. LIAne est construit autour des deux sous-tâches essentielles de la REN, consistant d’une part en une segmentation du texte d’entrée relativement aux frontières des entités nommées et d’autre part en une classification sémantique de ces entités nommées, selon une typologie ramenée ici aux types person, organization et location. La réalisation de ces deux sous-tâches peut être vue de façon jointe si l’on considère la classification comme un processus appliqué au mots ou tokens. Chacun d’eux reçoit alors une étiquette de type et une étiquette du modèle BIO, indiquant sa position au sein de la séquence formant une entité nommée — étiquette B (begin) pour la position initiale et I (inside) pour les autres —, les mots ou tokens n’appartenant pas à une telle séquence recevant l’étiquette vide et la position notée O (outside).

La REN ainsi considérée comme une tâche d’étiquetage de mots peut faire usage de toutes les méthodes développées pour l’étiquetage en parties du discours, notamment numériques. Les approches principales en la matière sont de type génératif, avec notamment les Modèles de Markov Cachés (Hidden Markov Models, HMM) [BSW99] ou discriminant avec notamment les modèles a maximum d’entropie [Bor+98] ou les Champs de Markov Aléatoires (Conditional Random Field, CRF) [ML03].

L’approche présentée par LIAne est hybride en tant qu’elle met en œuvre, successivement : • un processus génératif à l’aide d’un modèle HMM pour la prédiction d’étiquettes syntaxiques

(parties du discours) et sémantiques (type parmi person, organization et location dans la configuration présente) au niveau de chaque mot ou token,

• puis un processus discriminant reposant sur les CRF, chargé de déterminer les frontières des expressions formant des entités nommées sur le modèle BIO, et d’assigner un type global à la séquence ainsi identifiée.

Le format des données d’apprentissage se présente donc selon le modèle BIO, comme l’illustre la figure 5.9.

investiture NFS O

aujourd’hui ADV B-TIME

à PREPADE O

Bamako LOCATION B-LOCATION

Mali LOCATION B-LOCATION

du PREPDU O

président NMS O

Amadou PERSON B-PERSON

Toumani PERSON I-PERSON

Touré PERSON I-PERSON

Figure 5.9 : Format BIO de représentation des données d’apprentissage de LIAne

L’étiquetage des mots ou tokens à l’aide d’un modèle HMM préalablement à l’étiquetage final à l’aide de CRF est motivé par

• la facilité d’intégration de multiples sources d’information dans les estimations de probabi- lité des mots sachant les classes,

• la tolérance des HMM au bruit dans les données d’apprentissage, dès lors que la fréquence relative des événements modélisés est respectée,

3. Ressources : Outils 183 • la désambiguïsation partielle de la chaîne par l’étiquetage en parties du discours et en types sémantiques, qui permet de simplifier la tâche l’étiquetage du modèle CRF, concentré sur les problèmes de frontières et de classification globales.

L’emploi d’un modèle numérique tel que les CRF permet d’obtenir un ensemble d’analyses, cha- cune étant munie d’une probabilité quant aux frontières et au typage des entités nommées reconnues et un même segment pouvant être concerné par plusieurs analyses en concurrence. Les sorties du système LIAne correspondent à des DAG qu’il est ensuite possible de normaliser comme cela est fait pour les DAG de SxPipe/NP. Chaque DAG ainsi obtenu peut par ailleurs être considéré comme associé à une pondération, chaque chemin d’analyse en concurrence avec d’autres recevant un score correspondant à la probabilité émise par le modèle CRF de recon- naissance. La désambiguïsation des résultats de LIAne peut enfin être réalisée par sélection de l’analyse ayant reçu le score maximal.