Benutzer:Sebschne/Informationstate
Ein Informationstate repräsentiert die Informationen, die den Teilnehmern zu jedem Zeitpunkt in einem Dialog zur Verfügung stehen. Es ist die zentrale Komponente im Informationstate Ansatz für Dialogmanagement in Dialogsystemen.
David Traum und Staffan Larrson publizierten diesen Ansatz in dem Artikel "The Information State Approach to Dialogue Managament" in Current and New Directions in Discourse and Dialogue in 2003.[1]
Zentrale Idee des Ansatzes ist die Formalisierung von Dialogmanagementfunktionen unter Berücksichtigung von Zuständen des Dialogs. Diese Sichtweise soll die Identifizierung von relevanten Aspekten von Informationen in einem Dialog erleichtern und die Sicht auf Dialogtheorie und Implementierung vereinheitlichen. Als Konsequenz daraus können Werkzeuge zur Erstellung von Dialogsystemen besser wiederverwendet und erweitert werden. Ein Beispiel hierfür ist das von den Autoren vorgeschlagene Dialogue Move Engine Toolkit.[2]
Definition
Dialogmanager
In einem Dialogsystem aktualisiert der Dialogmanager den Kontext des Dialoges aufgrund der interpretierten Kommunikation, generiert kontextabhängige Erwartungen, koordiniert den Dialog und entscheidet welcher Inhalt ausgewertet und ausgedrückt werden soll.
Informationsbasierte Dialogtheorie
Die informationsbasierte Dialogtheorie (engl.Information-state based theory of dialogue) besteht aus:
- Informationskomponenten
- Formale Repräsentation
- Dialogue Moves
- Aktualisierungsregeln
- Aktualisierungsstrategien
Durch die Definition dieser einzelnen Komponenten soll es möglich sein, leicht neue Dialogtheorien in einem Dialogsystem zu implementieren und zu erweitern. Des Weiteren soll die Wiederverwendbarkeit von bereits implementierten Komponenten gesteigert werden.[3]
Informationskomponenten
Informationskomponenten können den internen Zustand der Teilnehmer und die gesamten externen Zustände des Dialogs beschreiben. Der interne Zustand kann durch den mentalen Status der Teilnehmer repräsentiert werden. Üblicherweise werden die Absichten, Überzeugungen und Wünsche (intentions, belief, desires: BDI Agenten) modelliert. Diese werden wiederum in statische, dynamische, private und geteilte (shared) Komponenten unterschieden. Statische Komponenten sind domänenspezifisch und ändern sich nicht während des Dialogs. Dynamische Komponenten können sich nach jeder Äußerung verändern.
Formal Representation
Die formale Repräsentation (formal representation) gibt an, in welcher Datenstruktur Informationskomponenten modelliert werden. Hierzu zählen alle klassischen Datenstrukturen wie Listen, Stacks, Queues oder Sets. Das folgende Beispiel zeigt die formale Repräsentation eines Informationstates.
PRIVATE: BEL: SET(PROP)
AGENDA: STACK(ACTION)
SHARED: BEL: SET(PROP)
QUD: STACK(QUESTION)
LM: MOVE
Zu den privaten Komponenten gehören Überzeugungen (BELIEFS), die aus einem Satz (SET) von Aussagen (PROPOSITON) bestehen, und eine Agenda die aus einem Stack von Aktionen (ACTION) besteht. Zu den Komponenten von denen ausgegangen wird, dass sie dem Benutzer und dem System gemeinsam zur Verfügung stehen, zählen gemeinsame Überzeugungen, Fragen die zur Diskussion stehen (QUD: Question Under Discussion), die als ein Stack mit Fragen (QUESTION) modelliert werden und der letzte Sprechakt (Last dialoge Move) der geäußert wurde.
Dialogue Moves
Die Äußerungen der Benutzer sind sogenannte Sprechakte (dialogue moves) und können in unterschiedliche Kategorien eingeteilt werden. Sie abstrahieren die verschiedenen Nachrichten die in einem Dialog kommuniziert werden können. Eine einzelne Äußerung kann mehrere simultane dialogue moves oder zeitlich geordnet moves enthalten. Durch einen move wird eine Aktualisierung des Informationstates ausgelöst. Den Umfang an vorhandenen dialogue moves hängt von der Aufgabe ab, in der das Dialogsystem eingesetzt werden soll. Die Schwierigkeit besteht darin dialogue moves voneinander zu unterschieden und die moves zu interpretieren, die mehrere Funktionalitäten ausdrücken können. In einem einfachen Dialogsystem könnten Beispielsweise die moves: Frage und Antwort unterschieden werden.
Aktualisierungsregeln
Aktualisierungsregeln (Update Rules) geben an, wie sich der Informationstate während eines Dialogs verändert. Sie bestehen immer aus einem Satz von Vorbedingung (preconditions) und Effekten (effects), die sich daraus ergeben. Beispiel:
U-RULE: integrateSysAsk
PRE: val(SHARED.LM, ask(usr,Q)), fst(PRIVATE.AGENDA, raise(Q))
EFF: push(SHARED.QUD, Q), pop(PRIVATE.AGENDA)
Diese Regel integriert eine Frage in den Informationstate, die vom System gestellt (integrateSysAsk) wurde. Sie beinhaltet zwei Vorbedingungen. Erstens, dass der letzte Dialogue Move eine Frage des Systems an den Benutzer war und zweitens, dass das erste Element der privaten Agenda des Systems war eine Frage zu stellen. Die Effekte dieser Regel sind, dass die gestellte Frage auf den Stack der Fragen die zur Diskussion stehen (QUD: Question Under Discussion) abgelegt wird und, dass das erste Element der privaten Agenda des Systems entfernt wird.
Update Strategy
Eine Aktualisierungsstrategie (Update Strategy) gibt an in welcher Reihenfolge die Aktualisierungsregeln angewendet werden sollen. Zum Beispiel: Nimm die erste Regel, die angewendet werden kann oder wende jede Regel sequentiell an. Weiterhin können auch probabilistischen Informationen zur Auswahl benutzt werden.
Unterschiede zu endlichen Automaten
Bei der Dialogmodellierung mit endlichen Automaten verhält sich der Dialog gegeben einer bestimmten Grammatik. Der Übergang von einem Zustand in den nächsten wird durch den Dialogue Move, der ausgeführt wurde, bestimmt. Im jedem Zustand gibt es nur einen Satz von erlaubten moves die ausgeführt werden können. Im Gegensatz zur Dialogmodellierung mit Hilfe von endlichen Automaten ist der Zustand des Dialogs, beim Informationstateansatz, implizit im Informationstate selbst modelliert. Somit hängt die Aktualisierung und die Auswahl des nächsten Dialogue Moves nicht von dem gesamten Zustand ab, sondern nur von einem Teil der Informationen die zu einem gegeben Zustand vorhanden sind.[4]
Beispiel
Das folgende Beispiel zeigt ein Dialogsystem, dessen Informationstate und Aktualisierungsregeln in einer Reisedomäne[5]. Zum Anfang sieht der Informationstate folgendermaßen aus:
PRIVATE = BEL = {}
AGENDA = (raise(?x.dest-city(x)),raise(..),..)
SHARED = BEL = {}
QUD = {}
LM = ...
Das System selektiert aufgrund des aktuellen Informationstate eine angemessene Aktualisierungsregel:
U-RULE: selectAsk
EFF: {set(NEXT.MOVE.ask(?x.dest-city(x))}
Dadurch fragt das System den Benutzer nach den gewünschten Zielort:
Sys: Where do you want to go?
Anschließend wird diese Frage in den Informationstate eingepflegt:
U-RULE: integrateSysAsk
EFF: push(SHARED.QUD, ?x.dest-city(x))
pop(PRIVATE.AGENDA)
Aufgrund dieser Aktualisierung verändert sich der Informationstate und die gestellte Frage wurde integriert:
PRIVATE = BEL = {}
AGENDA = (raise(?x.depart-city(x)),raise(..),..)
SHARED = BEL = {}
QUD = {?x.dest-city(x)}
LM = ask(?x.dest-city(x))
Der Benutzer antwortet und gibt seinen Reisewunsch an:
USR: Malvern
Anschließend wird die Aussage des Benutzers durch eine weitere Regel integriert und die offene Frage entfernt:
U-RULE: integrateUsrAnswer
EFF: {add.SHARED.BEL.dest-city(malvern)}
U-RULE: downdateQUD
EFF: {pop.SHARED.QUD}
Letztendlich ergibt sich daraus folgender Informationstate:
PRIVATE = BEL = {}
AGENDA = (raise(?x.depart-city(x)),raise(..),..)
SHARED = BEL = {dest-city(malvern)}
QUD = {}
LM = answer(malvern)
Multilevel Architektur für Dialogmanagement
Um einen Dialogsmanager für bestimmte Aufgaben bauen zu können benötigt man Fachwissen in den unterschiedlichsten Bereichen. Es muss ein komplexes Softwaresystem verwaltet werden, man benötigt Wissen in Dialogtherorien und benötigt domänenspezifisches Wissen. Da selten eine Person genügend Wissen über alle Bereiche besitzt wurde vorgeschlagen, die Bereiche in unterschiedliche Softwarekomponenten aufzuteilen.
Dies ermöglicht parallele Entwicklung und die Wiederverwendung von Komponenten in neuen Systemen. Auf der untersten Ebene dieser Architektur befindet sich die Verantwortung von Software Engingeering Techniken zur Entwicklung von Werkzeugen die eine leichte Implementierung von Dialogtheorien ermöglichen.[6] Für diesen Anspruch wurde das TrindiKit entwickelt.
Einzelnachweise
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management. In: 'Current and New Directions in Discourse and Dialogue. 2005, S. 325-353
- ↑ Staffan Larsson, Peter Bohlin, Johan Bos, and David Traum. TrindiKit 1.0 manual. Deliverable D2.2, TRINDI Project, November 1999
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management', 2005, S. 5-10
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management', 2005, S. 5
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management', 2005, S. 11
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management', 2005, S. 11-13
