Core Behaviors

Diese Dokumentation beschreibt das Konzept der Core-Behaviors; was ist ein Core-Behavior, welche gibt es und wofür werden sie eingesetzt.

Einleitung

Core Behaviors sind dialogische Verhaltensweisen in der Form von vordefinierten Dialog Modulen, die als Basis in jedem Mercury-Bot enthalten sind. Im Gegensatz zu den Dialog Modulen werden hier Dialoge durch sogenannte TriggerIntent vom System Eventgetrieben ausgelöst. Darüber hinaus folgen die Dialoge derselben Logik wie im Kapitel der Dialog Module beschrieben.

Core Behaviors können nicht gelöscht jedoch über das Menü zurückgesetzt werden da sie tief in die Dialog Engine integriert sind. Beim Zurücksetzen wird die ursprüngliche Dialogkonfiguration wider hergestellt. Dabei gehen alle Änderungen (Settings, Knoten & Verknüpfungen) verloren!

Es gibt folgende Core Behaviors:

Active Learning: Ist die NLP Komponente unsicher welche Intention ein Nutzer verfolgt, behandelt dieses Modul eine Dialogische Problemlösung.
Knowledge: Wird mit generativer KI mittels unseres Knowledge-Systems gearbeitet, kann hier Folgeerhalten in Form von Folgenachrichten etc. definiert werden.
Legal Privacy: Hier befindet sich alles rund ums Thema Datenschutz, OptIn und weiterführende Consent-Optionen.
Media: Werden dem Bot keine reinen Textinhalte geschickt, sondern anderweitige Medien wie Dokumente, Bilder, Videos und Audios kann hier entsprechend reagiert werden.
Recovery: Hier befindet sich alles rund ums Thema Verhalten im Fehlerfall. Was passiert wenn der Bot den Nutzer nicht versteht, was passiert im Falle eines abgebrochenen API-Calls und wann wird an einen Live-Agent weitergeleitet.

TriggerIntent

Jedes Core Behavior beinhaltet mindestens einen TriggerIntent der vom Dialogsystem in bestimmten dialogischen Situationen angesteuert wird. TriggerIntents sind tief in die Chatbot-Engine integriert und können nicht manuell hinzugefügt oder gelöscht werden. Im Editor werden TriggerIntents lila markiert:

Jeder TriggerIntent hat einen definierten Folgeknoten, kann individuell konfiguriert und in bestimmten Fällen abgeschaltet werden.

Active Learning

Die Mercury Chatbots sind in der Lage aus Benutzerinteraktionen Vorschläge zu Trainingsdaten zu generieren, indem sie durch ein Feedback-Dialog mit dem Benutzer qualifiziert werden. Das semi-aktive Lernverhalten dieses Core Behaviors definiert, wie der Chatbot mit Situationen umgeht, in denen er die Absicht des Benutzers nicht kennt.

Wir unterscheiden dabei zwei verschiedenen Fälle:

Disambiguation

Wenn das NLU-System zwei oder mehr Absichten mit ähnlich hoher Confidence identifiziert, kann der Bot diese Optionen artikulieren und den Benutzer fragen, welche Option beabsichtigt war. In diesem Falle würde also der Disabiguation-Trigger vom System ausgelöst werden bevor es mit dem eigentlichen Dialog weitergeht. Dieser Trigger bietet die Möglichkeit die maximale Anzahl an ambigen UserIntents einzustellen. Sind mehr UserIntents als die gesetzte Zahl ambig, wird der Trigger nicht ausgelöst. Stattdessen wird ein No Parse-Event erzeugt.

Wird der Trigger ausgelöst erzeugt der darauf folgende BotIntent Resolve Disambiguation eine Auswahl an UserIntents. Diese Auswahl wird via QuickReply-Buttons dargestellt wobei die Canonical des jeweiligen UserIntents als Buttontext verwendet wird.

Low Confidence

Wenn das NLU-System eine Absicht aus einer Nutzernachricht identifiziert, aber nicht sicher genug ist, wird der Trigger Low Confidence vom System ausgelöst. Der Bot spielt darauf hin eine Frage an den Nutzer aus, ob die identifizierte Absicht der tatsächlichen Absicht des Nutzers entspricht.

Diese Auswahl wird als QuickReply-Buttons dargestellt wobei die Canonical des in fragestehenden UserIntents als Buttontext verwendet wird.

Legal Privacy

Die Legal Privacy Core Behavior deckt alles ab, was mit der Einholung des OptIns und anderen Consents zu tun hat. Es beinhaltet ausserdem standard Dialoge zur Löschung von Nutzerdaten und weiterführende Datenschutzfragen.

