Intelligence linguistique et attributions des scores

Le cœur du projet

Directions et directives

Le stage a été l’occasion d’exploiter les différentes pistes à notre disposition pour extraire l’information du corpus. Ceci de manière automatisée sans intervention manuelle dans le processus afin de la présenter sous forme d’un nuage de mots. Les contraintes fixées ont été de conserver une facilité de portage dans différentes langues et d’utiliser des procédés ne nécessitant pas une maintenance (mise à jour) par un documentaliste expert. Le temps ayant permis de développer l’outil jusqu’à sa phase de mise en production, il a fallu réécrire le code de manière à ce qu’il soit facilement intégrable à l’infrastructure existante. Enfin, il faudra l’avoir rendu robuste et capable de gérer les problèmes informatiques usuels (erreurs d’écriture, ouverture de fichiers inexistants… etc). Dernier point, un maximum de paramètres devront avoir été pensé comme réglables pour éviter toute réécriture ou intervention au sein du code.
Si le nuage de mots n’est par définition qu’une forme de présentation graphique de l’information, les algorithmes, qui permettent l’extraction de l’information en amont pour donner un poids et un sens autre qu’un effet stylistique au nuage, sont quant à eux la réalisation concrète d’une des multiples facettes du TAL. Ce traitement de la langue (dans notre cas sous forme textuelle) est envisageable de bien des façons, et c’est là tout l’enjeu du stage qui a été mené au sein de Linkfluence. Si nous pouvons tout à fait distinguer cette partie algorithmique du nuage (rien n’empêchant de représenter les résultats par un autre intermédiaire), elle a été ici pensé pour produire une information directement exploitable sous la forme d’un nuage de mot dynamique avec une donnée temporelle.

Tour d’horizon des nuages de mots

Sur le web, nous pouvons aujourd’hui trouver une grande variété de nuages de mots (nous utiliserons le terme nuage de mots pour désigner à l’avenir la représentation graphique de l’information et la partie algorithmique comme un tout). Dans la plupart des cas ils ne diffèrent que par la présentation et ne proposent pas d’extraction avancée de l’information. Ils se contentent de prendre en entrée une liste de mots associés à une valeur numérique qui servira de score pour attribuer des poids différents, ce qui se traduira par des couleurs et/ou des tailles de polices différentes. Ils ont aussi un rôle de navigation au sein du site qui les emploie. En effet, les mots affichés possèdent généralement un lien hypertexte qui redirige l’utilisateur vers du contenu associé au mot sur lequel ils ont cliqué. A noter que le terme « mot » désigne par un abus de langage une unité graphique séparée par deux espaces dans notre cas. Nous serons amenés à l’opposer au terme n-gramme.
Cette valeur numérique a souvent comme origine la fréquence d’apparition des mots au sein d’un texte. Si cette information n’est pas négligeable dans le cadre de notre travail, seule elle reste pauvre et limite grandement les observations que nous pourrions envisager.
L’une des plate-formes les plus fréquentées pour ce type de média est Wordle. Pourtant en page d’accueil il est fait explicitement mention du fait que le générateur se contente d’utiliser les fréquences d’apparitions : « Wordle is a toy for generating “word clouds” from text that you provide. The clouds give greater prominence to words that appear more frequently in the source text. ». Dans la description même du produit, il est clairement établi qu’il est considéré comme un « jouet » (toute proportion gardée, les algorithmes de gestion de l’espace et d’affichage de l’information étant tout à fait remarquables). Son but reste purement visuel et n’offre pas une étude plus fine et poussée de l’information issue d’un texte source.

Le point de départ

Le tf-idf

Définition 

