Et en fait, ça n’a rien de bien nouveau. Nous appelons habituellement ça « RVI avec reconnaissance vocale » et c’est ce type d’expériences conversationnelles que nous créons depuis 20 ans.

Ce qui est nouveau, c’est qu’il existe désormais de nouvelles technologies et de nouvelles plateformes qui promettent d’accélérer et de faciliter la création de ce type d’expériences conversationnelles tout en bonifiant considérablement l’éventail des tâches que les agents virtuels vocaux (comme nous les appelons) peuvent exécuter.

Ces nouvelles technologies ont initialement vu le jour chez les assistants vocaux (Siri, Amazon Echo, Google Home) et sont en train de changer fondamentalement la façon dont les solutions RVI sont développées.

Pour comprendre comment, comparons la « RVI traditionnelle avec reconnaissance vocale » avec cette « nouvelle RVI ».

Technologie	RVI traditionnelle avec reconnaissance vocale	Nouvelle RVI
Reconnaissance vocale	Grammaires et modèles de langage statistiques	Transcription automatique de la parole (speech-to-text)
Compréhension du langage naturel (CLN/NLU)	Grammaires et classificateurs simples	Traitement automatique du langage naturel (TALN) par apprentissage profond (deep learning)
Synthèse de la parole	Concaténation de segment vocaux + synthèse vocale (TTS)	Synthèse vocale (TTS), principalement

Regardons tout cela plus en détails.

RVI traditionnelle avec reconnaissance vocale

Les engins de reconnaissance vocale traditionnellement utilisés dans les RVI (par exemple, Nuance Recognizer) ne sont pas en mesure de fonctionner “out-of-the-box”. Pour cela, on doit faire appel à des grammaires de reconnaissance vocale. Il existe deux types principaux de grammaires :

1. Les grammaires SRGS sont définies par un ensemble de règles, élaborées manuellement par un développeur de grammaires. Elles fournissent une description formelle des énoncés qui peuvent être reconnus par l’engin de reconnaissance. Le langage défini par les grammaires SRGS est rigide et seuls les énoncés prévus dans ces grammaires peuvent être reconnus par l’engin. Les grammaires SRGS sont bien adaptées aux dialogues dirigés, qui présentent typiquement un ensemble prévisible d’énoncés qui seront fournis par l’utilisateur.
2. Les modèles de langage statistique (SLM) sont définis par des N-grammes; ce sont les probabilités d’occurrence un mot étant donnés les mots précédents dans la phrase, probabilités apprises à partir d’un échantillon de phrases. Les modèles SLM fournissent un modèle de langage beaucoup moins rigide que les grammaires SRGS et sont donc beaucoup mieux adaptés pour traiter les réponses aux questions ouvertes (par exemple, « Comment puis-je vous aider? »), réponses normalement plus spontanées, et fournies par l’utilisateur en langage naturel. Pour bien performer, les modèles SLM doivent pouvoir s’entraîner sur un corpus de phrases suffisamment grand et représentatif du domaine ciblé.

Le développement d’une application RVI traditionnelle avec reconnaissance vocale nécessite la création d’une grammaire distincte pour chacune des étapes du dialogue. De plus, pour atteindre un niveau de précision de reconnaissance suffisant, ces grammaires doivent subir de nombreux réglages basés sur des énoncés d’utilisateurs réels, qui auront été collectés par l’application RVI en production.

Le développement et le réglage de ces grammaires sont des tâches chronophages qui nécessitent l’intervention de spécialistes de la parole hautement qualifiés. Si cela est bien fait, on peut atteindre une très grande précision dans la reconnaissance et créer des expériences utilisateur positives. Malheureusement, ces tâches sont trop souvent négligées, ce qui se traduit inévitablement par des performances de l’engin de reconnaissance décevantes, ce qui à son tour entraîne une expérience utilisateur médiocre. C’est d’ailleurs une des principales raisons pour lesquelles les RVI avec reconnaissance vocale ont si souvent mauvaise réputation.

Transcription automatique de la parole (speech-to-text, STT)

Au cours des dernières années, et grâce à l’apprentissage profond, nous avons assisté à une évolution fulgurante des technologies de reconnaissance vocale. Cette importante percée a permis d’entraîner des engins STT qui arrivent à fournir des transcriptions vocales de haute précision pour des types presque illimités de vocabulaires. De nos jours, bon nombre de fournisseurs proposent des engins STT (par exemple, Google STT, Nuance Krypton, Amazon Transcribe, Deepgram, etc.) et il existe également des versions en code source libre (open-source).

Avec l’utilisation des engins STT, il n’est plus nécessaire de développer des grammaires, un gain de temps non négligeable lors de la création d’applications RVI conversationnelles. Est-ce que l’on vient ici de résoudre l’énigme de la reconnaissance vocale? Loin de là! Atteindre un niveau de précision acceptable reste un enjeu majeur. En fait, des grammaires adéquatement réglées apporteront un niveau de précision souvent nettement plus élevé que le meilleur des engins STT.

Actuellement, les principaux problèmes rencontrés lors de l’utilisation d’engins STT sont:

• Données d’entraînement. Comme pour tout modèle basé sur l’apprentissage automatique, les performances du modèle STT seront optimales si ses données d’entraînement sont représentatives des conditions dans lesquelles il est utilisé. Ainsi, si un modèle était, par exemple, principalement entraîné sur des enregistrements obtenus à partir d’un haut-parleur intelligent, abordant typiquement des thèmes tels que la météo, le réglage des alarmes, la lecture de musique et des questions de connaissances générales, il est fort probable que ce modèle n’offrirait pas des performances optimales dans le cadre d’une application RVI de type bancaire. S’il était possible d’affiner les réglages d’un modèle STT en l’entraînant sur des données spécifiques à un domaine précis, cela pourrait faire une énorme différence en ce qui a trait à la précision. Malheureusement, la plupart des fournisseurs d’engins STT ne permettent pas cette option (exception faite de Deepgram). Notons toutefois que Nuance fournit une solution partielle en permettant d’entraîner le modèle par langue de domaine (domain language model, DLM) sur des phrases spécifiques à chaque domaine ciblé.

• Contextualisation. Les engins STT peuvent conceptuellement reconnaître n’importe quel énoncé d’utilisateur, que celui-ci parle de films, de politique, de météo, de musique, peu importe. C’est une fonctionnalité très puissante, mais qui peut aussi devenir un handicap dans le contexte des applications conversationnelles, qui sont généralement spécifiques à un domaine particulier en plus d’être fortement contextualisées. Si un agent virtuel demande à un utilisateur de fournir une date de naissance, il y a fort à parier que l’utilisateur réponde en fournissant une date de naissance. La fait de savoir tirer profit de ces connaissances contextualisées peut grandement améliorer la précision de la reconnaissance vocale. Les humains font cela constamment, sans même s’en rendre compte. Certains engins STT fournissent quelques capacités de contextualisation (par exemple, la fonctionnalité d’adaptation de modèle de l’engin STT de Google), mais celles-ci restent assez limitées pour le moment.

• Optimisation. Les engins de reconnaissance vocale des RVI traditionnelles offrent plusieurs moyens efficaces d’optimiser la précision. Par exemple, d’importants gains de précision peuvent être obtenus en affinant les transcriptions phonétiques, en modélisant la coarticulation à l’intérieur des mots et entre les mots, en modélisant les disfluences verbales, en ajustant les poids des différents éléments d’une grammaires ou les poids des différentes grammaires, en intervenant dans le post-traitement des meilleurs résultats (N-best results), etc. La plupart des engin STT offrent peu, sinon pas de moyens d’optimiser la précision.

• Support multilingue. Nu Echo étant située à Montréal, ville bilingue, la plupart des applications conversationnelles que nous déployons doivent savoir traiter les mots anglais dans les phrases en français et vice-versa (la reconnaissance d’adresses en est un très bon exemple). Cela ne peut être fait efficacement qu’avec un engin de reconnaissance vocale capable de traiter deux langues différentes à l’intérieur d’un seul et même énoncé, une fonctionnalité disponible chez certains engins de reconnaissance vocale des RVI traditionnelles, mais dans aucun engin STT de notre connaissance.

Les technologies STT évoluent extrêmement rapidement. Nous pouvons donc nous attendre à ce que le niveau de précision de reconnaissance soit en constante amélioration, à pouvoir profiter d’outils de contextualisation et d’optimisation de plus en plus efficaces, à accéder plus facilement à des modèles pouvant être optimisés en fonction de domaines spécifiques. En attendant, la solution idéale pourrait très bien être une combinaison engins STT, engins RVI traditionnelles.

Compréhension du langage naturel (natural language understanding, NLU)

Les premières applications RVI avec reconnaissance vocale reposaient exclusivement sur les grammaires SRGS pour la reconnaissance vocale; la compréhension du langage naturel (NLU) n’était donc pas un problème, le NLU étant intégré à la grammaire.

