Entrando en el mundo de las aplicaciones (Skills o Actions) para Alexa y/o Google Assistants, se nos plantea el reto de reutilizar, en todo lo posible, los elementos que forman parte de nuestra aplicación, la lógica de negocio, el NLP, etc.
La aplicación de un asistente es, básicamente una API que implementa una lógica de negocio junto con un servicio de procesamiento de lenguaje natural o NLP (Natural Language Processing). Alexa y Google Assistants se encargan de convertir nuestras palabras en texto para que podamos implementar nuestros diálogos con la funcionalidad necesaria para que nuestra aplicación interactúe con los usuarios.
Alexa
La arquitectura propuesto por Alexa para que implementemos una Skills se basa en utilizar un modelo de interacción donde podemos definir todos los Intents (intenciones) junto con los Slots (entidades) extraídas de las frases del usuario. Este es el proceso más básico, ya que existen otras funcionalidades para implementar diálogos y validaciones.
Con estos Intents y Slots, Alexa hace una petición POST a un EndPoint donde implementamos nuestra lógica de negocio y devolvemos la respuesta para que Alexa se la entregue al usuario.
Google Assistants
La arquitectura de Google Assistants es muy similar a la de Alexa, una Action se implementa sobre la base de Intents y Entities que se definen en la herramienta Dialogflow de Google.
Estos Intents pueden ser enviados a un Webhooks. A diferencia de Alexa, en Dialogflow podemos tener Intents que responden al usuario directamente, sin necesidad de comunicarse con nuestro Endpoint.
¿Cómo reutilizar los elementos de nuestra arquitectura?
A nivel de dispositivo está claro que no vamos a reutilizar y tampoco vamos a necesitar implementar ningún servicio de Speech to Text, ya que de esto se encarga el dispositivo.
La lógica de negocio la podemos tener en una API que implemente la especificación de Alexa y Google para recibir y responder ante una petición de un usuario. Hay que tener en cuenta que Alexa y Google hablan diferentes idiomas y que el código que procesa la petición y el código que responde al asistente no pueden ser el mismo, pero si pueden utilizar la misma lógica de negocio.
El servicio de procesamiento de lenguage (NLP) debería de ser el mismo, con lo que podemos aprovechar toda la definición y entrenamiento que hagamos para que sea efectivo en los dos asistentes. El objetivo es que nuestra aplicación entienda los Intents del usuario mediante un NLP común a las dos plataformas, cómo podemos ver en el diagrama anterior.
Dialogflow de Google permite, de una forma sencilla, deshabilitar o, realmente, no hacer ningún tipo de procesamiento del lenguaje y enviar todo el texto del Speech del usuario al Webhook definido en el servicio. Básicamente nos creamos un único Intent vacío con las llamadas al Webhook activadas.
Alexa no lo tiene del todo claro. Han deprecado un elemento de configuración (AMAZON.Literal) que nos permitía no hacer ningún tipo de procesamiento de lenguaje y pasar todo el texto al Endpoint. Aún así, es posible implementar un Intent que procese cualquier frase y que envíe el texto al Endpoint usando un Slot personalizado.
Aunque no vamos a reutilizar el 100% de nuestro código, hay que tener en cuenta que las sesiones, los diálogos, la forma en que podemos modificar el comportamiento del habla, etc., son diferentes en cada asistente.
Nuestra lógica de negocio junto con el procesamiento de lenguaje natural (NLP), sí que se puede reutilizar.No tiene que ser al 100% (porque seguro que podemos hacer uso de las capacidades especiales de cada asistente), pero sí en la medida en que nos permita interactuar con nuestra capa de negocio y/o con nuestros sistemas o aplicaciones.
¡Suscríbete a nuestras RRSS!
