Bonnes pratiques concernant les playbooks

Les bonnes pratiques suivantes peuvent vous aider à créer des agents robustes.

Nom du playbook en langage naturel

Utilisez un langage naturel avec des noms de playbooks clairs. Par exemple, "Guide du centre d'aide client" est plus descriptif que "company_specialist", ce qui améliore les performances de la LLM au moment de l'exécution.

Objectifs concis

Les objectifs doivent être une description concise de l'objectif du playbook.

Fournir des instructions de qualité

Les instructions doivent:

  • refléter l'approche étape par étape pour résoudre un problème de l'utilisateur final ;
  • être des phrases concises en langage naturel contenant des instructions de haut niveau ;
  • être simple et spécifier les scénarios d'utilisation de l'outil ;

Au moins un exemple pour chaque playbook

Vous devez inclure au moins un exemple pour chaque playbook, mais nous vous recommandons d'en inclure au moins quatre. Les exemples doivent inclure des scénarios de parcours réussi.

Sans suffisamment d'exemples, un playbook est susceptible de générer un comportement imprévisible. Si votre playbook ne répond pas ou ne se comporte pas comme prévu, cela est probablement dû à des exemples manquants ou mal définis. Essayez d'améliorer vos exemples ou d'en ajouter.

Précision des instructions et des exemples

Bien qu'il soit utile d'écrire des instructions claires et descriptives, c'est la qualité et la quantité de vos exemples qui déterminent la précision du comportement du playbook. En d'autres termes, consacrez plus de temps à rédiger des exemples détaillés qu'à rédiger des instructions parfaitement précises.

Faire référence à des outils dans des exemples

Si le playbook est conçu pour fournir des réponses à l'aide d'outils, référencez-les dans les exemples correspondant à ce type de requête.

Champ operationId du schéma de l'outil

Lorsque vous définissez des schémas pour vos outils, la valeur operationId est importante. Vos instructions de playbook feront référence à cette valeur. Voici les recommandations d'attribution de noms pour ce champ:

  • Lettres, chiffres et traits de soulignement uniquement.
  • Doit être unique parmi tous les operationId décrits dans le schéma.
  • Il doit s'agir d'un nom significatif reflétant la fonctionnalité fournie.

Validation du schéma de l'outil

Vous devez valider le schéma de votre outil. Vous pouvez utiliser l'éditeur Swagger pour vérifier la syntaxe de votre schéma OpenAPI 3.0.

Gérer les résultats vides de l'outil

Lorsque votre playbook s'appuie sur un outil pour définir sa réponse, un résultat d'outil vide peut entraîner un comportement imprévisible du playbook. Parfois, le LLM du playbook génère des informations dans une réponse au lieu d'un résultat d'outil. Pour éviter cela, vous pouvez ajouter des instructions spécifiques pour vous assurer que le LLM du playbook n'essaie pas de répondre seul.

Certains cas d'utilisation exigent que les réponses du playbook soient bien ancrées dans les résultats de l'outil ou les données fournies, et doivent atténuer les réponses uniquement en fonction des connaissances du LLM du playbook.

Exemples d'instructions pour atténuer les hallucinations:

  • "Vous devez utiliser l'outil pour répondre à toutes les questions des utilisateurs"
  • "Si vous ne recevez aucune donnée de l'outil, répondez que vous ne connaissez pas la réponse à la requête de l'utilisateur."
  • "N'inventez pas de réponse si vous n'obtenez aucune donnée de l'outil"

Générer un schéma avec Gemini

Gemini peut générer un schéma pour vous. Par exemple, essayez "Pouvez-vous créer un exemple de schéma OpenAPI 3.0 pour Google Agenda ?".

Playbooks ciblés

Évitez de créer des playbooks très volumineux et complexes. Chaque playbook doit accomplir une tâche spécifique et claire. Si vous avez un playbook complexe, envisagez de le diviser en sous-playbooks plus petits.

Éviter les boucles et la récursion

Ne créez pas de boucles ni de récursion lorsque vous associez des agents dans vos instructions.

Fournir des informations de calcul d'itinéraire pour les exemples

Lorsqu'un playbook doit être redirigé vers un autre playbook, vous devez fournir ces informations aux exemples. Il s'agit d'un exemple du champ Exemple de fin avec informations de sortie de la section d'exemples Entrée et sortie.

Par exemple, la dernière phrase de ce champ pourrait être "Redirection vers le playbook par défaut pour d'autres requêtes".

Utiliser des fonctions JavaScript Messenger pour les agents de conversation (Dialogflow CX) à des fins de personnalisation

Lorsque vous utilisez Messenger avec des agents de conversation (Dialogflow CX), les fonctions suivantes sont utiles pour envoyer des informations de personnalisation de l'utilisateur depuis l'interface Web au playbook: