Sprachlevel – Wo steht ihr Chatbot?

In dieser Artikelreihe werden wiederkehrende Dialogentwurfsmuster und der Einsatz von Active Learning in Dialogsystemen vorgestellt. Anhand des Rasa-Frameworks wird zudem eine Implementation von einigen Beispielen aufgezeigt. Dieser Artikel dient als kurze Einführung in die nötige Terminologie von Dialogsystemen im Allgemeinen und des spezifischen Vokabulars innerhalb des Rasa-Frameworks. Zusätzlich wird der momentane Stand der Technik erläutert, um die in den folgenden Beiträgen beschriebenen Verfahren in das Gesamtbild einordnen zu können.

Drei wesentliche Bestandteile eines Dialogsystems sind Intents, Entities und Slots.

Intents beschreiben die Nutzerabsichten, welche ein Dialogsystem erkennen kann. Dabei werden Stichworte, Phrasen und Sätze mit einem bestimmten Intent innerhalb des Systems verknüpft. Moderne Systeme setzen dabei auf Ähnlichkeitsmetriken, anstatt auf bloße Stichworterkennung, um eine flexiblere Modellierung zu ermöglichen.

Entities sind relevante Informationen innerhalb einer Nutzereingabe, welche von einem Dialogsystem extrahiert werden sollten. In der Regel wird hierzu eine Technik aus dem Natural Language Processing (NLP) namens Named Entity Recognition (NER) verwendet.

Slots bilden das Gedächtnis eines Dialogsystems. In den Slots werden relevante Informationen gespeichert, welche über mehrere Sprecherwechsel hinweg benötigt werden. Häufig sind dies Entities, welche aus vorherigen Nutzerinteraktionen extrahiert oder Entscheidungen, die vom Nutzer getroffen wurden.

Einen tieferen Einblick in den Aufbau von Chatbots erhalten Sie in diesem Blogbeitrag.

Rasa ist ein modernes Open Source Framework zur Implementierung von Dialogsystemen. Die grundlegende Struktur und die Kernkonzepte werden im Folgenden kurz erläutert. Große Teile der Funktionalität von Rasa können in Konfigurationsdateien im yaml-Format deklariert werden. Dies ermöglicht ein schnelles Prototyping und durch die deklarative Einbindung von eigenen Komponenten wird nichtsdestotrotz eine hohe Anpassbarkeit gewährleistet.

Das Sprachverständnis oder Natural Language Understanding (NLU), wird über die Angabe von Intents und zugehörigen Beispielphrasen in der nlu.yml-Datei deklariert.

Welche Funktionalitäten der Chatbot haben soll, kann in Rasa mithilfe von sogenannten Custom Actions abgebildet werden. Dies sind reguläre Python-Klassen, die ein Interface zum Chatbot bieten und beliebigen Code enthalten können, um die Geschäftslogik abzubilden.

Wie das System diese Intents und Actions kombinieren soll, wird mit sogenannten Rules und Stories modelliert. Während mit Rules fixe Interaktionsfolgen festgelegt werden können, lassen sich mit Stories kontextuell abhängige Konversationspfade bestimmen. Bei der Modellierung sollte also ein Gleichgewicht zwischen Vorhersagbarkeit durch Rules und Flexibilität durch Stories gefunden werden.

Die zentrale Konfigurationsdatei in Rasa ist die domain.yml. In der Domain müssen alle Intents, Entities, Slots und Actions deklariert werden, damit diese vom Chatbot verwendet werden können.

Eine detaillierte Erklärung der Funktionsweise des Frameworks finden Sie in diesem Blogbeitrag.

Rasa definiert 5 Entwicklungsstufen, in die Sprachassistenten eingeordnet werden können. Dabei werden maßgeblich zwei Dimensionen betrachtet. Zum einen die Sicht des Entwicklers und zum anderen das Endnutzererlebnis. Mit steigendem Level verbessert sich das Nutzererlebnis linear, der Entwicklungsaufwand hingegen steigt zunächst exponentiell an und flacht anschließend wieder ab.

Level 1 stellt dabei rudimentäre Systeme wie Command-Line Interfaces (CLIs) dar. Sie bieten eine direkte Schnittstelle zu einem Softwarepaket, erfordern jedoch konkretes Wissen über die angegebenen Parameter. Die Benutzung eines CLI erfordert also eine hohe initiale Lernkurve für den Anwender, ist an Effizienz für Power-User allerdings kaum zu schlagen.

