Retour sur l’épisode 1: TALN et gestion d’erreurs

Flashback – Scène 4: Répondre à des questions et suivre TED

Comme je l’ai mentionné dans la première partie, l’objectif du module de question-réponse (Q&R) était de permettre à l’utilisatrice² de poser une question au sujet de la Covid-19, pour laquelle nous afficherions la réponse retournée par l’API du modèle du Mila. Il y a eu plusieurs versions de cette portion de l’application, allant de très basique à plutôt complexe, et celle-ci a été incorporée à un nombre de plus en plus grand d’endroits dans le dialogue.

Dans la version initiale du flux de Q&R, l’utilisatrice devait choisir l’option “J’ai des questions” du menu principal ou après une évaluation, après quoi l’application recueillait sa question. Nous avons prévu quatre résultats possibles provenant de l’appel à l’API (le quatrième n’était toujours pas disponible au moment où notre participation au projet a pris fin):

• Échec: l’appel à l’API a échoué
• Succès: l’appel à l’API a réussi et le modèle a fourni une réponse
• Hors distribution: l’appel à l’API a réussi mais n’a fourni aucune réponse
• Requiert une évaluation: l’appel à l’API a réussi mais l’utilisatrice devrait évaluer ses symptômes pour obtenir une réponse à sa question

Si le résultat était un succès, Chloé posait une question supplémentaire afin de savoir si la réponse avait été utile (l’interface de clavardage que nous devions utiliser ne fournissait pas de boutons de type “j’aime/je n’aime pas” (thumbs-up/thumbs-down) qui nous auraient permis de facilement sauter cette interaction). Si le résultat était hors distribution, alors on demandait à l’utilisatrice de reformuler sa question.

Recueillir la question, la reformulation de celle-ci et la rétroaction sur l’utilité de la réponse pouvaient tous être inclus dans un formulaire; cependant, l’implémentation des transitions vers les autres portions du dialogue était moins claire. Il y avait 6 transitions différentes à partir du flux de Q&R selon le résultat et la présence de la case “self_assess_done” décrite précédemment. Nous avons vaguement considéré la possibilité de demander à l’usager ce qu’il voulait faire ensuite à l’intérieur du formulaire, afin de centraliser la logique du flux de Q&R, mais cette idée a été mise de côté puisque nous n’avons pas trouvé de façon élégante d’implémenter cela. Pour cette raison, nous avons finalement eu recours aux histoires et à la politique TED pour prédire les transitions déterministes.

Nous étions aussi confrontés au problème découlant du fait que certaines de ces transitions étaient des questions de type “affirm/deny” (autrement dit une intention booléenne), “affirm” menant soit vers une évaluation ou vers une autre question. À ce point, nos histoires d’évaluation de base démarraient directement avec une intention “get_assessment” comme raccourci pour la mémoïsation, et démarrer une histoire avec “get_assessment OR affirm” aurait évidemment généré des correspondances indésirables. Nous avons remis cet enjeu à plus tard avec une solution qui fonctionnait seulement parce que nous contrôlions les réponses des utilisateurs par le biais de boutons. Comme ceci:

Un raccourci d’intentions avec des boutons

Ainsi, nous n’avions pas besoin d’ajouter des histoires du module de question-réponse suivi d’une évaluation, mais avec le recul, nous aurions dû le faire d’entrée de jeu, puisque l’ajout d’histoires d’évaluations suivies de Q&R fonctionnait (somme toute) bien, et nous avons dû le faire de toute façon lors de l’ajout du TALN.

Scène 5.25: Détours de l’inscription au suivi quotidien

Le design du flux d’inscription au suivi quotidien a été approfondi pour y inclure certains cas d’exceptions. Cela était nécessaire puisque le numéro de téléphone et le code de validation étaient recueillis auprès de l’utilisatrice directement sous forme de texte. Voici les cas plus problématiques que nous avons traités:

• Le numéro de téléphone n’est pas valide
• L’utilisatrice dit qu’elle n’a pas de numéro de téléphone
• Elle veut annuler l’inscription parce qu’elle ne veut pas fournir son numéro
• Le code de validation est invalide
• L’utilisatrice n’a pas reçu de code de validation et veut en recevoir un nouveau
• Elle n’a pas reçu de code de validation et désire changer de numéro de téléphone