Per Default sind die weiterführenden Dialoge zu Legal und Privacy im NLP Access Mode none, sodass sie nicht von der NLP verwendet werden können. Sobald die dazugehörigen BotIntents mit Inhalt gepflegt sind, muss hier der Modus auf global gesetzt werden.

Die Hauptaufgabe dieses Core Behaviors ist es das OptIn von Nutzern einzuholen und bei Bedarf ein weiteres Consent zur Datenweiterverarbeitung zum Beispiel für werbliche Zwecke.

Der Mechanismus besteht aus mehreren Punkten die in folgender Reihenfolge vom System abgearbeitet werden, jedes Mal wenn ein Nutzer mit dem Bot interagiert:

Es wird geprüft, ob das OptInt bereits gesetzt ist. Dies spiegelt sich im speziellen booleschen ContextParameter legal.OptIn
1. ist das OptIn gegeben, also der Parameter hat den Wert true wird mit Punkt 3 fortgefahren.
2. ist das OptIn nicht gegeben, also der Parameter ist leer oder hat den Wert false wird mit Punkt 2 fortgefahren.
Ist das OptIn nicht gegeben, wird zunächst geprüft, ob es explizit eingeholt werden muss. Diese Einstellung ist Kanal-spezifisch und wird entsprechend am Kanal gepflegt und nicht am OptIn-Trigger Ist das explizite Einholen des OptIns nicht benötigt, wird mit Punkt 3 fortgefahren. Andernfalls wird vom System der OptIn Trigger ausgelöst, welches den Dialog startet, um vom Nutzer das OptIn explizit einzuholen.
Ist das OptIn gegeben also der Wert des Context Parameters ist true (entweder durch das Setzen des Kanals oder durch die explizite Zustimmung des Nutzers) wird als nächstes geprüft, ob ein erweitertes Consent eingeholt werden muss. Diese Einstellung wird direkt am Consent Trigger selbst gepflegt da sie nicht kanalspezifisch ist.
Wird ein erweitertes Consent benötigt wurde jedoch noch nicht vom Nutzer eingeholt, d.h. der dazugehörige boolesche Context Parameter legal.Consent ist nicht gesetzt (true oder false sind beides gültige Werte da das Consent nicht zwingend vom Nutzer gegeben werden muss, und auch abgelehnt werden darf), wird der Consent Trigger vom System ausgelöst.
Wird das OptIn explizit vom Nutzer abgelehnt kann mit dem Bot nicht interagiert werden, der Nutzer wird gelöscht. Eine erneute Anfrage würde wieder bei Punkt 1 beginnen.

OptIn

Dieser Trigger ist der erste, der vom System ausgelöst wird, wenn eine neue Konversation mit einem Nutzer begonnen wird. Muss ein OptIn explizit vom Nutzer eingesammelt werden, passiert dieses über eine ContextInitiative in der Perform OptIn DialogAction. Die Art und Weise wie nach dem OptIn gefragt wird, ist also in der ContextInitiative des legal.OptIn-Parameters definiert! Wird dem OptIn zugestimmt, branched die DialogAction in den BotIntent OptIn Acknowledged, andern falls in OptIn Not Acknowledged wo man die Möglichkeit dem Nutzer nochmal zu erklären, wofür das OptIn benötigt wird.

Der OptIn Trigger beinhaltet verschiedene Settings die den nachgeschalteten Dialog definieren:

Interpret initial utterance: Ein boolesches Flag, wenn aktiviert, wird die initiale Nachricht des nutzers interpretiert und bei erfolgreicher Einholung des OptIns (und ggf. Consents) als Folge-Intent ausgespielt.
Follow-up target node: Wird die initiale Nachricht des nutzers nicht interpretiert kann hier ein default Folge-Intent ausgewählt werden, welcher nach erfolgreicher Einholung des OptIns (und ggf. Consents) ausgespielt werden soll. Per Default, dieser Intent ist Default Conversation Start.

Wenn der Consent Trigger aktiv ist, wird er unmittelbar nach dem OptIn-Trigger ausgelöst. Ein Consent kann erforderlich sein, um z.B. Werbenachrichten an Nutzer auf WhatsApp zu senden, oder die in einem Chatbot gesammelten Informationen zum Targeting auf Werbeplattformen zu verwenden.

