Chatbot zähmen leicht gemacht

Betrachten wir zunächst den zweiten Aspekt: Die Definition einer zufriedenstellenden Antwort ist nicht-trivial und höchst subjektiv in vielen realen Anwendungsfällen. Chatbots haben meist eine zuvor festgelegte Zielgruppe und das korrekte Design und die Formulierung einer Antwort kann zentral für den Erfolg des Chatbots sein. Die Schöpfung einer konsistenten Persönlichkeit über verschiedene eintreffende Anfragen hinweg, sollte durch Experten geschehen, die die Zielgruppe kennen und mit dieser bereits interagiert haben (s. Abb. 1).

Aus einer rein technischen Perspektive ist die Bereitstellung der Antworten trivial. Der Fokus liegt bei diesem Teil des Problems auf der Lieferung präziser Informationen: Wie auch beim menschlichen Kundendienst muss ein Bot zuerst trainiert werden. Gerade bei Aufgaben die einer vordefinierten Struktur folgen, wie Hilfestellungen bei nicht-funktionalen Druckern, kann das Vorgehen als (meist gerichteter) Graph abgebildet werden und es kann ein relativ einfacher Top-down-Ansatz genutzt werden. Aus technischer Perspektive ist dieser Teil der Problemstellung in der Regel recht simpel.

Warum gibt es dann nicht noch mehr Chatbots?

Natürlich kann es dafür viele Gründe geben, besonders schwierig ist es jedoch zu erlernen, welche Informationen einer eintreffenden Anfrage für die Erbringung eines Dienstes relevant sind und welche vernachlässigt werden können. Für eine entsprechende Filterung der Informationen ist es daher wichtig, das zuerst genannte Problem zu lösen: die korrekte Klassifizierung der Intention des Nutzers.

Menschen können sich trotz der unendlich vielen Wortkombinationen in der natürlichen Sprache durch gemeinsame Konventionen und über kontextuelle Informationen gut verstehen. Jedoch treten bei Maschinen, die diese Konventionen und Kontexte nicht inhärent kennen, natürlich Probleme auf (s. Abb. 2).

Entschuldige, das habe ich leider nicht verstanden. Kannst du das bitte anders formulieren?

In den letzten Jahren gab es große Fortschritte in einer Disziplin, die Konzepte aus verschiedensten Forschungsgebieten der Informatik, Linguistik, Statistik und anderen Wissenschaften verbindet, um Maschinen den Umgang mit Sprache zu ermöglichen: Natural Language Processing (NLP). NLP ist ein sehr umfassendes Feld, welches unter anderem die maschinelle Übersetzung, die automatische Spracherkennung oder auch Text-to-speech-Lösungen umfasst. Ein zentrales Forschungsfeld für unser Problem, Chatbots beizubringen welche Intention der Nutzer hat und welche Informationen einer Eingabe relevant für eine zufriedenstellende Antwort sind, ist das sogenannte Natural Language Understanding (NLU). Dies wird genutzt, um Fragen zum Inhalt einer Anfrage zu klären: Was beabsichtigt ein Nutzer mit einer bestimmten Eingabe? Wie kann diese Intention korrekt klassifiziert werden und wie können alle relevanten Informationen herausgefiltert werden um eine zufriedenstellende Antwort zu generieren?

In der Geschichte des NLU gab es unterschiedlichste Ansätze. In den Anfängen gab es sehr direkte und unkomplizierte Ansätze wie bei Eliza (1966) [1]. Das "Verständnis" war hierbei noch darauf beschränkt, zu untersuchen, ob bestimmte Schlüsselwörter vorkommen. War dies der Fall wurde die Anfrage, ungeachtet der restlichen Information, einer vordefinierten Kategorie zugeteilt. Dies erfordert das manuelle Training einer großen Zahl von verschiedenen Eingaben, was nicht nur sehr mühsam sondern durch die unendlichen Kombinationsmöglichkeiten von Worten schlicht unmöglich und höchst fehleranfällig ist.