Certains de ces cas se trouvent à mi-chemin entre une digression et de la gestion d’erreur, et nous avons pensé les implémenter comme des digressions “contrôlées”, de la même façon que nous l’avions fait pour l’explication des antécédents médicaux, qui va comme suit:

Mais puisque la plupart impliquaient le recours à des compteurs et messages d’erreurs de même qu’à d’autres éléments plus complexes, nous avons décidé de gérer tous ces cas à l’intérieur de formulaires plutôt que de distribuer la logique entre formulaires, histoires et correspondances (mappings) d’intentions. Cela a présenté des inconvénients (au-delà des centaines de lignes de code supplémentaires): une partie de la logique s’échelonnait sur plusieurs interactions et nous avons dû ajouter plusieurs cases pour disposer de compteurs et de drapeaux³ pour en suivre la progression (notre version finale du formulaire utilise une dizaine de telles cases).

Flashback – 5.75: Pause – TED a besoin d’un cours d’appoint

Après quelques essais, il a été porté à notre attention qu’il était possible pour une utilisatrice de se retrouver coincée dans une boucle infinie dans le Q&R puisque la seule option offerte était de reformuler la question. Le design a été modifié afin de permettre à l’utilisatrice de soit réessayer, soit sortir du Q&R, et nous avons ajouté 2 transitions pour ce cas.

En ajoutant ces transitions, nous avons frappé un petit noeud: la politique TED n’apprenait pas le bon comportement après le Q&R; elle confondait les impacts des cases “question_answering_status” et “symptoms”. La redistribution équilibrée dans nos histoires des exemples de Q&R entre les évaluations sans symptômes, avec symptômes légers ou modérés, a représenté un travail de moine, mais cela a fonctionné. Au final, la politique prédisait le bon comportement pour les conversations qui n’étaient pas représentées dans nos histoires.

Scène 6: L’implémentation de la recherche de cliniques de dépistage sur le pilote automatique

La recherche de cliniques de dépistage, après avoir eu maille à partir avec les transitions du Q&R et la gestion d’erreurs de l’inscription au suivi quotidien, n’a présenté aucun nouveau défi. Le dialogue comprenait trois étapes principales:

1. Expliquer le fonctionnement et demander à l’utilisatrice si elle veut poursuivre
2. Si oui, collecter son code postal et en valider le format et l’existence, en annulant la tâche après trop d’erreurs
3. Afficher les résultats ou offrir un autre essai s’il n’y en avait aucun.

Suivant la logique de nos implémentations précédentes, nous avons utilisé un formulaire pour le code postal et la gestion d’erreurs, les appels à l’API et pour offrir le deuxième essai; et des histoires pour afficher les explications et gérer les transitions vers les autres flux de dialogue. Les transitions, encore une fois, variaient en fonction du résultat de l’appel à l’API et de la valeur de la case “self_assess_done”.

Scène 7: Explorer les chemins sinueux du TALN

Après être passés à travers l’implémentation de toutes les fonctionnalités en mode boutons-seulement-sans-gestion-d’erreur, nous avons pu commencer à explorer l’intégration du TALN et à nous attaquer aux entrées imprévues. Nous avons commencé nos essais par la toute première question au menu principal. Toute réponse n’étant pas reconnue comme l’une des options serait envoyée à l’API du Q&R; cependant, puisque le TALN n’est pas contextuel dans Rasa, et étant donné que nous nous attendions à une grande variété de questions pour le Q&R, “toute réponse” pouvait être n’importe quelle intention, avec n’importe quel score. “Comment gérer toutes ces intentions?” n’était pas une question aussi anodine qu’elle puisse paraître.

Option 1: Ajouter des exemples aux histoires

La manière évidente de procéder était d’ajouter des histoires avec des intentions non supportées et le comportement d’erreur voulu (c’est-à-dire envoyer le texte au formulaire de Q&R), mais de combien d’exemples aurions-nous besoin? La politique TED n’allait vraisemblablement pas pouvoir apprendre que le comportement des exemples était le comportement par défaut à utiliser aussi pour toute intention exclue des exemples. De plus, utiliser des OR pour inclure toutes les intentions non supportées aurait multiplié la durée de l’entraînement des modèles de façon exponentielle dès que nous aurions appliqué cette approche aux autres cas d’utilisation. Cette avenue était un cul-de-sac.

