Prácticas recomendadas para el uso del servicio

En esta guía, se proporcionan prácticas recomendadas para usar el servicio de Dialogflow. Estos lineamientos están diseñados a fin de lograr una mayor eficiencia y precisión, así como para obtener tiempos de respuesta óptimos del servicio.

También debes consultar la guía de diseño general de agentes para todos los tipos de agentes y la guía de diseño de agentes de voz específicamente para diseñar agentes de voz.

Producción

Antes de ejecutar el agente en producción, asegúrate de implementar las prácticas recomendadas de producción.

Habilita registros de auditoría

Habilita los registros de auditoría de acceso a los datos para la API de Dialogflow en tu proyecto. Esto puede ayudarte a hacer un seguimiento de los cambios durante el diseño en los agentes de Dialogflow vinculados a este proyecto.

Versiones de agentes

Siempre debes usar las versiones de agente para tu tráfico de producción. Consulta Versiones y entornos para obtener más detalles.

Crea una copia de seguridad del agente

Mantén una copia de seguridad del agente exportada y actualizada. Esto te permitirá recuperar rápidamente el agente o el proyecto si tú o los miembros de tu equipo los borran por accidente.

Reutilización del cliente

Para mejorar el rendimiento de tu aplicación, puedes volver a usar instancias de bibliotecas cliente *Client durante el ciclo de vida de ejecución de tu aplicación.

Lo más importante es que puedes mejorar el rendimiento de las llamadas a la API de detección de intents reutilizando una instancia de biblioteca cliente SessionsClient.

Consulta la referencia Sesiones.

Para obtener más información, consulta la guía de prácticas recomendadas con bibliotecas cliente.

Actualizaciones por lotes al agente

Si envías muchas solicitudes a la API individuales de actualización de agente en un período breve, es posible que se limite la cantidad de solicitudes. Estos métodos de API durante la fase de diseño no están implementados con el fin de manejar altas tasas de actualización para un único agente.

Algunos tipos de datos tienen métodos de procesamiento por lotes para ese fin:

  • En lugar de enviar solicitudes create, patch o delete a muchas EntityTypes, usa los métodos batchUpdate o batchDelete.
  • En lugar de enviar solicitudes create, patch o delete a muchos intents, usa los métodos batchUpdate o batchDelete.

Reintentos de errores de la API

Cuando llamas a métodos de la API, es posible que recibas respuestas de error. Hay algunos errores que se deben reintentar, ya que a menudo se generan debido a problemas transitorios. Existen dos tipos de errores:

Además, debes implementar una retirada exponencial para los reintentos. Esto permite que tu sistema encuentre una tasa aceptable mientras el servicio de la API administra una carga grande.

Errores de la API de Cloud

Si usas una biblioteca cliente proporcionada por Google, los reintentos de error de la API de Cloud con retirada exponencial se implementan por ti.

Si implementaste tu propia biblioteca cliente con REST o gRPC, debes implementar los reintentos para tu cliente. Para obtener información sobre los errores que debes o no debes reintentar, consulta Proposiciones de mejora de la API: Configuración de reintento automática.

Errores de webhook

Si tu llamada a la API activa una llamada de webhook, tu webhook puede mostrar un error. Incluso si usas una biblioteca cliente proporcionada por Google, los errores de webhook no se volverán a intentar de forma automática. Tu código debería reintentar los errores 503 Service Unavailable recibidos de tu webhook. Consulta la documentación del servicio de webhook para obtener información sobre los tipos de errores de webhook y cómo verificarlos.

Pruebas de carga

Una de las prácticas recomendadas es ejecutar pruebas de carga para tu sistema antes de lanzar el código a la producción. Considera estos puntos antes de implementar tus pruebas de carga:

Resumen Detalles
Acelera la carga. La prueba de carga debe acelerar la carga aplicada al servicio de Dialogflow. El servicio no está diseñado para manejar aumentos abruptos de actividad de carga, que rara vez ocurren con tráfico real. Al servicio le toma un tiempo ajustarse a las demandas de carga. Por ello, debes aumentar la tasa de solicitudes hasta que la prueba alcance la carga deseada.
Las llamadas a la API se cobran. Se te cobrará por las llamadas a la API durante una prueba. La cuota del proyecto limitará las llamadas.
Usa dobles de prueba. Es posible que no necesites llamar a la API durante la prueba de carga. Si el propósito de tu prueba de carga es determinar cómo tu sistema maneja la carga, a menudo es mejor usar un doble de prueba en lugar de llamadas reales a la API. Tu doble de prueba puede simular el comportamiento de la API bajo carga.
Usa los reintentos. Tu prueba de carga debe realizar reintentos con una retirada.

