¿Qué es un test A/B?

Es la forma de comparar estadísticamente 2 versiones de un mismo producto. En marketing se usa como estrategia que permite conocer los gustos y costumbres de los usuarios. Se crean 2 versiones de producto, versión A y versión B, que difieran en color, forma, tamaño, … Se definen las métricas (clicks, scrolls, tiempo de sesión, …) que servirán para comparar las 2 versiones. Una vez comparado los datos que arrojen las versiones, podemos extraer conclusiones para nuestro producto. Por ejemplo, dónde poner un botón, qué color de fondo funciona mejor o cómo de largo debe ser un texto, entre otros. En el siguiente video lo explican muy bien.

¿Por qué queremos hacer esto en nuestro bot?

En resumen, para entender mejor a nuestros usuarios, sus gustos y preferencias. La intención es adquirir 2 niveles de conocimiento.

1. General: Tomar perspectiva real de las preferencias de mis usuarios, aprender de ellos, puede haber cosas que pensamos que gustan y no se corresponde con la realidad. Nos ayudará a entender mejor los perfiles de nuestros usuarios.
2. Concreto: Para mejorar el diseño de nuestro bot, sus interacciones en modo vocal, textual o táctil, recursos gráficos, textos, sugerencias, … saber qué funciona mejor, en sus diálogos, la profundidad de los niveles de conversación, flujos diferentes …

¿Cómo lo hacemos?, ¿qué necesitamos tener en cuenta?

Para afrontar el problema de A/B testing en bots me gustaría enumerar algunas herramientas ya disponibles:

• Botanalytics.
• Botlytics.
• Chatbase.
• Dashbot.
• Facebook Analytics for Messenger bots.

Son herramientas que conectándose a tu bot pueden extraer los datos necesarios que sirven para hacer un análisis posterior. Si con ninguna de esas herramientas te vale, y quieres hacer tu propia herramienta para test, aquí te dejo algunas ideas.

Métricas 

Tu herramienta necesita incluir varios tipos de indicadores. Está muy bien medir el número de interacciones por usuario, pero qué sucede cuando tenemos un usuario que dice 300 veces “Hola, ¿qué tal?” , los resultados pueden distorsionarse. Aquí os sugiero algunos índices más:

• Interacciones. Separando totales, vocales o textuales y táctiles si las hubiera.
• Sesión. Duración de la sesión.
• Tasa de abandono. Número de personas que experimentan con tu bot pero no les gusta.
• Usuarios. Activos en el test, antiguos y nuevos.
• Recurrencia. Vuelven los usuarios al bot. Sobre qué versión vuelven más A o B.
• Calidad. Están los usuarios interactuando sin interés o son de calidad. Podemos contar las intenciones (intents) por usuario sobre cada versión del test y descartar las intenciones irrelevantes (saludos, despedidas, smalltalk, …). También ver el dominio al que se acoge cada interacción y ver si se encuentra en el marco de nuestro test. Incluso podríamos eliminar las stopwords como son las preposiciones, artículos o pronombres y sacar el índice de palabras con peso en las interacciones y comparar las versiones.
• Conversiones. Cada caso de uso de tu bot tiene un camino que acaba en una conversión. Donde una conversión es llegar al paso final del camino definido, y cada paso del camino es un nivel de profundidad de la conversación del bot. Cada versión A o B son caminos diferentes ¿Están tus usuarios llegando al final de cada camino?, ¿En que versión llegan más A o B? ¿Dónde se quedan?

Formas de establecer los grupos de usuarios del test

Establecer los grupos de usuarios puede complicarse, especialmente si quieres evitar inducir a sesgos cognitivos.

• Conversación abierta. Si es un experimento abierto en el que no se necesita tener en cuenta el perfil del usuario, puedes hacerlo aleatoriamente según los usuarios vayan entrando, de manera que, al final la distribución quede repartida tal y como lo has pensado en un principio (50/50, 20/30/50, 40/60, …) esto puede ayudar a evitar sesgos en el caso en que los usuarios sepan que versión será la suya.
• Conversación Restringida. En caso de que el experimento sea restringido a una conversación o funcionalidad específica, donde solo se despierte el interés de determinados usuarios, sería interesante perfilar a estos usuarios previamente para no meter a otros usuarios en el embudo equivocado y estropear las métricas. Es decir, un test A/B sobre una conversación de futbol sería bueno hacerlo con personas con cierto gusto por el futbol.

Independientemente si necesitas perfilar a los usuarios o no, otra idea para agrupar los usuarios de forma eficiente y evitar los sesgos, es hacer la asignación a los grupos de forma aleatoria sobre el espectro predefinido. A medida que los usuarios interaccionen serán añadidos en orden a la muestra predefinida.
Por ejemplo, un test AB sobre 1000 usuarios repartidos 50/50, reservaré 500 huecos al grupo A y 500 al grupo B, mezclados ya aleatoriamente, donde asignaré a los usuarios por orden de llegada.
Esto evita sesgos y nos permite hacer el cálculo de la versión que será asignada previamente, lo que puede ser más eficiente en caso de cálculos complejos por perfiles u operaciones propias del bot.

Peculiaridades de correr A/B test en bots

Los Tests A/B son una idea de unos ingenieros de Google, allá por los 2000 para medir cual de las 2 versiones A o B de un buscador, mostraba mejores resultados. Hacer esto en un bot tiene algunas singularidades:

• Conducir al usuario hasta nuestro embudo no es fácil mediante una conversación. Las conversaciones son mucho más abiertas que una web donde el usuario se restringe al área de acción de la web. En un bot no sabemos lo que el usuario va a decir, imagina que puede decir lo primero que le venga a la cabeza
• Al no saber que va a decir, debemos estar preparados para que la conversación pueda variar y debemos tenerlo presente para diseñar nuestro test. Podemos querer que el usuario entre por un camino concreto donde participará en el test pero si no entra en ese camino o si entra pero su conversación es inesperada, el bot debe estar preparado para responder adecuadamente.
• En un post anterior mencionaba las guías de usabilidad en interfaces vocales. GUI + TTS ≠ VUI (Graphical User Interface + Text to Speech ≠ Voice User Interface). Si vuestro bot tiene el apoyo de una interfaz visual, serviros de ella, pero es importante recordar que lo principal es la voz. Diseñar nuestro bot para que la voz sea la protagonista principal. Para hacer un test A/B y conducir al usuario a nuestro test diseña antes las posibilidades de conversación y los diferentes flujos que pueda tomar el diálogo.

Las 5 Claves para poner en marcha tus test A/B

