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.

Agentes

Un agente de Dialogflow CX es un agente virtual que controla las conversaciones simultáneas 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. Cuando un flujo se activa al principio, la página actual se convierte en la página de inicio. 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 de Inicio del diagrama representa la página de inicio del flujo del Pedido 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. El agente recopila estos parámetros en el orden definido en la página. Para cada parámetro de formulario obligatorio, 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
Nombre visible Es el nombre que se muestra en la consola para el intent.
Etiquetas Etiquetas que ayudan a categorizar intents. Por ejemplo: head intent.
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.
Patrones de DTMF Consulta DTMF para integraciones de telefonía.

Webhook

Los webhooks son servicios que alojan la lógica empresarial o llaman a otros servicios. 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.

Un webhook puede ser un webhook estándar o uno flexible. Con un webhook estándar, Dialogflow define los campos de solicitud y respuesta. Con un webhook flexible, tú defines los campos de solicitud y respuesta.

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.
Destino 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.

Regionalización y configuración de la ubicación

Cuando creas un agente, debes especificar una región como la ubicación del agente. Los servicios de Google en esta región controlan las solicitudes que se envían a tu agente, y Dialogflow mantiene los datos en reposo de forma física dentro de la región o ubicación geográfica. Para obtener el mejor rendimiento, debes elegir una región que esté cerca de tus servicios y usuarios finales.

Una vez que se crea un agente, su ubicación no puede cambiar. Para cambiar la ubicación del agente, debes exportar y restablecer a un agente nuevo con una ubicación diferente.

Cada ubicación tiene una configuración asociada que se aplica a todo tu proyecto. En la mayoría de los casos, no es necesario editar esta configuración, y la configuración predeterminada funcionará bien. Si tu sistema requiere claves de encriptación administradas por el cliente (que suelen requerir las entidades gubernamentales o las industrias reguladas), lee más sobre la configuración de la ubicació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.

Integraciones

Por el momento, Dialogflow CX proporciona varias integraciones integradas en otras plataformas de conversación. Estas integraciones proporcionan una interfaz de usuario al usuario final y llaman a la API de Dialogflow. Todo lo que necesitas hacer es compilar tu agente e implementar un servicio de webhook. El manejo de las interacciones varía según la plataforma de la integración, así que debes consultar la documentación correspondiente para obtener más detalles.

Interactions

Para cada turno de la conversación, se produce una interacción. Durante una interacción, un usuario final envía una entrada a Dialogflow y este envía una respuesta. Tienes dos opciones a la hora de implementar tu sistema para controlar las interacciones: usar la API o una integración.

Cuando usas la API, tu sistema debe controlar lo siguiente:

  • Compila un agente.
  • Proporciona una interfaz de usuario para los usuarios finales.
  • Llama 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.

Cuando usas una integración, tu sistema solo necesita controlar lo siguiente:

  • Compila un agente.
  • De manera opcional, implementa un servicio de 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 interfaz de usuario o sistema de integración 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 interfaz de usuario o sistema de integración.
  7. Tu interfaz de usuario o sistema de integración 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.