Tabla de contenidos
Introducción
La digresión es una parte común y natural de la mayoría de las conversaciones. El orador, introduce un tema, posteriormente el orador puede introducir una historia que parece no estar relacionada. Y luego vuelve al tema original.
La digresión también se puede explicar de la siguiente manera: cuando un usuario está en medio de un diálogo, también se refiere al customer journey, al tema o a la historia del usuario.
Y, está diseñado para lograr un único objetivo, pero el usuario decide cambiar bruscamente de tema para iniciar un flujo de diálogo que está diseñado para abordar un objetivo diferente.
Por lo tanto, el usuario quiere saltar a mitad de camino de un viaje o historia a otro completamente diferente. Esto normalmente no es posible dentro de un Chatbot, y una vez que el usuario se ha comprometido con un viaje o tema, tiene que terminarlo para poder empezar otro. Normalmente, el diálogo no admite esta posibilidad de que un usuario cambie de tema.
A menudo, un intento de divagar por parte del usuario termina con un “lo siento” del chatbot y rompe el viaje actual.
Por lo tanto, el marco de trabajo del chatbot que estás utilizando, debe permitir la digresión y las salidas, para salir y volver a una conversación.
Por ejemplo, el usuario podría estar pidiendo un nuevo teléfono, pero cambia de tema para preguntar sobre las tabletas. Su diálogo puede responder a la pregunta sobre las tabletas y luego devolver al usuario al punto en el que salió del recorrido del cliente para pedir un teléfono.
Este enfoque ofrece al usuario una verdadera experiencia de conversación no estructurada, pudiendo cambiar de un tema a otro. Esto es análogo a una conversación humana. Por lo tanto, el usuario puede cambiar de tema, siguiendo una ruta de diálogo o viaje sobre el tema no relacionado hasta su final, y luego volver a donde estaba antes.
De nuevo, esto simula una verdadera conversación natural entre humanos.
¿Por qué los marcos de desarrollo de Chatbot no se escalan bien?
Una característica de Cognigy es que a menudo hay múltiples formas de implementar un principio conversacional. Inicialmente, esto puede parecer una sobrecarga, pero el principio cobra sentido cuando se trata de escalar.
Muchos marcos de desarrollo de IA conversacional no escalan bien debido principalmente a dos razones.
La primera es la ausencia de posibilidades de diseño y desarrollo. Este es el caso de los entornos sin código y de bajo código. Hay casos en los que una determinada implementación de diseño no se puede llevar a cabo debido a la ausencia de elementos del lienzo de diseño/desarrollo.
Obviamente, los entornos pro-código no sufren de este mal, pero entonces hay otros desafíos.
Cuando el entorno de no-código/bajo-código no tiene la asequibilidad para una determinada implementación, hay que improvisar las características existentes. Y mediante la improvisación se consigue la experiencia de usuario deseada. Sin embargo, aquí es donde surgen los impedimentos para escalar y hacer crecer la experiencia conversacional.
El segundo escenario es tener una sola forma de hacer las cosas, y este es el enfoque más común; tener una sola forma de hacer las cosas.
Tener una sola posibilidad de diseño/desarrollo por cada reto de conversación y escenario percibido es justo. Pero tener más de una asequibilidad u opción posible para abordar un reto de diseño da a los desarrolladores/diseñadores la oportunidad de abordar los retos con configuraciones específicas de funcionalidad.
Por ejemplo, si se abordan 10 retos de diseño con 3 opciones o enfoques cada uno, el número de formas de resolverlos crece exponencialmente. Y esto contribuye a la escalabilidad del entorno.
Teniendo en cuenta todo esto… Cognigy tiene tres enfoques:
Got To Flow Node
El Got To Flow Node, o nodo de flujo en lenguaje, Cognigy, permite que el diálogo salte a otro flujo. Este salto, obviamente, se basa en una determinada condición que debe cumplirse.
No sólo se puede definir el flujo de destino, sino también el nodo de destino. El diálogo puede continuar, o ser configurado para esperar la entrada del flujo de destino.
Existe la opción de “Absorber el Contexto del Flujo de destino en el Contexto actual“. Esto depende realmente de si se ve la digresión de la conversación actuada por el Go To como una nueva conversación o una digresión.
En el ejemplo siguiente, puedes ver que a la izquierda el contexto del flujo de destino es absorbido por el contexto actual. A la derecha no es el caso.
Un requisito del mundo real podría ser si tú ves la digresión de un flujo a otro como una conversación, y más bien quieres mantener el contexto separado.
En VoiceXML y otros entornos existe la noción de subdiálogo, donde el diálogo se envía a un subdiálogo y posteriormente se devuelve al diálogo que lo llama.
Esto es útil para usar los subdiálogos como extensiones, funciones o componentes que pueden ser llamados y luego el diálogo regresa. No es así como está diseñado el Nodo Go To Flow. Sin embargo, se puede hacer algo similar con el nodo Execute Flow.
Execute Flow
Aquí tenemos un Execute Flow donde se ejecuta a través de un Flujo llamado una vez y luego se inicia de nuevo el Flujo original.
Esto es análogo a los subdiálogos en VoiceXML, donde se llama a una rutina y se devuelve el control al flujo llamado.
Los flujos pueden actuar como funciones, con el objetivo específico de ser reutilizados por otros flujos conversacionales más grandes. Esto recuerda al modo en que IBM Watson Assistant pretendía inicialmente utilizar las Action Skills dentro de las Dialog Skills.
Como se ha visto anteriormente, el flujo al que se llama se define con el nodo específico en el que debe caer la conversación. Una vez que el nodo se ejecuta, el control se devuelve al nodo llamante.
Attach Flow
Los flujos pueden simplemente adjuntarse entre sí, para reconocer los intentos construidos en otros lugares.
El Attach Flow está unido a la NLU de branches. Esto significa que, desde el flujo de branches, el usuario puede hacer una digresión a las ramas. Este es un buen enfoque si sospechas o ves que los usuarios quieren divagar de una intención a otra.
Arriba, una conversación en la que el usuario puede pasar del flujo de saldos al flujo de sucursales. El usuario no puede retroceder ya que la NLU de ramas no tiene saldos adjuntos.
Conclusión
El enfoque fácil es estructurar la conversación muy firmemente desde la perspectiva del chatbot. Y canalizar al usuario dentro y fuera de la interfaz conversacional, esto podría incluso presentarse muy favorablemente en los informes. Pero la experiencia del usuario es pésima.
La estructuración excesiva de la conversación rompe la belleza de una interfaz conversacional. Las interfaces conversacionales no estructuradas son difíciles de elaborar, pero permiten una experiencia de usuario excepcional.
Una de las razones es que los usuarios están tan acostumbrados a tener que estructurar su entrada, que quieren disfrutar y ejercer la libertad de expresión (hablada o de texto), lo que puede llevar a la decepción si no se cumplen las expectativas de libertad.
La digresión es una parte importante de la conversación humana, junto con la desambiguación, por supuesto. La desambiguación anula en cierta medida el peligro de la proliferación de retroceso en la que el diálogo no avanza realmente.