L’utilisation de modèles de langage statistiques (SLM) a fait naître le besoin d’avoir un engin NLU distinct, capable de comprendre les résultats de reconnaissance pour des énoncés spontanés. Des techniques de détection d’intentions, basées sur des techniques simples d’apprentissage automatique, ont été introduites il y a plus de 20 ans, pour des besoins reliés à l’aiguillage d’appels en langage naturel. Ces techniques font très bien fait l’affaire, mais elles nécessitent habituellement un imposant échantillon de phrases, pour chacune des intentions, afin que le modèle soit correctement entraîné, ce qui représente souvent un obstacle de taille à la mise en service d’un système.

Durant bon nombres d’années, ces techniques n’ont pas beaucoup évolué. Puis, est arrivé l’apprentissage profond, qui a totalement changé le paysage des technologies de traitement du langage naturel. Un premier grand changement a été l’introduction des représentations vectorielles continues de mots (word embeddings), qui améliorent la généralisabilité et permettent de diminuer de façon considérable la taille de l’échantillon de phrases nécessaire pour entraîner les modèles NLU. Plus récemment, des modèles de langage de grande taille (entraînés sur de gros corpus de données, par exemple BERT) et de nouvelles architectures de réseaux neuronaux apportent d’autres améliorations d’envergure.

Il est intéressant de noter que les technologies NLU utilisées pour traiter les conversations textuelles sont les même que celles utilisées pour traiter les conversations vocales, alors qu’il existe des différences importantes entre ces deux types de conversation. Par exemple, les systèmes traitant des conversations textuelles doivent être capables de gérer de manière fiable les fautes de frappe, les acronymes et les sigles (par exemple, « lol », « mdr »), les émoticônes, etc., alors que les systèmes traitant les conversations vocales doivent, de leur côté, savoir gérer les différences orthographiques entre homophones (par exemple, « cent » vs. « sans », « Desjardins » vs. « des jardins » ou « soixante-treize » (73) vs. « soixante treize » (60 13)), les normalisations de l’engin STT non-souhaitées (par exemple, « H 1 M 2 L 5 » → « H un mètre deux L cinq »), sans parler des erreurs de reconnaissance vocale.

Abordons maintenant certains problèmes reliés à l’utilisation des engins NLU :

• Contextualisation. La plupart des engins NLU ne sont pas contextuels (à l’exception de Dialogflow), ce qui peut être un problème car le même énoncé peut avoir des interprétations différentes en fonction du contexte dans lequel il apparaît. Par exemple, l’interprétation de l’énoncé « Montréal » sera différente selon que la question posée était « quelle est votre destination? » ou « quelle est la ville de départ? »

• Score de confiance. Un dialogue de réparation efficace doit pouvoir s’appuyer sur des scores de confiance fiables mais malheureusement, les scores de confiance des engins NLU n’ont pas tendance à être très précis. De plus, les scores des engins NLU ne prennent généralement pas en compte le score de confiance de reconnaissance vocale. Or, comment se fier à un résultat NLU s’il est lui-même basé sur un résultat de reconnaissance vocale à faible score de confiance? Pour être considérés comme sûrs, les scores de confiance des applications conversationnelles vocales doivent prendre en compte à la fois les scores STT et les scores NLU.

• Meilleurs résultats (N-best results). De nombreux engins NLU ne renvoient qu’une seule intention, celle avec le score de confiance le plus élevé, même si elle apparaît auprès d’autres intentions ayant des scores presque identiques. Le fait de pouvoir avoir accès à une liste des meilleurs résultats (N-best results) permet de prendre de meilleures décisions en ce qui a trait au dialogue (par exemple, lorsque vient le temps de désambiguïser certains énoncés) ou de choisir la meilleure hypothèse en fonction d’informations contextuelles qui ne seraient pas disponibles pour l’engin NLU.

Le traitement automatique du langage naturel est actuellement l’un des domaines de recherche en intelligence artificielle des plus dynamiques et nous nous attendons à ce que les systèmes d’IA conversationnels bénéficient d’un flux continu d’avancées technologiques.

Synthèse de la parole

Les technologies de synthèse vocale (TTS) existent depuis très longtemps, mais jusqu’à tout récemment, la qualité et l’intelligibilité des résultats n’étaient pas assez bonnes pour offrir une expérience conversationnelle convenable. Les segments vocaux des meilleures applications RVI avec reconnaissance vocale étaient presque tous enregistrés en studio avec des voix professionnelles. Pour ce qui est du rendu des phrases comprenant des données dynamiques, on devait alors procéder à de la concaténation de segments, ce qui est assez complexe à faire correctement.