Soll ein Consent explizit vom Nutzer eingesammelt werden, passiert dieses über eine ContextInitiative in der Perform Consent DialogAction. Die Art und Weise wie nach dem Consent gefragt wird, ist also in der ContextInitiative des legal.Consent-Parameters definiert! Wird dem Consent zugestimmt, branched die DialogAction in den BotIntent Consent Acknowledged, andern falls in Consent Not Acknowledged wo man die Möglichkeit dem Nutzer nochmal zu erklären, wofür das Consent benötigt wird.

Die Zustimmung des Consents ist immer optional. Nach einer potenziellen Ablehnung des Consents kann trotzdem mit dem Bot kommuniziert werden.

Ob ein Consent erforderlich ist, kann direkt am Consent Trigger definiert werden:

Recovery

Das Recovery Core Behavior behandelt verschiedene Fehlerfälle und unerwartet dialogische verhalten des Bots. Dies kann zum Beispiel sein, wenn der Bot die Absicht des Benutzers nicht versteht, fehlerhafte Konfigurationen im Dialog verwendet werden oder wenn das Ausführen von Aktionen wie Dialog Operationen oder Workflows zu Fehler führen. Das Recovery Core Behavior enthält verschiedene Trigger, um den Nutzerdialog aus diesen Fehlersituationen zu befreien.

Eine Besonderheit des Moduls ist es, dass über den internen Context Parameter internal.nlp.lastActiveNoneRecoveryModule die Fehlerbehandlung spezifisch für verschiedene UseCases (bzw. Dialog Module) gestaltet werden kann.

No Parse

Der No Parse Trigger wird von der Dialogengine ausgelöst, wenn die NLP Komponente die eingehende Nutzernachricht keinem existierenden UserIntent mit zufriedenstellender Konfidenz zugeschrieben werden kann und das Knowledge-System die Nutzernachricht ebenfalls nicht beantworten kann.

Der No Parse Trigger hat zwei Einstellmöglichkeiten:

Consecutive fails: Die Anzahl an hintereinander folgenden No Parse - Events bevor sich das Verhalten ändern soll.
When reaching the maximum number of consecutive fails the bot shall: Definiert was passieren soll wenn die Anzahl an Consecutive fails überschritten wird.
- start over: beim nächsten No Parse - Event wird Start over Trigger von der Dialogengine ausgelöst. Setzt den Zähler zurück.
- initiate handover: beim nächsten No Parse - Event wird Trigger Handover von der Dialogengine ausgelöst. Setzt den Zähler zurück.

Start Over

Wird die maximale Anzahl an hintereinander folgenden No Parse -Events überschritten kann als eine von zwei Optionen der Start Over Trigger ausgelöst werden. Die Einstellmöglichkeit befindet sich am No Parse Trigger.

Trigger Handover

Wird die maximale Anzahl an hintereinander folgenden No Parse -Events überschritten kann als eine von zwei Optionen der Trigger Handover Trigger ausgelöst werden. Die Einstellmöglichkeit befindet sich am No Parse Trigger. Der Trigger Handover Trigger kann zum moderierten Übergang von Bot zu menschlichem Gesprächspartner verwendet werden.

Die Moderation basiert dabei auf einen vorgefertigten Dialog welcher zunächst überprüft, ob eine Weiterleitung an einen Menschen bestätigt werden soll (Confirm Handover DialogAction), oder nicht. Im zweiten Schritt wird dann in der DialogAction Perform Handover über die Start Handover Operation das Handover ausgelöst sofern ein Live-Agent zur Verfügung steht. Falls nicht branched die DialogAction in den BotIntent Fail Handover.

Ob ein Handover vom Nutzer bestätigt werden soll, kann man direkt im Trigger einstellen.

Der entsprechende boolesche Wert wird als ConfirmHandover - Slot dem Dialog am Trigger-Knoten zur Verfügung gestellt und kann zum branchen verwendet werden:

Error

Der Error Trigger ist ein generischer Fallback für Fehler sämtlicher Art, die im Dialog passieren können. Er wird immer dann von der Dialogengine ausgespielt, wenn ein Fehler in einem UserIntent oder BotIntent passiert oder wenn ein Fehler in einer DialogAction auftritt und kein Fail Target definiert ist.

Typische Fehler sind:

Setzen von Context Parameter mit unpassenden Werten.
Zugriff auf nicht existierende Context Parameter Werte.
Fehler in Workflows
Ungültige Smart Expressions

Dead End

Der Dead End Trigger ist ein generischer Fallback für den Fall, dass ein userIntent ausgespielt wird jedoch kein Target definiert wurde.

Diese Art von Fehlern werden im Editor mit einem roten Ausrufezeichen angezeigt:

Media

