Livrable L6.1.1 Dossier d architecture et des technologies v1

Texte intégral

(1)Livrable L6.1.1 Dossier d’architecture et des technologies v1.

(2) Projet Acronyme. : LinTO. Nom complet. : LinTO : Assistant vocal open-source respectueux des données personnelles pour l'entreprise. Type. : Investissements d'Avenir - Grands défis du Numérique. Date de début. : 1er Avril 2018. Livrable Numéro. : L6.1.1. Nom. : Dossier d’architecture et des technologies v1. Version. :3. Date. : T0+12. Rédacteur(s). : Sarah Zribi, Damien Lainé, Sami Benhamiche, Abdelwahab Heba, Yoann Houpert, Ilyes Rebai, Guokan Shang, Rudy Bargalia, Romain Lopez, Jean-Pierre Lorré.. Editeur(s). : Sarah Zribi. Résumé Ce document décrit le fonctionnement technique du traitement des requêtes formulées à l’assistant LinTO / Traitement des données multi-modales captées dans le contexte d’une réunion.. Mots-clés LinTO-Client, Client-serveur, LinTO-Platform, architecture. i.

(3) Historique du documentHistorique du document Ver. N. Rédacteur(s). Description. 1 2. Damien Lainé Création du document Sarah Zribi, Damien Lainé, Sami Version intermédiaire Benhamiche, Abdelwahab Heba, Yoann Houpert, Ilyes Rebai, Guokan Shang, Rudy Bargalia, Romain Lopez, JeanPierre Lorré.. 3. Sarah Zribi, Damien Lainé, Sami Version Finale Benhamiche, Abdelwahab Heba, Yoann Houpert, Ilyes Rebai, Guokan Shang, Rudy Bargalia, Romain Lopez, JeanPierre Lorré.. ii.

(4) Table des matières. 1.DU CHOIX D’UNE ARCHITECTURE CLIENT-SERVEUR........................................................................................ 1 1.1.LES TROIS FONDAMENTAUX DU POSITIONNEMENT DE L’OFFRE LINTO..........................................................................1 1.1.1.L’utilisation de l’ASR chez nos clients finaux...................................................................................................... 1 1.1.2.Les besoins liés à un traitement large vocabulaire.............................................................................................. 1 1.1.3.Besoin de rationaliser l’exploitation d’une flotte d’équipements........................................................................ 2 2.ARCHITECTURE DE LA PLATEFORME SERVEUR................................................................................................. 2 2.1.SERVICES FONCTIONNELS AUTONOMES...........................................................................................................................3 2.1.1.API de décodage LinSTT (Speech To Text)...........................................................................................................3 2.1.2.Service de Natural Language Understanding...................................................................................................... 4 2.1.3.Service d'exécution de compétences..................................................................................................................... 4 2.2.SERVICES LIÉS EXCLUSIVEMENT À LINTO......................................................................................................................5 2.2.1.Interface d’administration....................................................................................................................................5 2.2.2.Compétences de LinTO.........................................................................................................................................6 2.2.3.Autres services avec un rôle purement technique.................................................................................................8 2.3.IMPLÉMENTATION TECHNIQUE........................................................................................................................................ 8 2.4.DIAGRAMME D’ARCHITECTURE TECHNIQUE................................................................................................................... 9 3.CLIENT LINTO MATÉRIEL V1.....................................................................................................................................11 3.1.3.1 SERVICES FONCTIONNELS........................................................................................................................................11 3.1.1.linto-command-module....................................................................................................................................... 11 3.1.2.linto-tts................................................................................................................................................................ 11 3.1.3.linto-gui.............................................................................................................................................................. 12 3.1.4.linto-client...........................................................................................................................................................12 3.2.SERVICES TECHNIQUES..................................................................................................................................................12 3.2.1.Service audio...................................................................................................................................................... 12 3.2.2.Broker MQTT..................................................................................................................................................... 12 3.3.ARCHITECTURE TECHNIQUE..........................................................................................................................................13 3.4.PROTOCOLE DE COMMUNICATION EXTERNE................................................................................................................. 13 3.5.CAS DU CLIENT MULTI-PLATEFORME............................................................................................................................ 14. iii.