Mais des progrès phénoménaux ont récemment vu le jour du côté des technologies TTS. Il est ainsi désormais raisonnable, dans la plupart des cas, d’utiliser des voix de synthèse plutôt que des enregistrements studio. C’est particulièrement vrai en anglais, où la qualité de la meilleure voix de synthèse est telle qu’il est parfois difficile de la distinguer d’une voix humaine. De plus, on peut maintenant créer des voix de synthèse personnalisées qui peuvent imiter notre voix professionnelle préférée.

Le recours aux technologies TTS change vraiment la donne pour tout ce qui a trait à la création et au développement des applications RVI conversationnelles. D’une part, elles éliminent le besoin de retourner constamment en studio pour enregistrer de nouveaux segments vocaux dès que survient un changement à l’application. D’autre part, elles nous épargnent de fastidieuses manipulations de milliers de segments vocaux (dans souvent plus d’une langue), tâches trop souvent sources d’erreurs. Désormais, les applications peuvent être modifiées, testées et mises en production dans la foulée.

Bien sûr, les technologies TTS ne sont pas parfaites et nous rencontrons encore des erreurs occasionnelles, mais généralement il s’agit d’un faible prix à payer en comparaison avec l’immense valeur ajoutée qu’elles apportent. La solution idéale pourrait très bien être une combinaison d’enregistrements en studio, pour les segments audios clés où nous recherchons une intonation et une émotion précise, et de segments de synthèse personnalisés, construits à partir de la même voix professionnelle que celle utilisée dans les segments pré-enregistrés.

Intégration avec les plateformes de centre de contacts

Les applications RVI traditionnelles avec reconnaissance vocale ont longtemps adhéré à des standards éprouvés pour réaliser l’intégration de technologies conversationnelles; qu’on pense au protocole MRCP pour la reconnaissance et la synthèse vocale, au langage VoiceXML pour les dialogues, à la spécification SRGS pour les grammaires de reconnaissance vocale ou au mécanisme SISR pour l’interprétation sémantique.

Désormais, avec l’émergence d’une nouvelle génération de plateformes de centre de contacts infonuagiques et l’arrivée des plus récentes technologies basées sur l’apprentissage profond, tous ces standards deviennent obsolètes et sont remplacées par un éventail d’interfaces de programmation (API) propriétaires et de nouveaux standards émergents (par exemple, l’environnement gRPC).

L’intégration de ces nouvelles technologies conversationnelles avec les plateformes de centre de contacts demeure une tâche en cours d’évolution. Voici ce que nous constatons:

• Certaines fonctionnalités de base que nous tenions habituellement pour acquises (par exemple, les interruptions (barge-in) et le repli DTMF) ne sont pas toujours disponibles
• Le choix des technologies conversationnelles disponibles sur plusieurs plateformes de centres de contacts reste limité
• Même lorsque des intégrations sont disponibles, il est souvent très difficile de tirer pleinement profit du potentiel des nouvelles technologies (par exemple, le fait de ne pas avoir accès aux scores de confiance ou aux listes des meilleurs résultats (N-best), le fait qu’il soit impossible de faire du post-traitement sur les résultats STT avant de les envoyer à l’engin NLU, etc.)

Certaines solutions voient tranquillement le jour afin de combler ces problèmes d’intégration. Par exemple, Audiocodes, avec son VoiceAI Connect, prétend fournir « une connectivité facile entre toute plateforme de centre de contacts et tout environnement de développement robot ou tout engin vocal » (“easy connectivity between any CC platform and any bot frameworks or speech engine”). Cela pourrait permettre d’exploiter au mieux les technologies conversationnelles en fonction des exigences propres à chaque solution à implanter.

Le meilleur des deux mondes

L’apprentissage profond a un impact fondamental sur les technologies d’IA conversationnelles et cela change considérablement la façon dont nous envisageons le développement des applications RVI. Nous sommes encore aux balbutiements de cette transformation. Ces nouvelles technologies sont encore trop immatures mais évolueront probablement très rapidement dans un avenir proche. À nous de nous adapter à leur évolution rapide et de comprendre comment les exploiter le plus efficacement possible.

Néanmoins, ces nouvelles technologies offrent déjà des avantages concrets très significatifs. Par exemple :

