Ce guide présente les bonnes pratiques à suivre pour utiliser le service Dialogflow. Ces consignes visent à améliorer l'efficacité et la précision du service, ainsi qu'à obtenir des temps de réponse optimaux.
Consultez également le guide de conception générale de l'agent pour tous les types d'agents, ainsi que le guide de conception d'un agent vocal spécifiquement destiné à la conception d'agents vocaux.
Passage en production
Avant d'exécuter votre agent en production, veillez à mettre en œuvre les bonnes pratiques suivantes :
- Utiliser les versions d'agent
- Réutiliser les clients de session
- Mettre en œuvre le traitement des erreurs avec des nouvelles tentatives
Versions d'agent
Vous devez toujours utiliser des versions d'agent pour votre trafic de production. Pour plus de détails, consultez la page Versions et environnements.
Créer une sauvegarde de l'agent
Conservez une sauvegarde à jour de l'agent exporté. Cela vous permettra de récupérer rapidement si vous ou les membres de votre équipe supprimez accidentellement l'agent ou le projet.
Réutilisation du client
Pour améliorer les performances de votre application, vous pouvez réutiliser des instances de bibliothèque cliente *Client pendant toute la durée d'exécution de votre application.
Plus important encore, vous pouvez améliorer les performances des appels d'API de détection d'intent en réutilisant une instance de bibliothèque cliente SessionsClient.
Sélectionnez un protocole et une version pour la référence de session :
| Protocole | V3 | V3beta1 |
|---|---|---|
| REST | Ressource de session | Ressource de session |
| RPC | Interface de session | Interface de session |
| C++ | SessionsClient | Non disponible |
| C# | SessionsClient | Non disponible |
| Go | SessionsClient | Non disponible |
| Java | SessionsClient | SessionsClient |
| Node.js | SessionsClient | SessionsClient |
| PHP | Non disponible | Non disponible |
| Python | SessionsClient | SessionsClient |
| Ruby | Non disponible | Non disponible |
Pour en savoir plus, consultez le guide des bonnes pratiques concernant les bibliothèques clientes.
Nouvelles tentatives en cas d'erreur de l'API
Lorsque vous appelez des méthodes d'API, vous pouvez recevoir des réponses d'erreur. Certaines erreurs doivent faire l'objet d'une nouvelle tentative, car elles sont souvent dues à des problèmes temporaires. Il existe deux types d'erreurs :
- Erreurs Cloud API
- Erreurs envoyées par votre service de webhook
En outre, vous devez mettre en œuvre un intervalle exponentiel entre les tentatives. Cela permet à votre système de trouver un taux acceptable lorsque le service d'API est soumis à une charge importante.
Erreurs liées à l'API Cloud
Si vous utilisez une bibliothèque cliente fournie par Google, les nouvelles tentatives avec intervalle exponentiel après une erreur sont mises en œuvre pour vous.
Si vous avez mis en œuvre votre propre bibliothèque cliente à l'aide de REST ou gRPC, vous devez mettre en œuvre les nouvelles tentatives pour votre client. Pour plus d'informations sur les erreurs pour lesquelles vous devez ou non effectuer une nouvelle tentative, consultez la section Propositions d'amélioration des API : configuration des nouvelles tentatives automatiques.
Erreurs de webhook
Si votre appel d'API déclenche un appel de webhook, celui-ci peut renvoyer une erreur.
Même si vous utilisez une bibliothèque cliente fournie par Google, les erreurs du webhook ne feront pas automatiquement l'objet d'une nouvelle tentative.
Votre code doit mettre en œuvre les nouvelles tentatives en cas d'erreur 503 Service Unavailable reçue en provenance de votre webhook.
Consultez la documentation du service de webhook pour plus d'informations sur les types d'erreurs de webhook et sur la façon de les vérifier.
Tests de charge
Il est recommandé d'exécuter des tests de charge pour votre système avant de publier le code en production. Tenez compte de ces points avant de mettre en œuvre vos tests de charge :
| Résumé | Détails |
|---|---|
| Augmentez la charge. | Votre test de charge doit augmenter la charge appliquée au service Dialogflow. Le service n'est pas conçu pour gérer les augmentations brusques de la charge, qui surviennent rarement avec du trafic réel. Il faut du temps pour que le service s'adapte aux demandes de charge. Augmentez donc lentement le débit des requêtes jusqu'à ce que votre test atteigne la charge souhaitée. |
| Les appels d'API sont facturés. | Les appels d'API vous seront facturés lors d'un test, et les appels seront limités par le quota du projet. |
| Utilisez des doubles de test. | Vous n'aurez peut-être pas besoin d'appeler l'API lors de votre test de charge. Si l'objectif de votre test de charge est de déterminer la manière dont votre système gère la charge, il est souvent préférable d'utiliser un double de test à la place d'appels réels à l'API. Votre double de test peut simuler le comportement de l'API en charge. |
| Utilisez les nouvelles tentatives. | Votre test de charge doit effectuer des nouvelles tentatives en appliquant un intervalle entre les tentatives. |
Appeler Dialogflow de façon sécurisée depuis un appareil d'utilisateur final
Vous ne devez jamais stocker les clés privées utilisées pour accéder à l'API Dialogflow sur un appareil d'utilisateur final. Cela s'applique au stockage direct des clés sur l'appareil, mais aussi au codage des clés en dur dans les applications. Lorsque votre application cliente doit appeler l'API Dialogflow, elle doit envoyer des requêtes à un service de proxy appartenant au développeur, sur une plate-forme sécurisée. Le service proxy peut ensuite effectuer les appels Dialogflow réels authentifiés.
Par exemple, vous ne devez pas créer d'application mobile qui appelle directement Dialogflow. Effectivement, cela impliquerait de stocker des clés privées sur l'appareil d'un utilisateur final. Votre application mobile doit transmettre les requêtes via un service de proxy sécurisé.
Performances
Cette section présente des informations sur les performances de diverses opérations dans Dialogflow. Comprendre la latence est important pour concevoir des agents réactifs et définir des attentes de performances réalistes, bien que ces valeurs ne fassent pas partie du contrat de niveau de service de Dialogflow.
Lorsque vous créez des outils de surveillance et d'alerte, notez que les grands modèles de langage (LLM) et le traitement du langage parlé sont généralement gérés à l'aide de méthodes de streaming. Les réponses sont envoyées au client dès que possible, souvent bien avant la durée totale de l'appel de méthode. Pour en savoir plus, consultez les bonnes pratiques concernant les grands modèles de langage (LLM).
Performances par opération
Le tableau suivant fournit des informations sur les performances typiques des opérations Dialogflow:
| Action | Remarques |
|---|---|
| Actions de flux: gestionnaires d'état | Opération la plus rapide |
| Flux: détection d'intents (texte) | Opération la plus rapide |
| Flux: détection de paramètres (texte) | Opération rapide |
| Reconnaissance vocale (flux) | Les données sont traitées et les réponses sont renvoyées dès que possible. Le temps d'exécution total est principalement déterminé par la durée de l'audio d'entrée. Nous vous déconseillons de mesurer la latence à l'aide de la durée d'exécution totale. |
| Synthèse vocale (streaming) | Le temps d'exécution total est principalement déterminé par la durée de l'audio de sortie. Les données sont traitées et les réponses sont renvoyées dans les plus brefs délais. |
| Datastores: IA générative désactivée | La durée réelle dépend de la taille du magasin de données. |
| Data stores: IA générative activée | Les performances dépendent de la taille du store de données, du modèle de langage utilisé et de la longueur de la sortie et de l'entrée de l'invite, dans cet ordre. |
| Retour à la valeur par défaut générative | Les performances dépendent de la langue utilisée, de la longueur de la sortie de l'invite et de la longueur de la saisie, dans cet ordre. |
| Générateurs | Les performances dépendent du modèle de langage utilisé, de la complexité de la requête d'entrée et de la longueur de la sortie, ainsi que du nombre de générateurs dans le tour. L'utilisation de plusieurs générateurs dans une même conversation entraîne plusieurs appels à un modèle de langage. |
| Exécution des playbooks | Les performances dépendent de la complexité du playbook, du nombre d'invites et du temps d'exécution des outils appelés. La longueur de la sortie et de l'entrée de la requête a un impact sur ces performances. Plusieurs invites de modèle de langue peuvent être exécutées de manière séquentielle, ce qui augmente la durée totale de l'appel. |
| Playbooks: outils | Les performances dépendent de l'exécution sous-jacente de l'outil. |
| Appels Webhook | Les performances sont directement déterminées par le temps d'exécution de votre code dans le webhook. |
| Agent d'importation / exportation | Les performances dépendent de la taille de l'agent. |
| Formation des agents | Les performances dépendent du nombre de flux, d'intents et d'expressions d'entraînement. L'entraînement de grands agents peut prendre plusieurs dizaines de minutes. |
| Création de l'environnement | La création d'un environnement implique l'entraînement de l'agent. La durée totale dépend donc de la taille et de la complexité de l'agent. |
Remarques importantes :
- Streaming:pour les appels en streaming (reconnaissance vocale et synthèse), les données sont traitées à mesure qu'elles arrivent, et les réponses sont renvoyées dès que possible. Cela signifie que la réponse initiale est généralement beaucoup plus rapide que la durée totale de l'appel.
- Playbooks:une requête LLM est créée en fonction des instructions du playbook, du contexte de la conversation et de l'entrée de l'outil. Plusieurs invites LLM peuvent être exécutées dans un seul appel de playbook. C'est pourquoi l'exécution du playbook est variable, en fonction du nombre d'invites émises et de la complexité des appels.
Remarques importantes concernant la latence
- Aucune garantie de latence:les contrats de niveau de service Dialogflow ne tiennent pas compte de la latence, même avec le débit provisionné.
- Latence du LLM:sachez que le traitement du LLM peut entraîner une latence importante. Tenez compte de ce point dans la conception de votre agent et dans les attentes des utilisateurs.
- Surveillance et alerte:lorsque vous configurez la surveillance et les alertes, tenez compte de la nature en streaming des réponses des LLM et des services vocaux. Ne partez pas du principe que le temps de réponse complet est égal au délai avant la première réponse.