Cette page a été traduite par l'API Cloud Translation.
Switch to English

Bonnes pratiques

Ce document répertorie les bonnes pratiques d'utilisation de Dialogflow. Ces consignes visent à améliorer l'efficacité et la précision du service, ainsi qu'à obtenir des temps de réponse optimaux.

Production

Avant d'exécuter l'agent en production, veillez à appliquer les bonnes pratiques suivantes:

Conception de l'agent

La conception de l'agent peut avoir un impact considérable sur la qualité et les performances de ce dernier. Consultez le guide de conception de l'agent pour connaître les bonnes pratiques à suivre dans ce domaine.

Versions de l'agent

Vous devez toujours utiliser des versions d'agent pour votre trafic de production. Pour plus d'informations, consultez la section Versions et environnements.

Nommer les intents

Si votre agent comporte de nombreux intents, vous devez envisager d'utiliser un schéma de dénomination qui vous aidera à les organiser. Il est courant de segmenter les noms d'intent avec des signes de ponctuation, où la spécificité augmente de gauche à droite. De plus, un nom d'intent doit refléter l'intention de l'utilisateur final pour un tour de conversation.

Il existe de nombreux schémas de nommage, mais en voici un exemple:

  • phone-service.order.cancel
  • phone-service.order.create
  • phone-service.order.change
  • tv-service.order.cancel
  • tv-service.order.create
  • tv-service.order.change.
  • compte.balance.get
  • account.balance.pay
  • compte.adresse.get
  • adresse.account.update.

Réutilisation du client de session

Vous pouvez améliorer les performances des appels d'API de détection d'intent de votre application en réutilisant une instance de bibliothèque cliente SessionsClient pour plusieurs requêtes.

Consultez la documentation de référence sur les Sessions.

Pour plus d'informations à ce sujet, consultez la page Bonnes pratiques relatives aux bibliothèques clientes.

Mises à jour par lot de l'agent

Si vous envoyez de nombreuses requêtes d'API de mise à jour d'agent individuelles sur une courte période, vos requêtes risquent d'être limitées. 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, patch ou delete, utilisez les méthodes batchUpdate ou batchDelete.
  • Plutôt que d'envoyer de nombreuses requêtes Intents create, patch ou delete, utilisez les méthodes batchUpdate ou batchDelete.

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 :

En outre, vous devez mettre en œuvre un intervalle exponentiel entre les tentatives pour les nouvelles tentatives. Cela permet à votre système de trouver un taux acceptable lorsque le service d'API est soumis à une charge importante.

Erreurs d'API Cloud

Si vous utilisez une bibliothèque cliente fournie par Google, les nouvelles tentatives d'erreur de l'API Cloud avec un intervalle exponentiel entre les tentatives 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 en savoir plus sur les erreurs à exécuter ou ne pas réessayer, consultez la page Propositions d'amélioration des API: configuration de la nouvelle tentative automatique.

Erreurs de webhook

Si votre appel d'API déclenche un appel webhook, celui-ci peut renvoyer une erreur. Même si vous utilisez une bibliothèque cliente fournie par Google, les erreurs de webhook ne seront pas réexécutées automatiquement. Votre code doit relancer les erreurs 503 Service Unavailable reçues du webhook. Consultez la documentation du service de webhook pour en savoir plus 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. Ce 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 s'adapter aux demandes de charge. Augmentez donc votre taux de demandes lentement, 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.