Multi-Plattform Entwicklung von Skills und Chatbots

Digitale Assistenten erfreuen sich bei Endkunden steigender Beliebtheit. Kaum eine Art der Interaktion ist intuitiver als die über Sprache. Die Entwicklung dieser sogenannten Skills ist jedoch herausfordernd – erst recht wenn Skills auf mehreren Plattformen verfügbar sein sollen.

Digitale Assistenten sind seit Jahren der letzte Schrei in Sachen Mensch-Maschine-Interaktion. Siri wurde bereits 2010 veröffentlicht und ist seit 2011 fester Bestandteil vieler Apple Produkte. Daraufhin haben auch die anderen Big-Player der IT geliefert: Amazon Alexa, Google Now/Assistant und Microsoft Cortana. Seit einiger Zeit ist es zudem möglich, dass Drittanbieter diese Assistenten um neue Funktionen erweitern können. Diese Erweiterungen werden meistens Skills genannt. So bietet DHL seinen Kunden zum Beispiel die Möglichkeit, den Paketstatus per Sprachbefehl zu erfragen.Eine weitere Möglichkeit, mit IT-Systemen per Sprache zur interagieren, sind die sogenannten Chatbots. Dies sind digitale Chatpartner auf Plattformen wie Skype oder Facebook Messenger, mit denen man per Textnachrichten kommuniziert.Diese Interaktionsmöglichkeiten vereinfachen die Verwendung von IT-Systemen – man muss nun keinen PC mehr bedienen können oder gar besitzen, wenn man Aufgaben in der digitalen Welt erledigen möchte. Doch was des einen Freud ist des anderen Leid. Denn die Kehrseite der Medaille sind konkurrierende Plattformen, die um die Gunst der Nutzer buhlen – und damit auch von den Unternehmen bedient werden müssen.Für eben jene Unternehmen ist es wünschenswert, mehrere Plattformen mit nur einer Softwarelösung bedienen zu können. Im Bereich der Chatbots bietet Microsofts Bot Framework bereits eine Vielzahl an Möglichkeiten (z.B. Skype, Slack, Facebook Messenger). Im Bereich der digitalen Assistenten sieht es dagegen mau aus. Nachfolgend ist am Beispiel eines Alexa Skills beschrieben, wie eine Architektur aussehen kann, die dieses Problem löst.

Ziel einer Multi-Plattform Architektur ist es, eine erweiterbare Architektur anzubieten, bei der das Hinzufügen einer zusätzlichen Chat-Plattform oder eines digitalen Assistenten (nachfolgend unter dem Begriff Kanal zusammengefasst) keine Anpassung am Backend der Anwendung mehr notwendig macht.

Alles beginnt mit einer Aussage des Nutzers, die per Text oder Sprache eingegeben wird. Das Skill-Backend nimmt diese entgegen. Dies ist das Backendsystem des Kanals – im Fall von Amazon Alexa heißt es z.B. Alexa Skills Kit. Diese Komponente wird vom Anbieter des Kanals bereitgestellt und muss durch einen Entwickler so konfiguriert werden, dass die eingehenden Nachrichten die Aussagen des Nutzers enthalten. Bei sprachgetriebenen Kanälen findet hier die Umwandlung von Speech-to-Text oder Text-to-Speech statt.Wie einleitend erwähnt, unterstützt das Microsoft Bot Framework bereits von Haus aus eine Vielzahl an Kanälen. Für die Anbindung weiterer gibt es zudem eine REST-API mit der das Chatbot-Backend angesprochen werden kann – genannt DirectLine API. Da der angebundene Kanal nicht direkt mit dieser API kommunizieren kann, vermittelt ein sog. Skill-Mediator zwischen ihnen. Dieser übernimmt die bidirektionale Umwandlung und Weiterleitung der Nachrichten. Er nimmt also Nachrichten vom Skill-Backend entgegen und schickt sie über die DirectLine API weiter – oder umgekehrt. Jeder angebundene Kanal verwendet für gewöhnlich ein eigenes Nachrichtenformat und wird daher einzeln implementiert.Das Chatbot-Backend empfängt die Nachricht nun über die DirectLine API. Es handelt sich dabei um die zentrale Komponente der Architektur. Sie steuert die Dialoge – weiß also, welche Informationen vom Nutzer für eine bestimmte Aktion abgefragt werden müssen und wie der Bot antworten soll. Auch externe APIs werden hier angebunden, damit notwendige Daten (bspw. Wetterbericht, Kundenprofil) ermittelt oder manipuliert werden können. Das Chatbot-Backend kann neue Aktionen nur unterstützen, wenn es entsprechend angepasst wurde.Wenn Daten nutzerspezifisch oder ihr Zugriff auf einen Nutzer beschränkt sein sollen, muss zusätzlich ein Identity Providerintegriert werden.Um zu identifizieren, welche Aktion ausgeführt werden soll, kommt die Natural Language Understandig (NLU)Komponente zum Einsatz. In diesem Beispiel wird dazu der Dienst LUIS als Teil der Microsoft Cognitive Services verwendet. (Unsere Architektur ist jedoch nicht auf diese Lösung beschränkt.) Die Komponente bildet textuelle Aussagen (Utterances) auf Nutzer-Absichten (Intents) ab. Auf Basis der erkannten Absicht werden Aktionen ausgeführt. Wichtig dabei ist auch das Herausfiltern von Entitäten aus den Aussagen:

Intent und Entitäten werden im Backend auf eine Aktion gemappt. Hier wird bspw. eine Wetter-API nach den notwendigen Daten abfragt und daraufhin eine passende Antwort für den Nutzer generiert.