Option 2: Action de repli

En excluant complètement les intentions non supportées de nos histoires, la politique TED prédisait quand même quelque chose, mais nous pouvions espérer que le score de confiance soit bas et utiliser un seuil pour déclencher une action de repli (fallback action). Cette action remplacerait l’intention retournée par une intention “fallback” et nous pourrions gérer celle-ci dans nos histoires. Or, les comportements attendus n’avaient pas de très bons scores, certains n’étant pas beaucoup mieux que ce qu’une intention “affirm” mal placée pouvait obtenir, puisqu’elle était dans plusieurs histoires. En conséquence, nous n’avons pas voulu dépendre d’un seuil de confiance pour déclencher l’action de repli.

La solution: La politique d’intention non supportée

Nous avons finalement récupéré l’idée de l’intention “fallback”, mais à l’aide d’une politique déterministe. La politique prédisait l’action qui remplaçait l’intention reconnue par une intention “fallback” si la conversation respectait deux conditions: la dernière action pertinente avant l’entrée de l’utilisatrice était la question du menu principal, et l’intention reconnue n’était pas dans la liste des intentions supportées. Des histoires et la politique de mémoïsation ont été utilisées pour déclencher le formulaire de Q&R et gérer les transitions particulières par la suite (l’échec de l’appel à l’API ainsi que le résultat hors distribution au menu principal étaient suivis d’un message d’erreur au lieu des messages habituels):

Utilisation du message déclencheur dans le formulaire de Q&R

Scène 8: Explorations supplémentaires

Dans un deuxième temps, nous avons ajouté le TALN dans les questions oui-non qui, selon le design, déclenchaient simplement, en cas d’erreur, une question reformulée avec des boutons et sans champ texte. La majorité d’entre elles étaient dans des formulaires, certaines avec des exceptions à la convention de message “utter_ask_{nom_de_la_case}”. Les exceptions s’appliquaient également aux messages d’erreurs, ce qui fait qu’une approche générique ne couvrant même pas tous les cas semblait trop complexe pour les bénéfices envisagés. Nous avons laissé cette idée de côté. Il semblait plus simple et plus rapide de simplement tout gérer dans des formulaires, comme ceci:

Intermission: Laisser le fantôme de la rétroaction loin derrière

En ajoutant du TALN, et par le fait même de la flexibilité, nous nous sommes rappelé de l’interaction de rétroaction obligatoire et laborieuse qui nous hantait toujours, et avons décidé de la rendre plus flexible aussi. Nous n’avions toujours pas de “widget” pour la rétroaction ni le temps d’en implémenter un, donc nous avons conservé la question, mais adapté la réaction: si l’utilisatrice répondait quoi que ce soit d’autre que oui ou non, la réponse serait traitée comme s’il s’agissait de la réponse à la prochaine question, qui elle se trouvait à offrir de poser une autre question et pouvait mener aux autres fonctionnalités. Il a fallu quelques contorsions afin de sortir du formulaire de manière préventive et de “reproduire” l’entrée de l’utilisatrice:

Scène 9: Sprint final pour l’ajout du TALN

Puisque nous avions déjà la politique pour remplacer des intentions par “fallback”, la gestion d’erreurs en dehors des formulaires consistait essentiellement en l’ajout d’entrées au dictionnaire des dernières intentions supportées par des actions, ainsi que l’ajout d’histoires pour réagir à l’intention “fallback”, soit en entrant dans le formulaire Q&R ou en affichant un message d’erreur en fonction du design. À l’intérieur des formulaires, nous avons appliqué la même approche que pour les questions oui-non. Nous avons dû faire quelques changements collatéraux, comme l’ajout d’une entité pour la province ou l’ajout d’histoires (principalement sous forme de OR) pour gérer les transitions là où “affirm” ou “deny” étaient valides (maintenant que le raccourci via les boutons n’était plus disponible). Nous avons aussi dû revenir en arrière et modifier notre façon élégante de gérer la digression des antécédents médicaux puisque la solution simple utilisant la politique de correspondance (mapping policy) ne pouvait pas s’appliquer à la gestion d’erreurs. Nous avons donc décidé de gérer cette digression dans un formulaire comme les autres.

