Utilisant les transformations que nous avons présentées, un expert peut alors construire un système d’analyse complet en combinant une série de transformations les unes à la suite des autres. La re-présentation de l’état de l’analyse étant prévue pour être externalisable, nos premières expériences ont pris la forme d’un simple pipe liant les différentes invocations des programmes implémentant les transformations. Une librairie commune gère les entrées/sorties vers et depuis la représentation in-terne. La figure 2.5 donne un exemple d’un tel script. Cette approche, bien que simple et très flexible, a plusieurs inconvénients :
– Pour un nombre de passes assez grand (autour de la trentaine), plus de 50% du temps d’analyse passait en entrées/sorties.
2.6. CONSTRUCTION D’UN ANALYSEUR COMPLET 49 # !/bin/sh
h="/people/.../system" r="$h/regles"
p="$h/par"
wmatch -Ftxtlines -Txml -R $r/sp-num.wm | \ wnumbers -Fxml -Txml | \
wtagger -Fxml -Txml -s $p/spanish-par-linux-3.1.bin $p/sp-mapping.txt | \ wmatch -Fxml -Txml -S $r/type-question.wm | \
wmatch -Fxml -Txml -S $r/sp-date-time.wm | \ wmatch -Fxml -Txml -S $r/org.wm | \
wmatch -Fxml -Txtag -S $r/loc.wm
FIG. 2.5 – Exemple de système d’analyse sous forme de script. wmatch correspond à la transformation
par règles, wnumbers à la transformation algorithmique de reconstitution des nombres, wtagger à la transformation statistique applicant les modèles du TreeTagger. Les paramètres -F et -T gèrent les formats d’entrée/sortie, les autres paramètres sélectionnent les méthodes d’application.
– En cas de crash causé par un bug du moteur, il n’était pas toujours facile d’isoler laquelle des étapes posait problème.
Elle avait cependant l’avantage d’être naturellement parallèle, chaque transformation pouvant po-tentiellement s’exécuter sur un processeur différent des autres. Cependant le temps pris par chaque transformation peut être très déséquilibré et le système se retrouve en pratique limité par la vitesse de la plus lente des transformations.
Pour remédier à ces différents problèmes, nous avons décidé d’intégrer la notion de système complet dans le moteur. Un mini-langage s’appuyant sur lua [Ierusalimschy, et al. 1996] permet de décrire les différentes étapes de l’analyse ainsi que les chemins d’accès des différents fichiers externes utiles. Un exemple est donné figure 2.6. Cette différence peut paraître insignifiante, mais elle se révèle à l’usage très importante par ce qu’elle permet. Tout d’abord, combinée à une organisation du moteur sous forme de bibliothèque, elle permet l’intégration d’un système d’analyse dans une application l’utilisant, comme un système Question-Réponse ou un système de dialogue, sans avoir à se préoccu-per de la structure interne de l’analyse. Un seul fichier décrivant l’analyse est visible de l’application l’utilisant. Elle permet aussi d’avoir une notion de compilation, où ce fichier décrivant l’analyse est passé à un programme qui fournit à partir de là un fichier binaire contenant la totalité des informa-tions utiles ainsi que les résultats de tous les précalculs dont le moteur a besoin. Ce fichier permet ensuite de charger l’analyse en un temps et une utilisation mémoire minimale, ce qui est très com-mode pour toutes les applications qui sont simples utilisatrices de l’analyse comme par exemple les systèmes Question-Réponse présentés dans les parties suivantes. Enfin il reste possible de paralléliser le résultat non plus au niveau des étapes mais au niveau des données, en distribuant les phrases ou les documents aux différents processeurs disponibles, avec pour effet qu’aucun processeur ne va faire
# !/people/.../bin/wmatch h = "/people/.../system" paths.regles = h.."/regles" paths.treetagger = h.."/par" r = input() r = match_left_recurse(r, "sp-num.wm") r = numbers(r)
r = treetagger_semideep(r, "spanish-par-linux-3.1.bin", "sp-mapping.txt") r = match_global_replace(r, "type-question.wm")
r = match_global_replace(r, "sp-date-time.wm") r = match_global_replace(r, "org.wm")
r = match_global_replace(r, "loc.wm") output(r)
FIG. 2.6 – Exemple de système d’analyse sous forme intégrée. Les fonctions match correspondent à la
transformation par règles, numbers à la transformation algorithmique de reconstitution des nombres, treetagger à la transformation statistique applicant les modèles du TreeTagger. Le nom des fonctions indique la méthode d’application, les formats d’entrée/sortie ne sont pas sélectionés à ce niveau.
attendre les autres.
Nous sommes arrivés à la conclusion que proposer la possibilité d’avoir une version packagée de l’analyse était bien plus qu’un simple plus au niveau des performances ou du débogage. Elle per-mettait une abstraction de l’analyse. Cette abstraction facilite l’utilisation boite-noire d’une analyse et ainsi la collaboration entre plusieurs personnes travaillant sur des aspects différents d’un système. Elle permet aussi la création d’outils de diagnostic capables de répondre à des questions telles que qu’est-ce qui dans l’analyse a décidé que cette instance du mot avocat était un fruit ? en permet-tant de reproduire et de contrôler la totalité des changements de la représentation effectués par les transformations.
Chapitre 3
Aspects algorithmiques
Après avoir exposé la spécification de notre moteur d’analyse nous abordons ici les problèmes d’im-plémentation. En particulier certains aspects spécifiques ont un effet primordial pour sa qualité du résultat : l’encodage de la représentation et en particulier la représentation des mots et des catégories, et les difficultés liées au moteur de règles.
3.1 Encodage de la représentation
Un premier aspect fondamental concerne l’encodage de la représentation de l’état de l’analyse. La structure elle-même ne pose pas de problème particulier, il ne s’agit que d’un vecteur d’objets nœuds pouvant récursivement contenir un vecteur de nœuds dérivés. L’encodage des mots est plus critique. En effet une grande partie des opérations effectuées par les transformations consistent à comparer si un mot de la représentation est identique à un mot particulier, venant des règles ou des modèles, ou encore chercher si un mot fait partie d’une table et si oui accéder aux informations associées. Comparer sans cesse des chaînes de caractères n’est pas très efficace et il est plus judicieux d’associer à chaque mot un identifiant numérique.
3.1.1 Attribution d’identifiants numériques aux mots
Deux méthodes principales existent pour associer un identifiant à un objet : recenser l’ensemble des objets possibles et leur associer à chacun un numéro, ou construire algorithmiquement un nombre à partir de la valeur de l’objet en espérant que deux valeurs différentes ne donneront pas en pratique le même numéro. La seconde méthode est souvent qualifiée de hachage.
A priori il n’est pas possible de prévoir l’ensemble des mots possibles, d’autant plus quand la défi-nition de mot est ensemble de caractères entre deux espaces. Cela pousserait donc vers la solution de hachage. Cependant elle n’est pas sans inconvénients. En effet, pour réduire la probabilité de col-lision à un niveau acceptable la valeur maximale produite par une fonction de hachage doit être au minimum le carré du nombre d’objets différents attendus. Cela implique des valeurs de 64 bits pour couvrir les mots de la langue, 32 bits étant insuffisant, plaçant la limite autour de 65 000 mots, et les tailles intermédiaires étant sous-optimales dans les architectures modernes. Une valeur de 64 bits est efficace pour les comparaisons d’égalité mais elle est potentiellement trop grande pour servir d’index dans un tableau, obligeant à recourir à des structures plus lentes telles les tables de hash pour trouver les informations associées à un mot.
Mais en pratique une variante du recensement est possible : recenser l’ensemble des mots présents dans les règles, modèles et dictionnaires utilisés dans les transformations et associer à chacun un numéro. En pratique nos analyses les plus importantes ont un vocabulaire d’environ 1,5 million de mots. Les inévitables mots de documents qui n’entrent pas dans ce vocabulaire sont regroupés sur un numéro spécial et un emplacement est prévu dans la structure nœud pour mettre le texte effectif. Cette méthode est en pratique très efficace car un mot ayant cet identifiant hors vocabulaire ne peut pas être dans les règles ou les tables, garantissant la validité de la comparaison des identifiants pour comparer l’identité des mots à partir du moment où un des mots comparés vient des règles ou modèles. De même il ne peut avoir d’informations associées pour des raisons identiques.
3.1.2 Gestion des catégories
Un autre aspect important du contenu des nœuds est la gestion des catégories. Ces classes de mots, décrites à la section 2.2, contiennent des types prédéfinis tels que tout en majuscules, tout en minus-cules, commençant par une majuscule, mais aussi des intervalles de nombres, cardinaux ou ordinaux. Tester ces classes à chaque fois qu’il y en a besoin serait inefficace, et il est plus performant de le faire au moment de la lecture du document et quand le contenu de nœuds est modifié par une transfor-mation. À chaque catégorie simple est associé un numéro et le nœud contient la liste de numéros de catégories qui lui sont associés. Seuls les intervalles numériques pourraient a priori poser problème. Mais en pratique il est possible de recenser l’ensemble des intervalles utilisés, faire l’inventaire de leurs bornes et s’en servir pour décomposer l’ensemble des entiers en segments disjoints tels que chaque intervalle soit exactement composé d’un ensemble fini de segments. Les segments sont alors considérés comme des catégories élémentaires et numérotés. Les références aux intervalles dans les règles sont remplacées par une union de références aux segments les composant. La classification d’un nombre ne demande alors qu’à rechercher dans quel segment il est contenu, ce qui peut être fait efficacement de manière dichotomique.