Aus Entwicklersicht sind diese Systeme einfach zu implementieren, da die Funktionalität klar voneinander getrennt und modularisiert werden kann.

Level 2 Systeme können hingegen als tatsächliche Chatbots identifiziert werden. Durch eine vage Formulierung des Ziels kann der Nutzer die gewünschte Funktionalität auslösen und die benötigten Parameter werden vom System selbstständig erfragt. Die hinterlegten Konversationspfade folgen jedoch nach wie vor starren Mustern und unvorhergesehene Abweichungen von diesem Pfad werden nicht unterstützt.

Der Entwicklungsaufwand explodiert für diese Systeme, da diese aus einem starren Regelwerk bestehen, für die jeder Fall konkret beschrieben werden muss. Das Hinzufügen neuer Funktionalität kann, aufgrund der Zerbrechlichkeit dieses Regelwerks, leicht zu Fehlern in bereits bestehenden Abläufen führen.

Level 3 ermöglicht eine Kontextualisierung der Nutzerinteraktionen. Es ist nicht mehr nötig, dass der Nutzer die Verwendung des Assistenten erlernen muss, sondern dieser passt sich umgekehrt an das Verhalten des Nutzers an. So können beispielsweise unvorhergesehene Nachfragen, Themenwechsel und Korrekturen des Nutzers unterstützt werden. Lediglich die Zielstellung muss dem Nutzer bekannt sein, welche er auch erkennbar als solche formulieren muss.

Der Entwicklungsprozess durchläuft an dieser Stelle einen Perspektivwechsel. Das Konversationsdesign wird nicht mehr durch den Entwickler selbst bestimmt, sondern durch observierte Nutzerinteraktionen. Das System passt sich also iterativ an die Bedürfnisse der Nutzerbasis an, indem der Entwickler Nutzerinteraktionen auswertet und einpflegt.

Level 4 erlaubt den Nutzern, ihre Situation in eigenen Worten zu formulieren. Das System ist in der Lage, das Ziel des Nutzers mittels gezielten Nachfragens zu erörtern, ohne dass dieses vom Nutzer explizit genannt wird. Das System führt den Nutzer also anhand seines formulierten Anliegens mittels Beratung und der Präsentation von möglichen Optionen zu einer Lösung, welche dem Nutzer eingangs eventuell noch unbekannt war.

Um dies zu ermöglichen, wird der in Level 3 eingeführte Paradigmenwechsel in dieser Stufe teilautomatisiert. Das System ist in der Lage, Interaktionen selbstständig zu bewerten und erfolgreiche Konversationen als neue Trainingsdaten zu integrieren. Fehlgeschlagene Konversationen werden als solche markiert und durch den Entwickler bewertet, korrigiert und manuell in das System überführt.

Level 5 erweitert das System um anpassbares Verhalten. Das Abstraktionsniveau der Nutzeranfrage wird analysiert und entsprechend reagiert, anstatt eine generische Antwort zu liefern. Das System erkennt selbstständig Nuancen in der Abfrage und ermöglicht eine nahtlose Weiterleitung an andere Systeme oder menschliche Mitarbeiter, falls es die Anfrage nicht bearbeiten kann.

In dieser Stufe beschränkt sich der Entwicklungsaufwand auf das Implementieren der Geschäftslogik. Um die neuen Funktionen im Sprachassistenten zu verankern, genügen wenige beispielhafte Interaktionen, da das System in der Lage ist, auch bisher ungesehene Situationen in Gänze selbstständig zu bewerten und zu kontextualisieren. Die Hauptaufgabe der Entwickler sollte in dieser Stufe die Kontrolle des Systems sein, um bei Bedarf manuelle Anpassungen vorzunehmen.

In diesem Artikel wurde das grundlegende Vokabular vorgestellt, welches für Dialogsysteme im Allgemeinen und das Framework Rasa im Speziellen benötigt wird. Weiterhin wurde ein Klassifikationsschema von Dialogsystemen vorgestellt. Mittels des Rasa Frameworks ist es möglich, Dialogsysteme zu entwickeln, welche der Stufe 2 und 3 entsprechen. In den folgenden Blogartikeln werden die Dialogentwurfsmuster vorgestellt um dies zu erreichen und wie mittels Active Learning ein Schritt in Richtung Stufe 4 ermöglicht wird. Lesen Sie dazu mehr in Blogartikel [2].

Seminarempfehlungen