Certains produits et fonctionnalités sont en cours de changement de nom. Les fonctionnalités de playbook et de flux génératifs sont également en cours de migration vers une console unique. Consultez les détails.

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

Exemples de playbooks

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 d'exemples de requêtes few-shot pour le LLM.

La console fournit une interface pour 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é des entrées et des sorties

En plus des paramètres d'entrée et de sortie, les playbooks peuvent recevoir un résumé d'entrée et émettre un résumé de sortie pour échanger des informations avec d'autres playbooks. Les récapitulatifs 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écapitulatifs d'entrée pertinents aux exemples pour conditionner le playbook à ajuster ses actions en fonction des récapitulatifs d'entrée au moment de l'exécution. Ajoutez des résumés de sortie incluant des informations pertinentes et précises sur l'exemple de conversation pour indiquer au playbook les détails importants à résumer.

Exemple d'état

À un moment donné de la conversation, un playbook peut se trouver dans l'un des états suivants:

OK: Le playbook a atteint son objectif et le contrôle est maintenant transféré au playbook parent.
CANCELLED: l'utilisateur a décidé de ne pas poursuivre l'objectif attribué au playbook. Le contrôle est maintenant transféré vers le playbook parent. Si le playbook parent est un parcours CX, l'intent de l'entrée utilisateur sera détecté avant l'exécution du parcours.
FAILED: le playbook ne peut pas poursuivre l'objectif en raison d'une erreur (par exemple, l'outil renvoie une erreur 500). La session se termine avec l'état "fail". Un message EndInteraction est ajouté à la réponse.
ESCALATED: Le playbook a décidé qu'il ne pouvait pas atteindre l'objectif et qu'il devait escalader la situation à un humain. La session se terminera avec un état escaladé. Un message EndInteraction est ajouté à la réponse.
PENDING: la conversation se poursuit dans le playbook.

L'exemple de niveau supérieur et ses invocations de playbook doivent être associés à un état correspondant au playbook qu'ils référencent.

Stratégie de sélection

Le paramètre de stratégie de sélection contrôle si un exemple est inclus dans l'invite du playbook envoyée au LLM. Les options suivantes sont disponibles :

Sélection dynamique: l'exemple est inclus de manière conditionnelle, en fonction de son pertinence pour le contexte de conversation actuel. L'exemple peut être omis si l'invite approche de la limite de jetons. Vous pouvez éventuellement fournir des correspondances de mots.
Toujours sélectionner: l'exemple est toujours inclus, quel que soit le contexte de la conversation. L'exemple peut être omis si l'invite approche de la limite de jetons.
Ne jamais sélectionner: l'exemple n'est jamais inclus dans la requête. L'exemple n'aura aucun impact sur les performances du playbook. Ce paramètre est utile pour exclure temporairement un exemple à des fins de test.

Correspondances de mots

Vous pouvez éventuellement fournir des correspondances de mots pour les exemples avec une stratégie de sélection dynamique. Vous pouvez ainsi mieux contrôler si l'exemple est inclus dans l'invite. Nous vous recommandons de le faire pour les playbooks comportant plus de 100 exemples.

Vous pouvez fournir plusieurs expressions de correspondance sous la forme de mots simples à mettre en correspondance ou d'expressions régulières. Chaque expression de correspondance peut être de l'un des types suivants:

user: les correspondances sont vérifiées par rapport aux messages des utilisateurs finaux.
agent: les correspondances sont vérifiées par rapport aux messages de l'agent.
any: les correspondances sont vérifiées par rapport aux messages des utilisateurs finaux et des agents, ainsi qu'aux actions.

Lors de la recherche d'une correspondance, les expressions sont mises en correspondance avec au maximum les cinq derniers tours de conversation et le premier message de l'utilisateur final.

Si une correspondance est trouvée pour l'exemple, celui-ci est prioritaire sur les autres exemples sélectionnés dynamiquement sans correspondance de mots.

Le format des correspondances de mots est une liste séparée par des virgules, où chaque expression commence par le type d'expression et un deux-points. Exemple :

user:red,agent:blue,any:placeOrder

Ces éléments correspondent si l'une des conditions suivantes est remplie:

Un message de l'utilisateur final contient red.
Un message d'agent contient blue.
Tout message ou action contient placeOrder.

Ajouter une action

Un exemple fourni dans un playbook se compose d'une série d'actions. Les combinaisons de ces actions peuvent varier, mais elles décrivent principalement l'interaction entre l'utilisateur et le playbook, ainsi que les actions effectuées entre-temps pour répondre à la requête ou aux exigences de l'utilisateur.

Vous pouvez ajouter des actions à un exemple de deux manières:

Pour ajouter une action manuellement, cliquez sur le bouton + en bas du volet de droite ou sur le bouton Ajouter une action lorsque vous maintenez le pointeur sur des actions existantes. Vous pouvez utiliser ces options lorsque vous créez un 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 du playbook existant, saisissez une entrée utilisateur dans le champ Saisissez une 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 un exemple après avoir sélectionné l'appel du playbook dans la liste des appels à gauche du volet Aperçu du playbook.

Veillez à vérifier la justesse des actions générées automatiquement et à les modifier si nécessaire. Cela est particulièrement important pour les playbooks qui comportent peu ou pas d'exemples.

Les types d'actions suivants sont acceptés par 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'une invocation d'outil pour obtenir les 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 stockage de données et l'outil de fonction, le nom de l'action est identique à celui 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 échanges précédents avec l'utilisateur.

Pour les outils Open API, le format JSON requestBody est obligatoire pour les types de méthodes POST, PUT et PATCH.

Exemple d'entrée requestBody de l'outil Open API pour l'action createPet:
```
{
  "id": 1,
  "name": "Luna"
}
```
Pour l'outil de data store, l'exemple requestBody où 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 Fransisco",
  },
  "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 erreur de chaîne (par exemple, "404 Introuvable").

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 Data Store:

{
  "answer": "Here's the address to your nearest store ...",
  "snippets": [
    {
      "title": "San Fransisco Downtown",
      "uri": "https://www.example.com/San_Fransisco_Downtown",
      "text": "Address for San Fransisco Downtown .."
    }
  ]
}

Pour vous assurer que le playbook est sûr, incluez également des exemples de la façon dont il doit réagir 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 introuvable") 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écapitulative.

Si vous souhaitez que votre outil de stockage de données 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 stockage de données, la sortie de l'outil de stockage de données doit contenir un URI correspondant à celui de la réponse du playbook. Remarque : fallback ne peut pas être utilisé dans ce scénario, car il désactive la capacité du playbook LLM à reformuler la réponse de l'outil de stockage de données pour inclure des URI dans la réponse du playbook.

Les exemples contenant des actions d'utilisation d'outils peuvent être très longs et contribuer à une consommation accrue de la limite de jetons d'entrée. Pour utiliser efficacement les jetons, assurez-vous que les sorties de l'outil sont concises et contiennent des informations pertinentes par rapport aux objectifs du playbook. Pour les outils de stockage de données, envisagez de supprimer les extraits des exemples, car ils peuvent contribuer à une consommation élevée de jetons d'entrée.

Appel du playbook

Cette action est utilisée lorsque le playbook doit appeler un autre playbook pour répondre à la requête de l'utilisateur. Cette action doit spécifier les informations suivantes:

Playbook: nom du playbook à appeler.
Résumé des entrées d'appel du playbook: résumé des parties pertinentes de la conversation précédente utiles au playbook appelé.
Paramètres d'entrée: paramètres d'entrée à transmettre au playbook
Résumé de la sortie de l'appel du 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.

Instructions du playbook

Paramètres du playbook