En esta guía se proporcionan prácticas recomendadas para usar el servicio Dialogflow. Estas directrices se han diseñado para aumentar la eficiencia y la precisión, así como para optimizar los tiempos de respuesta 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, que está dirigida específicamente a diseñar agentes de voz.
Puesta en producción
Antes de ejecutar tu agente en producción, asegúrate de implementar las siguientes prácticas recomendadas:
- Usar versiones de agentes
- Reutilizar clientes de sesión
- Implementar la gestión de errores con reintentos
Versiones del agente
Debes usar siempre versiones del agente para tu tráfico de producción. Consulta la sección Versiones y entornos para obtener más información.
Crear copia de seguridad del agente
Mantén una copia de seguridad exportada del agente actualizada. De esta forma, podrás recuperarlo rápidamente si tú o los miembros de tu equipo elimináis el agente o el proyecto por error.
Reutilización de clientes
Puedes mejorar el rendimiento de tu aplicación
reutilizando *Client instancias de la biblioteca cliente
durante el tiempo de ejecución de tu aplicación.
Lo más importante es que puedes mejorar el rendimiento de las llamadas a la API Detect Intent reutilizando una instancia de biblioteca de cliente SessionsClient.
Seleccione un protocolo y una versión para la referencia de la 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 para bibliotecas de cliente.
Reintentos de errores de la API
Al llamar a métodos de la API, puede que recibas respuestas de error. Hay algunos errores que se deben volver a intentar, ya que suelen deberse a problemas transitorios. Se pueden producir dos tipos de errores:
- Errores de la API Cloud.
- Errores enviados desde tu servicio de webhook.
Además, debes implementar un tiempo de espera exponencial para los reintentos. Esto permite que tu sistema encuentre una tarifa aceptable mientras el servicio de la API está sometido a una carga pesada.
Errores de la API de Cloud
Si usas una biblioteca de cliente proporcionada por Google, los reintentos de errores de la API de Cloud con retroceso exponencial se implementan automáticamente.
Si has implementado tu propia biblioteca de cliente mediante REST o gRPC, debes implementar reintentos para tu cliente. Para obtener información sobre los errores que debes o no debes volver a intentar, consulta Propuestas de mejora de la API: configuración de reintentos automáticos.
Errores de webhook
Si tu llamada a la API activa una llamada a un webhook, es posible que tu webhook devuelva un error.
Aunque uses una biblioteca de cliente proporcionada por Google, los errores de webhook no se volverán a intentar automáticamente.
Tu código debe volver a intentar 503 Service Unavailable
errores 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 comprobarlos.
Pruebas de carga
Te recomendamos que realices pruebas de carga en tu sistema antes de lanzar el código a producción. Ten en cuenta estos puntos antes de implementar tus pruebas de carga:
| Resumen | Detalles |
|---|---|
| Aumenta la carga. | La prueba de carga debe aumentar la carga aplicada al servicio Dialogflow. El servicio no está diseñado para gestionar picos de carga repentinos, que rara vez se producen con el tráfico real. El servicio tarda en adaptarse a las demandas de carga, por lo que debes aumentar la tasa de solicitudes lentamente hasta que la prueba alcance la carga deseada. |
| Las llamadas a la API se cobran. | Se te cobrarán las llamadas a la API durante una prueba y las llamadas estarán limitadas por la cuota del proyecto. |
| Usa dobles de prueba. | Puede que no necesites llamar a la API durante la prueba de carga. Si el objetivo de la prueba de carga es determinar cómo gestiona la carga tu sistema, suele ser 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 reintentos. | La prueba de carga debe realizar reintentos con un tiempo de espera. |
Llamar a Dialogflow de forma segura desde un dispositivo de usuario final
Nunca debes almacenar las claves privadas que se usan para acceder a la API Dialogflow en un dispositivo de usuario final. Esto se aplica al almacenamiento de claves directamente en el dispositivo y a la codificación de claves en las aplicaciones. Cuando tu aplicación cliente necesite llamar a la API Dialogflow, debe enviar solicitudes a un servicio proxy propiedad del desarrollador en una plataforma segura. El servicio proxy puede hacer las llamadas autenticadas reales a Dialogflow.
Por ejemplo, no debes crear una aplicación móvil que llame a Dialogflow directamente. Para ello, tendrías que almacenar claves privadas en un dispositivo de usuario final. En su lugar, tu aplicación móvil debería enviar las solicitudes a través de un servicio proxy seguro.
Rendimiento
En esta sección se describe el rendimiento de varias operaciones de Dialogflow. Es importante conocer la latencia para diseñar agentes con capacidad de respuesta y establecer expectativas de rendimiento realistas, aunque estos valores no forman parte del SLA de Dialogflow.
Cuando crees herramientas de monitorización y alertas, ten en cuenta que los modelos de lenguaje extenso (LLMs) y el procesamiento del habla suelen gestionarse mediante métodos de streaming. Las respuestas se envían al cliente lo antes posible, a menudo mucho antes de que finalice la llamada al método. Para obtener más información, consulta las prácticas recomendadas para usar modelos de lenguaje extenso (LLMs).
Rendimiento por operación
En la siguiente tabla se proporciona información sobre el rendimiento habitual de las operaciones de Dialogflow:
| Acción | Notas |
|---|---|
| Acciones del 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) | Funcionamiento rápido |
| Reconocimiento de voz (streaming) | Los datos se procesan y las respuestas se devuelven lo antes posible. El tiempo total de ejecución se determina principalmente por la duración del audio de entrada. No se recomienda medir la latencia con el tiempo total de ejecución. |
| Síntesis de voz (streaming) | El tiempo total de ejecución se determina principalmente en función de la duración del audio de salida. Los datos se procesan y las respuestas se devuelven lo más rápido posible. |
| Almacenes de datos: IA generativa inhabilitada | El tiempo real depende del tamaño del almacén de datos. |
| Almacenes de datos: IA generativa habilitada | El rendimiento depende del tamaño del almacén de datos, del modelo de lenguaje que se esté usando y de la longitud de la entrada y la salida de la petición, por ese orden. |
| Generative Fallback | El rendimiento depende del idioma que se esté usando y de la longitud de la entrada y la salida de la petición, por ese orden. |
| Generadores | El rendimiento depende del modelo de lenguaje que se esté usando, de la complejidad de la entrada de la petición y de la longitud de la salida, así como del número de generadores de la conversación. Si se usan varios generadores en un mismo turno, se harán varias llamadas a un modelo de lenguaje. |
| Ejecución de guías | El rendimiento depende de la complejidad del cuaderno de estrategias, el número de peticiones y el tiempo de ejecución de las herramientas que se llamen. La longitud de la entrada y la salida de la petición influye en este rendimiento. Las peticiones de modelos en varios idiomas se pueden ejecutar de forma secuencial, lo que se suma al 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 en función del tiempo de ejecución del código en el webhook. |
| Importar o exportar agente | El rendimiento depende del tamaño del agente. |
| Formación de agentes | El rendimiento depende del número de flujos, intents y frases de entrenamiento. Entrenar agentes grandes puede llevar decenas de minutos. |
| Creación de entornos | Crear un entorno implica entrenar al agente, por lo que el tiempo total dependerá del tamaño y la complejidad del agente. |
Notas importantes:
- Streaming: en las llamadas de streaming (reconocimiento y síntesis de voz), los datos se procesan a medida que llegan y las respuestas se devuelven lo antes posible. Esto significa que la respuesta inicial suele ser mucho más rápida que la duración total de la llamada.
- Guías: se crea una petición de LLM basada en las instrucciones de la guía, el contexto de la conversación y la entrada de la herramienta. Se pueden ejecutar varias peticiones de LLM en una sola llamada de libro de jugadas. Por eso, la ejecución de la guía es variable, ya que depende de la cantidad de peticiones que se hagan y de la complejidad de las llamadas.
Consideraciones importantes sobre la latencia
- Sin garantías de latencia: los SLAs de Dialogflow no tienen en cuenta la latencia, ni siquiera con el rendimiento aprovisionado.
- Latencia de LLM: ten en cuenta que el procesamiento de LLM puede introducir una latencia significativa. Tenlo en cuenta a la hora de diseñar tu agente y de gestionar las expectativas de los usuarios.
- Monitorización y alertas: al configurar la monitorización y las alertas, ten en cuenta que las respuestas de los LLMs y los servicios de voz se transmiten. No supongas que el tiempo de respuesta completo es igual al tiempo hasta la primera respuesta.