Modellierung von Sprachdialogen mit paragon semvox ODP S3

Die Steuerung von Geräten mittels Spracheingabe ist aus dem Alltag nicht mehr wegzudenken. Beispiele für moderne, intelligente Sprachdialogsysteme bzw. Sprachassistenten findet man in den bekannten Diensten der großen Technologiefirmen wie Apples Siri, Amazons Alexa oder Googles Assistant.

All diese Dienste verbindet der Einsatz einer cloudbasierten Erkennung. Die Erweiterung der Funktionalität mit eigenen Implementierungen ist möglich, jedoch sind die Möglichkeiten der Einflussnahme begrenzt und Teile des Dialogablaufs müssen als Black Box betrachtet werden.

Ein anderer Ansatz zur Implementierung einer Sprachbedienung in eine eigene Anwendung soll im folgenden Artikel näher vorgestellt werden: Der Einsatz von paragon semvox ODP S3.

Funktionsweise von Sprachdialogsystemen

Der grobe Ablauf eines Sprachdialogs lässt sich in verschiedene Schritte unterteilen: Eingabe, Erkennung, Dialoglogik und Ausgabe.

1. Eingabe

Moderne Sprachdialogsysteme unterstützen eine multimodale Bedienung. Die Sprache ist nur eine der möglichen Eingabeformen und kann z.B. mit Tastendrücken oder Gesten kombiniert werden. Der Dialog kann dementsprechend per Taste oder durch ein sogenanntes Hotword / Wake Up Phrase begonnen werden („Hallo Computer!“).

2. Spracherkennung

Im Schritt der Spracherkennung verarbeitet der Erkenner (ASR / Automated Speech Recognition) die aufgenommenen Audiosignale und ermittelt daraus die Intention des Nutzers, die dann an die Dialoglogik des Sprachbediensystems weitergereicht wird.

Während der Erkenner in älteren Systemen meist auf feste, vorher definierte Kommandos beschränkt war, arbeiten moderne Systeme mit natürlichsprachlicher Erkennung (NLU / Natural Language Understanding). Der Erkenner verwendet statistische Modelle und vermutet basierend darauf, über welches Thema der Nutzer spricht bzw. welche Intention er oder sie gerade hat. Neben dem so erkannten Topic bzw. Intent werden auch dynamische Anteile der Erkennung mitgegeben, für die sogenannte Slots als Platzhalter definiert werden können.

Der Erkenner kann sowohl offline als auch online angesiedelt sein. In letzterem Fall werden die Audiosignale zur Verarbeitung in die Cloud geschickt und die erkannte Intention wird zurückgeliefert.

3. Dialoglogik

Die Dialoglogik bestimmt, wie auf das erkannte Topic reagiert wird. Je nach modelliertem Dialogverhalten werden z.B. weitere Nachfragen gestellt oder Aktionen an einem Backend angestoßen. Auch wird hier bestimmt, welche Ausgabe dem Nutzer präsentiert werden soll.

4. Ausgabe

Die Ausgabe in Sprachdialogsystemen erfolgt über sogenannte Prompts. Diese enthalten Text, der von einem Sprachsynthesizer (TTS / Text To Speech) synthetisiert und gesprochen wird. Der Text kann dabei mit Hilfe der Markupsprache SSML um Pausen, Betonungen etc. ergänzt werden. Auch die Verwendung von Phonemen zum Erreichen eines möglichst natürlichen Klangs ist üblich. Wie bei der Eingabe erfolgt auch die Ausgabe multimodal, die Sprachausgabe kann z.B. von einer Bildschirmanzeige begleitet werden.

Ein Ziel moderner Sprachdialogsysteme ist es, einen möglichst natürlichen Dialogablauf zu erhalten. Der Nutzer soll frei mit dem System interagieren und sich dabei natürlich verhalten können. Es soll nicht permanent der Eindruck vorherrschen, mit einer Maschine zu kommunizieren. Sowohl die Architektur des Systems als auch die Gestaltung der Interaktion zwischen Benutzer und System innerhalb des Dialogs tragen zur Erreichung dieses Ergebnisses bei.

Moderne Dialogführung am Beispiel von ODP S3

ODP S3 bringt Unterstützung von Natürlichsprachlichkeit sowohl bei der Eingabe (NLU) als auch bei der Ausgabe (NLG / Natural Language Generation) mit. Ein auf ODP basierendes Sprachbediensystem besteht aus einer Platform und einem oder mehreren Bundles. ASR und TTS werden nicht vorgegeben, so dass hier beliebige Systeme verwendet werden können.

Die Platform bildet den Use-Case-unabhängigen Kern des Systems. Sie bindet ASR und TTS an die ODP Runtime an und konfiguriert und steuert die allgemeinen Anteile des Dialogverhaltens wie Dialogstart oder Pausieren. Auch das Laden der Bundles findet hier statt.

ODP Bundles enthalten die Dialoglogik für einen Systembestandteil. Dies umfasst die Definition von Ein- und Ausgabemöglichkeiten und Verhalten mit Hilfe von verschiedenen Domain Specific Languages (DSLs) und die Ontologie, die das Kernstück der Dialoglogik darstellt. Des Weiteren beinhaltet das Bundle die Einsprungspunkte in die Java-Welt, wo Services angesprochen werden können, die Aktionen ausführen, mit einem Backend kommunizieren oder Kontextinformation für ODP bereitstellen.

Die Ontologie enthält Beschreibungen aller Entitäten aus der Dialoglogik und bildet das Domänenwissen der Anwendung ab. Die in ihr modellierten Beziehungen zwischen den Entitäten werden verwendet, um intelligentes Dialogverhalten wie die im folgenden Beispiel beschriebenen Funktionen zu realisieren.

Als Beispiel soll in diesem Artikel ein einfaches Programm zur Abfrage des Wetterberichts dienen, um einige Möglichkeiten zur Modellierung eines natürlichsprachlichen Dialogablaufs mit ODP zu zeigen.

1. Direkte Eingabe

Mit Hilfe der ODP DSLs wurde hierfür folgendes modelliert:

• Ein sogenannter Task, der die Abfrage eines Wetterberichts simulieren kann, indem ein in Java geschriebener Service angesprochen wird. Der Task enthält zwei Slots, einen für den Ort und einen für das Datum des Wetterberichts. Der Service beantwortet den Request und ergänzt ihn um einen Wetterbericht, der zusätzlich zu Ort und Datum die Temperatur und die Wettervorhersage enthält.
• Eine Reaktion auf ein erkanntes Topic bzw. eine erkannte Regel, die den Task aufruft und die erkannten Slotinhalte „heute“ und „Braunschweig“ in Ontologieobjekte umwandelt an den Task weitergibt, wenn das definierte Topic „Wetter“ vom Erkenner erkannt wurde.
• Ein Template, dass auf die erfolgreiche Ausführung des Tasks reagiert und die TTS anweist, den beschriebenen Prompt „In Braunschweig ist es heute sonnig bei 18 Grad.“ auszugeben, wobei die Bestandteile „Braunschweig“, „heute“, „sonnig“ und „18 Grad“ dynamisch gefüllt werden.

Der Task und die zu verarbeitenden Informationen werden in der Ontologie des Bundles modelliert, die für das Wetterbeispiel folgendermaßen aussehen könnte (Auszug):

2. Slotfilling

Hier wird derselbe Task angesprochen, jedoch können die Slots nicht direkt gefüllt werden, da der Nutzer keine Informationen zu Ort und Datum gegeben hat. Es wäre möglich, dies einfach zu akzeptieren und mit vordefinierten Werten zu arbeiten. Im Beispiel wurden die Slots jedoch als notwendig deklariert. Daher reagiert das System automatisch mit einer Nachfrage nach den beiden Informationen. Dies führt dazu, dass für beide Werte jeweils das Template mit der Aufforderung zur Eingabe der Information gesprochen wird und der Erkenner erneut geöffnet wird, um auf eine passende Eingabe zu warten.

