![\"\"](\"https:\/\/www.nuecho.com\/wp-content\/uploads\/2020\/09\/avertissement.jpeg\")
<\/p>\n[et_pb_section admin_label=\u00a0\u00bbsection\u00a0\u00bb]
\n[et_pb_row admin_label=\u00a0\u00bbrow\u00a0\u00bb]
\n[et_pb_column type=\u00a0\u00bb4_4″][et_pb_text admin_label=\u00a0\u00bbText\u00a0\u00bb]<\/p>\n
<\/p>\n
Comme je l\u2019ai mentionn\u00e9 dans la premi\u00e8re partie, l\u2019objectif du module de question-r\u00e9ponse (Q&R) \u00e9tait de permettre \u00e0 l\u2019utilisatrice\u00b2 de poser une question au sujet de la Covid-19, pour laquelle nous afficherions la r\u00e9ponse retourn\u00e9e par l\u2019API du mod\u00e8le du Mila. Il y a eu plusieurs versions de cette portion de l\u2019application, allant de tr\u00e8s basique \u00e0 plut\u00f4t complexe, et celle-ci a \u00e9t\u00e9 incorpor\u00e9e \u00e0 un nombre de plus en plus grand d\u2019endroits dans le dialogue.<\/p>\n
Dans la version initiale du flux de Q&R, l\u2019utilisatrice devait choisir l\u2019option \u201cJ\u2019ai des questions\u201d du menu principal ou apr\u00e8s une \u00e9valuation, apr\u00e8s quoi l\u2019application recueillait sa question. Nous avons pr\u00e9vu quatre r\u00e9sultats possibles provenant de l\u2019appel \u00e0 l\u2019API (le quatri\u00e8me n\u2019\u00e9tait toujours pas disponible au moment o\u00f9 notre participation au projet a pris fin):<\/p>\n
Si le r\u00e9sultat \u00e9tait un succ\u00e8s, Chlo\u00e9 posait une question suppl\u00e9mentaire afin de savoir si la r\u00e9ponse avait \u00e9t\u00e9 utile (l\u2019interface de clavardage<\/a> que nous devions utiliser ne fournissait pas de boutons de type \u201cj\u2019aime\/je n\u2019aime pas\u201d (thumbs-up\/thumbs-down) qui nous auraient permis de facilement sauter cette interaction). Si le r\u00e9sultat \u00e9tait hors distribution, alors on demandait \u00e0 l\u2019utilisatrice de reformuler sa question.<\/p>\n Recueillir la question, la reformulation de celle-ci et la r\u00e9troaction sur l\u2019utilit\u00e9 de la r\u00e9ponse pouvaient tous \u00eatre inclus dans un formulaire<\/em>; cependant, l\u2019impl\u00e9mentation des transitions vers les autres portions du dialogue \u00e9tait moins claire. Il y avait 6 transitions diff\u00e9rentes \u00e0 partir du flux de Q&R selon le r\u00e9sultat et la pr\u00e9sence de la case \u201cself_assess_done\u201d d\u00e9crite pr\u00e9c\u00e9demment. Nous avons vaguement consid\u00e9r\u00e9 la possibilit\u00e9 de demander \u00e0 l\u2019usager ce qu\u2019il voulait faire ensuite \u00e0 l\u2019int\u00e9rieur du formulaire<\/em>, afin de centraliser la logique du flux de Q&R, mais cette id\u00e9e a \u00e9t\u00e9 mise de c\u00f4t\u00e9 puisque nous n\u2019avons pas trouv\u00e9 de fa\u00e7on \u00e9l\u00e9gante d\u2019impl\u00e9menter cela. Pour cette raison, nous avons finalement eu recours aux histoires<\/em> et \u00e0 la politique TED pour pr\u00e9dire les transitions d\u00e9terministes.<\/p>\n Nous \u00e9tions aussi confront\u00e9s au probl\u00e8me d\u00e9coulant du fait que certaines de ces transitions \u00e9taient des questions de type \u201caffirm\/deny\u201d (autrement dit une intention bool\u00e9enne), \u201caffirm\u201d menant soit vers une \u00e9valuation ou vers une autre question. \u00c0 ce point, nos histoires<\/em> d\u2019\u00e9valuation de base d\u00e9marraient directement avec une intention \u201cget_assessment\u201d comme raccourci pour la m\u00e9mo\u00efsation, et d\u00e9marrer une histoire<\/em> avec \u201cget_assessment OR affirm\u201d aurait \u00e9videmment g\u00e9n\u00e9r\u00e9 des correspondances ind\u00e9sirables. Nous avons remis cet enjeu \u00e0 plus tard avec une solution qui fonctionnait seulement parce que nous contr\u00f4lions les r\u00e9ponses des utilisateurs par le biais de boutons. Comme ceci:<\/p>\n Un raccourci d\u2019intentions avec des boutons <\/em><\/p>\n Ainsi, nous n\u2019avions pas besoin d\u2019ajouter des histoires du module de question-r\u00e9ponse suivi d\u2019une \u00e9valuation, mais avec le recul, nous aurions d\u00fb le faire d\u2019entr\u00e9e de jeu, puisque l\u2019ajout d\u2019histoires d\u2019\u00e9valuations suivies de Q&R fonctionnait (somme toute) bien, et nous avons d\u00fb le faire de toute fa\u00e7on lors de l\u2019ajout du TALN.<\/p>\n Le design du flux d\u2019inscription au suivi quotidien a \u00e9t\u00e9 approfondi pour y inclure certains cas d\u2019exceptions. Cela \u00e9tait n\u00e9cessaire puisque le num\u00e9ro de t\u00e9l\u00e9phone et le code de validation \u00e9taient recueillis aupr\u00e8s de l\u2019utilisatrice directement sous forme de texte. Voici les cas plus probl\u00e9matiques que nous avons trait\u00e9s:<\/p>\n Certains de ces cas se trouvent \u00e0 mi-chemin entre une digression et de la gestion d\u2019erreur, et nous avons pens\u00e9 les impl\u00e9menter comme des digressions \u201ccontr\u00f4l\u00e9es\u201d, de la m\u00eame fa\u00e7on que nous l\u2019avions fait pour l\u2019explication des ant\u00e9c\u00e9dents m\u00e9dicaux, qui va comme suit:<\/p>\n Mais puisque la plupart impliquaient le recours \u00e0 des compteurs et messages d\u2019erreurs de m\u00eame qu\u2019\u00e0 d\u2019autres \u00e9l\u00e9ments plus complexes, nous avons d\u00e9cid\u00e9 de g\u00e9rer tous ces cas \u00e0 l\u2019int\u00e9rieur de formulaires<\/em> plut\u00f4t que de distribuer la logique entre formulaires<\/em>, histoires<\/em> et correspondances (mappings<\/em>) d\u2019intentions. Cela a pr\u00e9sent\u00e9 des inconv\u00e9nients (au-del\u00e0 des centaines de lignes de code suppl\u00e9mentaires): une partie de la logique s\u2019\u00e9chelonnait sur plusieurs interactions et nous avons d\u00fb ajouter plusieurs cases pour disposer de compteurs et de drapeaux\u00b3 pour en suivre la progression (notre version finale du formulaire<\/em> utilise une dizaine de telles cases).<\/p>\n Apr\u00e8s quelques essais, il a \u00e9t\u00e9 port\u00e9 \u00e0 notre attention qu\u2019il \u00e9tait possible pour une utilisatrice de se retrouver coinc\u00e9e dans une boucle infinie dans le Q&R puisque la seule option offerte \u00e9tait de reformuler la question. Le design a \u00e9t\u00e9 modifi\u00e9 afin de permettre \u00e0 l\u2019utilisatrice de soit r\u00e9essayer, soit sortir du Q&R, et nous avons ajout\u00e9 2 transitions pour ce cas.<\/p>\n En ajoutant ces transitions, nous avons frapp\u00e9 un petit noeud: la politique TED<\/a> n\u2019apprenait pas le bon comportement apr\u00e8s le Q&R; elle confondait les impacts des cases \u201cquestion_answering_status\u201d et \u201csymptoms\u201d. La redistribution \u00e9quilibr\u00e9e dans nos histoires<\/em> des exemples de Q&R entre les \u00e9valuations sans sympt\u00f4mes, avec sympt\u00f4mes l\u00e9gers ou mod\u00e9r\u00e9s, a repr\u00e9sent\u00e9 un travail de moine, mais cela a fonctionn\u00e9. Au final, la politique<\/em> pr\u00e9disait le bon comportement pour les conversations qui n\u2019\u00e9taient pas repr\u00e9sent\u00e9es dans nos histoires.<\/p>\n La recherche de cliniques de d\u00e9pistage, apr\u00e8s avoir eu maille \u00e0 partir avec les transitions du Q&R et la gestion d\u2019erreurs de l\u2019inscription au suivi quotidien, n\u2019a pr\u00e9sent\u00e9 aucun nouveau d\u00e9fi. Le dialogue comprenait trois \u00e9tapes principales:<\/p>\n Suivant la logique de nos impl\u00e9mentations pr\u00e9c\u00e9dentes, nous avons utilis\u00e9 un formulaire<\/em> pour le code postal et la gestion d\u2019erreurs, les appels \u00e0 l\u2019API et pour offrir le deuxi\u00e8me essai; et des histoires pour afficher les explications et g\u00e9rer les transitions vers les autres flux de dialogue. Les transitions, encore une fois, variaient en fonction du r\u00e9sultat de l\u2019appel \u00e0 l\u2019API et de la valeur de la case \u201cself_assess_done\u201d.<\/p>\n Apr\u00e8s \u00eatre pass\u00e9s \u00e0 travers l\u2019impl\u00e9mentation de toutes les fonctionnalit\u00e9s en mode boutons-seulement-sans-gestion-d\u2019erreur, nous avons pu commencer \u00e0 explorer l\u2019int\u00e9gration du TALN et \u00e0 nous attaquer aux entr\u00e9es impr\u00e9vues. Nous avons commenc\u00e9 nos essais par la toute premi\u00e8re question au menu principal. Toute r\u00e9ponse n\u2019\u00e9tant pas reconnue comme l\u2019une des options serait envoy\u00e9e \u00e0 l\u2019API du Q&R; cependant, puisque le TALN n\u2019est pas contextuel dans Rasa, et \u00e9tant donn\u00e9 que nous nous attendions \u00e0 une grande vari\u00e9t\u00e9 de questions pour le Q&R, \u201ctoute r\u00e9ponse\u201d pouvait \u00eatre n\u2019importe quelle intention, avec n\u2019importe quel score. \u201cComment g\u00e9rer toutes ces intentions?\u201d n\u2019\u00e9tait pas une question aussi anodine qu\u2019elle puisse para\u00eetre.<\/p>\n La mani\u00e8re \u00e9vidente de proc\u00e9der \u00e9tait d\u2019ajouter des histoires<\/em> avec des intentions non support\u00e9es et le comportement d\u2019erreur voulu (c\u2019est-\u00e0-dire envoyer le texte au formulaire de Q&R), mais de combien d\u2019exemples aurions-nous besoin? La politique<\/em> TED n\u2019allait vraisemblablement pas pouvoir apprendre que le comportement des exemples \u00e9tait le comportement par d\u00e9faut \u00e0 utiliser aussi pour toute intention exclue des exemples. De plus, utiliser des OR pour inclure toutes les intentions non support\u00e9es aurait multipli\u00e9 la dur\u00e9e de l\u2019entra\u00eenement des mod\u00e8les de fa\u00e7on exponentielle d\u00e8s que nous aurions appliqu\u00e9 cette approche aux autres cas d\u2019utilisation. Cette avenue \u00e9tait un cul-de-sac.<\/p>\n En excluant compl\u00e8tement les intentions non support\u00e9es de nos histoires<\/em>, la politique<\/em> TED pr\u00e9disait quand m\u00eame quelque chose, mais nous pouvions esp\u00e9rer que le score de confiance soit bas et utiliser un seuil pour d\u00e9clencher une action de repli (fallback action<\/a>). Cette action remplacerait l\u2019intention retourn\u00e9e par une intention \u201cfallback\u201d et nous pourrions g\u00e9rer celle-ci dans nos histoires<\/em>. Or, les comportements attendus n\u2019avaient pas de tr\u00e8s bons scores, certains n\u2019\u00e9tant pas beaucoup mieux que ce qu\u2019une intention \u201caffirm\u201d mal plac\u00e9e pouvait obtenir, puisqu\u2019elle \u00e9tait dans plusieurs histoires<\/em>. En cons\u00e9quence, nous n\u2019avons pas voulu d\u00e9pendre d\u2019un seuil de confiance pour d\u00e9clencher l\u2019action de repli.<\/p>\n Nous avons finalement r\u00e9cup\u00e9r\u00e9 l\u2019id\u00e9e de l\u2019intention \u201cfallback\u201d, mais \u00e0 l\u2019aide d\u2019une politique<\/em> d\u00e9terministe. La politique<\/em> pr\u00e9disait l\u2019action qui rempla\u00e7ait l\u2019intention reconnue par une intention \u201cfallback\u201d si la conversation respectait deux conditions: la derni\u00e8re action pertinente avant l\u2019entr\u00e9e de l\u2019utilisatrice \u00e9tait la question du menu principal, et l\u2019intention reconnue n\u2019\u00e9tait pas dans la liste des intentions support\u00e9es. Des histoires<\/em> et la politique<\/em> de m\u00e9mo\u00efsation ont \u00e9t\u00e9 utilis\u00e9es pour d\u00e9clencher le formulaire de Q&R et g\u00e9rer les transitions particuli\u00e8res par la suite (l\u2019\u00e9chec de l\u2019appel \u00e0 l\u2019API ainsi que le r\u00e9sultat hors distribution au menu principal \u00e9taient suivis d\u2019un message d\u2019erreur au lieu des messages habituels):<\/p>\n Utilisation du message d\u00e9clencheur dans le formulaire de Q&R Dans un deuxi\u00e8me temps, nous avons ajout\u00e9 le TALN dans les questions oui-non qui, selon le design, d\u00e9clenchaient simplement, en cas d\u2019erreur, une question reformul\u00e9e avec des boutons et sans champ texte. La majorit\u00e9 d\u2019entre elles \u00e9taient dans des formulaires<\/em>, certaines avec des exceptions \u00e0 la convention de message \u201cutter_ask_{nom_de_la_case}\u201d. Les exceptions s\u2019appliquaient \u00e9galement aux messages d\u2019erreurs, ce qui fait qu\u2019une approche g\u00e9n\u00e9rique ne couvrant m\u00eame pas tous les cas semblait trop complexe pour les b\u00e9n\u00e9fices envisag\u00e9s. Nous avons laiss\u00e9 cette id\u00e9e de c\u00f4t\u00e9. Il semblait plus simple et plus rapide de simplement tout g\u00e9rer dans des formulaires<\/em>, comme ceci:<\/p>\n Intermission: Laisser le fant\u00f4me de la r\u00e9troaction loin derri\u00e8re<\/p>\n En ajoutant du TALN, et par le fait m\u00eame de la flexibilit\u00e9, nous nous sommes rappel\u00e9 de l\u2019interaction de r\u00e9troaction obligatoire et laborieuse qui nous hantait toujours, et avons d\u00e9cid\u00e9 de la rendre plus flexible aussi. Nous n\u2019avions toujours pas de \u201cwidget\u201d pour la r\u00e9troaction ni le temps d\u2019en impl\u00e9menter un, donc nous avons conserv\u00e9 la question, mais adapt\u00e9 la r\u00e9action: si l\u2019utilisatrice r\u00e9pondait quoi que ce soit d\u2019autre que oui ou non, la r\u00e9ponse serait trait\u00e9e comme s\u2019il s\u2019agissait de la r\u00e9ponse \u00e0 la prochaine question, qui elle se trouvait \u00e0 offrir de poser une autre question et pouvait mener aux autres fonctionnalit\u00e9s. Il a fallu quelques contorsions afin de sortir du formulaire <\/em>de mani\u00e8re pr\u00e9ventive et de \u201creproduire\u201d l\u2019entr\u00e9e de l\u2019utilisatrice:<\/p>\n Puisque nous avions d\u00e9j\u00e0 la politique<\/em> pour remplacer des intentions par \u201cfallback\u201d, la gestion d\u2019erreurs en dehors des formulaires consistait essentiellement en l\u2019ajout d\u2019entr\u00e9es au dictionnaire des derni\u00e8res intentions support\u00e9es par des actions, ainsi que l\u2019ajout d\u2019histoires pour r\u00e9agir \u00e0 l\u2019intention \u201cfallback\u201d, soit en entrant dans le formulaire Q&R ou en affichant un message d\u2019erreur en fonction du design. \u00c0 l\u2019int\u00e9rieur des formulaires, nous avons appliqu\u00e9 la m\u00eame approche que pour les questions oui-non. Nous avons d\u00fb faire quelques changements collat\u00e9raux, comme l\u2019ajout d\u2019une entit\u00e9 pour la province ou l\u2019ajout d\u2019histoires (principalement sous forme de OR) pour g\u00e9rer les transitions l\u00e0 o\u00f9 \u201caffirm\u201d ou \u201cdeny\u201d \u00e9taient valides (maintenant que le raccourci via les boutons n\u2019\u00e9tait plus disponible). Nous avons aussi d\u00fb revenir en arri\u00e8re et modifier notre fa\u00e7on \u00e9l\u00e9gante de g\u00e9rer la digression des ant\u00e9c\u00e9dents m\u00e9dicaux puisque la solution simple utilisant la politique de correspondance (mapping policy<\/a>) ne pouvait pas s\u2019appliquer \u00e0 la gestion d\u2019erreurs. Nous avons donc d\u00e9cid\u00e9 de g\u00e9rer cette digression dans un formulaire<\/em> comme les autres.<\/p>\n Fin<\/strong><\/p>\n Avec le recul, bien que nous ayons ajout\u00e9 le TALN, nous avons l\u2019impression d\u2019avoir pris plusieurs raccourcis et approches plus-ou-moins-rasa-esques. Notre cas d\u2019utilisation, qui \u00e9tait enti\u00e8rement pr\u00e9visible, sans navigation al\u00e9atoire mais rempli d\u2019exceptions et de petites variations, ne correspondait pas \u00e0 un cas d\u2019utilisation typique pour Rasa. Nous avons frapp\u00e9 plusieurs obstacles qui surgissent naturellement lorsqu\u2019on essaie d\u2019impl\u00e9menter un design de type diagramme de processus avec Rasa. N\u00e9anmoins, Rasa offre beaucoup de flexibilit\u00e9 par l\u2019interm\u00e9diaire de code et d\u2019ajouts possibles, et au final, nous avons souvent choisi d\u2019utiliser du code pour repr\u00e9senter des patrons de dialogue car lorsque le temps est compt\u00e9, le chemin qui nous est familier est le fa\u00e7on la plus s\u00fbre de se rendre \u00e0 bon port.<\/p>\n Dans un futur \u00e9pisode, nous irons plus loin dans l\u2019exploration des diff\u00e9rentes fa\u00e7ons d\u2019impl\u00e9menter deux des principales fonctionnalit\u00e9s des designs de type diagramme de processus, soit les arbres de d\u00e9cision et les dialogues modulaires. Ces derniers sont difficiles \u00e0 impl\u00e9menter avec Rasa et nous allons explorer les diff\u00e9rentes m\u00e9thodes pour ce faire. Nous allons \u00e9galement \u00e9valuer si et comment Rasa 2.0, toujours au stade alpha au moment d\u2019\u00e9crire ces lignes, pourra nous faciliter la t\u00e2che.<\/p>\n \u00b9Je rappelle que nous avons librement choisi de traduire les concepts les plus importants comme suit: <\/span>story <\/span><\/i>=> histoire, <\/span>form<\/span><\/i>=> formulaire, <\/span>policy<\/span><\/i>=> politique, <\/span>slot <\/span><\/i>=> case, <\/span>featurized <\/span><\/i>=> caract\u00e9ris\u00e9e. Ces choix n\u2019engagent que nous.<\/span><\/p>\n \u00b2Le f\u00e9minin est employ\u00e9 simplement pour all\u00e9ger le texte<\/span><\/p>\n \u00b3Oui, <\/span>flag <\/span><\/i>dans ce contexte c’est bien un <\/span>drapeau<\/span><\/i>, voir <\/span>Le grand dictionnaire terminologique<\/span><\/a> de l\u2019OQLF<\/span>[\/et_pb_text][\/et_pb_column] [et_pb_section admin_label=\u00a0\u00bbsection\u00a0\u00bb] [et_pb_row admin_label=\u00a0\u00bbrow\u00a0\u00bb] [et_pb_column type=\u00a0\u00bb4_4″][et_pb_text admin_label=\u00a0\u00bbText\u00a0\u00bb] Retour sur l\u2019\u00e9pisode 1: TALN et gestion d\u2019erreurs Flashback – Sc\u00e8ne 4: R\u00e9pondre \u00e0 des questions et suivre TED Comme je l\u2019ai mentionn\u00e9 dans la premi\u00e8re partie, l\u2019objectif du module de question-r\u00e9ponse (Q&R) \u00e9tait de permettre \u00e0 l\u2019utilisatrice\u00b2 de poser une question au sujet de la Covid-19, pour […]<\/p>\n","protected":false},"author":19,"featured_media":6974,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"off","_et_pb_old_content":" Fin<\/strong><\/p>\r\nAvec le recul, bien que nous ayons ajout\u00e9 le TALN, nous avons l\u2019impression d\u2019avoir pris plusieurs raccourcis et approches plus-ou-moins-rasa-esques. Notre cas d\u2019utilisation, qui \u00e9tait enti\u00e8rement pr\u00e9visible, sans navigation al\u00e9atoire mais rempli d\u2019exceptions et de petites variations, ne correspondait pas \u00e0 un cas d\u2019utilisation typique pour Rasa. Nous avons frapp\u00e9 plusieurs obstacles qui surgissent naturellement lorsqu\u2019on essaie d\u2019impl\u00e9menter un design de type diagramme de processus avec Rasa. N\u00e9anmoins, Rasa offre beaucoup de flexibilit\u00e9 par l\u2019interm\u00e9diaire de code et d\u2019ajouts possibles, et au final, nous avons souvent choisi d\u2019utiliser du code pour repr\u00e9senter des patrons de dialogue car lorsque le temps est compt\u00e9, le chemin qui nous est familier est le fa\u00e7on la plus s\u00fbre de se rendre \u00e0 bon port.\r\n\r\nDans un futur \u00e9pisode, nous irons plus loin dans l\u2019exploration des diff\u00e9rentes fa\u00e7ons d\u2019impl\u00e9menter deux des principales fonctionnalit\u00e9s des designs de type diagramme de processus, soit les arbres de d\u00e9cision et les dialogues modulaires. Ces derniers sont difficiles \u00e0 impl\u00e9menter avec Rasa et nous allons explorer les diff\u00e9rentes m\u00e9thodes pour ce faire. Nous allons \u00e9galement \u00e9valuer si et comment Rasa 2.0, toujours au stade alpha au moment d\u2019\u00e9crire ces lignes, pourra nous faciliter la t\u00e2che.\r\n\r\n \u00b9Je rappelle que nous avons librement choisi de traduire les concepts les plus importants comme suit: <\/span>story <\/span><\/i>=> histoire, <\/span>form<\/span><\/i>=> formulaire, <\/span>policy<\/span><\/i>=> politique, <\/span>slot <\/span><\/i>=> case, <\/span>featurized <\/span><\/i>=> caract\u00e9ris\u00e9e. Ces choix n\u2019engagent que nous.<\/span>\r\n\r\n \u00b2Le f\u00e9minin est employ\u00e9 simplement pour all\u00e9ger le texte<\/span>\r\n\r\n \u00b3Oui, <\/span>flag <\/span><\/i>dans ce contexte c'est bien un <\/span>drapeau<\/span><\/i>, voir <\/span>Le grand dictionnaire terminologique<\/span><\/a> de l\u2019OQLF<\/span>","_et_gb_content_width":"","om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[5],"tags":[],"class_list":["post-7046","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blogue"],"aioseo_notices":[],"yoast_head":"\n![\"\"](\"https:\/\/www.nuecho.com\/wp-content\/uploads\/2020\/09\/1-1.bmp\")
<\/p>\nSc\u00e8ne 5.25: D\u00e9tours de l\u2019inscription au suivi quotidien<\/h3>\n
\n
![\"\"](\"https:\/\/www.nuecho.com\/wp-content\/uploads\/2020\/09\/digression-fr.gif\")
<\/p>\nFlashback – 5.75: Pause – TED a besoin d\u2019un cours d\u2019appoint<\/h3>\n
Sc\u00e8ne 6: L\u2019impl\u00e9mentation de la recherche de cliniques de d\u00e9pistage sur le pilote automatique<\/h3>\n
\n
Sc\u00e8ne 7: Explorer les chemins sinueux du TALN<\/h3>\n
Option 1: Ajouter des exemples aux histoires<\/h4>\n
Option 2: Action de repli<\/h4>\n
La solution: La politique d\u2019intention non support\u00e9e<\/h4>\n
\n<\/em><\/p>\n![\"\"](\"https:\/\/www.nuecho.com\/wp-content\/uploads\/2020\/09\/3-1.bmp\")
<\/p>\nSc\u00e8ne 8: Explorations suppl\u00e9mentaires<\/h3>\n
![\"\"](\"https:\/\/www.nuecho.com\/wp-content\/uploads\/2020\/09\/4.bmp\")
<\/p>\n![\"\"](\"https:\/\/www.nuecho.com\/wp-content\/uploads\/2020\/09\/5.bmp\")
<\/p>\nSc\u00e8ne 9: Sprint final pour l\u2019ajout du TALN<\/h3>\n
\n[\/et_pb_row]
\n[\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":"Retour sur l\u2019\u00e9pisode 1: TALN et gestion d\u2019erreurs<\/h2>\r\n
\r\nFlashback - Sc\u00e8ne 4: R\u00e9pondre \u00e0 des questions et suivre TED<\/h3>\r\nComme je l\u2019ai mentionn\u00e9 dans la premi\u00e8re partie, l\u2019objectif du module de question-r\u00e9ponse (Q&R) \u00e9tait de permettre \u00e0 l\u2019utilisatrice\u00b2 de poser une question au sujet de la Covid-19, pour laquelle nous afficherions la r\u00e9ponse retourn\u00e9e par l\u2019API du mod\u00e8le du Mila. Il y a eu plusieurs versions de cette portion de l\u2019application, allant de tr\u00e8s basique \u00e0 plut\u00f4t complexe, et celle-ci a \u00e9t\u00e9 incorpor\u00e9e \u00e0 un nombre de plus en plus grand d\u2019endroits dans le dialogue.\r\n\r\nDans la version initiale du flux de Q&R, l\u2019utilisatrice devait choisir l\u2019option \u201cJ\u2019ai des questions\u201d du menu principal ou apr\u00e8s une \u00e9valuation, apr\u00e8s quoi l\u2019application recueillait sa question. Nous avons pr\u00e9vu quatre r\u00e9sultats possibles provenant de l\u2019appel \u00e0 l\u2019API (le quatri\u00e8me n\u2019\u00e9tait toujours pas disponible au moment o\u00f9 notre participation au projet a pris fin):\r\n
\r\n \t
\r\n\r\nAinsi, nous n\u2019avions pas besoin d\u2019ajouter des histoires du module de question-r\u00e9ponse suivi d\u2019une \u00e9valuation, mais avec le recul, nous aurions d\u00fb le faire d\u2019entr\u00e9e de jeu, puisque l\u2019ajout d\u2019histoires d\u2019\u00e9valuations suivies de Q&R fonctionnait (somme toute) bien, et nous avons d\u00fb le faire de toute fa\u00e7on lors de l\u2019ajout du TALN.\r\nSc\u00e8ne 5.25: D\u00e9tours de l\u2019inscription au suivi quotidien<\/h3>\r\nLe design du flux d\u2019inscription au suivi quotidien a \u00e9t\u00e9 approfondi pour y inclure certains cas d\u2019exceptions. Cela \u00e9tait n\u00e9cessaire puisque le num\u00e9ro de t\u00e9l\u00e9phone et le code de validation \u00e9taient recueillis aupr\u00e8s de l\u2019utilisatrice directement sous forme de texte. Voici les cas plus probl\u00e9matiques que nous avons trait\u00e9s:\r\n
\r\n \t
\r\n\r\nMais puisque la plupart impliquaient le recours \u00e0 des compteurs et messages d\u2019erreurs de m\u00eame qu\u2019\u00e0 d\u2019autres \u00e9l\u00e9ments plus complexes, nous avons d\u00e9cid\u00e9 de g\u00e9rer tous ces cas \u00e0 l\u2019int\u00e9rieur de formulaires<\/em> plut\u00f4t que de distribuer la logique entre formulaires<\/em>, histoires<\/em> et correspondances (mappings<\/em>) d\u2019intentions. Cela a pr\u00e9sent\u00e9 des inconv\u00e9nients (au-del\u00e0 des centaines de lignes de code suppl\u00e9mentaires): une partie de la logique s\u2019\u00e9chelonnait sur plusieurs interactions et nous avons d\u00fb ajouter plusieurs cases pour disposer de compteurs et de drapeaux\u00b3 pour en suivre la progression (notre version finale du formulaire<\/em> utilise une dizaine de telles cases).\r\nFlashback - 5.75: Pause - TED a besoin d\u2019un cours d\u2019appoint<\/h3>\r\nApr\u00e8s quelques essais, il a \u00e9t\u00e9 port\u00e9 \u00e0 notre attention qu\u2019il \u00e9tait possible pour une utilisatrice de se retrouver coinc\u00e9e dans une boucle infinie dans le Q&R puisque la seule option offerte \u00e9tait de reformuler la question. Le design a \u00e9t\u00e9 modifi\u00e9 afin de permettre \u00e0 l\u2019utilisatrice de soit r\u00e9essayer, soit sortir du Q&R, et nous avons ajout\u00e9 2 transitions pour ce cas.\r\n\r\nEn ajoutant ces transitions, nous avons frapp\u00e9 un petit noeud: la politique TED<\/a> n\u2019apprenait pas le bon comportement apr\u00e8s le Q&R; elle confondait les impacts des cases \u201cquestion_answering_status\u201d et \u201csymptoms\u201d. La redistribution \u00e9quilibr\u00e9e dans nos histoires<\/em> des exemples de Q&R entre les \u00e9valuations sans sympt\u00f4mes, avec sympt\u00f4mes l\u00e9gers ou mod\u00e9r\u00e9s, a repr\u00e9sent\u00e9 un travail de moine, mais cela a fonctionn\u00e9. Au final, la politique<\/em> pr\u00e9disait le bon comportement pour les conversations qui n\u2019\u00e9taient pas repr\u00e9sent\u00e9es dans nos histoires.\r\n
Sc\u00e8ne 6: L\u2019impl\u00e9mentation de la recherche de cliniques de d\u00e9pistage sur le pilote automatique<\/h3>\r\nLa recherche de cliniques de d\u00e9pistage, apr\u00e8s avoir eu maille \u00e0 partir avec les transitions du Q&R et la gestion d\u2019erreurs de l\u2019inscription au suivi quotidien, n\u2019a pr\u00e9sent\u00e9 aucun nouveau d\u00e9fi. Le dialogue comprenait trois \u00e9tapes principales:\r\n
\r\n \t
Sc\u00e8ne 7: Explorer les chemins sinueux du TALN<\/h3>\r\nApr\u00e8s \u00eatre pass\u00e9s \u00e0 travers l\u2019impl\u00e9mentation de toutes les fonctionnalit\u00e9s en mode boutons-seulement-sans-gestion-d\u2019erreur, nous avons pu commencer \u00e0 explorer l\u2019int\u00e9gration du TALN et \u00e0 nous attaquer aux entr\u00e9es impr\u00e9vues. Nous avons commenc\u00e9 nos essais par la toute premi\u00e8re question au menu principal. Toute r\u00e9ponse n\u2019\u00e9tant pas reconnue comme l\u2019une des options serait envoy\u00e9e \u00e0 l\u2019API du Q&R; cependant, puisque le TALN n\u2019est pas contextuel dans Rasa, et \u00e9tant donn\u00e9 que nous nous attendions \u00e0 une grande vari\u00e9t\u00e9 de questions pour le Q&R, \u201ctoute r\u00e9ponse\u201d pouvait \u00eatre n\u2019importe quelle intention, avec n\u2019importe quel score. \u201cComment g\u00e9rer toutes ces intentions?\u201d n\u2019\u00e9tait pas une question aussi anodine qu\u2019elle puisse para\u00eetre.\r\n
Option 1: Ajouter des exemples aux histoires<\/h4>\r\nLa mani\u00e8re \u00e9vidente de proc\u00e9der \u00e9tait d\u2019ajouter des histoires<\/em> avec des intentions non support\u00e9es et le comportement d\u2019erreur voulu (c\u2019est-\u00e0-dire envoyer le texte au formulaire de Q&R), mais de combien d\u2019exemples aurions-nous besoin? La politique<\/em> TED n\u2019allait vraisemblablement pas pouvoir apprendre que le comportement des exemples \u00e9tait le comportement par d\u00e9faut \u00e0 utiliser aussi pour toute intention exclue des exemples. De plus, utiliser des OR pour inclure toutes les intentions non support\u00e9es aurait multipli\u00e9 la dur\u00e9e de l\u2019entra\u00eenement des mod\u00e8les de fa\u00e7on exponentielle d\u00e8s que nous aurions appliqu\u00e9 cette approche aux autres cas d\u2019utilisation. Cette avenue \u00e9tait un cul-de-sac.\r\n
Option 2: Action de repli<\/h4>\r\nEn excluant compl\u00e8tement les intentions non support\u00e9es de nos histoires<\/em>, la politique<\/em> TED pr\u00e9disait quand m\u00eame quelque chose, mais nous pouvions esp\u00e9rer que le score de confiance soit bas et utiliser un seuil pour d\u00e9clencher une action de repli (fallback action<\/a>). Cette action remplacerait l\u2019intention retourn\u00e9e par une intention \u201cfallback\u201d et nous pourrions g\u00e9rer celle-ci dans nos histoires<\/em>. Or, les comportements attendus n\u2019avaient pas de tr\u00e8s bons scores, certains n\u2019\u00e9tant pas beaucoup mieux que ce qu\u2019une intention \u201caffirm\u201d mal plac\u00e9e pouvait obtenir, puisqu\u2019elle \u00e9tait dans plusieurs histoires<\/em>. En cons\u00e9quence, nous n\u2019avons pas voulu d\u00e9pendre d\u2019un seuil de confiance pour d\u00e9clencher l\u2019action de repli.\r\n
La solution: La politique d\u2019intention non support\u00e9e<\/h4>\r\nNous avons finalement r\u00e9cup\u00e9r\u00e9 l\u2019id\u00e9e de l\u2019intention \u201cfallback\u201d, mais \u00e0 l\u2019aide d\u2019une politique<\/em> d\u00e9terministe. La politique<\/em> pr\u00e9disait l\u2019action qui rempla\u00e7ait l\u2019intention reconnue par une intention \u201cfallback\u201d si la conversation respectait deux conditions: la derni\u00e8re action pertinente avant l\u2019entr\u00e9e de l\u2019utilisatrice \u00e9tait la question du menu principal, et l\u2019intention reconnue n\u2019\u00e9tait pas dans la liste des intentions support\u00e9es. Des histoires<\/em> et la politique<\/em> de m\u00e9mo\u00efsation ont \u00e9t\u00e9 utilis\u00e9es pour d\u00e9clencher le formulaire de Q&R et g\u00e9rer les transitions particuli\u00e8res par la suite (l\u2019\u00e9chec de l\u2019appel \u00e0 l\u2019API ainsi que le r\u00e9sultat hors distribution au menu principal \u00e9taient suivis d\u2019un message d\u2019erreur au lieu des messages habituels):\r\n\r\nUtilisation du message d\u00e9clencheur dans le formulaire de Q&R\r\n<\/em>\r\n\r\n
\r\nSc\u00e8ne 8: Explorations suppl\u00e9mentaires<\/h3>\r\nDans un deuxi\u00e8me temps, nous avons ajout\u00e9 le TALN dans les questions oui-non qui, selon le design, d\u00e9clenchaient simplement, en cas d\u2019erreur, une question reformul\u00e9e avec des boutons et sans champ texte. La majorit\u00e9 d\u2019entre elles \u00e9taient dans des formulaires<\/em>, certaines avec des exceptions \u00e0 la convention de message \u201cutter_ask_{nom_de_la_case}\u201d. Les exceptions s\u2019appliquaient \u00e9galement aux messages d\u2019erreurs, ce qui fait qu\u2019une approche g\u00e9n\u00e9rique ne couvrant m\u00eame pas tous les cas semblait trop complexe pour les b\u00e9n\u00e9fices envisag\u00e9s. Nous avons laiss\u00e9 cette id\u00e9e de c\u00f4t\u00e9. Il semblait plus simple et plus rapide de simplement tout g\u00e9rer dans des formulaires<\/em>, comme ceci:\r\n\r\n
\r\n\r\nIntermission: Laisser le fant\u00f4me de la r\u00e9troaction loin derri\u00e8re\r\n\r\nEn ajoutant du TALN, et par le fait m\u00eame de la flexibilit\u00e9, nous nous sommes rappel\u00e9 de l\u2019interaction de r\u00e9troaction obligatoire et laborieuse qui nous hantait toujours, et avons d\u00e9cid\u00e9 de la rendre plus flexible aussi. Nous n\u2019avions toujours pas de \u201cwidget\u201d pour la r\u00e9troaction ni le temps d\u2019en impl\u00e9menter un, donc nous avons conserv\u00e9 la question, mais adapt\u00e9 la r\u00e9action: si l\u2019utilisatrice r\u00e9pondait quoi que ce soit d\u2019autre que oui ou non, la r\u00e9ponse serait trait\u00e9e comme s\u2019il s\u2019agissait de la r\u00e9ponse \u00e0 la prochaine question, qui elle se trouvait \u00e0 offrir de poser une autre question et pouvait mener aux autres fonctionnalit\u00e9s. Il a fallu quelques contorsions afin de sortir du formulaire <\/em>de mani\u00e8re pr\u00e9ventive et de \u201creproduire\u201d l\u2019entr\u00e9e de l\u2019utilisatrice:\r\n\r\n\r\nSc\u00e8ne 9: Sprint final pour l\u2019ajout du TALN<\/h3>\r\nPuisque nous avions d\u00e9j\u00e0 la politique<\/em> pour remplacer des intentions par \u201cfallback\u201d, la gestion d\u2019erreurs en dehors des formulaires consistait essentiellement en l\u2019ajout d\u2019entr\u00e9es au dictionnaire des derni\u00e8res intentions support\u00e9es par des actions, ainsi que l\u2019ajout d\u2019histoires pour r\u00e9agir \u00e0 l\u2019intention \u201cfallback\u201d, soit en entrant dans le formulaire Q&R ou en affichant un message d\u2019erreur en fonction du design. \u00c0 l\u2019int\u00e9rieur des formulaires, nous avons appliqu\u00e9 la m\u00eame approche que pour les questions oui-non. Nous avons d\u00fb faire quelques changements collat\u00e9raux, comme l\u2019ajout d\u2019une entit\u00e9 pour la province ou l\u2019ajout d\u2019histoires (principalement sous forme de OR) pour g\u00e9rer les transitions l\u00e0 o\u00f9 \u201caffirm\u201d ou \u201cdeny\u201d \u00e9taient valides (maintenant que le raccourci via les boutons n\u2019\u00e9tait plus disponible). Nous avons aussi d\u00fb revenir en arri\u00e8re et modifier notre fa\u00e7on \u00e9l\u00e9gante de g\u00e9rer la digression des ant\u00e9c\u00e9dents m\u00e9dicaux puisque la solution simple utilisant la politique de correspondance (mapping policy<\/a>) ne pouvait pas s\u2019appliquer \u00e0 la gestion d\u2019erreurs. Nous avons donc d\u00e9cid\u00e9 de g\u00e9rer cette digression dans un formulaire<\/em> comme les autres.\r\n