Generative Playbooks

Generative Playbooks bieten eine neue Möglichkeit zum Erstellen von Dialogflow CX-Agents mit Large Language Models (LLM). Anstatt Abläufe, Seiten, Intents und Übergänge zu definieren, stellen Sie Anleitungen in natürlicher Sprache und strukturierte Daten in Form von Playbooks bereit. Dies kann die Erstellungs- und Wartungszeit von Agents erheblich verkürzen und für Ihr Unternehmen völlig neue Arten der Kommunikation ermöglichen.

Wenn Sie trotzdem die explizite Kontrolle von Abläufen in bestimmten Unterhaltungsszenarien benötigen, können Sie die Leistungsfähigkeit von Playbooks und Abläufen in einem einzigen Hybrid-Agent kombinieren.

Beschränkungen

Es gelten folgende Einschränkungen:

  • Nur Englisch wird unterstützt.
  • Es werden nur die Regionen us-central1 und global unterstützt.
  • Playbook-Agents unterstützen das Senden einer Begleit-SMS für Anrufe nicht über die Standard-Begrüßungs-Intent-Route im Standard-Startablauf, aber Sie können die Option für die Anruf-Companion-SMS in Standardabläufen aktivieren.

Playbook-Übersicht

Ein Playbook ist der Grundbaustein eines Playbook-Agents. Ein Agent hat in der Regel viele Playbooks, in denen jedes Playbook zur Verarbeitung bestimmter Aufgaben definiert ist. Die Playbook-Daten werden dem LLM bereitgestellt und haben daher die Informationen, die zum Beantworten von Fragen und Ausführen von Aufgaben erforderlich sind. Jedes Playbook kann Informationen bereitstellen, Abfragen an externe Dienste senden oder die Verarbeitung von Unterhaltungen auf einen traditionellen Ablauf oder ein anderes Playbook zur Verarbeitung von Unteraufgaben verschieben.

Playbook-Agents erstellen

Beim Erstellen eines Dialogflow-Agents können Sie wählen, ob der Agent eine Unterhaltung entweder mit einem Playbook (Playbook-Agent) oder einem Ablauf (herkömmlicher Agent) starten soll.

So erstellen Sie einen Playbook-Agent:

  1. Führen Sie die Schritte zum Erstellen eines Agents aus und wählen Sie Eigenen Agent erstellen aus.
  2. Wählen Sie als Agent-Typ Generativ aus.
  3. Klicken Sie auf Speichern.

Im linken Navigationsbereich gibt es drei neue Ressourcenselektoren. Mit diesen Auswahlfeldern können Sie zwischen folgenden Optionen wählen:

  • Flow-Ressourcen
  • Generative Ressourcen
  • Freigegebene Ressourcen

Wenn Sie einen Playbook-Agent erstellen, wird automatisch ein Standard-Playbook erstellt.

Playbook-Daten

In diesem Abschnitt werden die Daten beschrieben, die ein Playbook definieren.

Playbook-Name

Der Playbook-Name ist der Anzeigename für das Playbook. Playbooks können unter diesem Namen aufeinander verweisen.

Playbook-Ziel

Ein Playbook-Ziel ist eine allgemeine Beschreibung dessen, was mit dem Playbook erreicht werden soll.

Beispiel:

Help customers to book flights and hotels.

Playbook-Schritte

In den Playbook-Schritten wird der Prozess definiert, der ausgeführt werden muss, um das Playbook-Ziel zu erreichen.

Jeder Schritt enthält eine Anweisung in natürlicher Sprache, die Folgendes enthalten kann:

  • Eine grundlegende Anweisung, die das LLM verstehen kann.
  • Eine Anweisung, den Nutzer zu einem anderen Playbook weiterzuleiten. Auf Playbooks wird im Format ${PLAYBOOK: playbook_name} verwiesen.
  • Eine Anleitung zur Verwendung eines bestimmten Tools. Auf Tools wird mit dem Format ${TOOL: tool_name} verwiesen.
  • Eine Anweisung zum Weiterleiten des Nutzers zu einem Dialogflow-Ablauf. Auf Abläufe wird mit dem Format ${FLOW: flow_name} verwiesen.

Jede Schrittbeschreibung beginnt mit „-“ und Sie können Teilschritte durch Einrückung definieren.

