Stage de Antoine Herkens - IUT Belfort-Montbéliard - [8/04/19 au 14/06/19]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter André, Sébastien, Thomas

Sujet

• Proposition de stage

Stage (Avril - Juin 2019)

Avril

• Lundi 8 :
  • arrivée,
  • journée d'accueil salle de réunion de la Coupole
  • présentations de simbad, vizieR, X-match, Aladin, xmm Newton, serveurs du CDS, documentalistes, chatbot...

• Mardi 9 :
  • lecture de la documentation d'Alexis (rapport, code, présentation, lexique) pour m'approprier le sujet et le contexte du projet,
  • réunion de début de stage avec Thomas Boch, André Schaaff et Sébastien Derrière pour définir les enjeux :
    • Priorité 1 : assurer la robustesse du chatbot
    • Priorité 2 : changer Dialogflow de V1 à V2
    • Autres enjeux : modifier le scénario, utiliser Thesaurus (UAT 2018 et Unified Content Descriptor, regroupant une grde qté de vocabulaire standardisé et hiérarchisé (galaxie > étoile)) pour filtrer et afffiner les requêtes, gérér un maximum s'il y a le temps les ambiguïtés pour avoir un chatbot souple, reconnaissance vocale n'est pas un objectif pour ce stage
    • Plan : Semaine du 8 : compréhension du processus de fonctionnement du chatbot, et de Dialogflow
    • Plan : Semaine du 15 : transition de Dialogflow à V2 (connexion, puis interprétation et parsing)
  • séance au planétarium

• Mercredi 10 :
  • lecture du code plus approfondie pour comprendre le cheminement et les principales actions/traitement, schéma récapitulatif du chemin des données
  • connexion à dialogflow, découverte du paramétrage et fonctionnement de l'agent
  • rédaction de "Changement version Dialogflow (v1 à v2)" regroupant tâches et procédures nécessaires
  • rédaction d'un lexique pour me familiariser avec les termes courant (astronomiques)
  • recherches sur deux pistes intéressantes :
    • possibilités de filtrage de demande utilisateur : fulfillment+ API
    • l'UAT a une API assez complète : sûrement exploitable pour affiner les demandes utilisateur peu précises ou sans sens

• Jeudi 11 :
  • répertorisation du code à modifier
  • lecture approfondie, tests sur le code existant pour pouvoir tracer le processus clairement
  • rédaction de "Structure et contenu du code" pour faciliter la migration de dialogflow par la suite

• Vendredi 12 :

  • backup du l'agent dialogflow v1 et création d'un nouvel agent v2 à partir du backup

  • pause du vendredi matin
  • séminaire de Sébastien : What's new at CDS?
  • migration :
    • (correct) création de compte de services sur google cloud platform : permettra (via OAuth) de call l'API
    • (correct) GOOGLE_CREDENTIAL mise en variable d'environnement (accède à "astronlpv2-f12f491ca036.json", qui a la clé privée)
    • (correct) : finalisation du google cloud sdk
    • (correct) installation de python, node et npm
    • (incorrect, inabouti) installation de dialogflow : npm install dialogflow
    • (incorrect, inabouti) problème de compréhension à cause de la doc incomplète : quelle est la syntaxe pour call l'api v2

• Lundi 15 :
  • finalisation du paramétrage de la google cloud plateform :
    • npm install --save dialogflow
    • export GOOGLE_APPLICATION_CREDENTIALS='/home/herkens/Documents/astronlpv2-f12f491ca036.json'
  • création d'un script test en Node.js qui se connecte à la v2 de dialogflow : connexion fonctionnelle, mais l'agent semble ne pas avoir d'intent
  • présentation métier d'astronome (Sébastien Derriere)
  • débogage du script de connexion à v2 (maintenant fonctionnel) : les langues désignées n'étaient pas exactement les mêmes, ce qui empêchait le bon fonctionnement
  • adaptation du script de connexion à dialogflow v2 pour le chatbot :
    • problème avec le require utilisé en node qu'il faut transformer pour être utilisable en web : essai avec browserify
      • commande posant problème : browserify ./web/js/nlu/nlu.js -o bundle.js