Das Media Core Behavior bietet verschiedene Einstiegspunkte für Media-Nachrichten-typen. Da Nachrichten, die nicht auf reinen Text basieren, von der NLP Komponente nicht standardmäßig bearbeitet werden können, bietet dieses Core Behavior für die verschiedenen Media-typen TriggerIntent an welche von der Dialogengine ausgespielt werden, sobald es sich bei der Nachricht um den entsprechenden Media-Typ handelt.

Die eingehenden Dateien werden dabei im bot-internen Speicher hochgeladen und mit einer Asset-Id versehen. Jeder der Trigger exportiert einen Slot welcher die Asset-id beinhaltet. Im weiteren Dialogverlauf kann diese Asset-Id weiter verwendet werden, zum Beispiel in einem Workflow über externe APIs Bilder interpretieren zu lassen und wichtige Informationen so zurück an den Bot gegeben werden können.

Die Maximalgröße für Dateien jeglicher Art beträgt 10 MB!

Document

Wird ausgelöst, wenn ein Nutzer ein Dokument versendet. Die Asset-Id wird im Slot Document dem Dialog bereitgestellt.

Image

Wird ausgelöst, wenn ein Nutzer ein Bild versendet. Die Asset-Id wird im Slot Image dem Dialog bereitgestellt.

Unterstützte Typen:

JPEG
PNG
GIF

Andere Dateitypen werden per Default als Dokument behandelt!

Audio

Wird ausgelöst, wenn ein Nutzer eine Audiodatei versendet. Die Asset-Id wird im Slot Audio dem Dialog bereitgestellt.

Aktuell nur über Whatsapp möglich!

Video

Wird ausgelöst, wenn ein Nutzer ein Video versendet. Die Asset-Id wird im Slot Video dem Dialog bereitgestellt.

Aktuell nur über Whatsapp möglich!

Knowledge

Im Knowledge Core Behavior werden Folgeverhalten definiert die an Antworten gehangen werden die mittels generative KI über das Knowledge System erzeugt wurden.

Nach dem Ausspielen jeder generativen Nachricht wird von der Dialogengine der Knowledge Trigger ausgelöst. Ist dieser aktiviert kann über standard Dialogelementen eine Folgenachricht definiert werden.

Der Default sieht dabei vor zunächst zu prüfen wie viele Sources an der generierten Antwort beteiligt waren. Die beteiligten Source-Ids werden per Slot KnowledgeSourceId am Trigger dem Dialog bereitgestellt. In der DialogAction Branch for Knowledge Disambiguation wird über die Anzahl der beteiligten Sources gebranched.

Gibt es nur eine Source, wird mit dem Knoten Resume With KnowledgeSource weitergearbeitet. Sind mehrere Sources benutzt worden, um eine Antwort zu generieren, kann der Bot über einen Dialog den Nutzer fragen, zu welcher Source er weiterführende Informationen haben möchte. Diese Disambiguierung passiert in dem BotIntent Say Disambiguate Knowledge Sources. Über automatisch generierte QuickReply-Buttons werden die Sources dem Nutzer zur Auswahl angezeigt. Dabei wird die Canonical der Source als Buttontext verwendet.

Die Source steht dann im KnowledgeSourceId - Slot bereit und kann im weiteren Dialog zum Branchen verwendet werden. So können für Antworten aus verschiedenen Sources jeweils angepasste BotIntents bzw. Folgenachrichten definiert werden.
Das Beispiel zeigt zwei Sources Pricing und AboutUs die zur Verfügung stehen:

Als Folgenachricht kann hier zum Beispiel ein Link auf eine Webseite oder E-Shop, eine Verknüpfung in einen redaktionell gepflegten Dialog (UseCase) oder einfach nur eine generische Folgenachricht definiert werden.

Knowledge Trigger

Der Knowledge Trigger wird nach jeder Antwort ausgelöst, welche über das Knowledge-System generiert wurde. Der Trigger bietet damit einen einfachen Einstiegspunkt zurück in den redaktionell gepflegten Dialog.

Der Trigger hat zwei Einstellmöglichkeiten:

Activate knowledge follow-up: Wenn ausgeschaltet der trigger wird von der Dialogengine nicht ausgelöst.
Max number of knowledge sources: Definiert die maximale Anzahl an Sources die zur Disambiguierung herangezogen werden dürfen. Wenn der Wert auf 1 gesetzt ist, wird nicht disambiguiert.

Der Trigger befüllt den KnowledgeSourceId - Slot. Nach der Disambiguierung über die automatisch generierten Buttons, wird der Slot mit der entsprechenden Auswahl neu beschrieben, sodass der Slot immer nur eine Source-Id beinhaltet.