• Il n’est désormais plus nécessaire, pour que la reconnaissance vocale fonctionne, de créer des grammaires complexes ou de recueillir des milliers d’énoncés d’entrainement pour des modèles SLM. La précision de reconnaissance vocale des meilleurs engins STT est, d’emblée, suffisamment acceptable, de sorte qu’il est désormais possible de mettre rapidement en production un système opérationnel.
• Les plus récents engins NLU peuvent être entraînés avec énormément moins de phrases que les anciennes technologies de classification NLU, ce qui permet, ici encore, de pouvoir mettre très rapidement en production la première version d’un système.
• Les plus récentes technologies de synthèse vocale sont devenues si performantes qu’il n’est maintenant presque plus nécessaire de recourir à des segments audios pré-enregistrés (en particulier pour l’anglais). Cela réduit considérablement le délai nécessaire pour concevoir et mettre en production des nouvelles versions d’une application, facilitant et accélérant ainsi grandement leur déploiement.

La possibilité de mettre rapidement en service une première version d’une application est cruciale car elle permet de commencer rapidement à recueillir de vraies données conversationnelles et des énoncés d’usagers réels, matière première avec laquelle le système peut être amélioré et optimisé de façon continue.

Alors que certaines des limites des technologies STT commencent à être prises en considération (par exemple, en termes de contextualisation, d’optimisation, de traitement multilingue, etc.), les développeurs d’applications RVI conversationnelles devraient envisager de combiner les technologies STT avec les technologies de reconnaissance vocale des RVI traditionnelles afin d’obtenir le meilleur des deux mondes et d’offrir aux utilisateurs de RVI conversationnelles des expériences remarquables (certaines plateformes RVI, par exemple la plateforme vocale de Genesys, permettent cette combinaison d’approches).

Dialogflow CX vs. ES

L’entrevue débutait par une comparaison entre Dialogflow CX et ES. CX n’est pas qu’une simple évolution par rapport à ES; c’est en fait un redesign complet, avec un modèle de dialogue plus intuitif et beaucoup plus puissant. CX propose entre autres une nette séparation entre les intentions et les dialogues, ce qui augmente considérablement la réutilisabilité des intentions et la gestion des dialogues. CX vient avec une interface visuelle qui peut facilement être utilisée par les “Conversational Architects” afin de créer des dialogues complexes tout en utilisant moins de lignes de code.

Selon Passemard, c’était une demande de longue date de la part de beaucoup de clients. Bien que Google continuera à supporter et faire évoluer Dialogflow ES, qui reste approprié pour des dialogues simples, Dialogflow CX devrait devenir la plateforme toute désignée pour gérer les dialogues longs et complexes. De plus, Dialogflow CX offre plusieurs avantages par rapport à ES :

• Une tarification plus prévisible (mais pas nécessairement moins coûteuse)
• Plusieurs fonctionnalités spécifiques pour la RVI (incluant le support du ‘’barge-in’’, du DTMF, des “timeouts” et des “retries”)
• La possibilité de supporter jusqu’à 40 000 intentions (comparativement à 2 000 avec ES)
• Davantage de fonctionnalités de collaboration qui permettent aux équipes de développement de travailler plus efficacement sur de grands projets
• Un meilleur support pour l’analytique, l’expérimentation et les boucles de rétroaction.
• Un engin NLU plus performant, basé sur le dernier modèle BERT.

Tout le monde peut utiliser Dialogflow aujourd’hui. Cependant, pour la RVI conversationnelle, l’intégration de Dialogflow à une plateforme de centre de contact reste généralement un défi. Par exemple, la plateforme RVI doit pouvoir fournir à Dialogflow certains événements ou paramètres, que ce soit pour utiliser le DTMF pour des choix de menus, ou encore pour la gestion incrémentielle d’événements “no-input”.

Passemard a mentionné que certaines solutions, telles que Audiocodes, peuvent faciliter cette intégration. Fait intéressant, il a également mentionné qu’il est préférable de transmettre le flux audio directement à Dialogflow plutôt que d’utiliser Google STT pour transcrire l’audio et envoyer par la suite la transcription vers Dialogflow. La raison étant que Dialogflow dispose d’une fonction d’adaptation vocale automatique qui optimise la précision de la transcription en fonction des phrases d’apprentissage de l’agent.

Cela dit, notre propre expérience montre que nous pouvons souvent obtenir des résultats aussi bons sinon meilleurs en transmettant l’audio directement à Google STT, en utilisant l’adaptation vocale. De plus, il est souvent nécessaire de post-traiter les résultats de transcription afin de les rendre compatibles avec le NLU de Dialogflow, ce qui n’est pas possible lorsqu’on transmet le flux audio directement à Dialogflow.

L’Assistant à l’Agent pour le canal voix