Beispiel:

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

Playbook-Parameter

Playbooks können Kontextinformationen mithilfe explizit definierter Parameter akzeptieren und ausgeben. Nachdem Sie ein Playbook erstellt haben, werden die Parameter auf dem Tab Parameter pro Playbook definiert.

Playbook-Parameter haben einen Typ, einen Namen und eine Beschreibung. Nachdem Sie Parameter definiert haben, verwenden Sie sie in Playbook-Beispielen, um dem Playbook zu zeigen, wie Parameterwerte zuverlässig gelesen, geschrieben und verwendet werden. Weitere Informationen finden Sie unter Playbook-Beispiele für Eingabe und Ausgabe und Übergabe von Parametern.

Playbook-Eingabeparameter

Eingabeparameter ermöglichen Playbooks die Verwendung von Werten, die aus Abläufen und anderen Playbooks übergeben werden. Beispielsweise kann ein Playbook den bevorzugten Namen eines Nutzers als Parameter erhalten und ihn verwenden, um dem Nutzer persönlich zu danken, oder ein Playbook eine Bestell-ID als Parameter erhalten und diese verwenden, um Bestelldetails mit einem Tool abzurufen.

Playbook-Eingabeparameter werden pro Playbook definiert und Playbooks sind standardmäßig nicht für andere Dialogflow CX-Parametertypen sichtbar. Wenn ein Ablauf zu einem Playbook übergeht, werden Seiten- und Sitzungsparameter an das Playbook weitergegeben, wenn das Ziel-Playbook einen Eingabeparameter mit demselben Namen hat. Wenn Sie während einer Umstellung Informationen aus einem Ablauf an ein Playbook übertragen möchten, definieren Sie Playbook-Eingabeparameter mit demselben Namen wie ein Sitzungs- oder Seitenparameter, der vor der Umstellung vorhanden ist.

Erstellen Sie Beispiele, um zu steuern, wie sich der Wert des Eingabeparameters auf Playbook-Aktionen auswirken soll. Wenn sich beispielsweise ein Eingabeparameter darauf auswirken soll, wie der Agent auf den Nutzer verweist, erstellen Sie Beispiele, in denen ein Wert für den Parameter definiert wird, und verwenden Sie dann denselben Wert in den Äußerungsaktionen innerhalb des Beispiels. Weitere Informationen finden Sie unter Parameter übergeben.

Playbook-Ausgabeparameter

Mit Ausgabeparametern können Playbooks Informationen ausgeben, die von anderen Abläufen oder Playbooks verwendet werden können. Ein Playbook kann beispielsweise eine Bestellnummer von einem Nutzer erfassen und über einen Ausgabeparameter ausgeben, oder ein Playbook könnte ein Tool verwenden, um einen Flug zu buchen und die Bestätigungsnummer über einen Ausgabeparameter auszugeben.

Erstellen Sie Beispiele, um zu steuern, wie im Playbook der Wert für die einzelnen Ausgabeparameter festgelegt wird. Wenn beispielsweise ein Ausgabeparameter, der eine Bestätigungsnummer darstellt, seinen Wert aus der Ausgabe einer Toolnutzung ableiten soll, erstellen Sie Beispiele, bei denen die Ausgabe der Toolnutzung mit dem Wert des Playbook-Ausgabeparameters übereinstimmt.

Parameter übergeben

Im Gegensatz zu Abläufen unterstützen Playbooks das Einfügen von Parameterwerten mit einer bestimmten Syntax nicht. Playbooks basieren stattdessen auf Anweisungen und wenigen Beispielen für Eingabeaufforderung, um zu bestimmen, wie Parameterwerte verwendet und wie Werte bei der Angabe von Parameterwerten entschieden werden sollten.

Ein Kundenservicemitarbeiter, der für den Verkauf von Veranstaltungstickets entwickelt wurde, könnte die folgenden Playbooks umfassen:

  1. Ein Playbook mit dem Namen Ticket ordering, das Bestellungen mit einem Tool namens Ticket sales API aufgibt.
    1. Dieses Playbook akzeptiert einen Eingabeparameter vom Typ number und dem Namen event_id.
    2. Das Ticket sales API-Tool erwartet eine Anfrage mit event_id.
  2. Ein Playbook mit dem Namen Event selection, das Nutzern bei der Auswahl eines Ereignisses hilft und sie dann mit dem Parameter event_id an Ticket ordering weiterleitet, um Tickets zu kaufen.

