“Sniffe le réseau” est un des trois projets de Hacking Industry Camp 2017 qui comptait des super-héros de Versusmind. L’objectif de notre équipe était de détecter des pannes de courant à partir des messages sur des réseaux sociaux et y répondre de deux façons :

• proposer une assistance personnalisée aux utilisateurs concernés via notre chatbot ;
• notifier des techniciens en leur proposant une carte avec les messages géolocalisés pour mieux visualiser les problèmes de réseau.

Vous trouverez la description complète du projet dans le billet de blog précédent.

Ce billet présente comment l'analyse des tweets est effectuée sur le projet, à l'aide de la technologie LUIS (Language Understanding Intelligent System) de Microsoft. Après une rapide présentation rapide du service et ses capacités, je vous présenterai comment s'en servir pour l’analyse des tweets afin de détecter les messages parlant d’un problème de courant. Enfin, je ferai le tour des questions que l’on peut se poser lors de la mise à l’échelle des projets utilisant LUIS.

Pourquoi utiliser LUIS ?

“Ah, il fait tout sombre ! Je n’ai plus de courant chez moi !”
“C’est quoi cette panne d’électricité ? “
“C’est juste chez moi qu’il n’y a plus de jus ou tout le monde est coupé ?”
“Blackout total à Neudorf !”

Tous ces messages peuvent être résumés au fait que les personnes concernées sont privées d’électricité. Toutefois, cette information est exprimée de quatre façons différentes et la liste est loin d’être exhaustive. Comment alors repérer ces messages parmi tant d’autres et détecter les pannes de courant ?

Vous pouvez me répondre : mais c’est évident, sur Twitter, on va détecter les hashtags ! Euh, c’est bien beau, mais comment prédire tous les hashtags possibles et imaginables qu’une personne peut associer à ces messages ? Si l’on se concentre seulement sur quelques-uns les plus simples, comme #pannedecourant, #blackout, #plusdélectricité, on risque de manquer des messages et donc sous-estimer des problèmes de réseau.

LUIS est conçu pour répondre à cette problématique : le système analyse les phrases en langage naturel, sans dépendre de hashtags, et les classe par rapport aux catégories connues dans son modèle. Ces catégories sont appelées intentions. En effet, on communique avec des autres avec une ou plusieurs intentions, par exemple dans les messages ci-dessus, on veut à la fois :

• signaler le problème de courant électrique (tous les messages) ;
• se renseigner (les messages 2 et 3) ;
• exprimer éventuellement son désarroi.

Pour le projet “Sniffe le réseau”, la première intention est essentielle. Il faut donc focaliser le modèle LUIS sur la détection des messages qui signalent des pannes de courant.

Comment faire fonctionner LUIS ?

La mise en place d’une application LUIS est relativement simple : il faut créer un compte Microsoft et un compte LUIS. La politique de facturation de LUIS permet de tester et d’utiliser quelques applications gratuitement tant que le trafic n’atteint pas 10 K transactions par mois ou 50 transactions par seconde.

Ensuite, il faut créer une nouvelle application pour le projet et l’aventure commence !

Il est important de renseigner la langue, et plus précisément, la culture de l’analyse. La notion de la culture s’illustre bien sur l’exemple du français de la France et du français du Canada : les mêmes mots peuvent avoir un sens différent et il existe des expressions particulières qui peuvent influencer le modèle. A noter que la première version de LUIS est disponible pour seulement une douzaine de langues.

Une nouvelle application est créée. Voici son tableau de bord :

L’application contient déjà par défaut une intention sur 80 possibles.

Intentions et entités

Intentions et entités sont les éléments essentiels pour LUIS. On peut remarquer la présence des onglets dédiés dans le menu.

Intention “None”

Dans la rubrique “Intentions”, il existe par défaut l’intention “None” (aucune) qui n’a pas encore d’énonciations (utterances) associées.

Cette intention est très importante : elle permet de classer tout le bruit qui viendra perturber le modèle. En effet,dans l’ensemble de messages qui seront analysés avec LUIS, il y a aura seulement une partie à retenir. Pour cette partie de messages, je vais créer l’intention “signaler_blackout”. Le reste des messages devra être classé dans la première intention “None”.

Création d’une intention

L’intention “signaler_blackout” fraîchement créée ne contient aucune énonciation. Je vais donc y ajouter la première de mes quatre phrases exemples.

Une fois j’appuie sur “Enter”, LUIS essaie de prédire l’intention pour cette phrase.

Etant donné que je n’ai pas encore entraîné le modèle, LUIS ne peut pas classer cette phrase. Je vais l’aider au début et indiquer qu’il s’agit de l’intention “signaler_blackout” en appuyant sur sauvegarder.

Maintenant, je peux essayer d’entraîner le modèle dans l’onglet Train&Test. Une fois l’entraînement terminé (quasi instantané), je peux tester le modèle en mettant un énoncé, par exemple, un bout de notre phrase de départ :

On voit que le modèle contient bien l’exemple et y assigne le taux de confiance de 99%.

Toutefois, que se passe-t-il si l’utilisateur a employé un synonyme à la place de “courant” ?

Le taux de confiance baisse et LUIS ne sait pas à cette étape qu’il s’agit des synonymes.

Ajout des entités

Pour lui fournir cette information, je vais créer une entité regroupant les mots “courant” et “électricité”.
Pour cela, il existe l’onglet “Entities”. Je crée une entité propre à notre projet (“Custom entity”) et sélectionner le type List.

Ce type d’entités permet de définir une forme canonique et y associer des synonymes. Il existe d’autres types d’entités : des mots simples (par exemple, “blackout”), des entités composées qui regroupent plusieurs entités simples ou des listes, et des entités hiérarchiques qui organisent les mots en super-classes.

Maintenant, je vérifie que l’entité est bien repérée. Pour cela, je vais dans l’intention “signaler_blackout” et y ajoute ma deuxième phrase exemple :

La phrase est bien associée à l’intention “signaler_blackout” et l’entité est en place. Pour LUIS, cela signifie que les phrases “C’est quoi cette panne de courant ?” et “C’est quoi cette panne d’électricité ?” sont identiques. Et si l’utilisateur fait une faute de frappe et saisit “electricité” ?

Il faut noter que les variantes graphiques et les fautes sont à prévoir et à renseigner dans les entités, ce qui peut être fait au fur et à mesure.

Entraîner le modèle

Bien que les taux de confiance soient hauts à ce moment, il faut se rappeler que le modèle contient une seule phrase pour “signaler_blackout” et zéro pour “None”.

Pourquoi entraîner l’intention “None”

Voici les conséquences de ce modèle très pauvre et mal équilibré :

La structure de la phrase “je n’ai plus de fromage chez moi” est très proche de ma phrase d’entraînement “je n’ai plus de courant chez moi” et le système se sent à l’aise pour les classer dans la même intention. La deuxième phrase “il y a un grand chat sur ma fenêtre” classée dans cette intention est la conséquence directe de l’absence d’exemples pour l’intention “None”. La troisième phrase,  “J’ai vu un gars partir en courant”, illustre le cas de la polysémie où un mot, dans notre cas “courant”, peut avoir plusieurs sens.

Pour améliorer le modèle, il faut ré-assigner ces trois phrases à l’intention “None” et relancer l’entraînement.

Repérer des cas problématiques et ajuster le modèle

Après l’entraînement du modèle sur les 6 phrases (3 par intention), l’amélioration des résultats est évidente :

LUIS a bien repéré l’entité dans le premier exemple et a associé des taux de confiance très hauts aux phrases du modèle. Quant à l’intention “None”, le modèle contient maintenant les contre-exemples :

Si je reteste notre cas problématique avec le mot “courant”, la phrase “il est parti en courant” est bien classée parmi les non importantes :

Le travail sur le modèle pour LUIS est constitué des cycles où on ajoute des phrases dans les intentions, les mots dans les entités et on teste. Après, on ré-assigne les phrases mal classées et on ré-entraîne le modèle.

Quel effort pour avoir une application qui marche ?

Le modèle de LUIS créé pendant le hackathon #HIC2017, s’est montré efficace pour le projet d’analyse des tweets. Après des cycles d’entraînement, le repérage des messages pertinents était bien efficace (tous les tweets envoyés par l’équipe ont été bien captés par LUIS).

Les moyens mis en oeuvre ont été assez modestes :

Tout comme dans l’exemple ci-dessus, l’analyse a été menée par rapport à l’intention “signaler_blackout” et quelques entités. Au total, le modèle a été entraîné sur 135 tweets.

