In diesem Artikel zeigen wir, wie man einen FAQ Chatbot implementiert, der mit Hilfe von Rasa FAQs beantworten und automatisiert Formulare ausfüllen kann. Für das Arbeiten mit Formularen bietet das Rasa Framework mit dem Form eine einfache Möglichkeit, ohne umfangreiches Erstellen von Dialogen benutzerfreundliche Bots anzufertigen.
Mit dem Artikel "Chatbot erstellen mit Rasa" haben wir bereits beschrieben, wie ein einfacher Chatbot mit Rasa erstellt werden kann. Wir haben veranschaulicht, wie Rasa installiert wird und ein erstes Projekt initialisiert. Auch haben wir gezeigt, wie ein einfacher Dialog mit dem Bot geführt werden kann.
Für diesen Use-Case beschreiben wir einen Chatbot, der es ermöglicht, ein Hotelzimmer zu reservieren und grundlegende Fragen zum Hotel beantwortet. Eine beispielhafte Implementierung finden Sie hier.
Wir haben Rasa 3.0 genutzt. Zunächst beginnen wir damit, dass unser Chatbot Fragen aus einem FAQ beantwortet.
Zu Beginn initialisieren wir in einem leeren Ordner mithilfe der Rasa CLI ein Projekt. Falls Rasa bislang nicht installiert ist und das Aufsetzen eines initialen Projektes noch unbekannt, können die einzelnen Schritte mithilfe unseres vorherigen Tutorial durchgeführt werden.
Nach Initialisierung des Projektes löschen wir die *Intents, Stories und nicht benötigten Konfigurationen der Domain. Anschließend erstellen wir Intents für drei Fragen. Dem automatisierten FAQ-Chatbot können Fragen über den Standort des Hotels, das Aussehen und mögliche Aktivitäten dort gestellt werden. Diese erstellen wir zunächst innerhalb der NLU (Natural Language Understanding) Daten unter data/nlu.yml.
Mit dem ResponseSelector verfügt Rasa über eine Funktionalität, die den Umgang mit Smalltalk und FAQs vereinfacht. Diese Funktionalität wird im Folgenden verwendet. Dazu müssen die Fragen innerhalb der NLU-Daten speziell markiert werden, d. h. die Fragen müssen dem folgenden Muster entsprechen:
## intent: faq/ask_<name>
Die Frage nach dem Aussehen des Hotels wird unten als Beispiel gezeigt. Um den ResponseSelector zu verwenden, müssen mindestens zwei Intents erstellt werden.
Nach den Intents legen wir nun die Antworten an, also die Reaktionen des Bots auf den Intent des Benutzers. Dies erfolgt wie im Artikel zuvor beschrieben über Responses innerhalb der Domain.
Damit die Datei domain.yml nicht zu unübersichtlich und überladen mit Konfigurationen wird, legen wir im Ordner data eine neue Datei rules.yml an. Hier werden Rules erstellt, die vergleichbar zu Stories sind, allerdings mit lediglich einem Wechsel im FAQ zwischen Benutzer und Chatbot.
The answer utter_ask_location is defined in the domain.yml
Die Vorteile des ResponseSelector zeigen sich nun in der Erstellung der Story. Es ist nicht nötig mehrere Stories anzulegen, welche jede einzelne Frage behandelt. Innerhalb der Stories unter data/stories.yml werden alle FAQ gleichbehandelt, was sich vor allem bei Chatbots mit sehr vielen verschiedenen FAQ als großer Vorteil herausstellen kann.
Letztlich fügen wir den Intent faq und die Aktion zur Beantwortung der Fragen der Domäne (Datei: domain.yml) hinzu und der FAQ-Chatbot kann mit dem Befehl rasa train trainiert und anschließend über rasa shell getestet werden.
Der Chatbot ist nun im Stande, einfache Fragen zu beantworten. Des Weiteren wird der FAQ-Bot befähigt, Reservierungen anzunehmen. Dafür bietet Rasa die Möglichkeit, Formulare in sogenannten Forms zu füllen. Dieser Artikel beschreibt lediglich ein PoC mit beschränktem Funktionsumfang.
Rasa verfügt mit Entity Extraction über die Möglichkeit, komplexe Datentypen in Formulare einzugeben. So ist es möglich, Angaben des Benutzers wie “Morgen Nachmittag um 14:00 Uhr” korrekt zu deuten. Weitere Informationen finden Sie in der Rasa-Dokumentation.
Um ein Formular in Rasa auszufüllen, müssen wir zunächst die dafür benötigte RulePolicy unter policies in der config.yml mit aufnehmen. Im nächsten Schritt fügen wir das Form der Domain innerhalb der Datei domain.yml hinzu.
Die benötigte Policy und die notwendigen Slots sind hinzugefügt und das Form in die Domain aufgenommen. Wie bereits bei den zu beantwortenden Fragen legen wir nun eine Story an, die den Verlauf des Forms darstellt. Hierzu erstellen wir zunächst den Intent request_room innerhalb der Domain und legen unter data/nlu.yml Beispielintents für das Training an.
Hierzu erstellen wir zunächst den Intent request_room innerhalb der Domain und legen unter data/nlu.yml Beispielintents für das Training an. Hierbei legen wir zwei unterschiedliche Ausprägungen der Intents an. Der erste Intent enthält lediglich die Information, dass ein Zimmer zu reservieren ist.
Eine weitere Möglichkeit ist es, bereits in diesem Intent Informationen mit zu übergeben. So können bereits innerhalb dieses Intents sogenannte *Entities angegeben werden, wie in diesem Beispiel das Anreisedatum. Dabei ist wichtig, dass der Slot und die Entity die identische Bezeichnung, in diesem Beispiel date, aufweisen. Slots und Entities werden im weiteren Verlauf angelegt.
Diese beiden Intents ermöglichen es nun, bereits zu Beginn des Forms eines der Felder auszufüllen. Auch sie nehmen wir unter domain.yml in die Domäne auf. Während des weiteren Ausfüllens wird der Benutzer nicht mehr gefragt, welches Datum er wünscht, da er dieses bereits zu Beginn angegeben hat.
Nun legen wir eine Story an, die den optimalen Fall zum Ausfüllen des Forms wiedergibt.
Um das Form im Dialog ausfüllen zu können, erstellen wir die Python Klasse HotelForm innerhalb von actions.py. Diese Klasse erbt von der Klasse FormValidationAction und implementiert die vier Methoden name, requiered_slots, submit und slot_mappings. Der Zweck der jeweiligen Methoden und die Implementierung wird im Weiteren beschrieben.
Diese Methode gibt lediglich den Namen des Forms zurück, wie er innerhalb der Domain definiert wurde. Das ermöglicht es Rasa, das *Mapping zwischen Python Klasse und des in der Domain definierten Forms vorzunehmen.
Diese statische Methode gibt alle Pflichtfelder/Slots des Forms als Liste zurück. Die Reihenfolge der Liste definiert auch die Reihenfolge, in welcher der Chatbot den Benutzer nach den Pflichtfeldern fragen wird. In diesem Beispiel sind die Anzahl der Personen, das Anreisedatum, die Zahl der Nächte und der Raumtyp die Pflichtfelder des Forms.
Es wäre auch möglich, Felder dynamisch als obligatorisch zu definieren, basierend auf den Eingaben des Benutzers. Ein Anwendungsfall könnte die Angabe sein, ob ein Kinderbett erforderlich ist, wenn Kinder im Zimmer schlafen. Wenn kein Kind im Zimmer schläft, ist diese Frage unnötig und wird daher nicht gestellt. In unserem Beispiel sind jedoch keine dynamischen Pflichtfelder enthalten, so dass der Code wie folgt aussieht:
Um die Slots zu verwenden, definieren wir sie unter slots im domain. Dies geschieht ebenfalls unter domain.yml. Die Definition eines Slots gibt den Namen, den Datentyp und in speziellen Fällen mögliche Werte des Slots an. In diesem Beispiel zeigen wir nur die Slots number_of_persons und room_type.
Für die zwei weiteren Slots wählen wir einen korrekten Datentyp und verfahren wie bei number_of_persons. Der Slot room_type ist ein Beispiel dafür, dass lediglich eine begrenzte Auswahlmöglichkeit an Werten bestehen kann. Der Benutzer hat hier die Wahl zwischen zwei Varianten, die ihm bei Benutzung des Chatbots als zwei Buttons dargestellt werden.
Um mit dieser Methode verbundene Änderungen abzuschließen, müssen wir noch die Fragen vorbereiten, die der FAQ-Chatbot stellen wird, um die Slots zu füllen. Diese müssen ebenfalls innerhalb der Domain erstellt werden (Datei: domain.yml). Sie müssen nach der festgelegten Struktur utter_ask erstellt werden
utter_ask_<slot_name>.
erstellt werden. Ein besonderes Element ist der Slot room_type. Um dem Benutzer nur die beiden Auswahlmöglichkeiten als Buttons zur Verfügung zu stellen, legen wir diese Antwort wie folgt an:
</slot_name>
Die Methode submit wird ausgeführt, wenn das Form vollständig gefüllt wurde. Sie kann beispielsweise dafür genutzt werden, die Reservierung zu speichern. Dieses Beispiel führt lediglich die Aktion utter_submit aus, die die Eingaben des Benutzers ausgibt und sie damit bestätigt.
Um die Antwort utter_submit auszuführen, definieren wir diese innerhalb der Domain. Den aktuellen Wert können wir ausgeben, indem wir den Namen des Slots innerhalb des Response Textes angeben. Wollen wir beispielsweise den Wert von room_types ausgeben, erfolgt dies so:
"Wir haben die Reservierung für eine {room_type} Suite erhalten."
Innerhalb einer Antwort können beliebig viele Slots mit ihrem aktuellen Wert ausgegeben werden.
Die Methode submit wird ausgeführt, wenn das Form vollständig gefüllt wurde. Sie kann beispielsweise dafür genutzt werden, die Reservierung zu speichern. Dieses Beispiel führt lediglich die Aktion utter_submit aus, die die Eingaben des Benutzers ausgibt und sie damit bestätigt.
Jetzt fügen wir unter data/nlu.md Beispielinhalte mit den jeweiligen Entities hinzu. Die Entity room_type benötigt das nicht, da diese über eine Auswahlmöglichkeit von zwei Buttons befüllt wird. Wir empfehlen pro Entity mindestens fünf Beispiele für ein korrektes Training zu erstellen.
Wir haben die Entities und Slots der Domain hinzugefügt und die Intents innerhalb von data/nlu.md für das Training angelegt. Nun folgt als letzte Methode das Mapping von Entity zu Slots, hier eine sehr einfache Variante. Es erfolgt ein Mapping mit der Methode form_entity der Klasse FormAction. Als Parameter ist die Entity und eine Liste der möglichen Intents zu übergeben. Das Mapping erfolgt innerhalb des Dictionarys, das durch die Methode zurückgegeben wird.
Um den Chatbot nun korrekt ausführen zu können, starten wir den Action Server von Rasa. Vom Entwickler erstellte Aktionen werden innerhalb dieses Servers ausgeführt. Innerhalb von Rasa lassen sich noch weit komplexere Aktionen erstellen. So können wir beispielsweise externe Schnittstellen einbinden und innerhalb von Aktionen nutzen. Damit führt ein Fehler innerhalb einer Aktion nicht zum Abbruch des Bots, da dieser unabhängig ausgeführt wird.
Wir starten den Server mit dem Befehl rasa run action. Mit dem Parameter -p
<port>
ist es auch möglich, einen alternativen Port anzugeben, wenn dieser vom Standardport 5055 abweicht.
Startet man nun den Chatbot mit rasa shell, wird es nicht möglich sein, das Form zu füllen. Grund dafür ist, dass wir in der Konfigurationsdatei endpoints.yml die beiden Server, den Action Server und den FAQ-Chatbot selbst, miteinander verknüpfen müssen. Dafür fügen wir die ursprünglich auskommentierten Zeilen wieder hinzu:
Nun können wir den FAQ-Bot nach einem Training über rasa train mittels rasa shell nutzen. Einen Beispieldialog zum Füllen des Dialogs stellen wir im Folgenden dar:
*Intent = Absicht/Intention des Benutzers. Wenn ein Benutzer z.B. "show me yesterday’s technology news" eingibt, ist die Absicht des Benutzers, eine Liste von Schlagzeilen aus dem Technologiebereich abzurufen. Absichten erhalten einen Namen, oft ein Verb und ein Substantiv, wie z.B. "showNews".
*Entities/Entity = Als Entity wird in der Datenmodellierung ein eindeutig zu bestimmendes Objekt bezeichnet, über das Informationen gespeichert oder verarbeitet werden sollen.
*(Daten-)Mapping = Der Prozess, der Datenelemente zwischen unterschiedlichen Datenmodellen abbildet. Datenmapping wird als ein erster Schritt für verschiedene Aufgaben der Informationsintegration benötigt.
In diesem Artikel haben wir einen Chatbot zum Beantworten einfacher Fragen und zum Durchführen einer Reservierung erstellt.
Diese Umsetzung beinhaltet noch keine Fehlerbehandlung. So kann der FAQ-Chatbot noch nicht auf unerwartete Fragen reagieren. Auch kann der Benutzer noch keine Fragen während der Reservierung stellen. Die Möglichkeit, Slots durch externe Schnittstellen oder anhand von Abhängigkeiten zu füllen, bietet dieser Chatbot auch noch nicht.
Für all diese Probleme kann Rasa eine Lösung bieten, um den optimalen FAQ-Chatbot für die jeweilige Situation zu erstellen.
_Thumbnail.png)
