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
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 à 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.
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é.