Bonnes pratiques concernant les playbooks

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

Nom du playbook en langage naturel

Utilisez un langage naturel dont le sens est clair pour les noms de playbooks. Par exemple, "Client "Guide du centre d'aide" est plus descriptif que "spécialiste_entreprise", ce qui permet Performances du LLM au moment de l'exécution.

Des objectifs concis

Les objectifs doivent être une description concise du but du playbook.

Fournir des instructions de qualité

Les instructions doivent:

  • refléter l'approche étape par étape de la résolution d'un problème d'utilisateur final
  • être des phrases concises en langage naturel, contenant des instructions de haut niveau
  • être claires 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éussis.

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, des exemples manquants ou mal définis en sont probablement la cause. 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, la qualité et la quantité des exemples, qui déterminent l'exactitude 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.

Outils de référence dans les exemples

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

Champ operationId du schéma d'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 quelques recommandations d'attribution de noms pour ce champ:

  • Lettres, chiffres et traits de soulignement uniquement.
  • Doit être unique parmi tous les éléments 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éterminer sa réponse, un résultat d'outil vide peut entraîner un comportement imprévisible du playbook. Parfois, le LLM du playbook halluciner 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 nécessitent que les réponses des playbooks soient bien ancrées dans les résultats de l'outil ou données fournies et la nécessité d'atténuer les réponses uniquement sur la base des LLM du playbook connaissances.

Exemples d'instructions pour atténuer les hallucinations :

  • "Vous devez utiliser l'outil pour répondre à toutes les questions des utilisateurs"
  • « Si vous ne récupérez aucune donnée de l'outil, répondez que vous ne connaissez pas à la requête de l'utilisateur"
  • « N'inventez pas de réponse si vous ne récupérez pas de données 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 disposez d'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 routage aux 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 les fonctions JavaScript de Messenger d'agents conversationnels (Dialogflow CX) pour la personnalisation

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