Moderne Ansätze arbeiten daher mit Wahrscheinlichkeiten. Gerade zu Beginn wurden hierbei oft Modelle von Linguisten entworfen, die meist eine relativ starre grammatikalische Struktur erforderten. Und während diese Modelle zwar deutlich robuster waren, konnte die Sprache dennoch nicht so gut verstanden werden wie erhofft und selbst die komplexesten Sprachmodelle blieben sehr fehleranfällig. Zudem haben ineffiziente Mechanismen in der Verarbeitung, wie beispielsweise One-Hot-Kodierungen [2], zu einem hohen Ressourcenaufwand geführt. Das liegt daran, dass es sich bei Wörtern um diskrete Daten handelt: Ähnlich aussehende Wörter müssen keine ähnliche Bedeutung haben ("Wein" und "Wien"), sehr unterschiedliche ausschauende Wörter können jedoch eine sehr ähnliche Bedeutung haben, die Menschen durch Kontexte und Erfahrungen erlernt haben ("Stuhl" und "Hocker").

Um einer Maschine diese Ähnlichkeiten beizubringen sind bei den meisten Techniken jedoch kontinuierliche Daten erforderlich, bei denen die Differenz zwischen zwei Datenpunkten (hier: Wörtern) messbar ist und auch interpretiert werden kann. Das heißt, dass ähnliche Wörter (abhängig von einem zuvor definierten Konzept von Ähnlichkeit) nur eine geringe Distanz haben sollten. Im letzten Jahrzehnt gab es hier signifikante Fortschritte, unter anderem durch sogenannte word embeddings (s. bspw. word2vec [3]). Diese Techniken erlauben uns, die diskreten Datenpunkte auf einen reellwertigen Vektorraum abzubilden. Hierbei ist eine zentrale Eigenschaft, dass die Abstände nun interpretierbar werden, wodurch "Hocker" und "Stuhl" in diesem Vektorraum nahe beisammen sind und zusätzlich traditionelle Vektorraum-Arithmetik ermöglicht wird.

Sowohl das Training solcher Modelle, als auch das generelle Erstellen einer entsprechenden Infrastruktur erfordert viele Ressourcen, die den meisten Unternehmen nicht zur Verfügung stehen. Unternehmen, die Zugriff auf die entsprechenden Ressourcen haben, wie zum Beispiel Amazon oder Google, haben deshalb Dienste (Services) entwickelt, die die Spracherkennung übernehmen. Zwar ist es bei solchen Diensten oft unklar, welche Ansätze (oder eher welche Kombination der Ansätze) genutzt werden, jedoch ist dies für den Entwickler eines Chatbots in der Regel irrelevant, da oft eine entsprechende API angeboten wird, die die Nutzung so einfach wie möglich machen soll. Beispiele hierfür sind Microsoft (LUIS), Google (Dialogflow), Amazon (Lex) oder Facebook (wit.ai) [4], die häufig gegen eine geringe Gebühr pro Anfrage die Intention und relevante Informationen zurückliefern.

Aber selbst wenn man sich nun nicht mehr um das eigentliche Sprachmodell sorgen muss, muss sich der Betreiber immer noch mit dem Training des Chatbots beschäftigen, um die für den eigenen Use Case relevanten Informationen identifizieren zu können.

Training eines Chatbots

Es gibt viele Anbieter, die mit einer schnellen und einfachen Entwicklung eines Chatbots werben. Jedoch gibt es unserer Meinung nach kaum gute Informationen zu den Best Practices bei der wirklichen Entwicklung eines nachhaltigen Chatbots, der im Besonderen für den produktiven Einsatz gedacht ist und wichtige Themen wie Informationen zum Datenschutz zur Genüge betrachtet.

