• Lukas Danke
• Robert Halwaß
• Rim Khreis
• Alexis Popovski
• Dennis Walz

• Einleitung
• Tools
• Organisation
• Vorgefundener Stand
• Aktueller Stand
• Bisher aufgetretene Probleme
• Geplante Aufgaben

Chatbots sind ein logisches Produkt der heutigen Automatisierungsära. Sie können theoretisch für fast jedes Unternehmen nützlich sein, da ein erheblicher Teil von Benutzeranfragen ähnlich sind und wiederholt gestellt werden. Mit der schnellen Entwicklung des maschinellen Lernens, stellen Chatbots ein relevantes und aktuelles Thema dar, welches immer beliebter und nachgefragter wird. Weshalb also nicht auch ein Chatbot der Beuth Hochschule für Technik Berlin? Entwickelt von Studenten, für Studenten. Somit können nicht nur die Mitarbeiter des Studierendenservice entlastet, sondern auch kleine bis große Fragen der Studenten schnell beantwortet werden. Ein intelligenter Chatbot, der per Text und Sprache bedient werden kann, mittels künstlicher Intelligenz antwortet und vielen Features, wie z.B. sich vom Chatbot an wichtige Abgabetermine erinnern zu lassen.

In diesem Kapitel werden alle Tools aufgelistet und beschrieben, welche während des Projektverlaufes zum Einsatz kommen.

Jitsi ist ein OpenSource Video-Conferencing-Tool, welches im Rechenzentrum der Beuth-Hochschule gehostet wird. Dadurch ist der Datenschutz gewährleistet. Das Tool wird für die regelmäßigen wöchentlichen digitalen Treffen zwischen dem Betreuer und dem Projektteam zum Austausch von Informationen und Fragen genutzt.

Telegram ist ein kostenloser, verschlüsselter Text- und Sprachnachrichten-Dienst, welcher sowohl auf mobilen Geräten als auch Desktop-Ansicht funktioniert. Auch über Telegram kommuniziert das Projektteam über Textnachrichten mit dem Betreuer, falls, in den Tagen vor oder nach dem Meeting in Jitsi, Fragen aufkommen, welche schnellstmöglich beantwortet werden müssen.

Discord ist ebenfalls ein kostenloser Onlinedienst mit Chat-, Sprachkonferenz- und Videokonferenz-Funktion. Das Projektteam nutzt Discord, um sich, nach den wöchentlichen Treffen mit dem Dozenten, nochmal untereinander auszutauschen und auch an anderen Wochentagen zusammenzutun um sich zu organisieren.

Jira ist eine von Atlassian entwickelte Webanwendung, welche dem Projektmanagement bzw. Aufgabenmanagement dient. In Jira verfasst das Projektteam die Anforderungen des Projekts in kleineren Tasks, um diese wöchentlich in konstanten Schritten abzuarbeiten. Außerdem werden dort bislang die Stundenaufwände der einzelnen Projektmitglieder dokumentiert.

GitHub ist ein netzbasierter Dienst zur Versionsverwaltung für Software-Entwicklungsprojekte. Er wird für die Zusammenführung der Arbeitsergebnisse des Projektteams genutzt.

Im Wiki befindet sich eine große Sammlung an Berichten, Dokumentationen und Information zum BeuthBot und die Arbeit der vorherigen Semester an diesem. Diese große Ansammlung dient dem Projektteam zur Einarbeitung in das Projekt bzw. dem BeuthBot, aber auch zur Inspiration, wie sie bestimmte Dinge angehen und gestalten können. Des Weiteren hält das Projektteam in Ziemer's Wiki allgemeine Notizen zum Überblick, aber auch natürlich den Zwischenbericht und andere Dokumentationen fest.

Im folgenden werden die verschiedensten Entwicklungsumgebungen aufgelistet, welches jedes Projektmitglied nach seinen Vorlieben und Präferenzen nutzt, um am Code des BeuthBot's zu arbeiten und die Anforderungen umzusetzen.

• Visual Studio Code
• WebStorm / PHPStorm (Jetbrains Produkte)

Postman ist ein Programm zum Entwickeln, aber auch zum Testen von bereits bestehenden REST API's. Mit diesem Tool kann das Projektteam die Antwort auf ihre Anfragen überprüfen.

Jede Woche (Donnerstag 10:00) findet zwischen den Studierenden und dem Dozenten eine Rücksprache in Form eines Videochats mittels Jitsi statt. Bei diesem Treffen werden die Ergebnisse der letzten Woche besprochen, mögliche Unklarheiten geklärt und Ziele für die folgende Woche gesetzt.

