Conceptos básicos de Dialogflow CX

En este documento, se describen los conceptos básicos del uso de Dialogflow CX. Además, se proporciona una descripción general de los conceptos más importantes.

Agents

Un agente de Dialogflow CX es un agente virtual que maneja las conversaciones con tus usuarios finales. Es un módulo de comprensión del lenguaje natural que comprende los matices del lenguaje humano. Dialogflow traduce el texto o el audio del usuario final durante una conversación a datos estructurados que tus apps y servicios pueden comprender. Un agente de Dialogflow se crea y diseña a fin de manejar los tipos de conversaciones requeridas para tu sistema.

Un agente de Dialogflow es similar a un agente de un centro de llamadas humano. Lo entrenas para que se encargue de las situaciones de conversación esperadas; el entrenamiento no tiene que ser demasiado explícito.

Flows

Los diálogos complejos suelen incluir varios temas de conversación. Por ejemplo, un agente de entrega de pizzas puede tener el pedido de comida, la información del cliente y la confirmación como temas diferentes. Cada tema necesita varios turnos de conversación para que un agente obtenga la información relevante del usuario final.

Los flujos se usan para definir estos temas y las rutas de conversación asociadas. Cada agente tiene un flujo llamado Flujo de inicio predeterminado. Este flujo único puede ser todo lo que necesitas para un agente simple. Los agentes más complicados pueden requerir flujos adicionales, y los diferentes miembros del equipo de desarrollo pueden ser responsables de compilar y mantener estos flujos. Por ejemplo, los flujos de un agente de entrega de pizzas podrían ser algo parecido a lo siguiente:

Diagrama de varios flujos de ejemplo.

Los flujos de Dialogflow CX tienen un propósito similar al de los agentes secundarios para los agentes combinados de Dialogflow ES. Los flujos proporcionan un mejor control de la conversación y no generan costos adicionales.

Pages

Una conversación de Dialogflow CX (sesión) se puede describir y visualizar como una máquina de estado. Los estados de una sesión de CX se representan por páginas.

Para cada flujo, debes definir muchas páginas, en las que tus páginas combinadas pueden controlar una conversación completa sobre los temas para los que se diseñó el flujo. En un momento determinado, exactamente una página es la página actual, esta se considera activa y el flujo asociado a esa página se considera activa. Cada flujo tiene una página de inicio especial. Al principio, cuando un flujo se activa, la página de inicio se convierte en la página actual. En cada turno de la conversación, la página actual se mantendrá igual o pasará a otra página.

Configura cada página a fin de recopilar información del usuario final que sea relevante para el estado de conversación que representa la página. Por ejemplo, puedes crear las páginas (en azul) en el siguiente diagrama para un flujo de pedido de comida de un agente de entrega de pizzas. El nodo Start del diagrama representa la página de inicio del flujo Orden de comida. Cuando se completa el flujo, se transfiere al flujo de Confirmación.

Diagrama de varios flujos de ejemplo.

Tipos de entidad

Los tipos de entidades se usan para controlar cómo se extraen los datos de la entrada del usuario final. Los tipos de entidades CX son muy similares a los tipos de entidades de ES.

Dialogflow proporciona entidades del sistema predefinidas que pueden coincidir con muchos tipos comunes de datos. Por ejemplo, hay entidades del sistema que coinciden con fechas, horas, colores, direcciones de correo electrónico, etcétera. También puedes crear tus propias entidades personalizadas para detectar coincidencias en datos personalizados. Por ejemplo, podrías definir una entidad vegetal que coincida con los tipos de vegetales disponibles para la compra con un agente de supermercado.

Parámetros

Los parámetros se usan a fin de capturar y hacer referencia a los valores que proporcionó el usuario final durante una sesión. Cada parámetro tiene un nombre y un tipo de entidad. A diferencia de la entrada sin procesar del usuario final, los parámetros son datos estructurados que se pueden usar con facilidad para realizar alguna lógica o generar respuestas.

Los parámetros de CX son similares a los parámetros de ES, pero la utilidad y el permiso se han expandido y la sintaxis para hacer referencia a los parámetros cambió.

Formularios

Para cada página puedes definir un formulario, que es una lista de parámetros que se deben recopilar desde el usuario final de la página. El agente interactúa con el usuario final durante varios turnos de conversación hasta que haya recopilado todos los parámetros del formulario necesarios, que también se conocen como parámetros de página. Para cada parámetro del formulario, también proporcionas mensajes que el agente usa a fin de solicitar esa información del usuario final. Esto se denomina proceso para completar formularios.

Por ejemplo, puedes crear un formulario que recopile el nombre y el número de teléfono del usuario final para una página de Collect Customer Info.

El proceso para completar formularios de CX es similar al llenado de ranuras de ES.

Intents

Un intent clasifica la intención de un usuario final para un turno de conversación. En comparación con los intents de ES, los intents de CX se simplificaron para que sean un recurso más reutilizable.

Un intent contiene los siguientes datos:

Término Definición
Frases de entrenamiento Las frases de entrenamiento son frases de ejemplo de algo que podrían decir o escribir los usuarios finales, conocidas como entradas del usuario final. Cuando la entrada del usuario final se parece a una de estas frases, Dialogflow hace una coincidencia con el intent. No es necesario que definas todos los ejemplos posibles, ya que el aprendizaje automático integrado de Dialogflow expande la lista con otras frases similares.
Parámetros Define las frases de entrenamiento a fin de usar parámetros para extraer valores de partes específicas de la entrada del usuario final.

Webhook

Los webhooks son servicios que alojan la lógica empresarial. Durante una sesión, los webhooks te permiten usar los datos extraídos por el procesamiento de lenguaje natural de Dialogflow a fin de generar respuestas dinámicas, validar datos recopilados o activar acciones en el backend.

Los webhooks de CX son similares a los webhooks de ES, excepto que los campos de solicitud y respuesta se cambiaron para admitir características de CX.

Entrega

Para el turno de conversación de un agente, este debe responder al usuario final con una respuesta a una pregunta, una consulta de información o una finalización de la sesión. Es posible que el agente también deba comunicarse con el servicio para generar respuestas dinámicas o tomar medidas durante un turno. La entrega se usa para lograr todo esto.

Una entrega puede contener cualquiera de los siguientes elementos:

  • Mensajes de respuesta estática.
  • Webhook llama para obtener respuestas dinámicas o para realizar acciones.
  • Ajustes predeterminados de parámetros para establecer o anular los valores del parámetro

Durante el turno de un agente, es posible (y, a veces, conveniente) llamar a varias entregas, cada una de las cuales puede generar un mensaje de respuesta. Dialogflow mantiene estas respuestas en una cola de respuestas. Una vez que el turno del agente termina, Dialogflow envía las respuestas ordenadas al usuario final.

La entrega de ES se limita a conectar un servicio de webhook. Se aumentó el alcance de la entrega para CX, por lo que ahora abarca todos los tipos de mensajes y respuestas.

Controladores de estado

Los controladores de estado también llamados simplemente controladores, se usan para controlar la conversación mediante la creación de respuestas a usuarios finales o la transición de la página actual. Para cada turno de conversación, los controladores se evalúan y pueden afectar la sesión. Los controladores tienen tres tipos generales de datos:

Término Definición
Requisitos del controlador Estos son los requisitos que se deben cumplir para que el controlador tenga efecto en la sesión. Se dice que un controlador se llama cuando se cumplen sus requisitos y afecta la sesión de alguna manera.
Entrega del controlador Si se llama a un controlador, se usa una entrega opcional a fin de crear respuestas para los usuarios finales. Estas respuestas se definen en datos del agente estático o se recuperan de forma dinámica desde tu servicio de webhook.
Objetivo de transición del controlador Si se llama a un controlador, se usa un objetivo de transición opcional para cambiar la página actual. La página siguiente solo puede ser una página de inicio de flujo o una página dentro del flujo activo actual.

Existen dos tipos de controladores de estado con requisitos de controlador diferentes:

