Para garantizar que tu asistente de voz funcione en todas las situaciones, las pruebas son un factor crucial. Las herramientas, como Botium Box, permiten a las empresas implementar una estrategia de prueba holística para los asistentes de voz en todos los niveles de la pila de componentes. Este artículo se centra en la parte del reconocimiento de voz, los archivos de transcripción y la verificación de la tasa de errores de palabras.

Pruebas continuas de reconocimiento de voz

Los grandes proveedores de servicios en la nube Google, Amazon, Microsoft e IBM brindan servicios de voz de alta calidad con las mejores tasas de reconocimiento del mercado. Pero incluso con esos proveedores de la nube, algunos permiten agregar sus propias optimizaciones al cargar datos de capacitación adicionales; esto se usa a menudo para mejorar las tasas de reconocimiento para dominios específicos de vocabulario (sectores de salud, educación, etc). Aparte de los grandes proveedores de servicios en la nube, también hay una serie de paquetes de software gratuitos disponibles como Kaldi (para reconocimiento de voz) o MaryTTS (para síntesis de voz), que las empresas instalan, capacitan y operan en su propia infraestructura.

Las pruebas continuas de reconocimiento de voz tienen la mayoría de los beneficios para los asistentes de voz que utilizan un servicio de voz en la nube optimizado o modelos de lenguaje completamente autodidactas. Como parte de una estrategia de prueba de asistente de voz, la calidad del reconocimiento de voz debe verificarse continuamente, como todos los demás componentes de la pila.

Pruebas para escenarios de la vida real

Los asistentes de voz también deberían funcionar a la perfección, incluso en el caso de un sonido no perfectamente grabado. La intención no es probar el comportamiento del sistema en situaciones separadas, sino simular un uso realista al que se enfrentará el asistente de voz. Una respuesta estable en diferentes circunstancias se convierte en una cuestión de calidad y consistencia.

No solo usamos estas tecnologías en un ambiente completamente silencioso, sino también cuando nuestros hijos están jugando (lo que suele ir acompañado de gritos) o simplemente pasando por un túnel. Siempre tienen que responder en consecuencia en todas las circunstancias, incluso si los hablantes tienen un tono de voz, acento o tono diferente. El rendimiento en tales escenarios de la vida real diferenciará a su asistente de voz de los chatbots promedio con poca comprensión.

Humanificación: Añadir Ruido

En Botium Box, el término Humanificación se utiliza para describir la aplicación de algoritmos para introducir ruido en los datos de prueba. Para las pruebas basadas en texto, esto significa considerar patrones de comportamiento humano típicos y fallas humanas típicas como errores tipográficos, falta de distinción entre mayúsculas y minúsculas, espacios en blanco (o falta de espacios en blanco), uso de emojis y otros. Para las pruebas basadas en la voz, el ruido puede ser realmente ruido, como agregar un poco de ruido de fondo específico del entorno.

Canalización de efectos de voz

En la lista de Efectos de voz en Botium Box, puedes configurar tu pipeline de capas de ruido adicionales para aplicar a un archivo de audio. Hay varios efectos de audio comunes disponibles para simular entornos de la vida real:

• Agregar ruido de fondo
• Hacer que suene como una llamada telefónica GSM de bajo ancho de banda
• Simular una línea telefónica levemente interrumpida agregando descansos

Bonificación: Verifica la tasa de errores de palabras

En muchos casos, es posible que no estés realmente interesado en la transcripción exacta del archivo de audio, sino más bien si se cumplen ciertos criterios de calidad sobre la transcripción; aquí es donde entra en juego la tasa de error de palabras. Es una medida de cuántas palabras en una sola transcripción se han reconocido correctamente: para una transcripción perfecta que coincida completamente con la etiqueta, es 0 y el valor está entre 0 y 1. Dependiendo de tus requisitos, puedes considerar un error de palabra tasa de 0.1 (una transcripción incorrecta de 10 palabras)como correcta. Botium Box puede verificar la tasa de error de palabras en un solo nivel de expresión en lugar de la transcripción exacta.

Conclusión

Una vez que tu asistente esté implementado y expuesto al mundo real, lo más probable es que procese las entradas del usuario que no ha visto en los datos de entrenamiento. La prueba continua de reconocimiento de voz es el primer paso para determinar si tu asistente de voz entiende al usuario correctamente, ya que esa es la condición previa para dar una respuesta precisa y completar la tarea en cuestión.

The post Cómo desarrollar pruebas continuas de reconocimiento de voz first appeared on Planeta Chatbot.

A medida que las marcas continúan considerando cómo van a aprovechar este nuevo canal, necesitan aprender algunos métodos nuevos para brindar estabilidad y una buena y constante calidad en los servicios que ofrecen. En este artículo, empoderamos a tu asistente de voz para que su importancia crezca gracias a proporcionar una experiencia de calidad. 

¿Qué es una «aplicación de voz»?

No tenemos que hacerlo más complicado que esto: una «aplicación de voz» es una aplicación con una interfaz de usuario que puede ser operada por voz.

Para la interacción, el usuario habla por un micrófono en lugar de usar una pantalla táctil, un teclado u otro dispositivo de entrada táctil. La aplicación de voz envía la salida de voz generada por computadora al dispositivo de altavoz.

Tecnología involucrada en el proceso

Analicemos esto en las tecnologías que se requieren para una desarrollar y poner en producción un aplicación de voz. Recuerda que tienes que establecer una comunicación de audio bidireccional del usuario con la aplicación.

Voz a texto (reconocimiento de voz)

El comando de voz del usuario se convierte en texto, porque es mucho más fácil para una computadora entender el lenguaje humano a partir del texto que a partir de datos de audio.

Comprensión del lenguaje natural

El motor NLU extrae el significado del comando de voz y lo convierte en una forma comprensible para una computadora. Por lo general, esto significa extraer la intención y las entidades.

Generación de lenguaje natural

La aplicación de voz tiene que traducir de alguna manera el contenido generado por computadora a algo comprensible para los usuarios humanos: lenguaje natural.

Texto a voz (síntesis de voz)

