Online Eiscreme Bestellungen mit Dialogflow und Firebase —
Teil 1: Sprachdialog

1. Aufgabe

Der heiße Sommer 2018 wird auch mir noch länger im Gedächtnis haften bleiben. Hauptprofiteur in meinem Fall war auf jeden Fall eine Eisdiele im Osten von Nürnberg, der ich fast täglich einen Besuch abstattete. Beim Stehen in der Warteschlange – sie war, wie Sie sich denken können, häufig sehr lange – gehen einem immer die verrücktesten Ideen durch den Kopf. Oder gleich ein neues Geschäftsmodell?

Langes Schlangestehen ist für die meisten Menschen – vor allem für mich – eine stressige Angelegenheit. Mit „modernen Hilfsmitteln“ dachte ich mir, muss es doch möglich sein, meine Bestellung (Becher oder Waffel, welche Eissorten) via App direkt an das Eislabor zu übermitteln. Da ich bei starker Sonneneinstrahlung zu den Menschen zähle, die auf dem Display Ihres Smartphones nahezu nichts mehr erkennen, bietet es sich an, den Bestellvorgang einem Sprachassistenten zu übertragen. Natürlich müsste auch die Eisdiele mitspielen, indem sie das vorbestellte Eis an einer separaten Verkaufstheke verkauft. Also ohne lästiges Warten! An Hand dieser Vorüberlegungen sollte klar geworden sein, welches Gesamtszenario in dieser Fallstudie betrachtet wird. Es bietet sich eine Aufteilung in mehrere Teilschritte wie folgt an:

  • Teil 1 – Definition eines Bestelldialogs mit Dialogflow.

  • Teil 2 – Firebase Cloud Functions zur Implementierung des oder der fulfillments.

  • Teil 3 – Android App als Schnittstelle für den Kunden.

Im Teil 1 dieser Fallstudie geht es um die Eingabe einer Eisbestellung mit natürlicher Sprache. Setzen Sie dazu Googles Dialogflow Enterprise Edition ein. Das System für die Verarbeitung natürlicher Sprache (Natural Language Processing, NLP) ist aus der Plattform API.AI hervorgegangen, die Google 2016 übernommen hatte. Im Oktober 2017 wurde dieses Portal in Dialogflow umbenannt. Für den Dialog benötigen Sie einen Sprachagenten, der der Dialogflow-Repräsentant eines möglichen Dialogs ist. Beschäftigen Sie sich mit weiteren Features wie Intents, Training phrases, Responses, Actions, Parameters und Entities. Den letzten Aspekt der fulfillments betrachten wir im Teil 2 dieser Fallstudie, da es hier weniger um den Dialog an sich als vielmehr um dessen programmiersprachliche Verarbeitung geht. Auf diese Weise zeichnet sich der erste Teil dieser Artikelserie dadurch aus, dass wir zur Abwechslung mal ohne Quellcode auskommen.

2. Lösung

Backup of Agent: Siehe auch github.com/peterloos/Dialogflow_OnlineIcecreamParlor.git.

Bevor wir auf die Details des Dialogs eingehen, eine Vorbemerkung: Die prinzipielle Arbeitsweise des Dialogflow Enterprise Edition-Portals (Dialogflow) wird in dieser Studie nicht beschrieben. Es würde sich um nichts mehr als eine reine Wiederholung der offiziellen Dokumentation von Dialogflow handeln, die Sie an Hand von Tutorials oder Samples nachlesen können!