• Mardi 16 :
  • problème de lundi avec la commande : il fallait installer http et request avec npm
  • essais alternatifs à browserify avec requirejs mais non fructueux
  • problème : require is not defined : débogage avec sébastien puis j'ai trouvé la solution : ne pas inclure le script, juste le bundle (la commande avec bundle fait check déjà tous les require du script)
  • problème : le bundle jette une erreur, qui empêche donc le lancement du script

• Mercredi 17 :

  • débogage du dernier problème de mardi 16

    • il s'avère impossible de simplement intégrer le script de connexion en nodejs (serveur) au code javascript existant (client)
    • changement de technique : il faut créer un serveur pour dialogflow en node, et faire les appels au serveur depuis l'application js
  • programmation du serveur (qui fera la connexion à dialogflow), devant recevoir le message utilisateur depuis du js

• Jeudi 18 :

  • programmation du serveur et requete à travers une xmlhttprequest depuis un js
    • bug d'acces control origin (fonctionnel depuis postman mais pas depuis le navigateur)
    • bug résolu (problème d'url)

  • amélioration de la preuve de concept (ajout de la connexion à dialogflow) pour qu'elle récupère tout les paramètres nécessaires à dialogflow pour pouvoir ensuite simplement adapter dans le projet chatbot

    • non abouti : problème de tâche asynchrone

• Mardi 23 :
  • correction du problème de tâche asynchrone
    • preuve de concept terminée pour la connexion à dialogflow v2 depuis un script en js
  • adaptation de la preuve de concept dans le projet chatbot
    • réponses fonctionnelles du chatbot pour certaines requetes, sauf pour simbad (peut être problème à cause : encodeURL)
      • erreurs : Cross Origin, redirection forcée sur serveur local

• Mercredi 24 :
  • débogage fructueux : les erreurs de Cross Origin sont juste des problèmes de formats de requêtes, lié au mauvais parsing des résultats de dialogflow
  • fin du parsing : toute la démo est désormais fonctionnelle en avec la version 2 de dialogflow
  • début de refactoring de code pour plus de lisibilité : url dans des constantes dans un fichier config

• Jeudi 25 :
  • refactoring des constructions d'url pour plus de clarté
    • But : pouvoir modifier par la suite les appels aux services car certains sont dépréciés, ou alors changer le type de format récupéré (de xml à json par exemple)
  • réunion avec andré, sébastien et thomas pour expliquer mon travail réalisé et pour définir les objectifs suivants: compte rendu sur mon drive
  • écriture des log dans un fichier texte pour pouvoir comprendre le processus puis l'expliquer

• Vendredi 26 :
  • réunion, pause, séminaire
  • continuation du processus de logs
    • pour une session, pour chaque message utilisateur: intent, informations détectées par dialogflow, requete adql, url et service du CDS associé

• Lundi 29 :
  • tentative de débogage de la requête "could you check in vizier?" : erreur de parsing xml sous chrome mais pas sous firefox
    • plusieurs altlternatives proposées (https://stackoverflow.com/questions/649614/xml-parsing-of-a-variable-string-in-javascript/8412989#8412989), mais pas d'aboutissement

• Mardi 30 :
  • débogage des questions produisant des erreurs console
    • (corrigé) updateScrolling is not defined : remplacement de la fonction par refreshScrolling()
    • (non corrigeable, ok) "What are the magnitudes of sirius" : Failed to execute 'postMessage' on 'DOMWindow' : les services du CDS n'envoient pas de postMessage, donc pas possible de corriger côté chatbot
    • (non corrigeable, ok) Toutes les requêtes faisant appel à Aladin : produisent au moins une erreur de parsing : simplement liée au navigateur, donc pas de correction à apporte

  • modification de l'intent show_image (ajout d'une dizaine de training phrases) dans dialogflow pour plus de souplesse utilisateur : on peut désormais taper "sirius ir", ou juste "sirius", cela affiche l'image

Mai

• Jeudi 2 mai :
  • continuation de la modification de l'intent show_image pour plus de souplesse
  • modification de l'intent get_measure (ajout de training phrases) dans dialogflow pour souplesse utilisateur : on peut juste taper sirius ou m31, et les mesures "everything" sont affichées
    --> adaptation du code dans getMeasure()
  • modification de parsing JSON de dialogflow : puisque l'agent a été modifié, le JSON aussi
  • ==> toute la démo est fonctionnelle sous firefox; sous chrome : "could you check in vizier" et "try again" ne fonctionnent pas

• Vendredi 3 mai :

  • Visite coupole
  • débogage de "could you check in vizier" sous chrome : pas de solution trouvée après différents essais de parsing --> le pb vient du navigateur peut être?
    aide d'André mais pas de solution --> mise de côté pour y revenir plus tard, car pas une priorité

• Lundi 6 mai :

  • Warning CORS liés à show_image enlevés grâce au server web
  • filtre aladin choisi via une requête au Mocserver d'alasky

• Mardi 7 mai :

  • filtre aladin choisi le mocserver mais aussi grâce à la RA, DEC et triés par hips_order par défault
  • possibilité de changer le tri hips_order en moc_sky_fraction

• Jeudi 9 mai :

  • changement de filtre possible par un clic
  • createImageSurvey() puis setImage() pour rendre possible la visualisation d'un filtre pas enregistré par défaut
    • bug : le filtre choisi, malgré le tri par hips_order, n'est pas "bon" pour observation : beaucoup de noir, sûrement peu intéressant pour l'astronome

• Vendredi 10 mai :

  • changement de "IR en "Infrared" (suite à la demande de Thomas) pour avoir des filtres plus intéressants
  • tous les filtres sont affichés en résultat dans le chatbot, avec la possibilité de cliquer dessus pour changer (pas encore fonctionnel)
  • mini réunion avec André pour faire un point et définir le travail à faire pour la semaine prochaine (personnel absent : réunion IVOA)

• Lundi 13 mai :

  • débogage du problème de l'object passé en argument qui est forcé d'être un string (à cause de l'html)
    • débogage réussi : je passe l'id en argument seulement et je fais une recherche dans le tableau de filtres pour le retrouver ensuite
  • ajout de vérifications pour être sûr que les filtres soient bien tous valides

• Mardi 14 mai :

  • ajout de la requête pour voir une image en gas-line (url différente des autres longueurs d'ondes)
  • correction du bug "bye" --> chatbot répondait plus
  • tests multiples et variés : le chatbot semble stabe (question cependant sur les filtres qui sont souvent noirs)

• Mercredi 15 mai :

  • Début de programmation du serveur de logs node
  • Preuve de concept terminée : un texte est envoyé côté client au serveur qui l'écrit dans un fichier texte
  • Installation de forever pour que le serveur de dialogflow tourne en permance : sudo npm install -g forever puis forever start serverProofConcept.js
  • Adaptation du code pour envoyer les logs au serveur puis ensuite les écrire dans un fichier texte

• Jeudi 16 mai :

  • Fin de la programmation du serveur de log. Une fois le mode debug activé, tous les logs sont enovoyés au serveur node
  • L'utilisateur peut entrer un commentaire quand il le souhaite : celui-ci est ajouté à la fin des logs et correspond à la dernière réponse de dialogflow.
  • Les commentaires sont stockés sur le même serveur que celui des logs. Le commentaire permet d'améliorer le service, permet une sorte de feedback

• Vendredi 17 mai :

  • Séminaire sur "Evolution of Local Group dwarf galaxies as probed by resolved stellar populations"
  • Fin de la programmation du serveur qui stocke les logs et les commentaires dans des fichiers textes
  • Débogage des modes debug et commentaire et ajout de "sécurité" pour que l'on ne puisse pas rentrer de message invalide type exit dans le commentaire etc
    • L'utilisation de ces modes et la plus simple possible : on entre "debug" ou "comment" puis le chatbot guide l'utilisateur
  • A noter : le mode debug est destiné aux développeurs du chatbot, le mode commentaire aux utilisateurs qui reportent un problème

• Lundi 20 mai :

  • ajout de la réponse du chatbot dans les logs
  • changement de tactique pour l'intent "show_image" : un filtre par défault bien choisi est affiché, puis la liste des autres filtres sont ajoutés en dessous, puis on peut cliquer pour le changer
  • ajout de training phrases dans l'intent measure.context : permet des requêtes utilisateur plus souples et plus intuitives comme : "sirius" suivie de "everything about it"
  • débogage à moitié résolu pour l'enchaînement de ces requêtes : m31 puis show it. Cela ne fonctionne pas côté dialogflow, qui ne détecte pas le même intent à chaque essai
    • solution/contournement trouvé : ajout de training phrases dans image.contexte pour faciliter la reconnaissance, et utiliser "show me" au lieu de "show it, ce dernier étant trop aléatoire

  • rédaction des plans détaillés pour les présenter à M. Schaaf le 21 mai et à M. Salomon le 27 mai

• Mardi 21 mai :

  • rédaction du rapport
  • réunion avec André et Sébastien pour faire un point et définir les enjeux (voir les documents du drive qui synthétisent)

• Mercredi 22 mai :

  • débogage de l'encodage de l'url requêtant le mocserver, qui ne prend pas en compte le "dataproduct_type=image"
  • après des tests effectués par Sébastien, il trouve un nouvelle url qui ne comprte pas d'expression mais que des paramètres
    • http://alasky.unistra.fr/MocServer/query?RA=130.00&DEC=-16.00&SR=0.1&obs_regime=Optical&dataproduct_type=image&get=record&fmt=json&casesensitive=false
  • celle-ci fonctionne correctement et est plus pertinente. Cependant, il décide de ne pas traiter la longeur d'onde gas-lines car le mocserver contient des erreurs. Le bug est donc corrigé.
  • bug corrigé des coordonées ICRS [-1, -1]

• Jeudi 23 mai :

  • tentatives d'adaptation de la vue d'aladin en fonction de la taille et la magnitude de l'objet :
    • l'ajustement se fait, mais seulement depuis un serveur. Depuis le filesystem, l'appel ajax ne se fait pas
  • rédaction du rapport
  • modification des intents show_image et get_measure pour qu'ils ne prennent pas en compte juste un object sans information ou ordre
  • modification de please precise, mais pas encore aboutie

• Vendredi 24 mai :

  • rédaction du rapport
  • débogage:
    • en fonction de l'objet, l'intention détectée n'est pas la même : suppression des training phrases à 1 mot dans get_measure et show_image pour éviter une confusion d'intention
    • ajout de subtilité dans la fonction pleasePrecise() : si l'objet est connu, on cherche toutes les mesures à l'objet, sinon rien
    • bugs de updateSearchbar() appelée incorrectement : ajout d'un compteur pour vérifier
    • incompréhension lors d'un terme générique comme "information-" ou "measures-" "-about sirius" : si un terme général apparait, il est traité avec "everything"(modif dans code et dialogflow)

• Lundi 27 mai :

  • Visite de Michel Salomon
  • Overwriting des fichiers de logs et commentaires pour éviter la surcharge de fichiers
  • débogage
    • Ajout de gestion d'erreur pas faite dans certaines intentions : find_object, show_image, list_object
    • (en cours) problème d'envoi des logs pour "siblings of t tau", "Catalogues measuring redshift and parallax"

• Mardi 28 mai :

  • (en cours) problème d'envoi des logs pour "siblings of t tau", "Catalogues measuring redshift and parallax"
  • rédaction du rapport

• Mercredi 29 mai :

  • bug corrigé du problème d'envoi de logs : pour certaines requêtes, ils étaient trop longs. Il a donc fallu faire une vérification ligne par ligne avant de les envoyer.
  • permissions non accordées pour transférer le chatbot sur le serveur
    • Sébastien a réussi finalement à me donner les permissions
  • transfert des fichiers sur le serveur cds-chatbot.u-strasbg.fr
  • installation de node, npm, express, dialogflow pour faire tourner les serveurs node
  • bug dans dialogflowServer.js : ChatbotV2/node_modules/@grpc/grpc-js/build/src/index.js:45 // throw new Error(`@grpc/grpc-js only works on Node ${supportedNodeVersions}`); // Error: @grpc/grpc-js only works on Node ^8.13.0 || >=10.10.0

• Vendredi 30 mai :

  • bug de dialogflowServer.js du 29 mai réglé : installation d'une version 10 de node : https://linuxconfig.org/how-to-install-node-js-on-ubuntu-18-04-bionic-beaver-linux
  • mise en place fonctionnelle sur le serveur du cds
  • fin de rédaction des rapports

Juin

• Lundi 3 juin :
  • bug corrigé : les logs et commentaires ne fonctionnaient plus à cause d'un changement de chemin une fois sur le serveur
  • bug corrigé : "list some galaxies at redshift <= 0" pas fonctionnel à cause de condition ifOidExists, qui n'a pas lieu d'être dans l'intent list_object
  • déubt de programmation de la démo automatisée

• Mardi 4 juin :

  • fin de la programmation de la démo automatisée (fonctionnelle)
  • fin de rédaction du rapport technique

• Mercredi 5 juin :

  • changement dans les coordonnées ICRS
  • modification du css du chatbot pour plus de lisibilité

• Jeudi 6 juin :

  • changement du css
  • ajout d'exemples de noms d'étoiles, d'étoiles doubles, nébuleuses planétaires, pulsar et galaxies à l'intent get_measure
    • pas nécessaire de les ajouter dans les autres intent, car dialogflow apprend à détecter l'oid pour les autres intentions

• Vendredi 7 juin :

  • réunion infusion
  • ajout des quasars dans dialogflow dans get_measure
    • bug (corrigé par l'apprentissage de Dialogflow) pour pour le quasar WISE J015950.24+002340.9 : n'existe pas dans sésame et requetes TAP n'aboutissent pas non plus

  • modifications dans les magnitudes UBVRIJHKL

• Mardi 11 juin :

  • préparation de pré-soutenance
  • ma pré-soutenance et celles d'autres stagiaires
  • documentation du code

• Mercredi 12 juin :

  • fin de documentation du code
  • débogage avec Sébastien sur la requête TAP getFluxes() : dû au mauvais encodage, requête n'aboutissais pas

• Jeudi 13 juin :

  • ajout de flux dans getFluxes() et ajout de phrases d'entraînement pour détecter : "magnitudes of ..."
  • modification de la requete TAP pour donner l'oid de simbad dans getFluxes(oid) et non pas le nom d'objet comme effectué auparavant
  • correction du bug n'arrivant pas à afficher une image d'un objet : maitenant fonctionnel d'entrer "t tau", puis "its magnitudes" puis "show it"
  • entraînement de l'agent sur des phrases de find_object : le mot clé "radius" semble nécessaire au bon fonctionnement de la requête

• Vendredi 14 juin :

  • séminaire
  • installation du chatbot sur mon pc pour préparer la démo de soutenance
  • documentation du code et de mon travail, des suggestions à apporter etc
  • rédaction d'un guide d'installation du chatbotV2 sur une machine personnelle

Liens

• http://cds-chatbot.u-strasbg.fr/ChatbotV1/web/
• http://cds-chatbot.u-strasbg.fr/ChatbotV2/

Versions testables

• ...

Documentation

• Voir la partie "Attachments"

Liste des améliorations à envisager

• Les requêtes TAP devraient s'effectuer avec l'oid (numéro unique attribué par simbad) plutôt que le nom d'objet. Cela évite les traitements de chaînes de caractère et garantit de chercher les informations au bon endroit
• ajouter un système de reset, qui permet d’oublier le contexte d'apprentissage et de repartir sur une base correcte et donc non biaisée. Pour cela, il faudrait donc inclure un système évaluant la pertinence de la réponse (on pourrait se baser sur les logs de phrases fonctionnelles). Si c'est pertinent, le système peut continuer d'apprendre, sinon, il faut mettre la base de connaissance à jour.
• Pouvoir questionner les propros de l'utilisateur si ceux-ci ne sont pas clairs. Par exemple, si l'on demande une mesure qui n'est pas associée au type d'objet, proposer une suggestion, dire que sa demande n'a pas de sens plutôt que de répondre "je ne sais pas" ou une mesure vide

Liste de questions à propos de mesures astronomiques

Vérifier que le chatbot est capable d'interpréter des questions variées du type "What is the XXXX of YYYY ?" où XXXX est une grandeur physique, et YYYY est un nom d'objet astronomique. (questions 1, 2, 3, 4, 8, 11, 12 dans la liste du stage A. Guyot) Certaines mesures n'ont de sens que pour certaines catégories d'objets, il ne sera donc pas surprenant qu'ont n'ait pas de réponse en posant une question qui n'a pas grand sens.

Liste de noms d'objets groupés en quelques catégories pour varier les tests (sur une même ligne, les | séparent des noms équivalents d'un même objet) :

Etoiles :

• Vega
• Sirius
• Barnard's star
• HD 37805
• TYC 4771-793-1
• 2MASS J05414831-0210405 | [LLA2013] 31 | [MSJ2009] L1630MIR-81 | Gaia DR2 3216483553230620800
• alf Mon | alpha Mon | 26 Mon | ROT 1244 | HR 2970 | BD-09 2172 | Gaia DR2 3041619014954275712
• V* HS Vul

Etoiles doubles :

• ** WNO 7
• LP 395-8 | RX J2019.8+2256 | UCAC4 565-110196

Nébuleuse planétaire :

• M27
• PN M 1-16 | PN VV 41 | SCM 26 | [LFO93] 0734-09

Pulsar :

• Geminga | 2E 1697 | PSR J0633+1746
• Crab PSR | V* CM Tau | SN 1054

Galaxies :

• LMC
• SMC
• 2MFGC 15380 | 2MASX J20122414+1917287
• NGC 4038
• NGC 4039
• Antennae galaxies
• NGC 7582 | ESO 291-16 | [VV2010c] J231823.5-422214

Quasar :

• 4C 11.69 | 3FGL J2232.5+1143
• Mrk 1014 | 1RXS J015950.6+002337 | WISE J015950.24+002340.9

Quelles mesures ont un sens pour différents types d'objets :

(1) On peut traduire le redshift en radial velocity... (2) Pour les étoiles la distance peut être calculée comme l'inverse de la parallaxe. Pour les galaxies et QSO, cela peut se mesurer autrement, c'est moins fréquent. (3) Pour les étoiles ou étoiles doubles variables et périodiques (4) Le plus souvent, on va demander une magnitude spécifique: magnitude B, magnitude V, magnitude G Gaia, infrared magnitude... idem pour un flux, on va chercher le flux radio, ou en rayons X...

Bugs connus

• "could you check in vizier" et "try again" ne fonctionnent pas sous chrome. Le navigateur ne parse pas le xml correctement et donc fait crasher le processus de récupération de données.Pas de solution trouvée pour forcer un parsing du DOM en fonction du navigateur.

Sauvegarde des agents: AstroNLP-200819.zip - AstroNLPv2-200819.zip