Dans le cadre de travaux initiaux menés en collaboration entre l’équipe-projet Alpage et l’AFP, la chaîne de traitement SxPipe a été utilisée afin de prendre en charge les besoins préliminaires d’analyse et d’exploration de corpus, conduisant notamment au développement effectif du module SxPipe/NP. Celui-ci ne présentant cependant pas de fonctionnalité de désambiguïsation et se limitant à une analyse surfacique propre à la REN, un module ad hoc a été mis au point afin de rendre NP utilisable à court terme à des fins d’Extraction d’Information. Le nom de ce module, npNormalizer, reflète son objectif de départ : d’abord conçu dans le but de désambiguïser les sorties de NP et d’effectuer une normalisation des entités nommées — principalement des noms de personnes — au niveau des documents, npNormalizer a ensuite intégré une fonctionnalité équivalente au Liage tel que défini au chapitre 3 (section 3) afin de répondre à la nécessité prégnante d’associer la REN de NP à une Annotation Sémantique reposant sur des ressources d’entités identifiées [SS10]. On dispose donc, avec SxPipe et npNormalizer, d’une chaîne initiale accomplissant l’identification des entités dans les corpus de l’AFP, que l’approche et le système étudiés dans le présent travail proposent d’améliorer.
Cette amélioration est souhaitée pour plusieurs raisons :
• Le module npNormalizer est, au niveau formel, étroitement associé à SxPipe et à NP, et ne peut prendre en charge l’analyse de sorties d’autres systèmes de REN. L’approche proposée ici est quant à elle modulaire et s’intéresse à la possibilité d’utiliser tout système de REN considéré comme performant et adapté à la tâche.
• Le fonctionnement de npNormalizer repose sur un ensemble d’heuristiques, simulant par- tiellement les critères d’analyse généralement envisagés par le Liage. Ces heuristiques tra- duisent l’intuition générale selon laquelle les entités les plus notables ou populaires ont une probabilité plus grande d’être effectivement dénotées, étant donnés une mention et un ensemble d’entités candidates. Ce critère est cependant exploité de façon isolée et favorise ainsi systématiquement les entités les plus populaires a priori. Une telle stratégie permet, dans le cadre de travaux initiaux et exploratoires, de prendre en compte la distribution par- ticulière des entités dans les contenus journalistiques généralistes de l’AFP : la majorité des mentions d’entités correspondent en effet usuellement, dans de tels corpus, à un ensemble réduit d’entités à forte notoriété. Une désambiguïsation presque uniquement fondée sur la notoriété fournit ainsi une couverture non négligeable et une bonne précision des liens vers les entités dénotées. On peut cependant observer qu’une telle procédure répond de façon limitée à la tâche à réaliser, qui appelle la mise en œuvre d’une approche plus sophistiquée
et à même de prendre en charge le phénomène dénotationnel dans son ensemble. Le fonc- tionnement général ainsi que l’évaluation qui a pu être faite du module npNormalizer sont décrits ci-après.
• Le développement de npNormalizer est très fortement guidé par une adéquation aux don- nées de l’AFP. Plus précisément, les retours réguliers des utilisateurs en termes d’erreurs donnent lieu à des corrections immédiates et locales, souvent apparentés à des suppres- sions et ajouts manuels de règles spécifiques aux cas particuliers indiqués par les rapports d’erreurs, sans prise en compte au niveau plus général du mode d’analyse lui-même. D’autre part, npNormalizer reflète de façon systématique le corpus GAFP (cf. supra, section 2.1) qui est utilisé pour son développement et son évaluation.
• On peut considérer qu’un système reposant sur une approche numérique du phénomène à traiter devrait être plus robuste, généralisable et adaptable qu’un système reposant sur des heuristiques tel que npNormalizer.
Fonctionnement Comme dans l’approche proposée ici, npNormalizer est associé à la base d’en-
tités Aleda, ainsi qu’aux variantes qu’elle définit pour chaque entité recensée. De façon comparable au Liage tel qu’envisagé pour cette approche (cf. infra, section 1), un DAG correspondant à un automate modélisant chaque phrase à traiter est présenté à npNormalizer, qui considère dans un premier temps toutes les mentions d’entités y figurant, telles que retournées par SxPipe/NP, et procède à leur Liage. Cette étape résulte en une entité choisie pour chaque mention, le cas NIL étant également considéré. Chaque zone d’ambiguïté concernant des mentions est ensuite désambiguïsée par sélection du chemin contenant les entités les plus probablement dénotées par les mentions correspondantes, relativement aux entités choisies dans les autres chemins.
La première étape de traitement de npNormalizer, conformément au cadre général du Liage, établit en premier lieu un ensemble d’entités candidates pour chaque mention par la mise en correspondance du contenu de ses tokens avec les variantes lexicales recensées dans Aleda. Leur ordonnancement repose ensuite sur un ensemble d’heuristiques traduisant le rôle primordial ac- cordé au critère de popularité dans la résolution du phénomène dénotationnel. Ces heuristiques consistent principalement à assigner un poids à chaque candidat sous la forme d’un score numé- rique. Ce score est calculé à partir du poids indiqué par Aleda pour une entité donnée, soumis à une normalisation permettant de rendre comparables la popularité des entités issues de Wikipe- dia, correspondant à la taille de l’article correspondant, et le nombre d’habitants renseignés pour les lieux issus de GeoNames. Lorsque l’ensemble des candidats retourné par la requête sur Aleda est vide, l’entité spéciale NIL est assigné à la mention avec un score fixe. Le cas NIL n’est donc pas envisagé pour toutes les mentions à lier.
À partir du DAG décoré des informations de Liage pour les mentions, chacune d’elles étant associée à une entité la plus probablement dénotée, les différents chemins en situation d’ambiguïté dans chaque zone concernée par des mentions font l’objet d’une pondération permettant de désambiguïser la zone par sélection du chemin au score le plus élevé. Ce score est calculé à partir de celui des entités choisies pour chaque mention, modifié en tenant compte du statut des mentions. Ainsi, les entités choisies pour des mentions :
• apparaissant en tête de phrase,
• figurant sur une liste préétablie de façon manuelle et selon des jugements liés à la proba- bilité forte d’une chaîne de caractère de ne pas constituer une mention d’entité,
• figurant en tant qu’entrée d’un lexique général — ici le Lefff , • dont le type est organization
3. Ressources : Outils 185 voient leur score diminuer. À l’inverse, les entités choisies pour des mentions de type location sont favorisées, ainsi que les entités dont le sous-type indiqué par Aleda est City, Capital ou AdministrativeDivision.
npNormalizer est par ailleurs directement appliqué en sortie de SxPipe/NP et dispose d’infor- mations spécifiques à certaines des règles ayant donné lieu aux analyses retournées. Les analyses résultant de règles considérées comme plus sures que les autres, pour une même zone d’am- biguïté, sont favorisées. Il s’agit notamment de règles faisant intervenir des indices multiples : indices contextuels, indices internes et intervention d’une variante lexicale recensée dans Aleda. De telles informations ne sont pas transmises en sortie de SxPipe/NP dans le cadre du système développé ici : elles induiraient en effet des annotations différentes selon les règles appliquées, en contradiction avec la généralité attendue de tout module de REN employé à ce niveau. Il importe en effet que les analyses retournées par les différents modules de REN éventuellement combinés soient comparables.
Il est important de noter que toutes les valeurs, assignations et variations de scores d’entités dans npNormalizer sont établies manuellement.
Évaluation Le module npNormalizer est évalué à l’aide du corpus de référence GAFP, présenté
précédemment. Comme cela devra être le cas pour le système d’identification automatique pro- posé dans la suite de ce travail, l’évaluation porte à la fois sur la qualité du Liage et sur la reconnaissance des mentions d’entités en tant que telles, celle-ci étant en partie dépendante des choix effectués lors de la seconde étape. Les métriques utilisées correspondent donc
• d’une part à la précision, au rappel et à la F-mesure usuellement appliquées à la REN et notées Pren, Rren et Fren, avec
Fren= 2 × Pren× Rren
(Pren+ Rren)
• d’autre part au taux de correction de l’étape de Liage étant donné l’ensemble des mentions correctement reconnues, noté Acc. Acc est égal au nombre de mentions correctement reconnues et identifiées (cas NIL inclus) divisé par le nombre de mentions correctement reconnues.
• De ces deux types de mesures sont dérivés une précision, un rappel et une F-mesure de la tâche globale, notées Pall, Rall et Fall, comme cela sera discuté plus en détail lors de
l’évaluation du système présenté au chapitre 6, avec Pall = Pren× Acc Rall = Rren× Acc et
Fall = 2 × Pall× Fall
(Pall+ Rall)
Les résultats de l’évaluation, reportés à la table 5.1412, montrent que la base heuristique de npNor-
malizer est efficace et constitue une baseline déjà élevée. Ces bonnes performances ne doivent cependant pas occulter les insuffisances de npNormalizer évoquées ci-dessus, notamment en
12. L’évaluation de la REN tient compte de la correction des frontières de mentions d’entités, les correspondances partielles étant considérées comme des faux positifs. La correction du type est en revanche ignorée au niveau de la REN, pour être intégrée à la performance de Liage : une mention correctement liée reçoit en effet le type de l’entité choisie, qui se substitue au type assigné par le module de REN.
termes de possibilités de généralisation : le développement de ce module est en effet étroitement lié à la connaissance du corpus de référence GAFP, ainsi qu’aux réponses immédiates à apporter en termes de correction d’erreurs à court terme pour les usages exploratoires des contenus de l’AFP13. On peut également constater, comme cela a été évoqué à la section 1.1, que de bons ré-
sultats au niveau du Liage et de la REN aboutissent à un score global moins satisfaisant (en-deçà de 75%).
Pren Rren Fren Acc Pall Rall Fall
87,75% 78,22% 82,71% 88,78% 77,90% 69,44% 73,43%
Table 5.14 : Résultats d’évaluation de npNormalizer sur l’ensemble du corpus de référence GAFP. Au-delà des résultats d’évaluation reposant sur des mesures numériques usuelles en la ma- tière, il convient d’explorer la typologie des erreurs générées par npNormalizer en termes de reconnaissance de mentions et de Liage afin de déterminer. Ces erreurs sont en effet régulières, du fait de la nature systématique des manipulations effectuées aux deux niveaux, et peuvent, même en nombre absolu réduit, provoquer un effet de bruit faisant de npNormalizer une solution non satisfaisante au problème de l’identification d’entités. Le système présenté dans le chapitre suivant, Nomos, pourra être comparé à npNormalizer à la fois au niveau des scores obtenus quant aux métriques d’évaluation de la tâche d’identification (performances de la REN, taux de correction du Liage et performances au niveau global), mais également relativement à des tâches applicatives, abordées au chapitre 7,
13. Il convient également d’observer que ces résultats sont difficilement comparables à l’état de l’art en REN pour le français, tel que la campagne ESTER 2 a notamment permis de l’établir ; les données d’évaluation de npNormalizer sont en effet limitées à des dépêches d’agence, tandis que les corpus d’ESTER 2 sont constitués de transcriptions de l’oral, également du domaine journalistique mais a priori plus difficiles à traiter.
Chapitre 6
Un système d’identification d’entités :
Nomos
Le système Nomos procède à l’identification automatique d’entités selon l’approche proposée au chapitre précédent et dans la perspective d’une utilisation pour l’enrichissement des contenus de l’AFP. Afin d’expliciter les hypothèses à partir desquelles le développement de Nomos est envisagé, la section 1 propose une analyse des différentes configurations de l’identification, de la situation décrite pour la tâche de Liage dans le cadre de TAC-KBP (chapitre 3, section 3) à celle du traitement de contenus textuels bruts dont il s’agit dans le présent travail. La section 2 présente les composants de Nomos, conçus et agencés de façon à prendre en charge les aspects de l’identification spécifiques à un tel traitement. La section 3 fait état des expériences menées afin de tester la validité et l’efficacité de l’approche choisie relativement à cette configuration.
1
Configurations de l’identification
Nous proposons de qualifier de naïve la configuration de l’identification dans laquelle toute requête présentée au système est considérée comme une mention d’entité, sans que ce statut ne soit remis en cause, par opposition à une configuration informée, dans laquelle le caractère dénotationnel des requêtes peut être infirmé.