– term frequency : la fréquence d’apparition d’un terme divisée par la somme des fréquences d’apparitions de l’ensemble des termes du document.
– inverse document frequency : le logarithme du résultat du nombre de documents du corpus divisé par le nombre de documents où au moins une occurrence du terme apparait.
– tf-idf : term frequency* inverse document frequency
Le tf-idfest un algorithme qui a la particularité de donner un indice à chaque mot d’un texte plus ou moins fort selon sa fréquence d’apparition dans celui-ci par rapport à sa fréquence d’apparition dans l’ensemble des documents auxquel le texte est comparé. Ainsi, un terme extrêmement fréquent comme « de » verra son indice relativement faible puisque sa grosse fréquence d’apparition sera pondérée par celle dérivant de son apparition quasi systématique dans chaque texte du corpus. Cela permet d’attribuer aux mots les plus spécifiques du texte un indice plus important qu’à ceux communs à l’ensemble du corpus tout en conservant une forme de classement par leur fréquence d’apparition. Dans son utilisation première, le tf-idfpermet donc de sélectionner les documents parmi un set qui paraissent comme les plus pertinents par rapport à une requête précise. Dans l’utilisation que nous en avons faite, l’algorithme nous permet de sélectionner uniquement les mots (ou groupes de mots) qui caractérisent le mieux un ensemble de documents générés par une requête donnée par rapport à un corpus de référence. En effet, nous considérons le corpus de la requête comme un seul et unique document et le corpus de référence (composé d’un ensemble de billets sélectionnés aléatoirement – aujourd’hui résultants d’une requête contenant des opérateurs logiques du type ‘ le OR de OR la ‘ qui a pour but d’être la moins restrictive possible ) comme le set de documents.
Au cours du stage, nous avons ajouté à la formule du tf-idf une variable pour écraser l’échelle de grandeur des fréquences d’apparitions qui pouvait être disproportionnée (rapport de 1000 entre deux termes ce qui a pour effet d’attribuer à des mots non spécifiques mais sur-représentés un indice fort), cela se traduit par la présence d’une racine carré sur le term frequency.
Concrètement, le tf-idfnous permet de pondérer les mots d’un texte par rapport à ceux d’un corpus pris en référence.

Un premier essai réalisé par Linkfluence

L’équipe de Linkfluence a développé un premier prototype de nuage de mots. Sa principale caractéristique qui diffère grandement de ce qui a déjà été fait est d’utiliser la comparaison (à travers l’utilisation du tf-idf) des mots d’un texte par rapport à un ensemble d’autres pour y trouver ceux qui font la spécificité de ce premier.
A cela s’ajoute une ligne du temps qu’il est possible de parcourir et nous avons un nuage dynamique capable d’afficher sur une période définie, pour un jour en particulier, les mots qui sont spécifiques à cette journée par rapport aux autres jours. Nous pouvons donc suivre l’évolution de ces mots, les voir apparaître, disparaître ou simplement changer de poids selon l’importance qu’ils prennent ou perdent.
Le nuage ne fonctionne en revanche qu’avec des mots, il n’y a pas encore la prise en compte des n-grammes qui sera développée au cours du stage. De plus, c’est uniquement à l’aide d’une stoplistque sont filtrés les éventuels mots indésirables. Il n’y a pas non plus la moindre utilisation de linguistique plus classique (fondée sur des grammaires par exemple), l’ensemble est uniquement le résultat d’un algorithme statistique. Cependant, sur ce point, cela rend le déploiement du nuage rapide et facile pour d’autres langues.

Les fondements du nouvel outil

L’hypothèse derrière le nuage de mots est qu’on puisse arriver à extraire de l’information pertinente grâce au calcul du vocabulaire spécifique d’un texte par rapport à un autre. Cela sous-entend une qualité des données comme point d’entrée. Dans l’ensemble, le domaine du TAL est souvent confronté au bruit et il est généralement décidé de privilégier le silence au premier. Bien entendu, le but étant de réduire le silence au stricte minimum sans pour autant laisser le bruit s’immiscer dans les résultats. Dans notre cas, le choix des données ayant été effectué méticuleusement lors de la création de Linkscape, notre travail n’en a été que plus facile. Ce n’est pas pour autant que nous avons été libéré de toute forme de nettoyage, mais nous avons pu nous concentrer en privilégiant la précision et la justesse plutôt que l’action de masse.
Nous sommes donc parti sur des bases expérimentales, sans préjugés lors de la création des algorithmes. Au fur et à mesure de nos avancées nous les avons affinés afin d’approcher le plus près possible ce que nous jugions comme un résultat exploitable en production. Bien qu’étant dans un cadre de recherche et d’essais, il ne fallait pas occulter le fait que le travail réalisé avait un but concret d’application derrière, et qu’au delà de l’intérêt scientifique, il était nécessaire d’arriver à trouver quelque chose d’utilisable.
C’est pourquoi notre champ d’action est resté large mais sans oublier nos objectifs. Ainsi, s’assurer de la validité de l’hypothèse est resté un point central tout au long du stage, l’ensemble du projet reposant sur ce vocabulaire spécifique et ce qu’il est possible d’en faire.
Notre travail repose aussi sur des bases linguistiques éprouvées. Les collocations sont un phénomène qui a été largement étudié et analysé et dont l’existence n’est plus à démontrer.
Ainsi, le projet croise l’utilisation du vocabulaire spécifique avec celui des collocations dans le but d’obtenir des n-grammes dont l’intérêt sémantique et informatif se révèle pertinent (dans notre cadre). Ces n-grammes ne se limitent pas aux expressions figées, ils recouvrent aussi des extraits (parties) de phrases qui peuvent être issues de la répétition d’une citation à travers les différentes publications. Nous souhaitions donc pouvoir observer des phénomènes de langue lors de l’affichage de résultats.
C’est donc en partant de ce principe : afficher le spécifique d’un document ou corpus de documents que le développement du nouveau nuage de mots s’est déroulé. Le code du prototype n’a pas été réutilisé, seule l’idée de fonctionnement a été conservé. Il a donc fallu construire, brique après brique les différentes strates de l’analyse et les suites d’algorithmes pour permettre la réalisation du projet. Les compétences informatiques ont été relativement mises en avant, le projet nécessitait une bonne connaissance du langage Perl, connaissance qui a été en parti bâti tout au long du développement. Tout ceci combiné avec l’utilisation de linguistique par l’intermédiaire de la compréhension des mécanismes de la langue ainsi que l’utilisation de grammaires.
Le stage a aussi été l’occasion d’être formé à de nouveaux outils, aussi bien orientés développeur que linguiste. Ainsi, le framework GATE nous a apporté des solutions, au moins provisoires, dans l’attente d’un développement plus avancé et personnalisé de nos applications.