(5) 1. Du choix d’une architecture client-serveur Dès les prémices de la conception de l’assistant LinTO, nous avons analysé les différentes possibilités d’architecture technique que nous devions privilégier pour atteindre nos objectifs de création de valeur dans le domaine des assistants vocaux et particulièrement pour répondre aux enjeux du marché B2B. Les possibilités qui nous étaient ouvertes initialement étaient nombreuses et toutes extrèmement dimensionnantes quant à la démarche de R&D. La première idée, la plus directe, que nous aurions pu privilégier a été d’embarquer systématiquement tout le traitement “on edge”, c’est à dire directement dans le client matériel de référence. Dans le cadre du travail collaboratif et itératif avec nos partenaires, nous avons rapidement compris trois choses qui forgèrent les fondamentaux de ce qu’allait devenir la Plateforme LinTO.. 1.1.Les trois fondamentaux du positionnement de l’offre LinTO 1.1.1. L’utilisation de l’ASR chez nos clients finaux L’ASR (Automatic Speech Recognition / Reconnaissance Automatique de la Parole) est un enjeu majeur pour les entreprises. Un service de STT (Speech to text / Transcription de la parole) devrait être disponible pour d’autres flux de travail à l’intérieur de l’entreprise, par exemple pour “vocaliser” des applications métier ou des chatbots. Dans ce cadre, la valeur apportée par une solution fonctionnant On Premise (sur infrastructures techniques propres) est le premier critère d’évaluation pour les services DSI / R&D afin de répondre aux enjeux RGPD et sécurité de la donnée. Ce critère exclut de facto les API de transcription vocale des GAFAM et nous ouvre un marché qui semble particulièrement porteur. Pour résumer, tant que le traitement des données ne part pas “quelque-part sur internet” la solution est qualifiable. Le deuxième critère d’évaluation d’une solution de STT et la capacité du système à supporter une exploitation souple quant à l'entraînement de modèles de données. Une solution idéale permet d’ajouter facilement des annuaires de noms propres ou encore des termes métier (du jargon technique, des nomenclatures de documents, des acronymes, du “franglais” ou d’autres barbarismes). Nous réalisons que nous sommes en mesure d’adresser parfaitement efficacement ces deux critères cruciaux et que le traitement “on edge” des interactions utilisateur est un critère de second plan pour les décideurs et les usagers. 1.1.2. Les besoins liés à un traitement large vocabulaire Dans le cadre particulier de la salle de réunion et de l’assistance personnelle, nous distinguons deux groupes de besoins en terme d’ASR : 1. La reconnaissance et de commandes simples (mode commande de LinTO) : Pour demander une simple information ou piloter un équipement domotique (“Quelle heure est-il à Hong-Kong”, “Allume la lumière” etc.) 2. L’exploitation des données produites lors d’une réunion incluant plusieur participants : Dans ce cas, LinTO doit proposer une analyse du contenu multi-locuteur, multi-modale (renforcée par l’acquisition vidéo) et associée à un vocabulaire infini. 1.