Fin

Avec le recul, bien que nous ayons ajouté le TALN, nous avons l’impression d’avoir pris plusieurs raccourcis et approches plus-ou-moins-rasa-esques. Notre cas d’utilisation, qui était entièrement prévisible, sans navigation aléatoire mais rempli d’exceptions et de petites variations, ne correspondait pas à un cas d’utilisation typique pour Rasa. Nous avons frappé plusieurs obstacles qui surgissent naturellement lorsqu’on essaie d’implémenter un design de type diagramme de processus avec Rasa. Néanmoins, Rasa offre beaucoup de flexibilité par l’intermédiaire de code et d’ajouts possibles, et au final, nous avons souvent choisi d’utiliser du code pour représenter des patrons de dialogue car lorsque le temps est compté, le chemin qui nous est familier est le façon la plus sûre de se rendre à bon port.

Dans un futur épisode, nous irons plus loin dans l’exploration des différentes façons d’implémenter deux des principales fonctionnalités des designs de type diagramme de processus, soit les arbres de décision et les dialogues modulaires. Ces derniers sont difficiles à implémenter avec Rasa et nous allons explorer les différentes méthodes pour ce faire. Nous allons également évaluer si et comment Rasa 2.0, toujours au stade alpha au moment d’écrire ces lignes, pourra nous faciliter la tâche.

¹Je rappelle que nous avons librement choisi de traduire les concepts les plus importants comme suit: story => histoire, form=> formulaire, policy=> politique, slot => case, featurized => caractérisée. Ces choix n’engagent que nous.

²Le féminin est employé simplement pour alléger le texte

³Oui, flag dans ce contexte c’est bien un drapeau, voir Le grand dictionnaire terminologique de l’OQLF

​Contexte

Au moment où les mesures de confinement ont été mises en place au Canada, nous avons été approchés par Dialogue, une compagnie spécialisée en services de santé et télémédecine, pour les aider dans la migration de Chloé, leur agent conversationnel par règles pour la Covid-19, vers une solution plus conversationnelle en utilisant Rasa. Nous avions aussi comme mandat d’y ajouter des fonctionnalités. Il s’agissait d’un projet itératif s’étalant sur 10 semaines, en mode agile.

Voici les principales fonctionnalités de Chloé, à haut niveau:

• Auto-évaluation: fournir des recommandations personnalisées en fonction des symptômes et en suivant les consignes des gouvernements fédéral et provinciaux
• Questions-réponses (Q&R): permettre à l’utilisatrice¹ de poser des questions au sujet de la Covid-19 en utilisant un modèle développé par le Mila.
• Suivi quotidien: aider les utilisateurs à suivre leurs symptômes au jour le jour. Lorsque l’utilisatrice s’inscrit au suivi quotidien, elle reçoit un lien par texto une fois par jour qui lui permet de joindre Chloé afin d’évaluer la progression de ses symptômes.
• Recherche de cliniques de dépistage: à l’aide de son code postal, fournir à l’utilisatrice une liste de cliniques de dépistage près de chez elle grâce à l’API de Clinia.

La conception de Chloé a été effectuée de manière itérative à mesure que nous ajoutions des fonctionnalités et a été ajustée pour tenir compte des commentaires de l’équipe médicale de Dialogue et des testeurs, évoluant constamment. L’implémentation suivait, pas très loin derrière. Il y a plusieurs façons de développer certains patrons de dialogue avec Rasa et compte tenu des modifications constantes au design, nos choix d’implémentation nous donnaient souvent l’impression d’errer dans un labyrinthe. Nous avons fini par en trouver la sortie, non sans avoir rebroussé chemin à quelques reprises pour éviter de frapper un mur ou de grimper une falaise. Étant donné que nous n’avions pas, d’entrée de jeu, une idée précise du design final, certains choix d’implémentation sont plus ou moins cohérents, et étant donné l’échéancier très serré, nous n’avons pas pu effectuer toute la refactorisation voulue. Cependant, ce contexte nous a aussi permis d’explorer des chemins que nous n’aurions pas parcourus avec Rasa si nous avions eu le temps de répertorier des patrons et de créer des composants génériques pour les réaliser.

