GeneXus Chatbots Generator

En GeneXus estamos desarrollando un generador, que permita crear con facilidad un chatbot para ser integrado en aplicaciones para Smart Devices y Web; y también con las diferentes plataformas de mensajería existentes. Además siempre basándonos en que su definición pueda ser utilizada para los distintos providers del mercado (Watson Conversation, Dialogflow, Amazon Lex).

¿Cómo logramos esto? En el camino del desarrollo de este generador, lo primero que hicimos fue estudiar a fondo el funcionamiento de los diferentes providers, para poder generar una “capa de abstracción” que cubra todos los campos que manejan estos servicios. Para ser más claro, buscamos los puntos en común de cada uno, para que el punto de acceso, sea uno: GeneXus. Entonces, de esta manera logramos ser independientes de los proveedores a la hora de “crear” nuestro bot.

Ahora, ¿cómo logramos unificar la forma de definir un bot en GeneXus? Bueno, para eso decidimos crear un nuevo objeto: el Conversational Flows.

El Conversational Flows se instancia de forma independiente, y desde él se referencia a los objetos de nuestra base de conocimiento con los que queremos trabajar. Este objeto contiene diferentes elementos que ayudan a definir los distintos flujos que pensamos para el chatbot.

Veamos un poco sobre los principales elementos y propiedades, más adelante compartiré el enlace a la documentación del Chatbots Generator, en el que se puede ver con más profundidad cómo funciona cada elemento.

Flow

Es el principal elemento del Conversational Flows, se pueden agregar múltiples nodos Flow. Este nodo, se mapea a los proveedores como la representación de una intención.

Conversational Object

No es un elemento en realidad, sino que es una propiedad del nodo Flow. Al asignar un objeto en esta propiedad, el objeto asignado será el “Resolver” de la intención. Es decir, al culminar el flujo necesario para cumplir con la intención, se pasarán todos los datos a este objeto, el cuál podrá devolver una respuesta. Hoy, pueden ser Conversational Object los siguientes objetos: Transactions, Data Providers, Procedures, Web Panels y SD Panels.

User Input

Representan a los parámetros de entrada de un flujo, es decir los diferentes parámetros por los que el chatbot le va a preguntar al usuario cuando detecte la intención relacionada al flujo al que corresponden.

User Input Condition

Son condiciones que se ejecutan cuando el usuario ingresa datos para los parámetros. En base a estas se pueden realizar distintas acciones (redirigir la conversación a otro flujo o simplemente requerir o no un parámetro).

Response

Este nodo agrupa las diferentes posibles respuestas definidas para que el chatbot conteste al terminar con el flujo. En cada una de estas respuestas (Nodo Message), se podrán definir las condiciones que se tienen que dar para que sean ejecutadas. Estas condiciones, al igual que las de los User Input Conditions, se basan en los datos que está manejando el contexto en el momento de realizar la comparación lógica.

Los Response Messages pueden tener diferentes estilos, es decir pueden ser simplemente un mensaje de texto, una redirección a otro flujo o un componente. Con componente nos referimos a que se puede renderizar un SDPanel o un Web Panel, que muestre la información en pantalla.

Pero mejor, los vamos viendo con un ejemplo. Imaginemos que necesitamos desarrollar un chatbot para un hospital ¿Sí?. Bien, en principio, nos solicitan que el chatbot cubra lo más básico, que sería saludar al usuario y explicarle en qué lo puede ayudar.

Para cumplir con estos primeros requisitos, no necesitamos siquiera de la asistencia de otros objetos GeneXus, simplemente agregamos a nuestra instancia un nodo Flow que va a saber saludar, pero con el detalle de que le vamos a preguntar el nombre al usuario para que ya tengamos esa referencia y de esta manera, más adelante poder llevar una conversación más personalizada.

Bien, con ese pequeña interacción con el Conversational Flows logramos tener un chatbot que sabe preguntarnos nuestro nombre e informarnos acerca de sus capacidades. Pero le falta más, vamos a ver un ejemplo en el que nos pregunten qué doctor está de guardia.