(6) Dans ce second cas (vocabulaire large, multimodal, multi-locuteur), la performance et la pertinence des traitements est amenée à évoluer technologiquement (utilisation de nouvelles puces dédiées à l’IA, parallélisation massive GPU etc.). Ainsi, la centralisation de cet aspect dans une plateforme serveur permet de proposer un client matériel plus léger, plus évolutif, plus pertinent et bien-sûr plus portable Le retour que nous recevons quant à cet approche semble particulièrement favorable. D’autres acteurs du marché, comme Snips, proposent un traitement “on edge” uniquement, cela questionne les exploitants quant à la facilité de mettre à jour les modèles de reconnaissance de la parole embarqués - voir point suivant. 1.1.3. Besoin de rationaliser l’exploitation d’une flotte d’équipements Les exploitants d’une flotte d’équipements qui réalisent un traitement automatique du langage naturel ont un besoin d'efficacité (mes équipements fonts ce que je veux) et d'efficience (le rendement est bon, cela me fait gagner de l’argent et du temps). Cet aspect est particulièrement crucial. La différenciation de design de notre plateforme, qui centralise certains traitements, permet la liaison centralisée avec les producteurs de données de l’entreprise et ajoute un nécessaire outil d’exploitation et d’administration des flottes de terminaux physiques ou virtuels (apps, clients LinTO multiplateforme). Comprenons cela avec quelques exemples extrêmes qui forment autant de conditions sinéquanones pour permettre la mise en service d’équipements au sein des DSI exigeantes de nos partenaires et futurs clients : 1.. Aucun exploitant ne souhaite gérer la sécurité et la maintenance d’informations d’authentification vers leur SI (bus, building operating system …) terminal par terminal.. 2.. Aucun exploitant ne souhaite se connecter manuellement à des équipements (potentiellement disséminés géographiquement) pour y configurer point par point un LDAP ou l’adresse IP du vidéo-projecteur présent dans le réseau local.. 3.. Un terminal doit être entièrement télé-opéré et paramétré à distance. Un terminal doit pouvoir être remplacé ou déplacé sans nécessiter aucune opération lourde de provisionning (stockage d’unité de remplacement & opérations de mis en service) cf : OTP LIN 1 : Première version du dispositif matériel LinTO 5.3 Mécanismes de de mise en service - enrôlement externe. 4.. Cela est encore plus important quand on considère la tierce maintenance applicative, la mise à jour de sécurité ou l’évolution des fonctionnalités locales de chaque équipement (cf : OTP LIN 1 : Première version du dispositif matériel LinTO - 5.4 Exploitation et tierce maintenance applicative).. 2. Architecture de la plateforme serveur LinTO Platform est composée de plusieurs services fonctionnels. Un service est un composant pouvant potentiellement être utilisé de manière autonome pour prendre place dans un flux de travail ad hoc. LinTO Platform intègre également plusieurs services dédiés spécifiquement à l’exploitation et à la maintenance de flottes de clients LinTO.. 2.

(7) 2.1.Services fonctionnels autonomes L’application LinTO Platform est décomposable en 3 services qui constituent une boîte à outils pour les applications vocales de toutes sortes. Chacun des services / modules évoqués, outre la distribution de ses sources complètes sur GitHub, dispose d’une image Docker directement utilisable et disponible sur le DockerHub de LinTO https://cloud.docker.com/u/lintoai 2.1.1. API de décodage LinSTT (Speech To Text) Les technologies au coeur de cet outil sont détaillées dans le livrable L2.1.1 Système BaselineRAP situation réunion. L’implémentation technique que nous proposons dans la boîte à outils inclut : •. Un module “worker-standalone” : Propose une API REST directement pour réaliser les traitements de fichiers audio qui lui sont envoyés. cf : le dépôt linto-platform-stt-standaloneworker dans la forge du projet. •. Un couple de modules “worker-server” : Propose une API REST au niveau du module “server” qui consomme ensuite, via Websockets, différents “workers” qui se sont préalablement enregistrés auprès de lui. cf : le dépôt linto-platform-stt-server-worker-client dans la forge du projet.. •. Remarque : Ce dépôt n’est plus activement maintenu au profit du “worker-standalone”. Nous en faisons mention ici puisqu’il est encore utilisé dans les processus de décodage à large vocabulaire.. Les API sont documentées avec un client HTTP Swagger qui permet de tester les API directement depuis une page web. Le lancement du client Swagger est une fonctionnalité optionnelle du démarrage d’un des modules précédemment cités.. Figure 1. Exemple de vue d’utilisation du client Swagger pour consommer l’API de transcription. Enfin, les modèles (machine learning) pour réaliser les inférences sont également fournis sur notre GitHub sous formes de GitHub releases. 3.

