Embed Size (px)
Citation preview
Ecole Centrale Marseille LOGICA
38 rue Frédéric Joliot Curie 310 rue du Vallon
13013 Marseille 06560 Sophia Antipolis
France France
Travail de Fin d’Etudes
Du 26/03/12 au 26/09/12
Développement d’un prototype
de type « robot chat »
basé sur le traitement
du langage naturel
Samuel Lefèvre
3ème
année promotion 2012
Parcours S2I
Tuteur école : Tuteur Entreprise :
François Brucker Adil Zaid
2
Samuel LEFEVRE
3
Samuel LEFEVRE
Remerciements :
Je remercie chaleureusement toutes les personnes grâce à qui ce stage a pu se dérouler dans
les meilleures conditions, et plus particulièrement :
Adil Zaid, mon maître de stage,
Arnaud David, directeur de projet qui m’a accueilli à mon arrivée à LOGICA,
Blandine Corbier, qui m’a aidé à me préparer pour les entretiens d’embauche,
Guillaume Floyrac, qui m’a accompagné au long du processus d’embauche,
Violaine Perbost, qui s’est chargée de mon recrutement,
Aziz Kezzou, qui représente le client,
Prashant Balasubramanyan, qui nous a apporté son aide tout au long du stage,
Jean-Michel Durand, stagiaire avec qui j’ai travaillé sur ce projet,
Nicolas Duthoit, stagiaire qui a travaillé sur le projet de développement iPad,
sans oublier tous les collaborateurs que j’ai rencontrés et qui ont contribué à mon
intégration et au bon déroulement de ce projet.
4
Samuel LEFEVRE
Résumé :
Ce rapport décrit le déroulement de mon stage de fin d’études au sein de l’entreprise
LOGICA. Mon objectif était de développer un prototype d’application de type « robot chat »
basé sur le traitement du langage naturel, afin d’apporter du support aux équipes du client
AMADEUS. Cette mission a été réalisée en binôme avec Jean-Michel Durand, stagiaire issu
de l’Ecole Nationale Supérieure des Mines de Saint Etienne. Au travers de l’étude de l’état de
l’art, de l’analyse du besoin et du développement d’un prototype, nous avons été confrontés
aux problématiques de l’analyse et de la compréhension du langage naturel par l’ordinateur,
mais également de l’indexation et de l’extraction d’information des documents.
Abstract :
This report describes the different aspects of my third and last internship which took place at
LOGICA. My objective was to develop a “robot chat” application prototype based on natural
language processing, in order to provide support to the teams of the client AMADEUS.
During this mission I worked together with Jean-Michel Durand, who is a trainee from the
Ecole Nationale Supérieure des Mines de Saint Etienne. While making the state-of-the-art
study, the analysis of the needs and the development of the prototype we came across the
issues of the analysis and the understanding of natural language by a computer, as well as the
issues of indexing and extracting information from documents.
Mots-clés : Traitement du langage naturel – LOGICA – AMADEUS – Robot chat –
indexation – moteur de recherche
Keywords : Natural language processing – LOGICA – AMADEUS – Chat Robot – Indexing
– Search engine
5
Samuel LEFEVRE
Glossaire :
ATC = Amadeus Test Coordination: Equipe d’Amadeus chargée de rediriger les PTR
lies à des incidents en phase de test.
BE = Back end: Serveur utilisé pour tester les produits.
EDIFACT = Electronic Data Interchange for Administration, Commerce and
Transport: Un des formats de données utilisés par Amadeus pour communiquer.
GATE = General Architecture for Text Engineering: Solution open source complète
pour le traitement du langage naturel.
MDW = Middleware Development and Support: Equipe d’Amadeus en charge des
middlewares.
NLP = Natural Language Processing: Traitement du langage naturel ; au sens strict,
analyse syntaxique du langage naturel ; au sens large, inclus également l’analyse sémantique.
OTF = Un des moteurs de backend d’Amadeus ; fait également référence à l’équipe
en charge de ce BE.
OWL = Web Ontology Language: famille de langages de représentation de
connaissance utilisé pour la création d’ontologie, basée sur les RDFS.
PoC = Point of Contact: Personne à contacter dans le cadre d’un problème spécifique.
PoC = Proof of Concept: Prototype.
PoS = Part of Speech: Catégorie lexicale de mots ou de groupes de mots.
PRL = PNR Retrieve and List: Une des équipes d’Amadeus en charge de la gestion
des PNR.
PRN = Passenger Name Record: regroupe des données variées permettant
l’identification d’une réservation pour un vol, une location…
PTR = Problem Tracking Record: Utilisé par Amadeus pour signaler des problèmes
rencontrés, lorsque l’impact est limité à une seule équipe.
RDF = Resource Description Framework: famille de spécifications utilisée pour la
description de concepts ou la modélisation de l’information.
RDFS = RDF Schema: Ensemble de classes fournissant les éléments de base pour la
description d’ontologie.
6
Samuel LEFEVRE
QA = Question answering (Méthode 1): Une des trois principales méthodes utilisées
en traitement du langage naturel.
SI = Router d’Amadeus. Fait également référence à l’équipe en charge de ce routeur.
SMC = Service Management Center : Equipe d’Amadeus chargée de centraliser et de
rediriger les PTR lies à la production.
7
Samuel LEFEVRE
Sommaire
Remerciements : ...................................................................................................................................... 3
Résumé : .................................................................................................................................................. 4
Abstract : ................................................................................................................................................. 4
Glossaire : ................................................................................................................................................ 5
Introduction ............................................................................................................................................. 9
Partie 1 : Contexte de la mission ........................................................................................................... 10
A) Présentation de l’entreprise LOGICA ................................................................................... 10
1) Présentation générale de LOGICA ........................................................................................ 10
2) La vie au sein de l’agence de Sophia Antipolis ..................................................................... 15
B) Présentation du client AMADEUS ........................................................................................ 16
1) Présentation générale d’AMADEUS ..................................................................................... 16
2) La place des collaborateurs de LOGICA chez AMADEUS .................................................. 18
C) Contexte de la mission .......................................................................................................... 19
1) Ma place au sein de LOGICA ............................................................................................... 19
2) Mise en place du projet.......................................................................................................... 20
Partie 2 ................................................................................................................................................... 22
A) Etat de l’art ............................................................................................................................ 22
1) Introduction au langage naturel ............................................................................................. 22
2) Démarche générale du traitement du langage naturel ........................................................... 23
3) Principales méthodes ............................................................................................................. 24
B) Elaboration du cahier des charges ......................................................................................... 30
1) Etude du besoin ..................................................................................................................... 30
2) Solution proposée .................................................................................................................. 32
8
Samuel LEFEVRE
C) Mise en place de la solution .................................................................................................. 33
1) Travail réalisé ........................................................................................................................ 33
2) Technologies utilisées ........................................................................................................... 34
3) Interface ................................................................................................................................. 36
4) Traitement du langage naturel .............................................................................................. 38
Conclusion ............................................................................................................................................. 42
Bibliographie ......................................................................................................................................... 43
Annexes ................................................................................................................................................. 44
9
Samuel LEFEVRE
Introduction
Ce stage de fin d’études clôt pour moi une période de trois ans en école d’ingénieur à Centrale
Marseille et m’ouvre une nouvelle période, celle de la vie professionnelle. Après une
expérience de deux mois dans une start-up marseillaise en informatique l’année précédente, je
désirais découvrir l’univers des grands groupes. Le forum entreprises organisé par mon école
m’a permis de prendre contact avec certains groupes proposant des postes dans le conseil en
informatique, et c’est finalement à LOGICA que j’ai choisi d’effectuer mon stage de fin
d’études.
Lors des entretiens, plusieurs sujets de stage m’ont été présentés. Mon choix s’est
immédiatement porté sur le projet de traitement du langage naturel, qui me paraissait lié à un
domaine qui a toujours attisé ma curiosité, la linguistique. J’étais également intéressé par le
fait d’être impliqué dans les différentes étapes du cycle de vie d’un produit. La perspective de
travailler en binôme avec un autre stagiaire m’a également semblé stimulante. Avec quelques
mois de recul je pense maintenant avoir choisi cette entreprise et ce stage pour de bonnes
raisons.
Le traitement du langage naturel s’est révélé plus complexe que je l’imaginais, et les
problématiques liées à l’indexation et à la recherche des données se sont rapidement
dévoilées. Le désormais célèbre moteur conversationnel Siri d’Apple représentait
l’application idéale que j’aspirais à développer pendant ce stage ; je me suis rapidement défait
de cette chimère en réalisant que la route est encore longue avant de pouvoir converser
véritablement avec un ordinateur.
L’objectif de ce stage est de concevoir un prototype d’application de type « robot chat » basé
sur le traitement du langage naturel afin d’apporter de l’aide aux membres des équipes du
client en répondant à leurs questions. Pour atteindre cet objectif, notre équipe a commencé par
réaliser un état de l’art pour identifier différentes méthodes et les outils existants ; une fois
cette étape franchie nous avons rencontré quelques équipes intéressées du client pour analyser
le contexte et le besoin. Cela nous a permis d’élaborer un cahier des charges, et ce n’est
qu’une fois ce dernier validé par le client que nous avons réellement commencé à développer
le prototype.
10
Samuel LEFEVRE
Partie 1 : Contexte de la mission
A) Présentation de l’entreprise LOGICA
1) Présentation générale de LOGICA
LOGICA est une entreprise européenne de services en informatique, spécialisée dans le conseil,
l’intégration de systèmes et l’outsourcing. Fondée par Len Taylor, Philip Hughes et Pat Coen business
en 1969, LOGICA s’est développée au fil des ans et des acquisitions, et réunit aujourd’hui près de
41 000 collaborateurs. Andy Green est le PDG de LOGICA depuis janvier 2008. Le siège social de
l’entreprise se trouve à Reading, au Royaume-Uni.
Implantée dans 41 pays, LOGICA s’implique auprès de ses clients, parmi lesquels figurent les plus
grandes compagnies européennes, dans des secteurs extrêmement diversifiés. Elle s'engage dans des
collaborations à long terme et exploite ses savoirs pour répondre de façon innovante aux besoins de
ses clients. LOGICA est coté à la Bourse de Londres et d'Amsterdam.
Depuis le 20 août 2012, LOGICA fait officiellement partie de CGI, une SS2I canadienne d’envergure
internationale très fortement implantée en Amérique.
L’implantation de LOGICA au plus proche de ses clients lui permet de s’imprégner de leur langue et
de leur culture, et ainsi de vendre et livrer ses services directement sur leur lieu de vie et de travail.
Figure 1 : Histoire de LOGICA
11
Samuel LEFEVRE
Figure 2 : Implantation de LOGICA dans le monde
LOGICA a développé une culture d’entreprise unique partagée par ses 41 000 collaborateurs dans 41
pays. Un engagement sans faille, une quête d’innovation continue et une ouverture d’esprit sur le
monde constituent les valeurs fondamentales de LOGICA. L’entreprise a pour ambition d’être à la
pointe de son domaine, et encourage ses collaborateurs à développer un esprit d’équipe, un esprit
d’initiative et un goût pour l’effort constants. Toutes ces valeurs se retrouvent dans son slogan : « Be
brillant together ».
12
Samuel LEFEVRE
Figure 3 : Implantation de LOGICA en Europe
Avec près de 9200 employés répartis entre 23 agences, LOGICA France est la plus grande filiale de
LOGICA en Europe. Le président de LOGICA France est Jean-Marc Lazarri. Ses agences sont
regroupées en pôles de compétences, également appelés Business Unit (BU).
Mon stage s’est déroulé au sein de l’agence de Nice, située à Sophia-Antipolis, qui compte 130
employés. Cette agence forme avec l’agence d’Aix la BU PAC (Provences Alpes Côte d’Azur). Les
clients principaux pour cette Business Unit sont : AMADEUS, AIR FRANCE, ESCOTA, VINCI, RSI,
CMA CGM, BOURBON et PRO BTP.
Principales compétences techniques de la BU PAC :
Java/J2EE, .Net, Open Source
SOA, Web services
Mainframe
C, C++, TPF
BO, Cognos, SAS
Microsoft, SAP, SIEBEL, ORACLE
13
Samuel LEFEVRE
Principaux services:
Intégration
Design, Analyse & Développement
Validation/Qualification
Test
Consulting
Project Management
Figure 4 : Implantation de LOGICA en France
14
Samuel LEFEVRE
LOGICA France a réalisé en 2011 un chiffre d’affaires de près de 1,05 milliards d’euros, ce qui la
place en 7ème position des SS2I en terme de chiffre d’affaires en France.
Figure 5 : Principaux clients de LOGICA France
15
Samuel LEFEVRE
2) La vie au sein de l’agence de Sophia Antipolis
De nombreuses activités sont organisées au sein de l’agence afin d’impliquer au maximum les
collaborateurs et de favoriser les retours d’expérience. Ces activités étant ouvertes aux stagiaires, j’ai
pu participer à la majorité de celles qui ont eu lieu au cours de mon stage.
ShAKE IT :
Retour d’expérience formel organisé sous la forme d’une conférence interne, pendant la pause
déjeuner. J’ai pu assister à un ShAKE IT sur la méthode SCRUM en avril.
Réunion d’agence :
Cet événement regroupe les agences de Sophia Antipolis et d’Aix. Le directeur de la BU
présente les résultats financiers et la marche générale de l’entreprise aux collaborateurs des agences de
cette BU. Cette année, la réunion d’agence a eu lieu le 16 avril à Mougins. Plus de 80 personnes y ont
assisté.
5a7 :
Le 5a7 est une réunion organisée par des collaborateurs désirant partager leur expérience et
leur connaissance sur un domaine particulier. Il se tient généralement une fois par mois, entre 17h et
19h. Ils sont communs aux agences d’Aix et de Sophia Antipolis et peuvent donc se dérouler par
visioconférence. J’ai pu assister aux 5a7 ayant pour thème l’assistance à la maîtrise d’ouvrage
(AMOA) et business intelligence (BI). J’ai également prévu d’organiser un 5a7 en août sur le
traitement du langage naturel.
Petit-déjeuner du CE :
Tous les mois, cet événement réunit les collaborateurs de l’agence autour d’un petit-déjeuner
convivial. Il permet également de profiter des avantages obtenus par le Comité d’Etablissement,
notamment des réductions sur des tickets (cinéma, plongée…)
Afterwork :
Une fois tous les mois, une soirée informelle est organisée pour permettre aux collaborateurs
de se retrouver et de se détendre après les horaires de travail. J’ai pu notamment participer à une soirée
« jeux de société » ainsi qu’à une soirée « blind test ».
Présentation des représentants du personnel
Une réunion officielle a été organisée pour présenter et/ou rappeler quels sont les représentants
du personnel au sein de l’agence, ainsi que leurs fonctions. Cinq entités sont représentées :
-Comité d’établissement
-Comité centrale d’entreprise
-CHSCT
-Délégué du personnel
-Délégué syndical
16
Samuel LEFEVRE
B) Présentation du client AMADEUS
1) Présentation générale d’AMADEUS
Figure 6 : Logo d'AMADEUS
AMADEUS est le client principal de LOGICA à Sophia. L’entité d’AMADEUS à Sophia s’occupe
majoritairement du développement informatique. C’est pourquoi elle emploi de nombreux consultants
en plus de ceux de LOGICA.
AMADEUS est une société spécialisée dans les systèmes informatisés de réservations aériennes et
plus globalement dans les systèmes informatisés de réservations en lien avec le voyage. Son objectif
est de proposer d’avantages de services de plus en plus innovants.
Fondée en 1987 par quatre compagnies aériennes européennes (Air France, Iberia, Lufthansa et SAS)
AMADEUS à pour but de créer une structure commune de distribution informatisée des segments
aériens puis de regrouper l'ensemble de l'offre de vente de billets d'avion, toutes compagnies
confondues. Ce genre de société, nommé "Global Distribution System" (ou GDS), compte
actuellement quatre compagnies dont AMADEUS, les trois autres étant SABRE, GALILEO et
WORDLSPAN ; ces deux dernières étant désormais regroupées au sein de la même société
TRAVELPORT.
Avec un chiffre d’affaire de 2,65 Milliards d’euros en 2010, AMADEUS compte aujourd’hui plus de
10 000 employés répartit mondialement sur 9 sites centraux : Belgique, Londres, Sophia Antipolis,
Madrid (siège social), Bangkok, Sydney, Miami, Buenos Aires et Bangkok. Les clients principaux
d’Amadeus sont tout les organismes en lien avec les voyages : on retrouve les compagnies aériennes,
les hôtels, les loueurs de voitures, les compagnies ferroviaires, les agences de voyages… pour
atteindre finalement les voyageurs individuels.
17
Samuel LEFEVRE
Figure 7 : Implantation d'AMADEUS dans le monde
Figure 8 : Connexions entre AMADEUS et l'industrie du voyage
18
Samuel LEFEVRE
2) La place des collaborateurs de LOGICA chez AMADEUS
AMADEUS est l’un des principaux clients de LOGICA sur le site de Sophia Antipolis. Près de 110
collaborateurs de LOGICA sont répartis sur des missions confiées par AMADEUS, qui consistent
principalement à :
- Rencontrer les spécialistes des clients d’AMADEUS et comprendre leurs besoins.
- Ecrire les spécifications, développer et tester les programmes utilisés pour la réservation.
- Réaliser l’intégration de nouveaux clients (airlines) sous le système d’AMADEUS.
- Réagir rapidement et efficacement face aux bugs et aux problèmes techniques et
fonctionnels.
Figure 9 : Organisation de LOGICA dans le contexte d'AMADEUS
19
Samuel LEFEVRE
C) Contexte de la mission
1) Ma place au sein de LOGICA
Le jour de mon arrivée à LOGICA, j’ai été accueilli par le directeur de projets Arnaud DAVID, qui
m’a présenté l’entreprise ainsi que le client et le contexte général de ma mission. J’ai ensuite fait la
connaissance des autres stagiaires et des collaborateurs qui travaillent sur le plateau consacré au client
AMADEUS. Le lendemain j’ai participé au premier meeting avec un représentant du client, au sujet
des attentes concernant le stage. En fin de semaine j’ai eu ma première réunion avec mon tuteur
entreprise Adil Zaid, afin de mettre en place les éléments de gestion de projet et d’enchaîner sur la
réalisation d’un état de l’art sur le traitement du langage naturel.
Concernant les conditions du stage, j’ai eu accès aux activités proposées par LOGICA comme les
activités du Comité d’Entreprise, la réunion d’agence, les Afterworks et des retours d’expériences sur
différents sujet comme la méthode SCRUM, l’Assistance à la Maîtrise d’OuvrAge (AMOA) ou la
Business Intelligence de LOGICA PAC.
LOGICA n’hésite pas à impliquer au maximum les stagiaires afin de s’assurer de leur bonne
intégration parmi ses équipes, et préparer une éventuelle embauche en fin de stage. Ainsi le 15 juin
tous les stagiaires de l’agence ont pu réaliser une présentation de leur mission et du déroulement de
leur stage à un public composé de divers responsables de LOGICA, dont le directeur d’agence, les
directeurs de projets, les responsables du recrutement et les tuteurs de stage. Cette réunion a permis
une plus grande transparence du travail mené par les stagiaires et sur les bénéfices que tous pourraient
en tirer. Elle a également amorcé une réflexion sur la poursuite de l’aventure LOGICA après le stage.
Plusieurs réunions avec les responsables chargés de recrutement ont suivi, afin de nous présenter plus
en détail le processus de recrutement de LOGICA et les différentes offres de mission proposées. Des
réunions de préparation en vue d’entretiens d’embauche pour des missions proposées par AMADEUS
ont également été organisées pour les stagiaires travaillant sur les projets pour AMADEUS.
20
Samuel LEFEVRE
2) Mise en place du projet
Au niveau de l’organisation de l’équipe, elle était faite de la façon suivante : Adil Zaid, mon maître de
stage, a à sa charge deux projets de stage en lien avec le client AMADEUS, représenté par Aziz
Kezzou : un sujet de développement iPad et un sujet sur le traitement du langage naturel.
Le projet de développement iPad est mené par le stagiaire Nicolas Duthoit, de l’Institut Supérieur
d’Electronique et du Numérique (ISEN), avec le soutient de Sébastien Robert pour la partie technique
du côté LOGICA et Alexandre Pastorelly du côté AMADEUS.
Le projet de traitement du langage naturel est mené par Jean-Michel Durand, de l’Ecole Nationale
Supérieure des Mines de Saint-Etienne, et moi-même, avec le soutient de Prashant Balasubramanyan.
Adil joue le rôle d’interface entre les projets et le client. C’est lui qui est chargé d’organiser les
réunions et de vérifier l’avancement. Enfin, notre maître de stage est sous la direction du directeur de
projet Arnaud David.
Figure 10 : Organisation des projets des stagiaires pour AMADEUS
21
Samuel LEFEVRE
Nous avons mis en place un système de rencontres régulières avec Adil et le client afin de pouvoir
déterminer le besoin dans un premier temps et prendre en compte les retours lors de la partie de
développement. Nous nous rencontrons donc toutes les deux semaines avec Adil afin de préparer les
rencontres avec le client et faire le point sur l’avancée et l’atteinte des objectifs.
Au niveau de l’organisation interne, nous avons eu un espace de partage réseau (SharePoint) entre
stagiaires, ainsi qu’un système de reporting hebdomadaire sur TeamDrive.
Au sein du projet de traitement du langage naturel nous nous sommes inspirés de l’esprit des méthodes
agiles, notamment SCRUM, pour nous organiser en prenant le temps de répartir les tâches et en faisant
un bilan régulier des points bloquants et objectifs atteints.
Nous avons passé les deux premiers mois du stage à réaliser un état de l’art sur le traitement du
langage naturel, ce qui nous a permis de découvrir de nombreux outils et approches du traitement du
texte, de l’indexation et des moteurs de recherche. Puis nous nous sommes penchés pendant un mois et
demi sur l’analyse du besoin et la réalisation du cahier des charges de l’application finale, en
organisant des rencontres avec quatre équipes d’AMADEUS susceptibles d’utiliser l’application :
PRL, ATC, SI et OTF. Une fois le cahier des charges validé par le client nous nous sommes attelés au
développement du prototype pendant le reste du stage.
22
Samuel LEFEVRE
Partie 2
A) Etat de l’art
1) Introduction au langage naturel
Cela fait quelques années maintenant que l'ordinateur a dépassé le niveau des plus grands
professionnels au jeu d'échecs ; pourtant il atteint à peine le niveau d'un enfant de cinq ans lorsqu'il
s'agit de tenir une conversation naturelle avec un être humain. En 1950 Turing envisageait qu'en 2000
il serait impossible de distinguer une conversation avec un humain et avec un ordinateur ; malgré des
avancées spectaculaires, nous en sommes encore loin. La principale difficulté à l'heure actuelle vient
du traitement du langage naturel.
Le langage naturel ne désigne pas une langue à proprement parler, mais la manière naturelle de
s'exprimer des êtres humains, par opposition au langage binaire et aux langages utilisés en
programmation. C'est le langage des mails, des descriptions, du chat...
Il existe des programmes capables de traduire un texte d'une langue à une autre, de réaliser de la
détection et de la correction des fautes d'orthographe et de grammaire de traduire un discours vocal en
texte, ainsi que d'extraire diverses informations d'un texte. Mais tout cela ne suffit pas pour qu'un
ordinateur puisse tenir une conversation aboutie avec un être humain. Le simple fait de déterminer si
deux mots sont synonymes est plus difficile que de déterminer des intégrales pour un ordinateur.
23
Samuel LEFEVRE
2) Démarche générale du traitement du langage naturel
Le traitement du langage naturel consiste à analyser un texte pour en saisir la structure ; on peut
l'assimiler au sens strict à l'analyse syntaxique d'un texte.
Les principales étapes du traitement du langage naturel sont :
- Le découpage des mots et des phrases, en se basant notamment sur des séparateurs (espaces, signes
de ponctuation...)
- L'identification du lemma, ou forme canonique du mot (i.e. went -> go, largest -> large).
- L'identification de la nature de chaque mot (déterminant, nom, verbe, adjectif...)
- L'identification des groupes de mots structurels dans une phrase (groupe nominal, groupe verbal,
proposition relative...)
Il existe des outils efficaces réalisant ces différentes tâches, la plupart pour l'anglais, mais aussi
l'allemand, l'espagnol, le danois et le français. Le plus connu dans le monde de l'open source est
OpenNLP.
Par extension, le traitement du langage naturel englobe également l'analyse sémantique d'un texte,
étape nécessaire à la compréhension et donc à la tenue d'une conversation aboutie avec un humain.
C'est également l'étape la plus difficile. L'enjeu réel est de parvenir à associer les mots entre eux par
unité de sens, identifier des règles et des modèles de langage et en déduire des règles à appliquer pour
comprendre le sens derrière les mots : en d'autre termes, mettre en œuvre une grammaire.
Figure 11 : Architecture générale d’une application de traitement du langage naturel
24
Samuel LEFEVRE
3) Principales méthodes
Plusieurs approches sont possibles pour élaborer une application capable de répondre aux questions
posées en langage naturel par l'utilisateur, voici les trois principales.
Méthode 1 : Question Answering
Figure 12 : Schéma de la méthode1 (Question Answering)
Cette méthode est celle qui se rapproche le plus d'un moteur de recherche conventionnel, comme ceux
utilisés pour effectuer des recherches sur le web. La principale différence vient du traitement du
langage naturel appliqué à l'entrée de l'utilisateur, qui recevra comme réponse une liste de documents
de pertinence décroissante. Cette méthode est donc applicable sur un ensemble de données non
structurées, comme un corpus de documents quelconques, sans format prédéfini. Elle est ainsi la plus
facile à mettre en œuvre, mais ne renverra pas de résultat exact : c'est à l'utilisateur de vérifier si la
réponse qu'il souhaite se trouve dans les documents de la liste proposée en sortie. La recherche peut se
baser sur des mots-clés, raffinée par le traitement du langage naturel. Un programme basé sur cette
méthode mais n'utilisant pas d'analyse sémantique est DocFetcher.
25
Samuel LEFEVRE
Voici un exemple d'application complet de cette méthode :
Figure 13 : Exemple d'application de la méthode1
26
Samuel LEFEVRE
Méthode 2 : Interface avec des bases de données
Figure 14 : Schéma de la méthode2 (Interface to Databases)
Comme son nom l'indique, cette méthode est efficace avec des données structurées, mais inutilisable
avec des données non structurées. Elle fait appel à une analyse syntaxique similaire à celle utilisée
pour le Question Answering, mais elle fait intervenir une analyse sémantique beaucoup plus poussée.
En effet elle nécessite l'utilisation d'une grammaire complète, et donc l'identification de patterns
spécifiques et de règles pour relier ces paterns au langage naturel de la question posée par l'utilisateur
et à la structure des données. Cette méthode renverra alors un résultat unique et exact s'il existe. Elle
est toutefois la plus délicate et fastidieuse à mettre en œuvre, puisque la grammaire doit être créée à la
main pour être en parfaite adéquation avec la structure des données. Un programme basé sur cette
méthode est WASP.
27
Samuel LEFEVRE
Voici un exemple d'application de cette méthode, avec comme question : “What is the largest river which runs through California”.
Les règles appliquées pour traiter cette question sont :
Largest (comparaison de taille)
traverse (synonyme de “run through”, associe un Etat et un fleuve)
state (identifier l’Etat de Californie)
Figure 15 : Exemple d'application de la méthode2
Une requête est formulée à partir de la question et renvoie comme résultat "Colorado".
28
Samuel LEFEVRE
Méthode 3 : Chatterbox
Figure 16 : Schéma de la méthode3 (Chatterbox)
Cette méthode est celle utilisée pour les agents conversationnels. C'est celle qui permet de se
rapprocher le plus d'une conversation aboutie entre un humain et une machine. Elle est basée sur une
base de questions et de réponses prédéfinies, qui doivent être créées à la main pour s'adapter au
contexte d'utilisation, ce qui pose des problèmes de maintenabilité. Après une analyse syntaxique et
sémantique simple de la phrase entrée par l'utilisateur, l'application décrite par cette méthode vérifiera
les correspondances avec sa base de questions prédéfinies. Si une correspondance est trouvée,
l'application va retourner la réponse correspondante et demander à l'utilisateur si cette réponse est
pertinente. Cela permettra à l'application de mettre à jour sa base de réponse, par exemple en mettant à
jour les poids des termes retenus après traitement de la question de l'utilisateur. Si aucune
correspondance n'est trouvée, l'application va retourner un message invitant l'utilisateur à reformuler
ou à apporter des précisions à sa question.
29
Samuel LEFEVRE
En conclusion de cet état de l'art préliminaire, il apparaît que la méthode 1 est la plus facile à mettre en
œuvre, les deux autres méthodes demandant des efforts conséquents pour s'adapter à un domaine
particulier, ainsi que pour la maintenabilité. Cependant, la méthode 2 offre des résultats bien plus
intéressants en termes de performances. De nombreux outils sont disponibles pour implémenter ces
méthodes, en particulier parmi les projets Apache. Ces méthodes sont donc susceptibles d'être
améliorées en fonction des outils utilisés, mais le choix de la méthode à adopter dépend des données
cibles, et donc du besoin du client.
30
Samuel LEFEVRE
B) Elaboration du cahier des charges
1) Etude du besoin
Après nous être familiarisés avec les méthodes existantes, nous nous sommes penchés sur le besoin du
client. Les trois grands types de questions envisagés étaient :
- Trouver une équipe.
- Trouver un document.
- Trouver une information pour un voyageur.
Le troisième cas faisant l'objet d'un projet séparé, nous nous sommes focalisés sur les deux premiers,
qui concernent directement les équipes de notre client. Nous avons donc rencontré quatre équipe
d'Amadeus afin d'avoir une première approche de leur organisation, identifier leurs besoins et analyser
le contexte d'utilisation de l'application finale.
Amadeus utilise de nombreux outils pour gérer et stocker ses données, notamment des SharePoints et
des wikis. Ces outils doivent être pris en compte dans l'élaboration de l'application finale puisqu'elle
devra prendre en compte les documents pertinents où qu'ils se trouvent. Avec l'aide de notre
interlocuteur du côté AMADEUS, Prashant Balasubramanyan, nous avons réalisé le schéma ci-
dessous, qui présente une vue générale de l'environnement dans lequel sera déployée l'application
finale.
Figure 17 : Workflow d'AMADEUS
31
Samuel LEFEVRE
L'analyse du besoin nous a amené à élaborer une modélisation UML des cas d'utilisations (use cases)
de l'application finale. Chacune des équipes rencontrées dispose de son propre environnement de
travail et de tâches particulières pour lesquelles cette application pourra se révéler utile ; le schéma ci-
dessous synthétise les cas d'utilisation de l'application pour toutes les équipes rencontrées.
Figure 18 : Use case du prototype
Les sources d’information que nous devions cibler s’avéraient très variées : wikis, SharePoints,
documents internes… Il s’agit essentiellement de documents non structurés. C’est pourquoi la
méthode 1 (Question Answering) nous semblait de loin la plus appropriée, étant la seule viable sur des
documents non structurés, mais également parce qu’elle était la plus souple à mettre en place et à
maintenir.
Nous avons déduit de l’étude du besoin six fonctionnalités principales :
Chercher une équipe ou un produit.
Dialoguer avec l’application en langage naturel.
Afficher une interface utilisateur ergonomique sous la forme d’une chatbox.
Remplir des statistiques sur le nombre de questions posées et de réponses pertinentes
retournées.
Générer une réponse en langage naturel.
Administrer l’application en modifiant ses paramètres d’affichage, d’indexation et de
recherche.
32
Samuel LEFEVRE
2) Solution proposée
Au fil des réunions avec les équipes d'Amadeus, nous avons pris conscience que le traitement des
données cibles était aussi important que le traitement de la question elle-même. Renvoyer une liste de
documents n'est pas satisfaisant pour toutes les équipes, certaines d'entre elles ont besoin d'obtenir une
réponse exacte tirée d'un document. De plus, il est apparu qu'une gestion des feedbacks des utilisateurs
pourrait améliorer la pertinence des recherches. Nous avons donc modifié la modélisation de
l'application finale pour obtenir le schéma ci-dessous :
Figure 19 : Diagramme d'activités du prototype
33
Samuel LEFEVRE
C) Mise en place de la solution
1) Travail réalisé
Pour mener à bien le développement du prototype, nous nous sommes répartis les tâches à réaliser :
Jean-Michel s’est focalisé sur la partie de traitement du langage naturel tandis que je m’attelais à la
réalisation d’une interface de type « robot-chat ». Le développement a été mené sur nos ordinateurs de
bureau et les présentations sur nos ordinateurs portables personnels. Trois réunions de présentations du
prototype au client ont été planifiées, séparées de trois à quatre semaines, ainsi qu’une présentation
finale le 3 septembre 2012.
La première version du prototype, présentée au client le 11 juillet 2012, consistait en une seule
application regroupant un indexeur et un moteur de recherche basé sur des mots-clés. La séparation de
l’indexeur et de la chatbox est intervenue rapidement après cette réunion, ainsi que l’intégration des
annotations avec GATE.
La seconde version du prototype, présentée le 30 juillet 2012, était composée de deux applications :
l’indexeur et la chatbox. Un guide d’utilisation avec les vues du logiciel étaient également compris
dans le prototype. L’interface de l’indexeur n’avait quasiment pas évolué, mais ses performances
avaient été améliorées. L’interface de la chatbox avait en revanche subi un remaniement important : un
nombre déterminé de questions et de réponses précédentes étaient affichées au-dessus de la question
actuelle, et un nombre déterminé de questions fréquemment posées étaient également affichées en
permanence. La recherche basée sur les annotations et les règles avait été intégrée, ce qui permettait à
l’utilisateur d’obtenir des réponses plus rapides et surtout plus pertinentes. L’application générait une
réponse en langage naturel pour les questions liées à la recherche de points de contact des équipes
d’AMADEUS.
La troisième version du prototype, présentée le 23 août 2012, était toujours composée de l’indexeur et
de la chatbox. Les changements importants concernaient la chatbox : la gestion de l’historique avait
été revue pour permettre à l’utilisateur de pouvoir naviguer depuis la chatbox dans tout l’historique
tout en ne chargeant qu’un nombre limité de questions et de réponses à la fois. L’historique était
stocké dans un fichier accessible dans le dossier Resources sur le serveur. La gestion des questions
populaires a également été revue de façon à les afficher de façon dynamique. Lorsque l’application
renvoie plusieurs résultats à la suite d’une question posée par l’utilisateur, ce dernier peut choisir celle
qui lui convient, ou déclarer qu’aucune d’elle n’est intéressante.
Après cette réunion, d’ultimes modifications ont été apportées au prototype. En plus de modifications
graphiques mineures, il s’agissait de gérer différemment la réponse de la chatbox à une question de
l’utilisateur en fonction du nombre de résultats trouvés : au-delà de trois résultats, la chatbox doit
considérer que la question est trop imprécise et la rejeter. S’il y a trois résultats ou moins, l’utilisateur
peut choisir le meilleur résultat mais peut également déclarer que toutes les réponses sont pertinentes
ou non pertinentes.
34
Samuel LEFEVRE
2) Technologies utilisées
Notre tâche en tant que développeurs consiste à mettre au point un prototype de l’application finale
présentée dans la partie précédente. Nous nous sommes attelés à la réalisation du cœur même de
l’application, à savoir le traitement de la question de l’utilisateur, l’indexation et la recherche de la
réponse.
Nous avons choisi de développer notre prototype en Java, l’un des langages les plus utilisés dans les
projets que nous avons rencontrés. Nous avons choisi dans un premier temps de monter notre
application sous la forme d’une servlet Java/JEE sous Apache-Tomcat, un conteneur de servlets
simple et léger mais suffisant pour le développement d’un prototype.
N’ayant pas de contrainte sur les outils et les langages à utiliser, nous nous sommes dans un premier
temps penchés sur les différents projets Apache : OpenNLP, Jena, Solr/Lucene, Droids… avant
d’opter pour un outil open source plus complet, réalisé par l’université de Sheffield : GATE (General
Architecture for Text Engineering).
GATE permet d’assembler différents modules de traitement du langage naturel, d’indexation et de
recherche pour créer des applications. GATE offre des fonctionnalités très complètes, mais en
contrepartie se révèle assez complexe à prendre en main. Il dispose d’une API, GATE Embedded, qui
permet son intégration dans d’autres applications.
Nous avons ainsi construit notre prototype à partir des modules ANNIE (A Nearly-New Information
Extraction System) incorporés dans GATE. Ces modules permettent d’analyser des documents et d’en
extraire de l’information en construisant des annotations. Les annotations disponibles par défaut étant
insuffisantes, nous avons dû revoir un système d’annotations adapté à l’environnement d’AMADEUS.
Nous avons également dû écrire les règles adaptées à ces annotations pour pouvoir détecter les termes
à annoter dans les documents à analyser.
Figure 20 : Exemple de texte annoté
35
Samuel LEFEVRE
Une étape plus poussée dans l’analyse des documents consisterait à utiliser l’ontologie. GATE possède
également des modules adaptés à la création et à l’utilisation de modèles d’ontologie, mais à la
demande du client nous nous sommes concentrés sur l’extraction d’information basée sur les
annotations et les règles avec les modules ANNIE.
Nous avons donc adapté le prototype final de façon à extraire efficacement l’information contenue
dans des fichiers de type CSV, cependant le prototype n’aura qu’une efficacité médiocre pour analyser
d’autres types de documents.
Figure 21 : Pipeline des modules ANNIE
- Le module Document Reset PR permet de supprimer toutes les annotations préexistantes sur le
document à analyser.
- Le Tokenizer permet de séparer le corps du document à analyser en chaînes de caractères
simples (mots, ou tokens), en se basant sur les signes de ponctuation.
- Le Gazetteer permet de comparer d’identifier dans le document à analyser des chaînes de
caractères présentes dans des listes. GATE possède de base un ensemble de listes lui
permettant de reconnaître certaines entités, comme des prénoms, des lieux, des dates… Ces
listes ne sont pas exhaustives et peuvent être complétées manuellement. Il est également
possible de créer de nouvelles listes pour identifier de nouvelles entités.
- Le Sentence Splitter permet de découper le corps du document à analyser en phrases en se
basant sur des délimiteurs.
- Le PoS Tagger permet d’identifier la catégorie lexicale des mots. Les mots inconnus
commençant par une majuscule sont annotés comme des noms propres par défaut.
- Le Transducer permet d’appliquer des règles sur le document annoté pour en déduire de
nouvelles annotations.
36
Samuel LEFEVRE
3) Interface
Pour réaliser l’interface du prototype, j’ai été amené à m’auto-former à la technologie JEE en suivant
différents tutoriels. Je me suis également inspiré du modèle MVC pour construire une interface simple
tout en tentant de conserver une certaine souplesse dans la programmation. L’interface de la chatbox
est celle qui aura le plus évolué au long du projet.
Figure 22 : Diagramme de classes de la chatbox
La vue est constituée de Java Server Pages (JSP) contenant des formulaires grâce auxquels l’utilisateur
peut interagir avec la chatbox. La page d’accueil est index.jsp. Les informations entrées par
l’utilisateur sont récupérées par une servlet, ServletHandler, qui va les envoyer au contrôleur capable
de les traiter : SearchServlet ou AdminServlet. Le contrôleur va alors mettre à jour les modèles avec
ces informations et afficher la vue correspondante. L’intérêt du ServletHandler est d’assurer une
certaine souplesse du code en facilitant l’intégration de nouvelles fonctionnalités, mais également de
permettre à l’AdminServlet de modifier les paramètres du modèle sans avoir de dépendance avec la
SearchServlet.
37
Samuel LEFEVRE
Le modèle est composé de trois parties synchronisées par la classe ChatBot : l’historique, les questions
courantes et la conversation elle-même. C’est dans la partie conversation qu’est appelée la fonction qui
effectue la recherche et génère la liste des réponses à la question posée par l’utilisateur. Le modèle
Topic va alors différentier les cas en fonction du nombre de réponses trouvées, ce qui va permettre
d’afficher des messages différents selon les cas.
La possibilité d’envoyer des mails avec l’historique de chatbox avait été demandée par le client, les
briques permettant de tester cette fonctionnalité ont été incluses à part dans l’application en attendant
des tests complets, qui n’ont pu être réalisés faute de temps.
Une servlet dédiée à l’affichage des erreurs a été intégrée à chacune des applications du prototype :
l’indexeur, la chatbox et l’éditeur de règles.
38
Samuel LEFEVRE
4) Traitement du langage naturel
Le prototype final se présente sous la forme de trois applications déployées sur un serveur et d’un
répertoire de ressources : un indexeur, une chatbox et un éditeur de règles. L’utilisation de l’indexeur
est principalement réservée à un administrateur ; celle de l’éditeur de règles doit permettre aux
différentes équipes de rajouter des informations utilisables par le prototype, alors que la chatbox doit
permettre à l’utilisateur lambda de rechercher des informations dans les documents indexés.
Figure 23 : architecture générale du prototype final
39
Samuel LEFEVRE
L’indexeur
Il permet à l’administrateur de saisir le chemin du répertoire où se trouvent les documents à indexer,
ainsi que les extensions des documents à indexer. Par défaut, l’indexeur traitera uniquement les
documents CSV contenus dans le répertoire Resources. L’indexation est relancée périodiquement, et
les index créés sont stockés sur le serveur. Un des grands défis de notre projet a consisté à améliorer
les performances de l’indexeur en termes de temps de traitement et de mémoire utilisée. Actuellement,
l’indexeur peut indexer près de 36 000 documents (txt et html) en 90 minutes.
Figure 24 : Schéma du flow de l'indexeur
40
Samuel LEFEVRE
L’éditeur de règles
Il permet à l’administrateur d’ajouter de nouvelles annotations et de nouvelles règles utilisables par
l’indexeur et la chatbox. Pour cela, il soumet un document CSV à l’application, qui va réaliser des
vérifications afin de créer de nouvelles listes ou de compléter des listes existantes à partir du document
CSV. Les annotations et les règles associées à ces annotations seront générées par l’éditeur de règles,
ainsi que la règle globale prenant en compte toutes ces annotations.
Figure 25 : Diagramme d'activité de l'éditeur de règles
De nombreux points restent à développer sur l’éditeur de règles : en effet, l’administrateur doit encore
réaliser certaines étapes manuellement :
- L’ajout du nom des règles à déclencher dans le fichier Main.jape dans l’ordre dans lesquelles
les règles doivent se déclencher.
- La modification du code source de la chatbox pour y ajouter les classes correspondantes à la
nouvelle règle globale.
- La règle permettant d’identifier le type de question qui doit déclencher la règle globale
ajoutée.
- Le patron de la phrase en langage naturel à retourner pour répondre à la question mentionnée
dans le point précédent.
41
Samuel LEFEVRE
Le moteur de recherche
La chatbox est l’application qui permet à l’utilisateur de rechercher des informations dans les
documents indexés. L’historique des conversations est enregistré quotidiennement dans un fichier sur
le serveur, et affiché sur l’interface de la chatbox. Sont également affichées les questions les plus
courantes auxquelles l’application a trouvé une réponse. La taille de l’historique et de la liste des
questions les plus courantes peut être paramétrée directement depuis la chatbox.
Figure 26 : Exemple de création d'une requête à partir d'une question
Le point le plus délicat est la génération d’une requête à partir d’une question posée en langage
naturel. La compréhension de la question est basée sur l’extraction d’annotations spécifiques (ici
SearchCompoTeam, Role, Team) qui vont permettre d’identifier le type de réponse attendue
(CompoTeam). L’application va ensuite faire la correspondance entre le type de réponse attendue
(CompoTeam) et les annotations simples qui la composent (Role, FirstName, Surname, Team) afin de
construire la requête à partir des éléments annotés de la question (Role, Team).
Un guide d’installation et d’utilisation est inclus dans le prototype final, ainsi qu’un document
regroupant les différentes vues.
De nombreuses améliorations restent encore à apporter au prototype, non seulement au niveau
graphique pour rendre l’application « user-friendly » mais également au niveau de l’envoi de mail, de
la recherche de la réponse dans les documents et de l’automatisation de l’ajout d’information.
42
Samuel LEFEVRE
Conclusion
Ce stage a très bien répondu à mes attentes, puisqu’il m’a permis de travailler sur de
nombreuses étapes de l’élaboration d’un produit : état de l’art, étude du besoin, mise en place
du cahier des charges et de sa solution. Le traitement du langage naturel s’est révélé être un
domaine plus complexe que je l’imaginais ; derrière cette problématique se trouve un enjeu de
taille qui passionne la communauté informatique : rendre la machine capable de comprendre
l’homme. Des innovations dans ce domaine paraissent au jour le jour et il est nécessaire de
réaliser un travail de veille et d’adaptation pour rester à la pointe de l’innovation.
La décision de poursuivre ou non ce projet, et le choix de sa forme dépendent entièrement du
client. Le travail réalisé pendant ce stage m’a permis de réaliser à quel point le traitement du
langage naturel et la sémantique pourraient devenir cruciaux dans les années avenir, même si
ses domaines sont encore loin d’être matures. Je suis en tout cas très motivé par ce que j’ai pu
apprendre sur ses domaines, et si j’en ai la possibilité je souhaiterais poursuivre ce projet ou
un projet similaire.
J’ai également été satisfait de mon stage au sein de l’agence de Sophia Antipolis de
LOGICA. Malgré un changement récent dans la direction de la BU, j’y ai trouvé une
ambiance de travail assez stimulante ainsi qu’une profonde volonté de partager l’expérience
acquis par chacun. J’ai également pu apprécier le travail en équipe sur ce projet avec Jean-
Michel Durand. J’ai le sentiment d’avoir consolidé mes compétences techniques, notamment
en Java, et d’en avoir acquis de nouvelles. C’est également toute une démarche que j’ai pu
mettre en pratique et qui a mis à jour ma perception du cycle de vie d’un produit.
Un seul bémol toutefois, en tant que stagiaire je n’ai eu qu’un accès très limité aux données
du client. De plus, mon tuteur de stage se trouvait en mission chez le client, mais
l’organisation mise en place au début du stage a permis de suivre le bon déroulement du stage
à intervalles réguliers.
J’envisage à présent de continuer l’aventure au sein de LOGICA, si possible dans la
continuité du projet mené pendant ce stage. D’autres offres de poste m’ont également été
présentées, et j’ai récemment reçu un retour favorable à un entretien pour le poste d’ingénieur
Product Definition pour le compte du client AMADEUS pour ma première embauche. A plus
long terme, j’envisage de me tenir informé sur les possibilités de missions de traitement du
langage naturel ou de sémantique, tout en suivant de près les opportunités nationales et
internationales que la fusion annoncée entre LOGICA et le groupe CGI pourra apporter.
43
Samuel LEFEVRE
Bibliographie
Traitement du langage naturel
http://opennlp.apache.org/documentation/1.5.2-incubating/manual/opennlp.html http://www-lipn.univ-
paris13.fr/~audibert/pages/enseignement/TAL_ITCN.pdf
http://www.lsi.upc.edu/~nlp/papers/padro10b.pdf
Analyse sémantique
http://www.loria.fr/projets/JEP-TALN/actes/TALN/posters/Poster04.pdf
http://www.cs.utexas.edu/~ml/papers/parsing-conll-05.pdf
http://www.cs.utexas.edu/users/ml/papers/ge-acl-ijcnlp09.pdf
http://www.cs.utexas.edu/~ml/software/
www.cs.utexas.edu/users/ml/slides/ge-thesis.ppt
http://www.ark.cs.cmu.edu/SEMAFOR/
Question answering
http://sewm.pku.edu.cn/QA/reference/Mining%20the%20Web%20for%20Answers%20to%20Natural
%20Language%20Questions.pdf
Interface aux bases de données
http://users.encs.concordia.ca/~kosseim/Publications/2005dke.pdf
http://www.cs.washington.edu/homes/pedrod/papers/emnlp09.pdf
http://www.google.com/patents/US7702508?printsec=description&dq=7,702,508&ei=hKV1T-
y3AYfNhAesmqCoDQ#v=onepage&q=7%2C702%2C508&f=false
http://l2r.cs.uiuc.edu/~danr/Papers/CGCR10.pdf
http://www.inf.unibz.it/~franconi/papers/dl-04.pdf
http://scienceculture.academia.edu/SeyedHashemDavarpanah/Papers/246333/Using_Natural_Languag
e_Processing_in_Order_to_Create_SQL_Queries
http://acl.ldc.upenn.edu/N/N04/N04-3006.pdf
Outils
http://gate.ac.uk/
http://nlp.lsi.upc.edu/freeling/doc/userman/userman.pdf
http://www.w3.org/2004/OWL/
http://www.swi-prolog.org/index.txt
http://www.delph-in.net/index.php?page=3
http://docfetcher.sourceforge.net/fr/index.html
44
Samuel LEFEVRE
Annexes
Annexe 1 : Index des figures
Figure 1 : Histoire de LOGICA ................................................................................................................ 10
Figure 2 : Implantation de LOGICA dans le monde ............................................................................. 11
Figure 3 : Implantation de LOGICA en Europe .................................................................................... 12
Figure 4 : Implantation de LOGICA en France ..................................................................................... 13
Figure 5 : Principaux clients de LOGICA France ..................................................................................... 14
Figure 6 : Logo d'AMADEUS ............................................................................................................... 16
Figure 7 : Implantation d'AMADEUS dans le monde ........................................................................... 17
Figure 8 : Connexions entre AMADEUS et l'industrie du voyage........................................................ 17
Figure 9 : Organisation de LOGICA dans le contexte d'AMADEUS ................................................... 18
Figure 10 : Organisation des projets des stagiaires pour AMADEUS .................................................. 20
Figure 11 : Architecture générale d’une application de traitement du langage naturel ......................... 23
Figure 12 : Schéma de la méthode1 (Question Answering) .................................................................. 24
Figure 13 : Exemple d'application de la méthode1 ............................................................................... 25
Figure 14 : Schéma de la méthode2 (Interface to Databases) ............................................................... 26
Figure 15 : Exemple d'application de la méthode2 ............................................................................... 27
Figure 16 : Schéma de la méthode3 (Chatterbox) ................................................................................. 28
Figure 17 : Workflow d'AMADEUS ..................................................................................................... 30
Figure 18 : Use case du prototype ......................................................................................................... 31
Figure 19 : Diagramme d'activités du prototype ................................................................................... 32
Figure 20 : Exemple de texte annoté ..................................................................................................... 34
Figure 21 : Pipeline des modules ANNIE ............................................................................................. 35
Figure 22 : Diagramme de classes de la chatbox................................................................................... 36
Figure 23 : architecture générale du prototype final.............................................................................. 38
45
Samuel LEFEVRE
Figure 24 : Schéma du flow de l'indexeur ............................................................................................. 39
Figure 25 : Diagramme d'activité de l'éditeur de règles ........................................................................ 40
Figure 26 : Exemple de création d'une requête à partir d'une question ................................................ 41
46
Samuel LEFEVRE
Annexe 2 : Vues du prototype
Indexer prototype:
Home:
The Administration button redirects the user to the following page:
After entering the different parameters to administrate the index or choosing the basic indexation,
the user is redirected to the final page:
47
Samuel LEFEVRE
Searcher Prototype:
Home:
Clicking on the Start button initializes the application, which will open the datastore where the
indexed are created. If the initialization passes, the user will be redirected to the chat page. If there is
no available historic, the displayed page will be similar to this page:
48
Samuel LEFEVRE
If there is an available historic, the displayed page will be similar to that page:
49
Samuel LEFEVRE
On this page the user can ask his questions to the searcher, which will display the answers. If there
are several answers to the user’s question, the user will be asked to precise whether one of them is
the one he/she expected.
50
Samuel LEFEVRE
The searcher will display the answer if there is only one answer, or a message if there are no
answers.
51
Samuel LEFEVRE
An administration page allows admin users to change some parameters impacting the way the
chatbot is displayed and the research is processed. The following page is an incomplete view of the
administration page, since the complete list of parameters to edit has not been decided yet.
The “Back” button redirects the user to the conversation page whereas the “Apply” button sets up
the parameters with the given values and redirects the user to the Home page.
52
Samuel LEFEVRE
CSV Manager Prototype:
Home:
The user has to enter the path (relative or absolute) in the field to submit a CSV document.
Then for each title of the CSV, the user will have to select the corresponding annotation within the
list of annotations stored in the annotations description file.
53
Samuel LEFEVRE
If the title being processed appears in the annotation list, the following page will be displayed :
54
Samuel LEFEVRE
Else, the page displayed will be that one:
When all the titles of the current CSV document have been processed, the user will be redirected to
the home page, with the possibility to submit a new CSV document.
55
Samuel LEFEVRE
Annexe 3 : Guide d’utilisation du prototype
Contents of the package:
- indexProto4.war
- searchProto4.war
- csvProto4.war
- Resources folder
- javadoc folder
- userguide.pdf
- apache-tomcat-7.0.28.exe
Prerequisites:
- You must have a functional version of the Apache-Tomcat server installed on your computer
(version 5.5 or higher ; compatibility has not been tested on prior versions).
Installation guide:
Ensure that you have a functional version of Tomcat installed, and that the following line is present in
the conf/tomcat-users.xml file:
<user name="*" password="*" roles="admin-gui,manager-gui" />
where * symbolizes any string.
56
Samuel LEFEVRE
If you don’t have a functional version of Tomcat installed you can use the installer provided within
this package. The full installation is encouraged. If the line mentioned above is not present in your
conf/tomcat-users.xml file, you can paste the line and replace the * by your login and your password.
Copy indexProt.war, searchProt.war, csvProto4.war and the Resources folder in the webapps
repository of Tomcat.
How to use the prototype:
1) Start the Tomcat server.
2) Start your web browser and enter the Tomcat connector port number in the URL field (by
default : localhost:8080).
3) Go to the Manager Service of Tomcat (“Manager App” for Tomcat v7, “Tomcat Manager” for
prior versions) and log in to see the list of the applications.
4) If you have already created an index and you don’t want to update it, you can move to 5).
Else, launch the indexProto4 application. Here you can choose between an indexation with
default parameters or administrate the parameters of the indexation.
If you choose to administrate the index, you will have to enter the path of the
repository where the files you want to index are located. You will also be asked to select the
extensions of the files you want to consider. If you don’t enter a path, no document will be
indexed. If you don’t select any extensions, the application will consider only .csv documents.
If you choose to launch the defaults indexation, the application will index the .csv
documents which are located in the Resources/AmadeusResources folder.
5) Launch the searchProto4 application and click to the start button.
6) The robot will display a list of the most popular questions which have an answer.
It may also display the historic of the day: the previous questions and the final answer to
these questions. When the number of topics in the historic exceeds the number of topics
displayable in the historic box, you will be able to move through the different pages of the
historic by clicking on the “Previous topics” button at the top of the historic box or the “Next
topics” button at the bottom of the historic box.
You converse with the robot by entering your questions in the corresponding field.
If there are several answers to your question, the robot will display them and ask you
to indicate which one you expected. Once you entered the number of the answer you
expected, this answer will be added to the historic. If none of the answers displayed
57
Samuel LEFEVRE
corresponds to your expectation, you can enter “0”; then the robot will return that there are
no relevant answers to your question.
If there are only one or no answers, the robot will automatically add the result to the
historic and display it.
Once the topic has come to a conclusion (0 or 1 answer to your question) you can start a new
topic.
7) Stop Tomcat when you’re done.
N.B. Despite all the work done to prevent them, errors might occur. A different page may provide
information concerning these errors. The stack trace of these errors is hidden for users, but appears
in the source code of the page.
Next improvements:
- Improve annotations so that the application can accurately answer more questions.
- Improve synchronization between the indexer and the searcher to manage concurrence.
- Improve the administrations of rules.
- Implement the administration interface for the chatbox.
- Update the documentation according to the improvements listed above.