Und damit beginnen wir die Entwicklung unseres Sprachagenten für Eiscremes: Erstellen Sie im Dialogflow-Portal einen Agenten PetersIceCreamParlor. Okay, meinen Vornamen müssen Sie dabei natürlich nicht verwenden oder noch besser dürfen Sie den gesamten Namen des Agenten gleich an Ihre Bedürfnissen anpassen. Es geht gleich mit den Intents weiter. Wie der Name Intent, zu dt. „Absicht“ oder in unserer Situation noch besser „Absichtserklärung“ zum Ausdruck bringt: Es handelt sich um die Formulierung von Sätzen – so genannten Trainingsphrasen – die der Sprachagent verstehen muss / sollte, um die damit verbundene Absicht erkennen zu können. Der Begrüßungs-Intent kann sich aus dem standardmäßig vorhandenen Default Welcome Intent ableiten. Das Best Practice-Pattern empfiehlt an dieser Stelle drei Ziele in der Begrüßung: Eine mögliche Begrüßung wäre vor diesem Hintergrund:

  • einen Willkommensgruß dem Gesprächspartner übermitteln,

  • eine Übermittlung der Erwartungen an die Konversation und

  • die Übernahme der Konversation durch den Benutzer

Eine mögliche Begrüßung wäre folglich

Welcome. I can tell you our shop hours, our list of available ice cream flavors or I can take your order. What can I do for you?

Hinweis: Der Einfachheit halber formulieren wir den Dialog in Englisch! Andere Sprachen sind natürlich ebenfalls möglich (als auch wünschenswert), aber mit mehr Aufwand verbunden. Zum besseren Verständnis stellen wir den gewünschten Verlauf des Dialogs mit Flussdiagrammen dar. In Abbildung 1 betrachten wir den Begrüßungs-Intent:

Flussdiagramm des Begrüßungs-Intents mit passender Äußerung und Antwort.

Abbildung 1. Flussdiagramm des Begrüßungs-Intents mit passender Äußerung und Antwort.


Eine mögliche Antwort auf eine verstandene Begrüßung „When are you open?“ könnte

We're open from 10 AM to 22 PM every day. Is there anything else I can do for you?

sein. Das Flussdiagramm müsste, wie in Abbildung 2 gezeigt, erweitert werden:

Flussdiagramm des Begrüßungs-Intents und weiterem Intent OpeningHours.

Abbildung 2. Flussdiagramm des Begrüßungs-Intents und weiterem Intent OpeningHours.


Eine mögliche Erwiderung des Kunden auf den Begrüßungs-Intent kann von diesem Intent nicht mehr übernommen werden. Wir benötigen von nun an so genannte benutzerdefinierte Intents, die jeder für sich ein Detail des Dialogs übernehmen. Für eine Fragestellung der Art „When are you open?“ erkennen Sie in Abbildung 2 die Modellierung eines zweiten Intents OpeningHours. Bitte beachten Sie die textuelle Formulierung der Antwort (Response): Neben der Übermittlung der reinen Informationen schließt der Satz mit einer Fragestellung ab, um die Kontrolle des Dialogs wieder zurückzureichen!

Falsche oder vom Sprachagenten nicht verstandene Sätze sind im Dialog ebenfalls zu behandeln. Wir sprechen dann von einem so genannten Fallback-Intent, siehe Abbildung 3:

Flussdiagramm mit Fallback-Intent in der linken oberen Ecke.

Abbildung 3. Flussdiagramm mit Fallback-Intent in der linken oberen Ecke.


Um es aber an dieser Stelle ehrlich anzusprechen: In dieser Studio wird in erster Linie versucht, den Augenmerk auf eine Diskussion mit wenig Missverständnissen oder gar unterwarteten Äußerungen des Benutzers zu legen. Für einen Sprachagenten im Produktivbetrieb ist dieser Aspekt natürlich eminent wichtig, aber mit erheblichem Aufwand verbunden. In der Betrachtung einer Einstiegsstudie zum Thema Dialogflow und Spracherkennung habe ich mich deshalb auf das Wesentliche beschränkt.

Flussgramme sind ein wichtiges Hilfsmittel, um einen Dialog zu skizzieren. Im Folgenden betrachten wir die Umsetzung der vorgestellten Flussdiagramme im Dialogflow-Portal. Zunächst legen wir als erstes einen Agenten an. Ein Software-Entwickler würde sagen, dass ein solcher Agent einem Software-Projekt entspricht. Der Agent ist für den Verlauf eines Dialogs zuständig. Er wertet die Eingaben des Benutzers aus und versucht die Absichten (Intents), die der Benutzer mit seinen Spracheingaben zum Ausdruck bringen möchte, zu verstehen und etwaige Folgeaktionen in die Wege zu leiten. In Abbildung 4 finden Sie in der linken oberen Ecke den Namen des Agenten vor. Alle weiteren Themenbereiche wie Intents, Entities und das fulfillment sind unterhalb durch einen entsprechenden Menüeintrag erreichbar. Ferner erkennen wir an dem Label en, dass der Agent auf Englisch eingestellt ist.