1. Métricas. ¿Qué vamos a medir? Por ejemplo, quiero saber la tasa de conversión de una tarjeta de información (card) frente a otra con otro color. Podremos medir el número de taps dentro de la card, el número de veces que se pide información relativa a la card, el número de sesiones terminadas en la card, entre otros indicadores.
2. Estrategia. Diseña tu test, número de usuarios, como van a estar divididos (2 grupos de 50/50, 3 grupos de 30/20/50, …). Echa cuentas, cuántos usuarios tienes y cuántos necesitas que confirmen tu hipótesis inicial.
3. Escenario. Que sea lo más real y relevante posible. Si queremos probar con un grupo de usuarios una funcionalidad concreta pero no usamos el bot de producción es importante que los usuarios estén ante un entorno lo más real posible para no inducir a sesgos que distorsionen los resultados. Ve a lo importante, si tu bot es para pedir pizzas y tus usuarios no hacen pedidos, no tiene mucho impacto que hagamos A/B testing para saber si un saludo es mejor recibido que otro, servirá más que testemos la conversación previa y durante el pedido para detectar si algo no va bien.
4. Aislamiento. Si quieres testear un bot que recomienda ropa. Puedes empezar por los elementos visuales como las tarjetas de información (card) y luego los diálogos. No mezclemos todo. La interacción con botones y diálogos sobre lo mismo a la vez eso es un test A/B multivariante, empieza por algo sencillo.
5. Resultados. Busca una buena herramienta que te permita visualizar los resultados como mejor los entiendas tú y tu equipo. A mi personalmente Elastic Stack me va bien pero hay otras alternativas como splunk, logDNA o Loggly.

Espero que estas píldoras te ayuden.

Gracias por leerlo.

Fuentes

https://discover.bot/bot-talk/improving-chatbot-performance-through-ab-testing/
https://www.optimizely.com/optimization-glossary/split-testing/
https://chatbotsmagazine.com/a-b-testing-in-chatbots-2e6197787a5c
https://chatbotsjournal.com/the-definitive-guide-on-chatbots-a-b-testing-92384d76e0f2
https://medium.com/ibm-watson/chatbot-validation-methods-8930737aeb2d
https://blog.aimultiple.com/chatbot-analytics/
https://www.optimizely.com/optimization-glossary/multivariate-test-vs-ab-test/

The post 5 Claves para hacer A/B testing en tu bot: Escucha a tus usuarios first appeared on Planeta Chatbot.

Si te dedicas a desarrollar asistentes virtuales no puedes perderte los avances que se están haciendo en este campo.

Nuevos comienzos

Una de sus más recientes actualizaciones ha sido la de su kit de desarrollo (sdk v4). Esto ha empujado también a una nueva versión del emulador que nos permite testear esos desarrollos.

El emulador ha sido objeto de un gran rediseño, añadiendo sofisticación, así como potentes vínculos con herramienas propias como Microsoft Azure. Permitiendo, ahora desde el emulador, construir, testear y desplegar tus bots siguiendo instrucciones precisas.

Todos estos cambios han transformado la antigua experiencia en algo más redondo y comprensible para sus usuario.

Fichero .bot

El kit de desarrollo en esta última versión cambia la forma de crear bots. Una vez que consolidaron el movimiento dentro de Azure, Microsoft, ha depurado la experiencia de usuario. Desde la selección del lenguaje de programación .NET o Nodejs a plantillas de bots para ayudar en los comienzos.

Uno de esos múltiples cambios es al arrancar un bot. Ya no es necesario incluir una gran lista de variables de configuración. Ahora todo esta información se ha incluido en un fichero .bot que indexa la información.

fichero .bot

Entornos y tests

El fichero .bot no es más que una configuración por entornos con las propiedades que necesita el bot para funcionar. Estos entornos, como novedad, se pueden editar y configurar desde el propio emulador. Lo que hace que sin tocar una sola línea de código puedas testear tu bot en un entorno parecido a producción.

Así que, creamos nuevos entornos pero ¿podemos comparar sus resultados? Ahora se pueden abrir varios entornos y bots a la vez en múltiples pestañas de forma que nos permite comparar el comportamiento de 2 o más bots fácilmente.

Mejoras visuales

La posibilidad de abrir multiples bots a la vez se ha unido a unas cuantas más mejoras visuales:

• Página de bienvenida. Incluye un resumen de instrucciones y el momento de creación donde se encuentra tu bot. También ofrece la posibilidad de conexión con Azure.

welcome page

• Mejores logs. Se ha mejorado el inspector de la conversación. Haciendo click en las viñetas de diálogo puedes ver con detalle la información de las respuestas. Los logs ahora tienen una visualización más clara.
• Guadar conversaciones. Se crea la posibilidad de compartir conversaciones que a su vez se podrán abrir en desde el simulador.

guardar conversaciones

Recopilemos

Microsoft ha avanzado mucho ofreciendo un conjunto de herramientas que mejoran la experiecia del desarrollador. Con todas estas mejoras es el momento de evaluar si merece la pena la transición de versión. También comparar si otras compañías ofrecen herramientas similar, y evaluar una posible migración en caso de necesitarlo.

Para los que os guste seguir la pista de Microsoft y probar sus servicios os dejo aquí más información:

• http://croquetastecnologicas.com/2018/06/08/tutorial-puesta-en-marcha-bot-framework-sdk-v4/ → bot sdk v4 en .NET
• https://docs.microsoft.com/en-us/azure/bot-service/javascript/bot-builder-javascript-quickstart?view=azure-bot-service-4.0 → bot sdk v4 en Nodejs.

The post Bot Framework Emulator v4 — Review first appeared on Planeta Chatbot.

En esta ocasión la conferencia fue dividida en 4 salas diferentes, cada sala trataría un tema diferente: Cloud y Machine Learning, Web, Mobile y Assistant.
Es la primera vez que había un track especializado del famoso asistente de Google, así que Aura, la inteligencia artificial de Telefónica, quiso estar allí.
En el equipo de prototipado de Aura, nos dedicamos a probar nuevas ideas para mejorar las capacidades de nuestra inteligencia artificial. Así que, dadas las características de la conferencia seguro que podíamos aprender sobre la comunidad que desarrolla software para asistentes, los proyectos con asistentes y ver ideas frescas.

Hey Google, what is possible with Actions on Google?