Il faut noter que la qualité du modèle dépend de sa capacité d’éliminer le bruit. Pour cela, il faut fournir des phrases exemples, mais surtout des contre-exemples (plus de 80% de phrases pour l’intention “None” dans le modèle).

Evidemment, lorsque l’on sort du cadre d’un hackathon, cette quantité de données d’entraînement risque de ne pas suffire.

Mise à l’échelle : les questions à se poser

Pouvoir analyser et classer les contenus rédigés en langage naturel peut apporter plusieurs avantages pour le business : une meilleure interaction avec les clients, une meilleure recherche dans le catalogue des produits, une analyse des sentiments et une réactivité sans précédent en cas de crise. Toutefois, le passage à l’échelle industrielle nécessite nettement plus d’efforts qu’une application pour un hackathon.

Je voudrais évoquer dans ce billet les points positifs de LUIS, mais aussi quelques questions à se poser avant d’opter pour cette technologie.

Points forts de LUIS

L’avantage principal de LUIS à mes yeux est la simplicité de la création d’une application pour des tâches simples. Les interfaces (disponibles uniquement en anglais à ce jour) sont bien pensées et les explications sont généralement suffisantes.

Un des points forts de LUIS est la suggestion des phrases analysées (par exemple, à partir d’un flux de tweets) pour les prendre en compte dans l’ajustement du modèle. Cela évite de les stocker ailleurs et recopier à la main.

De plus, il existe de nombreuses options d’importation/exportation des listes des entitées, des données passées par une appli LUIS, voire d’applications entières en Json.

Pour un développeur, il est possible d’exploiter des intentions fournies par LUIS pour les inclure dans une chaîne de traitement (mais cet aspect sera traité dans un billet de blog à part).

Limites du nombre d’intentions et d’entités

Une application LUIS est limitée à 80 intentions et à 30 entités qui peuvent, certes, être organisées en hiérarchies. Dans la foire aux questions de LUIS, on retrouve la recommandation d’éviter des intentions trop proches (par exemple, réserver un vol international et réserver un vol national). Ils suggèrent aussi de créer une séquence d’applications LUIS où l’application d’entrée catégorise les phrases par rapport à des intentions génériques, pour ensuite les renvoyer vers des applications LUIS plus spécialisées.

En outre de la question des coûts, ce mode de fonctionnement complique la gestion des entitées qui peuvent rester communes entre plusieurs applications. Un outil à part doit alors être développé afin de préserver l’harmonie des données.

Absence de gestion multilingue des entités

De même, si un projet a besoin de deux applications LUIS pour des langues différentes, la FAQ conseille de traduire une des applications exportée sous le format Json en l’autre langue (les phrases et les entités).

Bien évidemment, il sera difficile de coordonner l’évolution des deux applications dans le temps et un effort complémentaire sera nécessaire.

Comment faire si une des langues cibles n’est pas supportée ?

Si une grande entreprise internationale adopte LUIS, le problème de langues risque de se poser. En effet, LUIS couvre déjà douze langues et va certainement en supporter davantage. Toutefois, si le business d’une entreprise est concentré en Italie, en France et en Espagne, c’est dommage de ne pas pouvoir traiter l’espagnol par la même technologie que le français et l’italien. De plus, il faut tenir compte du coût des l’infrastructure lié au choix d’une technologie d’analyse linguistique.

Ces questions ne seront peut être plus pertinentes pour les futures versions de LUIS.

Conclusion

Le projet “Sniffe le réseau” m’a donné l’occasion de tester LUIS et je suis globalement satisfaite de cette expérience. User-friendly et efficace, ce système apporte une valeur ajoutée au projet en permettant de s’en passer des hashtags pour identifier les tweets importants.

Si ce billet vous donne envie de mettre les mains dans la farine, n’hésitez pas ! Plus d’une soirée amusante garanties :) On peut inventer plusieurs façon d’intégrer LUIS dans des applications existantes ou en créer des nouveaux usages.

Retrouvez les autres billets (architecture, chatbot, application mobile, carte en 3D, etc.) du projet “Sniffe le réseau” sur le blog de Versusmind !

De nos jours, la vie au quotidien est difficilement imaginable sans accès à l’Internet. Nous sommes tous devenus des experts en recherche d’informations : se renseigner sur un domaine d’activité, trouver un emploi, réserver ses vacances et bien d’autres usages. Nos doigts sont des champions olympiques en saisie des mots-clés dans les onglets de recherche.

