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.
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.
Selecciona un protocolo y una versión para la referencia de sesión:
| Protocolo | V3 | V3beta1 |
|---|---|---|
| REST | Recurso de sesión | Recurso de sesión |
| RPC | Interfaz de sesión | Interfaz de 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.
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 |
|---|---|
| Acciones de flujo: Controladores de estado | Operación más rápida |
| Flujos: detección de intents (texto) | Operación más rápida |
| Flujos: 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. |
| Almacenes de datos: Se inhabilitó la IA generativa | El tiempo real depende del tamaño del almacén de datos. |
| Almacenes de datos: Se habilitó la IA generativa | El rendimiento depende del tamaño del almacén de datos, del modelo de lenguaje en uso y de la longitud de la entrada y la salida de la instrucción, en ese orden. |
| Generative fallback | El rendimiento depende del lenguaje en uso y de la salida de la instrucción y la longitud de la entrada, en ese orden. |
| Generadores | El rendimiento depende del modelo de lenguaje en uso, la complejidad de la entrada de la instrucción y la longitud de la salida, y la cantidad de generadores en el turno. Varios generadores en un solo turno generan varias llamadas a un modelo de lenguaje. |
| Ejecución de guías | El rendimiento depende de la complejidad de la guía de respuestas, la cantidad de instrucciones y el tiempo de ejecución de las herramientas a las que se llama. La longitud de la entrada y la salida de la instrucción afecta este rendimiento. Es posible que se ejecuten varias instrucciones del modelo de idioma de forma serial, lo que aumenta el tiempo total de la llamada. |
| Guías: herramientas | El rendimiento depende de la ejecución subyacente de la herramienta. |
| 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.