Dans cet article et dans le prochain de cette courte série, je vais vous raconter l’histoire du développement de Chloé. Pour chaque étape de notre parcours, je vais décrire les principaux obstacles auxquels nous avons fait face ainsi que les décisions d’implémentation que nous avons prises, souvent dans le feu de l’action. Dans cette première partie, nous allons principalement nous attarder aux fonctionnalités d’auto-évaluation et de suivi quotidien.

Épisode 1: Les dialogues d’auto-évaluation

Scène 1: Sprint vers la première démo de l’auto-évaluation

Très tôt dans le projet (c’est-à-dire au 8e jour), on nous a demandé si nous pouvions démontrer un dialogue d’auto-évaluation à la fin de la journée. Lorsque nous avons reçu la demande, la version initiale du design mijotait encore dans la tête de notre conceptrice; nous avions un projet Rasa fonctionnel, mais aucun dialogue n’avait été implémenté. Quoi qu’il en soit, nous avons retroussé nos manches et avons produit cette démo.

La démo initiale était un arbre de décision simple permettant d’évaluer la gravité des symptômes de l’utilisatrice et de proposer des recommandations adéquates. Nous avons pris le chemin le plus court: pour chaque flux possible, nous avons défini une histoire (story²) et avons utilisé la politique de mémoïsation.

Scène 2: Le chemin devient boueux à mesure que les flux d’auto-évaluation se multiplient

Le prochain ajout majeur aux flux de dialogue a été la distinction, à l’entrée de l’auto-évaluation, entre trois situations:

• L’utilisatrice pense être malade et veut évaluer ses symptômes (cas initial)
• Elle a reçu un résultat positif au test de dépistage et veut évaluer ses symptômes et obtenir des conseils
• Elle a effectué l’auto-évaluation précédemment et revient pour réévaluer ses symptômes

Cette distinction a créé un certain nombre de variations au flux de base, comme par exemple demander si les symptômes ont empiré dans le cas d’une réévaluation, ou encore démarrer le dialogue en recommandant à la personne de s’isoler si elle a reçu un résultat positif.

Nous avons suivi le même chemin, ajoutant des histoires pour l’implémentation de ces deux nouveaux flux de dialogue. Nous commencions toutefois à constater que le nombre d’histoires augmentait rapidement pour ces trois situations seulement (dont la complexité allait continuer à augmenter), et que certaines portions semblables se répétaient entre les histoires.

Deux histoires semblables pour une personne ayant des symptômes légers³

 

Ne voyant pas de solution simple à ceci dans les histoires – les checkpoints et les instructions de type OR ne nous aidaient pas car les sections similaires étaient prises en sandwich entre les différentes intentions (intents) et les variations qu’elles créent – nous n’avons pas fait de changements significatifs à l’implémentation à ce moment-là.

Pendant que nous développions ces trois flux de dialogue, nous avons dû effectuer un ajout qui s’appliquait aux trois: après que l’utilisatrice ait indiqué ne pas avoir de symptômes sévères, Chloé doit obtenir sa province de résidence et son âge afin de lui fournir des recommandations plus précises. Cette fois, la solution la plus simple a été de recourir à l’utilisation d’un formulaire (form): l’information doit être conservée et le formulaire est facilement réutilisable dans toutes nos histoires.

Scène 3: Voie rapide vers l’inscription au suivi quotidien

Passons à la prochaine fonctionnalité: nous avons ensuite ajouté l’inscription au suivi quotidien. Si l’utilisatrice a des symptômes, alors Chloé lui offre le suivi quotidien. Si elle accepte, Chloé collecte son nom et son numéro de téléphone, note si elle a des antécédents médicaux ou des problèmes de santé qui pourraient augmenter ses risques de complications, etc. Ce flux de dialogue était aussi sans contredit un formulaire. Dans la première version, plus simple, bien que nous utilisions du texte libre pour collecter le prénom et le numéro de téléphone, il n’y avait pas vraiment de gestion d’erreur: nous utilisions la totalité du texte entré pour le prénom et tous les chiffres entrés pour le numéro de téléphone, en vérifiant seulement s’il y avait 10 ou 11 chiffres, sans quoi le numéro était demandé de nouveau.

