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 par étapes pour résoudre un problème d'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 d'entraîner 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 outils 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
operationIddé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 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 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 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: