En esta guía, se proporcionan las 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 deberías 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ífica para el diseño de agentes de voz.
Producción
Antes de ejecutar el agente en producción, asegúrate de implementar las prácticas recomendadas de producción.
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.
Crear copia de seguridad del agente
Mantén una copia de seguridad actualizada del agente exportada. Esto te permitirá recuperarte con rapidez si tú o los miembros de tu equipo borran el agente o el proyecto por accidente.
Reutilización de clientes
Puedes mejorar el rendimiento de tu aplicación si reutilizas las instancias de la biblioteca cliente de *Client durante todo el ciclo de vida de la ejecución de la aplicación.
Lo más importante es que puedes mejorar el rendimiento de las llamadas a la API de detección de intent si reutilizas una instancia de biblioteca cliente de SessionsClient.
Selecciona un protocolo y una versión para la referencia de sesión:
| Protocolo | V3 | V3beta1 |
|---|---|---|
| REST | Recurso de la sesión | Recurso de la sesión |
| RPC | Interfaz de la sesión | Interfaz de la sesión |
| C++ | SessionsClient | No disponible |
| C# | SessionsClient | No disponible |
| Go | SessionsClient | No disponible |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | No disponible | No disponible |
| Python | SessionsClient | SessionsClient |
| Ruby | No disponible | No disponible |
Para obtener más información, consulta la guía de prácticas recomendadas con bibliotecas cliente.
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:
- Errores de la API de Cloud.
- Errores enviados desde tu servicio de webhook.
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.