Le sujet suivant abordé dans l’entrevue était l’Assistant à l’Agent (“Agent Assist”). C’est un sujet d’importance pour au moins deux raisons. D’abord, parce qu’il existe des cas d’utilisation très prometteurs pour l’Assistant à l’Agent et ensuite parce que nous avons beaucoup entendu parler de l’Assistant à l’Agent CCAI au cours des deux dernières années, mais qu’il a été difficile de comprendre exactement comment accéder à cette capacité.

Sur ce dernier point, Passemard a confirmé ce que nous soupçonnions, c’est-à-dire qu’il n’y a pas d’API publique pour l’Assistant à l’Agent vocal, Google ayant décidé de le rendre disponible uniquement via les partenaires de téléphonie CCAI. Comme le mentionne Simms, c’est probablement une bonne stratégie commerciale pour Google. En travaillant de manière agressive avec les partenaires de téléphonie pour intégrer l’Assistant à l’Agent à leurs plates-formes et en vendant cette fonctionnalité exclusivement à travers ces partenaires, Google pourrait faire en sorte de devenir le choix de facto pour l’Assistant à l’Agent.

L’inconvénient, par contre, est que les entreprises dépendent entièrement de la motivation et de la capacité des fournisseurs des plateformes de centres de contact à rendre CCAI disponible à leur clientèle. Il pourrait donc s’écouler beaucoup de temps avant que nombre d’entreprises ne puissent tirer parti de CCAI et, lorsque ça sera possible, ça pourrait demander des mises à niveau très coûteuses de leur infrastructure de centre de contact. Pour cette raison, les clients pourraient finir par se rabattre sur les solutions alternatives qui deviendront inévitablement disponibles.

Cela m’amène aux cas d’utilisation d’Agent Assist. Passemard a mentionné que la fonctionnalité de proposer des documents pertinents aux agents en fonction de la conversation n’a pas été jugée très utile par les clients. Les agents ne veulent pas lire des documents complets pour trouver la réponse aux questions des clients. Ils veulent une recherche extractive, qui peut extraire automatiquement la partie pertinente du document. Et, d’après ce qu’on a compris, cette fonctionnalité arrivera bientôt. Mais ce qui décolle vraiment en ce moment selon Passemard, c’est la capacité de remplir automatiquement des formulaires en temps réel avec les informations mentionnées par l’appelant. Et, bien sûr, un autre avantage de l’Assistant à l’Agent est d’obtenir une transcription de chaque appel.

L’Assistant à l’Agent pour le chat

Passemard a indiqué que l’Assistant à l’Agent pour le chat améliore considérablement la productivité et la satisfaction des agents et les scores CSAT. En particulier, les fonctionnalités Smart Reply et Smart Compose sont fournies à l’aide de modèles prédictifs entraînés sur les données du client, ce qui les rend beaucoup plus précises. L’Assistant à l’Agent pour le chat n’est actuellement disponible qu’à travers les fournisseurs de chat, mais une API publique sera bientôt disponible.

Insights

La dernière fonctionnalité CCAI mentionnée est Insights, qui est le nom que Google donne pour l’analytique des conversations (“speech analytics”). Insights est toujours en préversion, mais la bonne nouvelle est que ça sera bientôt accessible à tous avec une API publique. Insights consiste à comprendre les conversations qui se déroulent dans le centre de contact. En utilisant Insights, les entreprises pourront examiner les conversations, les indexer, les rechercher, faire de la modélisation de sujets et de l’analyse des sentiments, naviguer dans une conversation et effectuer des recherches en langue naturelle (par exemple, « donnez-moi toutes les conversations avec un message d’accueil » ). Google offrira une intégration SIPREC.

Notes finales

Passemard a mentionné que l’IA conversationnelle est probablement la première application de l’IA à avoir un impact profond sur les consommateurs. C’est une affirmation intrigante; il serait intéressant de voir quelques données qui soutiennent ses propos. Il conclut également en insistant sur l’importance d’un bon architecte conversationnel. Nous ne pourrions être plus en accord avec lui. Ce n’est certainement pas une expertise qui peut s’apprendre en deux semaines. Les très bons ont des années d’expérience et sont essentiels à la réussite de tout projet conversationnel.

Mon meeting Zoom est interrompu par la sonnette, qui résonne quatre fois.

Je reconnais le signal: je viens de recevoir un nouveau mandat.

Je m’excuse auprès des autres agents, quitte la session et cours vers la porte d’entrée.

