1.      II.3.1.  mise en perspective

 1.1.      II.3.1.1.  essai de langages

Il n'existe pas de langages de programmation spécifiquement dédiés à l’ingénierie linguistique qui soient réputés, comme Lisp et Prolog le sont pour l’intelligence artificielle. Ces derniers possèdent par ailleurs une analogie avec la linguistique, celle d’un code calqué sur le langage naturel, et va peut-être un peu plus loin puisque que Prolog serait : « conçu au départ dans une perspective de TAL. » (Miller, 1990 : 20). Une autre analogie concerne SQL, avec des instructions au sens explicite et une construction syntaxique proche de la grammaticalité, mais SQL est un langage de requête pour base de données, pas de programmation.

Le choix d’un langage se portera tout naturellement vers un code orienté sur le traitement de chaînes de caractère et sur des librairies les plus spécialisées : « TCL excelle par ailleurs dans le traitement des chaînes de caractère et donc, de manière générale, dans la manipulation de texte » (Desgroupes, 2002 : XVII). Outre TCL est Perl, dans lequel a été développé Winbrill, un catégoriseur fréquemment cité. Quoique concurrencé par PHP, il est particulièrement utilisé pour l’écriture des requêtes que l’on peut trouver dans les pages de la toile, appelées CGI (Common Gateway Interface) et donc du traitement textuel.

Les possibilités de langage sont multiples : Hyperbase, logiciel de lexicométrie, est développé en Tcl/Tk ; Qtag, un autre catégoriseur, en Java ; Alceste, toujours en lexicométrie, possède le cœur de son programme en Fortran, et le reste comme l’interface graphique ou la gestion des fichiers en C++ ; enfin Antidote : « est généré par la compilation de cinq couches de code source : les données linguistiques, les algorithmes linguistiques (programmés directement par les linguistes dans un métalangage orienté-objet opérant sur les mots et les arbres), les algorithmes généraux (codés en C++), les modules d’interface aux logiciels externes (codés en divers langages d’interface comme AppleScript, VBA et autres) et l’interface utilisateur (recodée nativement pour chaque plateforme). » (Brunelle, 2004 : 27). Chacun possède de toute façon les outils de base de traitement du texte, comme les expressions régulières pour le texte à l'état initial, les tableaux, une fois le texte découpé, et les requêtes de base de données, pour un texte transformé dans un format comme XML ou SQL. Autre facteur, la rapidité.

Les langages cités possèdent le point commun d'être des scripts, appelés aussi de haut niveau, c'est-à-dire lents, et en définitive inadaptés au traitement d’importantes quantités de corpus. Il existe de multiples façons d'y pallier, par exemple une fois un texte transformé en format SQL, la rapidité d'une requête est remarquable, mais rien de satisfaisant comparé aux langages dit de bas niveau, comme le C/C++. La lenteur peut apparaître insurmontable, mais les atouts des langages scripts sont ailleurs. Cette lenteur est toute relative si l’on songe que le programme va chercher des informations dans des centaines de mégaoctets de texte ou parcourt dans sa totalité un corpus avec des boucles imbriquées dans des procédures imbriquées pouvant atteindre plusieurs millions de tests, la qualité de l'algorithme y joue alors pour beaucoup.

Pour notre réalisation, le langage “idéal” a été déterminé en essayant d’exploiter plusieurs d’entre eux jusqu’à ce que se dégage le plus approprié. Les connaissances en informatique avant cette entreprise tenaient de la génération Basic des années 80, puis de brico-PC, d'aucune entreprise de longue haleine. Les essais, début 2000, en Visual Basic 6.0, en C++ avec des interfaces comme CVI 5.5 LabWindows et Builder 6.0, avec JavaBuilder 3.0, et sous WinDev 7.0 ont montré les difficultés de rentabiliser en autodidacte un langage de programmation en plus de son interface. JavaScript et PHP n’étaient a priori pas adaptés puisque consacrés à des applications internet. Il s’agissait de rendre disponible l’application sur la toile dans un second temps, et non un objectif réseau proprement dit. Les essais de langages mixtes internet/fixe avec Java de Sun, (pour une programmation directe via les applets sur le navigateur internet) et avec Perl se sont révélés infructueux, rebuté par leur installation, une difficulté de rédaction et donc de rendement. Python a montré qu’il était assez aisé à rendre productif en un temps satisfaisant, grâce à sa documentation, la sobriété de son interface et sa convivialité. Sans être un banc d’essai, c’est du moins un tâtonnement qui a présidé à la rédaction de notre programme de catégorisation.

 1.2.      II.3.1.2.  rapidité d’exécution