In diesem Beispiel sind mehrere Beispiele erforderlich, damit event_id zuverlässig von Event selection an Ticket ordering und von Ticket ordering zu Ticket sales API übergeben wird.

Das Playbook Ticket ordering sollte mehrere Beispiele enthalten:

  • Der Eingabeparameter event_id muss mit einem realistischen Wert angegeben sein, der in jedem Beispiel unterschiedlich ist.
  • Fügen Sie eine Toolnutzungsaktion mit einem Anfragetext ein, der denselben realistischen event_id-Wert enthält, der im Eingabeparameter angegeben ist.

Das Playbook Event selection sollte mehrere Beispiele enthalten:

  • Fügen Sie eine Nutzeräußerung ein, bei der der Nutzer ein Ereignis mit einer realistischen event_id auswählt, die sich in jedem Beispiel unterscheidet.
  • Fügen Sie einen Playbook-Aufruf von Ticket ordering ein, durch den der Parameter event_id auf denselben realistischen event_id festgelegt wird, der durch die Auswahl des Nutzers festgelegt wurde.

Zusätzlich zu Beispielen können Sie den Playbook-Schritten, dem Playbook-Zielvorhaben oder den Tooldetails spezifische Anweisungen zur Verwendung von Parametern hinzufügen. Das Playbook Ticket ordering enthält beispielsweise den folgenden Schritt:

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

Unter Berücksichtigung der beschriebenen Beispiele und Anleitungen wird im Event selection-Playbook anhand der Auswahl des Nutzers ein event_id korrekt festgelegt und als Eingabeparameter event_id an die Ticket ordering playbook übergeben. Anschließend übergibt Ticket ordering denselben event_id im Text einer Anfrage an Ticket sales API. Playbooks hängen von Beispielen mit unterschiedlichen Parameterwerten ab, damit sie besser ableiten können, wie Parameter verwendet werden sollen.

Playbook-Beispiele

Jedes Playbook sollte ein oder mehrere Beispiele enthalten. Diese Beispiele sind Beispielunterhaltungen zwischen einem Endnutzer und dem Agent, einschließlich des Dialogs und der Aktionen, die vom Agent ausgeführt werden. Dies sind praktisch wenige Beispiele für Prompts für das LLM.

Die Konsole bietet eine Oberfläche, in der Sie Aktionen eingeben können. Beispiel:

Screenshot des Beispieleintrags

Beispiel für Eingabezusammenfassung und Ausgabezusammenfassung

Zusätzlich zu den Eingabe- und Ausgabeparametern unterstützen Playbooks den Empfang einer Eingabezusammenfassung und die Ausgabe einer Ausgabezusammenfassung für den Austausch von Informationen mit anderen Playbooks. Zusammenfassungen sind hilfreich, um abstrakte Kontextinformationen zwischen Playbooks zu übergeben. Parameter hingegen sind hilfreicher, um strukturierte, klar definierte Felder zwischen Playbooks zu übergeben. Parameter sind die einzige Möglichkeit, Daten zwischen Abläufen und Playbooks auszutauschen.

Fügen Sie den Beispielen relevante Eingabezusammenfassungen hinzu, um das Playbook so zu konditionieren, dass seine Aktionen basierend auf den Eingabezusammenfassungen zur Laufzeit angepasst werden. Fügen Sie Ausgabezusammenfassungen mit relevanten, genauen Details zur Beispielunterhaltung hinzu, um dem Playbook zu zeigen, welche Details zusammengefasst werden müssen.

Beispiele für Eingabe- und Ausgabeparameter

Wenn in einem Playbook Eingabe- oder Ausgabeparameter definiert sind, sollten neben einer Eingabe- oder Ausgabezusammenfassung auch die entsprechenden Eingabe- oder Ausgabeparameter in den Beispielen des Playbooks alle definiert sein. So kann das Sprachmodell besser ableiten, wie die Parameterwerte zuverlässig verwendet werden sollen.