Para presentar el idioma generado al usuario, debe convertirse en datos de audio mediante el uso de una voz de computadora.

Pruebas automatizadas

Dado el volumen de tecnología empleado en este proceso  y dada la naturaleza de las interacciones conversacionales con una aplicación de voz, está claro que necesitamos una forma de simular una conversación de dos lados para automatizar el proceso de prueba:

• Por un lado, tenemos que simular a un usuario diciendo un comando de voz a la aplicación de voz.
• Por otro lado, tenemos que afirmar la respuesta de la aplicación de voz para cumplir con nuestros objetivos de prueba.

Simulación de la voz del usuario

Los componentes básicos para la prueba automatizada de los comandos de voz son los archivos de audio que se envían a la aplicación de voz. Hay varias opciones igualmente viables para generar estos archivos de audio, y una estrategia de prueba holística debe hacer uso de todas estas opciones. Para alcanzar una alta cobertura de prueba, debes considerar variaciones en múltiples dimensiones:

• Hablantes nativos frente a hablantes no nativos
• Hombre vs mujer vs neutral vs niño
• Audio de ancho de banda alto frente a ancho de banda bajo (puesto en trabajo de oficina frente a llamada telefónica)
• Red estable vs inestable
• Hardware de alta calidad frente a hardware de baja calidad
• Ruido de fondo

Grabaciones de audio

A pequeña escala, la opción más fácil es usar tu micrófono y grabar tu propia voz. Con un equipo de testers de voz, puedes crear tu propia biblioteca de muestras de audio para probar. El gran problema de este enfoque es la baja cobertura de las pruebas que depende principalmente de la diversidad de tu equipo y/o muestra.

Voces sintéticas

Si bien hace algunos años era bastante fácil distinguir una voz generada por computadora de una voz humana real, mientras tanto, las voces sintéticas se han vuelto ubicuas y con los últimos avances en machine learning y redes neuronales artificiales, la calidad de los servicios de generación de voz disponibles, es convincente.

Hay voces sintéticas disponibles para todos, desde gratuitas hasta costosas, desde código abierto hasta servicios en la nube, desde baja calidad hasta alta calidad, desde bajo uso de recursos hasta clústeres de supercomputadoras. Existen productos que reducen el esfuerzo de integración técnica, como Botium Speech Processing.

Una gran ventaja de usar voces sintéticas es la opción de generar archivos de audio sobre la marcha cuando se ejecutan los casos de prueba, en lugar de tener una biblioteca de archivos de audio.

Ruido de fondo y calidad de audio

Una buena solución de prueba de voz (como Botium) tendrá múltiples opciones para introducir ruido artificial en los archivos de audio, para simular una red inestable y condiciones ambientales ruidosas y más, las cosas que son difíciles de simular, especialmente al grabar t us propios archivos de audio.

Afirmar la corrección

El punto principal en las pruebas es verificar la corrección del sistema bajo prueba. Para una aplicación web típica, esto significaría, por ejemplo, comparar el contenido de la pantalla visible con el contenido de la pantalla esperado. Para una aplicación de voz, esto significa comparar la respuesta de audio con la respuesta esperada, pero en casi todos los casos no es factible comparar la transmisión de audio a nivel de byte.

Texto de respuesta

La forma obvia es aplicar el reconocimiento de voz a la respuesta de audio y comparar en un nivel de texto sin formato: los ingenieros de automatización de pruebas están acostumbrados a las afirmaciones de texto. Es importante tener en cuenta las deficiencias de los motores de reconocimiento de voz: debido a la naturaleza del machine learning, las transcripciones a veces no son 100 % precisas.

La solución de prueba debe admitir el uso de adaptaciones de homófonos, y puedes pensar en afirmar la tasa de error de palabras (WER) en lugar de la coincidencia directa de texto para lidiar con una precisión subóptima.

Calidad de audio

Incluso sin el reconocimiento de voz, es posible evaluar métricas sobre la calidad de la transmisión de audio en sí. Un método estándar para la evaluación automatizada de la calidad del habla en un sistema de telefonía es, por ejemplo, PESQ.

Métricas no funcionales

Además de lo anterior, es posible afirmar varias métricas no funcionales, como el tiempo de respuesta y el volumen de la transmisión de audio.

Canales de la aplicación de voz

Ahora que conocemos los artefactos y las métricas que necesitamos para probar una aplicación de voz, debemos identificar los puntos de integración que podemos usar para las pruebas automatizadas. No hay una respuesta obvia a esto, ya que depende de la tecnología, el canal de publicación y también las opciones de implementación. Una estrategia de prueba holística considerará todo esto y también adaptará el conjunto de pruebas para que se ejecute en múltiples niveles:

• End-2-End para verificar la experiencia del usuario final en diferentes plataformas
• Nivel de API para verificar funciones de audio a gran escala
• Pruebas no funcionales

Transmisión de audio frente a archivos de audio

Desde una perspectiva tecnológica, requiere un enfoque diferente, ya sea que la tecnología funcione con transmisión de audio o mediante el intercambio de archivos de audio.

Audio Streaming envía un flujo constante de datos de audio desde el usuario a la aplicación de voz y viceversa. Tecnologías que cubren este servicio son por ejemplo:

• Sistemas IVR con PSTN o VOIP
•  API de Websocket (tráfico bidireccional)

Para intercambiar archivos de audio, se carga un fragmento de audio con un principio y un final definidos en la aplicación de voz y se descarga la respuesta. Tecnologías de ejemplo:

• API de proveedores de chatbot con servicios de voz integrados como Dialogflow
• API REST personalizadas

Sistemas IVR

Los sistemas IVR son un tipo de aplicación de voz muy común y existen desde hace mucho tiempo. Para probar los sistemas IVR es necesario simular llamadas telefónicas vía PSTN (la red telefónica pública) o vía VOIP (voz sobre IP). Se establece un flujo de audio entre el sistema IVR y el software de automatización de pruebas, los datos de audio se inyectan en este flujo de audio y se recuperan de él.

La prueba automática de sistemas IVR a gran escala es posible con Botium Box y su conector VOIP/PSTN.

Hardware de sonido

