Alexa Games Hackathon: jugando con el dispositivo de voz de Amazon.

No hay duda de que las interfaces de voz se han convertido en imprescindibles en nuestro día a día. Tienen tanta relevancia, que todos los días podemos leer novedades y noticias sobre estos dispositivos casi a diario.

Los grandes proveedores (Google, AWS, Apple) presentan sus nuevas características a bombo y platillo en sus conferencias anuales, dedicando gran parte de sus sesiones y workshops a mostrar las nuevas capacidades de sus plataformas.

Todos los análisis coinciden en unas previsiones de crecimiento impresionantes, mostrando un mercado joven que va adquiriendo madurez… ¡estamos en la era de la voz!

El pasado 21 de septiembre, nos presentamos al Alexa Games Hackathon, evento organizado por Keep Coding. En este encuentro, el reto se centraba en el desarrollo sobre Alexa, la plataforma de voz de AWS, y en este post os vamos a comentar cómo nos preparamos y llevamos a cabo el hackaton.

La plataforma de desarrollo de Alexa

Antes de meternos en harina, veamos algunos términos que utilizaremos durante el desarrollo de este post:

Skill

Programa o función que se puede añadir a Alexa. En este caso, el objetivo del hackaton era precisamente crear una skill.

Intent

Entidad que define la acción que queremos realizar. Dentro de la skill sería cada una de las acciones que se van a poder realizar.

Utterance

Cada una de las frases o trozos de texto que queremos que Alexa reconozca, debemos asociarlo a un intent para que lo lance. Es decir, un Utterance va a producir que se ejecute un Intent, pero puede haber (y normalmente hay) varios utterances para cada intent.

..Alexa, deseo comprar un coche..

..Alexa, quiero comprarme un coche..

..Alexa, quiero comprar un coche..

Slot

Información que queremos extraer de una utterance para después manejarla. Podríamos decir que es un campo de un formulario que en el código se convertirá en una variable, es decir varía de una frase a otra y es dinámico para la comunicación con el back.

..Alexa, quiero comprar un {coche}..

..Alexa, quiero comprar un {camión}

Lambda

Es el servicio de FaaS (Function as a Service) de Amazon y será el código que invoque cuando se ‘dispare’ un Intent. El funcionamiento de la plataforma Alexa sigue este esquema:

Para simplificar aún más las cosas, Alexa te permite utilizar funcionales lambdas gestionadas directamente desde el propio entorno de desarrollo de Alexa, haciendo aún más sencilla la puesta en marcha de una skill.

En el caso de una aplicación más extensa o sin las limitaciones de tiempo de un hackathon, convendría utilizar un entorno ‘normal’, pero para este caso vimos que el entorno integrado era la mejor opción.

Requisitos del hackathon

Este hackaton tenía un planteamiento inicial claro: desarrollar un juego para poder interactuar con Alexa.

Para ello, nos plantearon 3 categorías:

• Daily casual games: valoramos que la gente tenga ganas de abrirlos todos los días para jugar menos de 5 minutos.
• Choose your own adventure (adventure games): valoramos que la gente cree juegos de tipo Rol donde tome decisiones en una aventura.
• Puzzle solving/Scape the Room: juegos para el ingenio con retos.

En nuestro caso, optamos por la categoría de casual games, nos pareció la opción más interesante para el tiempo del que disponíamos para desarrollar.

¿Cómo lo planteamos?

Antes de nada, deciros que las tres personas que nos presentamos al hackathon habíamos trasteado algo con la plataforma de Alexa, por lo conocíamos de antemano algunas de sus posibilidades y sus limitaciones.

Sabíamos, por ejemplo, que plantear flujos de conversación complejos dispararía la dificultad del desarrollo, por lo que deberíamos contenernos a la hora de diseñarlos.

También habíamos visto que, para el correcto funcionamiento de la skill, era necesario generar una buena variedad de utterances para que el ‘matching’ fuera apropiado cuando el usuario interactuara con él. Esta información nos ayudó a definir el planteamiento que aplicamos.

Sesiones de ideación iniciales

La organización nos permitía ir con una propuesta de juego ya pensada, por este motivo realizamos un par de sesiones de ideas para ver qué juego podíamos hacer. Esto fue clave para ganar tiempo en el hackaton y centrarnos en llevar a cabo lo que teníamos en mente.

