Chaîne de traitement pour une approche discursive de l'analyse d'opinion
EDU‐ CDU 24 CDU‐CDU
3. Architecture du système : l'analyse fine de l'opinion locale comme support
3.3. Environnement technique : vers un langage de règles compatible avec une chaîne industrialisée
3.3.1. Plate‐forme d'exécution
3.3.2.3. Myéline : un langage de règles à visée industrielle
Myéline est un langage de règles développé dans le cadre de cette thèse et du projet CASOAR, soutenu par la DGA. Spécifique au traitement du langage, il répond à un besoin de Synapse Développement allant au‐delà de l’analyse d’opinion : il permet, comme Jape, de déclarer des règles métiers exploitant des primitives sur le langage – analyse syntaxique, lexiques – ce qui permet de développer des modules dont la maintenance et l’évolution sont grandement simplifiées. Le principal avantage de Myéline est sa grande expressivité : le fait de pouvoir faire appel aux variables dès leur affectation dans la partie conditions permet de corriger le défaut de Jape relevé en section précédente.
Le langage Myéline a été développé prioritairement avec pour plate‐forme cible le module d’analyse syntaxique de Synapse Développement : le prototype du compilateur Myéline a été
développé pour cette plate‐forme cible. Dans une optique d’industrialisation, une compatibilité avec UIMA est également prévue, mais n’est pas encore disponible. Éléments de syntaxe Une règle Myéline se compose de deux parties. La partie condition regroupe les contraintes sur le texte rencontré pour déclencher l’application de la règle. La partie action décrit ce qui est effectué lorsque la règle est déclenchée – typiquement, la création d’une annotation. Exemple : Structure d'une règle Myéline Rule:<Rulename> { <Condition> } => { <Action> } L’unité de base d’une condition de règle Myéline est le Token. La partie condition est séparée en plusieurs sous‐conditions, chacune entre parenthèses. Chaque nouvelle sous‐condition concerne le Token suivant immédiatement celui concerné par la condition précédente. Exemple : Détail structure condition Rule: <Rulename> {
(<Contenu Sous-Condition 1 – concerne le premier Token>)
(<Contenu Sous-Condition 2 – concerne le second Token>)
…
(<Contenu Sous-Condition N – conerne le N-ième Token>)
}
=>
…
Dans chaque sous‐condition, il est possible de faire référence au Token courant via le mot‐clé Token. Plusieurs primitives lui sont associées : entre autres, pos (nature grammaticale), function (fonction syntaxique), lemma (lemme)… Le tableau suivant regroupe les principales primitives du langage associées à un Token.
113 Architecture du système : l'analyse fine de l'opinion locale comme support de remontée de l'opinion globale Token.pos Part of Speech (nature grammaticale) Token.lemma Lemme du mot Token.function Fonction grammaticale Token.startOffset Offset de début du mot Token.endOffset Offset de fin du mot Token.string Chaîne de caractères du mot Token.numProp Numéro de la proposition en cours Tableau 3.12 : Quelques primitives usuelles du Token Un Token ou un trait peut être stocké dans une variable. Une fois une variable initialisée, celle‐ci peut‐être utilisée directement : par conséquent, il est possible de vérifier dès la partie condition des propriétés entre Tokens successifs.
Exemple : Utilisation de variable pour résoudre le problème de regroupement de proposition. Syntaxiquement, l'opérateur ":" permet l'affectation dans une variable, et les variables sont identifiés par un '$'. L'opération d'affectation présente dans la sous‐condition étoilée (fermeture de Kleene (Ebbinghaus, Flum, and Thomas 1994, 656) est réalisée pour chaque nouveau Token découvert correspondant à la contrainte. La directive #define permet de définir un type
d'Annotation, la directive #RULENAME est une macro donnant le nom de la règle en cours.
#define Proposition(num, ruleName)
Rule: NumProp
{
(Token:$first && Token.numProp:$num)
(Token:$last && Token.numProp==$num)*
(Token:$last && Token.pos==PCT)?
}
=>
{
Proposition($first.startOffset, $end.endOffset, $num, #RULENAME);
} Chacun des objets manipulés possède un type : le tableau suivant décrit les types Myéline, et leur équivalent en C++ (plate‐forme cible Synapse Etiquette). Le type de chaque variable est calculé dynamiquement.
Type Myéline Type C/C++ Token int (identifiant interne)
Int int
String char *
Bool int ( 0 ou 1 )
Char char StoredTag myeline::Annotation * List myeline::List * Tableau 3.13 : Types Myélines et leurs équivalents pour la plate‐forme cible Synapse Étiquette Il est possible de faire appel, dans la partie condition comme dans la partie action, à des portions de code source externe, spécifique à la plate‐forme cible : cette possibilité est nécessaire afin de permettre des fonctionnalités avancées n’ayant pas vocation à faire partie du langage, comme par exemple une connexion à une base de données externes. Cet appel est possible via la déclaration de fonctions externes. Le type des paramètres comme celui de la valeur de retour de la fonction doivent être déclarés en Myéline, ce qui permet l’intégration directe de la fonction au langage. Ainsi, si l’on dispose d’une implémentation spécifique à chaque plate‐forme pour toutes les fonctions externes d’un module Myéline, le même code Myéline est compilable vers chacune de ces plates‐formes.
Exemple : Reprise de la règle Myéline précédente, avec ajout d'une fonction externe permettant de tracer l'application de la règle (par exemple, pour tracer dans un journal l'application des règles). Syntaxiquement, la directive import permet de déclarer une fonction externe.
La fonction externe de cet exemple – TraceRule – doit exister pour la plate‐forme cible, mais
le concepteur de la règle n'a pas à maîtriser cette implémentation : celle‐ci peut avoir été effectuée en amont par un informaticien – de même, cet informaticien n'a pas à maîtriser les détails linguistiques des règles appelantes.
#define Proposition(num, ruleName)
Import Bool TraceRule(Token, Token, String)
Rule: NumProp_Trace
{
(Token:$first && Token.numProp:$num)
(Token:$last && Token.numProp==$num)*
(Token:$last && Token.pos==PCT)?
}
115
Architecture du système : l'analyse fine de l'opinion locale comme support de remontée de l'opinion globale
{
Proposition($first.startOffset, $end.endOffset, $num, #RULENAME);
TraceRule($first, $last, #RULENAME) ;
}
Réalisation technique
Le compilateur Myéline a été réalisé en Java via l’analyseur lexical JFlex36, et l'analyseur syntaxique Cup37. Le compilateur génère un module C++ pour la plate‐forme Synapse Etiquette, directement
intégrable dans un projet Microsoft Visual Studio. Pour la plate‐forme UIMA, le compilateur génère un annotateur (Analysis Engine) Java, ainsi que les types d’annotations associés. Conclusion Le tableau suivant présente les avantages et inconvénients de Myéline. Adéquation Excellente : langage spécifique permettant de déclarer des règles à un bon niveau d'abstraction. Simplicité Bonne : Je pense que le langage Myéline est relativement intuitif, mais je ne suis pas le mieux placé pour l'évaluer.
Les décrochages en langage source sont empaquetés dans une déclaration Myéline : le concepteur de la règle n'est pas tenu de connaître le langage source et l'API interne de la plate‐forme cible.
Expressivité Bonne
Portabilité Excellente (théoriquement) – Correcte (en pratique) : Le code est portable, moyennant l'existence d'un compilateur pour la plate‐ forme cible. Tableau 3.14 : Avantages et inconvénients de Myéline Myéline a été spécifiquement conçu pour corriger certains défauts de Jape, et répondre ainsi aux besoins de Synapse Développement dans le cadre de nos travaux de recherche. Les spécifications du langage et le compilateur du langage ont été réalisés dans le cadre de cette thèse.
3.3.3.
Choix final d’architecture
En regard des contraintes techniques et des besoins d’industrialisation de la chaîne de traitement, il a été fait le choix d’utiliser la plate‐forme interne de Synapse Développement, et de développer le langage Myéline pour faciliter la maintenance de la chaîne de traitement. Le Tableau 3.15 résume les caractéristiques de ce choix. 36 http://jflex.de/ 37 http://www2.cs.tum.edu/projects/cup/Prototypage
Outils disponibles
Mitigée :
Pour : accès direct aux modules de Synapse Développement
Contre : des passerelles sont à développées pour la plupart des outils externes.
Abstraction des objets Excellente : les structures de données internes permettent la gestion de texte.
Industrialisation
Portabilité
Bonne ‐ Correcte :
Les modules Myéline sont potentiellement portables
Les modules et fonctions en C++ sont spécifiques, disponible Linux/Windows sous réserve de non‐utilisation de fonctions systèmes dans les parties spécifiques à l’extraction d’opinion. Légèreté Bonne : ne nécessite que l’installation de la
chaîne de traitement.
Possibilités d’optimisation Excellente : accès direct aux structures internes, permettant une optimisation poussée
Scalabilité
Bonne : maîtrise de la taille maximale des fichiers (segmentation en sous‐fichier envisageable). Exécution parallèle envisageable.
Licence OK dans le contexte de la thèse CIFRE.
Maintenance
Facilité
Bonne : Myéline assouplit considérablement la maintenance corrective, qui peut désormais être effectuée sans connaissances poussées de l'API interne.
Adaptabilité
Correcte : les modules sont compilés vis à vis du reste de la chaîne, mais sous forme de bibliothèques indépendantes.
Tableau 3.15 : Récapitulatif des avantages et inconvénients de l'environnement d'exécution final
Dans le cadre des expérimentations préliminaires, les algorithmes ont néanmoins parfois été préalablement testés sur d’autres plates‐formes, pour des raisons pratiques. En effet, ces prototypes n’ont pas à répondre aux problématiques d’industrialisation évoquées dans cette section. De plus, le développement de Myéline s’est réalisé tout au long de la thèse, et la plate‐ forme finale n’était pas nécessairement disponible au moment des expérimentations.
3.4. Conclusion
Dans cette section, nous avons pu voir l'architecture générale de la chaîne d'extraction de l'opinion. Cette chaîne comprend :
‐ un module de segmentation discursive, adapté de (Afantenos et al. 2010) pour l'analyseur syntaxique de Synapse Développement (Laurent, Nègre, and Séguéla 2009). L'évaluation de ce module montre des performances similaires à celles de (Afantenos et al. 2010) sur le corpus segmenté discursivement du projet ANNODIS
117 Architecture du système : l'analyse fine de l'opinion locale comme support de remontée de l'opinion globale (Péry‐Woodley et al. 2009), et légèrement supérieures sur le corpus de commentaires web issus du projet CASOAR (cf. chapitre 2). ‐ Un module de détection de la subjectivité des segments discursifs, détaillé au chapitre 5. ‐ Un module de repérage local des expressions à l'intérieur de chaque segment basé sur un lexique d'opinion présenté au chapitre 4. ‐ Un module de calcul local permettant de remonter les attributs de l'opinion du niveau de l'expression au niveau du segment en prenant en compte les opérateurs s'appliquant sur les opinions. Ce module peut‐être décomposé en deux sous‐tâches, l'une de détermination de la portée de chaque opérateur, l'autre de calcul des attributs résultants de l'application du ou des opérateurs. Ces deux composantes seront décrites au cours du chapitre 6.
‐ Un module de calcul de l'opinion globale au niveau du document, permettant la fusion des informations d'opinion en une seule valeur globale. Ce module sera abordé au chapitre 7.
Dans le cadre du contrat de thèse CIFRE, l'architecture utilisée devait répondre à plusieurs contraintes, notamment en matière d'industrialisation de la chaîne, et de confort de maintenance. Pour cela, après étude des différentes options disponibles, nous nous sommes décidés pour une architecture intégrée à la chaîne d'analyse syntaxique de Synapse Développement. Afin de permettre une maintenance corrective et adaptative aisée, nous avons également décidé de nous lancer dans la conception de notre propre langage de règles, Myéline. Ce langage, spécialisé dans le traitement du langage naturel, possède deux principaux avantages sur le langage Jape de la plateforme GATE : il est d'une part légèrement plus expressif, en permettant des références croisées via des variables dans la partie condition de la règle, et d'autre part potentiellement plus portable, en introduisant une couche intermédiaire de déclaration pour les usages de code externe spécifique à la plateforme.
119
Architecture du système : l'analyse fine de l'opinion locale comme support de remontée de l'opinion globale