3. Bestätigung

Es ist möglich, einen Task so zu konfigurieren, dass seine Ausführung bestätigt werden muss. In diesem Fall kann der Benutzer der Ausführung entweder zustimmen oder die eingegebenen Daten korrigieren.

Darüber hinaus sieht man an diesem Beispiel, wie das in der Ontologie modellierte Domänenwissen genutzt werden kann. Als Wert für den Datums-Slot hat der Nutzer „Wochenende“ angegeben. Das System hat dies automatisch auf „Samstag“ abgebildet und dafür das Wissen angewendet, dass „Wochenende“ als „Samstag“ gewertet werden kann.

4. Ambiguität

Bei der Verwendung von Sprachdialogsystemen kommt es immer wieder vor, dass eine Erkennung nicht eindeutig zugeordnet werden kann. Dies können sowohl sprachliche Ungenauigkeiten bei der eigentlichen Erkennung sein („Berlin“ vs. „Bellin“), als auch unterschiedliche Schreibweisen mit gleicher Aussprache („Torsten“ vs. „Thorsten“) oder mehrere mögliche Suchergebnisse für eine eindeutige Erkennung. Letzteres ist im Beispiel dargestellt. „Frankfurt“ könnte sowohl „Frankfurt an der Oder“ als auch „Frankfurt am Main“ meinen. Es wäre möglich, diese Ambiguität aus dem Kontext heraus zu lösen und beispielsweise den Ort zu nehmen, der näher ist oder schon öfter genannt wurde. Hier wurde sich jedoch dafür entschieden, die Ambiguität über eine Nachfrage aufzulösen. Mit „Letzteres“ wählt der Nutzer automatisch den letztgenannten Eintrag der präsentierten Liste der möglichen Städte aus.

5. Bezug auf vorhergehende Dialogschritte

Es ist jederzeit möglich, sich auf den Kontext oder auch auf die Dialoghistorie zu beziehen. Mit dem „dort“ in „Suche eine Unterkunft dort.“ teilt der Nutzer implizit mit, dass er den für die Unterkunftssuche zu füllenden Slot „Ort“ mit einem Wert füllen möchte, der im vorherigen Dialogkontext bereits verwendet wurde. Es ist also nicht mehr nötig, nach dem Ort zu fragen, auch wenn kein Ort explizit genannt wurde.

Entwicklungsumgebung

Für die Arbeit mit ODP S3 gibt es verschiedene Eclipse Plugins, z.B. den Ontologie Editor. Es ist auch möglich, mit der ODP Workbench eine eigene Entwicklungsumgebung zur Modellierung der DSLs zu verwenden. Auch eine Möglichkeit zur Spezifikation des Dialogverhaltens wird bereitgestellt. Auf diesem Weg kann man später Unittests implementieren, um das Dialogverhalten zu testen.

Fazit

ODP S3 kann verwendet werden, um natürlichsprachliche Dialoge unter Nutzung einer selbst gewählten ASR und TTS zu implementieren, so dass auch Anwendungen ohne Online-Erkenner möglich werden. Bei der Implementierung des Dialogverhaltens gibt es einen großen Freiheitsgrad und viele Möglichkeiten, das gewünschte Verhalten zu konfigurieren. Durch den ontologiebasierten Ansatz werden viele natürlichsprachliche Verhaltensweisen implizit ermöglicht. Es ist nicht nötig, jedes Verhalten explizit zu modellieren, stattdessen kann die in ODP integrierte intelligente Logik genutzt werden.

Links 
Verwendete Icons erstellt von Freepik, Vaadin, Darius Dan und Those Icons von www.flaticon.com

paragon semvox ODP S3 – https://www.semvox.de/technologien/odp-s3/
Aufbau von Sprachdialogsystemen – https://de.wikipedia.org/wiki/Sprachdialogsystem
Sprachassistenten – https://de.wikipedia.org/wiki/Intelligenter_pers%C3%B6nlicher_Assistent
SSML – https://www.xml.com/pub/a/2004/10/20/ssml.html