¿Cómo podríamos resolver esto? Es una consulta que en GeneXus la podríamos resolver con un Data Provider. Entonces, si tenemos un Data Provider, que nos devuelve el doctor que está de guardia, podemos simplemente agregar un Flow a nuestra instancia del Conversational Flows y en su propiedad Conversational Object, seleccionamos el Data Provider en cuestión.

Entonces, GeneXus nos va a agregar automáticamente los user inputs y los response parameters a nuestro flujo. Como no queremos que responda solamente con texto, vamos a seleccionar que el style de la respuesta es un component view. En este caso, como no seleccionamos un SDPanel o un Web Panel específico, GeneXus generará automáticamente objetos de ambos tipos que puedan renderizar la respuesta de la forma solicitada.

0.jpg

Una vez generado, lo volvemos a probar:

11

Como podemos ver, nos muestra en pantalla un componente en el que vemos los datos del doctor, una foto, nombre, apellido y especialidad.

En este artículo no vamos a seguir viendo cómo implementar todas las posibilidades que nos brinda el Chatbots Generator, para profundizar más en el tema se puede leer su documentación aquí.

Bien, ahora que vimos el “¿cómo?” una pregunta interesante es el “¿qué?”, es decir ¿qué es lo que generamos para que esto funcione?

Lo que el Chatbots Generator genera, lo podemos dividir en tres partes, user interfaces, backend y “provider side”.

En cuanto a las user interfaces se generan los clientes Web y Smart Devices necesarios para comunicarse con el chatbot. Y cuando hablamos de interfaz de usuario, seguramente surge la gran duda: y qué pasa con Messenger? y Slack? Sí, en principio la integración con estas plataformas de mensajería está soportada por los mismos proveedores, y en el caso de que no estén soportadas, nosotros vamos a ir integrándolas al generador.

Por el lado del backend, lo que vamos a tener son los servicios necesarios para que nuestra capa de servicios pueda recibir las consultas del cliente y enviárselas al provider, o recibirlas de parte del provider, dependiendo del servicio elegido para generar. También tenemos los objetos necesarios para que nuestro bot se pueda comunicar con los objetos que definimos en el Conversational Flows como “conversational objects”.

En lo que llamamos “provider side”, generamos la estructura que se puede importar hacia el proveedor, es decir generamos un archivo que contiene las intenciones, las entidades y los “diálogos” que va a saber manejar nuestro bot.

Saliendo un poco del funcionamiento del generador, me gustaría hacer una mención a RUDI y a Clarita, nuestros asistentes en el GX27. ¿Por qué? Porque estos dos chatbots fueron generados con el Chatbots Generator.  En el caso de RUDI, se aplicó el Conversational Flows sobre la base de conocimiento existente para la aplicación del evento. Obviamente que también hubo que implementar el diseño y algunas particularidades específicas de la aplicación. En el caso de Clarita, se realizó un procedimiento similar, solo que se utiliza otra interfaz de usuario, que no es la generada por nuestro generador.

Entonces, ¿qué ganamos con usar este generador?

Podemos dedicarnos a pensar en qué es lo que queremos que nuestro chatbot sepa responder, qué objetos queremos que trabajen con él, sin tener que preocuparnos por la generación de los servicios, ni por tener que armar la estructura en el proveedor, ni por tener que programar la interfaz de usuario. Acortamos mucho el tiempo de desarrollo, permitiendo que incluso se pueda contar con mayor tiempo para el entrenamiento del chatbot.

Para finalizar, me gustaría invitarlos a probar el generador que está disponible en estos momentos en una de sus primeras versiones en GeneXus Tero y a unirse a Google Groups 

Más información en el siguiente enlace: http://genexus.com/tero

One thought on “GeneXus Chatbots Generator

Leave a Reply

%d bloggers like this: