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