Pensamos diferentes juegos, principalmente evaluando un equilibrio entre complejidad de desarrollo y la posibilidad de hacer un buen papel en el hackathon. Queríamos poder presentar algo ‘funcional’, así que descartamos aquellas ideas que fueran muy complicadas a la hora de desarrollarlas.

Finalmente, decidimos apostar por la idea que más versatilidad nos ofrecía, y con la que pudiéramos explotar las capacidades que Alexa proporciona.

Visión de MVP

Durante la fase de ‘ideación’ surgieron múltiples funcionalidades para nuestro juego: desde customización de los usuarios, diferentes modos de juego o niveles de dificultad en función de la edad de los participantes.

Todas estas características, si bien eran interesantes, tanto desde el punto de vista de desarrollo como del resultado final de la skill, no eran imprescindibles para el desarrollo del juego, por lo que decidimos apartarlas para ‘fases posteriores’ en función del tiempo que nos quedará.

El MVP final era realmente simple: poder empezar una partida e ir avanzando hasta poder completarla, lo justo para poder ponerla en funcionamiento, aprender de lo que habíamos desarrollado y evaluar cuánto tiempo tardábamos en desarrollarla.

División de trabajo

La aplicación tenía tres componentes claramente definidos:

• Desarrollo de los utterances sobre la plataforma de Alexa.
• Desarrollo del código para la gestión de la conversación mediante funciones lambda.
• Desarrollo de algoritmo de juego.

De forma conjunta, planteamos los ‘contratos’ de comunicación entre los tres componentes, es decir, los distintos intent que tendría nuestra skill, junto con la API y las variables de entrada que tendría nuestro algoritmo. Con estos elementos definidos empezamos a avanzar de forma independiente.

Cuando alcanzamos una mínima funcionalidad estable, volvimos a evaluarlo de forma conjunta, comprobando que todo encajaba.

En ese momento rotamos en cuanto a labor que cada uno hacía. Nuestro objetivo personal del hackaton era aprender cómo desarrollar una skill para Alexa, por lo que los tres queríamos entender cómo funcionaban todas las piezas.

Testing

Desde el principio sabíamos que testear una interfaz de voz no iba a ser fácil, muchas iban a ser pruebas manuales, directamente interactuando con el simulador de Alexa y no iba a ser rápido ni cómodo.

El tiempo era limitado, así que debíamos de eliminar cualquier fallo debido a la programación y para ello decidimos crear todos los tests unitarios que pudiéramos para simular las situaciones que el motor de Alexa produciría.

Empezamos con pequeños test sobre el algoritmo que nos indicaría si la respuesta era o no correcta. Era el componente más claro a testear, era un elemento sin estado, por lo que debíamos proporcionarle toda la información para poder ir avanzando por el juego:

• Comienzo de partida.
• Respuesta positiva y negativa.
• Fin de la partida.

Estamos habituados a trabajar con tests, así que la implementación salió de forma bastante natural.

A continuación, queríamos testear los distintos ‘Intent’. Lo llevamos a cabo con la funcionalidad de testeo que provee el entorno de desarrollo, con el que para diferentes utterance de entrada podemos comprobar que hace el ‘matching’ con el Intent esperado.

Una vez conocida la información que Alexa proporciona a las funciones de código, fue muy fácil replicar las distintas situaciones y datos para invocar a las funciones.

En paralelo, y utilizando las herramientas que provee Alexa, probamos la selección de ‘Utterances’ para ver si los comandos de voz eran correctos, utilizando las herramientas que la plataforma de desarrollo nos facilita.

Algo interesante que nos provee Amazon en este producto, es ver el listado de las diferentes frases que usan los usuarios para comunicarse con Alexa. Esto nos permite adaptar los ‘Utterance’ inicialmente introducidos al lenguaje que utilizan nuestros usuarios.

Por último, hicimos las pruebas end-to-end, ya dentro del simulador y fuimos afinando hasta conseguir resultados adecuados, para conseguir la mejor experiencia de conversación.

Los tests fueron adaptándose en cada uno de los ciclos de funcionalidad incrementales que se fueron implementando. Nos basamos siempre en los test de las etapas anteriores, que nos sirvieron como pruebas de regresión.

Roadmap

En la primera hora y media habíamos conseguido ese ‘mínimo funcional’ que buscábamos. Podíamos empezar la partida y avanzar hasta lograr terminar el juego. Desde luego había muchas carencias y elementos que mejorar, pero ese era justo el objetivo.

