Playbooks génératifs

Les playbooks génératifs offrent un nouveau moyen de créer des agents Dialogflow CX à l'aide de grands modèles de langage (LLM). Plutôt que de définir des flux, des pages, des intents et des transitions, vous fournissez des instructions en langage naturel et des données structurées sous la forme de playbooks. Cela peut considérablement réduire le temps de création et de maintenance des agents, et permettre à votre entreprise de profiter de tout nouveaux types d'expériences de conversation.

Si vous avez toujours besoin du contrôle explicite fourni par les flux dans certains scénarios de conversation, vous pouvez combiner la puissance des playbooks et des flux dans un seul agent hybride.

Limites

Les limites suivantes s'appliquent :

  • Seul l'anglais est accepté.
  • Seules les régions us-central1 et global sont acceptées.
  • Les agents du playbook ne prennent pas en charge l'envoi d'un SMS d'appel associé à partir de la route d'intent d'accueil par défaut dans le flux de démarrage par défaut, mais vous pouvez activer l'option d'envoi de SMS associés aux appels dans les flux standards.

Présentation du playbook

Un playbook est le composant de base d'un agent playbook. Un agent dispose généralement de nombreux playbooks, chacun étant défini pour gérer des tâches spécifiques. Les données du playbook sont fournies au LLM. Il dispose donc des informations nécessaires pour répondre aux questions et exécuter des tâches. Chaque playbook peut fournir des informations, envoyer des requêtes à des services externes ou différer la gestion des conversations vers un flux traditionnel ou un autre playbook pour gérer les sous-tâches.

Créer des agents du playbook

Lorsque vous créez un agent Dialogflow, vous pouvez lui demander de démarrer une conversation avec un playbook (agent playbook) ou avec un flux (agent traditionnel).

Pour créer un agent playbook:

  1. Suivez les étapes pour créer un agent, en sélectionnant Créer votre propre agent.
  2. Sélectionnez le type d'agent Generative (Génératif).
  3. Cliquez sur Enregistrer.

Notez que trois nouveaux sélecteurs de ressources apparaissent dans le panneau de navigation de gauche. Ces sélecteurs vous permettent de choisir entre:

  • Ressources de flux
  • Ressources génératives
  • Ressources partagées

Lorsque vous créez un agent playbook, un playbook par défaut est automatiquement créé.

Données du playbook

Cette section décrit les données qui définissent un playbook.

Nom du playbook

Le nom du playbook est le nom à afficher pour le playbook. Les différents playbooks peuvent porter ce nom.

Objectif du playbook

L'objectif d'un playbook est une description générale de ce qu'il doit accomplir.

Exemple :

Help customers to book flights and hotels.

Étapes du playbook

Les étapes du playbook définissent le processus à suivre pour atteindre son objectif.

Chaque étape contient une instruction en langage naturel pouvant contenir l'un des éléments suivants:

  • Instruction de base que le LLM peut comprendre.
  • Instruction pour acheminer l'utilisateur vers un autre playbook. Les playbooks sont référencés au format ${PLAYBOOK: playbook_name}.
  • Une instruction pour utiliser un outil spécifique. Les outils sont référencés sous la forme ${TOOL: tool_name}.
  • Instruction permettant de rediriger l'utilisateur vers un flux Dialogflow. Les flux sont référencés au format ${FLOW: flow_name}.

La description de chaque étape commence par "-", et vous pouvez définir des sous-étapes à l'aide d'un retrait.

Exemple :

- greet the customer and ask them how you can help.
    - If the customer wants to book flights, route them to ${PLAYBOOK: flight_booking}.
    - If the customer wants to book hotels, route them to  ${PLAYBOOK: hotel_booking}.
    - If the customer wants to know trending attractions, use the ${TOOL: attraction_tool} to show them the list.
- help the customer to pay for their booking by routing them to ${FLOW: make_payment}.

Paramètres du playbook

Les playbooks peuvent accepter et émettre des informations de contexte à l'aide de paramètres définis explicitement. Une fois que vous avez créé un playbook, les paramètres sont définis par playbook dans l'onglet Paramètres.

Les paramètres du playbook sont associés à un type, un nom et une description. Après avoir défini les paramètres, utilisez-les dans des exemples de playbook afin de lui montrer comment lire, écrire et utiliser les valeurs de paramètres de manière fiable. Pour en savoir plus, consultez les exemples de playbooks et les paramètres de transmission.

Paramètres d'entrée du playbook

Les paramètres d'entrée permettent aux playbooks d'utiliser des valeurs transmises à partir de flux et d'autres playbooks. Par exemple, un playbook peut recevoir le nom préféré d'un utilisateur en tant que paramètre et l'utiliser pour le remercier personnellement, ou un playbook peut recevoir un identifiant de commande en tant que paramètre et l'utiliser pour récupérer les détails de la commande à l'aide d'un outil.

Les paramètres d'entrée des playbooks sont définis par playbook, et par défaut, ils ne peuvent pas voir les autres types de paramètres Dialogflow CX. Lorsqu'un flux passe à un playbook, les paramètres de page et de session sont propagés au playbook si celui-ci cible comporte un paramètre d'entrée portant le même nom. Pour communiquer des informations d'un flux à un playbook lors d'une transition, définissez les paramètres d'entrée du playbook et portent le même nom qu'un paramètre de session ou de page présent avant la transition.

Créez des exemples pour contrôler l'impact de la valeur du paramètre d'entrée sur les actions du playbook. Par exemple, si un paramètre d'entrée doit affecter la façon dont l'agent fait référence à l'utilisateur, créez des exemples qui définissent une valeur pour le paramètre, puis utilisez la même valeur dans les actions d'énoncé de l'exemple. Pour en savoir plus, consultez la section Transmettre des paramètres.

Paramètres de sortie du playbook

Les paramètres de sortie permettent aux playbooks d'émettre des informations qui seront utilisées par d'autres flux ou playbooks. Par exemple, un playbook peut collecter un numéro de commande auprès d'un utilisateur et l'émettre via un paramètre de sortie, ou utiliser un outil pour réserver un vol et émettre le numéro de confirmation via un paramètre de sortie.

Créez des exemples pour contrôler la manière dont le playbook doit décider de la valeur de chaque paramètre de sortie. Par exemple, si un paramètre de sortie représentant un numéro de confirmation doit obtenir sa valeur de la sortie d'une utilisation d'un outil, créez des exemples dans lesquels la sortie de l'utilisation de l'outil correspond à la valeur du paramètre de sortie du playbook.

Transmettre des paramètres

Contrairement aux flux, les playbooks ne permettent pas d'injecter des valeurs de paramètres avec une syntaxe particulière. À la place, les playbooks s'appuient sur des instructions et des exemples de requête few-shot pour déterminer comment les valeurs de paramètre doivent être utilisées et comment les valeurs doivent être décidées lorsque vous spécifiez les valeurs des paramètres.

Prenons l'exemple d'un agent conçu pour la vente de billets d'événements et proposant les playbooks suivants:

  1. Un playbook nommé Ticket ordering, qui passe des commandes à l'aide d'un outil nommé Ticket sales API.
    1. Ce playbook accepte un paramètre d'entrée de type number et le nom event_id.
    2. L'outil Ticket sales API attend une requête incluant un élément event_id.
  2. Playbook nommé Event selection, qui aide les utilisateurs à sélectionner un événement, puis les achemine vers Ticket ordering avec le paramètre event_id pour acheter des billets.

Dans cet exemple, pour vous assurer que event_id est transmis de manière fiable de Event selection à Ticket ordering et de Ticket ordering à Ticket sales API, plusieurs exemples sont nécessaires.

Le playbook sur Ticket ordering doit inclure plusieurs exemples:

  • Le paramètre d'entrée event_id doit être spécifié avec une valeur réaliste, différente dans chaque exemple.
  • Incluez une action d'utilisation de l'outil avec un corps de requête incluant la même valeur event_id réaliste que celle spécifiée dans le paramètre d'entrée.

Le playbook sur Event selection doit inclure plusieurs exemples:

  • Incluez un énoncé dans lequel l'utilisateur sélectionne un événement avec une event_id réaliste, différente dans chaque exemple.
  • Incluez une invocation de playbook de Ticket ordering qui définit le paramètre event_id sur la même valeur event_id réaliste que celle déterminée par la sélection de l'utilisateur.

En plus d'ajouter des exemples, essayez d'ajouter des instructions spécifiques aux étapes du playbook, à l'objectif du playbook ou aux détails de l'outil expliquant comment utiliser les paramètres. Par exemple, le playbook Ticket ordering comprend l'étape suivante:

- Use parameter event_id to send a buy_tickets request with ${TOOL: Ticket sales API}

Avec les exemples et les instructions décrits ci-dessous, le playbook Event selection choisit correctement une event_id en fonction de la sélection de l'utilisateur et la transmet en tant que paramètre d'entrée nommé event_id à Ticket ordering playbook. Ensuite, Ticket ordering transmet le même event_id dans le corps d'une requête à Ticket sales API. Les playbooks dépendent d'exemples avec des valeurs de paramètres distinctes pour les aider à déterminer comment les paramètres doivent être utilisés.

Exemples de playbooks

Chaque playbook doit comporter un ou plusieurs exemples. Ces exemples sont des exemples de conversations entre un utilisateur final et l'agent, y compris les dialogues et les actions effectués par l'agent. Il s'agit en fait d'exemples de requêtes few-shot pour le LLM.

La console fournit une interface qui vous permet de saisir des actions. Exemple :

Capture d'écran d'un exemple d'entrée

Exemple de résumé des entrées et de sortie

En plus des paramètres d'entrée et de sortie, les playbooks permettent de recevoir un résumé des entrées et d'émettre un résumé des sorties 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 d'ajuster ses actions en fonction des résumés des entrées au moment de l'exécution. Ajoutez des résumés de sortie comprenant des détails pertinents et précis sur l'exemple de conversation pour indiquer au playbook les détails qu'il est important de résumer.

Exemples de paramètres d'entrée et de sortie

Outre le résumé des entrées et des sorties, si un playbook définit des paramètres d'entrée ou de sortie, tous ses exemples doivent également définir ces paramètres d'entrée ou de sortie pour aider le modèle de langage à déduire comment utiliser les valeurs de paramètres de manière fiable.

Chaque exemple du playbook doit spécifier et utiliser des valeurs pour chaque paramètre défini dans le playbook, comme indiqué dans ce playbook avec deux paramètres d'entrée et un paramètre de sortie:

Capture d'écran d'un exemple avec les paramètres d'entrée et de sortie renseignés

Exemple d'état de sortie du playbook

Pour chaque exemple que vous créez, sélectionnez l'état du playbook qui représente le mieux l'état final de l'exemple de conversation:

  • OK: l'objectif du playbook a été atteint.
  • CANCELLED: le playbook s'est arrêté sans atteindre son objectif en raison des circonstances dans la conversation. Par exemple, cet état peut être approprié si la conversation implique qu'un utilisateur change d'avis sur le sujet pour lequel il souhaite obtenir de l'aide.
  • FAILED: le playbook s'est arrêté sans atteindre son objectif en raison d'une erreur ou d'une situation difficile à gérer. Par exemple, cet état peut être approprié si l'objectif n'a pas pu être atteint en raison de problèmes de réseau lors d'un appel d'outil.
  • ESCALATED: le playbook s'est arrêté sans atteindre son objectif, car l'utilisateur a demandé à être transmis à un agent humain.

Stratégie de récupération

La stratégie de récupération détermine si chaque exemple est inclus ou non dans l'invite du playbook.

  • DEFAULT: l'exemple peut être omis si l'invite s'approche de la limite de jetons.
  • STATIC: l'exemple est toujours inclus.
  • NEVER: l'exemple n'est jamais inclus dans l'invite. Cet exemple n'aura aucun effet sur les performances du playbook.

Créer un playbook

Pour créer un playbook:

  1. Sélectionnez les ressources génératives dans le panneau de navigation de gauche.
  2. Cliquez sur Playbooks.
  3. Cliquez sur Créer.
  4. Fournissez les données comme décrit ci-dessus.

Playbook par défaut

Lorsque vous créez un agent génératif, un playbook par défaut est créé automatiquement.

Le playbook par défaut est le point de départ des conversations. Il présente donc des différences importantes par rapport aux autres playbooks:

  • Le playbook par défaut ne reçoit pas de résumé des tours de conversation précédents.
  • Le playbook par défaut ne peut pas définir ni recevoir de paramètres d'entrée.

Versions du playbook

Vous pouvez enregistrer les versions des playbooks, qui sont des instantanés immuables des playbooks.

Pour enregistrer une version du playbook:

  1. Chargez le playbook dans la console.
  2. Cliquez sur Historique des versions.
  3. Cliquez sur Créer une version.
  4. Attribuez un nom à la version, puis cliquez sur Enregistrer.

Pour afficher l'historique des versions:

  1. Chargez le playbook dans la console.
  2. Cliquez sur Historique des versions.
  3. Cliquez sur Afficher l'historique des versions.
  4. Le panneau de l'historique des versions s'ouvre sur la droite. Vous pouvez cliquer sur chaque version pour afficher son contenu.