Scène 4: Répondre à des questions et suivre TED

La fonctionnalité de questions et réponses (Q&R) doit permettre à l’utilisatrice de poser toute question qu’elle a au sujet de la Covid-19, envoyer cette question au module développé par le Mila, recevoir la réponse et l’afficher dans la conversation. Nous voulions rendre cette fonctionnalité disponible dans tous les flux de dialogue, en permettant d’y accéder par plusieurs endroits, mais aussi de poursuivre le dialogue dans diverses directions en fonction du résultat (je décrirai les différents types de résultat, de même que les détails de cette fonctionnalité et son évolution, dans la prochaine partie de cet article).

Puisque Chloé ne devait pas offrir d’auto-évaluation si celle-ci avait déjà été effectuée au cours de la conversation, les transitions suivant le Q&R dépendaient également de cela, ce qui a eu pour effet de multiplier les voies de sortie. La politique de mémoïsation n’aurait pas suffi pour apprendre cette différence puisqu’il est possible de repasser dans le module de Q&R à plusieurs reprises. Par conséquent, nous avons ajouté une case caractérisée (featurized slot) nommée self_assess_done, combinée avec les histoires d’auto-évaluation et de Q&R, et nous nous avons eu recours à la politique TED pour apprendre à partir de quelques exemples. Cela a fonctionné, mais notre fichier d’histoires a soudainement beaucoup enflé.

 

Intermission: Volte-face vers les formulaires pour éviter une jungle d’histoires

Entrevoyant la multiplication et l’allongement à venir de nos histoires, nous avons décidé de transférer la partie commune des évaluations dans un formulaire avant d’intégrer complètement le Q&R. Cela nous permettrait de raccourcir et de simplifier les histoires, mais également de faciliter la collecte d’informations sous forme de cases (présence de toux ou de fièvre, qui étaient deux questions récemment ajoutées, ainsi que la gravité des symptômes), ces dernières étant nécessaires si l’utilisatrice s’inscrivait au suivi quotidien. Un formulaire permettait, oui, de réduire la redondance, mais nous forçait aussi à utiliser un ensemble de cases intermédiaires jetables afin de poser la série de questions nécessaires pour déterminer la valeur d’une case unique correspondant à la gravité des symptômes. Cette case unique était caractérisée pour personnaliser l’offre de suivi quotidien et les recommandations faisant suite au formulaire dans les histoires.

Cependant, ce formulaire unique d’évaluation n’a pas fait long feu; le design a changé dès que nous avons eu le dos tourné. Deux messages de recommandations, au sujet de l’isolement et de l’assistance à domicile, ont été remplacés par de petits flux de dialogue contenant chacun une question. La conception et l’implémentation de ceux-ci ont beaucoup changé. Au départ, les deux flux étaient des formulaires qui ont été insérés là où se trouvaient les messages correspondants. Ensuite, nous avons dû tripler le formulaire d’évaluation pour y insérer le flux d’isolement au début, au milieu ou à la fin selon la situation (évaluation régulière, test positif ou réévaluation). Plus tard, le flux d’isolement a été déplacé et modifié pour chaque situation, mais nous avons conservé trois versions distinctes du formulaire d’évaluation pour graduellement y inclure les questions spécifiques qui ne faisaient pas partie de la version commune. Nous avons conservé du code en commun, mais le “comment” a évolué avec le temps; nous élaborerons davantage sur ce sujet lorsque la question de la modularité sera traitée dans un futur article.

À cette étape du projet, notre modèle général utilise une combinaison d’histoires, de formulaires et d’actions; et peut être résumé ainsi:

• Histoires: effectuer la transition entre les flux et sous-flux de dialogue, définir les séquences de formulaires, conditions et actions possibles pour chaque fonctionnalité et dialogue à haut niveau
• Formulaires: collecter des éléments d’information et définir des arbres de décision, gérer les sous-dialogues réutilisables incluant au moins une question, etc.
• Actions: utilisation variée lorsque la collecte d’information n’est pas requise, notamment l’affichage de plusieurs messages consécutifs