Les outils sollicités

TreeTagger

TreeTagger est ce que nous appelons communément un pos-tagger. Il a pour fonction d’associer à chaque mot d’un texte la partie du discours (part of speech) qui lui revient. Son utilisation est facilitée au sein de GATE par une intégration simple à mettre en place. TreeTagger est fondé sur les principes de machine learning.

GATE

GATE est un frameworkde TAL qui offre de multiples fonctionnalités pour traiter du texte et en extraire de l’information à travers son système d’annotation. En effet, GATE donne l’opportunité d’annoter un texte selon des critères et des règles que nous aurons nous-même établis. Ainsi, il offre la possibilité d’écrire des grammaires dont il se servira pour repérer une partie quelconque du texte source qui correspondra aux règles fixées. Il propose aussi d’effectuer des chaînes d’opérations sans que nous n’ayons à intervenir dans le processus. Il sera possible, par exemple, de tokeniser un texte, puis de le taguer et enfin de l’annoter. Les différentes strates d’opération sont sélectionnées par l’utilisateur mais c’est GATE qui se chargera de les exécuter consécutivement. GATE utilise notamment ce qu’il appelle des gazetteers : ce sont des listes de mots auxquels il attachera une annotation particulière que nous aurons déclarée dans un fichier contenant des métadonnées sur un ou plusieurs gazetteers, voire une annotation qui se trouve au sein de l’un d’entre eux.
Une autre de ses forces et l’un des points clés qui ont permis son utilisation : sa version dite embeddedet qui offre une interface écrite en Java pour pouvoir utiliser GATE à travers nos propre applications sans devoir passer par la version usant de l’interface graphique. GATE reste néanmoins un grand consommateur de ressources et son coût dans le traitement peut être important suivant la tâche qui lui est dédiée.
Notons enfin que GATE dispose d’autres fonctionnalités que nous n’avons pas exploitées pour notre projet puisqu’elles n’étaient simplement pas requises.

Calculs et n-grammes

Les n-grammes

L’un des points clés du nuage a été la volonté de proposer un outil capable d’afficher, à la différence de nombreux autres, des mots simples mais aussi des mots composés (ou des suites de mots, syntagmes figés, entités nommées…). Utilisant le principe des n-grammes (un ‘gramme » étant ici une unité graphique délimitée par un espace devant et derrière elle), le premier stade de développement a été de mettre en place un système de calcul automatique des différents n-grammes d’un corpus donné. L’idée sous-jacente étant que les n-grammes spécifiques au corpus de la requête seraient composés notamment d’entités nommées complètes. Nous retrouverions alors à l’affichage des formes telle que «Noam Chomsky» en lieu et place de «Noam» d’un côté et «Chomsky» de l’autre.
Pour arriver à ce résultat, nous avons choisi de calculer letf-idfdes n-grammes en ayant limité à 4 le nmaximum pour un n-gramme. En effet, après différents essais, au delà de cette limite, le nombre de n-grammes pertinents à afficher chute drastiquement, il devient alors bien plus difficile et contraignant d’extraire ceux qui répondent aux critères de validité pour être affichés.
Nous commençons donc par calculer le nombre de documents du corpus de référence contenant un n-gramme donné et ce, pour tous les n-grammes de ce même corpus. Cette première passe nous permet d’obtenir la partie idfdu tf-idf, c’est à dire que nous avons les chiffres nécessaires à son calcul (le nombre de documents total et le nombre de documents contenant pour chaque n-grammes le-dit n-gramme).
Dans un second temps, nous calculons la fréquence d’apparition de chaque n-gramme dans le corpus de la requête (nous permettant d’établir la somme des fréquences de l’ensemble des n-grammes). Nous avons distingué à ce moment différents types de n-grammes, types correspondant au ndu n-gramme. En d’autres termes, le tf-idfdes n-grammes dont le nest égale à 1 est calculé distinctement du tf-idfdes n-grammes dont lenest égale à 2 et ainsi de suite. Ainsi, la somme des fréquences des 1-grammes (nous utiliserons cette forme de notation par commodité) est différente de celle des 2-grammes, des 3-grammes et des 4-grammes. Avec cette passe, nous avons maintenant à disposition la partie tf du tf-idf, partie qui nécessite pour chaque n-gramme sa fréquence d’apparition dans le texte (ici le corpus de la requête) et la somme des fréquences de tous les n-grammes (du même type donc) de ce même texte.

