Développer un skill Alexa avec Python

Lisez l'article suivant pour une description détaillée de l'intégration de notre API Météo dans Alexa, y compris un tutoriel vidéo étape par étape, dans lequel j'illustre le processus de création d'un skill Alexa à partir de zéro en utilisant la console de développement.

Le mot clé ici est "développer". Même si un utilisateur n'avait qu'une seule intention lorsqu'il s'adresse à un assistant vocal (obtenir les prévisions pour le week-end, par exemple), l'interprétation correcte de toutes les différentes façons dont cette intention peut être formulée ("dites-moi le temps qu'il fera samedi et dimanche", "quel temps fera-t-il ce week-end ?", ...) nécessite beaucoup d'essais et d'erreurs. Bien sûr, cette seule capacité serait une mauvaise utilisation de la richesse des données météorologiques disponibles à partir de Meteomatics, nous devons donc également interpréter d'autres phrases, correspondant à des demandes différentes, sans les confondre avec les autres énoncés.

Heureusement, au cours des dernières années, Amazon a créé l'Alexa Skills Kit (ASK) pour faciliter la création d'outils personnalisés qui peuvent ensuite être mis à la disposition de tout appareil compatible avec Alexa¹, y compris les smartphones dotés de l'application Alexa. Dans cet article, je parlerai de mon expérience de démarrage avec le kit de compétences Alexa en utilisant Python, je ferai la démonstration de notre prototype de compétences en météorologie et je partagerai certains de nos projets de développement futurs.

Comment créer une compétence Alexa

Définitions