Voici un exemple d’histoire illustrant le modèle à ce point-ci:

Flux d’auto-évaluation de base suivi d’une question

 

Scène 5: Suivi quotidien; un autre type d’évaluation, un chemin connu

Le but du suivi quotidien est de contacter l’utilisatrice (qui s’est préalablement inscrite) chaque jour pour évaluer ses symptômes et, entre autres choses, suivre leur progression. Une question initiale permet de déterminer laquelle de ces trois situations s’applique à l’utilisatrice: elle se sent mieux que la veille, elle se sent plus mal, ou il n’y a pas de changement. Chaque situation a son propre arbre de décision, et chacun présente des variations en fonction des symptômes de la veille. Bien que certaines questions soient communes aux trois flux de dialogue, globalement, les similarités étaient insuffisantes pour pouvoir réutiliser des portions significatives du dialogue. Par conséquent, riches de notre expérience dans l’implémentation des flux d’auto-évaluation, nous savions que la meilleure façon d’implémenter les flux de suivi quotidien serait par le biais de trois formulaires distincts.

Scène 5.5: Jusqu’au bout du suivi quotidien

Il y avait beaucoup plus que l’évaluation au suivi quotidien: un dialogue de “lien invalide” (l’identifiant de l’URL envoyé à l’utilisatrice pour accéder au suivi quotidien n’existe pas), la possibilité de se désinscrire en un clic avant l’évaluation, et une autre, selon les symptômes, après l’évaluation, ainsi qu’un ensemble de recommandations à la fin de la conversation. Le dialogue de lien invalide a été ajouté sous forme d’histoires puisqu’il faisait simplement le pont avec d’autres fonctionnalités. Les offres de désinscription ont été ajoutées comme formulaires puisque nous collections de l’information et devions interroger notre base de données. Les recommandations, quant à elles, ont d’abord fait partie d’une action constituant un flux indépendant, appelé si nécessaire comme action subséquente (followup action) dans les formulaires de suivi quotidien ou de désinscription. Nous nous sommes toutefois rendu compte par la suite que les actions subséquentes devaient quand même faire partie des histoires, et lorsque nous avons ajouté les transitions vers d’autres fonctionnalités, il nous est apparu plus logique d’inclure les recommandations directement dans le formulaire.

Dans le prochain épisode

Dans cette première partie, j’ai décrit comment nous avons utilisé les histoires et les formulaires pour implémenter les multiples variantes des flux de dialogue d’auto-évaluation et de suivi quotidien. Quoique les histoires étaient adéquates au départ pour définir des arbres de décision simples contenant peu de branches, il est rapidement devenu évident qu’elles ne constituaient pas le meilleur outil pour implémenter des arbres de décision complexes, des branchements conditionnels ou encore des portions de flux réutilisables. Nous avons donc dû créer plusieurs formulaires qui ont été enchâssés dans des histoires, et recourir aux histoires pour gérer les flux à plus haut niveau.

Dans les phases suivantes du projet, nous avons ajouté aux fonctionnalités initiales les éléments suivants:

• Nous avons augmenté et amélioré les flux du Q&R
• Nous avons ajouté la recherche de cliniques de dépistage
• Nous avons ajouté le support au langage naturel (NLU), d’abord dans certaines portions du dialogue, et au final partout

Ces ajouts ont soulevé de nouveaux enjeux et présenté de nouveaux défis quant à la façon d’utiliser Rasa, non seulement dans la conception et le développement des dialogues, mais aussi pour s’assurer que la performance et la précision du traitement du langage naturel soient adéquates.

Nous nous attarderons à ces sujets dans la deuxième partie de cet article.

 

¹Nous utilisons majoritairement le féminin afin d’alléger le texte

²Nous avons librement choisi de traduire les concepts les plus importants comme suit: story => histoire, form=> formulaire, policy=> politique, slot => case, featurized => caractérisée. Ces choix n’engagent que nous.

³Le code a été écrit en anglais; il s’agit de code en source libre pouvant être consulté par quiconque. Il n’a pas été traduit pour conserver la correspondance avec le projet réel.