Chaque playbook doit comporter un ou plusieurs exemples. Ces exemples sont des exemples de conversations entre un utilisateur final et le playbook, y compris le dialogue et les actions effectuées par l'agent. Il s'agit en fait de quelques exemples de prompts pour le LLM.
La console fournit une interface permettant de saisir des actions.
Agents multilingues
Si vous souhaitez que votre agent gère plusieurs langues, vos exemples doivent utiliser chacune d'elles.
Exemple de résumé d'entrée et de résumé de sortie
En plus des paramètres d'entrée et de sortie, les playbooks sont compatibles avec la réception d'un résumé d'entrée et l'émission d'un résumé de sortie pour échanger des informations avec d'autres playbooks. Les résumés sont utiles pour transmettre des informations contextuelles abstraites entre les playbooks, tandis que les paramètres sont plus utiles pour transmettre des champs structurés et bien définis entre les playbooks. Les paramètres sont le seul moyen d'échanger des données entre les flux et les playbooks.
Ajoutez des résumés d'entrée pertinents aux exemples pour conditionner le playbook afin qu'il ajuste ses actions en fonction des résumés d'entrée au moment de l'exécution. Ajoutez des résumés de sortie incluant des détails pertinents et précis sur l'exemple de conversation pour montrer au playbook les détails importants à résumer.
Exemple d'état
À un moment donné de la conversation, un playbook se trouve dans l'un des états suivants :
OK: le playbook a atteint son objectif et le contrôle est désormais transféré au playbook parent.CANCELLED: l'utilisateur a décidé de ne pas poursuivre l'objectif attribué au playbook. Le contrôle est désormais transféré au playbook parent. Si le playbook parent est un flux CX, l'intention de l'entrée utilisateur est détectée avant l'exécution du flux.FAILED: le playbook ne peut pas atteindre l'objectif en raison d'une erreur (par exemple, l'outil renvoie une erreur 500). La session se termine avec l'état "Échec". Un EndInteraction EndInteraction est ajouté à la réponse.ESCALATED: le playbook a décidé qu'il ne pouvait pas atteindre l'objectif et qu'il devait transmettre la situation à un humain. La session se termine avec l'état "Transmis". Un message EndInteraction est ajouté à la réponse.PENDING: la conversation se poursuit dans le playbook.
L'exemple de premier niveau et ses appels de playbook doivent être indiqués avec un état correspondant au playbook auquel ils font référence.
Stratégie de sélection
Le paramètre de stratégie de sélection contrôle si un exemple est inclus dans le prompt du playbook envoyé au LLM. Les options suivantes sont disponibles :
Sélectionner dynamiquement : l'exemple est inclus de manière conditionnelle, en fonction de sa pertinence pour le contexte de conversation actuel. L'exemple peut être omis si le prompt approche la limite de jetons.
Toujours sélectionner : l'exemple est toujours inclus, quel que soit le contexte de la conversation. L'exemple peut être omis si le prompt approche la limite de jetons.
Ne jamais sélectionner : l'exemple n'est jamais inclus dans le prompt. L'exemple n'aura aucun effet sur les performances du playbook. Ce paramètre est utile pour exclure temporairement un exemple à des fins de test.
Ajouter une action
Un exemple fourni dans un playbook se compose d'une série d'actions. Ces actions peuvent varier dans leurs combinaisons, mais elles décrivent principalement l'interaction entre l'utilisateur et le playbook, ainsi que les actions effectuées entre les deux pour répondre à la requête ou aux exigences de l'utilisateur.
Il existe deux façons d'ajouter des actions à un exemple :
- Pour ajouter une action manuellement, cliquez sur le bouton + en bas du volet de droite ou sur le bouton Ajouter une action lorsque vous pointez sur des actions existantes. Vous pouvez utiliser ces options lorsque vous créez un nouvel exemple en cliquant sur l'option + Exemple ou lorsque vous modifiez un exemple existant.
- Pour générer automatiquement des actions en fonction des instructions de playbook existantes, saisissez une entrée utilisateur dans le champ Saisir l'entrée utilisateur en bas du volet de droite. Vous pouvez utiliser cette option lorsque vous créez ou modifiez un exemple. Vous pouvez également utiliser cette option lorsque vous testez votre playbook au moment de l'exécution dans le volet Aperçu du playbook à droite. Pour enregistrer des actions dans un exemple à partir du volet Aperçu du playbook , cliquez sur Enregistrer l'exemple après avoir sélectionné l'appel de playbook dans la liste des appels à gauche du volet Aperçu du playbook.
Veillez à vérifier l'exactitude des actions générées automatiquement et à les modifier si nécessaire. Cela est particulièrement important pour les playbooks qui ne comportent que peu ou pas d'exemples.
Les types d'actions suivants sont compatibles avec le playbook :
Réponse du playbook
Réponse du playbook à la requête de l'utilisateur.
Entrée utilisateur
Requête de l'utilisateur.
Utilisation de l'outil
Il s'agit d'un appel d'outil permettant d'obtenir des informations supplémentaires nécessaires pour répondre à la requête de l'utilisateur. Cette action doit spécifier les informations suivantes :
Outil : nom de l'outil à appeler.
Action : nom de l'opération de l' outil OpenAPI à appeler. Pour les outils de datastore et les outils de fonction, le nom de l'action est le même que le nom de l'outil.
Entrée de l'outil : entrées à inclure dans l'appel de l'outil. Elles sont généralement dérivées des tours de conversation précédents avec l'utilisateur.
Pour les outils Open API,
requestBodyJSON est requis pourPOST,PUTetPATCHtypes de méthodes.Exemple d'entrée
requestBody`requestBody` de l'outil Open API pour l'action createPet :{ "id": 1, "name": "Luna" }Pour l'outil de data store, l'exemple
requestBodyoù la requête est obligatoire et les autres champs sont facultatifs.{ "query": "Where is my nearest store?", "filter": "country: ANY(\"United States\")", "userMetadata": { "userCity": "San Francisco", }, "fallback": "We don't have any stores in your area." }Sortie de l'outil : réponse de l'appel de l'outil. Il s'agit d'une réponse JSON valide de l'outil à l'entrée donnée. Pour les outils Open API, il peut également s'agir d'une chaîne d'erreur (par exemple, "404 Not found").
Exemple de sortie de l'outil Open API pour l'action listPets :
{ "pets": [ { "id": 1, "name": "Luna" }, { "id": 2, "name": "Charlie" }] }Exemple de sortie de l'outil de datastore :
{ "answer": "Here's the address to your nearest store ...", "snippets": [ { "title": "San Francisco Downtown", "uri": "https://www.example.com/San_Francisco_Downtown", "text": "Address for San Francisco Downtown .." } ] }
Pour vous assurer que le playbook est sécurisé, incluez également des exemples de la façon dont le playbook doit répondre en cas d'échec de l'appel de l'outil.
L'échec de l'appel de l'outil Open API
peut être représenté par une chaîne d'erreur ("404 not found")
dans la sortie de l'outil.
Pour
les outils de datastore
l'entrée fallback peut être utilisée pour spécifier comment répondre
en l'absence de réponse résumée.
Si vous souhaitez que votre
outil de datastore
inclue un URI dans la réponse du playbook,
ajoutez des exemples contenant l'URI avec lequel vous souhaitez que le playbook réponde.
Si cet URI provient de l'
outil de datastore,
la sortie de l'
outil de datastore
doit contenir un URI correspondant à l'URI de la réponse du playbook.
Note fallback ne peut pas être utilisé dans ce scénario
car il désactivera la capacité du playbook LLM à reformuler la
réponse de l'outil de datastore
pour inclure des URI dans la réponse du playbook.
Les exemples contenant des actions d'utilisation d'outils peuvent être très détaillés et contribuer à une augmentation de la consommation de la limite de jetons d'entrée. Pour garantir une utilisation efficace des jetons, assurez-vous que les sorties d'outils sont concises et contiennent des informations pertinentes pour les objectifs du playbook. Pour les outils de datastore, envisagez de supprimer des extraits des exemples car ils peuvent contribuer à une consommation élevée de jetons d'entrée.
Appel de playbook
Cette action est utilisée lorsque le playbook doit appeler un autre playbook de tâches pour répondre à la requête de l'utilisateur. Cette action doit spécifier les informations suivantes :
- Playbook : nom du playbook à appeler.
- Résumé de l'entrée de l'appel de playbook: Résumé des parties pertinentes de la conversation précédente utile au playbook appelé.
- Paramètres d'entrée: Paramètres d'entrée à transmettre au playbook.
- Résumé de la sortie de l'appel de playbook: Résumé de ce que le playbook doit générer une fois son objectif atteint.
- Paramètres de sortie: Paramètres de sortie générés par le playbook une fois son objectif atteint.
Transition de playbook
Une action de transition de playbook est une action terminale (ne doit pas être suivie d'autres actions) qui indique que le playbook de routine a décidé de quitter et de passer à un playbook de routine cible. Étant donné que cette action indique que le playbook quitte, ajoutez les paramètres de sortie du playbook à la sortie du playbook de l'exemple.
Appel de flux
Cette action est utilisée lorsque le playbook de tâches doit appeler un flux. Cette action doit spécifier les informations suivantes :
- Flux : nom du flux à appeler.
- Paramètres d'entrée du flux: Paramètres d'entrée à transmettre au flux.
- Paramètres de retour du flux : paramètres de sortie renvoyés par le flux.
Transition de flux
Une action de transition de flux est une action terminale (ne doit pas être suivie d'autres actions) qui indique que le playbook de routine a décidé de quitter et de passer à un flux cible. Étant donné que cette action indique que le playbook quitte, ajoutez les paramètres de sortie du playbook à la sortie du playbook de l'exemple.