(8) 2.1.2. Service de Natural Language Understanding La boîte à outil inclut une API de traitement des utterances qui lui sont transmises au format texte. Le rôle de cette API consiste à extraire les intentions et à valoriser les entités. Le système de NLU que nous distribuons (DockerHub / GitHub et modèles GitHub release) est articulé autour du projet Tock 1 de Voyages SNCF (The Open Conversation Kit). Nous décrivons en détails son fonctionnement dans le livrable L4.2.4 Spécification des intentions à usage personnel groupe 1. 2.1.3. Service d'exécution de compétences Basé sur un Runtime “Node Red” d’IBM - https://nodered.org, Il permet la mise en service de compétences pour un ou plusieurs clients LinTO dans leurs contextes métier (Une salle de réunion, un couloir ou encore dans le cadre du pilotage d’une application à la voix) Ce service est, résumé dans son rôle le plus générique, un consommateur des données sur les bus de données de l’entreprise. Il traite ensuite ces données (exécution des compétences) et renvoie de la donnée sur les mêmes bus. Dans le cadre d’une utilisation avec de compétences dédiés à LinTO, ce service est fortement couplé avec le service “LinTO Admin” que nous décrirons plus loin et qui permet de le paramètrer pour consommer et produire de la donnée en lien avec un client LinTO (données audios & commandes transformées en actions concrètes). Nous produisons également ce service sous forme d’une image Docker. Les sources sont disponibles dans la forge du projet sur le dépôt : linto-platform-business-logic-server Nous décrivons en détail l’usage qui en est fait dans le livrable L4.2.1 Spécification de l’API générique pour les outils de productivité.. Figure 2. Architecture en flux des “Skills”.. 1. The Open Conversational Toolkit https://github.com/voyages-sncf-technologies/tock 4.

(9) 2.2.Services liés exclusivement à LinTO Chacun des services / modules évoqués, outre la distribution de ses sources complètes sur GitHub, dispose d’une image Docker directement utilisable et disponible sur le DockerHub de LinTO https://cloud.docker.com/u/lintoai. 2.2.1. Interface d’administration Disponible sur le dépôt “linto-platform-admin”. Il s’agit d’une application web permettant de réaliser toutes les opérations liées à l’exploitation d’une flotte de clients LinTO •. Ajouts de contextes métier (création de salles de réunion). •. Association entre un client LinTO à une application ou à une salle de réunion. •. Déploiement et paramètres de compétences LinTO dans le contexte métier. •. Pilotage des mises à jour. •. Monitoring. •. Paramétrage des modèles de NLU. •. Paramétrage des langues utilisées. •. Réglage du niveau sonore. •. etc.. Figure 3. Monitoring de flottes.. 5.

(10) Figure 4. Monitoring et paramétrage d’un client LinTO.. Figure 5. gestion des salles de réunion.. Figure 6. Éditeur de flow Node Red intégré à LinTO-Admin.. LinTO admin est l’application centrale qui verra sa spécification grandement augmenter tout au long du déroulement du projet. En effet le concept de réunion (sous forme d’entité liée à plusieurs utilisateurs) et l’exploitation des données produites lors des réunions sur les plateformes de productivité (OpenPaaS) seront centralisées pour un accès depuis cette application web. 2.2.2. Compétences de LinTO Chaque compétence dédiée à un usage LinTO dans le framework Node Red est un module node.js publié sur le dépôt NPM https://www.npmjs.com/settings/linto-ai/packages Les sources de ces compétences sont disponibles dans la forge du projet “linto-skills-toolbox”. Les compétences LinTO sont également listées sur le dépôt de Node Red.. 6.

(11) Figure 7. Les skills LinTO listés sur NPM.. 7.