También hay aplicaciones de voz disponibles en los teléfonos inteligentes sin usar la telefonía, usando el micrófono y el altavoz del dispositivo del teléfono inteligente. Un ejemplo son las aplicaciones de traducción como Google Translate.

Botium Connector para Voice Apps utiliza Perfect Audio Functions para probar sitios web y aplicaciones de teléfonos inteligentes controlados por voz; en este caso, la transmisión de audio al micrófono y desde el altavoz se redirige a Botium.

The post Cómo hacer el testing de aplicaciones de voz o voicebots correctamente first appeared on Planeta Chatbot.

Dado que los chatbots ofrecen una amplia gama de aplicaciones, en ciertos casos también se vuelven responsables de recopilar y proteger información personal. En consecuencia, son una gran atracción para los piratas informáticos y también para los ataques maliciosos. La responsabilidad de garantizar la seguridad de los chatbots se ha pronunciado después de la introducción de GDPR en Europa. Como las estadísticas muestran que esta tecnología será un factor determinante en nuestras vidas, las pruebas de seguridad también deben formar parte de nuestras tareas diarias, para que estos chatbots puedan usarse con confianza.

Riesgos de seguridad, amenazas y vulnerabilidades

Las palabras riesgo, amenaza y vulnerabilidad a menudo se confunden o se usan indistintamente cuando se lee sobre seguridad informática, así que primero aclaremos la terminología:

• La vulnerabilidad se refiere a una debilidad en su software (o hardware, o en sus procesos, o cualquier cosa relacionada). En otras palabras, es una forma en que los piratas informáticos pueden encontrar el camino y explotar sus sistemas.
• Una amenaza aprovecha una vulnerabilidad y puede provocar la pérdida, el daño o la destrucción de un activo: las amenazas aprovechan las vulnerabilidades.
• El riesgo se refiere a la posibilidad de que se pierdan, dañen o destruyan activos: ¡amenazas + vulnerabilidad = riesgo!

El conocido OWASP Top 10 es una lista de los principales riesgos de seguridad para una aplicación web. La mayoría de los chatbots están disponibles a través de una interfaz web pública y, como tal, todos los riesgos de seguridad de OWASP también se aplican a esos chatbots. De estos riesgos, hay dos especialmente importantes contra los que defenderse, ya que, en contraste con los otros riesgos, esos dos son casi siempre una amenaza grave: XSS (Cross Site Scripting) y SQL Injection.

Además, para los chatbots habilitados con inteligencia artificial, existe un mayor riesgo de ataques de denegación de servicio, debido a la mayor cantidad de recursos informáticos involucrados.

Vulnerabilidad 1: XSS – Cross Site Scripting

Una implementación típica de una interfaz de usuario de chatbot:

• Hay una ventana de chat con un cuadro de entrada.
• Todo lo que el usuario ingresa en el cuadro de entrada se refleja en la ventana de chat.
• La respuesta del chatbot se muestra en la ventana de chat.

La vulnerabilidad XSS se encuentra en el segundo paso: al ingresar texto que incluye código Javascript malicioso, el ataque XSS se completa cuando el navegador web ejecuta el código inyectado:

<script>alert(document.cookie)</script>

Posible vector de ataque

Para explotar una vulnerabilidad XSS, el atacante tiene que engañar a la víctima para que envíe un texto de entrada malicioso.

1. El atacante engaña a la víctima para que haga clic en un hipervínculo que apunta al chatbot e incluye algún código malicioso en el hipervínculo.
2. El código malicioso se inyecta en el sitio web, lee las cookies de las víctimas y las envía al atacante sin que la víctima se dé cuenta.
3. El atacante puede usar esas cookies para obtener acceso a la cuenta de la víctima en el sitio web de la empresa.

Defensa

Esta vulnerabilidad es realmente fácil de defender al validar y desinfectar la entrada del usuario, pero aún así vemos que esto sucede una y otra vez.

---

Vulnerabilidad 2: Inyección SQL

Una implementación típica de un backend de chatbot orientado a tareas:

• El usuario le dice al chatbot algún elemento de información.
• El backend del chatbot consulta una fuente de datos para este elemento de información.
• Basándose en el resultado, se genera una respuesta en lenguaje natural y se presenta al usuario.

Con SQL Injection, el atacante engaña al backend del chatbot para que considere el contenido malicioso como parte del elemento de información:

my order number is "1234; DELETE FROM ORDERS"

Posible vector de ataque de Chatbot

Cuando el atacante tiene acceso personal al chatbot, el atacante puede explotar directamente una inyección SQL (consulte el ejemplo anterior), realizando todo tipo de consultas SQL (o no SQL).

Defensa

Los desarrolladores suelen confiar en sus tokenizadores y extractores de entidades para defenderse de los ataques de inyección. Además, en la mayoría de los casos, las comprobaciones simples de expresión regular de la entrada del usuario cerrarán esta vulnerabilidad.

---

Vulnerabilidad 3: Denegación de servicio

La inteligencia artificial requiere un alto poder de  computación, especialmente cuando se trata de deep learning como en los algoritmos de comprensión del lenguaje natural (NLU) de última generación. El ataque de Denegación de Servicio (Denial of Service, DoS, en sus siglas en inglés) se centra en hacer que un recurso no esté disponible para el propósito para el que fue diseñado, y no es difícil imaginar que los chatbots son más vulnerables a los ataques de Denegación de Servicio (DoS) que los backends habituales basados ​​en sistemas altamente optimizados. Si un chatbot recibe una gran cantidad de solicitudes, es posible que deje de estar disponible para usuarios legítimos. Estos ataques introducen grandes retrasos en la respuesta, pérdidas excesivas e interrupciones del servicio, lo que tiene un impacto directo en la disponibilidad.

Posible vector de ataque de Chatbot

Un ataque de este tipo envía una gran cantidad de solicitudes al chatbot para agotar intencionalmente los recursos disponibles. Sucederá que los recursos informáticos ya no estarán disponibles para los usuarios legítimos, es decir, los que verdaderamente están haciendo uso de la plataforma.

Pero hay un riesgo adicional a considerar: es bastante común que los desarrolladores de chatbots utilicen servicios basados ​​en la nube como IBM Watson o Google Dialogflow. Dependiendo del plan elegido, existen límites de uso y/o cuotas vigentes que pueden agotarse con bastante rapidez; por ejemplo, el plan gratuito Google Dialogflow Essential limita el acceso a 180 solicitudes por minuto, todas las demás solicitudes serán denegadas. Para un plan basado en el uso sin límites, un ataque DoS puede costar fácilmente una fortuna debido al aumento del número de solicitudes.

Defensa

Los métodos establecidos para defenderse de los ataques de denegación de servicio también se aplican a los chatbots.

---

Estrategias de mitigación

Además de las estrategias de defensa han explicado en las líneas anteriores, existen reglas genéricas para mitigar los riesgos de brechas en el sistema.

Educación para desarrolladores de software

Naturalmente, la mejor manera de defenderse de las vulnerabilidades es ni siquiera dejar que ocurran en primer lugar. Los desarrolladores de software deben recibir capacitación especial para considerar la seguridad del sistema como parte de su rutina diaria de desarrollo. Establecer la mentalidad y los procesos en el equipo de desarrollo es el primer paso y el más importante.

Pruebas de seguridad continuas

Las pruebas de seguridad deben ser parte de tu proceso continuo de pruebas. Cuanto antes se identifique y repare una vulnerabilidad de seguridad, más económico será el cambio.

Las pruebas básicas basadas en OWASP Top 10 deben realizarse tanto en el nivel de API como en el nivel End-2-End. Por lo general, la defensa contra inyecciones de SQL se prueba mejor en el nivel de API (debido a la velocidad), mientras que la defensa contra XSS se prueba mejor en el nivel de extremo a extremo (debido a la ejecución de Javascript).

Las herramientas especializadas como Botium ayudan a configurar tu proceso continuo de pruebas de seguridad para chatbots.

---

Conclusión

Los chatbots abren el mismo tipo de vulnerabilidades, amenazas y riesgos que otras aplicaciones web orientadas al cliente. Debido a la naturaleza de los chatbots, algunas vulnerabilidades son más probables que otras, pero las estrategias de defensa bien establecidas funcionarán para los chatbots.

The post Las 3 principales vulnerabilidades de seguridad en chatbots para el 2022 first appeared on Planeta Chatbot.

Topics de Short y Long tail

Si bien no poseemos una bola de cristal mágica para analizar escenarios de uso futuros, a partir de nuestra experiencia obtuvimos los mejores resultados con un enfoque sistemático en una configuración de retroalimentación continua. En casi todos los proyectos de chatbot, los casos de uso se pueden clasificar:

• Short-tail topics: los temas que satisfacen la mayoría de las necesidades de la mayoría de los usuarios (por lo general, se aplica la regla 90/10: el 90% de tus usuarios solicitan solo el 10% de los temas).
• Long-tail topics: todos los demás temas de alguna manera exóticos que el chatbot también podría responder.
• Temas de traspaso: temas en los que, por cualquier motivo, se requiere el traspaso a un agente humano.

Ejemplos de los topics de short-tail en el dominio de las telecomunicaciones:

• Horarios de las tiendas más importantes.
• Problemas de conectividad WLAN.
• Preguntas sobre líneas de factura individuales.

Ejemplos de topics de long-tail en el dominio de las telecomunicaciones:

• Disponibilidad de iPhone en las tiendas más importantes.
• Condiciones de roaming internacional.
• Teléfono con tarjeta SIM perdida.

Ejemplos de temas de traspaso en el ámbito de las telecomunicaciones:

• Cancelación de contrato.
• Productos comerciales y clientes comerciales.

Empezando

Nuestras recomendaciones para los primeros pasos en un proyecto de chatbot son siempre las mismas:

1. Enfoca la capacitación y las pruebas exclusivamente en los temas de short-tail; por lo general, con un chatbot de soporte al cliente, que son la mayoría de los chatbots con los que hemos estado trabajando, hay un puñado de temas solo para los que debe proporcionar una buena prueba.
2. Aparte de eso, deje de lado los topics de long-tail y diseñe un proceso de traspaso humano claro.

El desafío ahora es cómo obtener una buena cobertura de prueba para los topics de short-tail: este es el trabajo complejo en un proyecto de chatbot. Una vez escribí una publicación de blog sobre cómo recopilar datos de entrenamiento para un chatbot.

Retroalimentación continua

Tan pronto como el chatbot está en funcionamiento, se requiere un reentrenamiento constante: este proceso implica un trabajo manual para evaluar las conversaciones reales de los usuarios que por alguna razón salieron mal y para deducir los pasos de capacitación requeridos. Durante este proceso, la cobertura de la prueba aumentará; para los temas de short-tail, podemos esperar una cobertura de prueba cercana al 100% dentro de varias semanas después del lanzamiento: esos son los temas que se preguntan una y otra vez, y tan complejos como el lenguaje humano puede ser, solo hay un número finito de opciones para expresar una intención de una manera razonablemente corta.

A diferencia del título del post, puedes ver que sugerimos un enfoque muy realista: no probar lo inesperado o lo desconocido, sino probar las «opciones más probables» y tratar de obtener una alta cobertura de pruebas para esos casos (esto es posible ya que el lenguaje humano es complejo pero finito).

Pruebas automatizadas

Cuando se trata de la automatización de pruebas, la pregunta fundamental es si en algo vale la pena invertir el esfuerzo inicial de automatización.

• Es imprescindible establecer pruebas automatizadas para los temas de short-tail.
• Garantizar un proceso de traspaso fluido a un agente humano
• Los temas de long-tail se pueden manejar con pruebas manuales al principio

Obtener las herramientas

Sin las herramientas adecuadas, estarás perdido. Nuestro producto estrella Botium Box te ayuda en tu camino hacia las pruebas exitosas de chatbot.

The post Cómo hacer pruebas de chatbots para calcular las situaciones inesperadas first appeared on Planeta Chatbot.

• Tengo que probar un chatbot Whatsapp, ¿pueden ayudarme a configurar
  Appium?