In jedem Beispiel für das Playbook sollten Werte für jeden im Playbook definierten Parameter angegeben und verwendet werden, wie in diesem Playbook mit zwei Eingabeparametern und einem Ausgabeparameter gezeigt:

Screenshot eines Beispiels mit ausgefüllten Eingabe- und Ausgabeparametern

Beispiel für Playbook-Ausgabestatus

Wählen Sie für jedes von Ihnen erstellte Beispiel den Playbook-Status aus, der den Endstatus der Beispielunterhaltung am besten darstellt:

  • OK: Das Ziel des Playbooks wurde erreicht.
  • CANCELLED: Das Playbook wurde aufgrund der Umstände in der Unterhaltung beendet, ohne das Ziel zu erreichen. Dieser Status kann beispielsweise angemessen sein, wenn ein Nutzer in der Unterhaltung seine Meinung ändert und Hilfe benötigt.
  • FAILED: Das Playbook wurde aufgrund eines Fehlers oder eines nicht behebbaren Umstands beendet, ohne das Ziel zu erreichen. Dieser Status kann beispielsweise sinnvoll sein, wenn das Ziel aufgrund von Netzwerkproblemen während eines Toolaufrufs nicht erreicht werden konnte.
  • ESCALATED: Das Playbook wurde beendet, ohne das Ziel zu erreichen, weil der Nutzer eine Eskalation an einen menschlichen Kundenservicemitarbeiter angefordert hat.

Abrufstrategie

Die Abrufstrategie steuert, ob jedes Beispiel in den Prompt des Playbooks aufgenommen wird.

  • DEFAULT: Das Beispiel kann weggelassen werden, wenn sich die Eingabeaufforderung dem Tokenlimit nähert.
  • STATIC: Das Beispiel ist immer enthalten.
  • NEVER: Das Beispiel ist nie in der Aufforderung enthalten. Das Beispiel wird keinerlei Auswirkungen auf die Leistung des Playbooks haben.

Playbook erstellen

So erstellen Sie ein Playbook:

  1. Wählen Sie im linken Navigationsbereich die generativen Ressourcen aus.
  2. Klicken Sie auf Playbooks.
  3. Klicken Sie auf Neu erstellen.
  4. Stellen Sie die Daten wie oben beschrieben bereit.

Standard-Playbook

Wenn Sie einen generativen Agent erstellen, wird automatisch ein Standard-Playbook erstellt.

Das Standard-Playbook ist der Ausgangspunkt für Gespräche und weist einige wichtige Unterschiede zu anderen Playbooks auf:

  • Das Standard-Playbook erhält keine Zusammenfassung der vorangegangenen Unterhaltungsrunden.
  • Das Standard-Playbook kann keine Eingabeparameter definieren oder empfangen.

Playbook-Versionen

Sie können Playbook-Versionen speichern, bei denen es sich um unveränderliche Snapshots von Playbooks handelt.

So speichern Sie eine Playbook-Version:

  1. Laden Sie das Playbook in die Console.
  2. Klicken Sie auf Versionsverlauf.
  3. Klicken Sie auf Create version (Version erstellen).
  4. Geben Sie einen Versionsnamen an und klicken Sie auf Speichern.

So rufen Sie den Versionsverlauf auf:

  1. Laden Sie das Playbook in die Console.
  2. Klicken Sie auf Versionsverlauf.
  3. Klicken Sie auf Versionsverlauf ansehen.
  4. Der Versionsverlauf wird auf der rechten Seite geöffnet. Sie können auf die einzelnen Versionen klicken, um ihren Inhalt zu sehen.

Tools

Die Playbook-Schritte können auf Tools verweisen, die verwendet werden sollten, um den Schritt auszuführen. Für jedes von Playbooks verwendete Tool geben Sie die Details zum Tool durch Bereitstellung eines OpenAPI-Schemas an.

Derzeit werden HTTP API-Aufrufe oder Datenspeicherabfragen unterstützt.

Sie können eine Sitzungs-ID als Pfad oder Abfrageparameter angeben. Beispiel:

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'

Für HTTP API-Aufrufe gelten die folgenden Einschränkungen:

  • Mit Ausnahme der Sitzungs-ID werden Suchparameter nicht unterstützt.
  • Anfrage- und Antworttext müssen leer oder im JSON-Format sein.
  • Erweiterte Schemafeatures wie oneOf werden nicht unterstützt.

