Im ersten Teil dieses Beitrags wurden die verschiedenen Dialogbot-Frameworks vorgestellt, auf Basis welcher der Dialogbot erstellt wurde. Im zweiten Teil sollen nun die weiteren Komponenten und ihre Funktionsweise beschrieben werden. Zusätzlich wird noch eine Datenbank benötigt, in der das Wissen gespeichert werden kann, sowie eine Validierungskomponente, welche die Lücken im Graph findet und ein Java-Programm, welches die verschiedenen Einzelteile zu einem ganzheitlichen System zusammenfasst.
Graphendatenbank
Der Titel des Beitrags ist „Zielorientierter Dialogbot“. Einen Dialogbot kann man mit den bereits beschriebenen Services problemlos erstellen, doch was hat es mit der Zielorientierung auf sich?
Dem Dialogbot liegen semantische Daten in einer Graphendatenbank (in diesem Fall OpenLink Virtuoso) zugrunde. Folglich setzen sich die Daten aus verschiedenen Tripel zusammen, die jeweils aus Subjekt, Prädikat und Objekt bestehen (siehe Tabelle).
Semantische Daten erfreuen sich beispielsweise im medizinischen Bereich großer Beliebtheit, weil sie einen Datenstandart für die aus vielen heterogenen Quellen stammenden Daten bieten. Außerdem sind sie für den Menschen leicht verständlich, da sie wie ein Satz in natürlicher Sprache aufgebaut sind.
Jedoch sind die Daten in diesem Anwendungsfall nicht vollständig. Ziel des im Rahmen einer Bachelorarbeit erstellten Dialogbots war es, die Lücken in einem Wissensgraphen je nach Intention des Nutzers dynamisch über einen Dialog zu füllen.
Validierung
Um die Daten zu klassifizieren und zu validieren, eignet sich SHACL hervorragend. Durch verschiedene constraints kann man hier charakterisieren, von welcher Art und wie groß die Anzahl der Verbindungen einer Klasse sein müssen. Aus der Verletzung eines constraints kann mithilfe der einhergehenden Fehlermeldung die Lücke in einem Graph erkannt werden. Durch die Charakteristik der Fehlermeldung bewertet das Programm anschließend, welche fehlende Information als nächstes abgefragt werden muss. Die Funktionsweise und Fehlermeldungen von SHACL können hier ausprobiert werden. Dabei wird ein Datengraph mit einem _constraints graph _verglichen und das Ergebnis anschließend in einem validation report ausgegeben, aus dem man herauslesen kann, welche Daten als nächstes abgefragt werden müssen.
Hier ist ein Beispiel für ein Validierungsergebnis zu sehen, aus welchem die Art des Fehlers und der betroffene Knoten hervorgeht. Einem Knoten fehlt eine Verbindung vom Typ "schema:duration", dem anderen eine Verbindung vom Typ "schema:startDate".
Applikation
Zusammenfassend gibt es drei entscheidende Komponenten. Das Dialogbotframework, in welchem die Intents gespeichert werden, die Graphendatenbank, in welcher die (unvollständigen) Daten gespeichert werden und schließlich SHACL, das die Daten validiert. Warum kann man diese drei Komponenten nicht einfach in einen Webhook integrieren? Weshalb wird ein externes Programm benötigt?
Das Problem ist, dass aus einem Webhook heraus keine neuen Intents gestartet werden können, die dann die entsprechende Frage enthalten. Hierdurch wird unser Problem komplizierter, da es einer externen Anwendung bedarf, die das grundsätzliche Verlangen des Benutzers in standartmäßiger Dialogbot-Manier erkennt, aber dann zuerst die nötigen Fragen stellt, bevor das Ergebnis zurückgegeben wird. Die Umsetzung erfolgte in Java. Eine ausreichende Auswahl an geeigneten Bibliotheken zur Einbindung der Einzelkomponenten war somit gegeben.
Da es bei keinem der Dialogbotservices die Möglichkeit gibt, einen dynamischen Ablauf des Dialogbots zu modellieren, wurde ein externes Programm erstellt, welches das Gespräch abhängig von den jeweiligen Lücken lenkt. Statt also wie in den meisten sprachgesteuerten Anwendungen auf User Input zu reagieren, soll der Dialogbot aktiv das Gespräch lenken.
Probleme gab es dabei teilweise mit der Implementierung auf dem Raspberry Pi, da aufgrund der vielen Bibliotheken immer wieder Kompatibilitätsprobleme auftraten. Um die Java Anwendung auf dem Raspberry Pi zu testen, wurde über WinSCP eine Verbindung wie hier eingerichtet, die automatisch Änderungen der IDE IntelliJ auf den Raspberry übertrug. Hierdurch können auf der einen Seite die Vorteile einer IDE verwendet werden, zum anderen kann durch die simultane Synchronisation mit einem Git-Repository das Debugging erheblich erleichtert werden.
Für weitere Schwierigkeiten sorgten verschiedene Linux eigene .a Bibliotheken, die schlichtweg nicht mit Windows kompatibel waren, wodurch das vollständige Programm nur noch auf dem Raspberry lief.
Fazit
Durch die vielen verfügbaren Dialogbotservices und diverser verfügbarer Tutorials ist der Einstieg in die Welt der Dialogbots kinderleicht. Einfache Dialogbots sind, auch ohne große Vorkenntnisse, in wenigen Minuten erstellt. Will man jedoch einen Dialogbot mit einer anderen Architektur haben, der beispielsweise dynamisch sein soll, so wird der Aufwand ziemlich schnell ziemlich groß. Außerdem ist hierfür der manuelle Konfigurationsaufwand relativ hoch, da dieser spezielle Fall schlichtweg außerhalb der Möglichkeiten des Frameworks liegt.
Falls man aber einfach nur an einer selbstgebauten Alexa interessiert ist, die einfache Workflows erledigen soll, so bieten die Frameworks alle benötigten Mittel. Durch die vielen Dokumentationen und Tutorials ist eine reibungsfreie Implementation beinahe schon gewährleistet :)