(12) Figure 8. Les skills LinTO listés sur le site de Node Red https://flows.nodered.org/. 2.2.3. Autres services avec un rôle purement technique Le fonctionnel de la Plateforme LinTO attaché à une flotte de clients LinTO repose sur un réseau de micro-services intégrant : •. Des bases de données (Mongo DB). •. Des bases de données Redis pour les sessions des interfaces Web. •. Un broker MQTT Mosquitto pour permettre la connexion TCP sur TLS des clients LinTO. •. Un routeur HAProxy comme seul point d’entrée à la plateforme serveur et réaliser le decypher SSL. •. Un reverse-proxy Nginx pour router les requêtes HTTP et WebSocket entrantes vers les bon services. Le rôle de ces services étant purement technique, nous proposerons un dépôt technique “ lintoplatform-stack” dans la forge du projet. Ce dépôt proposant des templates de déploiement sur plateforme Docker (Swarm ou Compose). 2.3.Implémentation technique Dans le cadre d’un déploiement, nous utilisons donc Docker-Compose (sur une seule machine physique ou virtuelle par service) ou Docker en mode Swarm (pour une distribution des services sur un cluster de machines physiques ou virtuelles).. 8.

(13) À cette étape du projet, seule l’implémentation utilisant Docker-Compose (ou en lançant uns à uns les modules voulus à partir des dépôts) est disponible. La future utilisation de Docker Swarm (ou d’autres ordonnanceurs de services comme kubernetes) permettra la montée en charge des requêtes à destination de la plateforme, ainsi que l’usage de services spécialisés, comme par exemple des versions de LinSTT paramétrées pour utiliser des GPU).. 2.4.Diagramme d’architecture technique. 9.

(14) Livrable L6.2.1 Plateforme logicielle et matérielle LinTO V0.

(15) . Figure 10. L’architecture client-serveur de LinTO résumée.

(16) 3. Client LinTO matériel V1 Le client matériel de référence est conçu pour utiliser un Operating System Linux ARM customisé tel que décrit dans le livrable L3.2.3 - Prototype LinTO V1 au point 3.3 Operating system - LinTO OS generator. Sur une image LinTO OS ainsi produite, nous retrouvons installés, accompagnés de services Linux system.d, les services fonctionnels et techniques nécessaires.. 3.1.3.1 Services fonctionnels 3.1.1. linto-command-module cf dépôt “linto-command-module” dans la forge du projet. Ce service a pour tâches : •. De se connecter au bus audio (entrée son). •. D'acquérir le son en permanence. •. De réaliser l’extraction de paramètres MFCC. •. De réaliser les inférences avec le modèle de mot-réveil. •. De réaliser la détection des utterances (début et fin de la parole pour le mode commande). •. De publier sur un broker MQTT local les événements détectés. 3.1.2. linto-tts cf dépôt “linto-tts” dans la forge du projet. Ce service a pour tâches : •. De se connecter au broker MQTT local et de consommer les signaux lui demandant de vocaliser une réponse (LinTO parle). 11.

(17) 3.1.3. linto-gui cf dépôt “linto-gui” dans la forge du projet. Ce service a pour tâches : •. D’afficher l’application graphique LinTO. •. De consommer des signaux MQTT sur un broker MQTT local afin de changer d’état (LinTO écoute, LinTO est en train de parler…). •. De produire des signaux MQTT sur un broker MQTT local afin d’informer les autres services de l’utilisation de l’écran tactile (mode silencieux, son augmenté…). •. De produire des sons liés à l’expérience utilisateur (bip à l’activation d’un mot-réveil…).. 3.1.4. linto-client cf dépôt “linto-client” dans la forge du projet. Ce service a pour tâches : •. D’être le seul point de connexion externe vers la plateforme serveur. •. De stocker et mettre à jour les informations techniques liées à un LinTO (numéro de série, adresse du serveur d’exploitation…). •. D’envoyer les événements et les signaux audio vers la plateforme serveur. •. De recevoir les ordres techniques liés au monitoring et à l’exploitation. •. De séquencer les événements émergents sur le broker MQTT local à destination des autres services fonctionnels. •. De changer de rôle pour activer / désactiver les fonctionnalités “net-install”, nécessaires pour la mise à jour de l’OS, des services ou des processus d’enrôlement. 3.2.Services techniques 3.2.1. Service audio Au sein de LinTO OS se trouve un service système qui permet de paramétrer les entrées et sorties audio afin d’assurer la compatibilité plug’n play de périphériques son. Ce service permet notamment de multiplexer les connexions des autres services au bus audio. C’est techniquement un “wrapper” pour un daemon pulseaudio utilisé en mode client : https://www.freedesktop.org/wiki/Software/PulseAudio/ 3.2.2. Broker MQTT Les services fonctionnels communiquent entre eux via des échanges de signaux sur un broker MQTT embarqué sur le device (MQTT local, attaché à un port TCP sur localhost). Nous utilisons Mosquitto : https://mosquitto.org/ Nous choisissons d’utiliser une architecture technique s’apparentant au design pattern de blackboard 2 utilisant un “mini” broker MQTT (embarqué) pour échanger des signaux auxquels accèdent des 2. https://social.technet.microsoft.com/wiki/contents/articles/13215.blackboard-designpattern.aspx#Examples_of_the_blackboard_pattern Lalanda, P., Two complementary patterns to build multi-expert systems, Orsay, France: Thomson CSF Corporate Research Laboratory. 12.

(18) processus autonomes distincts déployés sous forme de services. Un ordonnanceur surveille les propriétés des signaux échangés et détermine les actions à prioriser. Dans le cas du client LinTO, cet ordonnanceur interne (service linto-client) relaie des messages reçus ou envoyés en relation avec la plateforme serveur à travers une connexion sécurisée. Cette connexion est aussi une connexion MQTT mais cette fois-ci utilisant les interfaces réseau externes afin de faire transiter les signaux par le réseau. Chacun des services embarqués sur le client LinTO utilise le “blackboard” MQTT interne pour produire ou consommer des signaux et composer ainsi des actions à destination finale d’un humain (feedback visuels et sonores) Les services développés incluent un système de vocalisation (Text To speech, le mécanisme de hotword, l’interface graphique etc.). 3.3.Architecture technique. 3.4.Protocole de communication externe Le module fonctionnel “linto-client” se connecte en TCP sur TLS vers la plateforme LinTO en utilisant un certificat SSL et une authentification par mot de passe. L’avantage du protocole TCP est qu’il est sortant. C’est le client qui établit la connexion au serveur et la maintient via le mécanisme de tcp keep-alive. Ceci permet ensuite au serveur d’adresser à n’importe quel moment des datagrammes TCP (porteurs de messages MQTT) dans la connexion ainsi maintenue ouverte. Ce fonctionnement permet de bénéficier d’une règle simple à mettre en oeuvre dans les firewall des entreprises. Aucun 13.

(19) NAT n’est nécessaire pour joindre le client depuis le serveur. MQTT permet de passer n’importe quel message sur les topics, par exemple du binaire (images provenant des caméras, audio…) ou du JSON, selon les besoins. MQTT introduit la notion de qualité de service (QOS) qui permet à un client de s’assurer qu’un message a bien été transmis, avec différents niveaux de fiabilité. Pour le monitoring de l’état de connexion, MQTT introduit la notion de “last will message”, qu’on pourrait traduire par “testament”. Il s’agit d’un message qui est envoyé automatiquement lorsqu’un client se déconnecte. Cela permet à n’importe quel consommateur de ce message d’être notifié “post mortem” de la déconnexion d’un autre client et d’agir en conséquence. MQTT depuis sa version 3.1.1 est un standard OASIS, (consortium mondial qui travaille pour la standardisation de formats de fichiers ouverts). Il existe de nombreuses implémentations dans la plupart des langages de programmation (C, C++, Java, Python, …). Dans le cas de la plateforme LinTO, un service (optionnel) est prévu pour enregistrer en permanence sur une base de donnée les connexions / déconnexions des clients LinTO sur le broker MQTT (“last will message”). Ce service s'appelle “linto-platform-overwatch”, il est dédié à ce monitoring. Les sources de ce logiciel sont présents dans la forge du projet.. 3.5.Cas du client multi-plateforme Cette spécification modulaire des différents composants du système client nous permet d’envisager une implémentation technique sur d’autres plateformes en tenant compte de leurs spécificités. cf : L3.2.1 - Plan d’industrialisation du dispositif LinTO V1 - point 3.3.1 Operating system Android compatible LinTO et 3.3.3 Plateforme hardware. 14.

(20)