Llama a Dialogflow de forma segura desde un dispositivo de usuario final

Nunca debes almacenar tus claves privadas usadas para acceder a la API de Dialogflow en un dispositivo de usuario final. Esto se aplica al almacenamiento de claves en el dispositivo directamente y a las claves de codificación hard-coded en aplicaciones. Cuando la aplicación cliente necesita llamar a la API de Dialogflow, debe enviar solicitudes a un servicio de proxy de propiedad del desarrollador en una plataforma segura. El servicio de proxy puede realizar las llamadas reales y autenticadas de Dialogflow.

Por ejemplo, no debes crear una aplicación para dispositivos móviles que llame a Dialogflow de forma directa. Si lo haces, es necesario que almacenes claves privadas en un dispositivo de usuario final. La aplicación para dispositivos móviles debería pasar las solicitudes a través de un servicio de proxy seguro.

Rendimiento

En esta sección, se describe la información de rendimiento de varias operaciones dentro de Dialogflow. Comprender la latencia es importante para diseñar agentes responsivos y establecer expectativas de rendimiento realistas, aunque estos valores no forman parte del ANS de Dialogflow.

Cuando crees herramientas de supervisión y alertas, ten en cuenta que los modelos de lenguaje grandes (LLM) y el procesamiento de voz suelen controlarse con métodos de transmisión. Las respuestas se envían al cliente lo antes posible, a menudo mucho antes que la duración total de la llamada al método. Para obtener más información, consulta las prácticas recomendadas con modelos de lenguaje grandes (LLM).

Rendimiento por operación

En la siguiente tabla, se proporciona información sobre el rendimiento típico de las operaciones de Dialogflow:

Acción Notas
Detección de intents (texto) Operación rápida
Detección de parámetros (texto) Operación rápida
Reconocimiento de voz (transmisión) Los datos se procesan y las respuestas se muestran lo antes posible. El tiempo de ejecución total se determina principalmente por la duración del audio de entrada. No se recomienda medir la latencia con el tiempo de ejecución total.
Síntesis de voz (transmisión) El tiempo de ejecución total se determina principalmente por la duración del audio de salida. Los datos se procesan y las respuestas se muestran lo más rápido posible.
Llamadas de webhook El rendimiento se determina directamente por el tiempo de ejecución de tu código en el webhook.
Agente de importación / exportación El rendimiento depende del tamaño del agente.
Capacitación para agentes El rendimiento depende de la cantidad de flujos, intents y frases de entrenamiento. El entrenamiento de agentes grandes puede tardar decenas de minutos.
Creación del entorno Crear un entorno implica entrenar al agente, por lo que el tiempo total dependerá del tamaño y la complejidad del agente.

Notas clave:

  • Transmisión: En el caso de las llamadas de transmisión (reconocimiento y síntesis de voz), los datos se procesan a medida que llegan y las respuestas se muestran lo antes posible. Esto significa que la respuesta inicial suele ser mucho más rápida que el tiempo total de la llamada.
  • Guiones de instrucciones: Se crea una instrucción de LLM en función de las instrucciones del guion, el contexto de la conversación y la entrada de la herramienta. Se pueden ejecutar varias instrucciones de LLM en una sola llamada a la guía de instrucciones. Por este motivo, la ejecución del libro de jugadas es variable, según la cantidad de instrucciones emitidas y la complejidad de las llamadas.

Consideraciones importantes sobre la latencia

  • Sin garantías de latencia: Los ANS de Dialogflow no consideran la latencia, incluso con la capacidad de procesamiento aprovisionada.
  • Latencia del LLM: Ten en cuenta que el procesamiento del LLM puede generar una latencia significativa. Ten en cuenta esto en el diseño de tu agente y en las expectativas de los usuarios.
  • Supervisión y alertas: Cuando configures la supervisión y las alertas, ten en cuenta la naturaleza transmitida de las respuestas de los LLM y los servicios de voz. No supongas que el tiempo de respuesta completo es igual al tiempo para dar la primera respuesta.