Das folgende Beispiel zeigt, wie auf einen Datenspeicher verwiesen wird:

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

Der DATA_STORE_TYPE-Wert kann einer der folgenden sein:

  • PUBLIC_WEB: Ein Datenspeicher, der öffentliche Webinhalte enthält.
  • UNSTRUCTURED: Ein Datenspeicher, der unstrukturierte private Daten enthält.
  • STRUCTURED: Ein Datenspeicher, der strukturierte Daten enthält, z. B. FAQ.

Das folgende Beispiel zeigt, wie auf ein HTTP-API-Tool verwiesen wird:

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 Practices

Die folgenden Best Practices können Ihnen beim Erstellen robuster Agents helfen.

Mindestens ein Beispiel für jedes Playbook

Für jedes Playbook sollte es mindestens ein Beispiel geben. Ohne genügend Beispiele führt ein Playbook wahrscheinlich zu unvorhersehbarem Verhalten. Wenn Ihr Agent nicht wie erwartet reagiert oder sich nicht wie erwartet verhält, sind wahrscheinlich fehlende oder schlecht definierte Beispiele die Ursache. Versuchen Sie, Ihre Beispiele zu verbessern oder neue hinzuzufügen.

Präzise Anleitungen und Beispiele

Auch wenn es hilfreich ist, klare und beschreibende Anleitungsschritte zu formulieren, ist es wirklich die Qualität und Quantität der Beispiele, die die Genauigkeit des Verhaltens des Agents bestimmen. Anders ausgedrückt: Verbringen Sie mehr Zeit damit, ausführliche Beispiele zu verfassen, als für exakte Anweisungen.

Feld für die Vorgangs-ID des Tool-Schemas

Beim Definieren von Schemas für Ihre Tools ist der Wert operationId wichtig. In der Playbook-Anleitung wird auf diesen Wert verwiesen. Im Folgenden finden Sie Empfehlungen zur Benennung dieses Felds:

  • Nur Buchstaben, Ziffern und Unterstriche.
  • Darf unter allen im Schema beschriebenen operationIds nur einmal vorkommen.
  • Muss ein aussagekräftiger Name sein, der die bereitgestellte Funktionalität widerspiegelt.

Schemavalidierung mit Tool

Sie sollten das Schema Ihres Tools validieren. Sie können die Syntax Ihres OpenAPI 3.0-Schemas mit dem Swagger Editor prüfen.

Schema mit Bard generieren

Bard kann ein Schema für Sie generieren. Versuchen Sie beispielsweise, ein Beispiel für ein openAPI 3.0-Schema für Google Kalender zu erstellen.

Playbooks mit Schwerpunkt

Vermeiden Sie sehr große und komplexe Playbooks. Jedes Playbook sollte eine spezifische und klare Aufgabe erfüllen. Wenn Sie ein komplexes Playbook haben, sollten Sie es in kleinere untergeordnete Playbooks aufteilen.

Testläufe

Die vorhandene Testlauffunktion wurde optimiert, um Playbooks zu unterstützen.

Das erforderliche Feld Erwartetes Testlaufergebnis wurde hinzugefügt. Es enthält eine Liste von Aktionen in Form von Playbook-Beispielen. Mit dem Testfall wird bestätigt, dass die Aktionen wie erwartet ausgeführt wurden.

Wenn Sie ein Playbook oder eine Playbook-Version aufrufen, können Sie über den Playbook-Daten auf den Tab Testläufe klicken, um die Ergebnisse der Testläufe anzusehen und einen Testlauf bei Bedarf auszuführen.

Sie können auch die Ergebnisse von Testläufen für verschiedene Versionen eines Playbooks vergleichen. Wählen Sie einen Testlauf aus und klicken Sie auf Vergleichen.

Wenn Sie alle Testläufe für den Agent sehen möchten, klicken Sie im linken Navigationsbereich auf Test Cases.

Unterhaltungsverlauf

Die vorhandene Funktion Unterhaltungsverlauf wurde optimiert, um Playbooks zu unterstützen.

Es wurden Informationen zur Tool-Ausführung, zum Playbook-Aufruf und zum Ablaufaufruf von einem Playbook-Agent hinzugefügt.