Comme je m’y attendais, il n’y a personne, mais je remarque un petit colis à mes pieds. Je le ramasse et retourne à l’intérieur. L’enveloppe n’a pas de timbre, pas d’adresse, pas de nom. Rien.

Je reviens au canapé, seulement pour trouver Rusty confortablement installé à l’endroit précis où j’étais il y a un instant.

«Miaou», fait-il. Traduction: «C’est ma place maintenant, humain. Et je ne bougerai pas.»

D’accord, d’accord… Je m’assois à côté de lui et ouvre le paquet. Sans grande surprise, j’y trouve un magnétophone portable. Très vintage, comme d’habitude. Une voix familière remplit l’air de mon salon lorsque j’appuie sur Play:

«Bonjour, Monsieur Gestionnaire de Projet.»

Je rigole doucement. Encore ce ton officiel, après toutes ces années?

«Votre mandat, si toutefois vous l’acceptez, est de fournir une application conversationnelle pour La Compagnie, qui souhaite améliorer son expérience client (CX) en automatisant ses services client. L’application devra pouvoir fournir des réponses personnalisées aux questions qui lui seront adressées, mais également exécuter des actions en fonction des demandes des utilisateurs. Elle devrait aussi permettre aux agents de prendre le relais afin de résoudre rapidement les conversations problématiques.»

Ça semble intéressant, tout ça. Évidemment, j’aurai besoin de plus d’informations avant de pouvoir commencer la planification, mais je peux déjà réfléchir à ce à quoi ressemblerait l’équipe parfaite pour ce projet.

«Les exigences initiales vous seront transmises sous peu. Je suis certain que vous opérerez au mieux de vos capacités lors de l’exécution de ce projet.»

Rusty, allongé sur le côté, étire ses jambes et ferme les yeux. «Ne t’inquiète pas, copain. Ton mandat, c’est de dormir.» Je le gratte entre les oreilles, et le chat ronronne son approbation.

«Cet appareil s’autodétruira dans dix secondes. Bonne chance.»

Oh non, pas ça encore! Je me précipite dans ma cour arrière, vise la poubelle et lance le magnétophone juste avant qu’il ne commence à se consumer. C’était moins une. La dernière fois, je n’ai pas été aussi chanceux, et ma maison a empesté le plastique brûlé pendant presque une semaine.

De retour sur le canapé. Je m’assois de nouveau à côté de Rusty, qui me lance un regard indigné. Sa queue fouette l’air alors que j’ouvre mon classeur spécial contenant les portraits de tous les agents à ma disposition.

Je parcours les photos, à la recherche d’une en particulier. J’ai besoin d’un excellent communicateur, comme… Le voilà, l’agent Analyste d’Affaires, pour faire le pont entre le client et l’équipe. Son sens aigu de l’observation lui sera très utile, car il devra comprendre les besoins et les règles d’affaires du client. Il rassemblera les exigences du client et l’aidera à les définir, les spécifier et les hiérarchiser afin de déterminer la solution qui lui convient le mieux.

Tout au long du projet, il mettra à profit sa compréhension de la technologie et de ses utilisations potentielles pour travailler avec le client et l’équipe technique afin de s’assurer que les exigences soient satisfaites et que l’application fonctionne telle que définie.

La photo suivante représente l’agente Architecte de Solutions. Oui, sa capacité à avoir une perspective technique globale sur le projet nous sera particulièrement utile. Sa profonde connaissance des technologies de pointe pertinentes l’aidera à conseiller le client ainsi que l’équipe technique sur les meilleurs choix technologiques à prendre afin de répondre aux exigences et se conformer aux contraintes du projet. Elle veillera à ce que toutes les différentes pièces de la solution soient considérées et bien intégrées les unes aux autres dans un ensemble aussi robuste qu’efficace.

Quelqu’un devra définir et concevoir la conversation entre l’utilisateur final et le système. Cette personne doit également être un excellent communicateur, capable d’interagir avec toutes les parties prenantes ainsi que les membres de l’équipe technique. Je me tourne vers Rusty, qui a déjà l’air un peu moins irrité. «Qu’est-ce que t’en penses, toi?» Il bâille. Merci pour l’aide, l’ami. Tu as parfaitement raison: l’agent Concepteur d’Expérience Utilisateur Conversationnelle (c’est un peu long; nous l’appelons Concepteur CUX, pour faire court) est le candidat idéal. Il sera responsable de l’expérience utilisateur et de la conception de l’interface utilisateur, à la fois pour le texte et la voix. Sa tâche consistera à traduire en cas d’utilisation les exigences commerciales et fonctionnelles. Il pourra ensuite rédiger la conception fonctionnelle détaillée, les flux de dialogue spécifiques, ainsi que les messages de l’application, qu’il devra valider avec le client et les utilisateurs finaux. Il incombera à l’agent Concepteur CUX de s’assurer que les conceptions répondent aux exigences du client tout en tenant compte des limitations techniques, y compris celles imposées par les outils de reconnaissance automatique de la parole (ASR) et de compréhension du langage naturel (NLU).