Allein bezüglich der Nachhaltigkeit gibt es einige häufig auftretende Fehler: Der gängigste ist es, direkt zu Anfang den Fokus auf mehrere Themengebiete oder ein sehr breit gefächertes Gebiet zu legen, beispielsweise um verschiedene Services eines Unternehmens zu unterstützen. Gerade zu Beginn sollte nur eine sehr geringe Anzahl von Themen (und Diensten) unterstützt werden, da es oft schwer ist, abzuschätzen, wie lange es dauert, bis die Antworten auf einem Gebiet zufriedenstellend sind. Dies wird häufig unterschätzt, vor allem wenn das Team, das den Chatbot pflegt, noch sehr klein und unerfahren ist. Ein langsames, kontrolliertes und somit stabiles Wachstum wird hier umso wichtiger. Bereits eine kleine Zahl externer Tester kann zu wichtigen und umfangreichen Einblicken in die Erwartungen potentieller Nutzer führen. Dies wird wichtiger je mehr Flexibilität ein Chatbot haben soll, d. h. viele freie Fragen und wenige Fragen, bei denen der Chatbot den Nutzer durch ein Gespräch leitet.

Chatbots funktionieren im Allgemeinen besser in Bereichen in denen man – implizit oder explizit – signalisieren kann, welche Fragen durch den Chatbot beantwortbar sind. Das kann zum Beispiel durch eine Einschränkung der Fragen, die ein Nutzer stellen kann, umgesetzt werden. Explizit kann dies durch technische und visuelle Maßnahmen geschehen, implizit durch die Wahl des Themengebietes. Gute Beispiele sind zum Beispiel Informationen zum Wetter, da die möglichen Variationen hier oft überschaubar sind, und starre Vorgänge wie Bestellungen. Gerade bei solchen starren Vorgängen fühlt sich der Nutzer oft weniger limitiert, da menschliche Interaktionen ähnlich ablaufen und der Nutzer ähnliche Erwartungen bei einem automatisierten Prozess haben wird. Die Erwartungen sind im Allgemeinen ein zentraler Aspekt: Wenn der Chatbot nicht in der Lage ist, die Fragen zu beantworten, die er durch die gesetzten Erwartungen beantworten können sollte, führt dies schnell zur Unzufriedenheit des Nutzers. Dieser wird daraufhin den Chatbot nicht weiter nutzen, auch wenn der Chatbot potentiell viele sinnvolle Funktionen hat.

Um dies zu vermeiden und eine korrekte Klassifikation der eintreffenden Anfragen zu ermöglichen, wird eine klare Definition des angebotenen Dienstes benötigt. Hilfreich bei der Formulierung dieser Definition ist das Konzept von intents das von vielen NLP-Services genutzt wird. Diese können, wie der Name bereits andeutet, als abstrakte Konstrukte verstanden werden, die zur Gliederung von bestimmten Intentionen des Nutzers genutzt werden. Auf diese Anfragen soll der Chatbot dann auf eine sinnvolle Art und Weise antworten können. Bei einer Pizzeria sind dies beispielsweise Anfragen wie die Bestellung einer Pizza oder eine Nachfrage zu den Öffnungszeiten (s. Abb. 4).

Um die relevanten Wörter zu detektieren, die für die korrekte Klassifikation und die Beantwortung der Anfrage benötigt werden, wird meist das Konzept der Entitäten (entities) genutzt. Dies können zum Beispiel Wörter sein, die im gegebenen Kontext synonym genutzt werden (wie Preis und Kosten) oder die zu einer bestimmten Gruppe von Wörtern gehören (wie die verschiedenen Beläge einer Pizza). Die Entitäten sollten für den eigenen Anwendungsfall relevant sein und durchweg konsistent genutzt werden.

NLP-Services erlauben es häufig, nicht nur die Sprache zu verstehen, sondern auf die erkannte Intention direkt mit entsprechenden externen Aktionen oder (statischen) Antworten zu reagieren. Wenn die Antworten im NLP-Service selbst definiert werden, kann ein Chatbot meist über One-click-Integrationen direkt in eine Messaging-Plattform eingebunden werden. Auf den ersten Blick hat dies viele Vorteile: Man braucht keinen zwischengeschalteten Server, da der Messaging-Dienst direkt mit dem NLP-Service kommuniziert. Vor allem ist dies aber einfach, schnell und benötigt kaum technisches Vorwissen. Diese verlockende Einfachheit ist jedoch mit Vorsicht zu genießen.