Oberfläche des Dialogflow-Portals nach Anlegen eines Sprachagenten.

Abbildung 4. Oberfläche des Dialogflow-Portals nach Anlegen eines Sprachagenten.


In Abbildung 4 finden wir bereits zwei Intents vor: Einen Begrüßungs-Intent und einen Fallback-Intent. Wir klicken auf den Begrüßungs-Intent und betrachten seine Details näher (Abbildung 5):

Trainingsphrasen des Begrüßungs-Intents.

Abbildung 5. Trainingsphrasen des Begrüßungs-Intents.


In Abbildung 5 erkennen wir, dass zum Zwecke einer – eher unkomplizierten oder gar jovialen – Begrüßung eine ganze Reihe von (englischen) Standard-Floskeln eingepflegt sind. Wenn wir auf dieser Seite etwas weiter nach unten scrollen, finden wir auch Standard-Floskeln einer möglichen Antwort vor (Abbildung 6):

Die standardmäßigen Antworten des Begrüßungs-Intents.

Abbildung 6. Die standardmäßigen Antworten des Begrüßungs-Intents.


Gemäß den konzeptionellen Vorgaben unseres Dialogs – gemeint sind die Flussdiagramme – gehen wir nun wie folgt vor: Wir löschen zunächst alle vorhanden Standard-Antworten, sie ergeben für unseren Dialog keinen Sinn. Stattdessen fügen wir die folgenden beiden Antworten hinzu:

  1. Welcome. I can tell you our shop hours, our list of available ice cream flavors or I can take your order. What can I do for you?

  2. Hello there. I can tell you the shop hours, the list of available ice cream flavors or I can take your order. How may I help you today?

Wenn Sie alles richtig gemacht haben, sieht die Maske des Begrüßungs-Intents im unteren Teil der Responses wie in Abbildung 7 gezeigt aus:

Anpassung des Begrüßungs-Intents um neue Antworten.

Abbildung 7. Anpassung des Begrüßungs-Intents um neue Antworten.


Damit kommen wir zu den benutzerdefinierten Intents. In unserer ersten Version des Online Eisdielen Bestellsystems wollen wir drei Aufgaben übernehmen:

  • Der Kunde kann sich über die Öffnungszeiten der Eisdiele informieren.

  • Der Kunde kann sich über die verfügbaren Eiscremesorten informieren.

  • Der Kunde kann eine Bestellung aufgeben.

Wir gehen zunächst auf einen Intent für die Öffnungszeiten ein. Ein Beispiel eines derartigen Dialogs könnte so aussehen:

Kunde: When are you open?

Agent: We're open from 10 AM to 22 PM every day. Is there anything else I can do for you?

Wir legen nun einen neuen, benutzerdefinierte Intent mit dem Namen OpeningHours an:

Im Abschnitt Training phrases geben wir ein:

When are you open?

Im Abschnitt Responses geben wir ein:

We're open from 10 AM to 22 PM every day. Is there anything else I can do for you?

Nach dem Speichern sieht das entsprechende Fenster in etwa so aus:

Oberfläche des OpeningHours Intents.

Abbildung 8. Oberfläche des OpeningHours Intents.


Wenn wir die Fragestellung When are you open? präzise eingeben, sollte die erwartete Antwort zurückkommen. Im echten Leben haben wir es natürlich mit vielen Kunden und entsprechend vielen Fragestellungen zu tun, die zwar alle dasselbe bedeuten, aber eben unterschiedlich formuliert sind. Aus diesem Grund müssen wir unseren OpeningHours-Intent, so wie es beim standardmäßig vorhandenen Default Welcome Intent auch der Fall ist, um weitere Variationen derselben Frage ergänzen:

  • Are you open today?

  • How late are you open on weekends?

  • When do you close?

  • What time do you open tomorrow morning?

  • Are you open now?

  • What are your Business hours please?

  • How early can I drop in?

  • Tell me your opening hours.

  • How late can I come in?