Pourtant, ce n’était pas toujours le cas. Il y a encore une dizaine d’années, l’accès à l’information était loin d’être aussi facile. La croissance technologique que la recherche d’informations a vu dans cette décennie est assez incroyable. Pour illustrer l’augmentation de la quantité des données, prenons l’exemple de Wikipédia. Depuis 2006, le nombre d’articles en anglais s’est multiplié par cinq pour atteindre 5,5 M, tandis que la quantité des articles en français a été décuplée avec environ 2 M d’articles disponibles aujourd’hui. Les technologies de stockage et d’indexation des données ont suivi cette tendance qui résulte en un grand nombre de domaines d'activités liés au BigData.

Ces évolutions nous offrent un large choix de moteurs de recherche allant des plus connus, comme Google ou Yahoo, à ceux militant pour le respect de la vie privée (DuckDuckGo), pour des causes sociales (Lilo) ou écologiques (Ecosia). Quelque soit le moteur de recherche, le mot d’ordre est le confort des utilisateurs.

Le confort des utilisateurs dépend, certes, de la pertinence des résultats par rapport à une requête, mais aussi de la vitesse d’exécution et de l’ergonomie des interfaces graphiques. Ces trois facteurs-clés sont au rendez-vous lorsque l’utilisateur cherche des informations générales en anglais, français, allemand ou dans une autre langue riche en ressources. Les limites des moteurs actuels sont en effet liées aux langues, aux domaines de spécialité, à l’interprétation de la requête de l’utilisateur et aux données.  

Des solutions à ces problématiques émergent de la recherche scientifique et des start ups innovantes. Ce billet de blog vous propose de faire un tour des technologies linguistiques et sémantiques qui vont définir nos futures expériences, mais aussi d’imaginer des fonctionnalités qui pourraient nous simplifier la vie.

Dis-moi quelles langues tu parles…

Les langues ne sont pas toutes égales face à l’histoire et la mondialisation. Ainsi, l’anglais a de loin devancé les autres langues en matière de la quantité de données disponibles. Les langues d’autres pays développés suivent, mais avec un grand retard. L’exemple de Wikipédia évoqué précédemment montre que le nombre d’articles en anglais est plus de deux fois important que celui des articles en français. Les spécialistes du traitement automatique des langues (TAL) distinguent également les langues peu dotées, pour lesquelles la quantité de données est encore moins importante.

Si l’on parle ici de la quantité de données, c’est parce qu’elle est corrélée avec l’accès au savoir. Dans les domaines de spécialité, l’écart entre les langues riches en ressources et celles peu dotées est évident. Par exemple, la requête “semantic search” sur Google en anglais fournit plus de 6 M de résultats, tandis que la requête en français “recherche sémantique” en trouve deux fois moins. L’essai en ukrainien “семантичний пошук” ne retourne que 132 K résultats. Ces écarts importants forcent les utilisateurs à faire leurs requêtes en anglais, ce qui défavorise ceux qui ne parlent pas cette langue.

Pourtant, l’accès général au savoir peut favoriser le développement social, scientifique et culturel. Les pays et les régions entiers pourraient gagner si l’ensemble des connaissances de l’humanité était à la portée de leurs citoyens.

 

Le développement de la traduction automatique permet déjà imaginer les systèmes où la requête d’utilisateur est traduite en d’autres langues pour trouver plus de documents pertinents qui pourront à leur tour être traduits en langue source. La traduction automatique a également ses limites, dont la qualité et la disponibilité des modèles pour les langues peu dotées. Toutefois, l’enjeu d’une telle technologie est assez important pour justifier sa mise en place.

Aller au-delà des mots-clés

“Eau”, “H2O”, “Flotte”, “Water”, “Wasser” : tous ces mots désignent un même concept. C’est le principe des concepts et des labels qui y sont associés. Séparer la forme du sens a plusieurs avantages. Avant tout, les concepts et les relations sémantiques entre eux existent en dehors d’une langue particulière et sont donc utilisables quelque soit la langue. Ce principe est utilisé dans les technologies sémantiques qui seront à la base du Web 3.0.

