Tabla de contenidos
Introducción
En términos simples, la idea detrás de un modelo de machine learning es recibir datos y devolver datos. Lo que debería hacer que sea diferente es que la entrada y salida de datos no es una coincidencia uno a uno.
El modelo debe poder evaluar los datos recibidos del usuario y, a su vez, responder con los datos que mejor coincidan con la entrada del usuario.
Por lo tanto, existe un proceso de evaluación y se crea una lista de los mejores ajustes con diferentes puntajes de confianza.
Lo ideal para una implementación de IA conversacional es tener este nivel de flexibilidad en las diferentes capas de la pila de tecnología.
Donde un usuario puede dar su entrada al chatbot, y el chatbot da la mejor respuesta. Cada turno de diálogo se basa en el siguiente paso más probable en la conversación. Manteniendo el contexto y la continuidad a lo largo de la conversación.
Los tres elementos de la arquitectura del chatbot que deben quedar obsoletos en algún momento son la gestión del diálogo de la máquina de estado, las intenciones y las respuestas del bot.
Esto a menudo se conoce como un agente conversacional de nivel 4 y 5, que ofrece interacciones de lenguaje natural compuesto sin restricciones.
Obviamente dentro del dominio de implementación del chatbot.
El status quo actual del chatbot se encuentra entre el reconocimiento de palabras clave y la intención estructurada y la coincidencia de entidades.
Pero, ¿qué es un chatbot de nivel 4 y 5?
Observaciones generales sobre los chatbots de nivel 4 y 5
Rasa describe un chatbots de nivel 4 de la siguiente manera:
Un asistente de nivel 4 te conocerá mucho más en detalle. No es necesario que pregunte todos los detalles y, en su lugar, verifica rápidamente algunas cosas finales antes de brindarle un presupuesto adaptado a su situación real.
Y, más que una experiencia súper personalizada, queremos presentar un chatbot donde el usuario puede tener:
- completamente natural
- conversación no estructurada
- y donde la conversación es dinámica.
Prácticamente, para tener un verdadero chatbot o agente conversacional de Nivel 4 y 5, es necesario eliminar las capas de restricción y rigidez. En otras palabras, las capas rígidas que introducen este enfoque directo requieren una depreciación.
Se puede decir que tradicionalmente los chatbots, o agentes de IA conversacionales, están constituidos por una arquitectura de cuatro pilares.
Esta arquitectura es muy universal en todas las plataformas de chatbot comerciales; ser:
- Intenciones
- Entidades
- Respuestas de bot (también conocido como diálogo Script / Bot)
- Gestión de máquinas de estado de diálogo
Los cuatro pilares de la arquitectura tradicional de chatbot. Para un chatbot de nivel 4/5, es necesario eliminar la rigidez en Intents, Bot Responses y Dialog State Management. Como también se muestra en la imagen a continuación…
Como se ve aquí, hay dos componentes; el componente NLU y el componente de gestión de diálogo. En el caso de Microsoft, Rasa, Amazon Lex, Oracle, etc., la distinción y separación entre estos dos es clara y pronunciada. En el caso de IBM Watson Assistant, no es el caso.
El componente NLU está constituido por intenciones y entidades. Y el componente Dialog por las respuestas del bot y la máquina de estado.
Los tres impedimentos para que los chatbots se conviertan en verdaderos agentes de inteligencia artificial son las intenciones, las máquinas de estado y las respuestas de los bots.
Las tres áreas de rigidez están indicadas por las flechas, como se analiza aquí.
- Por ejemplo, la expresión de un usuario se asigna a una única intención predefinida.
- A su vez, se asigna una única intención a un punto de entrada dentro de una máquina de estado rígida para que el bot responda.
- La máquina de estado tiene una respuesta codificada al usuario para cada nodo de diálogo conversacional. A veces, la redacción de la devolución tiene variables integradas para tener algún elemento de respuesta personalizada.
Las intenciones pueden verse como verbos o intenciones de usuario y las entidades como sustantivos (ciudades, fechas, nombres, etc.).
Por lo tanto, está claro que con estos tres niveles de rigidez, el progreso a los niveles 4 y 5 se ve seriamente obstaculizado.
El escenario ideal es donde la entrada del usuario se relaciona directamente con una historia de aprendizaje automático que puede aprender y adaptarse a las conversaciones de los usuarios.
Rompiendo la rigidez de la arquitectura actual donde el aprendizaje automático solo existe al hacer coincidir la entrada del usuario con una intención y entidades.
1. Gestión del estado de la conversación
Si bien el modelo NLU es un modelo de machine learning, donde hay un sentido de interpretación del lado del modelo NLU de la expresión del usuario, y las intenciones y entidades se asignan a la entrada del usuario…
La expresión del usuario se asigna a una intención. A su vez, la intención está vinculada a un punto particular de la máquina de estados.
A pesar de que el modelo no fue entrenado en esa expresión específica…
Este no es el caso con Conversation State Manager, también conocido como el sistema de flujo de diálogo.
En la mayoría de los casos, se trata de un enfoque de árbol de decisiones, en el que se evalúan las intenciones, las entidades y otras condiciones para determinar el siguiente estado de diálogo.
La conversación del usuario está dictada por este flujo rígido y predeterminado con condiciones y lógica que activan un nodo de diálogo.
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 en: #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.
2. Intenciones
La depreciación intencionada ha sido introducida por Rasa, IBM, Microsoft y Alexa. Incluso aunque solo sea en una capacidad experimental y limitada.
La razón detrás de esto es que generalmente se define una lista finita de intenciones.
Posteriormente, cada solicitud de usuario debe ser asignada o emparejada con una única intención predefinida. Esta es una ardua tarea para segmentar el dominio de interés del chatbot en diferentes intenciones.
Al mismo tiempo, se asegura de que no haya superposiciones o lagunas con las intenciones definidas. Pero, ¿y si pudiéramos pasar directamente de la expresión del usuario al significado? ¿Al cuadro de diálogo que mejor coincide con el enunciado del usuario?
Tradicionalmente, todas y cada una de las entradas imaginables del usuario deben asignarse a una intención particular. Durante la revisión de la transcripción, si la entrada del usuario no coincide perfectamente con una intención existente, es necesario inventar una.
Esta capa estrecha de categorizar la expresión de un usuario de acuerdo con una intención es rígida e inflexible en el sentido de ser un conjunto de categorías que maneja la conversación.
Por lo tanto, dentro de un chatbot, la primera línea de facilitación de la conversación es el reconocimiento de intenciones.
Y aquí radica el desafío, en la mayoría de las plataformas de chatbots hay un modelo de machine learning que se utiliza para asignar la expresión de un usuario a una intención específica.
Las intenciones también son una capa rígida dentro de un chatbot. Cualquier entrada concebible del usuario debe anticiparse y asignarse a una única intención.
Y desde aquí, la intención está vinculada a un punto específico en la máquina de estado (también conocido como árbol de diálogo). Como puede ver en la secuencia a continuación, el usuario ingresa “Estoy pensando en comprar un perro”. coincide con la intención Buy Dog. Y desde aquí, las intenciones están codificadas en puntos de entrada de diálogo.
Las intenciones también son una capa rígida dentro de un chatbot. Cualquier entrada concebible del usuario debe anticiparse y asignarse a una única intención.
Nuevamente, la lista de intenciones es rígida y fija. Posteriormente, cada intent se vincula a una parte del cuadro de diálogo predefinido.
La entrada del usuario se corresponde con una intención. La intención identificada es parte de una lista fija de intenciones. A su vez, cada intento se asigna a una parte del diálogo.
La entrada del usuario se corresponde con una intención. La intención identificada es parte de una lista fija de intenciones. A su vez, cada intento se asigna a una parte del diálogo.
Pero, ¿qué pasa si la capa de intenciones puede quedar obsoleta y la entrada del usuario se puede asignar directamente al cuadro de diálogo?
Este desarrollo es crucial para pasar de un bot de mensajería a una interfaz de IA conversacional.
Esta capa de intenciones es también una capa de traducción que enturbia las aguas de la conversación.
Tener intenciones opcionales y ejecutar los dos enfoques en paralelo permite que la conversación use o evite las intenciones.
3. Cuadro de diálogo Chabot Text o Return (NLG)
La generación de lenguaje natural es la desestructuración de datos estructurados en un formato conversacional.
El guion o diálogo que el chatbot devuelve y presenta al usuario también está bien definido y es rígido.
La reseña del restaurante se crea a partir de unas pocas palabras clave y el nombre del restaurante.
La redacción devuelta por el chatbot está muy vinculada uno a uno, a un nodo de estado de diálogo específico.
Con cada nodo de diálogo teniendo una respuesta establecida.
GPT-3 busca cambiar esto, y han depreciado estos tres elementos.
No hay necesidad de entidades definidas, la gestión del estado del diálogo y el contexto de la conversación, simplemente sucede.
Y, por último, el diálogo de retorno o la redacción están obsoletos con la generación de lenguaje natural en tiempo real (NLG).
Si bien GPT-3 ha dado este salto, lo que lo convierte en una demostración y un prototipo asombrosos, existen algunas dificultades.
Algunas trampas son:
- En algunos casos, se requiere una gran cantidad de datos de entrenamiento.
- Las aberraciones en NLG pueden resultar en una mala experiencia de usuario.
- Es posible que se pierdan el tono, la personalidad del bot y la calidad de las respuestas.
Conclusión
De hecho, GPT-3 ha depreciado estos tres elementos, las intenciones, la gestión del estado del diálogo y el texto / diálogo de respuesta del bot.
Pero a costa de ajustar formularios y políticas y utilizar una pequeña cantidad de datos de capacitación.
Es necesario encontrar un equilibrio, donde la complejidad bajo el capó, surja a través de una interfaz de desarrollo simple y eficaz. Sin atrapar a los usuarios en un entorno de código bajo sin la opción de ajustar y modificar el marco.