• Para nuestro cliente, tengo que probar un chatbot integrado en su aplicación, ¿puedo probarlo con Botium?
• Tengo problemas para probar el chatbot de soporte al cliente en nuestro sitio web, Selenium dice <algún código de error aleatorio de Selenium>
• … y así sucesivamente.

La conclusión que se puede extraer de estas preguntas es: los test engineers o ingenieros de pruebas aprendieron cómo probar sitios web con Selenium y aplicaciones para smartphones con Appium en el pasado, y ahora intentan aplicar este valioso conocimiento nuevamente, descuidando el hecho de que los chatbots son un nuevo tipo de aplicaciones. que requieren nuevos tipos de herramientas (como Botium).

Puedes leer sobre las diferencias más importantes en una de mis publicaciones de blog anteriores.

Con Selenium y Appium, estamos hablando de pruebas End-2-End (E2E), que simulan la experiencia completa del usuario en una interfaz gráfica de usuario. Esas pruebas:

1. Son extremadamente lentas en ejecución, ya que básicamente se ejecutan en tiempo real, e incluso para un proyecto de chatbot de tamaño mediano, generalmente hay un número de 5 cifras de casos de prueba para que la cobertura y los resultados de la misma sean validos; ejecutar esas pruebas en un escenario E2E requerirá horas en el mejor de los casos.
2. Requieren una gran cantidad de recursos informáticos o acceso a costosos servicios en la nube de navegador/dispositivo.
3. Son inestables ya que la infraestructura requerida también es propensa a errores.
4. No puede proporcionar una visión holística de la calidad del objeto de prueba, ya que algunas afirmaciones importantes como el rendimiento puro de NLP no son técnicamente posibles con las pruebas E2E.

Así que aquí están mis recomendaciones para los test engineers sobre cómo pueden proceder cuándo tengan que iniciar las pruebas de su chatbot.

API primero

La métrica más importante para un chatbot es: ¿puedes mantener una conversación significativa con un cliente? En cada equipo de proyecto de chatbot hay diseñadores de conversaciones que, bueno, diseñan las conversaciones que conformarán la experiencia final del usuario. El motor de chatbot está entrenado (o codificado) para proporcionar la lógica de estas conversaciones.

Flujo de conversación visualizado por Botium

Y este es el lugar para comenzar a probar: asegúrate de que las conversaciones
funcionan según lo diseñado, desde una perspectiva de contenido. Puedes leer más sobre las pruebas de flujo de conversación en los documentos de Botium. Una habilidad importante que debe tener el perfil de test engineer es conocer BotiumScript, el lenguaje de secuencias de comandos para definir casos de prueba de flujo de conversación.

Prueba del motor de NLP

La mayoría de los chatbots tienen algún tipo de componente de procesamiento de lenguaje natural (NLP) como parte del proceso de procesamiento: permitía a los usuarios comunicarse con el chatbot en lenguaje natural, y eso es lo que realmente constituye un chatbot. Como ingeniero de pruebas, es su trabajo explorar los límites del motor de PNL, y esto requiere habilidades básicas en conceptos de aprendizaje automático, como:

• Intenciones, entidades y confianza en la predicción.
• Exactitud, sensibilidad, especificidad, precisión, recuerdo, puntuación F1.
• Matriz de confusión.

Puedes leer sobre esto en mi serie de artículos Quality Metrics for NLU / Chatbot Training Data:

Quality Metrics for NLU/Chatbot Training Data, Part 1: Confusion Matrix

The post Cómo mejorar las skills de los test engineers para proyectos con chatbots first appeared on Planeta Chatbot.

Cuando se trata de probar los chatbots de WhatsApp hasta ahora, ha habido principalmente dos enfoques:

• Probar manualmente mediante un smartphone.
• Prueba de la funcionalidad de backend con API Testing.

Ambos enfoques son válidos y ningún proyecto de tecnología conversacional con enfoque empresarial debería perderlos. Pero hay dos defectos obvios:

1. Las pruebas manuales no son escalables en la medida necesaria para garantizar una alta calidad constante para los chatbots cuando estos estén en producción.
2. Las pruebas de backend no consideran la experiencia del usuario final.

Botium llena este vacío con un nuevo conector para probar los chatbots de WhatsApp en smartphones reales y virtuales.

Construcción de la infraestructura de prueba

Esto es lo que necesitas:

• Algunos teléfonos inteligentes con tarjetas SIM y cables USB.
• O Docker + Docker-Compose para iniciar dispositivos virtuales.

Configuración de dispositivos reales

• Compra algunos smartphones (o usa el tuyo propio) con tarjetas SIM.
• Instala y registra WhatsApp en ellos.
• Habilita el modo de desarrollador de Android: pregunta a Google cómo hacerlo para el modelo de tu dispositivo.
• Conéctalo a tu estación de trabajo con el cable de datos USB.

1. Instala SDK de Android.
2. Instala y ejecuta Appium.

Configurar dispositivos virtuales

1. Instala Docker y Docker-Compose.
2. Lanza un dispositivo virtual con la ayuda de este proyecto.

En resumen, puedes crear un archivo docker-compose.yml e iniciarlo con docker-compose up -d para obtener una sola máquina virtual con un solo dispositivo Samsung virtual en funcionamiento. Puedes verlo en funcionamiento en la siguiente ruta: http://localhost:6080

version: “3”
services:
samsung_galaxy_S8:
image: budtmo/docker-android-x86–11.0
privileged: true
ports:
- “6080:6080”
- “4723:4723”
environment:
- DEVICE=Samsung Galaxy S8
- APPIUM=true
- MOBILE_WEB_TEST=false
- AUTO_RECORD=false

Emulador de dispositivo Samsung

Obtén una cuenta Twilio o cualquier otro proveedor de SMS, instala WhatsApp en el dispositivo virtual y regístralo por SMS.

En uno de los próximos lanzamientos de Botium, el paso de registro también será automatizado por Botium Box.

Ahora que tus dispositivos están en funcionamiento y WhatsApp disponible, veamos qué más preparar.

Conectar Botium a WhatsApp

Necesitas una instalación de Botium Box para este propósito. Los ingenieros de DevOps experimentados pueden probar Botium Core, la biblioteca de automatización de código abierto y gratuita que alimenta a Botium Box y otros productos de Botium.

Obtén tu copia de Botium Box aquí.

Conectar Device Lab a Botium

En la configuración de Botium Box, registra un nuevo proveedor de dispositivos.

Cuéntale a Botium sobre el dispositivo

Si bien para la mayoría de los proveedores de dispositivos en la nube, los dispositivos disponibles se pueden enumerar automáticamente (llamando a las API de listas de dispositivos en la nube), esto no es posible para tu instalación local de Appium. Edita el archivo LOCALSELENIUM.json en la carpeta de recursos de Botium Box para informar a Botium sobre los dispositivos disponibles:

[
 {
 "name": "Samsung Galaxy S8 Emulator",
 "value": {
 "type": "MOBILEAPP",
 "capabilities": {
 "appium:platformName": "Android"
 }
 }
 }
]

Redactar un conjunto de dispositivos

Botium Box agrupa los dispositivos en los que desea ejecutar tus pruebas en conjuntos de dispositivos. Crea un nuevo conjunto de dispositivos para tu terminal de Appium y selecciona el emulador Samsung Galaxy S8 (y tal vez otros dispositivos también si los conectó).

Configurar el conector de Botium para Appium

Registra un nuevo chatbot en Botium Box

• Como tecnología Connector/Chatbot, usa WebdriverIO (Selenium o Appium).
• Como tecnología de automatización, seleccionae Use Appium.
• Como Webdriver Script, elige Whatsapp.

Como desarrollador experimentado de Appium, puedes preguntar ¿Dónde puedo ingresar los selectores de CSS de Selenium? — con Botium no tienes que hacer esto, ya que es parte de Webdriver Script Whatsapp.

En el último paso del Asistente de inicio rápido, asegúrate de seleccionar tu dispositivo configurado en la parte inferior para comenzar tus pruebas.

Escribir casos de prueba

Ahora puedes utilizar toda la potencia de BotiumScript para escribir tus casos de prueba. Uno fácil podría verse así:

hi#me

hi#bot

Welcome to the World Health Organization

Mira Botium Automatizando Whatsapp

• Abre la aplicación WhatsApp.
• Selecciona el contacto que representa al chatbot.
• Limpia el historial de mensajes.
• Envía un mensaje de prueba desde WhatsApp.
• Recibe la salida de WhatsApp y comparar con el caso de prueba.
• Repite los dos últimos pasos hasta que el caso de prueba esté listo.

Botium Automatizando Whatsapp

Conclusión

Con Botium Box y Appium ahora es posible ejecutar pruebas automatizadas end-to-end del flujo de conversación de tu chatbot de WhatsApp.

The post Cómo automatizar las pruebas de tu chatbot de WhatsApp first appeared on Planeta Chatbot.

Planificar iteraciones

En alemán decimos que Roma no se construyó en un día; lo mismo se aplica a los datos de entrenamiento de tu chatbot. Un chatbot robusto se construye mediante múltiples iteraciones, ciclos de entrenamiento y pruebas y mediante monitoreo continuo y ajuste del rendimiento: CÓDIGO, PRUEBA, DESPLIEGUE, REPETICIÓN.

NO subestimes la necesidad de una medición constante del rendimiento

Sin medir el rendimiento con conversaciones de usuarios reales, nunca sabrás si tu chatbot realmente está funcionando para tus usuarios.

DO: aplicar la regla 80/20 para probar expresiones

La mayoría de los equipos se sienten tentados a utilizar el 100% de los datos disponibles para la formación del bot. No hagas esto. No sabrás si tus datos de entrenamiento funcionan si usas parte de los datos de entrenamiento también para las pruebas. La regla general es utilizar el 80% de los datos para el entrenamiento y el 20% para las pruebas.

Si la cantidad de datos disponibles es muy pequeña, puedes probar la validación K-Fold para obtener algunas ideas sobre la calidad de tus datos.

NO confíes en pruebas de humo o pruebas de camino feliz

Nuevamente, la regla 80/20: el 20% es el trabajo dedicado a la zona de confort, el 80% del trabajo es la prueba y la corrección de errores. El 20% de tus usuarios seguirá el camino feliz, el 80% saldrá. Prepárate para esto.

DO: dedica una cantidad de tiempo razonable a las pruebas exploratorias

Las pruebas de regresión automatizadas son superiores para encontrar defectos que sabes que pueden ocurrir. No ayudará a encontrar defectos que no conoces. Dedica algún tiempo a las pruebas exploratorias (= manuales): intenta llevar tu chatbot al límite y más allá.

NO: ignora la necesidad de volver a realizar la prueba después del entrenamiento

Nunca sabrás qué efecto tendrá en otro punto del chatbot la introducción de nuevos datos, hasta que lo pruebes. Realiza una prueba de regresión completa de tu modelo NLU cada vez que realices cambios.

DO: pruebas fuera de contexto

Uno de los comportamientos más parecidos a los humanos es desplazarse hacia arriba en el historial de conversaciones en la ventana del chatbot y reanudar desde un paso anterior. La mayoría de los chatbots fallarán en este desafío si no se preparan para que sean capaces de superar la situación.

Plan de ACCIÓN

A continuación se ofrecen sugerencias para abordar lo que debes y no debes hacer cuando estás probando el entrenamiento de tu chatbot:

Establecer una mentalidad de prueba continua

Las pruebas son una parte crucial del proceso de desarrollo. No existe una sola fase de prueba cuando se da vida a un chatbot. Las pruebas deben ser parte del trabajo diario del equipo, al igual que la codificación, el diseño y la supervisión.

Impresionante imagen que muestra pruebas continuas.

Pruebas holísticas

Tanto para los chatbots como para los productos de software en general, hay más que pruebas unitarias codificadas por los programadores.

Tipos de proyectos de prueba de Botium