La recherche effectuée au niveau conceptuel est d’avance plus puissante, car elle prend en compte la synonymie, c’est-à-dire les mots désignant le même concept, comme “Eau” et “Flotte” (fam.), et restreint le sens recherché (“Eau de parfum” n’est pas la même chose que “Eau”). De plus, ce type de recherche est naturellement multilingue.

Recherche sémantique

La recherche sémantique implique l’annotation des documents au niveau sémantique, comme l’illustre la figure ci-dessus. Les requêtes en langue naturelle sont elles-aussi interprétées afin d’identifier les correspondances dans les documents indexés au niveau sémantique. L’exemple ci-dessus représente un modèle très simpliste d’une infrastructure qui peut en réalité contenir plus de modules et de ressources.

Ressources sémantiques et Linked Open Data

Les modules d’annotation et d’interprétation sémantique s’appuient sur des ontologies et des bases de données sémantiques. Les ontologies sont des structures de concepts liés entre eux par des relations hiérarchiques (ex. : le chat est un animal) et non-hiérarchiques (toutes les autres relations, dont celles définies en fonction des besoins d’un projet). Ces ressources peuvent être créées sur mesure ou venir des données connectées ouvertes (Linked Open Data ou LOD).

Les ressources LOD sont organisées en graphes de connaissances selon le modèle des triplets RDF composés de deux concepts et d’une relation entre eux. Ces graphes sont exploitables via les requêtes SPARQL. Les exemples des requêtes SPARQL sont disponibles ici. Elles permettent de questionner plusieurs niveaux dans la base, par exemple de trouver parmi les membres de la classe “Personnes célèbres” ceux qui ont joué dans des films dont le réalisateur était d’origine allemande.

Un des moteurs de recherche basé sur cette technologie est GraphScope développé par la start up allemande SearchHouse, dont la démo est disponible sur demande.

Vers des résultats plus compréhensibles

La lisibilité d’un document mérite d’être prise en compte dans la sélection des résultats pertinents. En effet, les résultats d’une requête peuvent mélanger des posts issus des forums, des sites gouvernementaux, des articles Wikipédia, des travaux scientifiques, des textes de lois, etc. A priori, ces documents ne visent pas le même public et varient en difficulté de lecture.

Il existe des formules permettant d’estimer si un document est facile à lire ou s’il nécessite une formation supérieure pour être lu sans difficulté. Une de ces formules est Flesch–Kincaid. Elle prend en compte la longueur des phrases et le nombre de syllabes dans les mots, pénalisant les phrases longues et des mots polysyllabiques. Développée pour l’anglais, cette formule fonctionne relativement bien pour le français.

Pour illustrer le test de lisibilité, prenons l’exemple de l’article “Air” sur Wikipédia qui s’adresse au grand public et le même article dans Wikimini, encyclopédie pour les enfants. L’outil d’évaluation en ligne a estimé l’indice de lisibilité de l’article adulte à 53,29 qui correspond à “assez difficile à lire”. L’article pour les enfants a obtenu le score de 72,34 signifiant “assez facile à lire”.

Bien que ces indices soient relatifs, ils donnent une idée sur la complexité de lecture. La prise en compte de ce test pourrait améliorer les moteurs de recherche pour les enfants, comme SafeSearchKids. De plus, combiné avec l’analyse terminologique, le test de lisibilité peut contribuer à la customisation de la recherche dans un domaine de spécialité.

Indexation des contenus média

Un des projets de pointe est xLiMe mené par l’équipe de Dr Achim Rettinger à KIT (Karlsruhe Institute of Technology). xLiMe est une plate-forme d’analyse sémantique cross-langue et cross-média qui représente une fusion des technologies sémantiques décrites précédemment.

 

La plate-forme permet la recherche simultanée en plusieurs langues et sur plusieurs supports. Notamment, elle cherche dans les contenus audio et vidéo, et non seulement dans leurs méta-données. Dans l’exemple illustré par la figure ci-dessus, la requête Brexit (utilisée dans le showcase de xLiMe) a retourné des tweets, des enregistrements audio, des articles et des concepts voisins marqués par le petit citron vert.

En quelque sorte, xLiMe offre une vision futuriste de moteurs de recherche. Le projet est terminé en 2016, mais la suite est attendue avec impatience.

En guise de conclusion

Ce bref aperçu des technologies linguistiques et sémantiques permet de se faire une idée des perspectives qui se profilent dans la recherche d’informations. Nous continuerons à suivre les dernières avancées dans nos futures publications.