En esta nueva entrada nos introducimos y experimentamos con DialogflowCX, el framework de creación de agentes y chatbots de Google Cloud. Repasaremos los conceptos básicos para las configuraciones necesarias e iniciales para luego proceder a crear un primer chatbot de atención al usuario. También tienes a disposición el artículo sobre VertexAI y Dialogflow, una integración de IA que potencia y facilita enormemente la creación de chatbots. Vamos al lío.
Agentes virtuales con DialogflowCX
Repasaremos algunos conceptos clave. Utilizando Dialogflow CX puedes crear 2 tipos de agentes:
Steering Bots
Se centran en dirigir la conversación. Determinan la intención del usuario y lo guían al flujo, la página o incluso a otro agente virtual especializado en una tarea concreta.
Task-oriented Bots
Los agentes orientados a tareas están diseñados para completar acciones para el usuario (por ejemplo, reservar un vuelo, comprobar el estado de un pedido, responder a preguntas concretas).
Creando Steering Agents
Para tener una conversación guiada con el usuario utilizaremos los Steering Boots. Para crearlo podemos utilizar DialogflowCX.
Qué son las máquinas de estados
Una máquina de estados es un modelo computacional que representa el comportamiento de un sistema. Es como un diagrama de flujo en el que el sistema sólo puede estar en un «estado» específico a la vez, y realiza transiciones entre estados basándose en entradas y reglas predefinidas.
Dialogflow permite utilizar una arquitectura de máquina de estados para gestionar el flujo conversacional. Esto significa dividir las interacciones en estados definidos, con transiciones entre ellos activadas por la entrada del usuario y condiciones predefinidas. Este enfoque permite crear experiencias conversacionales dinámicas y conscientes del contexto.
Los componentes de la máquina de estados Dialogflow
Una conversación (o sesión) Dialogflow CX entre un usuario final y un agente virtual puede describirse y visualizarse como una máquina de estados. Los estados de una sesión CX se representan mediante páginas.
Se pueden combinar varias páginas en un flujo que puede representar un tema de conversación. En Dialogflow CX siempre se empieza creando un agente. Un agente puede tener varios flujos (temas de conversación).
El mecanismo clave que controla cómo su agente virtual navega por las conversaciones. Pueden hacerlo creando respuestas para los usuarios finales (cumplimiento) y/o cambiando de página (transición).
Una interacción entre el agente virtual y el usuario final se denomina «turno». Normalmente, un turno es una única ronda de comunicación entre el usuario y el agente virtual. El usuario dice algo, y el agente procesa la entrada y proporciona una respuesta. (Nota: a veces, una o ambas partes pueden permanecer en silencio durante su turno).
El agente virtual tiene multitud de tareas potenciales durante cada turno:
- Hacer preguntas: Pedir información al usuario.
- Comprender las respuestas: Procesar e interpretar las respuestas del usuario.
- Volver a preguntar: Volver a preguntar a un usuario cuando su respuesta anterior no ha sido plenamente satisfactoria.
- Decidir los próximos pasos: Determinar la acción apropiada.
Toda esta toma de decisiones se produce en el contexto del estado de una página.
Comprender al usuario: El modelo NLU
Un agente virtual utiliza la comprensión del lenguaje natural (NLU) para interpretar la entrada del usuario en cada turno de conversación. Este proceso puede consistir en identificar la intención del usuario y extraer cualquier información relevante que proporcione.
Para entrenar el modelo NLU, hay que tener en cuenta las distintas formas en que una persona puede expresar la misma petición. Por ejemplo, un usuario podría preguntar por el tiempo de muchas maneras: «¿Cuál es la previsión?», “¿Qué tiempo hace ahora?”, “¿Qué temperatura hará mañana?”, etc. Estas variaciones se representan como Intents. Un «Intento de previsión» agruparía estas expresiones similares.
Al entrenar el modelo para que reconozca las intenciones que hay detrás de cada giro conversacional, su agente virtual puede responder adecuadamente.
Extracción de información pertinente
El modelo debe comprender cómo extraer datos clave del turno de un usuario. Esto va más allá de la intención básica y se centra en los detalles específicos de la solicitud.
Por ejemplo: Si un usuario pregunta: «¿Qué temperatura va a hacer mañana en Seattle?», el agente virtual tiene que
- Reconocer la intención: Obtener la previsión meteorológica
- Extraer datos (entidades):
- «mañana» (hora)
- «Seattle» (ubicación)
Las entidades son las piezas específicas de información para cuyo reconocimiento se entrena el modelo NLU. Representan los objetos o conceptos del mensaje de un usuario.
Cuando un usuario interactúa con el agente virtual, el modelo NLU determina la intención del mensaje y extrae las entidades relevantes, almacenándolas como parámetros. Estos valores de intención y parámetros permiten al agente generar una respuesta adecuada.
Respuesta al usuario
El agente virtual entiende al usuario, pero ¿cómo decide su respuesta?
Un agente virtual emplea un modelo de comprensión del lenguaje natural (NLU) para interpretar lo que dice el usuario. Sin embargo, comprender es sólo la mitad de la batalla: el agente también debe determinar la mejor manera de responder. Esta respuesta puede ser un mensaje al usuario o una acción del agente.
¿Recuerdas esas páginas de estado conversacional?
Las páginas sobre las que hablamos antes, que representan diferentes estados dentro de una conversación, son clave para decidir estas respuestas. Cada página contiene lógica que dicta:
- Acciones: Lo que el agente virtual debe hacer.
- Mensajes: Lo que el agente virtual debe responder al usuario.
- Lógica adicional: Otros factores de decisión.
Antes de sumergirnos en la lógica conversacional, vamos a explorar cómo entrenar tu modelo de lenguaje natural para entender con precisión las intenciones y entidades.
Dejo por aquí una guia oficial de términos en Dialogflow pero los principales conceptos a tener en cuenta son:
- Drivers: Categorías Temáticas
- Intents: grupos de expresiones de usuarios relacionadas que se tratarán de forma similar.
- Entities: Información que queremos extraer de las expresiones de los usuarios
Información más detallada en el curso oficial de Google DialogFlow sobre estos conceptos
Creación de una taxonomía
¿Qué es la taxonomía?
La taxonomía en general es una forma de categorizar «cosas». En el desarrollo de Dialogflow CX, una taxonomía se utiliza para:
- Categorizar los objetivos del usuario en drivers.
- Identificar las principales intenciones y las intenciones contextuales.
- Asociar estas intenciones con los drivers apropiados.
La creación de una taxonomía para Dialogflow CX requiere algunos pasos importantes:
- Dividir el conjunto de objetivos del usuario en drivers. Por ejemplo: en el sector de las telecomunicaciones, podrían ser «estado del pedido», «facturación» y «resolución de problemas».
- Asociar las intenciones principales a cada driver. Por ejemplo: para el driver «facturación», podría tener «pagar la factura» y «cambiar la fecha de vencimiento de la factura».
- Identifique las intenciones contextuales clave que planea utilizar.
¿Qué necesita para empezar a crear una taxonomía?
Hay tres tipos de datos que necesitaremos para crear una taxonomía en Dialogflow CX:
- Transcripciones de conversaciones – Se trata de transcripciones de conversaciones similares a las que está intentando modelar. Pueden ser conversaciones entre humanos o entre humanos y robots.
- Conjuntos de datos de conversaciones: se trata de colecciones más amplias de transcripciones de conversaciones.
- Enlaces externos de clientes – Enlaces a recursos externos, como preguntas frecuentes o artículos de ayuda, que pueden utilizarse para redirigir a los usuarios cuando sea necesario.
Para desarrollar una taxonomía sólida que maximice el potencial del modelo de comprensión del lenguaje natural (NLU) de Dialogflow CX, necesitamos:
- Aprovechar las transcripciones históricas: Lo ideal es analizar las conversaciones existentes entre humanos que sean relevantes para el caso de uso. Dar prioridad a la privacidad redactando cualquier información de identificación personal (PII).
- Adaptarse cuando los datos son limitados: Si estás empezando con un nuevo caso de uso y careces de transcripciones, considera cuidadosamente las formas más probables en que los usuarios se expresarán en cada etapa de la conversación.
- Empezar a construir e iterar: Comienza a construir tu taxonomía basándote en tus mejores ideas y luego refínala a medida que recopiles datos conversacionales del mundo real.
El proceso de crear Taxonomias
Es necesario identificar Drivers como categorias principales para ordenar los diversos campos posibles de acción. Luego identificar headers para las intenciones de usuarios que representen una acción concreta donde agruparemos las intenciones contextuales de estos usuarios.
Para identificar los drivers podemos recurrir a los casos de uso de los usuarios o partes interesadas, a las transcripciones históricas e incluso al uso de machine learning para identificar intenciones.
Un proceso similar puede utilizarse para los headers de intenciones y las intenciones contextuales
El proceso de crear nuestras taxonomías es iterativo, mejorable y debemos dedicarle tiempo y cuidado ya que se trata de un momento clave en la creación de nuestros agentes de conversación. Una mala gestión y creación de taxonomías en DialogflowCX puede tener consecuencias como:
- Detección de intenciones incorrecta
- Reducción del engagement del usuario
- Aumento de costos por intervención humana
Creación de un agente Dialogflow CX
Manos a la obra. Comenzaremos a crear nuestro primer agente. Lo primero es acceder a la consola de DialogflowCX en Google Cloud y seguir los pasos para crear una cuenta, un proyecto y configurar nuestras credenciales de pago(todo este proceso es gratuito y tiene un crédito inicial de Google por un valor de 300USD) para evitar sorpresas puedes configurar un costo mensual fijo en el que se te avisará a traves de tu correo si se ha consumido.
Una vez activa la cuenta y seleccionado el proyecto iremos a la opción «create your agent» y luego a «Build your own»
En la siguiente ventana configuraremos la zona horaria, nombre, locación y lenguaje por defecto:
Ahora ya puedes comenzar a dar forma al flujo conversacional, drivers, entities, en el framework de DialogflowCX. Para información detallada te recomiendo seguir la documentación oficial y el curso de DialogflowCX de Google Cloud.
Creación de Entidades en DialogflowCX
Algunas definiciones clave antes de crear nuestras entidades:
- Tipo de entidad: es el tipo de información que esperamos extraer del imput del usuario.
- Entrada de entidad: es un conjunto de palabras o frases que hacen match con nuestra entidad, se condiseran equivalentes.
- Sinónimos de entidades: múltiples palabras o frases que pueden estar refiriéndose a nuestra entidad.
Con el botón +Create vamos a crear nuestras entidades:
Tenemos entidades predefinidas(con algunas limitaciones de lenguaje y locación) y la posibilidad de crear nuestras propias entidades custom.
Al momento de crear nuestras propias entidades debemos completar los campos según corresponda:
En este paso especificamos el nombre de la entidad, las entradas y los sinónimos.
Tenemos la posibilidad en esta intancia de crear una Composite entity, un tipo de entidad especial que permite contener otras entidades, seleccionando «solo entidades» estaremos creando una entidad de esta clase que nos permite agrupar entidades de la misma «familia» e incluso utilizar expresiones regulares para indicar por ejemplo que dentro de la entidad debe haber un caracter especial, por ejemplo un número.
Recurso adicional: Aquí puedes encontrar un listado completo de entidades posibles del sistema y en este otro link más información sobre composite entity.
Creación de intents en DialogflowCX
Ahora que hemos aprendido a crear entidades, es el momento de crear otro componente clave de nuestra taxonomía: las intenciones. Como recordatorio, las intenciones se utilizan para capturar grupos de expresiones de usuario relacionadas que deben ser tratadas de forma similar por el agente.
Para crear un Intent iremos a Resource/Intents/Manage:
Aquí veremos un listado de los intents actuales. Haremos clic en +Create para agregar uno nuevo:
Lo primero es darle un nombre, por ejemplo una intención header, luego definiremos el tipo de intención, por ejemplo, «contextual», porque el disparador para reconocer a esta intención se presentará en el medio de la conversación. Le daremos una breve descripción para recordar el objetivo de esta intención.
Lo siguiente son las frases de entrenamiento. Aquí podremos agregar frases relacionadas que tengamos previamente definidas para, por ejemplo, identificar el número de productos que el cliente está solicitando. en este ejemplo relacionaremos la intención «números» a la solicitud del usuario.
Como en el caso de las entidades en las intenciones también tendremos algunas definidas por defecto. Estas pueden ser:
- Default Welcome Intent: contienen intenciones relacionadas con el inicio de la conversación, como podría ser un saludo por parte del cliente, ya que así es como se suele iniciar la conversación.
- Default negative intent (CX): Se trata de intenciones que previnenen a nuestro chatbot de hacer un match incorrecto. Por ejemplo, si esperamos que el usuario reserve una habitación en un departamento lo común sería «Quiero reservar en vuestro departamento» y no, «Quiero comprar vuestro departamento». Según el caso de uso puede haber frases que prevengan a vuestro chatbot continuar con un proceso incorrecto.
El proceso de entrenar a nuestro agente se activa una vez definidas todas las intenciones desde la sección «ML»:
Mejores Prácticas creando Entidades e Intenciones en DialogflowCX
1. Intenta utilizar conversaciones reales con usuarios para los entrenamientos y para hacer pruebas con las posibles variantes en tu caso de uso. La idea es ser lo más natural posible.
2. Utiliza frases cortas o una combinación largo/corto que sea acorde a los casos reales de solicitudes, no incluyas variantes innecesarias como la diferencia entre mayúsculas o minúsculas, puntuaciones, etc. e intenta no ser redundante con cada posibilidad ya que podrías estar sobreentrenando a tu agente lo cual puede conducir a errores.
3. El número de frases de entrenamiento para cada intención debe ser equilibrada ya que un número desproporcionado en alguna de ellas puede ocasionar una tendencia de intención por parte del modelo. Esto suele ocurrir cuando hay intencones más solicitadas que otras, debemos equilibrar las frases de entrenamiento en estas intenciones más solicitadas respecto de otras.
4. Las anotaciones sobre las frases de entrenamiento deben ser consistentes:
- Selecciona el texto que debe hacer match de manera precisa
- Asegúrate que las anotaciones apunten a las entidades correctas
- Debes tener una cantidad limitada de parámetros y una relación de 3 veces más frases que parámetros y al menos 5 frases para cada uno.
En este ejemplo las anotaciones de la izquierda son consistentes en cuanto a la definición de las horas y los momentos mientras que el ejemplo de la derecha al mezclaros genera inconsistencias:
5. Utiliza distintos intents según cada recurso que los usuarios solicitan en sus intenciones. En este ejemplo «hotspot» es una intención general, pero cada posible recurso solicitado también tiene su propio intent:
6. Puedes reducir el número de frases de entrenamiento haciendo uso de entity tagging para reutilizar un mismo template de intenciones similares. En el siguiente ejemplo la intención «I want to travel to X» puede ser simplificada para multiples destinos si tenemos una entidad [País]:
Creamos una entidad para cada país:
Reducimos la cantidad de frases de entrenamiento con el tag correspondiente:
7. La regla de oro para entidades e intenciones es: «Las intenciones corresponden a acciones y las entidades a objetos»:
– No debemos crear intenciones que ya estén diferenciadas por valores de las entidades
– No debemos diferenciar acciones a través de una entidad
8. Piensa que los modelos de NLU requieren variedad y consistencia, no son amigos de la ambigüedad, la falta de datos o la redundancia de los mismos. Para las entidades debemos tener en cuenta:
- La existencia de sufcientes sinónimos para cada valor de entidad en cada definición de entidad.
- Cada ocurrencia en el proceso de entrenamiento debe ser «tagueado».
- Gramatica amplia en su variedad(al menos 5 ejemplos) sobre dónde ocurre la entidad
Debes pensar en las frases de entrenamiento como templates, es suficiente con tener un template con una entidad «tagueada».
Por último, no es necesario crear entidades custom para entidades del sistema. Los días de la semana ya pueden ser identificados por parte del agente por defecto. No debemos redundar creando entidades para este tipo de datos si ya hemos definido una entidad por defecto del sistema para ellas.
Parámetros en DialogflowCX
Los parámetros y las entidades son dos caras de la misma moneda.
Las entidades son las piezas específicas de información para cuyo reconocimiento se entrena el modelo NLU. Representan los objetos o conceptos del mensaje de un usuario.
Los parámetros se utilizan para capturar y referenciar valores que han sido suministrados por el usuario final durante una sesión.
Son parte de los datos estructurados que nos permiten utilizar alguna lógica para generar las respuestas.
La forma más usual de los parámetros se conoce en DialogflowCX como parámetros de sesión
Hay dos manera de capturar parámetros en una conversación:
- Cuando automáticamente hacen match con un intent que está «tagueado» en una entidad.
- Cuando hacemos la pregunta directa al usuario para capturarlo. Por ejemplo: ¿En qué fecha quieres pagar tu cuenta»? La respuesta del usuario es la fecha que a su vez es una entidad.
Rutas en DialogflowCX
Anteriormente, aprendimos sobre la arquitectura de estados para gestionar conversaciones en Dialogflow CX. Los manejadores de estado controlan cómo se mueve la conversación entre páginas e incluso las transiciones a nuevos flujos.
Existen cuatro tipos de manejadores de estado:
- Rutas: Las rutas se utilizan para dirigir la conversación en diferentes direcciones mientras se está en una página. A veces puede que las rutas se vuelvan repetitivas, que las mismas rutas puedan aplicarse a varias páginas o incluso flujos.
- Grupos de rutas: Los grupos de rutas permiten crear rutas una sola vez y luego utilizarlas en varias páginas. Por ejemplo, puede tener varias rutas relacionadas con la gestión de perfiles: actualización de datos personales, consulta del historial de pedidos, etc. Puede crear un grupo para todas las rutas de gestión de perfiles y añadir el grupo de rutas a todas las páginas o flujos relevantes.
- Manejadores de eventos
- Almacenes de datos
Intent route y condition route
Las rutas se definen para tomar un curso de acuerdo a la intención o condición del intent. Una ruta de intención hace match con una intención cuando por ejemplo un head intent está definido para pagar una cuenta y una condición determina la ruta condicional si se requiere por ejemplo una sesión iniciada por parte del usuario:
Al definir una ruta se nos pedirá una descripción, un intent con el que la ruta deba matchear y una condición(pueden ser una o ambas opciones) si se requiere para guiar al usuario a la página siguiente.
La transición es hacia donde nos llevará una ruta una vez que una intención y/o condición se cumplan, estas pueden ser Flows o Pages.
Por otra parte podemos crear grupos de rutas que sirvan de template para casos similares. Por ejemplo, si tenemos 3 paginas donde el usuario quiere saber distintas cosas sobre el balance de su cuenta podemos crear un grupo de ruta que nos lleve al estado de balance para evitar crear una para cada página.
Al momento de definir un grupo de rutas podremos seleccionar el Flow particular o todos los flows disponibles sobre, por ejemplo, balance de cuentas.
Buenas prácticas cuando definimos rutas:
- Comprender el objetivo de un grupo de rutas es fundamental
- El orden de las operaciones, una ruta a nivel de página es precedente a una a nivel de Flow
- Crea los fullfillments con sentido para que haga match con tu ruta
- Utiliza parámetros generales y trancisiones que puedan ser utilizados en varias páginas
¿Ruta o Grupo de ruta?
¿Cómo elegir entre rutas y grupos de rutas para las rutas de head intent?
Rutas: Lo mejor para un uso amplio. Si desea que se reconozcan los mismos head intent en varias páginas, las rutas individuales son más eficaces que añadir el mismo grupo de rutas a cada página.
Grupos de rutas: Ideales para la precisión. Si necesita un control específico sobre las direcciones disponibles en determinadas páginas, los grupos de rutas ofrecen una mayor granularidad.
Ejemplo: Escenario de facturación
Imagina que tenemos varias intenciones relacionadas con acciones de facturación. Para que estén disponibles tanto para las solicitudes iniciales como para cuando el usuario necesite aclaraciones sobre la facturación, lo conveniente es crear un único grupo de rutas «Facturación» y añadirlo a las páginas correspondientes.
Eventos en DialogflowCX
Los eventos son desencadenantes que pueden hacer que su agente virtual realice una acción o transición específica dentro de la conversación.
Los controladores de eventos determinan lo que hará el agente virtual cuando se active un evento concreto. Son bloques lógicos adjuntos a páginas, flujos o parámetros.
Pueden ocurrir algunos escenarios en que la conversación no tenga un «disparador» que lleve a cambiar el estado, ya sea por un error o falta de claridad en el imput:
Para estas situaciones es útil crear eventos custom que actuarán en ciertas condiciones. El listado completo de eventos puedes encontrarlo en la documentación oficial sobre eventos de DialogflowCX
Buenas prácticas cuando definimos eventos:
- Los manejadores de eventos no-match y no-input deben estar presentes en cualquier parte que se solicite información al usuario.
- Lo mejor es tener prompts específicos para gestionar la situación
Una recomendación para ambos casos (no-match o no-input) es generar un template de 3 pasos para aclarar a nuestro agente donde el último paso transifere la llamada a un humano.
Fulfillments
Se trata de la respuesta final que entregaremos al usuario, la cual puede estar basada como vimos en el flujo de conversación definido por parámetros, eventos, entrenamiento, etc. Pero adicionalmente podemos cargar información por defecto, videos, recursos externos o incluso RAG sobre alguna documentación haciendo uso de un LLM. Las configuraciones posible abarcan:
Transitions
Las transiciones controlan la forma en que el agente virtual pasa a un nuevo flujo o página.
Con las transiciones definimos las rutas o cambios de rutas para que el agente vuelva a un punto anterior, termine un flow que ha quedado pendiente de terminar, abandone la sesión de chat, etc.
State Handlers in DialogflowCX
Los manejadores de estado controlan la conversación (mediante fullfilments y transiciones). Hay cuatro tipos:
- Rutas
- Grupo de rutas
- Eventos
- Datos almacenados
Hay tres pasos para procesarlos:
- Deben estar definidos para tener efecto
- Deben tener un orden logico
- Deben pasar la evaluación de llamada para dar lugar a los fullfilment y transiciones asociados.
Orden de la evaluación
Hay tres casos posibles que conforman las reglas para un orden apropiado:
- Transición a flow
- Transición a página
- Inicio de turno
Transición a flow
Cuando se presenta te enviará a la página de inicio del flow, a no ser que el flow haya finalizado, en cuyo caso te enviará al estado en el flow previo:
Transición a página
- El primer paso en este caso será ir a una página.
- Luego tomará en cuenta las rutas presentes en la pagina en orden(rutas de intención son ignoradas)
- Grupos de rutas si hubiera
- Parámetros
Comenzando un turno
El comienzo de turno puede ser más complicado ya que envuelve 4 subprocesos:
- Una pagina con un parámetro requerido que no está presente aún:
- Hemos definido no-match o no-input
- No los hemos definido
- Una página sin parámetros requeridos que no están presentes aún:
- Hemos definido no-match o no-input
- No los hemos definido
En cada caso:
- Indefinido el parámetro requerido + no-match/no-input trabajaremos con los event handlers en ese parámetro.
- Indefinido el parámetro requerido – no-match/no-input:
- Si la intención matchea trabajaremos con intenciones de ruta en la página.
- Luego trabajaremos con las condiciones de ruta en la página.
- Luego trabajaremos con grupos de rutas.
- Luego proveeremos prompts para el siguiente parámetro requerido no definido(si lo hubiera).
- Parámetro requerido indefinido + no-match/no-input:
- Suponiendo que hemos hecho no-match/no-input, entonces evaluamos los event handlers en la página.
- Si hemos hecho match con alguno que aplica, haz lo que dice y detente.
- Si no hemos match, evaluamos event handlers en la página de inicio.
- Parámetro requerido indefinido – no-match/no-input:
- Si matchea una intención trabajamos con rutas de intención en la página
- Si damos con uno que tiene condición hacemos lo que dice, pasamos de matchear con rutas de intención y procedemos a rutas de condición.
- Luego trabajamos con grupos de rutas en la página.
- Luego hacemos la trancisión al prompt inicial para el primer parámetro sin valores requerido en la página.
Puedes revisar la documentación sobre orden de evaluación para mayor información.
Construcción de desambiguaciones
¿Qué debe ocurrir cuando el usuario dice algo que es vago o ambiguo? Puede que el objetivo del usuario no esté claro o que el usuario haya omitido información fundamental que el agente necesitaría para entenderle. En este caso, el agente suele tener que aclarar con el usuario lo que quiere decir.
Lo hacemos a través de preguntas, tal y como lo hariamos naturalmente los humanos para aclarar y para definir rutas posibles. Por ejemplo, si un usuario quiere información sobre su cuenta y simplemente nos dice «Quiero información sobre mi cuenta» los escenarios posibles pueden involucrar desde explicar un cargo, pagar una cuenta o proveer un extracto de la cuenta, etc. Cada caso posible debe estar contemplado en nuestras rutas para dirigir al usuario a la ruta adecuada y la respuesta a la solicitud del usuario para este caso seria otra pregunta del tipo «Claro! quieres pagar una cuenta, revisar un cargo u obtener tu extracto?» de este modo ya estamos delimitando una segunda respuesta del usuario a rutas posibles(por lo general las más habituales). Delimitar al usuario a una respuesta final y no a otras preguntas abiertas es el camino ideal.
Tuning de agentes en DialogflowCX
Herramienta de validación
Luego de seguir todas las buenas prácticas y haber definido todas las taxonomias posibles de nuestro agente en una primera versión tenemos la posibilidad de evaluar su performance mediante una herramienta de validación. Podemos encontrarla en el area de «Manage»:
Algunos tipos de validaciones posibles que podremos obtener a través de esta herramienta involucran:
- Frases de entrenamiento similares
- Parámetros no definidos
- Errores en las anotaciones o falta de match entre estas y nuestras entidades
- Sinónimos repetidos
A su vez, el conjunto de problemas identificados por esta herramienta se clasifican segun orden de importancia en:
- Errores: deben ser resueltos para que nuestro agente funcione con normalidad
- Advertencias: no impiden que nuestro agente funcione pero pueden generar malas respuestas
- Información: contienen sobrre todo problemas de coherencia, redundancia, desequilibrios, buenas prácticas, etc. que no impiden el normal funcionamiento. Deben ser revisadas pero son menos importantes que las anteriores.
Scripts
Además de utilizar la herramienta de validación, es posible que desee crear scripts personalizados para la validación. Hay varios objetivos que puede tener para los scripts personalizados. Los scripts de similitud pueden utilizarse para detectar automáticamente frases de entrenamiento similares con diferentes intenciones. La herramienta de validación ya hace parte de esto automáticamente. Sin embargo, es posible que tenga necesidades particulares que requieran este tipo de análisis adicional.
Otro objetivo que puede tener es asegurarse de que el etiquetado de intenciones se ha realizado correctamente. Por ejemplo, a veces se etiqueta una entidad y no aparece en un sinónimo asociado a ese tipo de entidad. Tu script puede identificar casos como este.
Aquí les dejo dos ejemplos de scripts que pueden servirnos de guia:
Test sets
Otra manera de identificar problemas es utilizando Test sets. Estos como todo lo demás contienen un conjunto de buenas prácticas:
- No utilizar frases de entrenamiento en los test
- Cuando sea posible utilizar casos reales de solicitudes
- Aspirar a una cobertura amplia
- Identificar manera de automatizar los test con el framework de DialogflowCX o a través de scripts
gestión de intenciones solapadas
Uno de los problemas comunes es el overlapping de las intenciones. Esto ocurre cuando intenciones en principio distintas pero con frases de entrenamiento similares no prducen match. En estos casos si las intenciones son similares haremos un merge de ambas o dividir las frases para cada intención si son distintas.
Recursos Adicionales
Este contenido proviene del curso oficial de DialogflowCX que puedes tomar tu mismo.
Revisa la documentación oficial de DialogflowCX
Aquí tienes disponible una video playlist entera sobre DialogflowCX
Espero que este artículo introductorio de DialogflowCX te sirva para comenzar tu camino en el desarrollo de agentes chatbots y más. Todo comentario es bienvenido! =) y recuerda que si estás buscando consultoria o desarrollo IA puedes contactarme!
