Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the all-in-one-seo-pack domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/planetac/desa.planetachatbot.com/wp-includes/functions.php on line 6114

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wp-user-avatar domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/planetac/desa.planetachatbot.com/wp-includes/functions.php on line 6114
Algún día, todos los chatbots se construirán de esta manera - Planeta Chatbot

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 la salida de datos no coinciden uno a uno.

El modelo debe poder evaluar los datos recibidos y luego responder con los datos que mejor se ajusten a 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 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.

Este ejemplo muestra cómo IBM Watson Assistant intenta eliminar la ambigüedad de la entrada del usuario. Según la respuesta del usuario, el chatbot aprende automáticamente.

Los tres elementos de la arquitectura del chatbot que deben quedar en desuso son las intenciones, la gestión del diálogo de la máquina de estado 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.

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.

Pero más que una experiencia súper personalizada, queremos presentar un chatbot donde el usuario pueda 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 las plataformas de chatbot comerciales; ser:

  • Intenciones
  • Entidades
  • Respuestas de bot (también conocido como diálogo Script / Bot)
  • Gestión de la máquina de estado de diálogo

Permíteme explicarte…

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 IA son las intenciones, las máquinas de estado y las respuestas de los bots.

  • 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.).

Así que está claro que con estos tres niveles de rigidez, el progreso a los niveles 4 y 5 se ve seriamente impedido.

El escenario ideal es donde la entrada del usuario se relaciona directamente con una historia de machine learning que puede aprender y adaptarse a las conversaciones de los usuarios.

Rompiendo la rigidez de la arquitectura actual donde el machine learning solo existe al hacer coincidir la entrada del usuario con una intención y entidades.


1. 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 mejor cuadro de diálogo coincidente para 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 aprendizaje automático 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 puedes ver en la secuencia a continuación, el usuario ingresa «Estoy pensando en comprar un perro». se corresponde 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 intento 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.

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.


2. 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 las 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.

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.


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 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, que lo convierte en una demostración y un prototipo asombrosos, existen algunos escollos.

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 del ajuste fino de formularios y políticas y el uso de 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 efectiva. Sin atrapar a los usuarios en un entorno de código bajo sin la opción de ajustar y modificar el marco.

Por Cobus Greyling

Rasa Hero. NLP / NLU, Chatbots, Voz, UI / UX conversacional, Diseñador CX, Desarrollador, Interfaces de usuario ubicuas.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *