Playbook generativi

I playbook generativi offrono un nuovo modo per creare agenti Dialogflow CX utilizzando modelli linguistici di grandi dimensioni (LLM). Invece di definire flussi, pagine, intent e transizioni, fornisci istruzioni in linguaggio naturale e dati strutturati sotto forma di playbook. Ciò può ridurre notevolmente i tempi di creazione e manutenzione degli agenti, nonché creare nuovi tipi di esperienze di conversazione per la tua azienda.

Se hai comunque bisogno del controllo esplicito fornito dai flussi in determinati scenari di conversazione, puoi combinare la potenza dei playbook e dei flussi in un singolo agente ibrido.

Limitazioni

Si applicano le seguenti limitazioni:

  • È supportato soltanto l'inglese.
  • Sono supportate solo le regioni us-central1 e global.
  • Gli agenti playbook non supportano l'invio di un SMS compagno di chiamata dalla route Intent di benvenuto predefinito nel flusso di avvio predefinito, ma puoi abilitare l'opzione SMS companion per le chiamate nei flussi standard.

Panoramica sulla guida pratica

Un playbook è l'elemento di base di un agente. In genere, un agente ha molti playbook, in cui ciascuno è definito per gestire attività specifiche. I dati del playbook vengono forniti all'LLM, in modo che abbia le informazioni necessarie per rispondere alle domande ed eseguire le attività. Ogni playbook può fornire informazioni, inviare query a servizi esterni o rimandare la gestione delle conversazioni a un flusso tradizionale o a un altro playbook per gestire le attività secondarie.

Creazione agenti playbook

Quando crei un agente Dialogflow, puoi scegliere che l'agente avvii una conversazione con un playbook (agente playbook) o un flusso (agente tradizionale).

Per creare un agente playbook:

  1. Segui i passaggi per creare un agente, selezionando Crea il tuo.
  2. Seleziona Generative come tipo di agente.
  3. Fai clic su Salva.

Nota che ci sono tre nuovi selettori di risorse nel menu di navigazione a sinistra. Questi selettori ti consentono di scegliere tra:

  • Risorse di flusso
  • Risorse generative
  • Risorse condivise

Quando crei un agente playbook, viene creato automaticamente un playbook predefinito.

Dati playbook

Questa sezione descrive i dati che definiscono un playbook.

Nome playbook

Il nome del playbook è il nome visualizzato del playbook. I playbook possono fare riferimento l'uno all'altro con questo nome.

Obiettivo playbook

L'obiettivo di una guida pratica è una descrizione generale degli obiettivi che deve raggiungere.

Ad esempio:

Help customers to book flights and hotels.

Passaggi del playbook

I passaggi del playbook definiscono il processo da seguire per raggiungere l'obiettivo.

Ogni passaggio contiene un'istruzione di linguaggio naturale che può contenere:

  • Un'istruzione di base comprensibile all'LLM.
  • Un'istruzione per indirizzare l'utente a un altro playbook. Per fare riferimento ai playbook, viene utilizzato il modulo ${PLAYBOOK: playbook_name}.
  • Un'istruzione per utilizzare uno strumento specifico. Per fare riferimento agli strumenti viene utilizzato il modulo ${TOOL: tool_name}.
  • Un'istruzione per indirizzare l'utente a un flusso Dialogflow. Per fare riferimento ai flussi viene utilizzato il modulo ${FLOW: flow_name}.

La descrizione di ogni passaggio inizia con "- " e puoi definire i sottopassaggi usando il rientro.

Ad esempio:

- 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}.

Parametri playbook

I playbook possono accettare ed emettere informazioni sul contesto utilizzando parametri definiti esplicitamente. I parametri vengono definiti per playbook utilizzando la scheda Parametri dopo aver creato un playbook.

I parametri del playbook hanno un tipo, un nome e una descrizione. Dopo aver definito i parametri, utilizzali negli esempi del playbook in modo da mostrare al playbook come leggere, scrivere e utilizzare i valori parametro in modo affidabile. Per istruzioni, consulta gli esempi di input e output del playbook e il passaggio dei parametri.

Parametri di input del playbook

I parametri di input consentono ai playbook di utilizzare i valori trasferiti da flussi e altri playbook. Ad esempio, un playbook potrebbe ricevere il nome preferito di un utente come parametro e utilizzarlo per ringraziare l'utente personalmente oppure un playbook potrebbe ricevere un identificatore ordine come parametro e utilizzarlo per recuperare i dettagli dell'ordine utilizzando uno strumento.

I parametri di input del playbook vengono definiti per playbook e non hanno visibilità di altri tipi di parametri di Dialogflow CX per impostazione predefinita. Quando un flusso viene trasferito a un playbook, i parametri di pagine e sessioni vengono propagati al playbook se il playbook di destinazione ha un parametro di input con lo stesso nome. Per comunicare informazioni da un flusso a un playbook durante una transizione, definisci i parametri di input del playbook con lo stesso nome di un parametro sessione o pagina presente prima della transizione.

Crea esempi per controllare in che modo il valore parametro di input deve influire sulle azioni del playbook. Ad esempio, se un parametro di input deve influire sul modo in cui l'agente si riferisce all'utente, crea esempi che definiscano un valore per il parametro e poi utilizza lo stesso valore nelle azioni enunciate all'interno dell'esempio. Per ulteriori dettagli, consulta la sezione sul passaggio dei parametri.

Parametri di output del playbook

I parametri di output consentono ai playbook di emettere informazioni che possono essere utilizzate da altri flussi o playbook. Ad esempio, un playbook potrebbe raccogliere un numero d'ordine da un utente e inviarlo tramite un parametro di output oppure un playbook potrebbe utilizzare uno strumento per prenotare un volo ed emettere il numero di conferma tramite un parametro di output.

Crea esempi per controllare in che modo il playbook deve decidere il valore di ogni parametro di output. Ad esempio, se un parametro di output che rappresenta un numero di conferma deve ricavare il suo valore dall'output dell'utilizzo di uno strumento, crea degli esempi in cui l'output dell'utilizzo dello strumento corrisponda al valore del parametro di output del playbook.

Trasmissione dei parametri

Le guide pratiche, a differenza dei flussi, non supportano l'inserimento di valori parametro con una sintassi specifica. I playbook si basano invece su istruzioni ed esempi di prompt few-shot per determinare come devono essere utilizzati i valori dei parametri e come devono essere scelti i valori quando si specificano i valori dei parametri.

Prendi in considerazione un agente progettato per la vendita di biglietti per eventi con i seguenti playbook:

  1. Un playbook denominato Ticket ordering che effettua ordini utilizzando uno strumento denominato Ticket sales API.
    1. Questo playbook accetta un parametro di input di tipo number e nome event_id.
    2. Lo strumento Ticket sales API prevede una richiesta che includa un event_id.
  2. Un playbook denominato Event selection che aiuta gli utenti a selezionare un evento e poi li reindirizza a Ticket ordering con il parametro event_id per acquistare biglietti.

In questo esempio, per garantire che event_id venga trasmesso in modo affidabile da Event selection a Ticket ordering e da Ticket ordering a Ticket sales API, sono necessari diversi esempi.

Il playbook Ticket ordering deve includere più esempi che:

  • Hanno specificato il parametro di input event_id con un valore realistico, diverso in ogni esempio.
  • Includi un'azione di utilizzo dello strumento con un corpo della richiesta che includa lo stesso valore event_id realistico specificato nel parametro di input.

Il playbook Event selection deve includere più esempi che:

  • Includi un'espressione dell'utente in cui l'utente seleziona un evento con event_id realistici, diversi in ogni esempio.
  • Includi una chiamata al playbook Ticket ordering che imposta il parametro event_id sullo stesso valore event_id realistico deciso dalla selezione dell'utente.

Oltre ad aggiungere esempi, prova ad aggiungere istruzioni specifiche ai passaggi del playbook, all'obiettivo del playbook o ai dettagli dello strumento che spiegano come utilizzare i parametri. Ad esempio, il playbook Ticket ordering include il seguente passaggio:

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

Con gli esempi e le istruzioni descritti, il Playbook Event selection decide correttamente un event_id in base alla selezione dell'utente e la passa come parametro di input denominato event_id a Ticket ordering playbook. Quindi, Ticket ordering passa lo stesso event_id nel corpo di una richiesta a Ticket sales API. Le guide pratiche dipendono da esempi con valori parametro distinti per dedurre come devono essere utilizzati i parametri.

Esempi di playbook