Zur allgemeinen Kommunikation außerhalb der wöchentlichen Rücksprachen zwischen Studierenden und Dozent wird Telegram verwendet, um kleinere Fragen zu klären, welche nicht bis zum nächsten Rücksprachetermin warten können. Da der BeuthBot zum Start des Projektes nur Telegram unterstütze, erwies sich dies als logische Wahl.

Zur privaten Kommunikation unter den Studierenden wird Discord verwendet. Discord bietet den Vorteil, dass sowohl Text-Chat als auch Voice- und Video-Chat möglich ist. Dies bietet viel Flexibilität bei der Kommunikation innerhalb des Teams. Der Server wird privat gehostet, dadurch ist der Datenschutz hier ebenfalls gewährleistet. Viele der Studierenden haben auch bereits Erfahrung bei der Verwendung von Discord, wodurch keine lange Einarbeitungszeit notwendig war. Zusätzlich wurde sich auch dafür entschieden, den BeuthBot ebenfalls über Discord zugänglich zu machen.

Der Beuthbot besteht aus mehreren ineinandergreifenden Microservices, die über eine umfassende API miteinander kommunizieren. Durch diesen gewählten Ansatz lassen sich jederzeit weitere Microservices integrieren. Die Basis stellen folgende 4 Komponenten dar:

• Bot
• Gateway
• Registry
• Services

Hierbei handelt es sich um eine Abstraktion der verfügbaren Chatbots unterstützter Messaging-Dienste. Der Nutzer interagiert mit diesem Microservice, indem er Anfragen stellt und Antworten des Beuthbots erhält.

Das Gateway stellt das Herz des BeuthBots dar. Der Bot informiert das Gateway mit der vom User empfangenen Nachricht, nutzt dann NLP Microservices, um die Bedeutung und Absicht des Nutzers zu erkennen und informiert den entsprechenden Service, um dem Nutzer eine adäquate Antwort zu liefern.

Nachdem die Absicht des Nutzers analysiert worden ist, informiert das Gateway die Registry, um die Informationen zu erhalten, die der Nutzer benötigt. Darauffolgend verteilt die Registry die Anfrage an den entsprechenden Service.

Die Services liefern die seitens des Nutzers angefragten Daten. So liefert bspw. Der MensaService Informationen zu aktuellen Menüs, welche via diverser Parameter gefiltert warden (etwa nur vegetarische Gerichte).

Die Mikroservices kommunizieren untereinander mittels einer API. Sie basiert auf einem Response-Objekt, das die einzelnen Microservices durchläuft. Es besteht aus der anfänglichen Anfrage des Nutzers, seiner Daten und der ihm erstellten Antwort.

Der Bot läuft via docker-compose in einer VM. Immer wenn der Bot nicht erreichbar war, startete er neu sobald sich jemand in die VM einloggte und war dann auch wieder erreichbar. Der Grund dafür war, dass docker-compose so konfiguriert war, dass die Container zwar neu starten sollten, aber nicht sofort wenn sie abstürzten (sondern in diesem fall dann eben beim Login durch einen docker-user).

Der Lösung bestand entsprechend in der Änderung der Configuration nach „restart-always“. https://github.com/beuthbot/beuthbot/pull/3

Bei ersten Experimenten ist aufgefallen, dass wenn eine Nachricht an das Gateway geschickt wird und diese keine valide Telegram-ID enthielt, wurde die Nachricht ignoriert. Dieses war entgegen der Dokumentation, welche die Telegram-ID als optional definierte. Da dies für Testzwecke sehr hinderlich ist und im Projektverlauf zwei weitere Messenger (Discord und eigene Webseite) hinzugefügt werden sollen, galt dieses als eines der ersten Probleme die behoben werden sollten.

Durch eine Anpassung des Gateways bei der User-Abfrage wird eine valide Telegram-ID nicht vorausgesetzt. https://github.com/beuthbot/gateway/pull/2

Zuvor musste man um eine neue Version des BeuthBots zu deployen, musste manuell die neuste Version von GitHub gepullt werden und der Docker-compos-Befehl ausgeführt werden.

Mithilfe eines Selfhosted-Runners welcher auf dem BeuthBot-Server installiert wurde, ist es jetzt möglich diesen Prozess zu automatisieren. Sobald ein Git-Commit mit einem Versions-Tag gepusht wird, wird dies vom Runner erkannt und der Deploy-Prozess wird angestoßen. https://github.com/beuthbot/beuthbot/pull/4

• Say.js

  • https://www.npmjs.com/package/say
  • https://github.com/marak/say.js/
• Web Speech API 

  • https://wiki.selfhtml.org/wiki/JavaScript/Web_Speech
