Benutzer:Sebschne/TrindiKit
TrindiKit ist ein Toolkit zum Bauen und Experimentieren mit Dialogue Move Engines und Informationstates[1].
TrindiKit: Dialogue Move Engine Toolkit
Eine Dialogue Move Engine aktualisiert den Informationstate, überwacht ausgeführte Dialogue Moves und wählt den nächsten move aus. Abgesehen von der allgemeinen Systemarchitektur spezifiert TrindiKit Formate zur Definition von Informationstates, Aktualisierungsregeln, dialogue moves und zugehörigen Algorithmen. Des Weiteren liefert es Werkzeuge zum Experimentieren mit unterschiedlichen Implementierungen von Informationstates, Aktualisierungsregeln und Algorithmen.
Zum Bauen einer Dialogue Move Engine müssen Aktualisierungsregeln, dialogue moves, Aktualisierungsalgorithmen und die interne Struktur des Informationstate angegeben werden. Zusammen mit weiteren Modulen wird dadurch Dialoguemanagement und Diskursverfolgung realisiert. Somit liefert das TrindiKit Bausteine zum Bilden von unterschiedlichen Dialogtheorien und Systemen, jedoch keine explizite Implementation von diesen. Die aktuelle TrindiKit Implementation ist in SICSTUS Prolog geschrieben.[2]
Komponenten
Zu der TrindiKit Architektur gehören
- der Total Information State (TIS),
- die Dialogue Move Engine (DME), die aus mehreren DME Modulen bestehen kann
- non-DME Module
- eine Kontrolleinheit
Die Dialogue Move Engine kann eine oder mehrere Update Module enthalten, die jeweils unterschiedliche Update Rules und Update Strategies beinhalten. Der Total Information State besteht aus dem Informationstate, Interfacevariablen und Rescourcenschnittstellen.
Um ein nutzbares Dialogsystem bauen zu können werden jedoch noch zusätzliche Module (non-DME Module) benötigt. Es werden Module, die die Eingaben von dem Benutzer entgegenehmen, interpretieren und Ausgaben erzeugen benötigt, aber auch Schnittstellen zum lesen und schreiben dieser Module auf dem Informationstate. Desweiteren können noch externe Quellen wie Datenbanken oder Bibliotheken eingebunden werden. [3]
Implementationen
Mithilfe des TrindiKit Toolkits wurden mehrere Dialogsysteme implementiert, die unterschiedliche Dialogtheorien verwenden.
GoDiS
GoDis ist ein experimentelles Dialogsystem zur Explorierung und Entwicklung von Issue-based dialogue management. [4] Es kann mehrere Themen gleichzeitig behandeln, Implementiert nachfrageorientierten, aktionsbasierten Dialog, Grounding und Frageneinbettung. Das Letztere bedeutet, dass der Benutzer Fragen beantworten kann, die noch nicht gestellt wurden. Das System sucht zu dieser Antwort eine passende Frage und pflegt diese in den Informationstate mit ein. Es gibt sechs Dialogue Moves: ask, answer, request, confirm, greet und quit.[5]
Informationstate
Der Informationstate in GoDis sieht folgendermaßen aus:
BEL = {}
AGENDA = {}
PLAN = <findout(?x.dept-month(x)),findout(?x.dept-day(x)),findout(?x.class(x)), consultDB(?x.price(x))>
PRIVATE = TMP = ...
NIM = ...
COM = {}
ISSUES = <>
SHARED = QUD = <>
PU = ...
LU = ...
Die Komponenten des Informationstate haben in absteigender Reihenfolge folgende Bedeutungen:
- Belief (BEL): Proposition die das System als wahr annimmt.
- Agenda (AGENDA): Kurzfristige Absichten des Systems
- Plan (PLAN): Langfristige Dialogziele
- Temporary (TMP): Verfolgt geteilte Informationen, bevor die letzte Äußerung integriert werden soll.
- Not Integrated Moves (NIM): Speichert moves die, von der letzten Äußerung, noch nicht integriert wurden.
- Commitments (COM): Ein Satz von Annahmen, zu denen sich das System und der Benutzer verpflichtet haben.
- Issues (ISSUES): Enthält Fragen die explizit oder implizit aufgekommen sind, aber noch nicht geklärt wurden.
- Question under Discussion (QUD): Fragen die zur Diskussion stehen. Kann benutzt werden, um elliptische Aussagen zu interpretieren.
- Previous Utterance/Latest Utterance (PU/LU): Enthalten den letzten und aktuellen Dialogue Move.
Dialogbeispiel
Sys: Welcome to the travel agency! Usr: flights to paris Sys: Okay, you want to know about price. A flight to Paris. Let's see. What city do you want to go from? Usr: London Sys: Okay, from London. When do you want to travel? Usr: in april, as cheap as possible Sys: Okay, in April, economy class. What day do you want to travel? Usr: The fifth Sys: Okay. The price is $300
Die erste Äußerung des Benutzers wird von dem System als zwei Dialogue Moves interpretiert. In diesem Fall als zwei answer moves. Dadurch werden zugleich zwei Fragen beantwortet: Wohin soll die Reise gehen? und mit welchen Transportmittel?. Das System hat jedoch noch keine Pläne erstellt und keine Frage gestellt. Dadurch müssen Pläne und Fragen gefunden werden, die zu den Äußerungen passen. Nach dem eine passende Frage gefunden wurde und das System den passenden PLAN geladen hat, kann die Antwort des Benutzers integriert werden. Das System gibt dem Benutzer eine explizite Rückmeldung Okay und hat einen Plan geladen, welches das Verhalten des Systems steuert.[6]
Kritik
Kritisiert wird an TrindiKit, die langsame Geschwindikeit bei konkurrierenden Prozessen, die schlechte asynchrone Modifikation des Informationstate, die inkonsistente Semantik in GoDis und die fehlende Unterstützung von Multimodalität.[7]
Einzelnachweise
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management', 2005, S. 11-13
- ↑ [1], SICSTUS Prolog Homepage.
- ↑ Staffan Larsson, Peter Bohlin, Johan Bos, and David Traum. TrindiKit 1.0 manual. Deliverable D2.2, TRINDI Project, November 1999
- ↑ Staffan Larsson. 2002. Issue-based Dialogue Management. Ph.D. thesis, Göteburg University
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management, ' 2005, S. 16
- ↑ David R. Traum und Staffan Larsson. The Information State Approach to Dialogue Management, ' 2005, S. 18
- ↑ Burke, Carl and Harper, Lisa and Loehr, Dan A Flexible Architecture for a Multimodal Robot Control Interface ' 2002, S. 4
