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.
Vous devriez également consulter 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, qui est 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 la gestion des exceptions avec des nouvelles tentatives
Activer les journaux d'audit
Activez les journaux d'audit pour l'accès aux données dans l'API Dialogflow pour votre projet. Cela peut vous aider assurer le suivi des modifications de conception des agents Dialogflow associés à ce projet.
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 exportée de l'agent à jour. Cela vous permettra de récupérer rapidement l'agent ou le projet si vous ou les membres de votre équipe les supprimez accidentellement.
Réutilisation du client
Vous pouvez améliorer les performances de votre application en réutilisant les 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.
Pour en savoir plus, consultez le guide des bonnes pratiques concernant les bibliothèques clientes.
Mises à jour par lot de l'agent
Si vous envoyez de nombreuses requêtes API de mise à jour d'agent individuelles sur une courte période, vos requêtes risquent d'être ralenties. La mise en œuvre de ces méthodes d'API au moment de la conception n'est pas destinée à gérer des taux de mise à jour élevés pour un seul agent.
Pour certains types de données, des méthodes de traitement par lot peuvent être utilisées à cette fin :
- Plutôt que d'envoyer de nombreuses requêtes EntityTypes
create,patchoudelete, utilisez les méthodesbatchUpdateoubatchDelete. - Plutôt que d'envoyer de nombreuses requêtes Intents
create,patchoudelete, utilisez les méthodesbatchUpdateoubatchDelete.
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 décrit les performances de différentes opérations dans Dialogflow. Il est important de comprendre la latence pour concevoir des agents réactifs et définir des attentes réalistes en termes de performances, même si ces valeurs ne font pas partie du SLA Dialogflow.
Lorsque vous créez des outils de surveillance et d'alerte, notez que les grands modèles de langage (LLM) et le traitement de la parole 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 |
|---|---|
| Détection d'intention (texte) | Fonctionnement rapide |
| Détection de paramètres (texte) | Fonctionnement rapide |
| Reconnaissance vocale (streaming) | 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'entrée audio. Nous vous déconseillons de mesurer la latence à l'aide du temps d'exécution total. |
| Synthèse vocale (streaming) | Le temps d'exécution total est principalement déterminé par la durée de l'audio généré. Les données sont traitées et les réponses sont renvoyées le plus rapidement possible. |
| Appels Webhook | Les performances sont directement déterminées par le temps d'exécution de votre code dans le webhook. |
| Agent d'importation / d'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 de phrases d'entraînement. L'entraînement des 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épendra donc de la taille et de la complexité de l'agent. |
Remarques importantes :
- Streaming : pour les appels en streaming (reconnaissance et synthèse vocales), 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 : un prompt LLM est construit sur la base des instructions du playbook, du contexte de la conversation et de l'entrée de l'outil. Plusieurs prompts LLM peuvent être exécutés en un seul appel de playbook. C'est pourquoi l'exécution du playbook est variable, en fonction du nombre de prompts émis 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-en compte dans la conception de votre agent et les attentes des utilisateurs.
- Surveillance et alertes : lorsque vous configurez la surveillance et les alertes, tenez compte de la nature en flux continu des réponses des LLM et des services vocaux. Ne partez pas du principe que le délai de réponse complet est égal au délai avant la première réponse.