Tout d'abord, bien que je veuille éviter le jargon autant que possible, il y a quelques termes qu'Amazon utilise très spécifiquement dans le contexte de l'interface Alexa², et il vaut la peine de souligner quelques-uns d'entre eux avant de se laisser emporter. Un skill vocal Alexa (AVS – de l'anglais Alexa Voice Skill) - ou, plus communément, un simple "skill" - est le nom qu'Amazon a choisi de donner aux outils développés pour les appareils équipés d'Alexa. Plusieurs "intentions" valables peuvent s'inscrire dans le cadre plus large d'une compétence. Par exemple, les utilisateurs de notre compétence Meteomatics peuvent parfois vouloir savoir à quel point il va faire humide dans les prochains jours, ou encore se renseigner sur le recul de la calotte glaciaire au cours des 20 dernières années. Les réponses à ces deux questions peuvent être trouvées dans les données météorologiques et peuvent donc être traitées par le même skill³, mais elles reflètent des intentions très différentes de la part de l'utilisateur (bien qu'elles soient, espérons-le, assez faciles à distinguer).

En outre, chaque intention peut faire l'objet de légères variations, comme l'obtention des prévisions pour les prochains jours plutôt que pour toute la semaine prochaine. Au lieu de devoir définir une nouvelle intention pour différentes durées de prévisions et différentes heures de début, la même intention peut être utilisée avec de légères variations sous la forme de "créneaux". Enfin, comme je l'ai mentionné dans l'introduction, les utilisateurs ne devraient pas être limités à une syntaxe identique chaque fois qu'ils veulent demander la même chose à Alexa - après tout, ce n'est pas ainsi que nous parlons en tant qu'êtres humains. Les différentes façons dont un utilisateur peut spécifier la même intention sont appelées "énonciations", et le fait d'anticiper toutes les différentes énonciations qui devraient correspondre à la même intention sans chevauchement avec d'autres intentions fait partie du défi lors du développement d'un skill Alexa.

La console du développeur de compétences

Ok, c'est assez pour commencer. Alors, comment rédiger un skill Alexa ? Amazon's own walkthrough suggère de télécharger le code source pour traiter la parole (le Skill Developer Kit ou SDK) sur votre PC, avant de configurer l'hébergement dans le nuage pour le traitement de la parole vers le texte. Si, comme moi, vous trouvez tout cela plutôt intimidant, pas de panique ! Il est désormais possible de développer votre skill du début à la fin entièrement dans la console de développement - à laquelle vous pouvez accéder via un navigateur web - et cela signifie que votre skill sera initialisé avec une connexion à AWS Lambda dès le départ.

L'interface

Une fois que vous avez créé un skill, vous verrez une interface avec plusieurs onglets. Dans mon exemple ci-dessous, vous pouvez voir que mon skill s'appelle Meteomatics et que nous sommes actuellement dans l'onglet Build. Cet onglet gère l'interface du skill, et dans la barre latérale, vous pouvez voir les deux intentions sur lesquelles j'ai travaillé : MyWeatherNowIntent et WeatherWhenWhereIntent. De plus, comme j'ai mis en évidence le WeatherWhereWhenIntent, dans la fenêtre principale nous pouvons voir les énoncés⁴, qui montrent également les créneaux que cette intention attend. Ailleurs dans la console, vous pouvez définir les types de données pour ces slots, et indiquer à Alexa si ces données sont toutes nécessaires pour répondre à l'intention (et si c'est le cas, comment inviter l'utilisateur à les fournir s'il les a oubliées).

L'objectif du frontend, et la raison pour laquelle une connexion à un serveur en nuage est nécessaire pour le skill, est de traduire la parole prononcée par l'utilisateur en données qui peuvent être utilisées par le code dans le backend. Tout cela se fait à l'intérieur d'une boîte noire - et c'est tant mieux car le traitement du langage naturel est compliqué - nous pouvons donc passer à l'onglet Code, où le backend est conservé, et regarder comment la réponse est gérée.

Le Backend

Au cas où cela ne serait pas immédiatement évident, j'utilise Python pour développer mes skills - non seulement c'est le langage qui m'est le plus familier, mais j'ai également découvert qu'il y a relativement peu de ressources accessibles en Python disponibles en ligne (la plupart des développeurs d'AVS semblent préférer JS), j'espère donc que ce sera un exemple utile.

Quelques points méritent d'être soulignés dans l'extrait de code ci-dessus. Tout d'abord, vous pouvez voir que les deux classes de IntentHandler visibles partagent certaines propriétés - en fait, c'est également le cas de tous les autres Handlers. Ces propriétés sont les suivantes : elles héritent de la classe AbstractRequestHandler ; elles contiennent une méthode can_handle() à la syntaxe identique (qui renvoie simplement True/False selon que le Handler est approprié ou non pour l'intention) ; elles contiennent une méthode handle() dans laquelle toutes les fonctionnalités associées à l'intention sont écrites ; et elles renvoient toutes deux un objet handler_input qui possède des méthodes speak() et ask() ainsi qu'un attribut response. La méthode speak() prend le texte que vous voulez qu'Alexa dise à la suite de la logique du gestionnaire, tandis que la méthode ask() prend n'importe quel texte avec lequel vous voulez qu'Alexa relance l'utilisateur après une période d'attente (huit secondes par défaut).

L'argument handler_input est une instance de l'objet HandlerInput que vous pouvez voir importé en haut du script. Cet objet est un véritable cauchemar à comprendre, car ses attributs sont généralement eux-mêmes des instances d'objet avec leurs propres attributs d'instance d'objet (voir la ligne 50 pour un exemple d'un nombre modeste de tels objets imbriqués - de nombreux attributs souhaitables sont imbriqués encore plus profondément). Je ne recommanderais pas de passer trop de temps à essayer de comprendre cette structure dans votre premier skill : recherchez plutôt sur le web ce que vous voulez réaliser et copiez le code⁵.

Bien que vous puissiez voir un script helpers.py dans mon onglet Code, votre premier skill ne l'aura pas par défaut - je l'ai simplement créé pour garder les fonctions qui contactent l'API de Meteomatics séparées. Ce qui est important, cependant, c'est le fichier d'exigences. Il sera initialisé avec l'accès aux paquets ASK, mais si vous voulez ajouter des paquets pour vos propres besoins, vous devrez le compléter. La manière la plus simple de le faire est de développer la fonctionnalité backend de votre skill hors ligne dans un IDE, de créer un nouvel environnement dans lequel travailler et d'y installer les paquets requis. Une fois que le code se comporte bien, il peut être déplacé vers la console du développeur et le fichier d'exigences peut être créé à partir de l'environnement hors ligne à l'aide de la commande

pip freeze > requirements.txt

Copiez et collez ces exigences à la fin du fichier dans la console du développeur (assurez-vous de ne pas écraser les paquets qui sont présents par défaut).

A la fin du script lambda_function.py, vous verrez que les Handlers par défaut sont déjà ajoutés à un objet SkillBuilder. C'est essentiellement la façon dont ASK compile les différents Handlers contenus dans le script. Assurez-vous d'ajouter tout nouveau Handler au SkillBuilder, en reprenant cette syntaxe, et soyez conscient que l'ordre dans lequel vous les ajoutez peut parfois être important !

Testing

Nous pouvons maintenant passer à l'onglet Test. Pour tester votre skill, vous devez d'abord sélectionner "Development" dans la liste déroulante située en haut de l'écran. Vous pouvez ensuite commencer à tester la réponse d'Alexa à différentes expressions. Vous pouvez demander à Alexa de transformer votre discours en texte ou, si vous travaillez dans un bureau occupé et que vous vous sentez un peu gêné de parler à votre ordinateur toute la journée, vous pouvez également taper des phrases dans le simulateur.

A gauche, vous pouvez voir un exemple de dialogue que j'ai eu avec Alexa. Comme certains appareils Alexa sont toujours à l'écoute, il serait absurde qu'ils puissent répondre à tout ce qu'ils entendent et qui ressemble à une intention de skill. C'est pourquoi votre skill doit d'abord être invoquée à l'aide d'une phrase de lancement. Comme j'aime être poli avec mes robots, je demande à Alexa de "lancer la météo" ⁶ - vous n'êtes pas obligé de faire cela : il suffit d'utiliser le nom de l'invocation du skill. Maintenant qu'Alexa sait qu'elle est à l'écoute des intentions associées au skill Meteomatics, je peux utiliser une énonciation qui correspond à mon MyWeatherNowIntent. La réponse d'Alexa est un peu longue : en raison de la façon dont j'ai codé le backend, elle essaie d'abord d'obtenir ma géolocalisation précise en direct ; après avoir échoué⁷, elle essaie d'obtenir l'adresse enregistrée sur l'appareil ; c'est impossible parce que je suis sur mon ordinateur portable (mais cela fonctionne sur mon téléphone) ; elle revient donc par défaut à une adresse préprogrammée⁸ et me dit ce que c'est ; avant de contacter l'API Meteomatics avec cet emplacement et la date/heure actuelle pour obtenir des données météorologiques pertinentes, que je transforme en discours intelligible.

Cette première intention n'implique aucun emplacement. L'emplacement, la date et l'heure sont tous obtenus soit à partir de l'appareil, soit dans le script Python. Je voulais voir comment fonctionnaient les créneaux, et j'ai donc conçu une deuxième intention qui nécessite des informations supplémentaires de la part de l'utilisateur. J'envisage de retourner dans ma ville natale pour les fêtes de fin d'année et je veux savoir comment se déroulera notre traditionnelle promenade familiale du matin de Noël, j'ai donc décidé de demander à Alexa. Au début, c'est décevant - elle dit qu'elle ne peut pas trouver la réponse que je cherche - mais l'échec est en fait dû au fait que la session précédente s'est terminée et qu'Alexa a essayé d'utiliser le skill météo intégrée au lieu de celle de Meteomatics. (Cela pourrait être évité si je reprogrammais le SessionEndHandler dans le backend).

Je reformule donc ma question, en combinant cette fois la phrase de lancement et la requête. Alexa répond maintenant comme prévu, mais nous n'avons toujours pas notre prévision : J'ai oublié de préciser la date à laquelle je souhaitais obtenir l'information. Comme j'en ai fait un créneau obligatoire pour cette intention, Alexa me demande l'heure, que je fournis, et Alexa me donne le pronostic. On dirait qu'il va faire froid mais pas trop⁹ - je vais réserver mon voyage!

Debugging

Tout s'est bien passé, mais je vous conseille de ne pas vous attendre à ce que votre premier skill fonctionne dès la sortie de la boîte. Le débogage d'Alexa peut être un cauchemar, car la requête et la réponse JSON pour chaque énoncé ne contiennent pas beaucoup d'informations sur ce qui pourrait être cassé dans votre backend.

En tant que tel, je devrais rapidement démontrer l'outil de débogage le plus utile que j'ai trouvé en travaillant dans la console de développement.

De retour dans l'onglet Code, en haut de la fenêtre, vous pouvez voir une option de menu appelée CloudWatch Logs¹⁰. C'est là qu'Alexa stocke des informations sur les opérations de backend de votre skill. Un nouveau journal est automatiquement créé pour chaque session et contient des rapports horodatés sur chaque requête envoyée par Alexa, ainsi que la sortie d'erreur de la console Python si votre code tombe en panne. J'ai également importé le module de journalisation et enregistré plusieurs vérifications importantes au niveau .info. Voici un instantané du journal de notre conversation précédente avec Alexa:

Développer les compétences en météorologie

Ce que j'espère avoir montré jusqu'à présent dans cet article, c'est qu'une fois que vous avez dépassé le jargon et compris comment construire et déboguer un skill Alexa du début à la fin, il est assez simple de développer des skills qui gèrent plusieurs intentions de l'utilisateur et interagissent avec des API externes. Dans l'application Meteomatics, j'accède à la fois à l'API Meteomatics et à l'API de géocodage de Google, ce qui n'implique rien de plus compliqué que d'accéder à ces API à partir d'un script Python classique. Les parties les plus difficiles du développement d'un skill sont a) la conception d'une interface utilisateur vocale (VUI) qui capture la gamme des différentes façons dont les humains peuvent demander les mêmes choses sans ambiguïté, tout en évitant le chevauchement avec d'autres intentions et b) décider comment analyser la réponse API souvent assez complexe¹¹ en un texte qu'Alexa peut lire et que l'utilisateur peut comprendre. J'encourage les clients de Meteomatics qui ont trouvé cet article instructif à expérimenter l'intégration de nos données dans leurs skills : nous serions ravis de voir vos idées !

Notre compétence en météorologie n'est pas encore prête à être utilisée par le public. Comme elle est encore en cours de développement, il vaut la peine de conclure en parlant des projets que nous avons pour le skill à l'avenir, y compris ce qu'ASK peut actuellement faciliter. De même, si vous êtes un utilisateur de données météorologiques ou simplement intéressé par notre produit, nous serions ravis d'entendre vos idées sur des fonctionnalités utiles !

L'un des principaux avantages des données météorologiques de Meteomatics est qu'elles sont disponibles à une résolution incroyablement élevée. C'est ce qui a inspiré l'intention de MyWeatherNow, qui utilisera finalement la géolocalisation de l'appareil pour obtenir automatiquement la situation actuelle à l'endroit exact où vous vous trouvez. Bien entendu, cette fonctionnalité n'est pas utile : il est plus que probable que vous connaissiez déjà le temps qu'il fait à l'endroit où vous vous trouvez à l'instant même. Le principe pourrait toutefois être étendu à l'obtention des prévisions météorologiques pour l'endroit où vous vous trouvez. Les prévisions sont quelque peu difficiles à fournir avec une interface utilisateur virtuelle, car il y a beaucoup d'informations à synthétiser en une seule phrase. Prenons l'exemple d'un bulletin météo radio, qui résume en quelques phrases la situation d'une zone géographique. Les prévisions radiophoniques sont préparées par des humains, qui sont capables d'obtenir une impression générale à partir de données complexes et de la traduire en mots ; la formalisation de la logique nécessaire pour qu'un ordinateur puisse effectuer la même tâche est beaucoup plus compliquée.

Une utilisation plus pratique des données de géolocalisation est peut-être la mise en place d'une alerte ou d'un rappel météorologique. Les skills d'Alexa ont la capacité de mémoriser les attributs de la session et de les rappeler plus tard ou de les utiliser pour déterminer la prochaine action à effectuer.

Si vous étendez du linge pour le faire sécher, ou si vous essayez de prévoir quand quitter la maison d'un ami pour éviter de vous mouiller, il pourrait être utile de demander à Alexa de vous avertir une demi-heure avant le début de la pluie. Ce type d'application exploite les données météorologiques incroyablement fiables et spécifiques fournies par Meteomatics, et est certainement prometteur.

Vous pouvez également vous rendre à un endroit précis et vouloir connaître le temps qu'il fera une fois sur place. Là encore, les données Meteomatics sont parfaitement adaptées à ce problème ; le facteur limitant est l'interface utilisateur AVS. En raison de la diversité des formats d'adresses dans le monde, il est difficile de créer un type de données qui permette de capturer ces informations dans une fente. Amazon a mis en œuvre un type de données intégré pour les adresses aux États-Unis, mais l'extension de cette capacité à l'échelle mondiale dépendrait de la mise au point de types de données similaires pour le reste du monde.

Des lieux moins spécifiques sont plus faciles à mettre en œuvre. Par exemple, dans l'intention WeatherWhenWhere, je demande à l'utilisateur de fournir une ville et un pays¹². Ici, cependant, la haute résolution des données Meteomatics devient moins pertinente, mais notre API a une autre force qui est utile dans ce contexte, à savoir, la capacité de traiter rapidement de grandes quantités de données météorologiques. Dans le backend de WeatherWhereWhen, je fais cela en demandant des informations sur la température dans une grande zone et en prenant une moyenne spatiale. Ce type de traitement pourrait s'avérer utile lors de la préparation des vacances, qu'il s'agisse de requêtes simples telles que "quelle sera la température quotidienne moyenne à Barcelone la semaine prochaine" ou de requêtes plus complexes telles que "les conditions¹³ à Banff seront-elles bonnes pour skier lundi". En combinant la vaste gamme de paramètres disponibles auprès de Meteomatics avec des fonctionnalités prêtées par d'autres API, il n'y a aucune raison de ne pas répondre à des questions aussi compliquées que "quelle est la meilleure ville du nord de l'Italie de moins de 200 000 habitants pour y développer un projet immobilier". Ce type de question semble étrangement spécifique et n'est pas quelque chose que nous serions susceptibles de programmer explicitement dans une compétence, mais donne une idée de l'ampleur des questions qui peuvent être posées à l'API Meteomatics - et auxquelles elle peut répondre.

Il y a encore beaucoup d'étapes à franchir pour arriver à un skill Alexa complet pour Meteomatics. Nous espérons que cet article a donné un aperçu des possibilités passionnantes qui s'offrent à nous. Restez à l'affût pour le développement continu d'interfaces utilisateur vocales pour Alexa et d'autres appareils activés par la voix, et bien sûr, si vous avez des commentaires sur ce que vous aimeriez voir ensuite, nous serions ravis de vous entendre.