Die Erweiterung des OpeningHours-Intents um weitere Trainingsphrasen erfolgt analog wie die Eingabe der ersten Phrase. Die Ergänzungen im Portal sehen in etwa wie in Abbildung 9 gezeigt aus:

Oberfläche des OpeningHours Intents ergänzt um zusätzliche Trainingsphrasen.

Abbildung 9. Oberfläche des OpeningHours Intents ergänzt um zusätzliche Trainingsphrasen.


Nach dem Sichern aller Phrasen können wir den Agenten testen! In Abbildung 10 ganz oben geben Sie den Text ein – entweder via Spracheingabe mit Mikrophon oder getippt mit der Tastatur. Wenn Sie den Text sprechen, dann bekommen Sie ein Gefühl dafür, bis zu welchem Grad das Google Natural Language Processing System ihre Sprache versteht bzw. wann der Fallback-Intent zum Einsatz gelangt. Ich habe bei der Erstellung des Screenshots in der Tat „Are you open right now?“ in das Mikrophon gesprochen, das Textfeld mit dem Hint Try it now ist aus diesem Grund leer geblieben. Wir erkennen, dass der Text fehlerfrei erkannt wurde, dass der OpeningHours-Intent die Kontrolle übernommen hat und mit einer der beiden vorhandenen Antworten reagiert hat (Abbildung 10):

Test des OpeningHours-Intents.

Abbildung 10. Test des OpeningHours-Intents.


Wichtig: Vergessen Sie nicht, bei jeder Änderung am Agenten (wie Intents etc.), auf „Save“ zu klicken. Es folgen interessanterweise drei Phasen des Abspeicherns:

  1. Phase 1: Intent abgespeichert

    Das ist natürlich das Ergebnis, das wir von dieser Aktion erwarten. Da wir es aber mit einem cloud-basierten Portal zu tun haben, mögen ein oder mehrere Sekunden vergehen, bis der Agent tatsächlich abgespeichert wurde.

  2. Phase 2: Trainingsphase gestartet

    Da wir den Sprachagenten im Portal auch gleich testen können, genügt es nicht, die Daten des Agenten einfach abzuspeichern; es sind die internen Abläufe der Spracherkennung in Abhängigkeit vom gesprochenen Text zu aktualisieren. Dies erfordert ebenfalls ein wenig Zeit, wir werden glücklicherweise darüber informiert, wann der Agent sich aktualisiert ...

  3. Phase 3: Trainingsphase abgeschlossen

    ... und ab wann er für neue Spracheingaben bereit ist!

In den nun folgenden Erörterungen gehen wir auf einige zentrale Merkmale des Dialogflow Spracherkennungssystems ein. Wie erfolgt zum Beispiel der Verlauf bei zwei - semantisch - unterschiedlichen Äußerungen des Benutzers, wie zum Beispiel

  • When are you open?

    oder

  • Which ice cream flacors do you have?

Sie müssen für jede semantisch zusammenhängende Gruppe von Äußerungen des Benutzers einen separaten Intent in Dialogflow hinterlegen. Haben Sie die Trainingsphrasen hinreichend ausführlich und vielfältig pro Gruppe hinterlegt, übergibt Dialogflow die Kontrolle an den entsprechenden Intent und Sie können auf der Basis weiterer Intents den Gesprächsverlauf geeignet modellieren. In Abbildung 11 finden Sie neben dem Intent OpeningHours einen zweiten Intent ListOfFlavors vor; der Entscheidungsknoten im Dialogflow Spracherkennungssystem trifft an Hand der Trainingsphrasen seine Entscheidung:

Ein Entscheidungsknoten mit zwei möglichen Folge-Intents OpeningHours und ListOfFlavours.

