In diesem Dokument werden die Grundlagen der Verwendung von Dialogflow CX beschrieben. Es bietet eine Übersicht über die wichtigsten Konzepte.
Agents
Ein Dialogflow CX-Agent ist ein virtueller Agent, der nebenläufige Unterhaltungen mit Ihren Endnutzern abwickelt. Mithilfe von Natural Language Understanding (NLU) versteht der Agent die Nuancen der menschlichen Sprache. Im Laufe der Unterhaltung übersetzt Dialogflow Nutzereingaben in Text- oder Audioform in strukturierte Daten, die Ihre Anwendungen und Dienste verstehen können. Sie entwerfen und erstellen einen Dialogflow-Agent, der die für Ihr System erforderlichen verschiedenen Typen von Unterhaltungen verarbeitet.
Ein Dialogflow-Agent ähnelt einem menschlichen Callcenter-Agent. Beide werden für die Bearbeitung erwarteter Szenarien trainiert. Dabei sind keine übermäßig genauen Vorgaben nötig.
Abläufe
Komplexe Dialoge enthalten oft mehrere Unterhaltungsthemen. Beispielsweise kann es sein, dass ein Agent für die Pizzaauslieferung Essensbestellung, Kundeninformationen und Bestätigung als unterschiedliche Themen verarbeiten muss. Zu jedem Thema sind dann mehrere Unterhaltungsrunden erforderlich, damit der Agent die relevanten Informationen vom Endnutzer erhält.
Abläufe werden zum Definieren dieser Themen und der zugeordneten Unterhaltungspfade verwendet. Jeder Agent hat einen Ablauf, der als Standardstartablauf bezeichnet wird. Dieser eine Ablauf kann alles sein, was Sie für einen einfachen Agent benötigen. Komplexere Agents können zusätzliche Abläufe erfordern und verschiedene Mitglieder des Entwicklungsteams können für das Erstellen und Verwalten dieser Abläufe verantwortlich sein. Die Abläufe eines Pizza-Lieferdienst-Agents könnten zum Beispiel so aussehen:
Dialogflow CX-Abläufe haben einen ähnlichen Zweck wie Sub-Agents für Mega-Agents von Dialogflow ES. Abläufe bieten eine bessere Unterhaltungssteuerung und verursachen keine zusätzlichen Kosten.
Seiten
Eine Unterhaltung (Sitzung) in Dialogflow CX kann als Zustandsmaschine beschrieben und dargestellt werden. Die Zustände einer CX-Sitzung werden durch Seiten dargestellt.
Für jeden Ablauf definieren Sie mehrere Seiten, wobei die Gesamtheit der Seiten eine vollständige Unterhaltung zu den Themen ermöglicht, für die der Ablauf bestimmt ist. Es ist immer genaue eine Seite die aktuelle Seite. Diese aktuelle Seite wird als aktiv bezeichnet. Weiter wird der mit dieser Seite verknüpfte Ablauf als aktiv angesehen. Jeder Ablauf hat eine besondere Startseite. Wird ein Ablauf zum ersten Mal aktiviert, wird die Startseite zur aktuellen Seite. Pro Unterhaltungsrunde bleibt die aktuelle Seite entweder gleich oder wechselt zu einer anderen Seite.
Sie konfigurieren jede Seite so, dass vom Endnutzer Informationen erfasst werden, die für den von der Seite dargestellten Unterhaltungsstatus relevant sind. Sie können beispielsweise die Seiten (in Blau) im folgenden Diagramm erstellen, um einen Essensbestellungsablauf eines Pizza-Lieferdienst-Agents zu sehen. Der Startknoten des Diagramms stellt die Startseite des Essensbestellungsablaufs dar. Wenn der Ablauf abgeschlossen ist, wird zur Bestätigung gewechselt.
Entitätstypen
Entitätstypen steuern, wie Daten aus Endnutzereingaben extrahiert werden. CX-Entitätstypen sind ES-Entitätstypen sehr ähnlich.Dialogflow stellt vordefinierte Systementitäten bereit, die mit vielen gängigen Datentypen übereinstimmen. So gibt es beispielsweise Systementitäten für den Abgleich von Datumsangaben, Uhrzeiten, Farben und E-Mail-Adressen. Sie können auch eigene benutzerdefinierte Entitäten erstellen, um benutzerdefinierte Daten zuzuordnen. Es ist zum Beispiel möglich, mit der Entität "Gemüse" alle Gemüsearten zu erfassen, die bei einem Lebensmittelhändler erhältlich sind.
Parameter
Parameter werden zum Erfassen und Referenzieren von Werten verwendet, die der Endnutzer während einer Sitzung bereitgestellt hat. Jeder Parameter hat einen Namen und einen Entitätstyp. Im Unterschied zu unstrukturierten Endnutzereingaben sind Parameter strukturierte Daten, mit denen auf einfache Weise ein bestimmter Ablauf ausgeführt werden kann oder Antworten erzeugt werden können.CX-Parameter ähneln ES-Parametern. Allerdings wurden das Dienstprogramm und der Bereich erweitert und die Syntax zum Verweisen auf Parameter hat sich geändert.
Formulare
Für jede Seite können Sie ein Formular definieren. Dies ist eine Liste von Parametern, die vom Endnutzer für die Seite erfasst werden sollen. Der Agent interagiert mit dem Endnutzer mehrere Unterhaltungsrunden lang, bis er alle erforderlichen Formularparameter, auch Seitenparameter genannt, erfasst hat. Der Agent erfasst diese Parameter in der auf der Seite definierten Reihenfolge. Für jeden Formularparameter geben Sie auch Aufforderungen an, mit denen der Agent diese Informationen vom Endnutzer anfordert. Dieser Vorgang wird als Ausfüllen von Formularen bezeichnet.
Sie können beispielsweise ein Formular erstellen, in dem der Name und die Telefonnummer des Endnutzers für eine Collect Customer Info-Seite erfasst werden.
Das Ausfüllen von CX-Formularen ähnelt dem Ausfüllen von ES-Slots.
Intents
Ein Intent kategorisiert die Absicht eines Endnutzers für eine Unterhaltungsrunde. Im Vergleich zu ES-Intents wurden CX-Intents vereinfacht, um sie zu wiederverwendbareren Ressourcen zu machen.
Ein Intent enthält folgende Daten:
| Begriff | Definition |
|---|---|
| Anzeigename | Name, der in der Konsole für den Intent angezeigt wird. |
| Labels | Labels zum Kategorisieren von Intents. Beispiel: head intent. |
| Trainingssätze | Trainingsformulierungen sind Beispielformulierungen für das, was Endnutzer eingeben oder sagen könnten, sogenannte Endnutzereingaben. Wenn die Endnutzereingabe einer dieser Formulierungen ähnelt, ordnet Dialogflow den Intent zu. Sie müssen dabei nicht jede denkbare Formulierung angeben. Das integrierte maschinelle Lernen von Dialogflow erweitert Ihre Liste automatisch um ähnliche Äußerungen. |
| Parameter | Sie definieren Ihre Trainingsformulierungen, um mithilfe von Parametern Werte aus bestimmten Teilen der Endnutzereingabe zu extrahieren. |
| DTMF-Muster | Weitere Informationen zu Telefonieintegrationen finden Sie unter DTMF. |
Webhook
Webhooks sind Dienste, die Ihre Geschäftslogik hosten oder andere Dienste aufrufen. Während einer Sitzung können Sie mit Webhooks die Daten verwenden, die Dialogflow per Natural Language Processing extrahiert hat, um dynamische Antworten zu generieren, erfasste Daten zu validieren oder Aktionen im Backend auszulösen.Ein Webhook kann entweder ein Standard-Webhook oder ein flexibler Webhook sein. Bei einem Standard-Webhook werden die Anfrage- und Antwortfelder von Dialogflow definiert. Bei einem flexiblen Webhook definieren Sie die Anfrage- und Antwortfelder.
Fulfillment
Damit der Agent an der Unterhaltung teilnehmen kann, muss der Agent auf den Endnutzer mit einer Antwort auf eine Frage, einer Anfrage nach Informationen oder dem Beenden der Sitzung antworten. Ihr Agent muss sich möglicherweise auch mit Ihrem Dienst in Verbindung setzen, um dynamische Antworten zu generieren oder Aktionen für eine weitere Unterhaltungsrunde auszuführen. Auftragsausführung wird für all dies verwendet.
Eine Auftragsausführung kann folgende Elemente enthalten:
- Statische Antwortnachrichten
- Webhook-Aufrufe nach dynamischen Antworten und/oder Aktionen
- Parametervoreinstellungen zum Festlegen oder Überschreiben von Parameterwerten
Während der Unterhaltungsrunde eines Agents ist es möglich (und manchmal gewünscht), mehrere Auftragsausführungen aufzurufen, von denen jede eine Antwort erzeugen kann. Dialogflow speichert diese Antworten in einer Antwortwarteschlange. Nach Abschluss der Unterhaltungsrunde des Agents sendet Dialogflow die sortierten Antworten an den Endnutzer.
Die ES-Auftragsausführung ist auf das Verbinden eines Webhook-Dienstes beschränkt. Der Bereich der Auftragsausführung wurde für CX erweitert und deckt nun alle Arten von Eingabeaufforderungen und Antworten ab.
Zustands-Handler
Zustands-Handler, auch einfach Handler genannt, werden zur Steuerung der Unterhaltung verwendet. Handler erstellen Antworten für Endnutzer und/oder wechseln die aktuelle Seite. Für jede Unterhaltungsrunde werden Handler ausgewertet. Dies kann sich auf die Sitzung auswirken. Handler haben drei allgemeine Datentypen:| Begriff | Definition |
|---|---|
| Handler-Anforderungen | Dies sind die Anforderungen, die erfüllt sein müssen, damit sich der Handler auf die Sitzung auswirkt. Ein Handler gilt als aufgerufen, wenn er seine Anforderungen erfüllt und die Sitzung in irgendeiner Weise beeinflusst. |
| Handler-Auftragsausführung | Wenn ein Handler aufgerufen wird, werden mit einer optionalen Auftragsausführung Antworten für Endnutzer erstellt. Diese Antworten sind entweder in statischen Agent-Daten definiert oder werden dynamisch aus Ihrem Webhook-Dienst abgerufen. |
| Handler-Übergangsziel | Nach dem Aufruf eines Handlers wird ein optionales Umstellungsziel verwendet, um die aktuelle Seite zu ändern. Die nächste Seite kann nur eine Ablauf-Startseite oder eine Seite im aktuell aktiven Ablauf sein. |
Es gibt zwei Arten von Zustands-Handlern mit unterschiedlichen Handler-Anforderungen:
| Begriff | Definition |
|---|---|
| Routen | Routen werden aufgerufen, wenn eine Endnutzereingabe mit einem Intent übereinstimmt und/oder eine Bedingung für den Sitzungsstatus erfüllt ist. Eine Route mit einer Intent-Anforderung wird auch als Intent-Route bezeichnet. Eine Route mit lediglich einer Bedingungsanforderung wird auch als Bedingungsroute bezeichnet. |
| Event-Handler | Ereignis-Handler werden aufgerufen, wenn ein Ereignis eintritt. Einige integrierte Ereignisse werden ausgelöst, wenn unerwartete Endnutzereingaben empfangen werden oder wenn ein Webhook-Fehler auftritt. Sie können auch benutzerdefinierte Ereignisse definieren, die aufgerufen werden, wenn etwas außerhalb der Unterhaltung stattfindet. |
Die Verarbeitung eines Zustands-Handlers umfasst drei Schritte:
| Begriff | Definition |
|---|---|
| 1. Bereich | Ein Handler muss sich im Bereich befinden, um Auswirkungen auf die Sitzung zu haben. Der Bereich wird dadurch bestimmt, ob ein Handler auf einen Ablauf, eine Seite oder einen Formularparameter angewendet wird und ob der verknüpfte Ablauf aktiv ist, die zugehörige Seite aktiv ist oder der Agent versucht, den zugehörigen Formularparameter auszufüllen. |
| 2. Bewertung | Jeder Handler im Bereich wird der Reihe nach ausgewertet. Wenn die Anforderungen eines Handlers erfüllt sind, gilt die Bewertung als bestanden. |
| 3. Aufruf | Wenn ein Handler im Bereich liegt und die Bewertung besteht, wird er aufgerufen. Zugehörige Auftragsausführungen werden aufgerufen und zugehörige Umstellungsziele werden auf die Sitzung angewendet. |
Regionalisierung und Standorteinstellungen
Wenn Sie einen Agent erstellen, müssen Sie eine Region als Speicherort des Agents angeben. Anfragen, die an Ihren Agent gesendet werden, werden von Google-Diensten in dieser Region verarbeitet und Dialogflow speichert ruhende Daten physisch in der geografischen Region oder an dem entsprechenden Standort. Für eine optimale Leistung sollten Sie eine Region in der Nähe Ihrer Dienste und Endnutzer auswählen.
Nachdem ein Agent erstellt wurde, kann dessen Speicherort nicht mehr geändert werden. Wenn Sie den Standort eines Agents ändern möchten, müssen Sie einen neuen Agent mit einem anderen Standort erstellen und den Agent dorthin exportieren und wiederherstellen.
Jedem Standort sind Einstellungen zugeordnet, die für Ihr Projekt gelten. In den meisten Fällen müssen Sie diese Standorteinstellungen nicht bearbeiten und die Standardeinstellungen funktionieren gut. Wenn Ihr System vom Kunden verwaltete Verschlüsselungsschlüssel benötigt und diese häufig von Behörden oder regulierten Branchen benötigt werden, finden Sie weitere Informationen zu Standorteinstellungen.
Console
Dialogflow bietet eine Webbenutzeroberfläche namens Dialogflow CX Console (Dokumentation aufrufen, Konsole öffnen). Mit dieser Konsole können Sie CX-Agents erstellen und testen. Die CX Console hat einen ähnlichen Zweck wie die ES Console, die Benutzeroberfläche der CX Console ist jedoch wesentlich visueller. Sie stellt jeden Ablauf als Maschinendiagramm des Unterhaltungsstatus dar, wodurch komplexe Agents leichter zu entwerfen und zu verstehen sind.
Die Dialogflow CX Console unterscheidet sich von der GCP Console (Google Cloud Platform) (Dokumentation ansehen, Konsole öffnen). Die Dialogflow CX Console dient zum Verwalten von Dialogflow-Agents, während mit der GCP Console GCP-spezifische Dialogflow-CX-Einstellungen (z. B. für die Abrechnung) und andere GCP-Ressourcen verwaltet werden.
In den meisten Fällen sollten Sie zum Erstellen von Agents die Dialogflow CX Console verwenden. Agents für komplexere Szenarien können Sie aber auch mit der Dialogflow CX API erstellen.
Einbindungen
Dialogflow CX bietet derzeit mehrere integrierte Integrationen mit anderen Unterhaltungsplattformen. Diese Integrationen stellen dem Endnutzer eine Benutzeroberfläche zur Verfügung und rufen die Dialogflow API für Sie auf. Sie müssen lediglich einen Agent erstellen und optional einen Webhook-Dienst implementieren. Jede Integration behandelt die Interaktionen plattformspezifisch. Weitere Informationen finden Sie in der jeweiligen Integrationsdokumentation.
Interactions
Für jede Unterhaltungsrunde findet eine Interaktion statt. Während einer Interaktion sendet ein Endnutzer eine Eingabe an Dialogflow und Dialogflow eine Antwort. Sie haben zwei Möglichkeiten, Ihr System für die Verarbeitung von Interaktionen zu implementieren: mithilfe der API oder mithilfe einer Integration.
Wenn Sie die API verwenden, muss Ihr System Folgendes verarbeiten:
- Agent erstellen
- Benutzeroberfläche für Endnutzer bereitstellen
- Rufen Sie die Dialogflow API für jeden Sprecherwechsel auf, um Endnutzereingaben an die API zu senden.
- Wenn die Agent-Antworten nicht nur statisch sind (seltener), müssen Sie einen Webhook-Dienst für die Verarbeitung der Webhook-aktivierten Auftragsausführung hosten.
Wenn Sie eine Integration verwenden, muss Ihr System nur Folgendes verarbeiten:
- Agent erstellen
- Implementieren Sie optional einen Webhook-Dienst.
Das folgende Diagramm zeigt die Schritte, die für einen Sprecherwechsel einer Sitzung ausgeführt werden.
- Der Endnutzer gibt etwas ein oder sagt etwas. Dies wird als Endnutzereingabe bezeichnet.
- Ihr Benutzeroberflächen- oder Integrationssystem empfängt die Eingabe und leitet sie in einer Anfrage zur Intent-Erkennung an die Dialogflow API weiter.
- Die Dialogflow API empfängt die Anfrage zur Intent-Erkennung. Sie ordnet die Eingabe einem Intent- oder Formularparameter zu, legt bei Bedarf Parameter fest und aktualisiert den Sitzungsstatus. Falls eine Webhook-fähige Auftragsausführung aufgerufen werden muss, wird eine Webhook-Anfrage an Ihren Webhook-Dienst gesendet. Fahren Sie andernfalls mit Schritt 6 fort.
- Ihr Webhook-Dienst empfängt die Webhook-Anfrage. Der Dienst führt alle erforderlichen Aktionen aus, z. B. das Aufrufen externer APIs, das Abfragen oder Aktualisieren einer Datenbank usw.
- Ihr Webhook-Dienst erstellt eine Antwort und sendet eine Webhook-Antwort an Dialogflow.
- Dialogflow erstellt eine Antwort für die Intent-Erkennung. Wenn ein Webhook aufgerufen wurde, verwendet es die Webhook-Antwort. Wenn kein Webhook aufgerufen wurde, verwendet es die im Agent definierte statische Antwort. Dialogflow sendet eine Antwort für die Intent-Erkennung an Ihre Benutzeroberfläche oder Ihr Integrationssystem.
- Ihr Benutzeroberflächen- oder Integrationssystem empfängt die Antwort für die Intent-Erkennung und leitet die Text- oder Audioantwort an den Endnutzer weiter.
- Der Endnutzer sieht oder hört die Antwort.