Ogni playbook deve avere uno o più esempi. Questi esempi sono conversazioni di esempio tra un utente finale e l'agente, inclusi il dialogo e le azioni eseguite dall'agente. Questi sono effettivamente esempi di prompt few-shot per l'LLM.

La console fornisce un'interfaccia che consente di inserire le azioni. Ad esempio:

Screenshot della voce di esempio

Riepilogo degli input e degli output di esempio

Oltre ai parametri di input e di output, i playbook supportano la ricezione di un riepilogo degli input e dell'emissione di un riepilogo dell'output per lo scambio di informazioni con altri playbook. I riepiloghi sono utili per trasferire informazioni contestuali astratte tra i playbook, mentre i parametri sono più utili per il passaggio di campi strutturati e ben definiti tra i playbook. I parametri sono l'unico modo per scambiare dati tra flussi e playbook.

Aggiungi riepiloghi degli input pertinenti agli esempi per condizionare il playbook in modo che modifichi le sue azioni in base ai riepiloghi degli input in fase di runtime. Aggiungi riepiloghi degli output, inclusi dettagli pertinenti e precisi sulla conversazione di esempio per mostrare al playbook quali dettagli è importante riassumere.

Esempi di parametri di input e di output

Oltre a un riepilogo degli input e dell'output, se un playbook definisce parametri di input o di output, gli esempi del playbook devono definire tutti questi parametri anche per aiutare il modello linguistico a dedurre come utilizzare i valori dei parametri in modo affidabile.

Ogni esempio del playbook deve specificare e utilizzare i valori per ogni parametro definito nel playbook, come mostrato in questo playbook con due parametri di input e un parametro di output:

Screenshot di un esempio con parametri di input e di output completati

Esempio di stato dell'output del playbook

Per ogni esempio che crei, seleziona lo stato del playbook che rappresenta al meglio lo stato finale della conversazione di esempio:

  • OK: l'obiettivo della guida pratica è stato raggiunto.
  • CANCELLED: la guida pratica è stata interrotta senza raggiungere il suo obiettivo a causa di circostanze nella conversazione. Ad esempio, questo stato può essere appropriato se la conversazione include un utente che cambia idea su quello per cui vuole ricevere assistenza.
  • FAILED: il playbook è stato interrotto senza raggiungere il suo obiettivo a causa di un errore o di una circostanza non gestibile. Ad esempio, questo stato può essere appropriato se non è stato possibile raggiungere l'obiettivo a causa di problemi di rete durante la chiamata di uno strumento.
  • ESCALATED: la guida pratica è stata interrotta senza raggiungere il suo obiettivo perché l'utente ha richiesto la riassegnazione a un agente umano.

Strategia di recupero

La strategia di recupero stabilisce se ogni esempio è incluso o meno nel prompt del Playbook.

  • DEFAULT: l'esempio può essere omesso se il prompt si avvicina al limite di token.
  • STATIC: l'esempio è sempre incluso.
  • NEVER: l'esempio non viene mai incluso nel prompt. L'esempio non avrà alcun effetto sul rendimento del playbook.

Crea un playbook

Per creare un playbook:

  1. Seleziona le risorse generative nel riquadro di navigazione a sinistra.
  2. Fai clic su Playbook.
  3. Fai clic su Crea nuova.
  4. Fornisci i dati come descritto sopra.

Playbook predefinito

Quando crei un agente generativo, viene creato automaticamente un playbook predefinito.

Il playbook predefinito è il punto di partenza per le conversazioni, quindi presenta alcune importanti distinzioni rispetto agli altri playbook:

  • Il playbook predefinito non riceve un riepilogo dei turni delle conversazioni precedenti.
  • Il playbook predefinito non può definire o ricevere parametri di input.

Versioni del playbook

Puoi salvare le versioni dei playbook, ovvero snapshot immutabili dei playbook.

Per salvare una versione del playbook:

  1. Carica il playbook nella console.
  2. Fai clic su Cronologia delle versioni.
  3. Fai clic su Crea versione.
  4. Fornisci un nome di versione e fai clic su Salva.

Per visualizzare la cronologia delle versioni:

  1. Carica il playbook nella console.
  2. Fai clic su Cronologia delle versioni.
  3. Fai clic su Visualizza la cronologia delle versioni.
  4. Sul lato destro si apre il riquadro della cronologia delle versioni. Puoi fare clic su ciascuna versione per visualizzarne i contenuti.

Strumenti

I passaggi della guida pratica possono fare riferimento agli strumenti che dovrebbero essere utilizzati per portare a termine il passaggio. Per ogni strumento utilizzato dai playbook, fornisci i dettagli dello strumento fornendo uno schema OpenAPI.

Attualmente sono supportate le chiamate API HTTP o le query del datastore.

Puoi specificare un ID sessione come percorso o parametro di ricerca. Ad esempio:

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'

Alle chiamate API HTTP si applicano le seguenti limitazioni:

  • Parametri di ricerca non sono supportati, ad eccezione dell'ID sessione.
  • Il corpo della richiesta e della risposta devono essere vuoti o in formato JSON.
  • Le funzionalità avanzate dello schema come oneOf non sono supportate.

Nell'esempio seguente viene illustrato come fare riferimento a un datastore:

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

Il valore DATA_STORE_TYPE può essere uno dei seguenti:

  • PUBLIC_WEB: un datastore che include contenuti web pubblici.
  • UNSTRUCTURED: un datastore che contiene dati privati non strutturati.
  • STRUCTURED: un datastore che contiene dati strutturati (ad esempio, domande frequenti).

Nell'esempio seguente viene illustrato come fare riferimento a uno strumento 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

best practice

Le best practice seguenti possono aiutarti a creare agenti solidi.

Almeno un esempio per ogni playbook

Dovresti avere almeno un esempio per ogni playbook. Senza un numero sufficiente di esempi, è probabile che un playbook generi comportamenti imprevedibili. Se l'agente non risponde o non si comporta come previsto, è probabile che la causa sia un esempio mancante o non definito. Prova a migliorare gli esempi o ad aggiungerne di nuovi.

Precisione di istruzioni ed esempi

Sebbene sia utile scrivere passaggi didattici chiari e descrittivi, è la qualità e la quantità degli esempi a determinare l'accuratezza del comportamento dell'agente. In altre parole, dedica più tempo a scrivere esempi completi che a scrivere istruzioni perfettamente precise.

Campo OperationId dello schema dello strumento

Quando definisci gli schemi per i tuoi strumenti, il valore operationId è importante. Le istruzioni del playbook faranno riferimento a questo valore. Di seguito sono riportati alcuni suggerimenti di denominazione per questo campo:

  • Solo lettere, numeri e trattini bassi.
  • Deve essere univoco tra tutti i operationId descritti nello schema.
  • Deve essere un nome significativo che rifletta la funzionalità fornita.

Convalida dello schema degli strumenti

Dovresti convalidare lo schema del tuo strumento. Puoi utilizzare l'editor Swagger per controllare la sintassi dello schema openAPI 3.0.

Generare uno schema con Bard

Bard può generare uno schema per te. Ad esempio, prova "Puoi creare uno schema openAPI 3.0 di esempio per Google Calendar".

Playbook specifici

Evita di creare playbook complessi e di grandi dimensioni. Ogni playbook dovrebbe svolgere un'attività specifica e chiara. Se hai una guida pratica complessa, valuta la possibilità di suddividerla in sotto-playbook più piccoli.

Scenari di test

La funzionalità esistente dello scenario di test è stata migliorata per supportare i playbook.

È stato aggiunto un campo obbligatorio Risultato dello scenario di test previsto, che fornisce un elenco di azioni sotto forma di esempi di playbook. Lo scenario di test verifica che le azioni siano state eseguite come previsto.

Quando visualizzi una versione del playbook o del playbook, puoi fare clic sulla scheda Scenario di test sopra i dati del playbook per vedere i risultati dello scenario di test ed eseguire uno scenario di test on demand.

Puoi anche confrontare i risultati dello scenario di test per le diverse versioni di un playbook. Seleziona uno scenario di test e fai clic su Confronta.

Per visualizzare tutti gli scenari di test per l'agente, fai clic su Scenari di test nel menu di navigazione a sinistra.

Cronologia conversazione

La funzionalità esistente di cronologia delle conversazioni è stata migliorata per supportare i playbook.

Sono state aggiunte informazioni per l'esecuzione dello strumento, la chiamata del playbook e la chiamata del flusso da un agente playbook.