Tabla de contenidos
Introducción
Recientemente, NVIDIA lanzó Jarvis, que se describe como un marco de aplicación para la IA conversacional multimodal.
Jarvis incluye una solución de inteligencia artificial conversacional de alto rendimiento que incorpora señales visuales y de voz; un sistema que se conoce a menudo como velocidad facial. La velocidad facial incluye detección de mirada, actividad de labios, etc.
El aspecto multimodal de Jarvis se comprende mejor en el contexto de dónde NVIDIA quiere llevar a Jarvis en términos de funcionalidad.
La funcionalidad futura incluye:
- ASR (reconocimiento automático de voz).
- STT (voz a texto).
- NLU (comprensión del lenguaje natural).
- Reconocimiento de gestos.
- Detección de actividad labial.
- Detección de objetos.
- Detección de mirada.
- Detección de sentimiento.
Una vez más, lo emocionante de esta colección de funciones es que Jarvis está preparado para convertirse en un verdadero agente conversacional. ¿Pero por qué digo esto?
Chatbot de demostración de NVIDIA Jarvis Weather implementado en una AMI y al que se accede a través del túnel SSH
Nosotros, como humanos, nos comunicamos no solo con la voz, sino también detectando la mirada del hablante, la actividad de los labios, las expresiones faciales, etc.
Otro enfoque clave de Jarvis es el transfer learning o aprendizaje por transferencia. Hay un ahorro de costos significativo cuando se trata de tomar los modelos básicos avanzados de Jarvis y reutilizarlos para usos específicos.
La funcionalidad que está disponible actualmente en Jarvis 1.0 Beta incluye:
- Reconocimiento automático de voz (ASR / STT).
- Síntesis de voz (TSS).
- Procesamiento y comprensión del lenguaje natural (NLU).
Gestión del diálogo Jarvis
Al revisar la documentación y la demo, no hay duda sobre la capacidad ASR, TSS y NLU de Jarvis. Considerando elementos como el transfer learning y la velocidad del entrenamiento.
Sin embargo, un elemento que actualmente no está claramente definido es cómo se implementará Dialog Manager(DM) y cómo funcionará la interfaz de desarrollo de diálogo.
Entonces, hasta el momento, la función de desarrollo y administración de NVIDIA Jarvis Dialog está en desarrollo y aún no se ha lanzado.
La aplicación de muestra Asistente virtual (con Rasa) (https://docs.nvidia.com/deeplearning/jarvis/user-guide/docs/samples/rasa.html) muestra cómo Jarvis ASR, TTS y NLU se pueden usar con el Administrador de diálogo Rasa.
La gestión de diálogo, también conocida como gestión de estado o gestión de flujo de conversación, será diferente para Jarvis que para otros entornos de conversación.
La razón de esto es que Jarvis es una interfaz conversacional multimodal que no solo tendrá entrada de voz/texto. Pero también identificación del hablante, detección de miradas. También se conoce como look-to-talk.
Por lo tanto, multimodal se refiere a múltiples usuarios y también a la entrada de múltiples contextos y medios. Esto implica que el entorno Jarvis DM tendrá que ser más complejo que las interfaces tradicionales de conversación de texto y voz.
En cuanto a las herramientas Jarvis disponibles actualmente, el entorno de gestión de diálogo probablemente no será gráfico. Sino más bien un enfoque de configuración de texto como un archivo YML. Absorber la naturaleza multimodal de Jarvis en una estructura de diseño y desarrollo simplista será uno de los principales desafíos.
Como se mencionó, la multimodalidad de Jarvis necesitará una herramienta más compleja para satisfacer las demandas de entrada.
Entorno de gestión de diálogo
Como referencia, echemos un vistazo a cómo se ve el panorama actual de agentes conversacionales en términos de gestión y desarrollo de diálogos…
(En esta etapa, es posible que quieras pasar directamente a la conclusión). 🙂
Panorama actual de desarrollo y gestión de diálogos
Cuando diferentes proveedores y plataformas convergen en el mismo enfoque y principios básicos, es seguro asumir que es la forma más eficiente de hacerlo.
Al observar las grandes y emergentes plataformas de chatbots, todas convergen en dos aspectos clave:
- Intenciones.
- Entidades.
Hay elementos como el llenado de formularios o espacios, políticas, etc., que también son importantes. Pero a los efectos de esta historia, no nos centraremos en ella.
Intenciones
Las intenciones generalmente se definen con una descripción y algunos ejemplos de formación o expresión.
Los ejemplos de enunciados son lo que se espera que diga o diga un usuario. La intención que esperan haber cumplido.
Algunos entornos tienen características adicionales como la identificación de conflictos de intenciones y sugerencias de enunciados.
Entidades
Las entidades son los sustantivos que ingresa el usuario, a menudo múltiples entidades compuestas en una expresión de usuario.
Anotación de entidad contextual en IBM Watson AssistantEl desafío aquí es extraer las entidades cuando el usuario las pronuncia por primera vez.
La mayoría de los entornos pueden extraer entidades compuestas y también entidades contextuales.
Entonces, las entidades compuestas y contextuales están siendo implementadas por más plataformas de chatbot.
La opción de anotar entidades contextualmente también está en aumento. A menudo, las entidades tienen un conjunto finito de valores que se definen. Luego están las entidades que no se pueden representar mediante una lista finita; como ciudades del mundo o nombres o direcciones.
Estos tipos de entidad tienen demasiadas variaciones para enumerarse individualmente.
Creación de diálogos: desarrollo y gestión
El área donde hay una divergencia más que una convergencia es la de Desarrollo y
Gestión del Diálogo.
Lo que significa que, para algunos, el veredicto aún está por determinar cuál es el enfoque ideal…
Creación de diálogo
El componente de diálogo tiene la responsabilidad de gestionar el estado de la conversación, paso a paso. Esto también se conoce como máquina de estado, flujo de diálogo (en términos genéricos y no como plataforma de Google), diseño de conversación o gestión de diálogo.
Es necesario señalar que algunos entornos tienen una clara separación entre su componente NLU y los componentes centrales o de diálogo. Rasa, Microsoft y AWS entran en esta categoría.
IBM Watson Assistant tiene el enfoque opuesto donde los dos realmente se fusionan.
A continuación, analizo cuatro enfoques distintos que se siguen actualmente en el mercado de chatbot para la creación y gestión de diálogos.
1. Diseño Canvas
Un entorno de canvas de diseño es parte integral del nuevo entorno de diseño de Bot Society.
En el entorno de Botsociety, los diseños se pueden implementar en soluciones como Rasa, Microsoft Bot Framework y más.
Es evidente que Botsociety se está volviendo cada vez más técnico y complejo.
Claramente, el producto está en proceso de transformarse de una herramienta única de diseño, presentación y prototipo a una herramienta de desarrollo de conversaciones.
Puedes optar por exportar su diseño a:
- Bot Framework / Azure.
- Dialogflow.
- Rasa.ai.
- O tener la propia base de código (API).
Dialogflow CX también aprovecha este enfoque de lienzo en el que puede trazar una conversación compleja y expandir páginas o nodos conversacionales.
Google Dialogflow CX: Interfaz de desarrollo de diálogos donde se administra el estado de la conversación.
En este enfoque es fácil de iniciar un proyecto de chatbot y los diseñadores se sienten cómodos al principio.
Pero a medida que crece la complejidad, el escalado y la gestión se ven afectados.
Las ventajas de este enfoque son:
- Facilidad de colaboración.
- Panorámica y visualización del diseño.
- Acercar y alejar para ver más o menos detalles.
- Combinación del proceso de diseño y desarrollo.
- Adecuado para creación rápida de prototipos y creación conjunta.
Las desventajas de este enfoque son:
- Complejidad de grandes implementaciones.
- Gestión de cambios y evaluaciones de impacto.
- Resolución de problemas e identificación de puntos de interrupción de la conversación.
- Múltiples condiciones por nodo de diálogo que se ven afectadas cuando cambian los parámetros.
2. Configuración de diálogo
Puedes preguntarte cuál es la diferencia entre un lienzo de diseño y una configuración de diálogo…
La configuración de diálogo es un enfoque en el que no tienes un lienzo para diseñar, pero los nodos conversacionales se definen gráficamente.
Estos nodos de diseño son lineales y el entorno de desarrollo es más rígido y secuencial.
Dentro de cada nodo de diálogo se establecen las condiciones y la conversación puede saltar hacia arriba o hacia abajo dentro de la secuencia, lo que puede generar confusión.
IBM Watson Assistant sigue este principio de diseño.
Se pueden establecer condiciones para cada nodo de diálogo y definir ciertos resultados. Dialogflow ES también recuerda un enfoque de configuración de diálogo más junto con Microsoft Composer. Los agentes virtuales de Microsoft Power también se basan en un enfoque de configuración de diálogo.
Microsoft Bot Framework Composer: interfaz de diseño de flujo
Las ventajas de este enfoque son:
- Presentación un poco más condensada de la conversación.
- La naturaleza restrictiva prohíbe los cambios impulsivos.
- De naturaleza más técnica con diferentes niveles de configuración.
- Adecuado para la creación rápida de prototipos.
Las desventajas de este enfoque son:
- Difícil de presentar y realizar un recorrido
- Para conversaciones más amplias, existe una complejidad creciente y referencias cruzadas.
- Conciencia de cómo los cambios de parámetros y configuraciones se producirán en cascada.
- No es adecuado como herramienta de diseño de conversaciones.
3. Código nativo
El código nativo defiende un entorno altamente flexible y escalable. Las soluciones que me vienen a la mente en esta categoría son Amazon Lex y, en cierta medida, las habilidades de Alexa.
Pero especialmente Microsoft Bot Framework que se ejecuta en código nativo. La ventaja aquí es que se puede usar código no propietario. En el caso de Microsoft Bot Framework, se puede utilizar C # o Node.js. En el caso de las habilidades de Lex o Alexa; Funciones Lambda, lo más probable es que utilice Node.js o Python.
El código nativo le brinda mucha más agilidad y flexibilidad. Aunque existe un abismo entre el diseño y la implementación. Aquí es necesario establecer una comprensión compartida y se inhibe la cocreación.
También hay soluciones que utilizan código de propiedad para el diálogo, como Oracle con su BotML.
Las ventajas de este enfoque son:
- No propiedad en términos de lenguaje del entorno de desarrollo.
- Flexible y adaptable a los cambios de escala (en principio)
- Se requieren habilidades específicas no dedicadas o conocimientos específicos.
- Portar el código, o incluso reutilizarlo.
Las desventajas de este enfoque son:
- El diseño y la implementación están muy alejados el uno del otro.
- La interpretación del diseño puede ser un desafío.
- Se requerirá otra herramienta de diseño, probablemente dedicada.
- La complejidad de administrar diferentes permutaciones en el diálogo aún debe existir; dentro del código.
4. ML Stories
Aquí Rasa se encuentra solo en esta categoría; inventado y promovido por ellos. Donde aplican ML, y el marco calcula el próximo nodo conversacional probable a partir de historias de usuarios.
stories: - story: collect restaurant booking info # name of the story - just for debugging steps: - intent: greet # user message with no entities - action: utter_ask_howcanhelp - intent: inform # user message with no entities entities: - location: "rome" - price: "cheap" - action: utter_on_it # action that the bot should execute - action: utter_ask_cuisine - intent: inform entities: - cuisine: "spanish" - action: utter_ask_num_people
Ejemplo de historias de: #https: //rasa.com/docs/rasa/stories. 👆
El enfoque de Rasa parece bastante contrario a la intuición… en lugar de definir condiciones y reglas para cada nodo, el chatbot se presenta con conversaciones reales.
Luego, el chatbot aprende de estas secuencias de conversación para gestionar futuras conversaciones.
Estas diferentes conversaciones, denominadas Rasa Stories, son los datos de entrenamiento empleados para crear los modelos de gestión de diálogo.
Se pueden incorporar espacios y formas… y la idea de si CDD (Desarrollo impulsado por la conversación) apunta a la mejora continua de los modelos.
Rasa-X: interfaz de diseño basada en conversaciones
Las ventajas de este enfoque son:
- Todo el mundo sabe que la máquina de estados debe quedar obsoleta; esto logra eso.
- El tiempo de formación es razonable.
- No se requiere hardware específico o dedicado.
- No se requieren expertos en ML ni científicos de datos dedicados… es decir, Inteligencia Artificial para todos los que lo deseen.
- La complejidad está oculta en una presentación simplista.
Las desventajas de este enfoque son:
- Este enfoque puede parecer abstracto e intangible para algunos.
- Aprehensión en casos en los que sea necesario recopilar datos obligatorios. O donde la legislación dicta condiciones. Sin embargo, aquí entran en juego las políticas de formulario.
Conclusión
Jarvis está llevando el aprendizaje profundo a todos los perfiles. Teniendo en cuenta la potencia de procesamiento y la optimización de Jarvis con la GPU NVIDIA basada en su arquitectura Turing o Volta, un enfoque de aprendizaje automático parece más plausible. De ahí un escenario en el que se definen las posibles vías de conversación. Los elementos que deben incorporarse en el entorno de gestión del diálogo son la digresión, la desambiguación y la negación de la proliferación de reserva.
Considerando que los giros de diálogo se pueden iniciar con gestos, una mirada; entrada no definitiva.
Sin embargo, las señales no habladas o de texto o la entrada no explícita plantearán un desafío y definitivamente agregarán complejidad.
El transfer learning podría utilizarse para ciertas industrias, y podría estar disponible un paquete de inicio de estado de diálogo, para banca, seguros, telecomunicaciones, atención médica, etc., por ejemplo.
Jarvis será un servicio vivo. Vivir en el entorno del usuario y salir a la superficie a través de diferentes dispositivos y entornos (automóvil, hogar, oficina, teléfono, etc.). Esto conduce a un fenómeno conocido como orquestación ambiental. Donde se detectan patrones en el comportamiento del usuario y se muestra información específica en el momento y lugar y dispositivo correctos. Por lo tanto, estos servicios vivos se orquestaron siguiendo los puntos de contacto del usuario.
Esto, junto con la entrada multimodal, se inclinará en gran medida hacia un enfoque de ML.