Le résultat de la catégorisation aboutit au bout de quelques dizaines de secondes pour une phrase à quelques dizaines de minutes par page, soit environ un mot par seconde. Suffisant pour tester les règles, suffisant aussi pour étiqueter un texte comme Candide pour quelque 40.000 formes, en une nuit ; trop faible pour un traitement en temps réel d’un texte complet en ligne sur la toile ; suffisant pour désambiguïser des portions de texte issues d'un flux.

Les essais consistant à accroître la rapidité du programme se sont révélés minces. Antidote radical, la reprise de l’organisation du programme, l'algorithme, serait coûteuse en temps, et risque une impasse : « Notre mesure habituelle de l’efficacité est la vitesse, c’est-à-dire la durée d’un algorithme à produire ses résultats. Il existe des problèmes, cependant, pour lesquels l’on ne connaît aucune solution efficace. » (Cormen, 1994 : 7). Cette « impasse » pourrait provenir de le principe de la combinatoire et l'épuisement de ses possibilités, indispensables à notre stratégie de résolution, et contribuant à la lenteur (répétition et variable, § III.1.4.2). Le passage d'un code procédural à un code objet apporterait certainement un gain de rapidité et d'accessibilité. En introduisant des processus comme l'intelligence articificiel pour déterminer le meilleur chemin que doivent emprunter les règles, sans pour autant modifier l'algorithme initial, la performance pourrait s'améliorer et la réflexion sur la catégorisation s'enrichir. Quoi qu'il en soit, repenser la programmation serait plus une amélioration du concept initial, que l'espoir de passer du seuil de l'heure à celui de la seconde. Une bibliothèque dédiée au langage naturel NLTK, se heurte au même problème : « La limite principale de la bibliothèque NLTK est les performances de Python en termes de vitesse de calcul. » (Critique du livre par la rédaction développez.com par Franck Dernoncourt).

Il n'est pas possible de modifier le programme en profondeur, en abandonnant par exemple les listes pour les chaînes de caractères, à peu près dix fois plus rapides en Python, bien que la chasse aux opérations redondantes ou inutiles aient allégé le traitement. Pour notre programme, la fermeture des fichiers en mémoire ou la compilation n'a pas donné de résultats. L'essai de modules spécifiques pour l'accélération, comme Psyco, a amélioré de manière significative le traitement des chaînes, mais son importance est limitée face aux listes. Le changement de version de Python de 2.1 à 2.3 a permis grosso modo un gain de l’ordre de 10%, et le passage du 2.3 à 2.4 (version de novembre 2004) de 15%, et la version 2.5 (18 avril 2007, présentée comme plus rapide, 15 sec. pour 15 mots) par rapport à la 2.2a (20 sec. pour 15 mots), de 25%. L'avenir immédiat de notre programme appartient aux capacités du microprocesseur, aux nouvelles versions du langage prenant significativement en compte cette dimension, ou encore à la réécriture en un autre langage. Il existe d'autres modules appelés Swig ou Boost.Python, qui servent d’intermédiaire dans l’écriture des morceaux du programme en C pour les inclure dans la chaîne du traitement, ou PyPy qui se présente comme traduisant le code en C . Démarche malgré tout peu simple pour Swig, qui implique notamment de travailler sous Linux, ou de posséder le langage Visual C# sous Windows.

Si l’on envisage d’écrire le même programme en C++, ou en morceaux, il convient de considérer que Python est parfois décrit comme un langage de prototype, avant d’envisager une rédaction plus complexe, ce qui est le cas ici pour une recherche ambitieuse impliquant des dimensions syntaxiques et sémantiques. La rapidité de rédaction est évidente et il est peu probable que le projet ait été mené aussi loin avec un langage de bas niveau. Python n’est pas destiné à seulement gérer de petits projets et des sites webs. Enfin, il n’était pas évident lors du commencement de la rédaction que la question de la rapidité allait se poser de manière saillante. Le remplacement des boucles par des requêtes type base de données relationnelle deviendrait une autre stratégie, et il serait alors encore plus pertinent, bien qu'ambitieux, de franchir un cap dans l’approche en programmation en imaginant tout le code en expressions régulières et l'envisager en langage à part entière, envisageant une analogie linguistique, proche de la requête type SQL. Enfin l'on pourrait songer aux outils de compilation ou à l’assembleur, dans la mesure où le nombre d’instructions du moteur d'inférence est relativement limité..

 1.3.      II.3.1.3.  comparaison entre PHP et Python