Dadurch, dass One-click-Integrationen die Verbindung zwischen den Plattformen kontrollieren, ist es schwer oder meist unmöglich, zu kontrollieren, auf welche Informationen die NLP-Services zugreifen. Zudem sind die statischen Antworten, die in einer Datenbank bei dem NLP-Service gespeichert sind, selten ausreichend, um sinnvoll auf die Anfragen zu reagieren. Während viele NLP-Services auch die Integration von dynamischen Inhalten erlauben, ist man oft darauf angewiesen, zusätzliche Dienste des Herstellers zu nutzen auf denen weitere, oft vertrauliche Informationen verwaltet werden. Aus diesen Gründen sollte sich vorab damit auseinandergesetzt werden, wie der Zugriff durch den Anbieter des NLP-Services auf vertrauliche Nutzerdaten, genauso wie auf vertrauliche Daten der eigenen Infrastruktur, minimiert wird. Im Folgenden untersuchen wir die zu Beginn erwähnte Entwicklung eines Chatbots, der sowohl ohne großen Aufwand veröffentlicht werden kann, als auch die Privatsphäre der Nutzer und Entwickler schützt.

Erster Halt: Open Source

Die Nutzung von Open-Source-Software wie Rasa [8] ist eine Möglichkeit, die bestehenden Cloud-Lösungen großer Unternehmen zu umgehen und mehr Kontrolle über die Datenverarbeitung zu haben. Aber gerade wenn die Nutzung einer solchen Plattform nicht möglich ist, wird ein weiterer Aspekt immer relevanter: eine gute Architektur. Gut ist hierbei ein weiteres recht abstraktes Konzept, da jede Anwendung andere Anforderungen haben wird und es daher auch keine Architektur gibt, die für alle Anwendungsfälle optimal ist. Dennoch sollte man sich mindestens mit einem Punkt beschäftigen: Die direkte Kommunikation zwischen dem Messaging-Dienst und dem NLP-Service zu unterbinden. Dies hat allgemein einige positive Nebeneffekte, beispielsweise erleichtert die Trennung der Komponenten die Kontrolle des Informationsflusses und vereinfacht den Austausch einzelner Komponenten. Vor allem ist die Trennung jedoch wichtig, wenn eine Cloud-Lösung genutzt wird, da die Kontrolle über die Nutzerdaten und die Anwendungsdaten somit zum Teil überhaupt erst ermöglicht wird.

Bausteine und Voraussetzungen

Eine intuitive Lösung zur Trennung der Services ist das Zwischenschalten eines Servers. Dieser Server koordiniert den Datenverkehr zwischen allen Diensten, die für die eigene Anwendung relevant sind. Für einen minimalen Chatbot sind diese Dienste der Messaging-Dienst und der NLP-Service, wodurch es zusammen mit dem zwischengeschalteten Server drei Hauptkomponenten gibt. Im Folgenden wird angenommen, dass der Entwickler des Chatbots weder die Kontrolle über den Messaging-Dienst, noch über den NLP-Service hat. In der Praxis ist es möglich, dass die Kontrolle über beide Komponenten vorliegt, beispielsweise wenn der Chatbot in die eigene Website integriert wird und ein Open-Source-NLP-Service genutzt wird. Aber auch in diesem Fall ist eine Architektur mit klarer Komponententrennung sinnvoll. Dies kann nicht nur eine bessere Integration zusätzlicher Dienste erleichtern, sondern auch einen späteren Wechsel zu proprietären Messaging-Diensten oder NLP-Services. In dem vorliegenden Szenario mit drei Komponenten kommuniziert der Server mit den Plattformen über wohldefinierte Schnittstellen:

Eine eintreffende Nachricht von einem Messaging-Dienst wird zunächst an den Server geschickt. Dieser entfernt Metadaten und weitere Informationen, die für die Erkennung der Intention irrelevant sind oder die geschützt werden sollen, wie beispielsweise den eindeutigen User-Identifier des Messaging-Dienstes. Je nach Messaging-Dienst kann dieser Identifier genutzt werden, um sensible Informationen über den Nutzer, wie den Namen oder weitere, teilweise nicht-öffentliche, Daten zu erlangen. Ob und wie diese Daten bei One-click-Integrationen genutzt werden, ist nicht erkennbar, weshalb es sinnvoll ist, diese Daten von Beginn an nicht an den NLP-Service weiterzureichen. Meist wird ein solcher Identifier benötigt, um die Nachricht über den Messaging-Dienst zurück an den Nutzer zu schicken. In diesem Falle kann der Identifier auf dem Server gespeichert und pseudonymisiert an den NLP-Service übertragen werden.

Dadurch, dass die Nachricht über den eigenen Server geleitet wird, ist es zudem möglich, die Nachricht vorab zu bearbeiten, was in vielen Situationen helfen kann. Zum einen erlaubt es uns vertrauliche Informationen durch Platzhalter zu ersetzen, beispielsweise wenn als Antwort zu einer Frage die Eingabe der Telefonnummer erwartet wird. Zusätzlich können natürlich auch Informationen hinzugefügt werden, beispielsweise Daten zu dem Nutzer oder dem Gespräch, die in einer Datenbank oder einem CRM Service enthalten sind. In vielen Situationen erlauben oder erleichtern diese Informationen die weitere Verarbeitung der Nachricht. Alternativ kann die Verarbeitung hierdurch auch direkt zu Beginn abgebrochen werden, wenn es zum Beispiel nicht nötig ist, die Eingabe zu interpretieren, sondern stattdessen einfach eine vordefinierte Nachricht an den Nutzer geschickt werden soll. Auch können komplexere Aufgaben, wie Automated Speech Recognition zur Umwandlung von Spracheingaben in Text, integriert werden, ohne den eigentlichen Ablauf stark zu beeinträchtigen. Es bedarf somit bei einer solchen Architektur nur einer weiteren Abstraktionsebene um einen Sprachassistenten zu entwickeln (wobei diese Ebene natürlich mit einer Vielzahl weiterer Herausforderungen einhergeht).

Nachdem entschieden wurde, welche Nachrichten verarbeitet werden sollen, kann die Nachricht an den NLP-Service gegeben werden, der die Intention, gegebenenfalls die Antwort und/oder die resultierende Aktion determiniert. Eine Aktion ist hierbei ein selbstdefiniertes Event, welches meist nicht durch die NLP-Plattform ausgeführt werden kann: Dies kann das Speichern oder Auslesen in/von Datenbanken, das Senden von anderen Daten als reine Textdaten oder eine Anfrage an eine externe API sein.

Anschließend werden wiederum irrelevante Informationen von der Antwort des NLP-Services entfernt. Auf dem Server ermöglicht eine weitere Schnittstelle das Ausführen der vorab erwähnten Aktionen, die von uns selbst definiert wurden. Wenn nötig wird hier auch der Identifier depseudonymisiert und die finale Antwort wird an den Messaging-Dienst und somit den Nutzer übergeben.

Wie bereits erwähnt ist ein Vorteil dieser Architektur der einfache Wechsel des Messaging- oder NLP-Dienstes. Dies sorgt für eine deutlich geringere Bindung an die Plattform im Vergleich zu einer Anwendung die auf einen Dienst ausgelegt ist. Außerdem können Chatbots so auch auf unterschiedlichen Plattformen gleichzeitig bereitgestellt werden, ohne dass eine umfangreiche und somit teure Konfiguration benötigt wird.

Wir sind davon überzeugt, dass eine solche Architektur eine schnelle und einfache Möglichkeit darstellt, robuste Chatbots zu entwickeln und gleichzeitig die Privatsphäre von Nutzer und Betreiber deutlich besser zu schützen. Aus diesem Grund wurde nun eine gut dokumentierte TypeScript-Implementierung eines solchen Frameworks veröffentlicht. Gemeinsam mit weiterführenden Beispielen ist das Framework auf GitHub zu finden und kann alternativ über npm installiert werden [9].