Ce guide présente les bonnes pratiques d'utilisation du 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 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 dans votre projet. Semblables à la fonctionnalité Historique des modifications, les journaux d'audit peuvent vous aider à suivre les modifications apportées lors de la conception aux agents Dialogflow CX associés au 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.
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. 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 |
|---|---|
| Actions de flux : gestionnaires d'état | Opération la plus rapide |
| Flux : détection d'intent (texte) | Opération la plus rapide |
| Flux : détection des 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. |
| Data stores : IA générative désactivée | La durée réelle dépend de la taille du data store. |
| Datastores : compatibles avec l'IA générative | Les performances dépendent de la taille du data store, du modèle de langage utilisé et de la longueur de l'entrée et de la sortie du prompt, dans cet ordre. |
| Remplacement génératif | Les performances dépendent de la langue utilisée, de la longueur de la sortie du prompt et de la longueur de l'entrée, dans cet ordre. |
| Générateurs | Les performances dépendent du modèle de langage utilisé, de la complexité du prompt d'entrée et de la longueur de la sortie, et du nombre de générateurs dans le tour. Si vous utilisez plusieurs générateurs au cours d'un même tour, le modèle de langage sera appelé plusieurs fois. |
| Exécution des playbooks | Les performances dépendent de la complexité du playbook, du nombre de requêtes et du temps d'exécution des outils appelés. La longueur de la sortie et de l'entrée du prompt a un impact sur ces performances. Plusieurs requêtes de modèle de langage peuvent être exécutées en série, ce qui s'ajoute à 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 / 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 d'expressions d'entraînement. L'entraînement d'agents volumineux 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 de 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 : une requête LLM est construite en fonction des instructions du playbook, du contexte de la conversation et de l'entrée de l'outil. Plusieurs requêtes 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 de requêtes é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-en compte dans la conception de votre agent et dans 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.