Término Definición
Rutas Se llama a las rutas cuando una entrada de usuario final coincide con un intent o se cumple alguna condición en el estado de la sesión. Una ruta con un requisito de intent también se denomina una ruta de intents. Una ruta con solo un requisito de condición también se denomina una ruta de condición.
Controladores de eventos Los controladores de eventos se llaman cuando se invoca un evento. Algunos eventos integrados se activan cuando se recibe una entrada del usuario final inesperada o cuando se produce un error de webhook. También puedes definir eventos personalizados que invocas cuando algo sucede fuera de la conversación.

El procesamiento de un controlador de estado consta de tres pasos:

Término Definición
1. Alcance Un controlador debe estar dentro del alcance para tener algún efecto en la sesión. El alcance se determina en función de si un controlador se aplica a un flujo, a una página o a un parámetro de formulario, y de si el flujo asociado está activo, la página asociada está activa o el agente intenta completar el parámetro del formulario asociado.
2. Evaluation Cada controlador dentro del alcance se evalúa en orden. Si se cumplen los requisitos de un controlador, se aprueba la evaluación.
3. Llamar Si un controlador está dentro del alcance y pasa la evaluación, se llama. Se llama a cualquier entrega asociada y se aplica cualquier objetivo de transición asociado a la sesión.

Console

Dialogflow proporciona una interfaz de usuario web llamada consola de Dialogflow CX (visita la documentación, abre la consola). Puedes usar esta consola para crear, compilar y probar agentes CX. La consola CX tiene un propósito similar al de la Consola ES, pero la interfaz de usuario de la consola CX es mucho más visual. Asigna cada grafo como un diagrama de máquina de estado de conversación, lo que facilita el diseño y la comprensión de los agentes complejos.

La consola Dialogflow CX es diferente a Google Cloud Platform (GCP) Console (consulta la documentación, abre la consola). La consola Dialogflow CX se usa para administrar los agentes de Dialogflow CX, mientras que GCP Console se usa en la configuración de Dialogflow CX específica de GCP (por ejemplo, facturación) y otros recursos de GCP.

En la mayoría de los casos, debes usar la consola de Dialogflow CX a fin de compilar agentes, pero también puedes usar la API de Dialogflow CX a fin de compilar agentes para situaciones avanzadas.

Interacciones del usuario con la API

Usar la API para CX es similar a usar la API para ES, excepto que se modificaron algunas rutas y métodos de recursos para admitir nuevos tipos, métodos y campos.

Tu sistema debe controlar lo siguiente:

  • Dialogflow CX aún no admite ninguna integración, por lo que tu sistema debe proporcionar una interfaz de usuario para interactuar directamente con los usuarios finales.
  • Debes llamar a la API de Dialogflow para cada turno de conversación a fin de enviar la entrada del usuario final a la API.
  • A menos que tus respuestas de agente sean estáticas (poco comunes), debes alojar un servicio de webhook para manejar la entrega habilitada para webhook.

En el siguiente diagrama, se muestran los pasos que se deben seguir para un turno de conversación de una sesión.

Diagrama de flujo de la API.

  1. El usuario final escribe o dice algo, conocido como entrada de usuario final.
  2. Tu sistema de interfaz de usuario recibe la entrada y la reenvía a la API de Dialogflow en una solicitud de intent de detección.
  3. La API de Dialogflow recibe la solicitud de intent de detección. Coincide con la entrada a un intent o parámetro de formulario, establece los parámetros según sea necesario y actualiza el estado de la sesión. Si necesita llamar a una entrega habilitada para webhook, envía una solicitud de webhook a tu servicio de webhook, de lo contrario, va al paso 6.
  4. Tu servicio de webhook recibe la solicitud de webhook. Tu servicio realiza las acciones necesarias, como llamar a API externas, consultar o actualizar una base de datos, etcétera.
  5. Tu servicio de webhook compila una respuesta y envía una respuesta de webhook a Dialogflow.
  6. Dialogflow crea una respuesta de intent de detección. Si se llamó a un webhook, usa la respuesta proporcionada en la respuesta de webhook. Si no se llamó a ningún webhook, usa la respuesta estática que se define en el agente. Dialogflow envía una respuesta de intent de detección a tu sistema de interfaz de usuario.
  7. Tu sistema de interfaz de usuario recibe la respuesta de intent de detección y reenvía la respuesta de texto o audio al usuario final.
  8. El usuario final ve o escucha la respuesta.