Intelligence linguistique et attributions des scores

Les entités nommées

Maintenant que nous possédons un corpus annoté, nous pouvons en extraire les annotations pour travailler directement dessus. Dans l’ensemble, tous nos n-grammes annotés sont des candidats idéaux pour être affichés. Néanmoins, nous allons tout de même ajouter quelques restrictions ainsi que traiter certains d’entre eux de manière particulière.
Nous allons calculer un set de candidats sans tenir compte d’une quelconque donnée temporelle en premier lieu, et de ce set nous calculerons le score des candidats jour par jour selon les dates des billets de notre corpus dans un second temps.
Pour commencer, l’un des principaux objectifs que nous voulions atteindre par l’utilisation de n-grammes était d’arriver à extraire les entités nommées d’un corpus. Si notre système ne permet pas d’identifier de façon précise si tel ou tel n-gramme est une entité nommée, il n’en reste pas moins qu’elles sont présentes dans leur forme entière (la majeure partie du temps) puisqu’elles sont, pour la plupart, des n-grammes spécifiques de notre corpus. Nous allons donc essayer de les favoriser par un filtrage simple fondé sur une liste d’autorité construite à partir des données de Wikipédia.
Wikipédia propose régulièrement en téléchargement un dumpde ses bases de données. A partir de celui-ci, nous avons extrait de la façon la plus précise possible les données relatives aux entités nommées. Pour procéder à cette extraction, nous avons utilisé le contenu des articles, notamment celui des infobox. De ces dernières, nous avons établi une liste de titres. Titres qui sont attribués aux infobox qui (après observation manuelle) correspondaient à une entité nommée dont nous souhaitions récupérer les informations.
Nous avons concentré notre choix sur les personnes (fictives ou non), les lieux, les noms d’entreprises et de logiciels (ou produits). En automatisant la tâche, nous avons construit une liste à partir des titres d’articles et du contenu des infoboxen veillant à conserver les relations entre les données lorsqu’elles avaient attrait à la même entité. En complément de cette première liste, par le croisement des informations que Wikipédia met à disposition, nous avons pu ajouter à chaque entité nommée ses différentes formes de réalisations (formes qui correspondent aux redirections vers l’article source de l’entité nommée).

Limiter la redondance à travers la fusion

Pour ce qui est de nos n-grammes en général, nous appliquons aussi une fusion basée sur la distance de Levenshtein. Elle est calculée pour chaque n-gramme d’un type par rapport aux n-grammes du même type. Si la distance est égale ou inférieur à un seuil choisi (de valeur Z car paramétrable), le n-gramme dont la fréquence d’apparition est la plus faible se verra fusionné au profit de celui dont elle est la plus forte. La même opération est effectuée pour chaque n-grammes de type deux_gramme au profit des n-grammes de type trois_gramme mais sans tenir compte de la fréquence d’apparition. Cela permet de favoriser les n-grammes longs pour augmenter leur visibilité. La fusion est automatique si la distance est inférieur à X (paramétrable). Ainsi, nous faisons de même pour les ngrammes de type quatre_gramme qui bénéficient d’une fusion avec ceux de type trois_gramme.
Nous avons aussi mis en place une deuxième opération de fusion par l’intermédiaire d’une comparaison entre un n-gramme de type trois_gramme et un autre de type quatre_gramme.
Si le premier est inclus dans le second, en se basant sur leur fréquence d’apparition, nous conservons celui des deux qui possède la plus haute, avec en cas d’égalité un choix pour le quatre_gramme, toujours dans l’optique de favoriser le plus long.
Nous récupérons par la suite la forme accentuée la plus fréquente pour chaque n-gramme de notre liste. Enfin, nous passons les n-grammes restant à travers un filtre : un n-gramme doit avoir une fréquence d’apparition qui représente au moins X% de la somme des fréquences d’apparitions des n-grammes du même type (avec X paramétrable), et qui doit aussi représenter Y% de la moyenne des sommes des fréquences de l’ensemble des ngrammes (tout type confondu, avec Y paramétrable).
Nous possédons maintenant un set de candidats qu’il faut replacer dans un contexte temporel. Nous avons tout de même la possibilité à ce stade de créer un nuage sans cette notion de temporalité. La deuxième boucle de traitement consiste à calculer, pour chaque jour dont nous avons un billet dans notre corpus, parmi l’ensemble des n-grammes issus de l’extraction des annotations, le score de ces derniers s’ils apparaissent dans le set de candidats. Les opérations sont semblables à celles effectuées précédemment tout en tenant compte cette fois-ci de la présence dans le set des candidats du n-gramme en phase de traitement. Ainsi, nous avons par date les n-grammes que nous afficherons et nous pourrons suivre leur présence au cours de la période ou l’importance du nombre de leurs occurrences.

Prise de recul, analyse et commentaires

Difficultés du projet

Perl

Au cours de la réalisation du projet, les difficultés et les problèmes auront fait leur apparition. La première source de ces contraintes a été le code en lui-même. Il a nécessité à plusieurs reprises, au fur et à mesure de sa complexification, une réécriture pour le e rendre plus lisible (réduire sa longueur) ou améliorer ses performances (optimiser le parcours et l’organisation des structures de données). Dans l’optique de faciliter son intégration, il aura aussi été totalement repensé orienté objet, le rendant modulable et paramétrable. La programmation orientée objet a nécessité une phase d’apprentissage sérieuse pour être mise en pratique. Néanmoins, ses avantages étant indéniables pour notre projet, le temps investi n’a pas été perdu et le résultat s’est avéré payant.

Un outil à dompter

Le frameworkGATE a posé aussi divers problèmes, dont certains que nous n’avons pas résolus. Dans l’ensemble, la mise en place d’un script faisant appel à l’interface embedded de GATE n’aura pas été facile. Cela commence par le langage même dans lequel est écrit cette interface, Java. Pour pouvoir écrire un script en Java il a d’abord fallu apprendre la syntaxe du langage et ses spécificités au moyen de tutoriels ou d’enseignements de l’équipe. Passé cet obstacle, c’est la documentation, parfois peut bavarde (se reposant essentiellement sur les javadoc), qui aura été un frein en imposant des recherches pour mettre en place un système opérationnel. A la suite de l’écriture du script, nous avons pu constater l’utilisation importante des ressources machine de la part de GATE. Chose amplifiée par une fuite mémoire que nous n’avons pas pu corriger à l’heure actuelle. La solution que nous avons mise en place pour le moment consiste à découper le traitement de GATE en plusieurs passes.
Nous avons donc été confronté en majorité à des problèmes techniques plutôt que des failles théoriques. Dans l’ensemble, nous avons pu passer outre en les résolvant de manière propre et efficace. Il était important de trouver un compromis entre solution et temps, puisqu’une solution qui nous aurait coûté un grand temps de développement n’aurait eu de solution que le nom. C’est cet équilibre qui nous a momentanément forcé à délaisser le problème de fuite mémoire. Néanmoins, il sera important d’y remédier dans un avenir proche, bien que cela ne nuise pas au fonctionnement du nuage de mots.

Table des matières
Introduction
Partie 1 : Gestation et naissance d’un nouveau projet
1 Environnement et cadre professionnel
Au sommet de la tour
Linkfluence, Linkscape
2 Le cœur du projet
Directions et directives
Tour d’horizon des nuages de mots
3 Le point de départ
Le tf-idf
Un premier essai réalisé par Linkfluence
Les fondements du nouvel outil
Partie 2 : De l’idée au produit final
1 Les outils sollicités
TreeTagger
GATE
2 Calculs et n-grammes
Les n-grammes
Stoplist et accentuation
Sélection
3 Grammaires et automates à état fini
4 Intelligence linguistique et attributions des scores
Les entités nommées
Limiter la redondance à travers la fusion
Partie 3 : Prise de recul, analyse et commentaires
1 Difficultés du projet
Perl
Un outil à dompter
L’encodage
2 Évaluation et critiques
Un constat, des avis
Le spécifique
Technique, statistiques et linguistique
Licences
Une ville, un cas : Grenoble
3 Retours sur le déroulement du stage
Le projet
Jour après jour
Sources
Bibliographie
Glossaire
Résumé

Télécharger le rapport complet