— Rose Grundy (https://twitter.com/roseanna_g)

Y así comenzó la charla con una introducción general de las últimas novedades de Google Assistant de la mano de Rose. Novedades generalmente orientadas a mejorar la experiencia del usuario o del desarrollador.

Continued Conversation

Esta fue la mayor funcionalidad publicada en el último Google I/O el pasado Mayo, junto con Duplex. Trata de evitar que el usuario diga “Ok Google” cada vez que quiera hablar con el dispositivo. Esto quiere decir que el dispositivo siempre está escuchando una vez que invoquemos al asistente.

Actions Templates

Son plantillas que nos permiten desarrollar una app en minutos mediante un Google Sheet, el excel de Google Apps. Con esto quieren abrir el círculo del desarrollo a personas que no tengan habilidades de programación muy desarrolladas pero con ideas para hacer un app en un asistente.

Sample Actions

Estos son los ejemplos que tiene Google para que los desarrolladores puedan empezar sus proyectos con alguna base. Siempre apoyándose en la plataforma Dialogflow, que facilita la creación de estás apps de tal forma que no haga falta una línea de código para tener una app funcionando.

Table Card

Es la nueva solución gráfica destinada especialmente para facturas o cualquier tipo de datos tabulados.

Theme customization

Con la personalización de los temas Google Assistant permite a los desarrolladores diferenciar sus actions permitiendo personalizar el color de fondo, color principal de las cards, tipografía, tipos de bordes de las tarjetas e imagen de fondo, en este caso no se mostraría el color de fondo.

Last seen tag

Para ayudar a fortalecer el contexto de la conversación, Google Assistant ha introducido un tag dentro de la información de usuario que ayudarará a los desarrolladores a retomar la conversación donde la dejaron.

En Aura ya hemos iniciado la investigación para añadir algunos de estos componentes, aunque concretamente en Brasil ya hemos usado la personalización de temas para nuestra app en Google Assistant, y es bastante útil para diferenciar tu app.

Talk to me

— Adi Mazor Kario (https://twitter.com/AdiMazorKario)

Aquí, la ponente, nos introdujo, desde el punto de vista de Proucto y UX, el diseño de conversación. Conociendo el auge de los interfaces con reconocimiento de voz y las búsquedas en internet por voz es un aspecto que debemos empezar a cuidar.
Fue una charla muy interesante porque ponía el foco en lo que el proyecto Aura, estamos mejorando. Estos nuevos términos están empezando a propagarse y nos gustó ver que dirección llevan otras empresas y poder comparar.

Todos los implicados en el mundo de los asistentes nos hacemos la pregunta “¿Cómo será el futuro?”, y Adi nos ofreció una serie de puntos para ayudarnos a respondernos.

• Las conversaciones serán sin fricciones y más naturales.
• Los asistentes serán más humanos.
• Conocerán tu personalidad.
• Comunicarán con un carácter.
• Reaccionarán a tus emociones.

Para llegar a este idílico futuro, Adi, comentó que para una conversación la vista no funciona igual que el oido. Hay que preparar la conversación sabiendo que lo primero e importante es la interacción vocal.

Y nos propuso el siguiente esquema de trabajo:

1. El diseño de la conversación. Analiza los requirimientos: identifica a tus usuarios, los casos de uso clave y crea un personaje para tu asistente. Haz un boceto rápido de la conversación, de solo una parte la consideres principal. Ahora piensa si este boceto escalaría.
2. La conversación es lo primero. Empieza como si fuera el guión de una película. Imagina como fluiría tu conversación ideal y haz un mapa de la conversación con las posibles interacciones.
3. Happy Path / Error path. Cada caso de uso tiene que tener definido el caso de exito y el caso de error en la conversación. Es importante que no olvidemos esto. En muchos casos el tratamiento de errores caen en el olvido, y es algo que desconcierta mucho al usuario cuando sucede.
4. Repasa los principios para crear una conversación. Respeta los turnos de palabra. Respeta el principio de cooperación entre tu asistente y el usuario. Asegurate que tu asistente sabe tejer la conversación, contextualizar, contempla las variaciones del lenguaje y es capaz de enmendar los errores que pueda cometer.
5. Validar la conversación. Utiliza algunas herramientas o técnicas para validar una conversación, como, la lectura en voz alta. Es constructivo escuchar el punto de vista de personas que no estén relacionadas con el proyecto. Nuestras ideas ya están viciadas por el contexto. Si es posible, pruébalo ante usuarios regulares de asistentes virtuales.
6. Apoya tu VUI con GUI. No lo hagas al revés. Prueba primero la conversación en la experiencia solo de voz, y luego añade el soporte visual.

Para finalizar, Itera. Necesitamos hacer este recorrido tantas veces como sea necesario, hasta que veamos limadas todas las aristas de nuestra experiencia.

Zero to App: Building for the Google Assistant Using Dialogflow and Firebase

— Aygul Zagidullina (https://twitter.com/aygul)
— Kaan Mamikoglu (http://twitter.com/kaanmamikoglu)

En esta sesión Aygul y Kaan, que eran parte del staff que organizaba el evento, nos explicaron como mezclar Actions on Google, Dialogflow y Firebase, todas ellas tecnologías de Google para crear una experiencia completa dentro del asistente.

Desde Aura seguimos con interés estas tecnologías y actualmente las usamos para prototipar pequeños proyectos. Así que, la charla no nos pilló por sorpresa.
Aygul, se centró en la parte de crear la app con Dialogflow. Nos contó los consejos para sacar el mayor partido a esta herramienta y así apoyar la experiencia de Actions on Google.
Una de las partes más destacadas es saber como preguntar por información al usuario. Por ejemplo pedir permiso para activar la localización.

Preguntar por información de usuario.

Nos enseño las mejoras que Actions on Google ha introducido en account linking, configurable con dos modalidades:

• Para Multiplataforma Google Sign in + OAuth linking.
• Para Assistant solamante Google Sign in.

Kaan, expandió la experiencia que tenía Aygul usando 2 herramientas de Google:
1. Cloud Firestore. Una base de datos en Cloud que ofrece: sincronización, resolución de conflictos, uso offline, una estructura de datos flexible y escala automáticamente. La herrmienta perfecta para almacenar datos multi usuario con flexibilidad.

2. Cloud Storage. Es una base de datos en Cloud que ofrece comparativamente con lo anterior: robustez, seguridad y escalabilidad. Destinada para guardar información más relevante o que necesite más seguridad.
De forma que nos ofrecieron un proyecto con Dialogflow extendiendo las capacidades y le dieron potencial para crecer con Firebase.

Building conversational interfaces for Google Assistant

— Martin Hawksey (https://twitter.com/mhawksey)

En su tiempo, Martin, nos habló de como combinar Google App Scripts y Dialogflow para hacer un bot en Google Hangouts.
Sí, Google Hangouts ofrece una solución donde sus bots pueden responder desde acciones en Google App scripts.
Los Google App scripts son scrips que permiten hacer operaciones sencillas sobre las Apps de Google como mail, drive, calendar, docs, slides en pequeñas funciones de un lenguaje parecido a javascript y ejecutadas en Google Cloud.

Así que la idea fue ver cómo Martin construyó el bot desde Google Hangouts, cómo el bot atiende a las respuestas desde Google App Scripts o desde Dialogflow cuando sea requerido.

Para poder disponer de estas operaciones necesitamos hacer una pequeña configuración:

• Generar un service account key en Dialogflow.
• Subir ese Json a google drive de forma que podamos enlazarlo.
• Añadir la referencia a ese fichero en el proyecto de Google App script

Aquí puedes ver el código y explicación detallada de lo que nos contó Martin.

Esta charla fue quizás la menos relacionada con lo que hacemos en Aura pero aprendimos nuevas ideas como los bots de Google Hangout.

Learning to play the guitar with Actions on Google

— Joe Birch (https://twitter.com/hitherejoe)

Para seguir con la tarde, Joe nos presentó un proyecto personal en el que ha completado una app dentro de Actions on Google, usando Dialogflow y Firebase.
Parece que las herramientas empiezan a ser comunes en las presentaciones. Todos los ponentes excepto uno se han apoyado en Dialogflow y muchos también se apoyan en Firebase para almacenamiento de datos. Joe usó Actions SDK con Dialogflow y hosteó su bot en una función de Firebase. El ecosistema que Google está abriendo para los desarrolladores es bastante intuitivo y ofrece muchas posibilidades para crear una app.

Para hacer prototipos rápidos, tanto Dialogflow y Firebase son herramientas perfectas. Se añaden facilmente, tienen una documentación sencilla y tienen un buen plan gratuito. En el equipo de prototipos de Aura es uno de nuestros combos favoritos para las demos.

Tanto Adi, antiormente, como Joe insistieron en la idea de crear primero la experiencia de voz y luego darle soporte visual para reforzar la experiencia. No al contrario.

La app que construyó Joe es una app donde preguntas por un acorde de guitarra y te dice como tienes que colocar la mano. De forma que en poco tiempo puedes empezar a tocar la guitarra.

Building assistive apps with App Actions

— Elaine Dias Batista (https://twitter.com/elainedbatista)

Eleaine, que es Google Developer Expert de Android, empezó describiendo el recorrido que ha seguido Android hasta llegar al concepto de App Actions. Como en 2017 empezaron con las filas de predicciones de apps con una tasas del 60% de predicción, y como en 2018 se fraguó el concepto de App Actions https://developer.android.com/guide/actions/.

La idea que Android está lanzando es asociar la app que estamos corriendo a un intent de forma que sea visible en multiples superficies. Se pueden asociar las apps con intents que ofrece Android o crear intents personalizados.

Esto todavía no ha sido lanzado en Android, aunque la idea es muy interesante para aquellos que tengan una app en Android y quieran continuar la experiencia desde Google Assistant.

La segunda derivada sería extender la experiencia de de las App Actions a Conversational Actions, que serían las acciones conversacionales lanzadas desde un asistente, Google Assistant en nuestro caso.
De forma que, como Elaine sugería, fuera posible mapear Intents de Google Assistant a Built-in intents de Android.

Para Aura esto sería una buena forma de relacionar las apps de Android donde tenemos presencia, con intents de la conversación que pueda tener Aura en sus apps de Google Assistant. Ganando así recurrencia de usuarios y mejor accesibilidad

Beyond Smart Speakers: Get Your Google Assistant Apps Ready for Smart Displays

— Aygul Zagidullina (https://twitter.com/aygul)

Última de la charlas, de nuevo la organizadora Aygul nos cuenta buenas prácticas para implementar nuestra app dentro de Actions on Google y cómo hacer nuestra app más visible para los usuarios. Lo importante de manejar las invocaciones explícitas e implícitas.
Fue el perfecto resumen de muchas cosas que vimos a lo largo del día.

Por último nos reveló la noticia sobre el último dispositivo, todavía no disponible en España, un altavoz con pantalla llamado Google Home Hub.
Como curiosidad, en comparación con nuestro Movistar Home, no tiene cámara porque parece estar destinado a conquistar el dormitorio.

Aprendizajes

En Aura estamos siguiendo un camino parecido a lo que hacen compañias como Google, que tienen mucho más presupuesto y con más gente involucrada en la resolución de los problemas.
En cuanto a talento, esfuerzo e ideas estamos bien situados.

Gracias por leerlo.

The post Aura Prototipos en GDG London first appeared on Planeta Chatbot.

Imaginemos unas cuantas conversaciones que normalmente puedan mantener personas con asistentes virtuales o bots.

Una señorita llamada Clara que quiere saber la predicción meteorológica.

—Clara: Ok ROBOT, ¿Qué sabes hacer?

—ROBOT: ¡Hola! ¿Cómo te llamas?

— Clara: Ok ROBOT, Clara.

—ROBOT: ¿Qué puedo hacer por ti Clara?

—Clara: Ok ROBOT, dime el tiempo en Ronda de la comunicación

La señorita Clara vuelve en un rato.

—Clara: Ok ROBOT, dime el tiempo hará el fin de semana en Segovia.

—ROBOT: ¡Hola! ¿Cómo te llamas?

Clara no entiende a qué viene esta pregunta de nuevo.

Ahora Clara quiere consultar su balance en el banco.

—Clara: Ok ROBOT, quiero ver mi balance de la cuenta en BBVA.

—ROBOT: ¡Hola Clara! Cuanto tiempo. Para realizar esta operación necesitas añadir tu cuenta del banco.

Clara añade la cuenta del banco y consigue acceder a sus datos con su pin.

Clara vuelve en 5 minutos y quiere consultar un gasto concreto

—Clara: Ok ROBOT, quiero ver mis últimos gastos en BBVA.

—ROBOT: De acuerdo Clara, introduce tu pin de nuevo

— Clara: Lo he metido hace 5 minutos

La hija de Clara, llamada Lucía de 16 años, intenta acceder a la agenda de su madre Clara, sin permiso, para ponerle un meeting con su jefe el viernes por la tarde y hacer una fiesta en casa.

— Lucía: Ok, ROBOT, quiero añadir un evento el viernes

—ROBOT: De acuerdo Clara, dime un título

— Lucía: Revisión de salario con Agustín (el jefe)

—ROBOT: Dime la hora y duración

— Lucía: A las 17.00 por 2 horas. (Así puedo traer a mis amigas a casa)

—ROBOT: Evento añadido de 17.00 a 19.00 para el Viernes, que pases buena tarde Clara.

Cuando Clara el viernes por la tarde descubre todo, quiere … beber.

En estos ejemplos anteriores vemos las dificultades a las que se enfrenta un usuario al hablar con un Bot. A nivel contexto, acceso y suplantación de entidad.

¿Por qué la inteligencia artificial no es más inteligente?

¿Podría un bot identificarnos sin necesidad de decirle una y otra vez quienes somos?

Qué es una biometría

Una biometría es una prueba basada en los patrones físicos de las personas. Con esta prueba podemos diferenciar un usuario de otro o perfilar al usuario, por ejemplo, por su edad, sexo o estado de ánimo entre otras características.

Operaciones posibles

Podemos clasificar las pruebas biométricas en función del uso de sus resultados:

• Perfilado: Obtener las cualidades de un usuario edad, sexo o estado de ánimo.
• Verificación: Decir si un usuario es quién dice ser.
• Identificación: Dado un grupo de usuarios, comprobar que el usuario es miembro del grupo.

Atendiendo al tipo de prueba elegida y el medio usado podemos establecer:

• De las biometrías más conocidas podría ser la huella dactilar necesitandose un soporte físico para hacer la prueba.
• Usando el soporte audio podríamos tener una biometría vocal.
• Usando la imagen podríamos tener la biometría facial o selfie.
• Con audio e imagen tendríamos una biometría de video.
• Usando la captura de la retina tendríamos la biometría de retina. (De la que se ha pensado que puede provocar daños físicos)

Para qué nos sirve esto

Tenemos una conversación con usuarios que manejar. Cuanta más información “legal” de la que dispongamos del usuario “con su consentimiento” mejor para la conversación.

Si el usuario es mujer u hombre, se llama Juan o Rosa, es niño o adulto, está contento o enfadado, es algo que podemos usar para hacer más humana nuestra conversación.

Obteniendo estos datos de la persona tenemos más información sobre el contexto de la conversación. Podríamos añadirlos a nuestro puzle para componer un mensaje de vuelta correspondiente al usuario.

Analizando los tipos de contextos que podemos apropiar a un Bot tendríamos algo así:

• Contexto de Usuario: Si el usuario está logado en nuestros sistemas tenemos información suya relevante para la conversación. O si el bot se ejecuta en alguna App que extraiga información del sistema donde está siendo ejecutada.
• Contexto de Conversación: Referente a la parte linguistica de la conversación. Dominio actual, entidades e intención.
• Contexto Histórico: Basado en las converaciones almacenadas del usuario.
• Contexto Inferido: Relacionado con lo que ocurre alrededor de la conversación. Día de la semana, sexo, edad y estado ánimo del usuario.

Buscamos dar respuestas mejores, más contextualizadas y más empáticas. En el caso de las biometrías podemos enriquecer sustancialmente el contexto inferido.

Cómo funciona una biometría

Para las biometrías más comunes, huella dactilar, reconocimiento facial o de voz, el proceso sería diferente dependiendo si queremos perfilar, identificar o verificar:

Pasos para una biometría

Para un perfilado de usuario prescindimos del entrenamiento puesto que no necesitamos la distinción de una persona y otra, solo sus características personales.

Estos pasos implican que las pruebas de identificación y verificación puedan ser percibidas como más invasivas que las de perfilado, ya que roban la atención del usuario más tiempo. Incluso puede ser necesario que el usuario necesite estar presente delante del dispositivo que nos realiza la prueba. Este sería el caso de la biometría facial o de vídeo.

Como incluyo esto en mi bot

Lo normal sería acomodar, la conversación y pantallas, para que la persona que está hablando con el bot realizara los entrenamientos y hacer la prueba indicando que estamos verificando o identificando la identidad de la persona.

Identificar a las personas mediante un flujo de conversación está bien. Sin embargo, esto puede provocar cierto rechazo por ser tedioso o no ser necesario en el momento de la conversación que lo incluimos.

Pero podemos quizás añadir algo de azúcar al jarabe. Lo ideal sería intentar ser lo menos invasivo con las pruebas posible. ¿Necesitamos preparar siempre a la persona para que realice la prueba? Dependerá del tipo de prueba.

En el caso de perfilar al usuario es más sencillo, ya que los entrenamientos no son necesarios.

Como podemos mejorar estos procesos

Esta mejora se asocia a crear una estrategia adecuada para cada caso concreto. No obstante dependerá de algunas variables. Aquí quiero referenciar algunas de las variables más importantes que he identificado.

Variables para una estrategia.

Teniendo en cuenta estas variables también me gustaría dar algunas ideas que pueden resultar intersantes para enfrentarse al problema.

Pruebas asíncronas

No todas las pruebas tienen que hacerse en mitad de la conversación. Podríamos hacer que identificara al usuario, por voz, en un momento concreto de la conversación en la que al usuario le cause menos problemas. Por ejemplo, al iniciar una conversación podemos capturar la voz del usuario en cualquier frase y realizar un perfilado sin necesidad de entrometer la biometría en la conversación.

Pruebas múltiples combinadas

A menudo la identificación y verificación pueden ser cruciales en nuestro sistema. Para ello, en lugar de jugar a una sola carta podemos combinar varias biometrías a distinto tiempo. Por ejemplo, biometría de voz y facial aplicada en distintos momentos de la conversación de forma que si tenemos que autorizar un pago la verificación sea más segura.

Biometrías grupales y perfilado

Si tu bot tiene alguna funcionalidad que vaya dirigida a grupos de personas, o que pueda ser usado, en la misma conversación, por varias personas indistintamente, donde quizás la seguridad no sea un factor relevante, pero quieras añadir un plus a la conversación, podrías apoyarte en esta idea. Imagina que tu bot es recomendador de restaurantes para grupos. Podrías capturar una foto del grupo y con un servicio que estraiga el sexo de los componentes, su edad y su estado de ánimo podrías realizar una recomendación más precisa.

Suplantación (spoofing con imágenes y voces)

Si tu bot accede a sistemas críticos donde la seguridad es algo vital. Y vas a implementar o contratar un servicio de reconocimiento es importante fijarse en que detecte la suplantación de identidad. Por ejemplo, en el caso de las imágenes. Si el sistema en el que se apoya nuestro bot para identificarnos no tuviera detección de spoofing podríamos, con la fotografía de un usuario autorizado, acceder a los sistemas críticos.

Otras pruebas interesantes

A parte de las pruebas biométricas ya mencionadas me gustaría mencionar algunas otras biometrías quizás más futuristas pero interesantes.

• Identificación con la palma de la mano. Con las venas del dedo y de la palma de la mano ya que el recorrido de las venas es único. https://whatis.techtarget.com/definition/palm-vein-recognition
• Usar la forma de las orejas. La forma que tienen nuestras orejas es única. Podríamos poner un detector de orejas en los teléfonos cuando recibimos una llamada. https://www.newscientist.com/article/dn7672-ear-biometrics-may-beat-face-recognition/
• Olor corporal. Cada uno tenemos olores diferentes. Han desarrollado una una tecnología para oler esos matices de las personas de forma que puedan identificarnos. https://www.popsci.com/technology/article/2010-04/army-wants-smelling-sensors-can-id-potential-perps-afar
• Análisis de comportamiento y detección de presencia. Se pueden diferenciar las personas según la forma de caminar o de moverse por casa. A través de ondas electromagnéticas que miden patrones físicos del cuerpo. https://www.aerial.ai/services/
• Análisis de comportamiento en computadoras. Nuestra forma de teclear, hacer click y mover del ratón parece que es única. Se están haciendo mediciones para identificar a personas en función de estos parámetros. https://www.typingdna.com/

Conclusión

Parece que la inclusión de biometrías en nuestras vidas puede ser algo futurista. Aunque en realidad se están aplicando desde hace mucho tiempo. Ahora están accesibles para ser usadas por nuestros Bots simplemente hay que entender dónde, cuándo y cómo incluirlas.

Espero que te haya gustado.

Gracias por leerlo.

Gracias a Daniel Coloma, Marta Pérez García y Julia Llanos Alonso.

The post Bots y biometría first appeared on Planeta Chatbot.

Esta vez me gustaría mostrar como validamos nuestras hipótesis y sacamos conclusiones para mirar hacia delante en nuestros proyectos.

A. Hipótesis inicial

Hoy, he decidido usar las Actions de Google para construir una app dentro de Google Assistant. Usando un servicio cognitivos de Microsoft AI llamado LUIS (Language Understanding) en el lugar donde Google ofrece Dialogflow, herramienta habitual en estos casos.

Las 2 ideas técnicas que me gustaría validar son:

1- ¿Es posible crear una Action de Google reemplazando Dialogflow por otro servicio NLP (Natural Language Processor)?

2- ¿Sería posible un servicio NLP común y portable entre plataformas de manera que proporcione estabilidad y homogeneidad a nuestras respuestas?

B. Objetivos — ¿Qué queremos aprender?

Me gustaría adquirir varios aprendizajes en este prototipo.

Primero, conseguir un conocimiento más profundo de las Actions de Google y ver sus límites. También explorar un servicio NLP alternativo para la app con las Actions de Google que queremos desarrollar.

Aunque lo más interesante será ajustar una tecnología como el servicio de NLP, LUIS, sobre un bot que no pertenece a su ecosistema natural.

C. Implementación — ¿Qué hemos hecho?

Voy a construir un pequeño prototipo para ayudarnos con nuestras hipótesis. No será algo perfecto o terminado pero el objectivo tampoco es ese, sino validar nuestras ideas iniciales.

Nota: Saltaré la creación y publicación de una Action de Google al no ser el propósito de este post. Para profundizar sobre esto recomiendo seguir el siguiente enlace https://developers.google.com/actions/sdk/

El lenguaje elegido es Javascript (Nodejs), donde Google libreró un módulo muy útil https://github.com/actions-on-google/actions-on-google-nodejs que va a sostener nuestra implementación.

Lo primero, he creado 2 grupos donde recogemos las peticiones o consultas que tienen un significado común o parecido, conocidos como intents. Uno es el responsable de arrancar la app y se llama action.intent.MAIN. Y el otro recogerá cualquier otra consulta general y se llama action.intent.TEXT.

{
  "actions": [
    {
      "description": "Default Welcome Intent",
      "name": "MAIN",
      "fulfillment": {
        "conversationName": "myWebhook"
      },
      "intent": {
        "name": "actions.intent.MAIN"
      }
    },
    {
      "description": "text intent",
      "name": "TEXT",
      "fulfillment": {
        "conversationName": "myWebhook"
      },
      "intent": {
        "name": "actions.intent.TEXT"
      }
    }
  ],
  "conversations": {
    "myWebhook": {
      "name": "myWebhook",
      "url": "<YOUR ACTION URL>"
    }
  },
  "locale": "en"
}

Paralelamente he creado una app de LUIS, el servicio NLP de Microsoft AI, con 3 intents. El intent None, que es creado por defecto en LUIS, y recoge todas las peticiones que no entran en ninguno de los otros intents definidos en la app. Y otros 2 intents más llamados: name y help.

Dentro de cada intent he añadido unas pocas frases, conocido como utterances. Para testear la app de LUIS es necesario entrenar la app con las frases añadidas. De esta forma se compone el modelo que va a regir nuestas consultas.

Una vez terminado de testear la app de LUIS para poder publicarla necesitamos crear un servicio cognitivo dentro de Azure. Al crear este servicio obtendremos una clave. Después habilitaremos la clave dentro de LUIS para que así nos proporcione una URL nueva para esta clave recien añadida. Ahora si, podremos publicar nuestra app de LUIS y usar esta URL para las peticiones dentro de la Action de Google.

help intent

name intent

Usando el ejemplo de la documentación https://developers.google.com/actions/sdk/fulfillment y añadiendo la petición a la URL del NLP LUIS, obtendremos el intent de la petición y podremos adaptar la respuesta de la Action de Google.

const {actionssdk} = require('actions-on-google');
const express = require('express');
const bodyParser = require('body-parser');
const rp = require('request-promise');

// get this url from publish section in luis.ai
const LUIS_URL = '<YOUR LUIS URL>';

const app = actionssdk({debug: true});

app.intent('actions.intent.MAIN', (conv) => {
  conv.ask('Hi!');
});

app.intent('actions.intent.TEXT', (conv, input) => {
  const url = `${LUIS_URL}${input}`;
  
  return rp({
    url,
    json: true,
  })
  .then((res) => {
    // create a function by intent detected by LUIS NLP
    const actionMap = {
      name: nameIntent,
      help: helpIntent,
    };
    // check that LUIS response with a valid intent
    if (res.topScoringIntent && res.topScoringIntent.intent && res.topScoringIntent.intent !== 'None') {
      
      // Map intents to functions for different responses
      actionMap[res['topScoringIntent']['intent']](conv);
      
    } else {      
      conv.ask('Sorry, I don\'t understand what you mean. Please try to ask for help or about my name.');
    }
  })
  .catch((e) => {
    console.log('Error =>', e);
  });
});

function nameIntent(conv) {
  conv.ask('My name is Lola test and I like talking.');
} 

function helpIntent(conv) {
  conv.ask('I like when you can ask for my name.');
}

express().use(bodyParser.json(), app).listen(8888)

D. Conclusiones — ¿Qué hemos aprendido?

Dialogflow es un bot en si mismo que actua ante determinadas peticiones vinculadas a los intents definidos en su configuración. Ofreciendo respuestas propias para esa petición determinada. También podría detectar el intent y delegar la respuesta a otro webhook que ejecutase la respuesta llamado fulfilment. En definitiva Dialogflow funciona ante una petición con un texto determinado devolviendo otro texto.

Sin embargo LUIS de Microsoft se dedica a detectar el intent sobre un texto específico. Esto hace a LUIS de Microsoft AI potente y versatil. Es rápido, al no tener que preparar la respuestas, y se puede combinar con otros servicios.

Intenté combinar estas 2 tecnologías por el mero experimento, pero en realidad hay una razón más poderosa detrás. Imagina que tuviera que crear una skill de amazon, app de Cortana o app para Actions on Google. ¿No sería más sencillo usar el mismo reconocedor de intents siempre? De esta forma solo lo programaríamos nuestro NLP una única vez y estaría disponible para todas las plataformas. Sería homogeneo en sus interpretaciones. Además seríamos más rápidos implementando nuevas plataformas y modificándolo según nuestras necesidades.

Espero que te haya gustado.

Gracias por leerlo.

The post Dónde coinciden las Actions de Google con LUIS de Microsoft AI first appeared on Planeta Chatbot.

Quizás para los bots antiguos que todavía no hayas actualizado veas algo roto en la web, aquí veremos un motivo.

1. Comienzo

La forma de crear un bot ha cambiado un poco. Ahora Microsoft nos redirige a Azure donde necesitamos una cuenta con crédito para crear un Bot Service. En mi caso recibí un crédito de 170 €. No está nada mal para empezar.

redirección a Azure

Una vez dentro de Azure nos muestra 3 modalidades de bots para elegir:

– Web app bot
– Bot channel registration
– Functions bot

tipos de Bot Service

Veamos un caso teórico y uno práctico de dos tipos diferentes de servicio de forma que nos permita conocer las nuevas funcionalidades más profundamente.

2. La teória

a. Web app bot

Esta es la clásica implementación de un bot para un web chat. Muestra un formulario con plantillas en Node.js o C# a escoger, para implementar el servidor incluyendo las diferentes modalidades de bot según necesidad.
En este caso hemos escogido generar un bot con un servicio cognitivo llamado LUIS (Language Understanding System) de Microsoft. Esto nos permitirá tener un chatbot con reconocimiento de intenciones.

Una vez generado nos solicita el nombre del bot y el nombre de la App web que va a crear para usar el bot.

b. Hosting

Ahora en la configuración del bot la única opción para alojar el bot es Azure. Al usar la plantilla de código Azure ya genera un espacio donde se aloja el proyecto. Anteriormente podías alojarlo en otro servidor y configurarlo en los settings del bot con una url HTTPS.

c. Código

El código que se ha alojado en Azure está disponible de tres formas en la plataforma:

• editando el código en linea
• manualmente descargando un zip y volviéndolo a subir
• configurando la implementación continua bajando un zip, subiéndolo a un repositorio en uno de los proveedores soportados y cada vez que subas código nuevo en la rama configurada se desplegará una nueva versión.

formas de trabajar con el código

Si queremos usar la implementación continua, tenemos varios proveedores que nos ayudarán a desplegar una nueva versión del código cada vez que necesitemos.

d. Registro de canales

Para dar de alta un canal lo tendrás que hacer desde Azure también. Los canales posibles no han variado en relación a los que había antes, es más, parece que hayan usado las mismas vistas aplicando un capa de CSS diferente.

Conectar canales a tu bot

Este ligero cambio hace que en Azure la experiencia sea correcta pero en los bots antiguos se vea desparejo, como decíamos, parece que hayan reutilizado algo que no ha quedado del todo cuadrado.

CSS para bot antiguos

e. Testear tu bot

Las pruebas las han dejado prácticamente intactas solo han movido a las vistas a Azure. De forma que ahora tenemos casi todo a mano por si hay que hacer cambios.

testing

f. LUIS

Al haber elegido un bot que reconoce las intenciones Azure ha creado en www.luis.ai una instancia nueva de una aplicación de LUIS que enlaza con el bot y nos proporciona el servicio.

popiggbot2-b86b creada para este ejemplo

No vemos muy claro porque la app de LUIS está en www.luis.ai que es el dominio para US, y no se ha creado en eu.luis.ai ya que hemos seleccionado al crear el bot en West Europe. Quizás estén revisando esta parte ya que la release está en beta y ha sido muy reciente.

3. Caso práctico

Para el caso práctico hemos elegido Functions Bot Service de forma que nos permite despreocuparnos de configurar Web apps o servidores. La function de Azure se invocará cuando se detecte la llamada al bot y ejecutará nuestro código. Esta implementación está muy lograda porque al crear el bot automágicamente crea una function que al ejecutarse arranca el bot.

El código de este bot es el más sencillo que hemos encontrado en la documentación de Microsoft.

Añadiendo nuestras modificaciones al código y habilitando los despliegues automáticos, podemos saber que versión hay desplegada.

4. Cambios y mejoras

a. Pruebas

Para hacer pruebas sobre el server, anteriormente, necesitábamos usar un dominio https que podríamos obtener con certificado sobre un dominio propio, o para prototipos más rápidos mediante tunneling con herramientas como ngrok. Ahora no es necesario, podemos probar nuestro bot una vez desplegado en Azure ya que nos proporciona un dominio.

b. Despliegues automáticos

Desde mi punto de vista esta funcionalidad es la más relevante. Puedes desplegar tu bot desde distintos proveedores populares metiendo tu código en un repositorio visible por la plataforma. Esto evita bastante trabajo para proyectos sencillos.

c. Plantillas genéricas por lenguaje

En la nueva versión hay plantillas para que no tengas que hacer casi nada de código o por lo menos haya un ejemplo donde empezar. Es bastante útil para iniciarse. Hasta ahora hay disponible plantillas en Node.js y C#.

d. Edición del código online

También han incluido un editor online de forma que ante alguna urgencia tus cambios tendrían efecto inmediatamente. Puede venir bien para solucionar errores críticos pero sencillos.

e. Hosting

El obligarte a usar su hosting restringe las libertades pero facilita el uso. No lo catalogaría como una mejora pero en ciertos casos añade sencillez a todo el proceso.

5. Conclusiones

Parece que el giro de Microsoft en la parte de la inteligencia artificial ha sido para redondear el producto, afinar la configuración y APIs pero recorta algunas libertades. Espero que con las nuevas funcionalidades los ventajas actuales se vean superadas.

Photo by Max DeRoin from Pexels https://www.pexels.com/photo/keyboard-green-51415/

Espero que te haya gustado, si así es, puedes compartirlo.

Gracias por leer.

The post Cómo crear bots con la última actualización de Microsoft first appeared on Planeta Chatbot.

Recientemente estaba en una charla y el ponente habló de las Olas Tecnológicas. Ahora ya puedes pensar cuantas de ellas has vivido a lo largo de tu experiencia profesional.

Hace unos meses me uní a un equipo nuevo donde construimos prototipos rápidos para probar conceptos y aprender para aplicarlo a un producto. A veces acabamos testeando estos conceptos en dispositivos para tener un feeling más exacto de como será la experiencia final.

La Ola Tecnológica en que ahora mismo vivimos me atrevo a decir que trata de explotar los términos Inteligencia Artificial y Bots y desde nuestro equipo no queríamos quedarnos atrás. Empezamos a pensar sobre como enganchar esa inteligencia en diversos dispositivos.

Una prueba de concepto simple, flexible y portable que pudiera ser usado para diferentes propósitos con un mínimo de adaptación.

La idead de usar un Procesador de Lenguaje Natural ( NLP ), que pudiera ser llamado via HTTP API desde una aplicación cliente. La idea sería algo así como, el servicio NLP contestaría nuestras peticiones; la aplicación cliente necesitará un reconocedor de voz para el usuario, transformar esa voz a texto y realizar una petición al servicio NLP, que nos responderá y convertiremos esa repuesta a voz.

Este experimento nos permitirá ver como es la interacción de nuestros usuarios mediante voz y tener feedback rápido de nuestros usuarios en aspectos como: problemas en el reconocimiento, ruido en la comunicación, expectativas con esta nueva tecnología y algunos otros más datos relevantes para el equipo.

Veamos las piezas de puzzle en detalle.

1. El servicio NLP

En esta ocasión probaremos DialogFlow, que es un servicio NLP de Google, tiene muchas integraciones disponibles, SDK para muchos lenguajes y agentes ya cargados que nos facilitan la prueba. Se integra especialmente bien con Google Assistant.

Antes de seguir me gustaría revisar algunos conceptos:

• Intent: Es un patrón detectado por el servicio NLP mediante el uso de utterances que son un conjunto de sentencias que definen un modelo de comportamiento. Normalmente esos intents son palabras clave que tu puedes acomodar a tu sistema.
• El servicio NLP define algunos intents y algunas utterances que son usadas por el servicio para responder a nuestras peticiones. El servicio NLP permite peticiones via HTTP API, y eso is lo que necesitamos para la prueba.

Intent Menu

Se pueden añadir nuevos intents.

Intent creation Menu.

Hay una consola en un lateral desde la que puedes testear tus intents y utterances manualmente y siguiendo la documentación se puede encontrar como hacer las peticiones HTTP:

Dialogflow SDKs | Dialogflow

Voice interface is cross-platform. Your agent will understand your users no matter what device you’re using. You design…

dialogflow.com

dialogflow/dialogflow-javascript-client

dialogflow-javascript-client – JavaScript Web SDK for Dialogflow

github.com

2. El Cliente

Como hemos mencionado anteriormente a veces usamos dispositivos para test finales. Ser portable es siempre bueno para construir prototipos que demuestran ciertas hipótesis y React-Native cubre nuestras necesidades. En este caso testearemos sobre una plataforma android por disponibilidad.

Asumimos que has instalado ya react-native-cli y has comenzado un proyecto Android. Si no puedes seguir esta documentación que te muestra los pasos:

Getting Started – React Native

This page will help you install and build your first React Native app. If you already have React Native installed, you…

apply plugin: "com.android.application"

import com.android.build.OutputFile

apply from: "../../node_modules/react-native/react.gradle"

def enableSeparateBuildPerCPUArchitecture = false
def enableProguardInReleaseBuilds = false

android {
    compileSdkVersion 23
    buildToolsVersion "23.0.1"

    defaultConfig {
        applicationId "com.rnauratest"
        minSdkVersion 16
        targetSdkVersion 22
        versionCode 1
        versionName "1.0"
        ndk {
            abiFilters "armeabi-v7a", "x86"
        }
    }
    splits {
        abi {
            reset()
            enable enableSeparateBuildPerCPUArchitecture
            universalApk false  // If true, also generate a universal APK
            include "armeabi-v7a", "x86"
        }
    }
    buildTypes {
        release {
            minifyEnabled enableProguardInReleaseBuilds
            proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro"
        }
    }
    // applicationVariants are e.g. debug, release
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            // For each separate APK per architecture, set a unique version code as described here:
            // http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits
            def versionCodes = ["armeabi-v7a":1, "x86":2]
            def abi = output.getFilter(OutputFile.ABI)
            if (abi != null) {  // null for the universal-debug, universal-release variants
                output.versionCodeOverride =
                        versionCodes.get(abi) * 1048576 + defaultConfig.versionCode
            }
        }
    }
}

dependencies {
    compile project(':react-native-tts')
    compile fileTree(dir: "libs", include: ["*.jar"])
    compile "com.android.support:appcompat-v7:23.0.1"
    compile "com.facebook.react:react-native:+"  // From node_modules
    compile project(':VoiceModule') // Add voice module package
}

// Run this once to be able to run the application with BUCK
// puts all compile dependencies into folder libs for BUCK to use
task copyDownloadableDepsToLibs(type: Copy) {
    from configurations.compile
    into 'libs'
}

rootProject.name = 'popiggTest'
include ':react-native-tts'
project(':react-native-tts').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-tts/android')

include ':VoiceModule', ':app'
project(':VoiceModule').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-android-voice')

package com.popiggtest;

import android.app.Application;

import com.facebook.react.ReactApplication;
import com.facebook.react.ReactNativeHost;
import com.facebook.react.ReactPackage;
import com.facebook.react.shell.MainReactPackage;
import com.facebook.soloader.SoLoader;
import com.wmjmc.reactspeech.VoicePackage; // voice recognition package
import net.no_mad.tts.TextToSpeechPackage; // test to speech package

import java.util.Arrays;
import java.util.List;

public class MainApplication extends Application implements ReactApplication {

  private final ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {
    @Override
    public boolean getUseDeveloperSupport() {
      return BuildConfig.DEBUG;
    }

    @Override
    protected List<ReactPackage> getPackages() {
      return Arrays.<ReactPackage>asList(
          new MainReactPackage(),
          new VoicePackage(), // voice recognition package
          new TextToSpeechPackage() // test to speech package

      );
    }
  };

  @Override
  public ReactNativeHost getReactNativeHost() {
    return mReactNativeHost;
  }

  @Override
  public void onCreate() {
    super.onCreate();
    SoLoader.init(this, /* native exopackage */ false);
  }
}

3. Último paso

Una vez que todos los módulos están listos veamos como integrarlo dentro de nuestra app:

Con no muchas líneas hemos construido nuestro propio asistente de voz en Android. Pero no todo funciona siempre a la primera.

4. Problemas potenciales y puntos fuertes

Ahora que acabamos de construir nuestro asistente en Android, flexible y ajustable en términos de intents y respuestas, con una interfaz es tiempo de la revisión.

• Puede ser que la cache juegue en tu contra cuando haces debug de tu aplicación. Las dependencias externas se pueden complicar sumado a la caché de NPM. Atención a esto, borra y reinstala las dependencias, eso suele funcionar.
• DialogFlow SDK: Finalmente decidimos realizar las peticiones usando Fetch de React-Native porque el SDK no funcionaba fácilmente. La documentación no es la mejor para este caso puntual pero la parte que hay de HTML + JS está muy bien para nuestra demo.
• El punto clave es el debugger remoto de React-Native. Con un simple console.log, console.warn y console.error, se pueden trazar las acciones y lo que sucede entre bambalinas en tu aplicación con el navegador. Por ejemplo en esta demo es importante saber como van las peticiones y respuestas en la aplicación. También como se está reconociendo la voz.

React-Native remote debug

• Dialogflow es impresionante, tiene una interfaz sencilla, es fácil de usar, está disponible en varios lenguages y es suficientemente flexible para extender las respuestas del servicio NLP con tus propias respuestas.

Si te ha gustado y quieres ver un poco más profundo como está montado aquí está el código de la demo.

popigg/DialogflowReactNative

DialogflowReactNative – Your voice assistant in ReactNative & DialogFlow

github.com

Espero que te guste, si así es, puedes compartirlo.

Gracias por leerlo.

The post Crea tu asistente de voz en ReactNative y Dialogflow first appeared on Planeta Chatbot.