Il est délicat d’affirmer que tel langage de programmation serait plus indiqué pour le traitement du texte. Opérer des comparaisons entre langages sur ce point peut rapidement devenir compliqué. Ce sont plutôt le talent du programmeur à optimiser les jeux d’instructions, la vitalité de la communauté des programmeurs autour de ce sujet, et des librairies existantes, qui pourraient être convainquants. À l’usage, un argument peut faire pencher la balance du choix, celui des manipulations courantes, comme le découpage de base des chaînes de caractères. C'est-à-dire les facilités de base qui sont proposées au programmeur pour créer ses propres outils. Ici PHP ne semble pas le plus pertinent puisqu’il possède des jeux d’instructions peu homogènes tandis que Python les associe directement aux variables. Ce qui est une conséquence du fait que Python soit un langage objet en natif. C’est peut-être cela qui confère un sentiment dit d’élégance lors de la programmation dans ce langage, tandis que PHP donne au contraire le sentiment de considérer que le texte est un domaine comme un autre de la programmation, fait d'instructions disparates. Il est possible de réaliser les mêmes programmes en PHP et en Python, cela étant le propre des langages récents, qui plus est pour un domaine basique comme le texte. Au crédit de PHP, il semble qu'il ait plus d’instructions spécifiques, en tout cas natives. Celles-ci évitent la référence aux modules et l’adaptation de commandes de base, parfois sous forme d’astuces, ce qui est le cas pour Python. Mais si les instructions de PHP peuvent paraître plus détaillées, plus pédagogiques ou plus nombreuses, sa non-homogénéité de la programmation du texte provoque l’écueil d’avoir à plonger à un nouveau concept à l'apprentissage d'une nouvelle instruction et l'articuler avec une autre voisine, sans passerelle. Ces aspects de nouveaux concepts et d’articulation d’instructions étant de même notables pour JavaScript, et ce malgré la possibilité de transformer les instructions en objet. À l’inverse, la philosophie de Python repose sur le traitement des chaînes de caractères, avec les chaînes et les listes. Elles sont des concepts proches des variables et s’imbriquent aisément. PHP s’en tient à une approche qui fait du texte un paramètre à traiter d’un bloc. Le niveau de traitement des chaînes en groupe amène à utiliser la notion de tableau pour PHP et celle de liste pour Python. PHP doit faire appel à une instruction pour chaque manipulation de placement là où Python se contente d'opérations arithmétiques avec des crochets. À titre d’exemple, en PHP, pour l'insertion à l'intérieur d'un tableau, il faudrait faire appel à une instruction du type array_insert, ce qui est déjà un peu lourd pour une manipulation élémentaire, or celle-ci n'existe pas (ni en PHP 5) et implique une fonction dédiée de découpage puis de fusion, ou l’emploi de array_splice (PHP 5) ou array_push, mais surtout se complique singulièrement si l'on manipule des tableaux imbriqués. Peut-être que la philosophie de PHP est de considérer que le traitement complexe du texte passe nécessairement par les bases de données. Cette approche est critiquable par sa lourdeur pour les manipulations de complexité intermédiaire.

Vu la variété et la spécificité de la programmation de la langue, un socle solide d’instructions de base et manipulations élémentaires portant sur le texte apparaît comme le plus approprié à la réalisation de fonctions de qualités, ce qui est le cas pour Python.

La démonstration qui précède porte sur le langage en temps que tel. Comme évoqué en préambule, un autre critère pour une comparaison d'outils de programmation est l'existence d'extensions, de librairies ou de modules dédiés au traitement du texte ou spécifiquement au langage naturel. Il resterait donc à établir un catalogue comparatif des librairies pour les deux langages. Exercice en soi difficile, consistant à mettre sur le même plan une myriade d'outils différents. Les communautés PHP et Python sont dynamiques. Tous deux sont indirectement riches pour le TAL, de par leur proximité avec les programmes de traitement d'information et les applications autour d'internet, lesquelles consistent pour beaucoup à des opérations autour du texte : récupération, harmonisation, triage etc... Le TAL étant un domaine expérimental, spécialisé, et aux perspectives variées, établir un palmarès des librairies peut-être salvateur pour un domaine du TAL, mais n'est pas nécessairement le critère pertinent pour une approche globale ou à l’inverse pluri-domaine, évolutive et native.

 1.4.    Bibliographie

 1.5.    Liens