Vor einigen Jahren war die Kommunikation mit Maschinen in Form von natürlicher Sprache noch relativ unbrauchbar. Inzwischen sind Sprachassistenten wie beispielsweise Alexa oder Google Home unser alltäglicher Begleiter und erfüllen das Verstehen von diversen Befehlen mehr als souverän. Auch verbreiten sich diverse Chat- und Dialogbots in den verschiedensten Bereichen. In diesen zwei Beiträgen sollen die Erfahrungen geteilt werden, die beim Erstellen eines Dialogbots für den Raspberry Pi, basierend auf einer Java-Applikation, gemacht wurden. Der erste Beitrag soll dabei eine allgemeine Einführung in die Thematik und die unterschiedlichen Dialogbot-Frameworks liefern.
Als Ausgangspunkt für das ursprüngliche Problem liegt hierbei ein unvollständiger Wissensgraph vor. Diesen soll ein Dialogbot, abhängig von den verschiedenen Intentionen des Users, mit Informationen füllen. Klingt erstmal ein bisschen kompliziert, wird aber durch folgendes Beispiel verständlicher:
Ein naheliegender Anwendungsfall ist eine App, die Diagnosen auf Basis von Patientendaten durchführt. Je nach Diagnose müssen verschiedene Daten vorhanden sein. Fehlt für eine Diagnose exemplarisch das Gewicht, so muss dieses zuerst über einen Dialog in natürlicher Sprache ergänzt werden. Sind dann alle Daten vollständig, so wird die Diagnose ausgeführt und das Ergebnis ausgegeben.
Im zweiten Teil werden dann die einzelnen Komponenten des erstellten Dialogbots näher beschrieben. Dabei sollen folgende, zentrale Fragen beantwortet werden: Was ist ein Wissensgraph und wie speichert man ihn? Wie findet man die Lücken in einem Wissensgraph? Wie verbindet man alle genannten Komponenten zu einem funktionierenden Dialogbot?
Dialogbot-Frameworks
Durch verschiedene Cloud Dienste können eigene Dialogbots entwickelt werden. Für diese Anwendung wurden vor allem Googles Dialogflow und Amazons Lex verglichen. Dabei gibt es keine signifikanten strukturellen Unterschiede zwischen den einzelnen Anbietern und der Teufel steckt wie so oft im Detail. Diese Aussage wird auch durch die Wahl der jeweiligen Favicons unterstrichen (siehe Bild).
Die grundsätzliche Struktur ist bei allen Services letztendlich relativ ähnlich: Ein Bot besteht aus mehreren Intents, welche die verschiedenen Intentionen des Users darstellen. Soll ein Bot beispielsweise verschiedene Bestellungen aufnehmen, so könnte ein Intent exemplarisch für das Bedürfnis „Blumen bestellen“ stehen.
Intents können zusätzlich verschiedene Slots haben, die gefüllt werden müssen. Möchte man Blumen bestellen, könnten die Slots Sorte, Abholdatum und Abholzeit lauten. Für jeden Slot kann man die Frage nach demselben festlegen (Welcher Art sollen die Blumen sein? An welchem Tag werden die Blumen abgeholt? Um wie viel Uhr werden die Blumen abgeholt?).
Wurden alle Slots über die festgelegten Fragen gefüllt, kann man durch so genannte Webhooks Daten aus externen Quellen integrieren, die dann in die Antworten des Dialogbots einfließen können, wie etwa der Web Service eines lokalen Blumenladens, der überprüft, ob die Blumen zu diesem Zeitpunkt verfügbar sind. Für detailliertere Erklärungen kann man gerne hier weiterlesen.
Für den Dialogbot wurde Googles Dialogflow verwendet, da es im Gegensatz zu Amazons Lex vollständig auf Deutsch verfügbar ist und sich darüber hinaus die Sprachanwendungen durch ein paar Klicks mithilfe des Google Assistenten auf ein Smartphone übertragen lassen. Ein weiterer Pluspunkt von Dialogflow ist, dass die Kosten deutlich übersichtlicher dargestellt sind als bei Amazon Lex. Diese Punkte sind natürlich rein subjektiv und nicht unbedingt ausschlaggebend für die Wahl eines Framweorks, außer man spricht kein Englisch oder mag einfach eins der beiden Favicons deutlich lieber…
