Introducción

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 llenado de formularios o slots, políticas, etc. que también son importantes. Pero a los efectos de esta historia, no nos centraremos en ellos.

Intenciones

Las intenciones generalmente se definen con una descripción y algunos ejemplos de formación o expresión.

Rasa Chatbot Framework: ejemplo de intención con entidades contextuales definidas.

Los ejemplos de inputs 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 expresiones.

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 Assistant

El 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álogo: 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 sobre qué enfoque es ideal aún no está claro…

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 state machine, 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ónentre 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. Design Canvas

Un entorno de lienzo de diseño es parte integral del nuevo entorno de diseño de BotSociety.

En el entorno Botsociety, los diseños se pueden implementar en soluciones como Rasa, Microsoft Bot Framework y más.

Es evidente que Botsociety se está volviendo más técnica y compleja.

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 conversación.

Puedes optar por exportar tu diseño a:

• Bot Framework / Azure
• Dialogflow
• Rasa.ai
• O poseer código base (API)

Dialogflow CX también aprovecha este enfoque de lienzo en el que puedes 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.

Con 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 aumenta 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. Dialog Configuration

Puedes preguntar cuál es la diferencia entre un lienzo de diseño y una configuración de diálogo…

IBM Watson Assistant: Nodos de diálogo

La configuración de cuadros de diálogo es un enfoque en el que no tienes un lienzo sobre el que diseñar, pero los nodos de conversación 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.

Para cada nodo de diálogo se pueden establecer condiciones y se pueden 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 prototipos rápidos.

Las desventajas de este enfoque son:

• Difícil de presentar y realizar un recorrido.
• Para conversaciones más extensas, 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 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 utilizar 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 un entendimiento compartido 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. Historias de AA

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) apuntala 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 … IA para las masas.
• 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 es necesario recopilar datos obligatorios. O donde la legislación dicta condiciones. Sin embargo, aquí entran en juego las políticas de formulario.

Conclusión

Se habla mucho de chatbots con o sin aprendizaje automático… Siempre hay cierto grado de aprendizaje automático cuando el entrenamiento se realiza sobre intenciones y entidades. Esto, lamentablemente, no se extiende al flujo y la gestión del diálogo; en la mayoría de los casos.