Chatbots sind seit einigen Jahren eine moderne Lösung für automatisierte Prozesse und werden viel im Bereich des Supports eingesetzt. Durch ihre ständige Verfügbarkeit und die einfache Nutzung gewinnen sie immer mehr an Beliebtheit. Wir möchten herausfinden, wie man einen Chatbot aufsetzen und ihn in einen internen Prozess integrieren kann.
Im Zuge eines Studierendenprojektes befassten wir uns mit dem Aufbau eines Chatbots in der Cloud und seiner Integration in unser zentrales Kommunikationstool Slack. In diesem Blogpost berichten wir von unseren Erfahrungen, eine Chatbot-Infrastruktur aufzusetzen, und wie wir einen ersten Use Case bei inovex intern implementiert haben.
Zielsetzung
Im Vordergrund steht die Entwicklung eines intelligenten Assistenten, der Kolleg:innen im Alltag für häufige Fragen zur Seite steht. Wir nennen ihn inovex Digital Assistant, kurz iDA. Mit iDA setzen wir uns das Ziel, einen modernen Ansatz für einen bestehenden Prozess zu entwickeln, der sich leicht in den Alltag integrieren lässt. iDA kann dabei als Anlaufstelle für einen internen Prozess dienen und ihn vereinfachen, indem er durch einen Chatverlauf abgearbeitet und beschleunigt wird. Dafür binden wir einen Chat-Client sowie die bisherige Datenquelle an. Am Ende der Konversation soll eine E-Mail mit den gesammelten Informationen geschickt werden. Darüber hinaus führen wir weitere Funktionen ein, die den Nutzer:innen helfen, Eingaben freundlich und umgangssprachlich zu gestalten. Mehr dazu später in der Übersicht der Features!
Use Case
Chatbots können für unterschiedliche Einsatzbereiche interessant sein – ob in der Vorbereitung, Mitarbeit oder dem Abarbeiten von Prozessen. Wir möchten uns im ersten Ansatz einem internen Prozess widmen, den der Chatbot vollständig erledigt: Derzeit wickeln wir die Reiseplanung intern über Google Forms ab, d. h. wir sammeln bestimmte Informationen zu der Reise und bearbeiten sie im Nachgang anhand der im Formular gemachten Angaben. Die Abfrage über Google Forms ist jedoch statisch und nicht sehr attraktiv. Daher möchten wir einen digitalen Assistenten bauen, der sowohl einfach im Alltag integrierbar ist und ebensolche statische Prozesse vereinfacht. Bei inovex bilden wir unsere zentrale Kommunikation über den Chat-Client Slack ab. Demzufolge entwickelten wir einen Chatbot, den wir in Slack aufrufen können und der den Reiseplanungsprozess abdeckt. Dabei legen wir Wert auf die Modularität, sodass die Komponenten klar getrennt sind und den Betrieb dadurch vereinfachen.
Chatbot Features
Der Chatbot sollte den bestehenden Formularprozess sowohl vollständig abbilden als auch optimieren. Im Folgenden stellen wir einige Features vor, die das Gespräch ein wenig interessanter gestalten könnten.
Flexibilität
Wir führten User-Profile ein, die mit Benutzereingaben gefüllt und in die nächste Buchung mit einbezogen werden. Das bedeutet, dass häufig auftretende Fragen übersprungen werden und sich der Prozess dadurch beschleunigt. Beispiele hierfür sind hinterlegte Dokumente, Reisepräferenzen und mehr. Zudem war es uns wichtig, nicht nur die vorgemerkten, statischen Eingaben, sondern auch freie Nachrichten zu erlauben. Neben Synonymen konnten wir die Datumsangaben natürlichsprachlich wie „morgen“ oder „1 Woche später“ formulieren. Dies ist ein Punkt, der sich wesentlich vom Formular unterscheidet. Chatbots sind dynamischer und verifizieren die Antworten der Nutzer:innen direkt.
Während der Buchung werden Nutzereingaben direkt gemappt (siehe Screenshot weiter unten). Beispielsweise wird der Reisegrund „Sprintwechsel“ als „Projekt“ erkannt und die Datumsangaben werden entsprechend des Formats angepasst.
Unterstützung und Dokumentation
Damit wir den weiteren internen Prozess vereinfachen, merkt sich der Chatbot die Buchungsdaten und erinnert Nutzer:innen kurz vor der Reise an wichtige Dokumente per E-Mail. Dadurch garantieren wir, dass nichts vergessen wird und manuelle Eingriffe nicht mehr notwendig sind. Und wenn der Chatbot mal nicht weiter weiß, verlinkt er relevante Quellen, die wir intern für die Dokumentation verwenden.
Feedback
Am Ende jeder Konversation geben wir Nutzer:innen die Möglichkeit, Feedback zu geben. Die Antworten pflegen wir in unserer Datenbank ein und verwenden sie als Basis für die Weiterentwicklung des Chatbots.
Vereinfachung
Neben Texteingaben bietet unser Chatbot zudem grafische Elemente, u. a. Buttons oder die Eingabe des Feedbacks über Sterne. Die Konversation sollte nicht statisch klingen, indem sie einfach die Fragen des Formulars überführt. Wir wollten sie so einfach wie möglich halten und bieten zum Ende der Buchung an, in einem Fenster weitere/seltene Felder zu füllen oder die bestehenden zu verändern.
Architektur
Die Applikation besteht im Wesentlichen aus vier Komponenten. Für den Nachrichtenverkehr ist der Webserver verantwortlich. Er ist mit dem Web Framework Django implementiert und beinhaltet gunicorn zum Umgang mit erhöhtem eingehenden Nachrichtenverkehr. Um die parallel ankommenden Anfragen zu verarbeiten, wird das Task Queue Modell von Celery verwendet.
Erreicht den Webserver eine Nachricht von Slack, wird eine Anfrage zur Verarbeitung dieser an das Sprachmodell geschickt. Dieses besteht aus der Rasa NLU/Core und dem Rasa Action Server. Die Rasa NLU/Core wendet das trainierte Sprachmodell auf die eingehende Nachricht an und führt auf Basis eines konfigurierten Regelsatzes die nächste Aktion aus. Eine Aktion ist entweder eine Textantwort zurück an Slack oder die Ausführung von benutzerdefiniertem Code mit Hilfe des Rasa Action Servers. In unserem Use Case verschickt der Action Server E-Mails und versendet Anfragen an die Datenbank-API.
Als Gedächtnis des Sprachmodells dient der Redis Tracker-Store. Darin werden die aktuellen Konversationsverläufe der Nutzer gespeichert, um diese in die Vorhersage einfließen zu lassen. Redis wird gleichzeitig von Celery als Task Queue verwendet.
Für die langfristige Weiterentwicklung des Bots werden Nutzerfeedback und abgeschlossene Konversationen in einer persistenten Datenbank (mongoDB) gespeichert. Alle Komponenten laufen als Docker Container auf unserem internen Computing/Hosting Cluster (inovex Cloud Service, kurz iCS).
Lessons Learned
Rasa Framework
Das Open Source Framework Rasa umfasst klar verständliche Konstrukte und kann einfache Konversationsstränge gut einbinden. Es stellte sich heraus, dass das Tool viele Möglichkeiten für unseren Use Case bietet und sich gut mit anderen Services integrieren lässt. Auf der einen Seite erlaubten es uns die sogenannten custom actions, eigenen Code zu integrieren, wodurch wir sehr flexibel in der Anbindung Use-Case-spezifischer Logik waren. Auf der anderen Seite agiert Rasas Natural Language Understanding (NLU) oft als Black Box. Unter einer NLU versteht man die Komponente, die relevante Informationen des Texts zu verstehen versucht. Diese basiert auf konfigurierbaren neuronalen Modellen, kann darüber hinaus aber auch regelbasierte Methoden verwenden. Neuronale Ansätze werden vor allem für flexible Gespräche präferiert und verbessern sich, indem wir Trainingsdaten für das Modell bereitstellen. Zusätzlich kann man das Modell anhand einiger Parameter steuern, doch die Klassifizierung der Benutzereingaben war nicht immer komplett transparent.
Entwicklung und Evaluierung der Benutzereingaben
Die Intransparenz des Rasa-Modells erforderte tiefere Einblicke in die Klassifizierung. Rasa X (nun kostenpflichtig) bietet eine Oberfläche für das Testen und Debugging von Gesprächsverläufen sowie das Re-Training von Modellen. Das Tool zeigt Wahrscheinlichkeiten zu Vorhersagen auf und bietet die Möglichkeit an, durch die Analyse das Modelltraining direkt zu beeinflussen.
Wenn man nicht in Rasa X investieren möchte, ist es außerdem möglich, über den ‘interactive’-Mode in der Konsole zu debuggen, um Einblicke in die NLU zu erlangen. Der ‘interactive’-Mode erleichtert ebenfalls durch interaktive Dialoge die Generierung neuer Trainingsdaten. In den Anfangsphasen eines Chatbot-Projekts lässt es sich nicht vermeiden, dass die Auswahl der Trainingsdaten durch die Entwickler:innen selbst passiert. Jedoch sollten Endnutzer:innen frühestmöglich in den Entwicklungszyklus eingebunden werden. Auf diesem Wege lassen sich Trainingsdaten sammeln, die realen Konversationen ähneln.
Deployment und Versionierung
Bisher führten wir das Framework Rasa für die Abbildung unserer Konversationen sowie die Datenbank zum Persistieren vor. Nun möchten wir die Komponenten in Produktion bringen. Dafür setzen wir auf einen automatisierten Entwicklungsprozess anhand von Gitlab CI/CD, einer Pipeline, mit der wir die Komponenten kontinuierlich testen und ausrollen. Diese Pipeline rollt die Container versioniert in der Cloud (iCS) aus.
Zusammenfassung
In diesem Blogpost geben wir einen Überblick über die Implementierung und Integration eines Chatbots bei inovex. Diesen entwickelten wir anhand eines internen Use Cases der Reiseplanung, der einfach erweitert werden kann.
In den technischen Deep Dives erfuhren wir, dass sich ein digitaler Assistent recht modular aufbauen lässt. Dabei bot sich Rasa als Framework aufgrund der einfachen Bedienung gut an. Wir konnten neben den Fragen aus einer Wissensquelle, in unserem Fall GForms, verschachtelte Gesprächsverläufe modellieren und die Eingaben der Benutzer erweitern, sodass die Konversation freier und natürlicher wirkt. Darüber hinaus wollten wir bekannte Tools nicht vermissen, die wir intern bereits viel im Einsatz haben. Der Assistent konnte problemlos in den Alltag integriert werden und dies war nur der erste Schritt in der Entwicklung von iDA.