Abbildung 11. Ein Entscheidungsknoten mit zwei möglichen Folge-Intents OpeningHours und ListOfFlavours.


In Abbildung 12 erkennen Sie, dass ich es zumindest versucht habe, die Frage nach den verfügbaren Eissorten geringfügig abwechslungsreich zu hinterfragen:

ListOfFlavors Intent mit einigen Traningsphrasen.

Abbildung 12. ListOfFlavors Intent mit einigen Traningsphrasen.


Wir kommen auf ein weiteres Feature von Dialogflow zu sprechen, das so genannte Slot Filling. Wenn es zum Beispiel um die Eingabe einer Eiscreme-Bestellung geht, benötigt die Eisdiele im wesentlichen drei Informationen, um das gewünschte Eis ausliefern zu können: Becher oder Waffel, wie viele Kugeln und welche Geschmackssorten. Also drei Informationen, die aus der Sicht eines Informatikers Variablen unterschiedlichen Typs sind. Die Wahrscheinlichkeit, dass ein Kunde für eine Bestellung einen kompletten Satz mit allen Daten halbwegs sicher und verständlich zum Ausdruck bringt, ist eher unwahrscheinlich. Nicht, dass ich damit die Intelligenz eines durchschnittlichen Eisdielen-Kunden anzweifeln wollte, ganz im Gegenteil. Aber die meisten von uns haben doch in den üblichen nervigen Telefon-Warteschleifen mit angegliederter Spracheingabe eher unangenehme Erfahrungen gesammelt, wie ich zum Beispiel. In einer solchen Situation ist es nicht immer ganz einfach, die Ruhe zu bewahren. Vor allem dann, wenn man vom Gegenüber nicht verstanden wird. Das Stichwort bei Dialogflow lautet an dieser Stelle Slot Filling: In den Trainingsphrasen können Sie Parameter einpflegen, die einem gesuchten Datum (z.B. Anzahl der Kugeln) entspricht. Ein weiteres Feature hierbei ist: Es genügt pro Trainingsphrase einen Parameter zu integrieren, also nicht alle auf einmal. Die fehlenden Parameter werden dann interaktiv von Dialogflow nachgefragt.

In Abbildung 13 finden Sie das Slot Filling am Beispiel des Intents TakeOrder vor. Die weiter oben zitierten drei Informationen für eine Eisbestellung werden pro Parameter von Dialogflow mit den Fragen

  • Okay, I can you help with that: How many scoops do you like?,

  • Which flavors do you like to eat?

    und

  • Do you want a cup or a cone?

der Reihe nach abgefragt.

Intent TakeOrder mit Slot Filling.

Abbildung 13. Intent TakeOrder mit Slot Filling.


Hinweis: Vielleicht haben Sie es bereits bemerkt? Bei der Eingabe der Geschmackssorten habe ich aus Aufwandsgründen Benutzeräußerungen der Gestalt „Zwei Kugeln Vanille“ oder „Dreimal Schokolade“ weggelassen! Vielleicht haben Sie eine Idee, wie Sie diesbezüglich den Sprachassistenten erweitern müssten? Im Übrigen: Wenn Sie partout zwei Kugeln Vanille bestellen wollen, kämen Sie auch mit der vorliegenden Implementierung ans Ziel: Sie müssten „Vanille und Vanille“ äußern – der Dialogflow-Agent wird Ihnen die Umständlichkeit der Eingabe verzeihen.

In Dialogflow sieht die Eingabe der Parameter nun wie in Abbildung 14 gezeigt aus:

Eingabe der Parameter im Intent TakeOrder.

Abbildung 14. Eingabe der Parameter im Intent TakeOrder.