Damit die Architektur zustandslos arbeitet, werden die während des Gesprächs gesammelten Informationen außerhalb der Komponenten zwischengespeichert. Das übernimmt eine Storage-Komponente, bspw. Azure Table Storage. Das Bot Framework bietet aber auch ein Interface zur Anbindung beliebiger Persistenzsysteme.

So viel zum prinzipiellen Aufbau einer Multi-Plattform Architektur für digitale Assistenten und Chatbots. Damit wird es möglich, Chatbots und digitalen Assistenten mit einem identischem Backend einzusetzen. Eine angepasste Dialogführung kann dennoch ratsam sein: Basierend auf den Möglichkeiten des Kanals – Chatbots nutzen i.d.R. visuelle Elemente, digitale Assistenten ggf. nur Audio-Medien – können Interaktionen im Backend entsprechend unterschiedlich gehandhabt werden.

Welche besonderen Herausforderungen eine Multi-Plattform Architektur mit sich bringt, wird nachfolgend bei der Anbindung von Alexa an das Chatbot-Backend deutlich.

Bei diesem Ansatz wird der Alexa Skill so aufgebaut, dass keine Dialoge im Skill- Backend konfiguriert werden. Der Skill dient lediglich dazu, die Aussage des Nutzers zu erfassen, in Text umzuwandeln (Speech-to-Text) und an das Chatbot-Backend weiterzuleiten.

Da das Alexa Skills Kit (ASK) von Haus aus keine Möglichkeit bietet, die Aussagen des Nutzers abzugreifen, ist ein kleiner Trick notwendig: Hierzu wird ein einziger Intent angelegt, der über einen Custom Slot Type die gesamte Aussage abgreift und als Entität bereitstellt (in ASK als Slot bezeichnet). Als Ausgangspunkt für den Skill-Mediator wurde das alexa-bridgeProjekt verwendet und erweitert. Hier sind auch Details zur Einrichtung des Behelfs-Intents und des Custom Slot Types zu finden.

Die Anwendung liest nun die Utterance aus dem Slot-Value aus und schickt sie als Message an das Chatbot-Backend. Sobald dieses eine Nachricht zurücksendet, wird sie im Skill-Mediator umgewandelt und an das Alexa-Backend zurückgesandt. Von dort erfolgt die Weiterleitung zur Ausgabe an das Amazon Echo Endgerät.

Für sehr einfache Dialoge sowie vor allem in englischer Sprache betriebene Alexa Skills ist die Vorgehensweise gut geeignet. Sollen die Dialoge jedoch komplexer sein oder wird ein Skill in deutscher Sprache verwendet, ist Variante 2 besser geeignet. Dies liegt vor allem daran, dass die Spracherkennung (NLU) deutscher Texte gegenüber der englischen Sprache zurückliegt. Je nach Art und Form der Aussagen und Entitäten kann es hier zu Verständnisproblemen kommen.

Der große Vorteil dieser Variante ist die Beschränkung auf lediglich einen Intent, der im Skill-Backend konfiguriert wird. Kommen neue Dialoge hinzu, so ist keine Anpassung notwendig.

Hierbei wird ebenfalls der Skill-Mediator verwendet, jedoch in abgewandelter Form: Im Skill-Backend werden die Dialoge vollständig modelliert und notwendige Entitäten abgefragt. Diese Daten werden anschließend gemeinsam als Nachricht an das Chatbot-Backend gesendet. Da hierdurch die Daten nochmal in LUIS (siehe Abb. 1) verarbeitet werden, muss für diese Nachricht ein Format definiert und als Aussage für die Intents in LUIS hinterlegt werden. Ein solches Format könnte wie folgt aussehen

alexa-intent - <Intent-Name-im-Alexa-Backend>;<Slot-Value 1>;…;<Slot-Value n>

So kann der Skill-Mediator weiterhin unabhängig von den konfigurierten Intents arbeiten und muss lediglich eine Nachricht nach diesem Schema konstruieren und versenden.

Auf diese Weise funktioniert die Spracherkennung zuverlässiger – insbesondere bei deutschen Skills – denn bereits im Skill-Backend können so Entitäten innerhalb der Aussagen markiert und damit zuverlässiger extrahiert werden. Ein Nachteil ist, dass die Dialogpflege sowohl in LUIS als auch im Alexa Backend nötig ist. Mit fortschreitender Reife der Spracherkennung deutscher Texte könnte dieser „Umweg“ jedoch überflüssig werden.

Um der wachsenden Zahl an Chat- und Assistenten-Plattformen Herr zu werden, ist es notwendig, einen Architekturansatz zu entwickeln, der eine plattformunabhängige Entwicklung von Bots und Skills ermöglicht.

Bei den hier vorgestellten Lösungen kommt ein Skill-Mediator zum Einsatz, der die Anbindung digitaler Assistenten-Plattform vereinheitlicht. Die Komponente übernimmt die Ankopplung an die jeweils gewünschte Assistenten-Plattform und schafft so eine effiziente Erweiterungsschnittstelle. Eine Anpassung des Chatbot-Backends ist nicht erforderlich. Je nach Qualität der Speech-to-Text-Engine der Assistenten-Plattform und Mächtigkeit des eingesetzten Natural Language Understanding Frameworks entfällt ebenfalls die mehrfache Pflege der Dialogführung. Damit spart der Skill-Mediator nicht nur Aufwand und Kosten, sondern ermöglicht zudem eine einheitliche User-Experience über alle angebundenen Plattformen hinweg. Das steigert die Nutzer-Akzeptanz, wenn ein Skill bspw. sowohl via Amazon Echo als auch via Smartphone per Google Assistant verwendet wird.