• Prueba de regresión: identifica fallos o faltas en el flujo de la conversación antes de pasar a producción.
• Prueba de NLP: mejora la comprensión de tu chatbot.
• Prueba E2E: verificación de la experiencia del usuario final.
• Pruebas de voz: comprende a tus usuarios en los canales de voz.
• Prueba de rendimiento: asegúrate de que tu chatbot responde ante un mensaje con mucha información.
• Pruebas de seguridad: haz que tu chatbot sea seguro.
• Monitoreo: recibe notificaciones cuando surjan problemas.

Coloca las herramientas adecuadas

Sin las herramientas adecuadas, estarás perdido. Con Botium Box, estás preparado para los desafíos de implementarlos e integrarlos en el ciclo de vida de desarrollo de tu chatbot.

Obtén tu prueba gratuita de Botium Box Mini aquí

The post Consejos a la hora de probar el entrenamiento de tu chatbot first appeared on Planeta Chatbot.

La aplicación de las prácticas que en este artículo se sugieren ayuda a responder las siguientes preguntas:

• ¿Mi aplicación de voz sigue el flujo de conversación diseñado? ¿El flujo de la conversación funciona como se esperaba?
• ¿Cómo funciona mi aplicación de voz en condiciones reales? ¿Tiene baja calidad de audio? ¿Las conexiones de red lentas?
• ¿Mi aplicación de voz está disponible 24×7 o hay interrupciones en el servicio?

El arte de desafiar los chatbots

Los desafíos a la hora de probar chatbots, especialmente los habilitados en canales de voz, son diferentes a los de probar aplicaciones con una interfaz gráfica de usuario: mientras que una interfaz gráfica de usuario restringe las posibles interacciones del usuario mediante los controles que ofrece, con lenguaje natural, el número de posibles usuarios las entradas son ilimitadas. Además, cuando se usa la voz como entrada del usuario, nuevamente hay más variables a tener en cuenta: los matices individualesen las voces, la calidad del micrófono, los ruidos de fondo que rodean al orador y además: al hacer clic en el botón de una interfaz gráfica, la aplicación siempre interpreta lo mismo, independientemente de quién haya hecho clic en ella. En voz, no.

Las plataformas detrás de las poderosas aplicaciones de voz aún están evolucionando y están sujetas a mejoras constantes, lo que significa que los desarrolladores tienen que depender de componentes que no son de su propiedad y la posible influencia es limitada.

Prueba del flujo conversacional de voz

El producto de código abierto Botium te proporciona todas las herramientas necesarias para implementar una estrategia de prueba integral y holísticapara tus aplicaciones de voz. Puedes leer sobre Botium y los antecedentes sobre cómo probar un flujo conversacional en la documentación oficial de Botium.

Botium Tutorial – Botium documentation

Botium Box Live Chat — Grabador

Puedes guardar la conversación como caso de prueba y realizar algunos cambios después.

• Refinando el texto y el audio de entrada y salida.
• Usar listas de expresiones o coincidencias de comodines en lugar de texto completo.
• Agregar pasos de prueba o afirmadores adicionales.

Caso de prueba de voz Botium Box

Sintetizar casos de prueba mediante conversión de texto a voz

En lugar de grabar tu propia voz para los casos de prueba, puedes decidir usar en tu lugar (o adicionalmente) muestras de voz sintetizadas. Botium tiene su propia plataforma Text-To-Speech y Speech-To-Text basada en los mejores motores de código abierto y en la nube disponibles: Botium Speech Processing.

Los casos de prueba ahora muestran texto sin formato en lugar de la entrada de audio auf:

Botium Box Live Chat — Entrada de texto

Eliminación los problemas: asignaciones de homófonos

Un problema típico cuando se prueban aplicaciones de voz es que las transcripciones de audio, especialmente para audio de baja calidad, pueden ser bastante inestables; en la automatización de pruebas, generalmente confiamos en hechos concretos (afirmaciones de texto fijo), y esto conducirá a una mayor falta de precisión en los resultados de la prueba.

En este ejemplo, puedes ver que en lugar de okay milch ist auf deiner liste the transcription says okay milch is auf seiner liste; esta diferencia de un carácter hará que un caso de prueba falle:

Problema de transcripción

Botium ofrece la opción de especificar asignaciones homófonas para tratar fragmentos de audio que el motor Speech-To-Test a menudo malinterpreta.

Especificación de asignaciones de homófonos

Los casos de prueba utilizan estas asignaciones para calificar los resultados de la transcripción como correctos o fallidos.

Problema de transcripción: asignación de homófonos aplicada

Prueba de escenarios de la vida real

Usar tu propio micrófono frente a tu portátil puede ser un buen punto de partida, pero en la vida real, las aplicaciones de voz se usan de otra manera: con un smartphone, con un dispositivo domótico o de entretenimiento como Alexa o Google Home, en un automóvil. Para llegar a casos de prueba significativos de End-2-End para estos escenarios, tendrás que hacer que tus datos de prueba sean similares a esos escenarios.

• Agrega ruido de fondo en varios niveles.
• Sube o baja el volumen.
• Simula varios niveles de distancia
• Simula restricciones técnicas como línea telefónica GSM o ancho de banda bajo.
• Simula una mala calidad de audio, como interrupciones o varios niveles de silencio.
• Llámale…

En Botium Box puedes aplicar varios efectos para simular escenarios de uso de la vida real a tus propias grabaciones limpias o muestras de audio sintetizadas.

Efectos de voz de Botium Box

Monitoreo continuo

La receta para garantizar la disponibilidad de tu aplicación de voz es bastante simple todo lo que necesitas es:

• Una smoke test para verificar el comportamiento básico (por ejemplo, simplemente enviar un saludo simple a la aplicación de voz y listar para obtener una respuesta)
• Un programador para ejecutar la prueba de humo cada pocos minutos.
• Un mecanismo de notificación para informarte en caso de averías.

Con Botium Box, todo lo que necesitas sale de la caja.

Resumen

Ahora que sabes lo que se necesita para las pruebas automatizadas de tu aplicación de voz, puedes probar Botium Box o puedes seguir el plan gratuito y de código abierto con Botium Core.

• Grabar tu propia voz o use voz sintetizada.
• Aplicar efectos de audio para simulación de la vida real.
• Prueba de flujo de conversación con Botium.

The post Tutorial para automatizar el testing de aplicaciones de voz first appeared on Planeta Chatbot.

Rasa es una herramienta de construcción de chatbot extensible y amigable para desarrolladores de self-hosting. Botium Speech Processing es una API unificada y fácil de desarrollar para los mejores servicios gratuitos y de código abierto Speech-to-Text y Text-to-Speech disponibles. Combinemos esto, pero primero echemos un vistazo rápido a la arquitectura.

Arquitectura

1. El usuario habla por un micrófono.
2. Un servicio Speech-To-Text se traduce en texto (Botium Speech Processing).
3. Un motor NLU extrae información del texto (Rasa).
4. Un motor de diálogo crea una respuesta de texto (Rasa).
5. Un servicio Text-To-Speech se traduce en texto hablado (Botium Speech Processing).
6. El usuario escucha el archivo de audio.

La imagen es de esta publicación de blog de Rasa

Pasos de instalación

Así que vayamos a la parte divertida.

Prerrequisitos

Esto es lo que necesitas tener disponible para poder desarrollar este tutorial:

• Cliente de Git.
• Docker y Docker-Compose.

Lanzamiento del servicio de procesamiento de voz Botium.

Botium Speech Processing viene con una configuración predeterminada razonable.

• MaryTTS para conversión de texto a voz
• Kaldi para Speech-To-Text

Ambos son gratuitos y de código abierto y una buena combinación para iniciarse con las tecnologías de voz. Además, sin duda se encuentran entre las mejores herramientas de voz gratuitas disponibles.

Puedes iniciarlo con unas pocas llamadas a:

$ git clone https://github.com/codeforequity-at/botium-speech-processing.git
$ cd botium-speech-processing
$ docker-compose up -d

Dependiendo de la velocidad de la red y del hardware, este paso puede llevar un tiempo.

Apuntando tu navegador a http: // localhost mostrará el explorador de API para Botium Speech Processing.

Configurar Rasa

Usaremos Sara, el Rasa Demo Bot, como ejemplo.

Puedes encontrar información de primera mano en el repositorio de Github.

Prefiero usar Docker en lugar de instalar todo localmente. Entonces, puedes usar estas llamadas para descargar el bot de demostración Rasa y ejecutar un primer entrenamiento:

$ git clone https://github.com/RasaHQ/rasa-demo.git
$ cd rasa-demo
$ docker run — rm -v .:/app rasa/rasa:latest-full train — domain domain.yml — data data/core data/nlu — out models/dialogue — augmentation 0

Dependiendo de la velocidad de la red y del hardware, este paso puede llevar un tiempo.

Coloca este archivo docker-compose.yml en la carpeta Rasa:

version: ‘3.0’
services:
rasa:
image: rasa/rasa:latest-full
ports:
- 5005:5005
volumes:
- ./:/app
environment:
RASA_DUCKLING_HTTP_URL: http://rasa-duckling:8000
command: run — model models/dialogue — endpoints endpoints.yml
rasa-actions:
build:
context: .
ports:
- 5055:5055
rasa-duckling:
image: rasa/duckling
ports:
- 8000:8000

En el archivo endpoints.yml, cambie la URL del punto final de acciones de http: // localhost: 5055 / webhook a http: // rasa-actions: 5055 / webhook.Ahora inicia el servicio Rasa:

$ docker-compose up -d

El servicio de Rasa ahora está esperando conexiones.

Agrega capacidades de voz a Rasa

Este repositorio de Github incluye un conector personalizado basado en el conector Socket.io integrado de Rasa que agrega capacidades de Speech-To-Text y Text-To-Speech a Rasa.

Primero, clona el repositorio y copia la carpeta de conectores a la carpeta Rasa:

$ git clone https://github.com/codeforequity-at/botium-speech-processing.git
$ cd botium-speech-processing
$ cp -R connectors <rasa-dir>

En el archivo Connectors / rasa / credentials.yml, hay una configuración de muestra para el conector personalizado Rasa.

Puedes usar este archivo directamente o copiar la configuración del conector botium.SocketIOVoiceInput a su Rasa credentials.yml existente

Cambia el archivo para que apunte a tu ordenador para el procesamiento de voz (también inicia un conector REST por conveniencia y otras pruebas):

botium.SocketIOVoiceInput:
 socketio_path: /socket.io
 user_message_evt: user_uttered
 bot_message_evt: bot_uttered
 session_persistence: false
 botium_speech_url: http://localhost
 botium_speech_apikey:
 botium_speech_language: en
 botium_speech_voice: dfki-poppy-hsmmrest:

Luego, cambia el archivo docker-compose.yml para que Rasa use este conector.

version: ‘3.0’
services:
rasa:
image: rasa/rasa:latest-full
ports:
- 5005:5005
volumes:
- ./:/app
environment:
PYTHONPATH: “/app/connectors/rasa:/app”
RASA_DUCKLING_HTTP_URL: http://rasa-duckling:8000
command: run — cors “*” — credentials /app/connectors/rasa/credentials.yml — enable-api — model models/dialogue — endpoints endpoints.yml
rasa-actions:
build:
context: .
ports:
- 5055:5055
rasa-duckling:
image: rasa/ducklingports:
- 8000:8000

Reinicia Rasa para realizar los cambios en tus contenedores Docker.

$ docker-compose up -d

Pruebas

Hay un cliente de prueba simple basado en Rasa Voice Interface disponible en el proyecto Botium Speech Processing.

En el directorio conectores / rasa / client, cambia el endpoint de Rasa en el archivo docker-compose.yml:

version: ‘3’
services:
frontend:
build:
context: .
args:
RASA_ENDPOINT: http://localhost:5005
RASA_PATH: /socket.io
PUBLIC_PATH: /
image: botium/botium-speech-rasa-voice
restart: always
ports:
- 4700:8080

Luego, inicia el sitio web con “docker-compose up -d” y accede a la interfaz web en http: // localhost: 4700 para iniciar una conversación con tu bot en Rasa.

La interfaz de voz en acción

¡Ahora es el momento de utilizar el micrófono y los altavoces y charlar con Rasa!

The post Dando voz a Rasa con Botium Speech first appeared on Planeta Chatbot.