Outils

Les étapes du playbook peuvent référencer les outils à utiliser pour accomplir cette étape. Vous devez fournir les détails de chaque outil utilisé par ces playbooks en fournissant un schéma OpenAPI.

Les appels d'API HTTP ou les requêtes sur le data store sont actuellement acceptés.

Vous pouvez fournir un ID de session en tant que paramètre de chemin ou de requête. Exemple :

parameters:
  - name: petId
    in: path
    description: ID of pet that needs to be updated
    required: true
    schema:
      $ref: '@dialogflow/sessionId'
  - name: petName
    in: query
    description: ID of pet that needs to be updated
    required: true
    schema:
      $ref: '@dialogflow/sessionId'

Les limites suivantes s'appliquent aux appels d'API HTTP:

  • À l'exception de l'ID de session, les paramètres de requête ne sont pas acceptés.
  • Le corps de la requête et de la réponse doit être vide ou au format JSON.
  • Les fonctionnalités de schéma avancées telles que oneOf ne sont pas compatibles.

L'exemple suivant montre comment référencer un data store:

"dataStoreConnections": [
    {
       "dataStoreType": "DATA_STORE_TYPE",
       "dataStore": "projects/PROJECT_ID/locations/LOCATION_ID/collections/default_collection/dataStores/DATA_STORE_ID"
    }
]

La valeur DATA_STORE_TYPE peut être l'une des suivantes:

  • PUBLIC_WEB: data store contenant du contenu Web public.
  • UNSTRUCTURED: data store contenant des données privées non structurées.
  • STRUCTURED: data store contenant des données structurées (par exemple, "FAQ").

L'exemple suivant montre comment référencer un outil API HTTP:

openapi: 3.0.2
info:
  title: Search Attraction Tool
  description: >-
    This API search for attractions for travel purposes
  version: 1.0
servers:
  - url: https://search-attraction.app
paths:
  /search:
    post:
      summary: Search for attractions given a query
      operationId: search
      requestBody:
        description: Query
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Query'
      responses:
        '200':
          description: Successfully got results (may be empty)
          content:
            application/json:
              schema:
                type: object
                properties:
                  results:
                    type: array
                    items:
                      type: string
components:
  schemas:
    Query:
      required:
        - text
      type: object
      properties:
        text:
          type: string

Bonnes pratiques

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

Au moins un exemple pour chaque playbook

Vous devez disposer d'au moins un exemple pour chaque playbook. Sans suffisamment d'exemples, un playbook est susceptible de provoquer un comportement imprévisible. Si votre agent ne répond pas ou ne se comporte pas de la manière attendue, 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 étapes instructions claires et descriptives, ce sont en fait la qualité et la quantité de vos exemples qui déterminent l'exactitude du comportement de l'agent. En d'autres termes, passez plus de temps à écrire des exemples détaillés qu'à rédiger des instructions parfaitement précises.

Champ "operationId" du schéma de l'outil

Lorsque vous définissez des schémas pour vos outils, la valeur operationId est importante. Les instructions de votre playbook feront référence à cette valeur. Voici quelques recommandations de dénomination pour ce champ:

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

Validation du schéma de l'outil

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

Générer un schéma avec Bard

Bard 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 spécifiques

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

Scénarios de test

La fonctionnalité de scénario de test existante a été améliorée pour accepter les playbooks.

Un champ obligatoire Résultat du scénario de test a été ajouté. Il fournit une liste d'actions sous la forme d'exemples de playbooks. Le scénario de test vérifie que les actions ont été effectuées comme prévu.

Lorsque vous consultez la version d'un playbook ou d'un playbook, vous pouvez cliquer sur l'onglet Scénarios de test au-dessus des données du playbook pour afficher les résultats et exécuter un scénario à la demande.

Vous pouvez également comparer les résultats des scénarios de test pour différentes versions d'un playbook. Sélectionnez un scénario de test, puis cliquez sur Comparer.

Pour afficher tous les scénarios de test de l'agent, cliquez sur Scénarios de test dans le panneau de navigation de gauche.

Historique de la conversation

La fonctionnalité existante d'historique des conversations a été améliorée pour accepter les playbooks.

Des informations ont été ajoutées pour l'exécution de l'outil ainsi que pour les appels de playbook et de flux à partir d'un agent de playbook.