• Text2Speech

  • https://www.npmjs.com/package/text-to-speech-file

https://github.com/mozilla/DeepSpeech https://github.com/AASHISHAG/deepspeech-german

• Opensource
• Offline nutzbar
• Viel Dokumentation
• Deutsches Modell
• WER: 15%
• Zukunft ungewiss

https://github.com/kaldi-asr/kaldi http://kaldi-asr.org/doc/about.html

• Opensource
• Offline nutzbar
• Deutsche Modelle
• WER: 8,44%

https://github.com/facebookresearch/wav2letter

• Opensource
• Offline nutzbar
• Deutsche Modelle
• WER: 4%

https://github.com/freewym/espresso

• Opensource
• Offline nutzbar
• Kein deutsches Modell

https://github.com/NVIDIA/OpenSeq2Seq

• Opensource
• Offline nutzbar
• Kein Deutsches Modell

• Google (8%)
• Microsoft (5.9%)
• IBM (5.5%)
• Apple (5%)
• Baidu (16%)
• Hound (5%)

Quelle: https://askwonder.com/research/current-voice-recognition-word-error-rates-google-amazon-microsoft-ibm-apple-5b88trj0t

Eine initiale Feature-Idee für dieses Semester war es, dem Bot eine Moodle-Integration zu implementieren, durch die der Nutzer Ereignisse in Moodle mitgeteilt und an Abgabetermine erinnert werden kann. Moodle bietet hierfür eine REST-API: https://docs.moodle.org/dev/Web_service_API_functions.

Damit user-bezogene Daten abgerufen werden können muss der User sich in Moodle via username + passwort einloggen. Dieser Login kann nicht über die Chatbot-Funktionalitäten erfolgen, da Messenger in der Regel keine Passwort-Eingabe ermöglichen, was darin mündet, dass die Credentials im Cleartext im Chatlog landen.

Lösung: Es benötigt ein Webformular, was den Moodle-Login sicher zentralisiert. Der Bot darf im Chat nur den Link zum Login ausspielen.

Der BeuthBot ist ein Studierenden-Projekt. Es gibt derzeit keinen Production-Server, der nicht von Studierenden eingesehen werden kann. Die hohe Fluktuation an „Administratoren“ erzeugt ein hohes Risiko für das „Leaken“ von gespeicherten Credentials.

Gefahren:

1. Böswilliger Entwickler (programmiert daten-abfluss)
2. Gutwilliger Entwickler (macht Programmierfehler)
3. Böswilliger Admin (transferiert/liest persistierte daten)
4. Gutwilliger Admin (dupliziert/transferiert daten als backups)
5. Böswilliger Nutzer (nutzt sicherheitslücken / programmierfehler)

Das Token wird so nie auf die Festplatte geschrieben

1. [x] Böswilliger Entwickler (programmiert daten-abfluss)
2. [✓] Gutwilliger Entwickler (macht Programmierfehler)
3. [✓] Böswilliger Admin (transferiert/liest persistierte daten)
4. [✓] Gutwilliger Admin (dupliziert/transferiert daten als backups)
5. [✓] Böswilliger Nutzer (nutzt sicherheitslücken / programmierfehler)

Nachteil Lösung 1: Die Usability leidet stark, wenn der User sich ständig neu einloggen muss, weil der Bot die Credentials beim Neustart vergisst. Vor allem für Erinnerungs-Features ist das ein Showstopper.

Die Daten werden beim Speichern mit einem One-Time-Token verschlüsselt. Beim nächsten Start des Dienstes werden die Daten entschlüsselt und die persistente Kopie gelöscht

1. [x] Böswilliger Entwickler (programmiert daten-abfluss)
2. [✓] Gutwilliger Entwickler (macht Programmierfehler)
3. [x] Böswilliger Admin (transferiert/liest persistierte daten)
4. [✓] Gutwilliger Admin (dupliziert/transferiert daten als backups)
5. [✓] Böswilliger Nutzer (nutzt sicherheitslücken / programmierfehler)

Nachteil Lösung 2: Der One-Time-Key muss auch irgendwie gespeichert werden. Da dieser auch für die Anwendung zugänglich sein muss liegt er gewissermaßen neben der verschlüsselten Datei. Ein cleveres One-Time-Verfahren kann hier zwar dafür sorgen, dass fremder Zugriff auf die Daten nicht unbemerkt bleibt - Gerade Backups können auf diese Art ganz gut abgesichert werden indem der Key dort nicht gespeichert wird. Ein echter Schutz der Daten ist aber nicht gegeben, spätestens der böswillige Admin wird einen Weg finden das Verfahren zu manipulieren