In Abbildung 14 erkennen wir, dass es eine Reihe von Standard-Datentypen gibt, wie etwa @sys.number, @sys.number-integer, @sys.date, @sys.unit-currency, @sys.zip-code usw. Daneben lassen sich auch benutzerdefinierte Datentypen definieren. Diese lassen sich durchaus mit dem enum-Aufzählungsdatentyp von C/C++ vergleichen. In Dialogflow sprechen wir hier von Entities. In Abbildung 15 finden Sie die von mir definierten Entitäten container (Eis im Becher oder in der Waffel) und flavor (Menge aller verfügbaren Eissorten) in der Übersichtsdarstellung aufgelistet vor. Danach folgt in Abbildung 16 ein Blick ins Detail, also in die Definition der Entität flavor, um es an diesem Beispiel klarer zu machen:

Menü Entities im Überblick mit zwei benutzerdefinierten Entitäten container und flavor.

Abbildung 15. Menü Entities im Überblick mit zwei benutzerdefinierten Entitäten container und flavor.


Die flavor-Entität im Detail.

Abbildung 16. Die flavor-Entität im Detail.


Wir kommen nun auf Kontexte (Contexts) zu sprechen. Unter einem Context in Dialogflow verstehen wir einen Zustand, der aktiv oder inaktiv sein kann. Einem Intent können ein oder mehrere Kontexte zugeordnet werden. Dabei unterscheidet man zwischen Input Context und Output Context:

  • Input Context

    Normalerweise wird ein Intent von Dialogflow aktiviert, wenn die Äußerung eines Benutzers den Trainingsphrasen dieses Intents zugeordnet werden kann. Ist einem Intent ein Input Context zugeordnet, werden Äußerungen eines Benutzers mit den Trainingsphrasen dieses Intents nur dann abgeglichen, wenn der Input Context aktiv ist. In anderen Worten: Sollten die Benutzeräußerungen mit den Trainingsphrasen eines Intents zusammenpassen, wird dieser Intent nicht ausgewählt, wenn ein Input Context vorhanden und inaktiv ist.

  • Output Context

    Ausgangskontexte dienen dem Zweck, einen Kontext zu aktivieren und damit die zur Verfügung stehenden Intents für die nächste Benutzeräußerung einzuschränken. Mit aktiven Kontexten lässt sich ein Dialog modellieren, der einem Frage-Antwort-Stil entspricht. Einem Output Context wird eine Lebensdauer (lifespan) zugewiesen (Wert zwischen 1 und 5), die das Aktiv-Sein dieses Intents auf eine bestimmte Anzahl von Turnarounds, also Benutzeräußerungen mit anschließender Intent-Reaktion, festlegt.

Wir betrachten nun die vorliegende Dialogsteuerung bzgl. ihrer Erweiterung um Kontexte. Eine Liste aller Intents, die wir im finalen Entwurf dieser Fallstudie haben, gibt Abbildung 17 wieder:

Die Dialogsteuerung im Überblick: Liste aller Intents.

Abbildung 17. Die Dialogsteuerung im Überblick: Liste aller Intents.


In meinem Eisbestellungs-Dialog verwende ich Kontexte zu unterschiedlichen Zwecken. Betrachten wir zu diesem Zweck Abbildung 18. Ein vergleichsweise triviales Beispiel ist die Eingabe einer „Yes“ oder „No“-Äußerung. Diese kann offensichtlich an unterschiedlichen Stellen im Dialog auftreten. Dialogflow kann dann nicht auf Grund der Mehrdeutigkeit den gewünschten Intent zuordnen bzw. ausführen. Führen wir zum Beispiel den TakeOrder-Intent aus, so wird nach der Eingabe der Bestellungs-Parameter (Slot-Fillung) der Anwender aufgefordert, die Korrektheit der Bestellung mit „Yes“ oder „No“ zu quittieren. Diesselbe Äußerung wird vom Benutzer aber erwartet, wenn dieser seine Bestellung kostenpflichtig an die Eisdiele senden soll, also die Bestellung rechtsgültig wird und dem Bestellvorgang eine Bestellnummer zugewiesen wird (Übergang von Intent ConfirmOrderYes zu PlaceOrder).

Betrachten Sie in Abbildung 18 die Lösung dieses Problems mit Hilfe von Kontexten. Der Wechsel von Intent TakeOrder zu ConfirmOrderYes wird mit einem aktiven Kontext awaiting_confirmation begleitet. Dies heißt: Bei Eingabe von „Yes“ kann Intent PlaceOrder – auch dieser besitzt die Trainingsphrase „Yes“ - nicht aktiviert werden, da dieser keinen Kontext awaiting_confirmation (sei es aktiv oder inaktiv) besitzt! Beachten Sie in der Abbildung die unterschiedliche Darstellung von Eingangs- und Ausgangskontexten. Ein Input Context ist in kursiv geschrieben, ein Ausgangskontext in fett. Dabei muss also immer ein Ausgangskontext (fett) auf einen Eingangskontext (kursiv) desselben Namens abgebildet werden.

Die Dialogsteuerung im Überblick: Ergänzung der Intents um Eingangs- und Ausgangskontexte.

Abbildung 18. Die Dialogsteuerung im Überblick: Ergänzung der Intents um Eingangs- und Ausgangskontexte.


Ich weise auf eine weitere kritische Stelle in Abbildung 18 hin: Im Intent TakeOrder ist nach der Phase des Slot-Fillings eine komplette Bestellung vorhanden. Es soll jetzt zielgerichtet der Benutzer mit „Yes“ oder „No“ antworten, ob mit dieser Bestellung weiterverfahren wird oder nicht. Anders formuliert: Es sollen jetzt bei jeglicher Benutzeräußerung nur zwei Intents zur Auswahl stehen, die sich des Ja- oder Nein-Falls annehmen. Aus diesem Grund ist der awaiting_confirmation-Kontext bei zwei Intents (ConfirmOrderYes und ConfirmOrderNo) als Eingangskontext aktiviert. Alle anderen Intents sind vorübergehend nicht erreichbar!

Und noch ein letzter Hinweis: Wird im Intent TakeOrder die vorliegende Bestellung vom Benutzer abgelehnt, wird mit Hilfe dreier nachfolgender Intents TakeScoops, TakeFlavors und TakeContainer versucht, die Bestellung noch einmal der Reihe nach (sequentiell) abzufragen. Auch hier kommen wieder Kontexte zum Einsatz. Mit Hilfe dreier unterschiedlicher Kontexte awaiting_scoops, awaiting_flavors und awaiting_container, die geeignet als Eingangs- und Ausgangskontext mit der Lebensdauer 1 aktiviert werden, kann das Gespräch gezielt auf drei Eingaben gelenkt werden. Abschließend wird wieder der Kontext awaiting_confirmation aktiviert, den wir bereits beim Intent TakeOrder verwendet haben.

Damit wären wir fürs Erste in der Betrachtung eines Dialogflow-Dialogs zur Aufgabe einer Eiscreme-Bestellung am Ende angekommen. Auf ein weiteres Dialogflow-Feature, die so genannten Follow-Up-Intents, weise ich noch der Vollständigkeit hin. Sie sind speziell für Dialoge mit „seriellem“ Charakter geeignet und wären damit auch für diese Fallstudie einsetzbar. Ich habe ihnen einzig und allein aus Aufwandsgründen in dieser Studie keinen größeren Spielraum eingeräumt.

Noch sind wir nicht ganz am Ziel angekommen: Der letzte Teil des Dialogs, die Übergabe der Bestellung in das Eisdielen-Bestellsystem und die Vergabe einer Bestellnummer, sind offen. Gemäß der Dialogflow-Notation sind wir beim Feature des fulfillments angekommen – und damit auch bei den ersten Zeilen programmiersprachlicher Anweisungen. Aus Gründen einer gewissen Lastverteilung habe ich diesen Part – sowie die Verfolgung ihrer Bestellung in einer Android-App – in zwei nachfolgende Teile dieser Fallstudie ausgelagert.

Und zu guter Letzt: Es gibt sie tatsächlich, meine Lieblingseisdiele. Natürlich – oder leider – noch ohne Online Spracherkennungsfunktionalität, aber sollten Sie sich einmal zufälligerweise im Nürnberger Osten aufhalten, dann statten Sie doch ihr einen Besuch ab.