Tras repasar de forma intensa lo que llevábamos hecho, pusimos en común el listado de mejoras que serían necesarias. Priorizamos y seleccionamos las que creíamos más necesarias. Decidimos trabajar en:

• Mejorar la conversación, haciéndola más natural añadiendo distintas opciones de respuesta.
• Dotar de ‘personalidad’ a la skill, este es un punto muy importante para lograr la naturalidad que buscábamos. Estábamos implementando un juego, así que la personalidad debía ser ‘divertida’.
• Incrementar el set de datos para el juego.
• Internacionalización, dejándolo preparado para incluir distintos idiomas. Puede parecer irrelevante a estas alturas, pero es muy sencillo y nos ayudaba a la hora de incluir las distintas opciones de respuesta.
• Incluir una opción para ‘pedir ayuda’ por si no sabes jugar.

A medida que fuimos probando, vimos que Alexa paraba el juego si se tardaba mucho en dar una respuesta (algo normal, pero hasta el momento no habíamos caído en ello). Decidimos entonces persistir los datos de sesión, para poder recuperar el juego donde se había dejado.

Poco después de comer, teníamos listas las funcionalidades. Nos dedicamos nuevamente a comprobar el resultado e ir tomando nota de posibles mejoras.

Después de las pruebas, los tres llegamos a la misma conclusión: al haber incrementado el set de datos del juego, había muchas más opciones. Esto supuso que, en algunas situaciones, el juego se quedase “bloqueado”, algo frustrante al no saber por dónde avanzar.

No nos quedaba mucho tiempo, así que decidimos que una opción de ‘pedir pista’ sería la única que implementaríamos. Era la única que veíamos factible con una mínima seguridad de poder completarla.

Con esto cerramos el desarrollo, el tiempo restante estuvimos repasando las funcionalidades que se habían quedado fuera (interfaz visual para los dispositivos con pantalla, la personalización de usuarios…) y planteando los ‘siguientes pasos’ de cómo se podrían desarrollar nuevas funcionalidades si decidiéramos seguir adelante con la skill fuera del entorno del hackaton.

Problemas que nos hemos encontrado

El desarrollo y el trabajo sobre la plataforma fue en general bastante bueno, sin embargo nos encontramos con algunos problemas y limitaciones a medida que fuimos avanzando en el desarrollo.

El mayor de los problemas fue, sin duda, la imposibilidad de poner un ‘slot de texto libre’ junto a otro tipo de slots, ni siquiera cuando estaba al final del utterance y lo intentábamos separar por palabras fijas que marcasen su principio. Tuvimos que ‘partir’ la conversación en distintos bloques para poder solventar este problema, a costa de perder naturalidad en la misma.

Por otro lado, el entorno de desarrollo integrado, si bien nos ayudó a empezar más rápido, supuso luego un problema al no estar preparado para trabajar en grupo.

No vimos una forma sencilla de engancharlo con el sistema de control de versiones por lo que en cada prueba debíamos copiar ‘a mano’ los ficheros con el código.

En entorno de desarrollo integrado nos permite actualmente desarrollar en Node.js y Python.

Resultado final

Creamos una pequeña presentación para que nos sirviera de soporte a la hora de hablar con el jurado.

Ahí comentábamos de qué trataba la skill, por qué habíamos elegido ese tipo de juego y cuáles eran los objetivos que nos habíamos marcado para conseguir el reto.

Indicamos también cuál era el roadmap esperado de la skill y cuáles eran las funcionalidades que nos gustaría haber incluído.

Quisimos también hacer hincapié en los problemas que nos habíamos encontrado, y cómo planteamos la resolución de los mismos, así como lo que habíamos aprendido. Además de la presentación por supuesto hubo demo.

Conclusión

Aunque los tres conocíamos la plataforma de Alexa, el hackaton nos ha permitido verla más en profundidad, desde un punto de vista más ‘real’, comprobando sus posibilidades e incluso descubriendo alguna de sus debilidades como hemos comentado anteriormente.

La conclusión es algo que ya sabíamos, están en un estado de crecimiento y mejora continuada, que si bien es esperanzador, actualmente se quedan cortas para algunos casos de uso.

El modelo de conversaciones sencillas está bien cubierto, con facilidades que simplifican el desarrollo. Sin embargo, intentar implementar algo más complejo no parece a día de hoy que sea recomendable por el esfuerzo que puede llegar a suponer obtener un resultado adecuado.

El futuro de las interfaces de voz es realmente prometedor, ¡estamos impacientes por ver qué mejoras vendrán!