​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.