Il est très important de s’assurer que l’application comprenne bien ce que dit l’utilisateur et interprète correctement ce qu’il veut dire. Après tout, pour qu’une interface conversationnelle soit efficace, il est essentiel que les dires de l’utilisateur soient bien compris et qu’ils soient interprétés avec précision, à la fois globalement et en contexte. J’arrive à la fin du classeur, recommence depuis le début. Où est-elle? Ah, voilà! L’agente Spécialiste NLU. Elle travaillera en étroite collaboration avec l’agent Concepteur CUX, car ils représentent les deux faces d’une même médaille: il doit y avoir une cohésion parfaite entre le dialogue et le NLU pour que la conversation soit réussie. Pour les applications vocales, elle sera responsable de la configuration et du réglage de l’ASR.

Une fois la solution déployée et utilisée par des personnes réelles, l’agente Spécialiste NLU continuera à jouer un rôle essentiel dans la mise au point et l’amélioration de l’application dans sa capacité à comprendre ce que veut dire l’utilisateur.

Une partie de l’équipe devra matérialiser les exigences et les conceptions en une application réelle qui pourra être rendue accessible aux utilisateurs finaux. La quantité de travail que cela représente est beaucoup trop grande pour une seule personne. Je résiste à l’envie de demander à nouveau de l’aide à Rusty, qui s’endort doucement contre ma cuisse. Bon, alors: je vais mettre… l’agente Développeuse Logiciel, l’agent Software Developer, l’agent Ohjelmistokehittäjä et l’agente Softwareentwickler sur cette tâche. Ce sont eux qui mettront en œuvre le dialogue, créeront les accès aux systèmes backend du client (ce qui est crucial si nous voulons fournir des réponses personnalisées et interagir avec le système au nom de l’utilisateur), rédigeront les tests unitaires et adapteront les outils existants, comme des widgets de clavardage, pour tous les besoins particuliers du projet. Sans développeurs, une application conversationnelle n’est rien de plus qu’un concept. Les développeurs expérimentés peuvent également fournir des commentaires utiles aux concepteurs et ainsi contribuer à la réussite du projet.

Pour que toutes les pièces de l’application fonctionnent ensemble, j’ai besoin de, voyons voir… Oui: l’agent Intégrateur. Son large éventail de compétences, qui couvre à la fois le domaine du logiciel ainsi que la résolution de problèmes, sera déterminant pour fournir une solution fonctionnelle adaptée aux besoins du client. Son approche généraliste l’aidera à effectuer tous les diagnostics d’anomalie qui sont inévitablement nécessaires lors de l’intégration de projets complexes.

Rusty ronfle à côté de moi, plongé dans ses rêves de chat. Pour mener à bien ce projet, j’aurai besoin de l’aide précieuse de la brigade des Spécialistes de l’Assurance Qualité (QA). Ils joueront un rôle essentiel pour s’assurer que l’application déployée est entièrement conforme aux spécifications détaillées et répond à toutes les exigences. La brigade interagira avec les concepteurs et les développeurs, mais aussi avec le client, offrant leur soutien lors de la phase des tests d’acceptation. Ils seront responsables des plans de test et de la définition de tous les cas de test détaillés, qu’ils soient manuels ou automatisés (ces derniers sont indispensables dans le cadre d’une intégration continue et d’une livraison continue (CI / CD)). La qualité de la solution dépend beaucoup du dévouement et du professionnalisme des Spécialistes QA, car ce sont eux qui donnent le feu vert final pour le déploiement.

Oui, je crois que c’est bon. Il est temps de démarrer ce projet. Mais d’abord, une petite tasse de thé, ce serait super. En me levant, je remarque un épais nuage de fumée qui s’élève depuis ma poubelle, dans la cour. Je soupire tout bas, pour éviter de réveiller Rusty. Le thé devra attendre. Je dois d’abord m’occuper de ce magnétophone autodestructeur (ou simplement destructeur, en fait).

Pourquoi ne pas faire comme tout le monde et simplement envoyer des courriels?

 

Merci à mes collègues Linda Thibault et Karine Déry

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.