Strategien für Dialogsegmente in natürlichsprachlichen Anwendungen

Universität Hamburg
Fachbereich Informatik
Strategien für
Dialogsegmente in
natürlichsprachlichen
Anwendungen
Stefan W. Hamerich
Diplomarbeit
betreut von
Prof. Dr. Walther von Hahn
AB Natürlichsprachliche Systeme
FB Informatik
Universität Hamburg
Hamburg
Dr. Carsten Günther
IBM Voice Systems
European Speech Research
IBM Deutschland Entwicklung GmbH
Heidelberg
20. Dezember 2000

Vertraulichkeitshinweis
Die vorliegende Arbeit unterliegt einer Geheimhaltungsvereinbarung mit der IBM. Die Arbeit
wurde von der IBM zur Veröffentlichung freigegeben, nachdem alle als IBM Vertraulich
klassifizierten Teile entfernt wurden. Bei Streichung von ganzen Abschnitten, wird dies in
der Arbeit kenntlich gemacht, ansonsten wurden einzelne Textpassagen entfernt, ohne den
Textzusammenhang zu verändern.

IV
VERTRAULICHKEITSHINWEIS

Vorwort
Bei vorliegender Arbeit handelt es sich um meine Diplomarbeit, die am Fachbereich Informatik
der Universität Hamburg vorgelegt wurde. Die Arbeit ist zum größten Teil in Heidelberg
bei der IBM European Speech Research entstanden, in enger Abstimmung mit Walther von
Hahn vom Arbeitsbereich Natürlichsprachliche Systeme (NatS) am Fachbereich Informatik
der Universität Hamburg.
Die Durchführung dieser Arbeit wäre ohne die Unterstützung zahlreicher Leute nicht möglich
gewesen, ich möchte mich daher an dieser Stellen sehr herzlich bei ihnen bedanken.
Ohne die Bereitschaft von Walther von Hahn, diese Arbeit zu unterstützen und zu betreuen,
wäre sie nicht entstanden. Er hat sich für die Genehmigung dieser ungewöhnlichen Arbeit
eingesetzt und gleichzeitig die Betreuung übernommen. Insbesondere möchte ich ihm für die
gute persönliche Betreuung danken, die bedingt durch die große Entfernung zu einem Großteil
auf elektronischem Wege lief. Ich möchte mich außerdem für das stete Entgegenkommen,
auch kurzfristig persönliche Treffen in Hamburg abzuhalten, sehr bedanken.
Herzlich bedanken möchte ich mich auch bei Carsten Günther, der mir die Durchführung
dieser Arbeit bei der IBM ermöglicht hat. Auch er war ständig für mich erreichbar und
unterstützte mich, wo er konnte. Außerdem gab er mir die Gelegenheit, die allgemeine Arbeit
bei der IBM mitzuverfolgen und ermöglichte mir damit einige sehr interessante Einblicke.
Mein besonderer Dank gilt Marion Mast von der IBM. Sie unterstützte mich bei der Erstellung
dieser Arbeit über das übliche Maß hinaus und fungierte somit quasi als Drittbetreuerin
meiner Arbeit. Mein Dank gilt ihr nicht nur für die praktische Unterstützung während der
Implementationsphase, sie versorgte mich auch reichlich mit Literatur und Tips für die
vorliegende Arbeit.
Ich möchte mich auch sehr für die allgemeine Unterstützung des gesamten Teams der IBM
European Speech Research in Heidelberg bedanken. Sowohl in allgemeinen Fragen, wie auch
in speziellen Problemfällen zeigten sich die einzelnen Mitglieder immer interessiert und offen
mir gegenüber. Insbesonders möchte ich mich bei Jochen Friedrich, Martin Herzog, Siegfried
Kunzmann, Thomas Roß, Henrik Schulz und Bernhard Zeller bedanken. Ein weiterer Dank
an Kornelia Artmeyer, Wolfgang Karbstein und René Werth für die Herstellung des Kontakts
nach Heidelberg.
Insbesondere für das angenehme Klima und die vielen kleinen Hilfen möchte ich mich bei
den Studenten der Abteilung bedanken, mein Dank gilt dabei vor allem Markus Dreyer,
Markus Klehr und Christian Weiß. Außerdem geht ein großes Dankeschön an Katja Schlee,
die den Classer und Parser von ShopTel stark verbesserte. Mein spezieller Dank geht an
Jan Leimeister, der ebenfalls bei der IBM an seiner Diplomarbeit geschrieben hat. Er hatte

VI
VORWORT
immer ein offenes Ohr für meine Fragen, trotz des immer näher rückenden Abgabetermins
seiner eigenen Arbeit. Die Zusammenarbeit war sehr lehr- und hilfreich.
Auch Jens-Uwe Möller gebührt ein Dankeschön für die Zurverfügungstellung seiner Dissertation
und der zugehörigen Literatur. Beides hat mir sehr viele Anregungen für den Inhalt
dieser Diplomarbeit gegeben.
Die Erstellung dieser Arbeit in Heidelberg wurde jedoch auch von ganz anderer Seite unterstützt.
Insbesondere für die engagierte Hilfe bei meiner mehrmaligen Zimmersuche möchte
ich mich daher bei Eva-Maria Fridrich und Rebekka Metzinger bedanken. Für meine zwischenzeitliche
Beherbung geht außerdem ein großes Dankeschön an Tim Gollisch und Andreas
Schäfer, schließlich möchte ich mich bei Fatima von Holtey vom Feriendienst des AMH
ausdrücklich bedanken. Ohne Euch alle hätte ich wohl doch unter einer Neckarbrücke schlafen
müssen...
Desweiteren möchte ich mich an dieser Stelle bei den Bewohnern des Albertus-Magnus-Heims
bedanken, insbesondere für die jeweilige Unterstützung bei Markus Fuchs, Hoang Nguyen,
Alex Notz und Manuel Ritter. Ein weiteres Dankeschön geht an die Heimleitung.
Ein Dank für ihre Unterstützung und hilfreichen Kommentare geht an Martin Glockemann,
Henrik Heine und Susanne Jekat vom AB NatS. Susanne Walther aus Heidelberg gebührt
Dank für ihre engagierte Literaturrecherche. Außerdem bedanke ich mich für die Hilfestellung
u.a. in TEXnischen Fragen bei Kay Kröger aus Barsbüttel.
Schließlich danke ich allen Testbenutzern, die mein System ausprobiert und bewertet haben,
mich häufig mit Feedback versorgten und einige frustierende Erfahrungen mit der Technik
sammeln konnten. Ohne die aus den Rückmeldungen gewonnen Erkenntnisse hätte ich
ShopTel nicht so weit gebracht.
Ein ganz besonderer Dank geht an Sandra Ranft, die diese Zeit zwischen Hamburg und
Heidelberg mit mir zusammen ausgehalten hat, mich sehr stark unterstützt hat und auch
immer ein kritisches Auge auf die Arbeit hatte.
Und schlußendlich möchte ich meinen Eltern danken, ohne die diese Arbeit in vielfältiger
Hinsicht nicht zustandegekommen wäre. Vielen Dank!
Barsbüttel, den 20. Dezember 2000
Stefan W. Hamerich

Inhaltsverzeichnis
Vertraulichkeitshinweis
III
Vorwort
V
Inhaltsverzeichnis
VII
Abbildungsverzeichnis
XI
Abkürzungsverzeichnis
XIII
Tabellenverzeichnis
XVII
1 Einleitung 1
1.1 Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Einführung in die Dialogtheorie 5
2.1 Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Einheiten in Dialogen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Dialogeinheiten aus Performanzsicht . . . . . . . . . . . . . . . . . . . 6
2.2.2 Dialogeinheiten aus Systemsicht . . . . . . . . . . . . . . . . . . . . . 7
2.3 Dialogstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Dialogmodell und -steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5 Dialogstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

VIII
INHALTSVERZEICHNIS
3 Grundlagen von Dialogsystemen 15
3.1 Dialogsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Komponenten eines Dialogsystems . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Spracheingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.2 Spracherkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.3 Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.4 Dialogkontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.5 Hintergrundsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.6 Antwortgenerierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.7 Sprachsynthese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.8 Sprachausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Konstruktion von Dialogsystemen . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.2 Dialogmaterial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.3 Parsingkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.4 Dialogkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.5 Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.6 Ein- und Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4 Dialogsysteme im Überblick 25
4.1 Auskunftssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1 SPICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1.2 SUNDIAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1.3 TABA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.4 Dialogos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.5 EVAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.6 JUPITER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.7 ISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Aktionssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.1 TRAINS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Carnegie Mellon Communicator . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Übersetzungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 JANUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.2 VERBMOBIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Vergleich der verschiedenen Systeme . . . . . . . . . . . . . . . . . . . . . . . 37

INHALTSVERZEICHNIS
IX
5 SHOPTEL 39
5.1 Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Szenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1 Telefonie-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.2 Spracherkenner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.3 TTS-Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.4 IVR-Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.5 Backend und Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.6 Grundlagen der NLU-Tools . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.7 NLU ControlCenter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.8 Parsing in den NLU-Tools . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3.9 Classer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.10 Canonicalizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.11 Dialogverarbeitung in den NLU-Tools . . . . . . . . . . . . . . . . . . 49
5.3.12 Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.3.13 Dialogmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.4 Konstruktion des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.1 Spezifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.4.2 Dialogmaterial und Parsingkomponente . . . . . . . . . . . . . . . . . 53
5.4.3 Dialogkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4.4 Backend und Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.5 Ein- und Ausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.4.6 Konstruktionsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 Evaluation des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.5.1 Performanzevaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.5.2 Benutzerevaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

X
INHALTSVERZEICHNIS
6 Dialogsegmente für Shopping-Anwendungen 61
6.1 Menschliche Dialoge im Telefonmarketing . . . . . . . . . . . . . . . . . . . . 61
6.2 Dialogsegmente in SHOPTEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Forms in SHOPTEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.3.1 Form INIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3.2 Weitere Forms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.4 Strategien für SHOPTEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4.1 Strategien in SHOPTEL . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.4.2 Alternative Strategien . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.4.3 Graphical ControlCenter . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
7 Ausblick 77
A IBM Tools für Telefoniesysteme 79
A.1 IBM ViaVoice Telephony Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . 79
A.2 IBM ViaVoice Telephony Natural Language Tools . . . . . . . . . . . . . . . 79
B SHOPTEL 81
B.1 Beispieldialoge mit SHOPTEL . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.1.1 Dialog I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
B.1.2 Dialog II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
B.1.3 Dialog III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
B.2 Vergebene Tags und Labels in SHOPTEL . . . . . . . . . . . . . . . . . . . . 87
B.3 Performanzevaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.4 Fragebogen zur Evaluation von SHOPTEL . . . . . . . . . . . . . . . . . . . 88
B.5 Auswertung des Fragebogens . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Literaturverzeichnis 91
Erklärung nach § 23 IX DPO 99

Abbildungsverzeichnis
2.1 Ausgewählte Dialogakte aus VERBMOBIL . . . . . . . . . . . . . . . . . . . . . 8
2.2 Verschiedene initiale Systemprompts von NJFun . . . . . . . . . . . . . . . . 11
2.3 Beispiel eines Mensch-Maschine-Dialogs . . . . . . . . . . . . . . . . . . . . . 12
2.4 Dialogmodell für Beispieldialog . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1 Die Benutzeroberfläche von VERBMOBIL . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Architektur von ShopTel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2 Beispielbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Beispieläußerung für eine Bestellung mit ShopTel . . . . . . . . . . . . . . . . 47
5.4 Klassifizierte Beispieläußerung für Bestellung mit ShopTel . . . . . . . . . . . 48
5.5 Baum der klassifizierten Beispieläußerung . . . . . . . . . . . . . . . . . . . . 48
5.6 Beispieläußerungen für Bestellungen mit ShopTel . . . . . . . . . . . . . . . . 48
5.7 Parse-Tree der klassifizierten Beispieläußerung . . . . . . . . . . . . . . . . . 50
5.8 Parse-Tree von liefern sie bitte in die STREET NUM in NUM CITY“ ”
. . . . 50
5.9 Attribut-Wert-Paar der Beispieläußerung . . . . . . . . . . . . . . . . . . . . 52
5.10 Beispieldialog für die Systemevaluation (ohne Systemäußerungen) . . . . . . 57
6.1 Form INIT (gekürzt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2 Der Slot PRODUCT (Ausschnitt aus dem Form LIST) . . . . . . . . . . . . . . 68
6.3 Grobes Dialogmodell für Bestelldurchgang eines bekannten Benutzers . . . . 71
6.4 Ansicht des gCC mit MAINMENU von ShopTel . . . . . . . . . . . . . . . . . 72
6.5 Ansicht des gCC mit PAYMENT von ShopTel . . . . . . . . . . . . . . . . . . 73
A.1 Architektur des IBM ViaVoice Telephony Toolkit mit NLU-Tools . . . . . 80
B.1 Fragebogen zur Evaluation von ShopTel (erste Seite) . . . . . . . . . . . . . . 88
B.2 Fragebogen zur Evaluation von ShopTel (zweite Seite) . . . . . . . . . . . . . 89

XII
ABBILDUNGSVERZEICHNIS

Abkürzungsverzeichnis
A/D
AI
ASR
AT&T
Analog/Digital
Artificial Intelligence
Automatic Speech Recognition
American Telephone & Telegraph Corporation (New York – USA)
ATR Advanced Telecommunications Research Institute International (Kyoto –
Japan)
AWP
BMBF
BMFT
BULM
CFG
cmp-lg
CMU
CoRR
cs.AI
cs.CL
cs.DL
CSELT
CSLI
DB
DM
DFKI
DiaMoLE
DS
Attribut-Wert-Paar
Bundesministerium für Bildung, Wissenschaft, Forschung und Technologie
(Bonn + Berlin)
Bundesministerium für Forschung und Technologie (Bonn; heute BMBF)
bottom-up leftmost
Context-Free Grammar
The Computation and Language E-Print Archive
(http://www.arxiv.org/cmp-lg)
Carnegie Mellon University (Pittsburgh – USA)
The Computing Research Repository (http://www.arxiv.org/archive/cs/)
,Artificial Intelligence‘-Archiv des CoRR
,Computation and Language‘-Archiv des CoRR (Nachfolger von cmp-lg)
,Digital Libraries‘-Archiv des CoRR
Centro Studi e Laboratori Telecommunicazioni (Turin – Italien)
Center for the Study of Language and Information (Stanford – USA)
Database
Dialogue Manager
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
(Kaiserslautern + Saarbrücken)
Dialogue Model Learning Environment (Systemumgebung – U Hamburg)
Dialogue System

XIV
ABKÜRZUNGSVERZEICHNIS
DTMF
ELOQUENS
ESCA
Dual Tone Multi-Frequency
TTS-Komponente des CSELT
European Speech Communication Association
EVAR Erkennen, Verstehen, Antworten und Rückfragen (Dialogsystem –
U Erlangen)
FDM
FORWISS
Form-Based Dialog Manager
Bayerisches Forschungszentrum für Wissensbasierte Systeme (Erlangen)
FränKi Fränkisches Kino-Informationssystem (Dialogsystem –
U Erlangen + FORWISS)
GALAXY
gCC
GUI
HMM
HPSG
IBM
IEEE
IPO
ISA
IVR
JANUS
JUPITER
KI
LM
MIT
MT
NJFun
NL
NLP
NLU
NLU-Tools
ODBC
OOV
PCFG
PHOENIX
Architekturmodell für Dialogsysteme vom MIT
graphical ControlCenter
Graphical User Interface
Hidden-Markov-Modell
Head-Driven Phrase Structure Grammar
International Business Machines Corporation (Armonk – USA)
Institute of Electrical & Electronics Engineers (New York – USA)
Institute of Perception Research (Eindhoven – Niederlande)
IBM Stau Applikation (IBM Deutschland)
Interactive Voice Response
Automatisches Übersetzungssystem (CMU + U Karlsruhe)
Auskunftssystem für Wetterberichte (MIT)
Künstliche Intelligenz
Language Model
Massachusetts Institute of Technology (Cambridge – USA)
Machine Translation
New Jersey Funplaces (Dialogsystem – AT&T)
Natural Language
Natural Language Processing
Natural Language Understanding
IBM ViaVoice Telephony Natural Language Tools
Open Database Connectivity
Out Of Vocabulary
Probabilistic Context-Free Grammar
Parser der CMU

ABKÜRZUNGSVERZEICHNIS
XV
POS
RC
SDS
SDU
SER
SIL
SMS
SPHINX
SPICOS
SQL
SR
SUNDIAL
TABA
Tcl
TRAINS
TRUETALK
TTS
U
Part Of Speech
Return Code
Spoken Dialogue System
Semantic Dialogue Unit
Slot Error Rate
Semantic Interface Language
Short Message Service
Spracherkenner der CMU
Siemens-Philips-IPO Continuous Speech Understanding and Dialog
(Dialogsystem)
Structured Query Language
Success Rate
Speech Understanding in Dialogue (Dialogsystem – u.a. CAP Gemini,
CSELT, Daimler-Benz, Siemens, U Erlangen, U Surrey – EU-Projekt)
Telefonische Automatische Bahnfahrplan-Auskunft (Philips)
Tool Command Language
Dialogsystem auf Güterzug-Domäne (U Rochester – USA)
TTS-Komponente der Firma Entropic
Text To Speech
Universität
VERBMOBIL Automatisches Übersetzungsystem (u.a. DaimlerChrysler, DFKI, Philips,
Siemens, U Erlangen, U Hamburg, U Karlsruhe, U des Saarlandes)
VTT
WER
WOZ
IBM ViaVoice Telephony Toolkit
Word Error Rate
Wizard Of Oz

XVI
ABKÜRZUNGSVERZEICHNIS

Tabellenverzeichnis
2.1 Sequenzen und Komponenten des Beispieldialogs . . . . . . . . . . . . . . . . 12
2.2 Segmente und Dialogakte des Beispieldialogs . . . . . . . . . . . . . . . . . . 13
4.1 Vergleich der vorgestellten Systeme . . . . . . . . . . . . . . . . . . . . . . . 38
5.1 nötige Arbeiten bei der Entwicklung von ShopTel . . . . . . . . . . . . . . . . 55
6.1 Slots im Form INIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

XVIII
TABELLENVERZEICHNIS

Kapitel 1
Einleitung
Das wichtigste Kommunikationsmittel des Menschen ist und bleibt seine Sprache. Daher
erscheint es nur logisch, sich auch in der Mensch-Maschine-Interaktion der natürlichen Sprache
zu bedienen, um dem Menschen einen möglichst natürlichen Umgang mit Maschinen
zu ermöglichen. In der zwischenmenschlichen Kommunikation ist der Dialog die vorherrschende
Kommunikationsform. Eine Verwirklichung dieses Konzepts in sprachsignalverarbeitenden
Systemen war lange Zeit nicht machbar, da die Schwierigkeiten, insbesondere
spontansprachliche Äußerungen zu erkennen, immens sind. Seit einiger Zeit ist es jedoch
dank der stetig fortschreitenden technischen Entwicklung und der immer weiter wachsenden
Rechenkapazität möglich, realitätsnahe Dialoge in gesprochen-sprachlichen Systemen sinnvoll
zu verarbeiten. Als Beispiele hierfür seien das System SPICOS (siehe z.B. [Niedermair
1987; Niedermair 1992]), das System EVAR (siehe u.a. [Ehrlich et al. 1992; Gallwitz et al.
1998]) und der Forschungsprototyp VERBMOBIL (vgl. z.B. [Wahlster 1993a; von Hahn und
Amtrup 1996; Wahlster 1997; Wahlster 2000]) erwähnt.
Um Sprachsignale in gesprochen-sprachlichen Systemen verarbeiten zu können, werden Mikrofone
eingesetzt. Dabei sind grundsätzlich verschiedene Arten von Mikrofonen denkbar,
über die ein gesprochen-sprachliches System seine Eingaben erhalten kann. Insbesondere für
Dialogsysteme bieten sich beispielsweise Kopfbügelmikrofone (engl. headset) an, die auch in
mobilen Umgebungen eingesetzt werden können. Doch auch die gewohnte Nutzung bereits
aus dem Alltag bekannter Geräte, wie dem Telefon, stellt eine sinnvolle Alternative dar.
Zudem ermöglicht die starke Verbreitung von Mobiltelefonen eine einfache und praktische
Benutzung von gesprochen-sprachlichen Systemen in jeder Situation.
Telefonanwendungen stellen eine besondere Schwierigkeit für gesprochen-sprachliche Systeme
dar, da die Sprachsignalverarbeitung stark unter der geringen Bandbreite im Telefonkanal
leidet. Zusätzlich können häufig Kanalstörungen die Sprachqualität stark verschlechtern 1 .
Trotz dieser Einschränkungen sind Telefonanwendungen seit den 90er Jahren immer häufiger
im Einsatz (siehe u.a. [Albesano et al. 1996; Aust und Schröer 1998b; Crestani 1998; Grävemeyer
1998; Grävemeyer 1999a]). Dies liegt vor allem an der stetig steigenden Qualität
der Spracherkenner, deren Erkennungsraten bei Sprachdaten aus Telefonleitungen in den
letzten Jahren kontinuierlich verbessert wurden, und der mit dieser verbesserten Qualität
einhergehenden Verbreitung der Dialogsysteme. 2
1 Eine frühe Schilderung dieser Probleme findet sich in [Ney 1982].
2 Zur näheren Darstellung der Spracherkennung in Telefoniesystemen siehe insbesondere [Albesano et al.
1996; Günther et al. 2000].

2 KAPITEL 1. EINLEITUNG
1.1 Problemstellung
Das Ziel der vorliegenden Arbeit bestand in der Findung von passenden Dialogsegmenten
und auf diesen fußenden Strategien in einem Dialogsystem mit gegebener Softwareumgebung.
Dabei sollten auch allgemeine Segmente und Strategien herausgearbeitet werden. Zu diesem
Zweck mußte zuerst ein System entworfen und implementiert werden, das einen Dialog in
gesprochener Sprache mit einem Benutzer erlaubt. Dieses System wurde als Telefonanwendung
ausgeführt und mit Hilfe der IBM ViaVoice Telephony Natural Language Tools
(vgl. u.a. [Davies et al. 1999; Papineni et al. 1999; Mast et al. 2000]) implementiert, welche
auf der IBM-Spracherkennungstechnologie aufbauen, die heute als IBM ViaVoice (siehe z.B.
[Bahl et al. 1993]) auch als Desktop-Produkt erfolgreich vermarktet wird. 3
Als Anwendungsdomäne des im Rahmen dieser Arbeit zu entwickelnden Systems wurde
die Bestellannahme eines Versandhandels gewählt, um die in einer so vielfältigen Umgebung
existierenden verschiedenen Dialoge herauszustellen. Diese Vielfältigkeit wird noch verstärkt
durch die Wahl von verschiedenen Produktkategorien, da die, in dieser Auswahl begründeten,
unterschiedlichen Granularitäten und Einheiten zu einer großen Vielfalt an lexikalischen,
syntaktischen und semantischen Strukturen beitragen.
Das entstandene System wurde auf Grund seiner Domäne und seines Eingabekanals ShopTel
genannt, es sollte mit dem System möglich sein, verschiedene Produkte einfach zu bestellen.
Dies war durch sinnvolle Anordnung der entsprechenden Dialogsegmente sicherzustellen, die
garantieren, daß dieser Bestellvorgang möglichst natürlich implementiert wurde, ohne einen
Benutzer bei einer Bestellung zu stark im Dialogverhalten zu beeinflussen. Gleichzeitig war
jedoch auf die stete Erreichbarkeit des Dialogzieles zu achten. Der Umgang sollte sowohl
erfahrenen, als auch ungeübten Benutzern möglich sein. ShopTel wurde aus diesem Grund
während der Erstellung dieser Arbeit laufend überwacht und aufgetretene Fehler wurden
dabei teilweise beseitigt. Trotz dieser laufenden Verbesserungen kann das System nur als
Prototyp angesehen werden.
Abschließend wurde ShopTel auf Dialogsegmente und Strategien für diese untersucht. Dabei
wurden unterschiedliche, teilweise alternative, Strategien betrachtet. Um Dialogsegmente
in Dialogsystemen möglichst einfach bearbeiten zu können, wurde eine Systemumgebung,
namens graphical ControlCenter (gCC) erstellt, welche die verschiedenen Aktionen eines
Dialogsystems analysiert und abbildet. Gleichzeitig sollte es mit dieser Umgebung möglich
sein, unter Beachtung der Konsistenz des Gesamtsystems, unterschiedliche Strategien für
Segmente in Dialogsystemen zu aktivieren.
Das graphical ControlCenter wurde nicht nur für ShopTel erstellt. Es ist komplett anwendungsunabhängig,
um damit auch weitere Dialogsysteme analysieren zu können.
Die Betrachtung der verschiedenen Dialogsegmente erfolgte auch mit dem Hintergedanken, es
für die Zukunft zu ermöglichen, auf der Basis eines Grundgerüsts ein ”
Natürlichsprachliches
System“ schnell in einer konkreten Domäne zur Anwendung zu bringen. Zum Beispiel sollte
eine Anwendung schnell für einen anderen Anbieter angepaßt werden können oder eine
einfache Erweiterung bestehender Systeme möglich gemacht werden.
3 Spracherkennung wird bei der IBM schon seit einiger Zeit als Forschungsgegenstand gesehen, das hat dazu
geführt, daß bereits 1986 der erste experimentelle Spracherkenner für einen PC vorgestellt werden konnte
(siehe [Averbuch et al. 1986]).

1.2. VORGEHENSWEISE 3
1.2 Vorgehensweise
Die Arbeit ist in 7 Kapitel gegliedert, der Inhalt der einzelnen Kapitel wird im folgenden
kurz erläutert.
Zuerst müssen, um in dieser Arbeit auf Dialogsysteme und -segmente eingehen zu können,
die grundlegenden Begriffe, auf denen diese Betrachtung beruht, eingeführt werden. Daher
wird in Kapitel 2 auf die notwendigen Termini der Dialogtheorie eingegangen, insbesondere
auf die Begriffe Dialog, Dialogmodell und Dialogstruktur. Außerdem wird der für diese Arbeit
grundlegende Terminus des Dialogsegments eingeführt und erklärt.
Aufbauend auf dem Begriff des Dialogs erfolgt in Kapitel 3 eine Beschreibung der Grundlagen
von Dialogsystemen. Dafür wird zuerst der Begriff Dialogsystem für diese Arbeit definiert
und äquivalent zum englischen Begriff conversational system der Terminus Konversationssystem
eingeführt. Desweiteren werden die Komponenten eines allgemeinen Dialogsystems
näher dargestellt und abschließend die Konstruktion eines solchen Systems beschrieben, wobei
auch auf die Schwierigkeiten eines solchen Prozesses eingegangen wird.
Nach der Klärung des Begriffs Dialogsystem und der Vorstellung eines allgemeinen Systems
in Kapitel 3 erfolgt in Kapitel 4 ein Überblick über bereits vorhandene Dialogsysteme, um
das Umfeld des im Rahmen dieser Arbeit entstandenen Systems darzustellen. Das Kapitel ist
in die Abschnitte Auskunftssysteme, Aktionssysteme und Übersetzungssysteme untergliedert,
in denen verschiedenste Systeme einander gegenübergestellt werden.
Schließlich wird in Kapitel 5 auf das im Rahmen dieser Arbeit entstandene System SHOPTEL
eingegangen. Hier werden die verschiedenen Komponenten des Systems erklärt, soweit sie
sich von den allgemeinen, in Kapitel 3 dargestellten, unterscheiden. Es wird auch auf die
Implementation und die Besonderheiten des Systems eingegangen. Desweiteren wird die
Systemevaluation beschrieben.
Kapitel 6 beschäftigt sich mit Dialogsegmenten, hier werden die aus ShopTel entwickelten
Dialogsegmente und Forms näher betrachtet und ihre Verwendbarkeit in weiteren Anwendungen
bewertet. Es wird zudem auf die Besonderheiten der Domäne von ShopTel eingegangen.
Außerdem wird die ebenfalls im Zuge dieser Arbeit erstellte Systemumgebung
graphical ControlCenter vorgestellt. Diese Umgebung ermöglicht eine anwendungsunabhängige
Analyse von Dialogsystemen, die mit den IBM ViaVoice Telephony Natural
Language Tools erstellt worden sind. Es ist damit auch möglich, verschiedene Dialogsegmente
schnell in einem System zum Einsatz zu bringen.
Abschließend erfolgt in Kapitel 7 ein Ausblick auf weitere Möglichkeiten und Entwicklungen
in diesem Gebiet.
Im Anhang werden die beiden Basiswerkzeuge von ShopTel, das IBM ViaVoice Telephony
Toolkit und die IBM ViaVoice Telephony Natural Language Tools näher beschrieben.
Desweiteren werden einige Dialoge mit ShopTel wiedergegeben, die auch für die Evaluation
benutzt wurden. Auch der Fragebogen für die Benutzerevaluation ist im Anhang abgebildet.

4 KAPITEL 1. EINLEITUNG

Kapitel 2
Einführung in die Dialogtheorie
In diesem Kapitel werden die für diese Arbeit essentiellen Begriffe der Dialogtheorie 1 eingeführt
und erklärt. Auf eine formelle linguistische Betrachtung der entsprechenden Termini
soll im folgenden allerdings verzichtet werden. Vielmehr steht eine kurze begriffliche
Einführung im Vordergrund, ohne dabei auf die Besonderheiten des IBM-Systems einzugehen.
Die Behandlung eines Dialogs in ShopTel ist daher Bestandteil der Abschnitte 5.3.6 ff.
2.1 Dialog
Um Dialogsegmente in dieser Arbeit behandeln zu können, bedarf es zuerst einer grundsätzlichen
Definition und Einordnung des Begriffs ”
Dialog“ (engl. dialogue; amer. dialog). Laut
[Drosdowski 1990] ist ein Dialog ein Gespräch, das zwischen zwei Gruppierungen geführt
wird, um sich und die gegenseitigen Standpunkte kennenzulernen oder eine von zwei Personen
abwechselnd geführte Rede und Gegenrede. [Lewandowski 1979] definiert einen Dialog als
partnerbezogenes Zwiegespräch, eine Form der interaktionalen Kommunikation, bei der thematisch
und/oder situativ bestimmte, intentional gesteuerte Äußerungen an einen Partner
gerichtet und beantwortet werden. In [Bunt 1989] wird ein information dialogue eingeführt,
der eine zweckgebundene, sprachliche Handlung bezeichnet, die der Übertragung oder dem
Erhalt von Informationen dient. [Niedermair 1992] sieht einen Dialog als ein Frage-Antwort-
Schema an, das die Möglichkeit beinhaltet, unentscheidbare Fragen mit einem Dialogpartner
zu klären, auch mit Bezug auf bereits getätigte Äußerungen. Schließlich wird in [Schmitz
1997] ein Dialog als soziale Interaktion beschrieben, die durch zwei wichtige Prinzipien bestimmt
ist: wechselseitige Initiative und Kooperation.
In der vorliegenden Arbeit soll in Anlehnung an [Möller 1999] unter einem Dialog eine
zielorientierte Interaktion zwischen zwei Partnern verstanden werden. Diese Interaktion muß
im Sinne von Möller nicht notwendigerweise rein sprachlicher Natur sein. Die Interaktion mit
einem System durch die ausschließlich taktile Bedienung von Menüs kann somit ebenfalls
als Dialog angesehen werden. 2 In dieser Arbeit wird unter einem Dialog grundsätzlich eine
1 In der allgemeinen Linguistik werden Dialoge als eine Sonderform des Gesprächs angesehen und ihre
Betrachtung damit als Teil der Gesprächsanalyse verstanden (vgl. u.a. [Linke et al. 1994]). Da bei den in
dieser Arbeit vorgestellten sprachgesteuerten Systemen aber nur Gespräche zwischen zwei Partnern möglich
sind, soll im folgenden der Terminus ”
Dialog“ als gleichberechtigt zum ”
Gespräch“ angesehen werden.
2 Siehe dazu z.B. [Hamerich 1999].

6 KAPITEL 2. EINFÜHRUNG IN DIE DIALOGTHEORIE
sprachliche Interaktion entweder zwischen Menschen oder zwischen einem (menschlichen)
Benutzer und einem System verstanden. Dies wird auch in Definition 2.1 wiedergegeben.
Definition 2.1 Ein Dialog ist eine zielorientierte sprachliche Interaktion zwischen zwei
Partnern. Er besteht aus Untereinheiten, die einer Dialogstruktur folgen.
Eine solche sprachliche Interaktion basiert in einem gesprochen-sprachlichen Dialog auf einer
Menge von sprachlichen Äußerungen zweier Partner. Die Äußerung wird im folgenden
definiert.
Definition 2.2 Als Äußerung wird der Beitrag eines Gesprächsteilnehmers zu einem Dialog
bezeichnet. Eine Äußerung wird durch einen Sprecherwechsel begrenzt.
Im folgenden Abschnitt werden die verschiedenen Untereinheiten eines allgemeinen Dialogs
vorgestellt und eingeführt. Dabei wird vor allem darauf geachtet, die Systemsicht der Performanzsicht
gegenüberzustellen und diese Trennung möglichst deutlich zu machen.
2.2 Einheiten in Dialogen
Die oberste Betrachtungsebene dieser Arbeit, sowohl im System wie auch aus Benutzersicht,
ist der Dialog. Der Dialog wird jedoch aus Performanzsicht als eine Menge von sprachlichen
Äußerungen begriffen, während er aus der Systemsicht vornehmlich dem Erreichen eines
Dialogziels dient. Aus dieser Unterscheidung folgen verschiedenen Einheiten eines Dialogs.
Auf diese Einheiten der jeweiligen Sichten wird daher in den beiden folgenden Abschnitten
näher eingegangen.
2.2.1 Dialogeinheiten aus Performanzsicht
Bei der Betrachtung der Einheiten eines Dialogs aus Performanzsicht dienen gesprochene
Dialoge als Datengrundlage. Im allgemeinen wird ein Dialog in drei Phasen unterteilt (siehe
z.B. [Mast 1993; Linke et al. 1994]). Dabei werden eine Einleitungsphase, ein Haupteil und
eine Schlußphase unterschieden. Diese Unterteilung ist allerdings sehr grob, um eine feinere
Unterteilung vornehmen zu können, wurde in [Jekat-Rommel 1994] ein gesprochener Dialog
in verschiedene Sequenzen unterteilt. Eine Sequenz wird dabei als zusammengehöriger Teil
eines Dialogs angesehen und besteht aus mindestens zwei Komponenten. Eine Komponente
wird dabei laut Jekat-Rommel als konstituierender Teil einer Sequenz mit einem bestimmten
Inhalt und verschiedenen sprachlichen Realisationsmöglichkeiten angesehen. Die Komponenten
selber bestehen aus inhaltlich zusammenhängenden Äußerungen 3 eines Sprechers. Diese
stellen somit die Basiseinheiten eines Dialogs aus der Performanzsicht dar. Eine weitergehende
Betrachtung von Äußerungen soll in dieser Arbeit allerdings nicht erfolgen. In Definition
2.3 sind diese Zusammenhänge noch einmal dargestellt.
Definition 2.3 Ein Dialog besteht aus Performanzsicht aus Sequenzen. Eine Sequenz ist
ein inhaltlich zusammengehöriger Teil eines Dialogs und besteht aus Komponenten, die sich
aus Äußerungen zusammensetzen. Jede Sequenz erfüllt ein anderes Teilziel eines Dialogs,
wobei in einem abgeschlossenen Dialog die Summe der einzelnen Teilziele das Dialogziel
enthält.
3 Vgl. Definition der Äußerung in Def. 2.2.

2.2. EINHEITEN IN DIALOGEN 7
Die Reihenfolge der Sequenzen ist in [Jekat-Rommel 1994] für einige VERBMOBIL-Dialoge verglichen
worden und es wurde festgestellt, daß sie stets gleich ist, während bei Komponenten
eine gewisse Variation innerhalb der einzelnen Sequenzen festgestellt wurde. Der Vorteil dieser
Unterteilung wurde vor allem darin gesehen, daß durch die feste Ordnung der Sequenzen
registriert werden kann, ob beim Übergang von einer Sequenz in die nächste alle notwendigen
Informationen für eine Sequenz geliefert worden sind. Dieses Modell stellt damit die
Basis für Dialogmanager dar (siehe Abschnitt 3.2.4).
In VERBMOBIL (siehe Abschnitt 4.3.2) wurden u.a. folgende Sequenzen herausgearbeitet:
Begrüßgung, Vorstellung, Grund einer Terminabsprache, Entscheidung, etc. (siehe [Jekat-
Rommel 1994]). Aus diesen Sequenzen ist ersichtlich, daß deren Definition domänenabhängig
ist. Sequenzen mit ihren jeweiligen Komponenten können in verschiedenen Domänen vollkommen
unterschiedlich repräsentiert werden.
In dieser Arbeit möchte ich das Konzept der Komponenten und Sequenzen übernehmen,
allerdings verstehe ich die Sequenz in ihrer Granularität etwas feiner als bei Jekat-Rommel.
Sequenzen werden hier ebenfalls mit den entsprechenden Inhalt repräsentierenden Namen
versehen und können auch nur aus einer einzigen Dialogkomponente bestehen. Dies wird
anhand eines Beispiels in Abschnitt 2.6 illustriert.
2.2.2 Dialogeinheiten aus Systemsicht
Auch bei Dialogsystemen wird der Dialog als Betrachtungsgegenstand angesehen. Dieser
steht damit ebenfalls in der obersten Betrachtungsebene und bedarf somit gleichfalls einer
weiteren Unterteilung. Bevor jedoch Einheiten eines Dialogs aus Systemsicht beschrieben
werden können, müssen bestimmte Rahmenbedingungen für ein Dialogsystem erfüllt sein.
So müssen beispielsweise die Domäne, der Aufgabenbereich des Systems, der Systemtyp
und das Dialogziel definiert werden. Wenn dieses Dialogziel in kleinere Einheiten unterteilt
werden kann, können Dialogeinheiten aus Systemsicht bestimmt werden.
Eine Bestimmung dieser Einheiten ist jedoch nur dann sinnvoll, wenn für die Domäne des
vorliegenden Dialogsystems auch verschiedene Sequenzen von möglichen Benutzern vorliegen.
Ein solcher Fall liegt beispielsweise bei dem dieser Arbeit zugrundeliegenden System
ShopTel vor. Eine Bestellung (Dialogziel) zerfällt bei diesem System in verschiedene Sequenzen
(z.B. Anmeldung, Auswahl, Bezahlung, etc.). Zu diesen Sequenzen aus Benutzersicht
bedarf es einer Einheit im Dialog aus Systemsicht, um diese im System gegeneinander
abzugrenzen und somit deren erfolgreiche Abarbeitung in einem Dialogsystem in einer bestimmten
Reihenfolge zu gewährleisten.
Diese Einheit modelliert in einem Dialogsystem als Äquivalent zur Sequenz einen zusammengehörigen
Teil in einem Dialog und bildet somit eine Sequenz mit ihren jeweiligen Komponenten
in einem Dialogsystem ab. Aus Mangel an bisherigen Ergebnissen auf diesem Gebiet,
habe ich diese Einheit Dialogsegment genannt. Dieses wird im folgenden definiert.
Definition 2.4 Wenn bei einem betrachteten Dialog für ein Dialogsystem mehrere Dialogsequenzen
vorliegen, können diese als Einheiten in einem Dialogsystem abgebildet werden.
Diese Abbildung wird Dialogsegment genannt. Ein Dialog besteht demnach aus Systemsicht
aus Dialogsegmenten, die sich jeweils in Dialogakte untergliedern.
Die Basiseinheit des Dialogs aus Systemsicht, der Dialogakt, steht der Äußerung als Basiseinheit
aus Benutzersicht gegenüber. Allerdings kann eine Äußerung auch mehrere Dialogakte

8 KAPITEL 2. EINFÜHRUNG IN DIE DIALOGTHEORIE
bezeichnen, wie auch ein Dialogakt aus mehreren Äußerungen bestehen kann. Der Dialogakt
wird vor allem definiert, um diesen Einheiten eine Semantik zuordnen zu können. Er wird
verwendet, um damit eine leichtere und differenziertere Verarbeitung der einzelnen Äußerungen
zu erreichen.
In der Theorie ist die Basiseinheit eines jeden Dialogsystems der Dialogakt, allerdings endet
vielfach die Sichtbarkeitsebene vor dieser Einheit, so daß in einigen Dialogsystemen keine
Dialogakte definiert werden. Statt dessen besteht jedoch die Möglichkeit, konkreten Beispieldaten
eine Semantik zuzuordnen. Dieses Vorgehen bietet sich vor allem für Domänen
an, die keine sehr differenzierte Betrachtung einzelner Äußerungen benötigen, dagegen ist es
in Übersetzungssystemen fast unerläßlich, Dialogakte einzuführen.
Da ShopTel nicht auf Dialogeinheiten im klassischen Sinne beruht, dient die Einführung
dieser im folgenden nur dem besseren Verständnis einzelner, in Kapitel 4 vorgestellter, Dialogsysteme,
die auf Dialogakte zurückgreifen.
Wenn ein Dialogsystem auf diesen Dialogeinheiten beruht, werden diese als Basiseinheiten
angesehen und als Sprech- oder Dialogakte (vgl. u.a. [Bunt 1981; Mast 1993]) bezeichnet. Ein
Dialog besteht somit aus einer Folge von Dialogakten, die als kleinste beschreibende Einheit
von Dialogen definiert werden (siehe z.B. [Alexandersson et al. 1995; Jekat et al. 1995; Mast
et al. 1996]).
Da Dialogakte immer sehr von der Umgebung des Systems, in dem sie verwendet werden,
abhängen, gibt es keine allgemeingültigen Dialogakte. Einen allgemeinen Überblick über
Dialogakte in verschiedenen Systemen gibt [Möller 1999]. Auf Abbildung 2.1 werden einige
ausgewählte Dialogakte dargestellt, die im Rahmen des Verbundvorhabens VERBMOBIL in
der Domäne ”
Terminvereinbarung“ definiert wurden.
accept
bye
commit
greet
init
introduction
reject
suggest
explizite Akzeptanz eines Vorschlages
Verabschiedung eines Dialogpartners vom anderen
explizite Annahme eines Vorschlages
Begrüßung eines Dialogteilnehmers
Einführung des Themas
Vorstellung der eigenen Person
Ablehnung eines Vorschlages
expliziter Vorschlag in aktueller Domäne
(nach [Jekat et al. 1995; Alexandersson et al. 1997; Alexandersson et al. 1998])
Abbildung 2.1: Ausgewählte Dialogakte aus VERBMOBIL
Die hier eingeführten Begriffe und Zusammenhänge werden in Abschnitt 2.6 an einem Beispiel
verdeutlicht.
Die in diesem Abschnitt eingeführten Dialogeinheiten komplettieren den Begriff des Dialogs.
Daher wird im folgenden eine neue Definition für den Dialog wiedergegeben, die als
Erweiterung zu Definition 2.1 zu verstehen ist:
Definition 2.5 Ein Dialog ist eine zielorientierte sprachliche Interaktion zwischen zwei
Partnern. Er besteht aus Benutzersicht aus einer Folge von Sequenzen, die auf Äußerungen
basieren. Korrespondierend mit den Sequenzen besteht ein Dialog aus Systemsicht aus

2.3. DIALOGSTRUKTUR 9
einer Folge von Segmenten, basierend auf Dialogakten. Letztere korrespondieren mit den
Äußerungen.
Die Sequenzen und Segmente folgen der Dialogstruktur, die Bestandteil des Dialogmodells
ist.
Wie in Definition 2.5 beschrieben, wird für die Verarbeitung von Dialogen in einem Dialogsystem
eine Struktur benötigt, um nach einer Analyse eine Modellierung durchführen
zu können, die dann in einem System implementiert werden kann. Der folgende Abschnitt
beschäftigt sich daher mit der Strukturierung von Dialogen.
2.3 Dialogstruktur
Eine Dialogstruktur kann sowohl über bereits vorhandene Dialogdaten, als auch über einen
Dialog aus Systemsicht erstellt werden. Im folgenden wird allerdings von dieser Sicht abstrahiert
und es wird nur die allgemeine Erstellung einer Dialogstruktur betrachtet. Als
Dialogeinheiten werden demzufolge die entsprechenden Einheiten aus jeder Sicht angesehen.
In der Dialogstruktur sind die gesamten Regeln für den Ablauf eines Dialogs enthalten. Diese
Struktur ist zusammen mit den Dialogeinheiten wesentlicher Bestandteil des Dialogmodells
und stellt damit das Gerüst für die Dialogeinheiten dar. Für die Repräsentation der Dialogstruktur
existieren zwei Ansätze: Planbasierte Repräsentationen (vgl. z.B. [Allen et al.
1982]) und Diskursgrammatiken (siehe u.a. [Bunt 1989]). Es gibt aber auch die Möglichkeit,
beide Ansätze miteinander zu kombinieren, wie z.B. im System VERBMOBIL geschehen (vgl.
[Alexandersson et al. 1995]).
Üblicherweise wird ein Dialog in einem Dialogsystem auf einem Dialogmodell definiert und
über ein eigenes Systemmodul ausgewertet. Beides ist daher Thema des nächsten Abschnitts.
2.4 Dialogmodell und -steuerung
Das Dialogmodell ist die Basis eines Dialogs und beschreibt die erwarteten Äußerungen
von einzelnen Dialogteilnehmern (vgl. [Jekat et al. 1995]). Folglich kann man ein Dialogmodell
auch als Wissensbasis einer Dialogsteuerung in einem Dialogsystem beschreiben. Im
allgemeinen ist ein solches Modell aus Dialogakten, Dialogstrukturen und einer Interpretationsvorschrift
aufgebaut.
Die Aufgabe eines solchen Modells in einem Dialogsystem ist nach [Möller 1999] die Beschreibung
des Dialogflusses in der Art, daß eine Benutzeräußerung sinnvoll von einer Dialogsteuerung
interpretiert und eine adäquate Reaktion darauf vom System initiiert werden
kann.
Die Dialogsteuerung besteht aus den Interpretationsvorschriften, die in das Dialogmodell
eingehen. Diese Interpretationsvorschriften sind über einzelnen Dialogeinheiten definiert,
anwendungsabhängig und dienen insgesamt dem Erreichen eines Dialogziels. Die Dialogsteuerung
ist meist als eigenes Systemmodul in einem Dialogsystem integriert und stellt in
diesem Fall die zentrale Steuerungseinheit eines Dialogsystems dar. Die Basis der Dialogsteuerung
ist das Dialogmodell.

10 KAPITEL 2. EINFÜHRUNG IN DIE DIALOGTHEORIE
2.5 Dialogstrategie
Strategien, die in einem Dialog angewendet werden, um ein Dialogziel besser und schneller zu
erreichen, werden Dialogstrategien genannt. Dabei können diese Strategien ganz allgemein
oder speziell im Kontext eines Dialogs bestimmt werden. Dialogstrategien werden auch von
menschlichen Dialogpartnern angewandt, beispielsweise kann ein Dialog freundlich, zielstrebig,
hastig oder umständlich geführt werden (siehe [Mast 1993]). Bei der Implementation
von Dialogstrategien ist es laut Mast allerdings sehr viel wichtiger, einen Dialog unter unterschiedlichen
Randbedingungen zu optimieren, als diese menschlichen Strategien zu realisieren.
[Möller 1999] ordnet Dialogstrategien in bestimmte Gruppen ein und bezeichnet eine Dialogstrategie
als den zugrundeliegenden Charakter der Interaktion von Dialogpartnern. Bei
Dialogsystemen bestimmt er eine Strategie durch das Systemverhalten (aktiv oder inaktiv)
und durch die Interaktionsart (direktiv, reaktiv, kooperativ oder konkurrierend) und
unterscheidet damit folgende grundsätzliche Dialogstrategien:
• Direktive Dialogstrategie liegt bei der Verwendung von Kommandosprachen vor. Dabei
ist das Systemverhalten meist passiv, das System wartet also auf Kommandos, die es
dann ausführt.
• Reaktive Dialogstrategie, auch als gesteuerter (engl. directed) Dialog bezeichnet. Bei
dieser Strategie folgt auf jede Frage genau eine Antwort. Informationssysteme, an
die ein Benutzer einfache Fragen stellen kann, sind dabei passive Varianten. Bei der
Verwendung von Kommandos liegt allerdings eine direktive Strategie vor.
• Kooperative Dialogstrategie zeichnet sich durch eine Mischung von aktiven und passiven
Phasen aus, beide Dialogpartner können also die Initiative übernehmen (siehe
z.B. [Walker et al. 1997]). Allerdings müssen in diesem Fall immer die Benutzerabsichten
erkannt werden, dazu sollte auch eine Überbeantwortung von Fragen im System
verarbeitet werden können.
• Konkurrierende Dialogstrategie, bei dieser Strategie wollen beide Dialogpartner ein Ziel
gegenüber dem jeweilig anderen durchsetzen. Dafür ist auch eine Verhandlung mit dem
Dialogpartner nötig.
Eine Dialogstrategie kann zusätzlich auch robust sein (siehe [Mast 1993]), diese Strategie
stellt für gewisse relevante oder auch alle Daten, die der Spracherkenner liefert, Bestätigungsanfragen.
Dies ist vor allem bei einer schlechten Spracherkennung sinnvoll, insbesondere
wenn eine eventuelle Nachfrage von der Bewertung des Spracherkenners abhängt. 4
In [Denecke und Waibel 1997] wird eine Dialogstrategie als Sequenz von Aktionen definiert,
deren Ende genau ein Kommunikationsziel trifft. Dieses Ziel (engl. communicative goal) wird
dabei durch eine Feature-Struktur spezifiziert. Solange diese Struktur unterspezifiziert ist,
sind nach Denecke und Waibel Nachfragen nötig, die der Disambiguierung von Daten dienen.
Es gibt noch weitere Definitionen von Dialogstrategien, so werden Dialogstrategien auch
sehr oft systemabhängig definiert. Dabei wird auf jeder einzelnen Dialogäußerung mit einem
System eine Dialogstrategie definiert (siehe z.B. [Litman et al. 2000]).
4 Dieser Ansatz wird in [Komatani und Kawahara 2000] näher vorgestellt.

2.6. BEISPIEL 11
Die Wichtigkeit der einzelnen Systemmeldungen wurde z.B. in [Litman et al. 1998] gezeigt.
Dort wurde nachgewiesen, wie die Erfolgsrate in Dialogsystemen bei Veränderung der
Systemäußerungen verbessert wird. Dieser Ansatz wird auch durch die beiden unterschiedlichen
initialen Systemprompts des Veranstaltungsinformationsystem NJFun (siehe [Litman
et al. 2000]) in Abbildung 2.2 dokumentiert. Im Fall des ersten Systemprompts besteht die
Möglichkeit, daß ein Benutzer frei seinen Wunsch äußert und dabei viele Informationen mitgegeben
werden, die nicht, oder nur sehr schwer verarbeitet werden können. Prompt (2)
fordert dagegen eine konkrete Information von einem potentiellen Benutzer, eine Verarbeitung
dieser Daten ist sehr viel einfacher möglich, das Dialogziel kann daher sehr viel schneller
erreicht werden. Die Dialogstrategie sieht in Fall (1) eine sehr allgemeine Fragestellung vor,
die dem Benutzer alle Freiheiten läßt. Diese Strategie ist allerdings nur dann sinnvoll, wenn
auch nach diesem Systemprompt verschiedene weitere Dialogzustände in einem Dialogmodell
erreicht werden können, ansonsten wird eine Allgemeinheit suggeriert, die das entsprechende
System nicht verarbeiten kann.
(1) Willkommen bei NJFun, was kann ich für sie tun?
(2) Willkommen bei NJFun, bitte nennen sie einen Tag und eine Veranstaltungsart.
(nach [Litman et al. 2000])
Abbildung 2.2: Verschiedene initiale Systemprompts von NJFun
In dieser Arbeit möchte ich den Begriff der Dialogstrategie als die Strategie eines einzelnen
Systems im Hinblick auf das Erreichen eines Dialogziels, vor allem mit Blick auf die verschiedenen
Anfragetypen und -arten in einem Dialogsystem, verstehen. Dabei können sehr
wohl verschiedene Dialogstrategien parallel in einem System existieren.
Die Implementation einer optimalen Dialogstrategie ist das Ziel bei der Konstruktion eines
jeden Dialogsystems. Allerdings ist diese Strategie im Regelfall erst nach einer großen Zahl
von überwachten Experimenten zu finden. Neuerdings gibt es erste Versuche, eine optimale
Dialogstrategie auf automatischem Wege zu erreichen, dieser Ansatz ist in [Walker et al.
1998a; Litman et al. 2000] näher dokumentiert.
2.6 Beispiel
Um die in den vorherigen Abschnitten eingeführten Begriffe besser verstehen zu können,
werden diese im folgenden anhand eines Beispieldialogs veranschaulicht.
Der Beispieldialog in Abbildung 2.3 stellt einen Mensch-Maschine-Dialog einer typischen telefonischen
Bestellsituation dar. Der Dialog ist ohne Satzzeichen und nur in Kleinbuchstaben
abgebildet, wie er auch meist intern in Dialogsystemen repräsentiert wird.
Das System (in der Abbildung mit S gekennzeichnet) führt mit dem Anrufenden (A) einen
Bestell-Dialog, wie er mit dem im Rahmen dieser Arbeit entstandenen System ShopTel
möglich ist. Da es sich bei ShopTel um ein Telefonie-System handelt, gibt es einige Unterschiede
zu normalen Dialogsystemen. So steht in der Telefondomäne immer eine initiale
Begrüßung am Anfang eines Gesprächs.

12 KAPITEL 2. EINFÜHRUNG IN DIE DIALOGTHEORIE
(1) S: guten tag hier ist shoptel bitte geben sie vor der bestellung ihren namen an
(2) A: hallo hier ist mueller ich haette gerne ein paar flaschen weisswein bestellt
(3) S: bitte geben sie vorher noch ihre kundennummer an
(4) A: 1 2 3 4
(5) S: was fuer einen weisswein moechten sie gerne bestellen
(6) A: den weissen burgunder bitte
(7) S: wieviele flaschen haetten sie gerne
(8) A: ich nehme bitte 12 flaschen
(9) S: sie moechten also 12 flaschen weissen burgunder bestellen
(10) A: ja bitte
(11) S: das macht 154 mark 80 moechten sie noch etwas bestellen
(12) A: nein danke das waere alles
(13) S: wie moechten sie bitte zahlen
(14) A: ich zahle per rechnung
(15) S: ok die ware wird ihnen zugestellt
(16) A: sehr schoen auf wiederhoeren
(17) S: auf wiederhoeren und vielen dank fuer ihren anruf
Abbildung 2.3: Beispiel eines Mensch-Maschine-Dialogs
A nennt gleich zu Anfang in Äußerung (2) das Ziel seines Anrufs. Das System muß dieses
erkennen und verstehen. Das Erreichen dieses Ziels stellt die Aufgabe für das System dar,
dabei muß es wissen, wie das Ziel erreicht werden kann und muß es auch erreichen können.
Die Aufgabe des Systems ist die erfolgreiche Abwicklung einer Bestellung. Dazu muß sich
ein Benutzer zuerst authentifizieren, anschließend ein eindeutiges Produkt nennen (auch unterstützt
durch Rückfragen des Systems) und dazu noch die gewünschte Menge eingeben.
Diese Daten müssen noch einmal vom Benutzer bestätigt werden. Wenn der Anrufer keine
weiteren Bestellungen wünscht, folgt die Angabe einer Bezahlungsart. Danach ist das
Gespräch beendet, die Aufgabe ist erfüllt und das Dialogziel wurde erreicht.
An dem Beispieldialog lassen sich auch die Sequenzen mit ihren Komponenten darstellen.
Diese sind mit den jeweilig zuzuordnenden Äußerungen in Tabelle 2.1 dargestellt.
Äußerung Sequenz Komponenten
(1) Begrüßung Begrüßung
(2) - (4) Initialisierung Kundenname, Produkt, Kundennummer
(5) - (8) Produktbestellung Produkt, Anzahl
(9) - (12) Bestätigung Bestätigung
(13) - (15) Rechnungstellung Zahlungsart
(16) - (17) Gesprächsende Verabschiedung
Tabelle 2.1: Sequenzen und Komponenten des Beispieldialogs
Der Beispieldialog weist folglich sechs Dialogsegmente auf, die teilweise in mehrere Komponenten
separiert werden. Einige Segmente bestehen jeweils aus nur einer Komponente, wie
es bereits in Abschnitt 2.2.1 als zulässig gefordert wurde.

2.7. ZUSAMMENFASSUNG 13
Zur weiteren Verdeutlichung werden in Tabelle 2.2 die Segmente und Dialogakte des Beispieldialogs
wiedergegeben.
Äußerung Segment Dialogakte
(1) Begrüßung Begrüßung-S
(1) - (4) Authentifizierung Nachfrage-Name, Nennung-Name,
Nennung-Produkt, Nachfrage-Nr, Nennung-Nr
(5) - (8) Produktauswahl Nachfrage-Produkt, Spezifizierung, Nachfrage-Anzahl,
Nennung-Anzahl
(9) - (12) Bestätigung Nachfrage, Bestätigung,
Nennung-Summe, Nachfrage, Ablehnung
(13) - (15) Bezahlung Nachfrage-Zahlungsart, Nennung-Z.art, Bestätigung
(16) - (17) Gesprächsende Bestätigung, Verarbschiedung-A, Verabschiedung-S
Tabelle 2.2: Segmente und Dialogakte des Beispieldialogs
Die Entsprechung der Segmente mit den Sequenzen kann bei einem Vergleich der beiden
entsprechenden Tabellen nachgewiesen werden. Zu beachten sind allerdings die verschiedenen
Sichten. Für die Implementation eines Dialogsystems ist die Systemsicht entscheidend, bei
der Beobachtung von menschlichen Dialogen liegt die Benutzersicht vor. Eine klare Trennung
von Dialogsegmenten und auch -sequenzen ist jedoch nicht einfach. Beispielsweise könnte
Äußerung 16 auch noch der vorherigen Sequenz bzw. dem vorherigen Segment zugeordnet
werden.
In Äußerung (1) liegt ebenfalls eine Segmentgrenze, da die Äußerung zwei Dialogakte enthält.
Daher wurde in Tabelle 2.2 diese Äußerung zu zwei Segmenten zugehörig erklärt.
Aus den Ausführungen über den Dialogablauf läßt sich ein grobes Dialogmodell erstellen,
welches in Abbildung 2.4 zu sehen ist. Das abgebildete Modell basiert allerdings nicht auf
Dialogakten, sondern auf den in Tabelle 2.2 aufgeführten Segmenten. Die Abfolge der Dialogzustände
im Dialogmodell stellt die bereits oben eingeführte Dialogstruktur dar, die im
Zusammenhang mit der Dialogsteuerung als Interpretationsvorschrift dient. Dieser obliegt
im vorliegenden Modell die Sicherstellung des geregelten Übergangs der einzelnen Zustände.
Die einzelnen Dialogzustände repräsentieren außerdem die jeweiligen Dialogsegmente.
Die im Dialogmodell dargestellte Verzweigung geht aus dem Beispieldialog nicht hervor, da
dieser nur eine Bestellung enthält. Da diese Verzweigung jedoch möglich ist und auch im
Dialog abgefragt wird, wurde sie in das Dialogmodell mit aufgenommen.
Der Beispieldialog in Abbildung 2.3 folgt einer kooperativen Dialogstrategie, dies kann z.B.
an der verarbeiteten Überbeantwortung der ersten Äußerung (2) in der Abbildung des Benutzers
erkannt werden. Außerdem ist die verwendete Dialogstrategie robust, was an der
Bestätigungsfrage in (9) zu erkennen ist.
2.7 Zusammenfassung
In diesem Kapitel sind die grundlegenden Begriffe für diese Arbeit eingeführt und definiert
worden. Von besonderer Wichtigkeit ist vor allem der Dialog als grundsätzliche Basis für
Dialogsysteme, die im nächsten Abschnitt vorgestellt werden. Desweiteren wurden Dialogeinheiten
vorgestellt und begrifflich eingeführt, dabei sind vor allem der Dialogakt und das

14 KAPITEL 2. EINFÜHRUNG IN DIE DIALOGTHEORIE
Abbildung 2.4: Dialogmodell für Beispieldialog
Dialogsegment für das Verständnis dieser Arbeit essentiell. Außerdem sind die wichtigen
Termini Dialogmodell und Dialogstrategie erklärt und an einem Beispiel eingeführt worden.
Im nächsten Kapitel werden der Terminus ”
Dialogsystem“ definiert und anschließend die
allgemeinen Bestandteile eines solchen Systems kurz in ihrer Funktionsweise erklärt.

Kapitel 3
Grundlagen von Dialogsystemen
Im vorliegenden Kapitel möchte ich zuerst eine Begriffsklärung des Dialogsystems für die
vorliegende Arbeit geben. Danach werden die einzelnen Bestandteile eines Dialogsystems
kurz dargestellt, um einen besseren Überblick über diese und ihre Interaktion miteinander
zu geben. Abschließend werden die grundsätzliche Vorgehensweise zur Konstruktion eines
allgemeinen Dialogsystems sowie einige Problemfelder aufgegriffen und überblicksartig dargestellt.
3.1 Dialogsystem
Unter einem Dialogsystem soll ein sprachverstehendes System verstanden werden, welches
dem Erreichen von Zielen dient, die im gegenseitigen Dialog (vgl. Abschnitt 2.1) erreicht
werden können. Ein solches System muß in der Lage sein, einen Dialog zu führen, das
heißt verschiedene Äußerungen eines Benutzers zu analysieren, zu verstehen und darauf zu
reagieren und es muß insbesondere einem ungeübten Benutzer die Verwendung ermöglichen
(dies kann zum Beispiel mit Hilfedialogen geschehen). Zusammengefaßt kann gesagt werden:
Definition 3.1 Ein Dialogsystem ist ein sprachverstehendes System, das dem Erreichen
von Zielen im gegenseitigen Dialog dient, dafür muß es Benutzeräußerungen adequat verarbeiten
und darauf sinnvoll reagieren können.
Ein Dialogsystem, das Nachfragen stellen kann und auch Referenzen zu bereits getätigten
Äußerungen eines Benutzers nachvollziehen kann, wird in der englischsprachigen Literatur
häufig als conversational system bezeichnet, ich werde in der vorliegenden Arbeit dafür als
deutsches Äquivalent den Begriff Konversationssystem nutzen. Eine definitorische Klärung
eines Konversationssystems erfolgt in Definition 3.2, die eine Erweiterung von Definition 3.1
darstellt.
Definition 3.2 Ein Konversationssystem ist ein Dialogsystem, das Nachfragen zu kontextuellen
Bezügen stellen und Referenzen in Benutzeräußerungen verarbeiten kann.
Im allgemeinen Fall möchte ich allerdings weiterhin von einem Dialogsystem sprechen, nur
wenn der Unterschied zwischen beiden Systemarten betont werden soll, werde ich den Term
Konversationssystem verwenden.

16 KAPITEL 3. GRUNDLAGEN VON DIALOGSYSTEMEN
3.2 Komponenten eines Dialogsystems
In den nächsten Abschnitten dieses Kapitels werden die verschiedenen Komponenten eines
gesprochen-sprachlichen Dialogsystems erklärt und eingeführt, um ein besseres Verständnis
für die einzelnen Komponenten und deren Interaktion zu ermöglichen. Dieser Überblick ist
allgemein gehalten und nur als Einführung in die entsprechenden Bereiche zu verstehen.
3.2.1 Spracheingabe
Die Eingabe in ein Dialogsystem besteht aus gesprochener natürlicher Sprache. Diese Spracheingabe
kann entweder über ein stationäres oder ein in ein Telefon integriertes Mikrofon
geschehen. Bei beiden Verfahren wird eine gesprochene Äußerung aufgezeichnet und als
Sprachsignal von einem A/D-Wandler digitalisiert. Eine Eingabe über Telefon ist allerdings
wegen der geringeren Bandbreite 1 des Telefonkanals und der möglichen Leitungsstörungen
meist von geringerer Qualität als eine Mikrofonaufzeichnung. Die Qualität des aufgenommenen
Sprachsignals ist für das erfolgreiche Erreichen eines Dialogziels in einem Dialogsystem
allerdings sehr wichtig, denn schon ein falsches Wort kann den Sinn einer Äußerung nachhaltig
verändern und damit zum Scheitern eines Dialogschritts führen. Robuste Dialogsysteme
können mit schlechten Erkennungsraten umgehen, indem beispielsweise Sprachsignale unterhalb
eines gewissen Schwellwertes nicht betrachtet werden oder der Benutzer in einem
solchen Fall gebeten wird, seine Äußerung zu wiederholen.
3.2.2 Spracherkennung
Das aufgezeichnete Sprachsignal wird im folgenden auf eine Menge bzw. Kette von Wörtern
abgebildet, diesen Prozeß nennt man Spracherkennung. Dabei wird das Sprachsignal in festgelegten
Abständen (meist um die 10 ms) abgetastet, aus dem Ergebnis werden dann Kurzzeitspektren
erstellt. Mit Hilfe der Fourier-Transformation werden spektrale Parameter gewonnen,
aus denen wiederum Merkmalsvektoren errechnet werden, die in chronologischer
Reihenfolge mit Referenzmustern verglichen werden. 2 Dieser Vergleich wird meist mit dem
Hidden Markov Modell (HMM) durchgeführt. Das HMM ist ein zweistufiger stochastischer
Prozeß, der aus einer Markov-Kette mit Zuständen besteht, denen Wahrscheinlichkeiten
zugeordnet sind. Eine einzelne Markov-Kette steht für eine Phonemfolge, ein Zustand symbolisiert
ein Phonem 3 . Das HMM emitiert in jedem durchlaufenen Zustand ein Phonem. Die
wahrscheinlichste Phonemfolge stellt damit das Wort dar, das mit der größten Wahrscheinlichkeit
erkannt worden ist. Allerdings müssen die auf diesem Weg erkannten Phonemfolgen
dem Erkenner selber vor dem eigentlichen Erkennungsvorgang bekannt sein, eine Erkennung
von unbekannten Phonemfolgen (und damit auch unbekannten Wörtern) ist bislang in den
wenigsten Dialogsystemen machbar.
Um eine unsystematische oder unmögliche Wortfolge zu verhindern, wird ein Sprachmodell
(engl. language model) berechnet, dieses besteht aus Wortfolgewahrscheinlichkeiten 4 . Von einem
Sprachmodell (LM) werden die Wortfolgen bevorzugt, die mit einer gewissen Häufigkeit
in diesem auftreten.
1 Die Bandbreite des Telefonkanals beträgt im allgemeinen 8 kHz, im Gegensatz zu 22 kHz, die vom
menschlichen Gehör wahrgenommen werden können.
2 Für eine genauere Beschreibung der Sprachsignalverarbeitung siehe z.B. [Vary et al. 1998].
3 Ein Phonem ist die kleinste bedeutungsdifferenzierende Einheit in der Sprache (nicht im Sprachsignal!),
im Gegensatz dazu ist ein Phon die kleinste akustisch wahrnehmbare Einheit.
4 Meist Bigramme (zwei aufeinanderfolgende Wörter) oder Trigramme (drei aufeinanderfolgende Wörter).

3.2. KOMPONENTEN EINES DIALOGSYSTEMS 17
Für Dialogsysteme werden häufig bereits existierende Spracherkenner verwendet. Um jedoch
in der entsprechenden Domäne eine noch bessere Erkennungsleistung erzielen zu können,
wird in den meisten Fällen ein Sprachmodell über den Dialogdaten der entsprechenden
Anwendung berechnet.
Ein Spracherkenner in sprachverarbeitenden Systemen liefert als Lösung des Erkennungsprozesses
entweder einen Worthypothesengraphen 5 , ein Graph in dem die wahrscheinlichsten
Wortfolgen repräsentiert sind, oder aber die wahrscheinlichste Wortfolge, die als beste Kette
bezeichnet wird. 6 Diese Lösung wird an die nachfolgenden Komponenten weitergereicht, um
dort weiterverarbeitet zu werden.
3.2.3 Parsing
Im Parsing werden die syntaktischen Strukturen und semantischen Beziehungen innerhalb
einer Äußerung herausgearbeitet. Dies ist nötig, um die Aussage einer sprachlichen Äußerung
in einem Dialogsystem zu verstehen und damit eine entsprechende Reaktion auslösen zu
können.
Dabei dient die syntaktische Analyse der Erkennung der grammatischen Strukturen eines
Satzes. Dieser Schritt ist meist unabdingbar, um eine anschließende semantische Analyse
eines Satzes durchzuführen.
Die semantische Analyse dient zur Bestimmung der Bedeutung einer Äußerung. Nur mit dieser
semantischen Analyse ist es möglich, den Sinn einer Äußerung zu erkennen und nur mit
Kenntnis dieses Sinns einer Äußerung kann eine entsprechende Reaktion von einem System
ausgehen. Die semantische Analyse ist in Dialogsystemen zumeist domänenabhängig implementiert,
um eine möglichst eindeutige Bedeutungszuordnung zu ermöglichen. Eine generelle,
domänenunabhängige semantische Analyse ist auf Grund der großen Vielzahl möglicher
Bedeutungen zur Zeit nicht leistungsfähig genug.
Grundsätzlich existieren verschiedenste Verfahren und Techniken für das Parsing. Da der
Parsingvorgang auf Sprachdaten basiert, wird das Parsing selber häufig als linguistische
Aufgabe angesehen. Daher bietet sich die Verwendung von Grammatiken für diesen Vorgang
an. Viele Beispiele für diese Sichtweise finden sich in [Allen 1995], der Parsing als Methode
der Satzanalyse, in der die Satzstruktur auf Grund einer Grammatik gefunden werden soll,
beschreibt. Diese – und verschiedene andere – Parsingtechniken werden auch in [Busemann
1995] vorgestellt.
Ein großes Problem aller Parser ist die Unsicherheit der Daten, die vom Spracherkenner
kommen. Viele Parsingalgorithmen gehen von korrektem Input aus, der syntaktisch analysiert
werden soll. Allerdings ist insbesondere bei spontansprachlichen Systemen nicht von
korrekten Sätzen auszugehen. Aus diesem Grund werden robuste Algorithmen benötigt, die
auch auf nicht korrekten Daten sinnvoll arbeiten können. In [Smith und Hipp 1994] wird eine
probabilistische kontext-freie Grammatik (PCFG) als Grundlage für einen robusten Parser
propagiert. Auch eine Anwendung von Constraints über einer Grammatik wird vorgestellt.
Ein anderer Weg wird in [Menzel 1998; Menzel und Schröder 1998; Foth et al. 2000a; Foth
et al. 2000b] mit der selektiven Anwendung von Constraints vorgeschlagen, dieser Ansatz
ist überaus robust und benötigt keine Grammatik.
5 Mehr Informationen über Wortgraphen siehe z.B. bei [Amtrup et al. 1996].
6 Häufig werden die besten Lösungen als n-beste bezeichnet, wobei ”
n“ auch den Wert ”
1“ annehmen
kann.

18 KAPITEL 3. GRUNDLAGEN VON DIALOGSYSTEMEN
3.2.4 Dialogkontrolle
Die Dialogkontrolle interpretiert die getätigten Äußerungen im Hinblick auf das Dialogziel
und den aktuellen Status des Dialogs und wird häufig auch als Dialogsteuerung (vgl. Abschnitt
2.4), manchmal auch als Dialogmanager (DM) in einem Dialogsystem bezeichnet.
Im Falle einer Datenbankabfrage muß die Dialogkomponente z.B. die für die Erledigung
der Abfrage notwendigen Angaben kennen und deren Parameter sammeln. Es obliegt der
Dialogkontrolle, diese Angaben gezielt abzufragen und dann gesammelt oder einzeln an
ein eventuelles Hintergrundsystem weiterzuleiten. In den meisten Fällen wird diese Datensammlung
durch ein slot-filling erledigt, dabei wird für jedes in der aktuellen Dialogphase
abzufragende Datum ein eigener Slot bereitgestellt, der mit den entsprechenden Angaben
gefüllt wird.
Häufig werden im Rahmen der Dialogkontrolle Dialogakte oder Dialogsegmente eingeführt,
die zum Erreichen des Dialogziels geäußert bzw. durchlaufen werden müssen.
3.2.5 Hintergrundsystem
Das Hintergrundsystem oder auch backend ist das eigentliche System, welches durch ein
vorgeschaltetes Dialogsystem gesteuert wird. In den meisten Fällen handelt es sich hierbei
um eine Datenbank, deren Informationen über ein Dialogsystem abgefragt werden. Als Beispiele
seien hier das Zug-Auskunftssystem von Philips (vgl. Abschnitt 4.1.3), welches als
Datengrundlage das Kursbuch der Deutschen Bahn AG benutzt, und das Stauinformationssystem
der IBM (siehe Abschnitt 4.1.7), dessen Datenbank Einträge über Staus auf deutschen
Autobahnen enthält, genannt.
Bei komplexeren Systemen, bei denen nicht nur eine Information aus einer Datenbank abgefragt
werden soll, kann auch eine Planungskomponente existieren, die z.B. gültige Routen
plant (siehe System TRAINS in Abschnitt 4.2.1.) oder freie Termine vergibt (CMU Communicator,
Abschnitt 4.2.2).
3.2.6 Antwortgenerierung
Alle Rückfragen und Antworten müssen an den Benutzer in einer verständlichen und sinnvollen
Form weitergegeben werden. So muß insbesondere beachtet werden, daß gesprochener
Output von einem Benutzer anders aufgenommen wird, als eine Tabelle oder eine
Aufzählung. Gleichzeitig sollte dem Benutzer ein Feedback über bisher Verstandenes und die
bisherigen Aktionen gegeben werden, dabei ist eine Informationsüberflutung für den Benutzer
allerdings zu vermeiden. Die Antwortgenerierung übernimmt daher die genaue Planung
des Output, stellt die notwendigen Informationen bereit und gibt diese an die Sprachsynthese
weiter.
3.2.7 Sprachsynthese
Die Sprachsynthese synthetisiert den von der Antwortgenerierung bereitgestellten Output
und sendet ein digitales Sprachsignal an den Ausgabekanal. Die Synthese erfolgt meist mittels
sogenannter text to speech (TTS) Systeme. 7
7 Näheres über die Sprachsynthese siehe z.B. in [Vary et al. 1998].

3.3. KONSTRUKTION VON DIALOGSYSTEMEN 19
TTS-Systeme sind, genauso wie Spracherkenner, sprachabhängig, das heißt, eine deutsche
Synthese verwendet die Ausspracheregeln der deutschen Sprache, eine englische Synthese
die Regeln des Englischen. Aus diesem Umstand resultiert die Problematik für viele TTS-
Systeme, Fremdwörter korrekt zu synthetisieren.
Als Alternative zur Sprachsynthese wird teilweise die Technik der Sprachwiedergabe (auch
reproduktive Sprachsynthese) verwendet. Es handelt sich in diesem Fall um die Montage
und Wiedergabe bereits aufgezeichneter Sprachsignale, sogenannter Prompts.
3.2.8 Sprachausgabe
Die Sprachausgabe des Sprachsignals erfolgt entweder über Lautsprecher bzw. Kopfhörer
oder Telefon. Der jeweilige Ausgabekanal sollte bereits bei der Sprachsynthese berücksichtigt
werden, um den jeweiligen Besonderheiten Rechnung zu tragen (z.B. Beachtung der geringen
Bandbreite und der möglichen Kanalstörungen des Telefonkanals).
3.3 Konstruktion von Dialogsystemen
In den nachfolgenden Abschnitten sollen kurz schematisch die wichtigsten Schritte zur Konstruktion
eines Dialogsystems aufgeführt werden. Diese Abschnitte sind sehr allgemein gehalten,
um einen grundsätzlichen Einblick in die Konstruktion eines Dialogsystems zu geben.
Im Falle einer Konstruktion mit Hilfe eines Toolkits 8 müssen diese Schritte nicht immer
nachvollzogen werden, da einige Komponenten in den Tools bereits enthalten sind.
3.3.1 Spezifikation
Am Anfang der Konstruktion eines beliebigen Dialogsystems steht die Spezifikation. In dieser
Phase werden die grundlegenden Entscheidungen für das zu erstellende System gefällt, diese
betreffen u.a. den Aufgabenbereich des Systems und die dazugehörige Systemdomäne. Dabei
ist insbesondere eine klare Abgrenzung zu relevanten und nicht mehr relevanten Aktionen
des Systems nötig, um die Domäne dieses geplanten Systems möglichst exakt bestimmen zu
können und somit von Anfang an Grenzfälle möglichst auszuschließen.
Während der Spezifikation ist nach der Bestimmung der Domäne und des Aufgabenbereichs
für das zu erstellende System der Systemtyp zu definieren. In Abhängigkeit dieses Typs ist
im folgenden auch die architektonische Arbeit betroffen. Üblicherweise werden bei Dialogsystemen
folgende drei Typen unterschieden (vgl. Kapitel 4):
• Auskunftssysteme, die lediglich Auskünfte erteilen und somit sehr häufig als Frontend
vor einer Datenbank konstruiert werden
• Aktionssysteme, die neben Auskünften auch Aktionen erlauben, wie zum Beispiel Routenplanungen
oder die Erledigung von Aufgaben
• Übersetzungssysteme, die Dialoge in verschiedenen Quell- und Zielsprachen gestatten
und auch eine Übersetzung des ganzen Dialogs oder einiger Teile leisten
8 Es gibt inzwischen bereits verschiedene Toolkits zur Erstellung von telefonbasierten Dialogsystemen,
z.B. SpeechMania von Philips oder das IBM ViaVoice Telephony Toolkit der IBM.

20 KAPITEL 3. GRUNDLAGEN VON DIALOGSYSTEMEN
In den Bereich der Spezifikation fallen auch die ersten architektonischen Arbeiten. So sollte
bereits überlegt werden, wie ein zu erstellendes Dialogsystem benutzt werden soll: es bieten
sich zum Beispiel Telefonanwendungen oder Dialogsysteme für den Mikrofoneinsatz an, die
z.B. in face-to-face Situationen zum Einsatz kommen können. 9
3.3.2 Dialogmaterial
Um ein Dialogsystem konstruieren zu können, wird vor allem ein Dialogmodell benötigt.
Für ein erstes Dialogmodell werden jedoch repräsentative Dialogdaten gebraucht, um ein
allgemein verwendbares Dialogsystem herstellen zu können. Die erste Konstruktion eines
solchen Dialogmodells kann manchmal einfach abgeleitet und die Dialogdaten selbst erdacht
werden, häufig ist die Domäne eines Dialogsystems für einen solchen Vorgang aber zu komplex,
außerdem ist auf die Repräsentativität der Dialogdaten zu achten. Aus diesen Gründen
werden in den meisten Fällen empirische Untersuchungen über eine mögliche Dialogstruktur
vorgenommen. Dabei werden zuerst Dialogdaten erhoben und diese anschließend analysiert,
um aus diesen gewonnenen Daten ein Dialogmodell zu erstellen.
Erhebung des Dialogmaterials
Die Erhebung von Dialogmaterial kann sehr aufwendig und problematisch sein. Denn das
entstehende Dialogsystem wird mit sehr ähnlichen oder sogar identischen Daten getestet.
Wenn aber nach einer erfolgreichen Testphase während der praktischen Erprobung die erhobenen
Daten nicht repräsentativ oder falsch sind, müssen neue Daten für das Dialogsystem
erhoben werden.
Es gibt drei hauptsächliche Methoden zur Erhebung von Dialogmaterial:
Bei der Beobachtung werden natürliche (also nicht gestellte) Dialoge zwischen zwei Personen
aufgezeichnet. Daten, die mit dieser Methode erhoben wurden, liefern im allgemeinen sehr
viel Überflüssiges, da menschliche Dialogpartner sehr häufig dazu tendieren, nebensächliche
Äußerungen einem Thema hinzuzufügen. Während der Analyse wird daher ein Großteil der
Arbeit daraus bestehen, die wesentlichen Daten zu extrahieren. Die Methode der Beobachtung
empfielt sich daher nur als erster Versuch oder für sehr kleine und stark eingrenzbare
Domänen.
Die nächste Möglichkeit besteht in der Anwendung bestimmter Szenarien. Dabei werden
ein Dialogziel und klare Anweisungen an die Sprecher ausgegeben. Die erhobenen Daten
sind damit besser geeignet, allerdings nicht unter natürlichen Umständen entstanden. Die
Entwicklung von guten Szenarien ist sehr aufwendig, da diese andauernd überprüft und
getestet werden müssen. Es ist darauf zu achten, daß Testpersonen sich nicht zu stark auf
das Dialogziel einschränken und damit die Repräsentativität verloren geht.
Die dritte Möglichkeit zur Dialogmaterialsammlung sind sogenannte Wizard-of-Oz Experimente
(WOZ). Bei dieser Methode wird einer Testperson ein bereits funktionierendes Dialogsystem
vorgetäuscht. In Wirklichkeit steuern allerdings Menschen das Dialogsystem und
versuchen auf diese Art, wie das zukünftige Dialogsystem zu reagieren. Bei dieser Methode
ist der Aufwand sicherlich am größten, allerdings sind die erhobenen Daten am besten
geeignet und erfordern keine zusätzlichen Arbeitsschritte.
9 Beispiele für Telefoniesysteme sind z.B. TABA (siehe Abschnitt 4.1.3) oder die IBM Stau Applikation
(siehe Abschnitt 4.1.7); wohl bekanntestes Beispiel für ein Dialogsystem in face-to-face Situationen ist das
System VERBMOBIL (siehe dazu Abschnitt 4.3.2).

3.3. KONSTRUKTION VON DIALOGSYSTEMEN 21
Analyse des Dialogmaterials
Wenn die erhobenen Daten als Audiodaten vorliegen, müssen diese zuerst transkribiert werden.
Dies geschieht im allgemeinen nur als textuelle Transkription.
Die verschriftlichten Dialogdaten werden zur Analyse annotiert. Die Notationen können dabei
entweder syntaktische oder semantische Markierungen sein, oder auch Dialogakte (vgl.
Abschnitt 2.2.2). Der Vorgang der Annotation wird labeling oder labeln genannt. Diese Arbeit
ist sehr zeitintensiv, da sie von Hand ausgeführt wird und stark von den Kenntnissen
der ausführenden Person abhängt. Da das Labeln systemabhängig ist, muß dieser Vorgang
für jedes neue System durchlaufen werden. Dabei ist insbesondere auf die Konsistenz der
einzelnen vergebenen Notationen zu achten.
Die annotierten Daten dienen nun als Grundlage für die Dialogmodellierung in dem zu
konstruierenden Dialogsystem, es kann ein erstes initiales Modell erstellt werden und damit
das System getestet werden.
Die gesammelten Daten können auch noch für andere Zwecke weiterverwendet werden, es
bietet sich z.B. an, aus ihnen ein Sprachmodell (siehe Abschnitt 3.2.2) zu berechnen und
außerdem mit dem Vokabular dieser Daten den Spracherkenner zu trainieren. Auch der
Parser basiert auf den annotierten Daten.
3.3.3 Parsingkomponente
Im allgemeinen muß als nächstes ein Parser (siehe Abschnitt 3.2.3) konstruiert werden,
der auf den Annotationen der Dialogdaten aufbaut. Aus diesem Grund ist es nochmals zu
betonen, daß die einzelnen Notationen für das Dialogmaterial sehr konsistent zu vergeben
sind, um die Arbeit des Parsers zu erleichtern.
Die Parsingkomponente ist für einen erfolgreichen Dialog mit einem Dialogsystem sehr entscheidend.
Denn erst diese Komponente ordnet einer Äußerung einzelne Bedeutungen zu
und gibt damit einen ersten Ausschlag für die Zuordnung von Aktionen oder Dialogakten
zu den jeweiligen Äußerungen.
Jedes Dialogsystem benötigt eine Parsingkomponente, es gibt auch Systeme die über mehrere,
unterschiedliche solcher Komponenten verfügen. Dies wird häufig gemacht, um Ergebnisse
von verschiedenen Parsingmoduln bzw. -techniken vergleichen zu können. Es gibt auch
die Möglichkeit, den eigentlichen Parsingvorgang in mehrere Schritte und somit mehrere
Komponenten zu unterteilen, um das Parsing zu vereinfachen.
3.3.4 Dialogkomponente
In jedem Dialogsystem muß eine Form der Dialogsteuerung (vgl. Abschnitt 2.4) existieren.
Diese kann in einfacheren Systemen aus einem einfachen Skript bestehen, in komplexeren
Systemen stellt die Dialogsteuerung ein eigenes Modul dar. In diesem Modul wird die
gewünschte Struktur eines Dialogs sichergestellt, es basiert auf dem Dialogmodell. Die Entwicklung
dieser Komponente ist sehr arbeits- und zeitaufwendig.
Die Dialogsteuerung ist das Herz eines jeden Dialogsystems. Je einfacher die Abgrenzung
einer Aktion des Systems gegen eine andere ist, desto leichter kann die Dialogsteuerung
zwischen unterschiedlichen Aktionen unterscheiden. Sehr wichtig ist an diesem Punkt die

22 KAPITEL 3. GRUNDLAGEN VON DIALOGSYSTEMEN
Konsistenz zwischen dem, aus den gesammelten Dialogdaten erstellten, Dialogmodell, dem
Parser und der Dialogsteuerung. Die in den Daten verwendeten Notationen müssen im Parser
korrekt verarbeitet und den einzelnen Aktionen zugeordnet werden, in der Dialogsteuerung
müssen die verwendeten Aktionen existieren und ausführbar sein.
Die Dialogsteuerung greift, bei Existenz, auf die Dialogsegmente zu. Die Segmente beinhalten
Informationen über die jeweilig benötigten Daten und die möglichen Aktionen in jeder Phase
des Dialogs mit einem System.
Eine andere Schwierigkeit stellt häufig die Wahl der richtigen Dialogstrategie (vgl. Abschnitt
2.5) dar, diese muß meist in umfangreichen Tests ermittelt werden. In [Litman et al.
2000] wird ein automatisches Lernverfahren für die Ermittlung der optimalen Dialogstrategien
vorgestellt.
3.3.5 Backend
Um die Ausführung von Aktionen der Dialogsteuerung zu realisieren, werden häufig entsprechende
Methoden im Backend (vgl. Abschnitt 3.2.5) benötigt, die aus der Dialogsteuerung
ansprechbar sein müssen. Gleichzeitig muß es möglich sein, Daten vom Backend zur Dialogkomponente
zurückzugeben, um Antworten zu übermitteln.
3.3.6 Ein- und Ausgabe
Schließlich bedarf ein gesprochen-sprachliches Dialogsystem noch einer Spracheingabekomponente.
Desweiteren wird noch ein Modul für eine Sprachausgabe benötigt.
Für die Spracheingabe wird ein Spracherkenner (vgl. Abschnitt 3.2.2) benötigt, dieser muß
auf dem verwendeten Vokabular trainiert sein. Es bietet sich an, dieses Training über den
erhobenen und transkribierten Dialogdaten (vgl. Abschnitt 3.3.2) durchzuführen. Für eine
weitere Verbesserung der Erkennungsrate des Spracherkenners, sollte ein Sprachmodell aus
diesen Daten errechnet werden.
Letztendlich wird für das Systemfeedback eine Sprachausgabe benötigt. Diese kann entweder
als TTS-Modul ausgeführt sein, oder es können aufgezeichnete Prompts abgespielt werden.
In letzterem Fall ist allerdings ein sehr gutes Datenmaterial an aufgezeichneten Äußerungen
nötig, um eine möglichst hohe Vielfalt an Rückmeldungen zur Verfügung zu haben. 10
3.4 Zusammenfassung
In diesem Kapitel wurde der Begriff ”
Dialogsystem“ definiert und außerdem das ”
Konversationssystem“
definitorisch eingeführt. Desweiteren sind die einzelnen Komponenten eines
allgemeinen Dialogsystems kurz dargestellt und in ihrer Funktionsweise beschrieben worden.
Ebenfalls wurde ein Überblick über die beispielhafte Konstruktion einer Dialoganwendung
gegeben. Hierbei ist insbesondere auf die Spezifikation und die Erhebung von Dialogmaterial
eingegangen worden, die beide eine unabdingbare Voraussetzung für ein Dialogsystem
darstellen.
10 Ein Beispiel für ein System, daß komplett nur mit aufgezeichneten Prompts arbeitet, ist das System
TABA von Philips, siehe Abschnitt 4.1.3.

3.4. ZUSAMMENFASSUNG 23
Im folgenden Kapitel werden jetzt einige ausgewählte Dialogsysteme vorgestellt, um damit
das Umfeld der bereits existierenden Dialogsysteme darstellen zu können. Dabei möchte ich
mich auf die in diesem Kapitel eingeführten Komponenten und Begrifflichkeiten beziehen.
Etwaige Sonderfälle werden dabei einzeln diskutiert.
In Kapitel 5 wird dann das im Rahmen dieser Arbeit entstandene System ShopTel vorgestellt.
Auch in diesem Kapitel möchte ich mich an den hier beschriebenen Modulen und
Funktionalitäten orientieren. Es werden dort allerdings auch die Besonderheiten des Systems
im Gegensatz zu allgemeinen Systemen dargestellt.

24 KAPITEL 3. GRUNDLAGEN VON DIALOGSYSTEMEN

Kapitel 4
Dialogsysteme im Überblick
Dialogsysteme werden bereits seit geraumer Zeit in verschiedenen Forschungsprojekten und
-gruppen entwickelt. Im vorliegenden Kapitel werden einige ausgewählte Systeme kurz vorgestellt,
um einen Eindruck der bisher existierenden Systeme und der verwendeten Technologie
zu vermitteln. Das Kapitel wird mit einem kurzen Vergleich beschlossen, in dem die
angesprochenen Systeme einander gegenübergestellt werden.
Die vorgestellten Systeme verfügen alle über eine Dialogkomponente und einen Spracherkenner.
Die Spracheingabe kann bei einigen Systemen über ein Mikrofon, bei anderen per
Telefon geschehen.
Die meisten der vorgestellten Systeme sind weder marktreif, noch fehlerfrei. Sie sind vielmehr
in Forschungseinrichtungen konstruiert worden, um die grundsätzliche Machbarkeit
von sprachverstehenden Dialogsystemen nachzuweisen und, um verschiedene neue Techniken
auszuprobieren.
Die vorgestellten Systeme wurden, um eine bessere Vergleichbarkeit zu gewährleisten, in
drei Kategorien unterteilt. Die Differenzierung erfolgte in die Kategorien Auskunftssysteme,
Aktionssysteme und dialogfähige Übersetzungssysteme. Den drei Kategorien entsprechen die
jeweiligen Abschnitte des Kapitels.
4.1 Auskunftssysteme
Auskunftssysteme bieten im allgemeinen den Zugang zu einer Datenbank an. Dabei dient
der natürlichsprachliche Zugang als Erleichterung für den Benutzer.
Die gängigste Anwendung dieser Systemkategorie stellen Zugauskunftssysteme dar, wie das
EU-Projekt SUNDIAL (siehe Abschnitt 4.1.2), TABA von Philips (vgl. Abschnitt 4.1.3),
Dialogos vom CSELT aus Italien (Abschnitt 4.1.4) oder EVAR von der Universität Erlangen
(Abschnitt 4.1.5). Desweiteren werden ein System für Dokumentenverwaltung (Abschnitt
4.1.1), ein Wetterinformationssystem (Abschnitt 4.1.6) und ein Stauinformationssystem
(Abschnitt 4.1.7) vorgestellt.
Die Reihenfolge der Darstellung erfolgt nach chronologischer Ordnung.

26 KAPITEL 4. DIALOGSYSTEME IM ÜBERBLICK
4.1.1 SPICOS
Das System SPICOS war das erste Dialogsystem, das in Deutschland entstanden ist. Sein
Akronym steht für Siemens-Philips-IPO COntinuous Speech Understanding and Dialog.
Dieses System wurde in Kooperation von Philips, Siemens und dem IPO-Institut in Eindhoven
(Niederlande) von 1984 bis 1990 als Gemeinschaftsprojekt durchgeführt und vom
Bundesministerium für Forschung und Technologie (BMFT) finanziert. Schwerpunkt des
Projekts war die erstmalige Verwirklichung eines Dialogsystems, das mit kontinuierlicher
deutscher Sprache bedient werden konnte und den natürlichsprachlichen Zugang zu einer
Datenbank ermöglichen sollte.
Im Jahr 1987 wurde der Prototyp SPICOS I präsentiert (siehe [Niedermair 1987]). Dieser
erste Prototyp gestattete bereits einfache Frage-Antwort-Schemata, bei denen eine Anfrage
in gesprochener, kontinuierlicher Sprechweise getätigt werden konnte, die vollständig zu
formulieren war. Die Antwortzeit lag damals bei 100facher Echtzeit (vgl. [Ney et al. 1992]).
SPICOS II, die 1990 präsentierte Weiterentwicklung von SPICOS, verfügte über verschiedene
Verbesserungen gegenüber dem Vorgängermodell, dies galt insbesondere für die Dialogverarbeitung.
Um einen besseren Überblick über das System zu geben, wird im folgenden eine
kurze Beschreibung des Systems gegeben:
Die Spracherkennungskomponente von SPICOS II liefert die besten vier Hypothesen (vgl.
Abschnitt 3.2.2) zur Weiterberarbeitung an den Dialog-Handler. Dieser steuerte die Abfolge
der einzelnen Analyseschritte. Z.B. wurde vor der syntaktischen und semantischen Analyse
ein Sprachmodell als Filter über den Sprachdaten eingesetzt. Der Parsingvorgang wurde
in zwei einzelne Vorgänge unterteilt, dabei war das Parsingmodul des Systems allerdings
nur für die Verarbeitung von grammatisch wohlgeformten Input konstruiert worden, spontansprachliche
Äußerungen konnten daher nicht verarbeitet werden. Als Grundlage für den
syntaktischen Parser diente eine Phrasenstrukturgrammatik. Der zweite Parsingvorgang,
die semantische Verarbeitung, geschah auf der Basis von semantischen Netzwerken. Die Zuordnung
von einzelnen Aktionen wurde im Dialog-Handler über Dialogakte (vgl. Abschnitt
2.2.2) realisiert. Da insbesondere eine Verbesserung der Dialogkomponente in SPICOS II erreicht
werden sollte, wurde im Rahmen der Dialogverarbeitung auch eine Anaphernresolution
implementiert, die Antecedenten speicherte und so in der Lage war, bei einer Bezugnahme
die entsprechenden Bezüge zu liefern. In Zweifelsfällen wurde dabei eine Nachfrage des Systems
initiiert. Nur in diesem Fall lag die Initiative im Dialog beim System, ansonsten lag sie
ausschließlich beim Anwender. 1
Die im Jahre 1990 präsentierte Version war vom Dialogverhalten her bereits auf den Betrieb
per Telefon ausgerichtet, ein Bildschirm wurde für die Steuerung nicht mehr benötigt. Da
allerdings Eingaben nicht robust verarbeitet werden konnten, erschien eine Anbindung an
das Telefon nicht sinnvoll.
Beide Systeme, SPICOS I und SPICOS II konnten Anfragen zu abgelegten Dokumenten und
zu am SPICOS-Projekt beteiligten Personen beantworten. Viele Erkenntnisse der zweiten
Version gingen bei Siemens in die Forschung für das Projekt SUNDIAL (siehe Abschnitt
4.1.2) ein (vgl. [Niedermair 1992]).
Die Spracherkennung konnte mit kontinuierlicher Sprache umgehen, war allerdings sprecherabhängig.
Dabei umfaßte das Vokabular von SPICOS I rund 900 Wörter, SPICOS II
arbeitete auf einem Vokabular von 1200 Wörtern und konnte Anfragen in 5-20facher Echtzeit
bei einer durchschnittlichen Wortfehlerrate von 9,4 % beantworten (vgl. [Ney et al. 1992]).
1 Weitere Ausführungen siehe in [Niedermair 1992].

4.1. AUSKUNFTSSYSTEME 27
4.1.2 SUNDIAL
Das Projekt SUNDIAL war eines der größten von der EU im Rahmen des ESPRIT-Vertrages
finanzierten Projekte der Sprachtechnologie. Die Laufzeit des Projekts ging von 1988 bis
1993, die Durchführung oblag folgenden Projektpartnern: CAP Gemini Innovation (F),
CNET (F), CSELT (I), Daimler-Benz, Universität Erlangen, IRISA (F), Logica (GB), Politechnico
di Torino (I), Sarin Telematica (I), Siemens, University of Surrey (GB) und Vocalis
(GB). Das Akronym SUNDIAL steht für Speech UNderstanding in DIALogue. Ziel des
Projekts war die Konstruktion eines Dialogsystems, welches in Echtzeit in kooperativen
Dialogen mit einem Benutzer über Telefon kommunizieren konnte (vgl. [Peckham 1993]).
Der im Rahmen des Projekts entstandene Prototyp konnte Anfragen zu Zugverbindungen
auf Deutsch und Italienisch und zu Flugverbindungen auf Englisch und Französisch verarbeiten.
Anfragen konnten dabei sowohl von erfahrenen als auch von unerfahrenen Benutzern
kommen; daher resultierte die erfolgte Verarbeitung spontansprachlicher Phänomene
in SUNDIAL. Bedingt durch die Sprachvielfalt wurde jedoch für jede Sprache ein eigenes
System erstellt (siehe [McGlashan 1994]).
Die Funktionalität der einzelnen Systeme wurde zuerst durch umfangreiche WOZ Simulationen
(siehe Abschnitt 3.3.2) spezifiziert. Die Ergebnisse dieser Experimente trugen maßgeblich
zur Erstellung einiger Informationen bei, die unerfahrenen Benutzern von SUNDIAL
vorgelegt wurden, um eine effiziente Benutzung des Systems zu ermöglichen.
Jedes System bestand aus fünf Modulen. Die sprachliche Analyse wurde auf eine akustische
Erkennung und eine Parsing-Komponente verteilt. Die Ergebnisse des Parsers werden in
einer sprachenunabhängigen Repräsentation (Semantic Interface Language – SIL), die im
Rahmen dieses Projektes entwickelt wurde, an den Dialogmanager (DM) weitergereicht. Der
DM ordnete jeder sprachlichen Repräsentation des Parsers eine Interpretation im aktuellen
Kontext zu, anhand dieser der Dialog weitergeführt wurde. 2 Systemäußerungen wurden vom
DM geplant und der Generierungskomponente übergeben. Abschließend wurde die Ausgabe
von der TTS-Komponente an das Telefon vorgenommen.
SUNDIAL war das erste große Projekt, das eine Verarbeitung spontansprachlicher Äußerungen
sogar von unerfahrenen Benutzern gestattete. Die aus Sicht von Peckham erfolgreiche
Umsetzung dieser Aufgabe, wurde als der Beginn einer Ära bezeichnet: At least as far as
task-oriented dialogue is concerned, the age of the conversational computer is about to dawn
(siehe [Peckham 1993]).
Die Evaluation der Systeme ist in [McGlashan 1994] näher beschrieben. Im einzelnen wurden
für das deutsche System folgende Zahlen veröffentlicht: 98 % der kontextuellen Zusammenhänge
wurden richtig zugeordnet. In 86 % aller Fälle waren Transaktionen erfolgreich.
Die WER wird mit 33,5 % über einem durchschnittlichen Vokabular von 1000 Wörtern
angegeben 3 .
2 Der DM wurde zuerst als gemeinsame Komponente entwickelt und war anwendungs- und sprachunabhängig.
Allerdings wurden einige regionale Varianten des DM konstruiert, die über eine schnellere Antwortzeit
und größere Robustheit verfügten (vgl. [Peckham 1993]).
3 Zahlen nach [McGlashan 1994], in [Peckham 1993] werden folgende Erfolgsraten genannt: für das italienische
System zwischen 51 und 96 % (unerfahrene vs. erfahrene Benutzer), für das englische System eine
durchschnittliche SR von 96 %.

28 KAPITEL 4. DIALOGSYSTEME IM ÜBERBLICK
4.1.3 TABA
Das System TABA (Telefonische Automatische Bahnfahrplan-Auskunft) ist die automatische
Bahnauskunft von Philips (siehe [Aust und Schröer 1998a; Aust und Schröer 1998b]).
Diese Anwendung ist ein sprachgesteuertes, telefonbasiertes Dialogsystem und schon seit
Februar 1994 für die Öffentlichkeit zugänglich. 4 TABA war das weltweit erste Dialogsystem,
das der gesamten Öffentlichkeit zur Verfügung stand und schon kurz nach seiner Vorstellung
so erfolgreich, daß der Hersteller eine zweite Telefonleitung benötigte, um alle Anfragen
verarbeiten zu können.
TABA ist – im Gegensatz zu vielen anderen Dialogsystemen – nicht als Machbarkeitsstudie
konstruiert worden, sondern wurde kommerziell z.B. in der Schweiz eingesetzt. Philips
hat mit TABA die erste Anwendung vorgestellt, die auf dem Philips Toolkit SpeechMania
beruht. Mit diesem Toolkit ist die Firma in der Lage, Telefonanwendungen für komplett
unterschiedliche Diskursbereiche und verschiedene Sprachen herzustellen, wie in [Aust und
Schröer 1998a] dargestellt 5 .
Als Datengrundlage für TABA wurden die Originalverbindungsdaten der 1.000 größten
Bahnhöfe Deutschlands, sowie deren Umstiegsmöglichkeiten, genutzt.
Das System erlaubt einen natürlichen Dialog mit dem Benutzer und zeichnet sich durch
aufgenommene Prompts aus, die einem Anrufer vorgespielt werden (vgl. Abschnitt 3.2.7).
Ein Benutzer bekommt damit menschliche und gut verständliche Antworten zu hören, die
ein TTS-System in dieser Qualität immer noch nicht leisten kann.
Der Spracherkenner, der für TABA eingesetzt wurde, ist der Standard-Erkenner von Philips,
wie er auch für das Philips-Diktiersystem eingesetzt wird, allerdings liefert der Erkenner
bei TABA nicht das beste Ergebnis, sondern einen Wortgraphen (siehe Abschnitt 3.2.2).
Dieser Wortgraph wird dann von den nachfolgenden Komponenten verarbeitet und daraus
die jeweils wahrscheinlichste Wortfolge ermittelt [Aust und Schröer 1998a].
Ein Parsing findet bei TABA nicht statt, da die spontansprachlichen Phänomene als zu
hinderlich angesehen werden. Statt dessen werden die Worte und Wortfolgen (Konzepte)
gesucht, die eine Bedeutung vor dem Anwendungshintergrund haben. Diese Methode wird
meist als phrase spotting bezeichnet und gilt als robust gegenüber spontaner Sprache. Für
die Definition und Suche der Konzepte wurde eine attributed stochastic context-free grammar
genutzt.
Die Dialogkontrolle wurde über eine von Philips selbst entwickelte Beschreibungssprache
abgewickelt. Diese wurde speziell für Auskunfssysteme entwickelt und erlaubt auch ein Feedback
der Sprachanalyse zur Dialogkontrolle. Es besteht außerdem die Möglichkeit, Feedback
von der Dialogkontrolle an den Spracherkenner zu senden, damit z.B. andere Lexika oder
Sprachmodelle aktiviert werden können.
Das Philips-System kann als Konversationssystem bezeichnet werden, da die zu einer Anfrage
fehlenden Daten automatisch vom System nachgefragt und im Zweifelsfall disambiguiert
werden.
Es gibt von Philips keine Zahlenangaben über die Leistungen des Systems, einzig die Erfolgsrate
von TABA wird angegeben und beträgt nach Herstellerangaben über 90 % [Aust
4 Die automatische Bahnauskunft von Philips ist unter 0241/604020 zu erreichen.
5 So wurde z.B. eine niederländische Bahnauskunft, eine Flugauskunft für die Lufthansa, eine Wetterauskunft
für RTL (Telefon: 0190/577577), ein Restaurantführer für Boston (USA) u.v.a. Anwendungen
realisiert.

4.1. AUSKUNFTSSYSTEME 29
und Schröer 1998b]. Ansonsten wird eine slot error rate (SER) angegeben, welche die Zuordnungsfehler
von einzelnen Wörtern zu Slots mißt, diese Rate wurde mit nahezu 0 %
angegeben (siehe [Aust und Schröer 1998a]).
4.1.4 Dialogos
Dialogos ist ein Echtzeit-System, das mit spontaner Sprache von erfahrenen und unerfahrenen
Benutzern per Telefon bedient werden kann (vgl. [Albesano et al. 1996]). Die Entwicklung
erfolgte beim ,Centro Studi e Laboratori Telecommunicazioni‘ (CSELT) in Turin
(Italien). Der Diskursbereich besteht aus Bahnfahrplänen in Italien, die entsprechenden Daten
stehen in einer eigenen Datenbank zur Verfügung, die mit dem System angesprochen
werden kann. Die einzelnen Komponenten sind bis auf die TTS eigene Entwicklungen, die
nur für diese Anwendung konstruiert wurden. Die verwendete TTS-Komponente ist ELO-
QUENS, ein kommerzielles Modul des CSELT.
Die sprachliche Analyse beginnt bei Dialogos mit der Analyse der besten Kette des Erkenners.
Das Parsing wird in drei Schritten ausgeführt, bei denen der erste eine syntaktische
Analyse durchführt. Die nächsten beiden Schritte sind semantische Verarbeitungen, die über
einer kontext-freien Grammatik arbeiten, dabei arbeitet der erste Schritt nur lokal, der zweite
über der gesamten Äußerung und soll auch Konflikte der beiden ersten Schritte beheben.
Der DM des Systems arbeitet auf pragmatischen Konzepten, die eine Erwartung darüber
zum Ausdruck bringen, was der Benutzer als nächstes äußern könnte. Dafür existiert ein
Kanal vom DM zum ASR, auf dem die entsprechenden Erwartungen übertragen werden.
Eventuelle Diskrepanzen zwischen diesen Erwartungen und dem tatsächlichen Benutzerverhalten
werden als Fehler in vorherigen Verarbeitungen angesehen.
Motivation für dieses Projekt war eine Machbarkeitsfrage der Telecom Italia, die vom CSELT
positiv beantwortet wurde. Dafür wurde ein groß angelegter Feldtest durchgeführt, über den
[Albesano et al. 1996] detailliert berichten. Im Rahmen dieser Versuche wurden Dialoge von
knapp 500 Benutzern und über 13.000 resultierenden Äußerungen aufgenommen und verarbeitet.
Es wurden verschiedene Szenarien und Umgebungen mit unterschiedlichen Telefonen
getestet, dabei wurde eine Wortakkuratheit von 77,4 % erreicht. Die Erfolgsrate des Systems
wurde mit 84,5 % angegeben.
4.1.5 EVAR
Das System EVAR (Erkennen, Verstehen, Antworten und Rückfragen) ist am Lehrstuhl
für Informatik 5 (Musterkennung) der Universität Erlangen-Nürnberg seit 1987 entwickelt
worden (vgl. u.a. [Ehrlich et al. 1992; Gallwitz et al. 1998]). Ziel war die Realisierung eines
telefonischen Auskunftssystems mit dem Diskursbereich der Bahnauskunft. Ein Benutzer
sollte in spontaner Sprache verschiedene Anfragen stellen können, dabei war das System in
der Lage, bei für eine DB-Anfrage noch fehlenden Daten selbständig Nachfragen zu initiieren.
Das System verfügt über eine sehr komplexe Dialogkomponente, deren erster Entwicklungsstand
in [Mast 1993] beschrieben ist.
Im Jahr 1993 wurde das System mit Mikrofon-Eingabe getestet. Auf einem Vokabular von
1081 Einträgen erreichte EVAR laut [Mast 1993] eine Wortfehlerrate von 26,3 % auf einem
Bigrammodel mit einem Echtzeitfaktor von 4.2, dabei wurden 49 % aller durchgeführten
Dialoge erfolgreich beendet.

30 KAPITEL 4. DIALOGSYSTEME IM ÜBERBLICK
EVAR ist von der Universität Erlangen-Nürnberg allerdings kontinuierlich weiterentwickelt
worden. So ist EVAR seit 1994 per Telefon erreichbar und es konnten dadurch große Datenmengen
an spontansprachlichen Mensch-Maschine-Dialogen gesammelt werden (vgl. [Eckert
et al. 1995]). Wie in [Gallwitz et al. 1998] beschrieben, wurde langfristig auch eine WWW-
Anbindung des Systems angestrebt. Außerdem wurde eine der größten Fehlerquellen in
sprachverstehenden Systemen beseitigt, indem eine Behandlung von Wörtern, die nicht im
Vokabular des Systems enthalten sind, vorgesehen wurde. Diese Out-Of-Vocabulary (OOV)
Behandlung erlaubt z.B. das Hinzufügen von neuen Wörtern zum Vokabular, durch diese
Maßnahme stieg die Erfolgsrate von Dialogen auf 69 % an. 6 Mit der im Rahmen des Projekts
VERBMOBIL konstruierten Prosodie-Komponente wurden ebenfalls einige Versuche im
Rahmen von EVAR gemacht, diese zeigten u.a., daß die einzelnen semantischen Attribute
sehr häufig durch Prosodie klar getrennt werden konnten. Die Planungen gingen bis zur
Integration einer Prosodie-Komponente in EVAR.
EVAR ist von der Architektur sehr offen konstruiert worden, so konnte der ASR sowohl
die beste Kette, als auch einen Wortgraphen an den linguistic processor (LI) senden, dieser
konnte beide Ergebnisse verarbeiten. Der LI extrahierte aus den Daten semantische Konzepte
und lieferte dieses Ergebnis an den DM, der die Vollständigkeit der für eine Anfrage nötigen
Daten überprüfte und entweder eine Rückfrage initiierte oder eine DB-Anfrage auslöste. Die
TTS-Komponente von EVAR setzte (wie auch bei TABA) bereits aufgezeichnete Sätze von
menschlichen Sprechern zusammen (reproduktive Sprachsynthese, siehe Abschnitt 3.2.7).
Im System EVAR (siehe Abschnitt 4.1.5) sind in der ersten Phase laut [Mast 1993] drei verschiedene
Strategien implementiert worden, u.a. eine robuste Dialogstrategie. Letztere dient
der unbedingten Erreichung des Dialogziels, dabei sind verschiedentlich Bestätigungsfragen
vorgesehen, um die Richtigkeit der Daten, die aus der Äußerung des Benutzers gewonnen
wurden, zu verifizieren. Mast schlägt noch eine andere Strategie vor, die bei der Unterschreitung
eines Schwellwertes der Qualität der erkannten Benutzeräußerung automatisch
eine Bestätigungsfrage setzt. 7 In [Gallwitz et al. 1998] wird dargelegt, daß das Hauptziel
von EVAR die Sammlung von spontansprachlichen Äußerungen war, daher war die verwendete
Dialogstrategie sehr offen gehalten, eine Maximierung der Erfolgsrate war daher nicht
erklärtes Ziel der Entwickler.
Die Universität Erlangen-Nürnberg hat EVAR sehr lange als Forschungsprojekt betrieben
und daraus vielfältige Erkenntnisse gesammelt. Diese wurden auch in kommerzielle Projekte
eingebracht. So ist das System FränKi (Fränkisches Kino-Informationssystem) 8 mit dem
Know-How der Universität Erlangen und des FORWISS entstanden. 9 Das System selbst
wird allerdings privat vermarktet von der Firma Sympalog.
4.1.6 JUPITER
JUPITER ist ein telefonbasiertes Wetterinformationssystem, das seine Informationen von
verschiedenen Datenbanken aus dem WWW bezieht (vgl. [Zue et al. 1997; Glass et al. 1999]).
Das System ist vom MIT in der GALAXY-Architektur 10 entwickelt worden. JUPITER ist
ein multilinguales System, das die Sprachen Chinesisch, Deutsch, Englisch, Französisch und
6 Details zur OOV-Verarbeitung siehe in [Boros et al. 1997].
7 Dieser Ansatz wird z.B. bei [Komatani und Kawahara 2000] näher dargestellt.
8 FränKI ist unter der Telefonnummer 09131/6166116 erreichbar.
9 Siehe u.a. [Grävemeyer 1999b].
10 Für nähere Informationen zu GALAXY siehe [Seneff et al. 1998].

4.1. AUSKUNFTSSYSTEME 31
Spanisch verarbeiten kann. Die Übersetzung in die Zielsprache wird immer von der internen
semantischen Repräsentation vorgenommen, die sprachunabhängig ist.
Die Wetterinformationen für Jupiter werden aus verschiedenen Datenquellen im Internet
bezogen und in eine SQL-Datenbank übernommen. Das System kann Anfragen zu 638 teilweise
internationalen Städten beantworten, sowie Anfragen zu (geographischen) Regionen
und Staaten.
Laut [Glass und Hazen 1998] wurde auf einem Vokabular von 1893 Wörtern eine durchschnittliche
WER von 11,8 % gemessen. Die einzige veröffentlichte Success-Rate ist aus dem
Jahr 1997 und beträgt 53,8 % (vgl. [Zue et al. 1997]). Sämtliche Angaben gelten allerdings
nur für englische Sprecher, da die Referenzdaten für ausländische Sprecher nicht in der für
eine solche Auswertung nötigen Menge vorlagen. Eine genaue Beschreibung der Evaluation
von JUPITER wird in [Polifroni et al. 1998] gegeben.
4.1.7 ISA
ISA (IBM Stau Applikation) ist im Rahmen eines Praktikums im Jahre 1999 von Stefan
Hamerich bei der IBM kostruiert worden und wurde seitdem kontinuierlich weiterentwickelt.
Das System wurde im Jahr 2000 erstmalig in einem größeren Rahmen präsentiert (vgl.
[Günther et al. 2000]). Es stellt allerdings immer noch einen Prototypen dar.
Die Applikation ist mit Hilfe des IBM ViaVoice Telephony Toolkit konstruiert worden
(siehe dazu im Anhang Abschnitt A.1) und stellt eine Telefonanwendung dar. Das System
ermöglicht eine Stauabfrage für alle deutschen Autobahnen und bietet verschiedene Anfrageoptionen.
Es existiert zudem eine Routenabfrage, die Staumeldungen zwischen zwei
Städten liefert. Außerdem besteht die Möglichkeit, sich Meldungen per SMS auf ein Mobiltelefon
schicken zu lassen. Anfragen erfolgen dabei in einer reaktiven Dialogstrategie (siehe
Abschnitt 2.5), es werden z.B. keine Ellipsen verarbeitet
Als Spracherkenner dient der IBM ViaVoice-Erkenner, der allerdings speziell für den Telefonkanal
aufbereitet wurde 11 . Der Erkenner übergibt die beste erkannte Wortfolge dem
IVR-Hub (Interactive Voice Response), dieser stellt die zentrale Steuerungseinheit des IBM
ViaVoice Telephony Toolkit dar. Der IVR-Hub erledigt die gesamte Verarbeitung der
Wortfolge, die vom Erkenner kommt. Dabei werden nur die für die jeweilige Anwendung relevanten
Wortfolgen als Annotationen verarbeitet. Anschließend werden entsprechende Aufrufe
an das Backend gestartet und schließlich die Ausgabe an das TTS-Modul übergeben.
Die Sprachausgabe der Staumeldungen erfolgt über eine im IBM-Toolkit integrierte TTS-
Komponente. Die Anwendungsdaten werden von einer Internetseite extrahiert, aufbereitet
und lokal zwischengespeichert. 12
ISA ist ein Dialogsystem, stellt allerdings kein Konversationssystem dar, da es z.B. keine
Bezüge zu vorherigen Äußerungen erlaubt, außerdem wird eine Anfrage immer komplett in
einem Stück erwartet, Nachfragen werden nicht gestellt (vgl. dazu Abschnitt 3.1).
Die Erfolgsrate von ISA ist mit 91,3 % sehr gut, die Wortfehlerrate liegt allerdings bei über
15 %. Da aber für eine korrekte Verarbeitung nur die jeweilig relevanten Wortfolgen von
Interesse sind, ist eine schlechte Erkennung der übrigen Worte nicht ausschlaggebend.
11 Für Details siehe [Günther et al. 2000].
12 ISA ist ebenfalls öffentlich erreichbar, und zwar unter der Nummer 06221/593129.

32 KAPITEL 4. DIALOGSYSTEME IM ÜBERBLICK
4.2 Aktionssysteme
Unter Aktionssystemen werden solche Systeme zusammengefaßt, die über den normalen
Anwendungsrahmen eines reinen Auskunftssystems hinausgehen und die Durchführung von
Aktionen gestatten, ein Beispiel dafür sind Planungssysteme.
Planungssysteme dienen der Durchführung von komplexen Aufgaben. Meist wird in einer
Domäne ein Auftrag beschrieben und dieser dann im folgenden von einem System ausgeführt.
Gängige Beispiele für solche Systeme sind Routenplanungen. Im folgenden werden
exemplarisch zwei Systeme vorgestellt, ein Agentensystem zur Steuerung einer imaginären
Güterzuggesellschaft (Abschnitt 4.2.1) und ein Terminverwaltungssystem (Abschnitt 4.2.2).
4.2.1 TRAINS
Das TRAINS-Projekt wurde 1990 an der Universität von Rochester (USA) unter James F.
Allen als Langzeitprojekt begonnen. Ziel dieses Projekts war die Entwicklung eines natürlichsprachlichen
Systems, das mittels (englischer) Konversation mit einem Benutzer interagieren
und Aufgaben bewältigen konnte (vgl. [Allen et al. 1994]). TRAINS unterscheidet sich in
der Hinsicht von anderen Systemen, als daß es kein Auskunftssystem ist, sondern ein conversational
agent, also ein Agent, der mittels Sprache gesteuert wird und der dann je nach
Auftrag Pläne durchführt. In [Sikorski und Allen 1997] wird das System deshalb als intelligent
planning assistant bezeichnet.
Das System ist für den Hintergrund der Routenplanung einer imaginären Güterzuggesellschaft
im Nordosten der USA konstruiert worden, alle Komponenten wurden jedoch so
allgemein gehalten, daß der Einsatz in einer fremden Domäne möglich ist. Auch hierbei war
nicht die Schaffung eines spezialisierten Systems das Ziel, sondern vielmehr die Konstruktion
eines sprachgesteuerten Systems im allgemeinen. Ein spezielles Ziel im Rahmen dieser
Arbeit war die Bereitstellung von Wissen für einen möglichen Anwender auf rein verbaler
Ebene. Ein Schwerpunkt von TRAINS war die Planung; die Generierung und Ausführung
von Plänen in Zusammenarbeit mit einem Dialogsystem war die große Herausforderung von
TRAINS.
Die Spracherkennung und die Sprachsynthese von TRAINS sind externe Komponenten,
die von der CMU (SPHINX-II 13 ) bzw. der Firma Entropic (TRUETALK) stammen, die
restlichen Komponenten wurden an der Universität Rochester entwickelt (siehe [Allen et al.
1996]). Die Erkennungsrate in der TRAINS-Domäne liegt, bei spontansprachlichem Input
bei 80 % bei einem Vokabular von 60.000 Einträgen. Allerdings verfügt TRAINS über eine
statistische Fehlerkorrektur, welche die Erkennungsfehler des Spracherkenners minimiert. 14
Für TRAINS wurde außerdem ein spezielles Augenmerk auf ein besonders robustes Parsing
gelegt, wie in [Allen et al. 1994; Allen et al. 1996] beschrieben. Die Evaluation eines
solchen Planungssystems ist in [Sikorski und Allen 1997] näher beschrieben. Dort wird von
einer Erfolgsrate von 94,4 % berichtet, außerdem wird die WER mit genau 20 % (ohne
Fehlerkorrektur) angegeben.
13 Siehe dazu http://www.speech.cs.cmu.edu/speech/.
14 Zur Fehlerkorrektur in TRAINS siehe [Heeman und Allen 1994].

4.3. ÜBERSETZUNGSSYSTEME 33
4.2.2 Carnegie Mellon Communicator
An der CMU wird seit 1998 an dem Carnegie Mellon Communicator gearbeitet. Dieser ist
domänenunabhängig und wurde auf den Domänen Terminplanung und Reiseplanung getestet
(vgl. [Constantinides et al. 1998]). Die Grundidee dieses Systems war die weiterführende
Entwicklung eines Dialogsystems über den Ansatz der einfachen Auskunftssysteme hinweg.
Der Communicator nutzt, wie TRAINS (vgl. Abschnitt 4.2.1) den von der CMU entwickelten
SPHINX-Erkenner sowie den PHOENIX-Parser, der ebenfalls dort entwickelt worden ist.
Das System kann über das Telefon bedient werden. Für die Reiseplanung war das System
über das Internet mit verschiedenen Fluggesellschaften verbunden, deren Daten dann für
die Dialoge verwendet wurden.
Da das gesamte System domänenunabhängig implementiert ist, wurden außerhalb des Dialogmanagers
(DM) verschiedene domain agents eingeführt, die jeweils einen eigenen Bereich
abdecken. In [Rudnicky et al. 1999] werden Agenten für die folgenden Bereiche erwähnt:
Reiseinformationen, Datums- und Zeitinterpretationen und Benutzermodell.
Trotzdem ist der DM noch für die Steuerung des gesamten Dialogs verantwortlich, er wertet
die Benutzeräußerungen aus und stößt bei Bedarf die nötigen Nachfragen an, um beispielsweise
einen Flug buchen zu können. Der Communicator ist daher ein echtes Konversationssystem.
Der Communicator verfügt außerdem über einen Überwachungsmodus, einen sogenannten
supervisor mode, in dem das System selbständig in verfahrenen Situationen einen menschlichen
Gesprächspartner hinzuzieht, um einem Benutzer auch im schlimmsten Falle eine
Anfrage zu beantworten.
Das System ist 1998 einer Evaluierung unterzogen worden, dabei wurden 82 % aller Dialoge
erfolgreich durchgeführt. Außerdem wurde die Zeit für eine erfolgreiche Flugbuchung mit
dem Communicator und einer normalen telefonischen Buchung bei einer Fluggesellschaft
mit einem menschlichen Gesprächspartner verglichen, dabei schnitt der Communicator 15
Sekunden schlechter ab, als der Telefonist. Allerdings wird dieser Vergleich in [Constantinides
et al. 1998] sofort durch die Aussage relativiert, daß der gebotene Service bei einem
menschlichen Gesprächspartner sehr viel höher sei.
4.3 Übersetzungssysteme
In diesem Abschnitt werden zwei ausgewählte Übersetzungssysteme, die auf natürlichsprachlichen
Dialogen basieren, vorgestellt. Diese Systeme dienen der mehrsprachigen Benutzung
unter Verwendung von Dialogen. Sie haben grundsätzlich nicht nur mit den Problemen der
Spracherkennung und der Dialogsteuerung zu kämpfen, sondern zusätzlich mit den Schwierigkeiten
einer maschinellen Übersetzung (engl. machine translation) (MT). MT-Systeme
stellen somit eine Synthese aus Spracherkennung, -verarbeitung und maschineller Übersetzung
dar. Da der Schwerpunkt der vorliegenden Arbeit auf Dialogsystemen liegt, wird im
folgenden nur auf die Dialogeigenschaften der jeweiligen Systeme eingegangen. Die Übersetzungsleistungen
der Systeme wird nicht näher betrachtet.
Es gibt inzwischen eine große Anzahl verschiedenster dialogfähiger Übersetzungssysteme,
im folgenden sollen allerdings nur zwei exemplarisch vorgestellt werden. Insbesondere das
System VERBMOBIL (Abschnitt 4.3.2) ist dabei hervorzuheben, da viele Erkenntnisse aus

34 KAPITEL 4. DIALOGSYSTEME IM ÜBERBLICK
diesem System in die gesamte Forschung für Sprachverarbeiter in Deutschland eingegangen
sind. Außerdem wird das System JANUS (Abschnitt 4.3.1) vorgestellt, welches zum Teil
ebenfalls in Deutschland entstanden ist.
4.3.1 JANUS
JANUS ist ein Übersetzungssystem, das seit Ende der 80er Jahre maßgeblich an der CMU
und der Universität Karlsruhe entwickelt wird (siehe u.a. [Waibel 1996]). Entwicklungspartner
sind außerdem Siemens und ATR (Japan). JANUS wird mit spontansprachlichen
Eingaben in einer Terminvereinbarungsdomäne betrieben. Einige Erkenntnisse von JANUS
sind wegen teilweise identischen Partnern und der übereinstimmenden Domäne in VERBMOBIL
(siehe Abschnitt 4.3.2) eingeflossen.
Das System kann Eingaben in deutscher, englischer und spanischer Sprache verarbeiten und
Ausgaben zusätzlich auf Japanisch und Koreanisch produzieren. Das Lexikon von JANUS ist
als Vollformlexikon implementiert und verfügt über mehr als 3000 Einträge für die englische
Sprache.
Das JANUS-System besteht aus drei Hauptmodulen: der ASR, dem MT-Modul und der
Sprachsynthese. Das ASR-Modul berechnet anhand von HMM’s und einem statistischen
LM den besten Wortgraphen. Dieser wird um Redundanzen verkürzt und dann der MT-
Komponente übergeben. Diese besteht laut [Lavie et al. 1997] aus zwei voneinander unabhängigen
Teilen, dem General LR Modul (GLR), das sehr akkurate Ergebnisse liefert,
sowie dem für die robuste Verarbeitung konstruierten PHOENIX-Modul. In beiden Modulen
erfolgt die sprachliche Analyse, deren Ergebnis Interlingua genannt wird und eine
sprachunabhängige Repräsentation darstellt. Nach [Waibel 1996] wird die Analyse in JA-
NUS nur nach semantischen Kriterien vorgenommen, eine syntaktische Analyse findet nicht
mehr statt, um eine robustere Verarbeitung zu erlauben.
Das GLR-Modul erhält den String des Erkenners und parst diesen zuerst, anschließend wird
die lexikalische Analyse durchgeführt. Der Parser nutzt die Grammatikregeln eines unifikationsbasierten
Formalismus, um die Interlingua zu erhalten, die in Form einer Feature-Struktur
vorliegt. Der Parser ist robust gegen spontansprachliche Phänomene, indem nicht verarbeitbare
Teile der Äußerung ausgelassen werden. Nach dem Parsing wird die Interlingua vom
Diskurs-Prozessor ergänzt und die einzelnen semantischen Dialogeinheiten (engl. semantic
dialogue unit) (SDU) werden zugewiesen, wobei eine SDU grob mit einem Sprechakt
korrespondiert (vgl. [Lavie et al. 1997]). Diese Einheiten werden in der Interlingua weiterverarbeitet
um dann schließlich in die entsprechende Zielsprache transferiert zu werden.
Das PHOENIX-Modul besteht nur aus dem PHOENIX-Parser und einem Generator, der das
Ergebnis in die Zielsprache überträgt. Die semantische Analyse erfolgt mit dem PHOENIX-
Parser, der auf semantischen Grammatiken arbeitet (vgl. [Waibel 1996]). Dabei wird eine
Äußerung in Slots von sogenannten semantischen Frames verarbeitet. Diese Frames werden
dann in Interlingua repräsentiert und weitergegeben, um daraus den entsprechenden Ausgabestring
zu erstellen.
Das Ergebnis des jeweiligen MT-Moduls wird dem Generierungsmodul übergeben, das den
Ausgabestring in der Zielsprache produziert. Bei diesem Modul handelt es sich um ein kommerzielles
Modul, das nicht an einer der beteiligten Universitäten entwickelt wurde.
Die Evaluation von JANUS ist in [Gates et al. 1997] näher dargestellt. Da es sich bei JANUS
um ein MT-System handelt, sind die entsprechenden Werte allerdings nicht mit denen der
Systeme aus Abschnitt 4.1 zu vergleichen. Der Vollständigkeit halber sollen trotzdem einige

4.3. ÜBERSETZUNGSSYSTEME 35
Zahlen vorgelegt werden: die WER wird mit 33,2 % angegeben, bei der End-To-End Evaluation
wurden mit dem GLR-Modul 54 % aller Äußerungen richtig verarbeitet, 49 % wurden
mit dem PHOENIX-Modul korrekt verarbeitet. Beide Zahlen gehen von einem Input des
ASR aus. Unter Vernachlässigung der Fehlerrate des Erkenners wurden über 78 % mit dem
GLR und über 70 % mit dem PHOENIX-Modul korrekt verarbeitet.
4.3.2 VERBMOBIL
VERBMOBIL war ein langfristig angelegtes, interdisziplinäres Projekt des Bundesministeriums
für Bildung, Wissenschaft, Forschung und Technologie (BMBF). Ziel dieses Projekts war die
Entwicklung eines mobilen Übersetzungssystems für face-to-face Situationen oder den Telefonzugriff
von menschlichen Dialogpartnern für die Domäne Terminabsprache. Das Projekt
wurde vom BMBF als Verbundvorhaben unter der Beteiligung verschiedener Wirtschaftsunternehmen,
Universitäten und Forschungszentren von 1993 bis 2000 gefördert (vgl. z.B.
[Wahlster 1993b; Wahlster 1997; Wahlster 2000]). 15,16
Der Name VERBMOBIL leitet sich aus dem Ziel des Projekts ab, das System sollte eine verbale
Kommunikation mit ausländischen Gesprächspartnern in mobilen Umgebungen gestatten
(vgl. [Wahlster 2000]). Das VERBMOBIL-System sollte diese Kommunikation für spontansprachliche
Eingaben von bestimmten Dialogdomänen der Sprachenpaare deutsch – englisch
und deutsch – japanisch leisten. Diese Domänen bestanden während der ersten Projektphase
(1993 – 1996) aus Terminverhandlungsdialogen von Geschäftspartnern, in der zweiten
Projektphase (1997 – 2000) stand zusätzlich die Übersetzung von Dialogen der Domänen
Reiseplanung und Hotelreservierung im Vordergrund, außerdem sollte eine Fernwartung von
PC’s mit VERBMOBIL international möglich sein (siehe u.a. [von Hahn und Amtrup 1996;
Wahlster 2000]).
Im Zusammenhang mit der Konstruktion des Systems wurde ein sehr großer Aufwand in
die Sammlung und Analyse von Dialogen der entsprechenden Domänen investiert, so wurden
nicht nur verschiedene Aufnahmetechniken und Analysemethoden getestet, es wurden
auch großangelegte WOZ-Experimente gemacht und viele menschliche Dialoge der Systemdomänen
beobachtet, um Erkenntnisse aus diesen Daten zu gewinnen (vgl. z.B. [Jekat-
Rommel 1994; Jekat et al. 1997; Krause 1997; Fischer 1999; Jekat und von Hahn 2000]).
Im Laufe der Projektdauer wurden deshalb 3.200 Dialoge aufgenommen, die sich zusammen
auf über 181 Stunden belaufen, die transkribierten Dialoge benötigen mehr als 21 GB Platz
und sind auf 56 CD-ROM’s verteilt (nach [Karger und Wahlster 2000]).
Die Endversion von VERBMOBIL ist in mehrere Module unterteilt, die über zahlreiche Kommunikationsschnittstellen
miteinander verbunden sind. Einen groben Überblick über die
Systemarchitektur gibt die Abbildung 4.1; sie stellt allerdings einen vereinfachten Blick auf
die Architektur von VERBMOBIL dar. Laut [Wahlster 2000] vereinigt das System VERBMOBIL
69 Systemkomponenten in sich. Die Hauptkomponenten werden im folgenden kurz vorgestellt:
Da es sich bei VERBMOBIL um ein multilinguales System handelt, existieren je Sprache ein
15 Siehe auch: http://www.dfki.de/verbmobil.
16 Projektteilnehmer waren: CSLI (USA), DaimlerChrysler, DASA/Temic, DFKI, HU Berlin, Philips, RW-
TH Aachen, Siemens, TU Berlin, TU Braunschweig, TU Dresden, TU München, U Bielefeld, U Bochum, U
Bonn, U des Saarlandes, U Erlangen-Nürnberg, U Hamburg, U Karlsruhe, U München, U Stuttgart und U
Tübingen. Folgende Teilnehmer waren nur in der ersten Projektphase von 1993-96 beteiligt: Alcatel SEL,
ATR (Japan), CAP Debis Systemhaus, CMU (USA), IBM, U Hildesheim, U Kiel und U Ulm. (vgl. [Karger
und Wahlster 2000]).

36 KAPITEL 4. DIALOGSYSTEME IM ÜBERBLICK
Abbildung 4.1: Die Benutzeroberfläche von VERBMOBIL
Erkenner und ein Synthesemodul, im ganzen existieren daher sechs sprachabhängige Komponenten,
alle anderen Module im System sind allerdings sprachunabhängig. Die Erkenner
liefern jeweils 17 einen Worthypothesengraphen im VERBMOBIL-Format an die Parsing-
Module. Vorher werden die Daten der Erkenner jedoch noch von der Prosodiekomponente
angereichert (siehe dazu u.a. [Mast et al. 1996; Warnke et al. 1997]). In VERBMOBIL existieren
drei Parser, die alle auf verschiedenen syntaktischen Wissensquellen basieren. Es
gibt einen Chart-Parser, einen statistischen LR-Parser (in der Abbildung als ”
Integrierte
Verarbeitung“ dargestellt) und einen HPSG-Parser für die tiefe Analyse ( ”
deep analysis“).
Die Ergebnisse der ersten beiden Parser werden an ein Modul geschickt, um dort in das
VERBMOBIL-eigene Graphenformat transferiert zu werden (das Modul ist in der Abbildung
als ”
semantic construction“ bezeichnet). Die Hypothesengraphen aller Parser werden anschließend
miteinander kombiniert, um einen möglichst vollständigen Graphen zu erhalten.
Die statistische Übersetzung beginnt bereits mit dem ersten Ergebnis des Erkenners, dem
nur prosodische Informationen hinzugefügt werden. Die Ergebnisse dieser Komponente sind
eine Wortfolge in der Zielsprache und eine Bewertung des gefundenen Ergebnisses. Desweiteren
gibt es zwei MT-Module der fallbasierten Übersetzung. Eine Komponente basiert
auf Substrings, die andere auf 30.000 Übersetzungs-Templates. Außerdem existiert noch ein
MT-Modul, das auf Dialogakten basiert. Dafür wurden in VERBMOBIL 19 verschiedene Dialogakte
mit einer eigenen Hierarchie definiert (vgl. [Jekat et al. 1995; Alexandersson et al.
1997; Alexandersson et al. 1998]). Die Dialogakt-Komponente liefert eine Frame-Repräsen-
17 Wichtig zu bemerken ist, daß VERBMOBIL kein push-to-talk System ist, vielmehr wird eine openmicrophone-Technologie
verwendet (siehe [Wahlster 2000]).

4.4. VERGLEICH DER VERSCHIEDENEN SYSTEME 37
tation als Ergebnis, die in einem Template-Verfahren in ihre entsprechende Übersetzung
transformiert werden. Abschließend wird aus allen gelieferten Übersetzungen die mit der
besten Bewertung ausgewählt, um an die Dialogkomponente übergeben zu werden. Die Dialogkomponente
besteht aus einem Planer, der einen Dialog in Dialogphasen strukturiert.
Dialogakte sind dabei die Blätter einer Baumstruktur, welche die Dialogstruktur repräsentiert.
Die Dialogphasen sind vor allem für die Auflösung von Ellipsen oder Anaphoren von
Bedeutung. Das Transfer-Modul kann eine Kontext-Suche starten, falls die jeweiligen Graphen
unterspezifiziert sind, andernfalls werden die korrekten Graphen der Generierungs-
Komponente übergeben. Diese generiert einen Satzplan bestehend aus lexikalischen Feldern
und semantischen Rollen. Abschließend wird die Ausgabe in der gewünschten Zielsprache
synthetisiert.
Obwohl VERBMOBIL als Übersetzungssystem verstanden wird, ist dieser Terminus hier mißverständlich.
Die Aufgabe des Systems liegt in der Übersetzung der kommunikativen Ziele
(engl. communicative goals) eines Benutzers, dabei lagen bei den zu übersetzenden Äußerungen
häufig spontansprachliche Phänomene vor, insbesondere Selbstkorrekturen, Hesitationen,
Auslassungen etc. Die Übersetzung sollte jedoch grammatisch wohlgeformt sein, somit
waren Selbstkorrekturen usw. aufzulösen.
Das Vokabular von VERBMOBIL besteht laut [Karger und Wahlster 2000] aus 19.594 Wortformen,
davon 10.157 deutsche, 6.871 englische und 2.566 japanische. Die Evaluation des
Gesamtsystems und ihre Ergebnisse sind bei [Tessiore und von Hahn 2000] beschrieben.
Evaluiert wurde größtenteils über der ersten und zweiten Domäne (Terminabsprache und
Reiseplanung). Dabei wurden Dialoge mit einer durchschnittlichen Rate von 86,8 % erfolgreich
beendet.
4.4 Vergleich der verschiedenen Systeme
Um einen abschließenden und zusammenfassenden Überblick über die in diesem Kapitel vorgestellten
Dialogsysteme zu ermöglichen, werden diese im folgenden miteinander verglichen.
Betrachtet werden alle in den Abschnitten 4.1, 4.2 und 4.3 vorgestellten Systeme.
Eine Bewertung der verschiedenen Systeme gegeneinander soll hier nicht erfolgen, da weder
die jeweiligen Ausgangssituationen noch die Möglichkeiten bei der Entstehung der verschiedenen
Systeme miteinander vergleichbar sind.
Die Vergleichsdaten sind in Tabelle 4.1 zusammengefaßt, um einen vollständigen Überblick
über die verschiedenen vorgestellten Dialogsysteme zu ermöglichen. Die Übersetzungssysteme
sind ebenfalls mit aufgeführt, ihre Erfolgsraten wurden allerdings eingeklammert, da
diese vor allem durch die jeweilige Übersetzungsqualität bestimmt sind, die nicht Teil dieser
Arbeit ist.
Die Tabelle wird in Kapitel 5 noch einmal aufgegriffen, um einen Vergleich von ShopTel mit
den behandelten Systemen zu ermöglichen.

38 KAPITEL 4. DIALOGSYSTEME IM ÜBERBLICK
System Hersteller Jahr L LEX WER SR LM Eingabe
SPICOS Siemens, Philips 1 1990 D 1200 9 2 k.A. Tri Mikrofon
SUNDIAL CAP Gemini (F) 3 1993
4
1000 34 86 Bi Telefon
TABA Philips 1994 D k.A. k.A. 90 Bi Telefon
Dialogos CSELT (I) 1996 I 3471 23 85 Bi Telefon
EVAR U Erlangen 1998 D k.A. k.A. 69 Bi Telefon
JUPITER MIT (USA) 1998
5
1893 12 54 Bi Telefon
ISA IBM 2000 D 500 15 91 Tri Telefon
TRAINS U Rochester (USA) 1995 E 60000 20 6 94 7 Tri Mikrofon
Communicator CMU (USA) 1998 E k.A. k.A. 82 Tri Telefon
JANUS CMU (USA) 8 1997
9
3000 33 (54) Tri Mikrofon
VERBMOBIL CSLI (USA) 10 2000
11
19594 k.A. (87) Tri Mikrof. 12
1 und IPO (NL)
2 sprecherabhängige Erkennung
3 desweiteren CNET (F), CSELT (I), Daimer-Benz, U Erlangen, IRISA (F), Logica (GB), Politechnico di
Torino (I), Sarin Telematica (I), Siemens, U of Surrey (GB), Vocalis (UK)
4 D E F I (Zahlenangaben nur für D)
5 C D E F S (Zahlenangaben nur für E)
6 ohne statistische Fehlerkorrektur
7 mit Fehlerkorrektur
8 mit U Karlsruhe
9 D E S (Ausgabe zusätzlich auch in J K)
10 außerdem DaimlerChrysler, DASA/Temic, DFKI, HU Berlin, Philips, RWTH Aachen, Siemens, TU
Berlin, TU Braunschweig, TU Dresden, TU München, U Bielefeld, U Bochum, U Bonn, U des Saarlandes,
U Erlangen, U Hamburg, U Karlsruhe, U München, U Stuttgart, U Tübingen; nur von 1993-96: Alcatel
SEL, ATR (J), Debis, CMU (USA), IBM, U Hildesheim, U Kiel, U Ulm
11 D E J
12 auch Telefon, Zahlenangaben beziehen sich jedoch auf Mikrofon-Betrieb
Erklärung der Spaltenbezeichnung:
L: Language (Sprachen, die das entsprechende System versteht: C = chinesisch, D =
deutsch, E = englisch, F = französisch, I = italienisch, J = Japanisch, K = Koreanisch,
S = spanisch) – LEX: Lexikon (bezeichnet die Vokabulargrösse im Lexikon) – WER: Word
Error Rate (Wortfehlerrate) Werte auf ganze Zahlen gerundet – SR: Success Rate (Erfolgsrate)
Werte gerundet – LM: Language Model (bezeichnet das verwendete Sprachmodell: Bi
= Bigramm, Tri = Trigramm)
Tabelle 4.1: Vergleich der vorgestellten Systeme

Kapitel 5
SHOPTEL
Im Rahmen dieser Arbeit ist das System ShopTel entstanden. Dieses ist mit Hilfe der
IBM ViaVoice Telephony Natural Language Tools 1 entwickelt worden, die auf dem IBM
ViaVoice Telephony Toolkit 2 aufbauen. Ziel war die Entwicklung eines Konversationssystems
für eine automatische Bestellaufnahme. Mit Hilfe dieses Systems sollten Kunden
Bestellungen ausführen und Informationen über die ausgewählten Produkte erhalten können.
ShopTel sollte in seiner Leistungsfähigkeit einem einfachen Auskunftssystem durch die
Möglichkeit der Durchführung dieser Bestellaktion überlegen sein. Bedingt durch diese Vorgabe
handelte es sich bei der Entwicklung von ShopTel nicht um die Konstruktion eines
Auskunftssystems, sondern um die eines Aktionssystems (vgl. Abschnitt 4.2).
Der nächste Abschnitt wird die Entwurfsziele von ShopTel behandeln, anschließend wird
das Szenario des Systems dargestellt, um dann die Architektur des Systems detailliert zu
beschreiben. Schließlich wird die Evaluation des Systems mit ihren Ergebnissen vorgestellt.
5.1 Ziele
ShopTel wurde implementiert, um am Beispiel dieses Systems Dialogsegmente (siehe Abschnitt
2.2.2) entwickeln und untersuchen zu können. 3 Dafür mußte ShopTel als Konversationssystem
implementiert werden, das auch komplexe Nachfragen verstehen und Rückfragen
stellen konnte (vgl. dazu Abschnitt 3.1). Um diese Anforderungen in einem für Benutzer interessanten
und realitätsnahen Kontext zu erfüllen, wurde die Domäne einer automatischen
Bestellaufnahme gewählt. Für die Wahl dieser Domäne sprach zusätzlich die hohe Komplexität
von dort möglichen Dialogen. Eine besondere Rolle hinsichtlich der Komplexität des
Systems wurde auch der zugrundeliegenden Produktauswahl zuteil, die zu einem großen Teil
für die lexikalische und semantische Vielfalt des Systems verantwortlich ist.
ShopTel sollte in der gewählten Domäne herkömmlichen Auskunftssystemen, wie im Abschnitt
4.1 beschrieben, weit überlegen sein. Es war nicht nur Ziel, einem Benutzer Informationen
über verschiedene Produkte zur Verfügung zu stellen, es sollte auch die Möglichkeit
1 Vgl. dazu z.B. [Davies et al. 1999; Papineni et al. 1999; Mast et al. 2000] und den Anhang.
2 Siehe dazu auch Abschnitt 4.1.7, den Anhang und [Günther et al. 2000].
3 Die entsprechenden Segmente werden in Kapitel 6 vorgestellt.

40 KAPITEL 5. SHOPTEL
geben, mit dem System sinnvolle Aktionen ausführen zu können. Daher sollte eine Bestellung
mit ShopTel möglichst realitätsnah durchgeführt werden können. Um dies zu ermöglichen,
wurde eine Auswahl existierender Produkte in ShopTel aufgenommen. Wichtig bei dieser
Auswahl war auch die Existenz verschiedener Granularitäten, um unterschiedliche Mengen
und Größenangaben zu implementieren und anschließend auch verarbeiten zu können.
Im einzelnen mußten bei der Entwicklung und Implementation des Systems folgende Punkte
besonders berücksichtigt werden:
• intuitiver Ablauf des Bestellvorgangs mit einer sinnvollen Anordnung der verschiedenen
Dialogsegmente
• keine zu starke Einschränkung des Benutzers durch gesteuerte Dialoge, trotz nötiger
Benutzerführung
• möglichst freie Dialogführung, um dem Benutzer eine echte Auswahl unter den zur
Verfügung stehenden Segmenten anzubieten
In der obigen Aufzählung wird damit schon das Dilemma der Implementation deutlich: eine
gewisse Benutzerführung ist zwar erforderlich, um eine grobe Lenkung des Benutzers
im System zu ermöglichen und ihn damit letztendlich zum Dialogziel zu führen, allerdings
soll ein Anrufer nicht von ShopTel in ein bestimmtes Dialogmuster gezwungen werden.
Vielmehr soll er seine Bestellung möglichst frei formulieren können und dann im Idealfall
nur durch gezielte Nachfragen gesteuert werden. Dieses Konzept kann optimal mit dem –
in den IBM ViaVoice Telephony Natural Language Tools enthaltenen – Dialogmanager 4
(DM) verwirklicht werden. Allgemein galt es, das zu erstellende System in dieser Hinsicht
möglichst frei zu gestalten, dies war mit der Benutzung der IBM-Tools ohne große Kompromisse
möglich.
Desweiteren waren auch die üblichen Qualitätseigenschaften von Software zu beachten, dies
sind im einzelnen:
• Möglichkeit der späteren Erweiterung des Systems, um beispielsweise neue Produkte
oder Kunden hinzuzufügen
• eine spätere Wiederverwendbarkeit in anderen Kontexten sollte ebenfalls ermöglicht
werden, um die Implementation von späteren Dialogsystemen auf der NLU-Umgebung
zu erleichtern
• bedingt durch die vorgegebene Architektur der IBM ViaVoice Telephony Natural
Language Tools war eine Modularisierung der einzelnen Komponenten von ShopTel
zwingend vorgesehen
Selbstverständlich sollten auch die Qualitätsmerkmale aus Anwendersicht, und zwar vor
allem die Funktionserfüllung beachtet werden. Da es sich aber bei der zu erstellenden Anwendung
um einen Prototypen – also eine Machbarkeitsstudie – handelt, stand dieses Ziel
nicht im unmittelbaren Vordergrund.
4 Für Details dazu siehe Abschnitt 5.3.13.

5.2. SZENARIO 41
5.2 Szenario
Das Szenario von ShopTel sah anfangs vor, daß ein Benutzer sich vor dem Bestellvorgang
authentifizieren muß. Dies sollte durch Nennung einer persönlichen Kundennummer und
des Namens geschehen. Benutzer, die noch keine Kundennummer haben, sollten ShopTel
als Probebenutzer verwenden können. Details zur Probebenutzung sollen dem Benutzer in
einem Hilfetext erläutert werden.
Nach der erfolgten Anmeldung kann ein spezifisches Produkt oder auch eine Produktkategorie
geäußert werden, die im folgenden disambiguiert wird. Das nach der Disambiguierung
und Bestätigung durch den Benutzer ausgewählte Produkt kann dann in beliebiger Stückzahl
bestellt werden, wobei bei einigen Produktarten (wie z.B. bei Wein) verschiedene Produkteinheiten
(im vorliegenden Fall Flaschen und Kisten) unterschieden werden.
Es ist möglich, beliebig viele Produkte hintereinander zu bestellen, dies wird durch eine Wiederholung
des Bestellsegments erreicht. Erst nach expliziter Angabe, nichts mehr bestellen
zu wollen, wird der Bestellmodus verlassen und der Zahlungsdialog angestoßen. In diesem
wird zuerst nach der gewünschten Zahlungsart gefragt. Es werden Kreditkarte, Rechnung,
Nachnahme, Bankeinzug und Überweisung zur Auswahl stehen. Als nächstes werden die
spezifischen Daten der gewählten Zahlungsart nachgefragt, dabei ist darauf zu achten, nur
diese spezifischen Daten zu erfragen.
Bei einer Probebestellung endet hier der Durchlauf durch ShopTel, nur registrierte Benutzer
müssen im folgenden noch die gewünschte Lieferadresse angeben. Dafür werden ein Straßenname,
eine Postleitzahl und ein Ortsname benötigt. Für den Anfang sollen hier nur wenige
ausgewählte Adressen zur Eingabe möglich sein, um den Vokabularumfang nicht zu stark
anwachsen zu lassen.
Im folgenden Abschnitt wird die Architektur und Funktionsweise von ShopTel beschrieben.
Insbesondere sollen die Unterschiede zu den allgemeinen Komponenten eines Dialogsystems,
wie in Abschnitt 3.2 beschrieben, dargestellt werden.
5.3 Architektur
ShopTel wurde mit dem IBM ViaVoice Telephony Toolkit (VVT-Toolkit) entwickelt. Der
Vorteil dieser Vorgehensweise liegt in der Nutzung bereits vorhandener oder nur anpassungsbedürftiger
Komponenten, wie z.B. von Telefonie-Modul, Spracherkenner und TTS-
Komponente. Die Verwendung der IBM ViaVoice Telephony Natural Language Tools
(NLU-Tools) ermöglichte ferner die Nutzung des Dialogmanagers, sowie des diesen Tools
zugrundeliegenden Parsers. Das Toolkit und die Tools werden in den folgenden Abschnitten
nur soweit Betrachtungsgegenstand sein, wie sie für die jeweiligen Module von ShopTel von
Interesse sind, eine nähere Darstellung der IBM-Werkzeuge wird im Anhang gegeben.
Da ShopTel mit den NLU-Tools der IBM erstellt worden ist, wird es im folgenden auch als
NLU-Anwendung bezeichnet.
Die gesamte Architektur von ShopTel ist in Abbildung 5.1 dargestellt. Die einzelnen Komponenten
und Module werden in den folgenden Abschnitten eingehend betrachtet. Für eine
grundsätzliche Funktionsbeschreibung der einzelnen Komponenten möchte ich auf Abschnitt
3.2 verweisen, dort erfolgte eine grundsätzliche Beschreibung der Komponenten eines
Dialogsystems.

42 KAPITEL 5. SHOPTEL
Abbildung 5.1: Architektur von ShopTel
5.3.1 Telefonie-Modul
Das Telefoniemodul ist im VVT-Toolkit enthalten und stellt die Schnittstelle zwischen Anwendung
und Telefon dar. Es kann Anrufe annehmen, leistet eine DTMF-Erkennung, detektiert
Äußerungsanfänge und -enden und übernimmt außerdem die Kanalüberwachung. Für
die Bereitstellung der Funktionalität werden eine Telefoniekarte und eine angeschlossene
Telefonleitung benötigt.
5.3.2 Spracherkenner
Die automatische Spracherkennung (engl. automatic speech recognition) (ASR) ist ebenfalls
bereits im IBM ViaVoice Telephony Toolkit enthalten. Der verwendete Spracherkenner
im IBM ViaVoice Telephony Toolkit basiert auf dem marktüblichen IBM ViaVoice-
Dekoder 5 , um jedoch auch eine Erkennung der Daten aus dem Telefonkanal leisten zu
können, ist der Erkenner zusätzlich mit 8 kHz-Daten, sowie mit von 20 kHz in 8 kHz transformierten
Sprachsignalen trainiert worden 6 . Dabei ist auch ein gesondertes Training mit
Daten von Mobiltelefonen vorgenommen worden, deren Datenqualität schlechter als die von
stationären Telefonen ist. 7
Damit die ASR in eine NLU-Anwendung integriert werden kann, muß ein Sprachmodell
(engl. language model) (LM), das den konkreten Anwendungsdaten der Domäne entstammen
sollte, berechnet werden (vgl. dazu Abschnitt 3.2.2).
Der Erkenner bezieht seine Daten über den IVR-Hub (siehe Abschnitt 5.3.4) vom Telefonie-
Modul und liefert in ShopTel die ”
beste Kette“ und eine Bewertung dieser Daten an den
IVR-Hub zurück.
5 Siehe dazu [Bahl et al. 1993].
6 Für nähere Angaben zum Dekoder im IBM ViaVoice Telephony Toolkit siehe auch [Davies et al. 1999;
Günther et al. 2000; Mast et al. 2000].
7 Vergleiche dazu auch [Vuerinckx und Vanpoucke 2000].

5.3. ARCHITEKTUR 43
5.3.3 TTS-Modul
Die Text-To-Speech-Komponente (TTS), die für ShopTel verwendet wird, ist ebenfalls im
IBM ViaVoice Telephony Toolkit enthalten und ist als IBM Outloud Bestandteil von IBM
ViaVoice.
IBM Outloud ist ein formantbasiertes TTS-Modul, das für bekannte Wörter auf ein internes
Lexikon zurückgreift, für unbekannte Wörter ist die Synthese phonbasiert. Für das IBM
ViaVoice Telephony Toolkit gibt es optimierte Einstellungen für das Telefon. Je nach
installierter Sprachversion ist auch die TTS-Komponente sprachabhängig.
In ShopTel wird dem TTS-Modul ein beliebiger String übergeben, der synthetisiert und
über das Telefon an den Benutzer übertragen wird.
5.3.4 IVR-Hub
Der IVR-Hub (Interactive Voice Response) ist ein wesentlicher Bestandteil einer Anwendung,
die mit dem IBM ViaVoice Telephony Toolkit erstellt wird. Er koordiniert die einzelnen
Bestandteile des Systems und leitet sämtliche Daten an die jeweiligen Empfängerkomponenten
weiter.
Der IVR-Hub ist auch die Komponente, die alle anderen Module startet und bei Bedarf neu
startet, um so bei Fehlern oder Abbrüchen einen kompletten Systemneustart zu verhindern.
Er ist bei ShopTel als Skript in der Sprache Tcl implementiert. Dieses Skript hat Zugriff
auf einige externe Programmbibliotheken, die im IBM-Toolkit enthalten sind, um damit die
Steuerung des Erkenners und der Telefonieumgebung zu ermöglichen.
Das Skript des IVR-Hub ist anwendungsabhängig, da ihm alle anderen Komponenten bekannt
sein und systemspezifische Besonderheiten beachtet werden müssen (z.B. zusätzlicher
Versand von SMS-Nachrichten 8 , Backendzugriffe, etc.).
5.3.5 Backend und Datenbank
Das Backend stellt das Bindeglied zwischen der Datenbank (engl. database) (DB) und dem
System dar. Es wandelt die eingehenden Anfragen in SQL-Abfragen für die Datenbank um
und ist ebenfalls als Tcl-Skript implementiert worden.
Die Datenbank ist eine reine SQL-Datenbank und enthält alle Daten, die für die Anwendung
relevant sind. Diese Daten müssen von Hand hinzugefügt werden, eine automatische
Datenaktualisierung ist zur Zeit nicht vorhanden. Es existieren momentan je Produktkategorie
eine Datenbank, ein Lookup-Table und eine DB für die Kundendaten. Die Datenbanken
werden über eine ODBC-Schnittstelle vom Backend angesteuert.
Das Backend stellt SQL-Anfragen an die Datenbank, welche die jeweils resultierenden Daten
an das Backend zurückliefert. Das Backend sendet die jeweils von der DB erhaltenen
Daten über den IVR-Hub an die entsprechend anfragende Komponente im jeweils verlangten
Format. Die gesamte Disambiguierung von Datensätzen erfolgt ebenfalls im Backend. In
deren Rahmen wird neben den Daten ein return code (RC) zurückgegeben, der im DM eine
differenzierte Behandlung von verschiedenen Daten erlaubt (siehe Abschnitt 5.3.13).
8 Siehe z.B. [Günther et al. 2000; Mast et al. 2000].

44 KAPITEL 5. SHOPTEL
Eine Erweiterung der DB um neue Datensätze oder sogar neue Produktkategorien kann
ohne weiteres vorgenommen werden. Auch können die vorhandenen Daten problemlos ausgetauscht
oder aktualisiert werden.
5.3.6 Grundlagen der NLU-Tools
Es gibt zwei Ansätze der IBM, um Telefonieanwendungen zu entwickeln: das IBM ViaVoice
Telephony Toolkit (VTT) und die IBM ViaVoice Telephony Natural Language Tools
(NLU-Tools). Es kann auch nur mit ersterem eine Anwendung erstellt werden (wie z.B.
ISA, Abschnitt 4.1.7), das Toolkit erlaubt allerdings keine sprachlichen Elipsen. Anwendungen,
die nur mit dem VTT erstellt werden, sind grundsätzlich grammatikbasiert. Bei
VTT-Anwendungen existiert also eine Grammatik, die alle möglichen Äußerungen eines Benutzers
beschreibt, somit werden auch nur die Äußerungen weiterverarbeitet, die in genau
der vorliegenden Form in der Grammatik implementiert sind.
Mit den NLU-Tools besteht jedoch die Möglichkeit, ein Konversationssystem (engl. conversational
system) (vgl. Abschnitt 3.1) zu erstellen. Dazu wird das VVT als Grundlage gebraucht,
für die weitergehende Funktionalität werden dann zusätzlich die NLU-Tools benötigt. Diese
Tools greifen vor allem auf einen ausgereiften Parser zurück, der nicht grammatikbasiert ist,
sondern auf Beispieldaten trainiert wird (siehe dazu Abschnitt 5.3.8).
Alle im folgenden aufgezählten Komponenten von ShopTel sind Teil der NLU-Tools. Sie
alle werden vom IVR-Hub (vgl. Abschnitt 5.3.4) über das ControlCenter (Abschnitt 5.3.7)
gesteuert und verwaltet. Die VVT-Komponenten, die oben beschrieben wurden, sind in ihrer
Funktionsweise von denen der NLU-Tools unabhängig.
5.3.7 NLU ControlCenter
Das NLU ControlCenter stellt die Verbindung zwischen dem IVR-Hub (Abschnitt 5.3.4) und
den Komponenten der NLU-Tools her. Alle bisher in diesem Kapitel aufgeführten Module
sind Bestandteil des Toolkits, die folgenden Komponenten sind ausnahmslos den NLU-Tools
zugehörig.
Das ControlCenter gibt so z.B. erkannte Daten zuerst an den Classer, dann an den Canonicalizer
und schließlich an den Parser weiter. Die gesammelten Daten dieser Durchgänge
werden dem Dialogmanager zur Auswertung übergeben, etwaige DB-Anfragen werden über
den IVR-Hub an das Backend weitergeleitet.
5.3.8 Parsing in den NLU-Tools
In Abschnitt 3.2.3 habe ich bereits allgemein die Funktionsweise eines Parsing-Moduls dargestellt.
Dort wurde auch darauf hingewiesen, daß der Parsingvorgang häufig als linguistische
Aufgabe angesehen wird und daher mit Grammatiken gelöst wird. Doch die komplette
Erstellung einer Grammatik kann nicht nur extrem zeitaufwendig sein, sie ist auch sehr komplex,
da nur von linguistisch geschultem Personal durchführbar. Um diese Schwierigkeiten zu
umgehen, werden häufig auch statistische Parser eingesetzt. Diese basieren im wesentlichen
nach [Busemann 1995] auf endlichen Automaten oder kontextfreien Syntaxen, unterscheiden
sich aber durch die Verwendung von probabilistischen Informationen von diesen. Auch für

5.3. ARCHITEKTUR 45
die NLU-Tools wurde ein statistischer Parser verwendet. Dieser wird im folgenden beschrieben,
um ein besserers Verständnis für die sich in der Systemarchitektur wiederspiegelnden
Besonderheiten dieses Ansatzes zu ermöglichen.
Aus den Forschungslaboratorien der IBM kommt der Vorschlag, Korpora von handannotierten
Sätzen anzulegen, dieser Vorgang wird als treebanking bezeichnet und verlangt einen
geringeren Aufwand als das Erstellen von umfassenden Grammatiken [Jelinek et al. 1994].
Der Aufwand reduziert sich auf die Sammlung von Sätzen aus der Domäne des zu erstellenden
Dialogsystems und das Erstellen von passenden Annotationen (vgl. Abschnitt 3.3.2).
Das Vorhandensein dieser hiermit erstellten Baumbanken (engl. treebank) ermöglicht es nun,
den Parsingvorgang als Suchproblem über diesen Treebanks anzusehen. Der Prozess der Anwendung
der Annotationen aus diesen Korpora für neue Sätze wurde von Jelinek et al. als
treebank recognition bezeichnet, dieser ist als das eigentliche Parsingproblem zu begreifen.
Dieses Problem kann sehr gut über eine Grammatik gelöst werden, diese Lösung hat jedoch
immer noch den Nachteil, daß sämtliche zulässigen Sätze damit vor dem Parsing definiert
sein müssen. Daher wurde ein Verfahren erdacht, ohne zugrundeliegende Grammatik den
passendsten Baum T ∗ für einen gegebenen Satz w n 1 mit n Worten zu finden:
T ∗ = arg max p (T |w1 n )
T ∈T(w1 n )
wobei die Maximierung über die Gesamtheit aller Bäume, die den n-Wort-Satz überspannen,
berechnet wird.
Jelinek et al. sehen einen Baum einer Baumbank als geometrisches Muster an und ordnen
jedem Knoten eines Baums zwei Eigenheiten zu, einen Namen (POS-Tag oder Label) und
eine Erweiterung, welche die Richtung des entsprechenden Vaterknotens von diesem Knoten
aus angibt (right oder left). Bei der Richtungsangabe wird außerdem noch unterschieden, ob
ein Knoten alleiniges Kind seines Vaters ist (unary) oder nur direkt unter seinem Vater (up)
liegt. Grundsätzlich werden die Blätter mit Tags (in Kleinbuchstaben benannt) bezeichnet,
darüber liegende Knoten mit Labels (benannt in Großbuchstaben), wie in Abbildung 5.2 zu
sehen.
Abbildung 5.2: Beispielbaum
Die Knoten in Abbildung 5.2 sind der Einfachheit halber von 1 bis 5 durchnumeriert worden.
Der abgebildete Baum wird wie folgt konstruiert: am Anfang sind nur die Knoten
3,4,5 aktiviert, allerdings ohne zugewiesenes POS-Tag. Nun wird als erstes von links nach
rechts gehend Knoten 3 ausgewählt und mit dem Tag det versehen. Dies korrespondiert mit
der Herleitungsfunktion [3]. Nun wird 3 erneut genommen und eine passende Erweiterung
gewählt (right im Beispiel), die Herleitung ist also [3 3]. Dies wird nun weitergeführt, bis

46 KAPITEL 5. SHOPTEL
der abgebildete Baum mit der Herleitung [3 3 4 4 2 2 5 5 1 1] erstellt werden konnte. Die
Strategie, mit der diese Herleitung erfolgt ist, wird BULM genannt (bottom-up leftmost).
Das Parsing im NLU-Toolkit funktioniert ebenfalls nach der BULM-Strategie. Die Folge
aller Knoten, die für die Herleitung eines solchen Baums nötig sind wird als d bezeichnet.
Der Name des Knotens wird mit d i , seine Erweiterung mit e di benannt. Das Parsing folgt
nun folgendem Algorithmus:
• suche den Knoten unter den aktiven, der erweitert werden soll, mit:
p (active = d i |context),
• dann
– weise dem ausgewählten Knoten ein POS-Tag zu, wenn nötig oder gebe ihm ein
Label nach der Regel p (l di |context), oder
– erweitere den ausgewählten Knoten (durch hinzufügen einer Kante in den Graphen)
nach p (e di |context).
Es wird also pro aktiviertem Knoten eine Benennung und eine Erweiterung durchgeführt,
wobei nur die Erweiterung einen neuen Knoten aktiviert. Der Kontext, der für die Erstellung
eines Baums verwendet wird, hat ein Fenster von 5 Knoten um den jeweilig aktiven. 9
Die Wahrscheinlichkeit für die Herleitung eines Parse-Baums ist somit das Produkt der
Einzelwahrscheinlichkeiten der jeweiligen Namen und Erweiterungen in diesem Baum und
der Wahrscheinlichkeit von jedem ausgewählten Knoten:
p (T, d|w1 n ) =
∏
1

5.3. ARCHITEKTUR 47
diesem Ansatz richtig verarbeitet werden, da für die Verarbeitung vor allem auf die Wurzelknoten
der Bäume geachtet wird. Aus diesen Gründen gilt dieser Parsing-Ansatz als robust
gegenüber Erkennungsfehlern und spontansprachlichen Phänomenen.
Das Parsing in den NLU-Tools findet in zwei Schritten statt, um eine bessere Verarbeitung
von größeren Datenmengen im Parser zu ermöglichen. Während des ersten Schrittes werden
einfache semantische Klassen identifiziert, daher wird die Komponente Classer genannt. Der
zweite Schritt beinhaltet das eigentliche Parsing, diese Komponente, der Parser, arbeitet
basierend auf den vorverarbeiteten Daten des erstens Schrittes. Beide Schritte folgen dem
in diesem Abschnitt formulierten Algorithmus, es gibt keine Besonderheiten hinsichtlich
der zugrundeliegenden Idee bei den Modulen. Im folgenden werden beide Komponenten im
Kontext von ShopTel näher dargestellt.
5.3.9 Classer
Der Classer leistet die Vorverarbeitung für den Parser. Er klassifiziert die einzelnen Worte
einer Äußerung und vereinfacht damit den Arbeitsvorgang für den Parser, da dieser bei klassifizierten
Wörtern nicht mehr auf den Worten, sondern nur noch auf den Klassen operiert.
Klassifiziert werden grundsätzlich nur semantische Klassen in lokalem Kontext, es erfolgt keine
syntaktische Analyse des Wortmaterials. Klassifikationen von größerem Kontext bleiben
dem Parser (Abschnitt 5.3.12) überlassen.
Der Classer basiert, wie der Parser, auf statistischen Modellen (dargestellt in Abschnitt
5.3.8). Die für diese Anwendung gesammelten Sätze und Äußerungen wurden von Hand
klassifiziert und mit entsprechenden Tags (für semantische Wortarten) und Labels (für die
Klassen) versehen, anschließend wurde ein Training über diesen Wortfolgen durchgeführt.
(1) einen rechner für 5 tausend euro bitte
Abbildung 5.3: Beispieläußerung für eine Bestellung mit ShopTel
Anhand eines Beispiels wird im folgenden die Funktionsweise des Classers erläutert. Satz
(1) aus Abbildung 5.3 enthält z.B. folgende semantische Wortarten und Klassen:
• semantische Wortarten:
Zahlenwerte einen, 5, tausend
Produktarten rechner
Währungen euro
• Klassen:
Zahlenwerte einen
Produkte rechner
Geldbeträge 5 tausend euro
Nach erfolgter Verarbeitung im Classer wird die Äußerung wie Satz (2) in Abbildung 5.4
mit einer Bewertung der Lösung an die nachfolgende Komponente weitergegeben. Der entsprechende
Baum des Classers ist in Abbildung 5.5 dargestellt. Dabei wird für ShopTel eine

48 KAPITEL 5. SHOPTEL
(2) NUM PRODUCT für AMOUNT bitte
Abbildung 5.4: Klassifizierte Beispieläußerung für Bestellung mit ShopTel
andere Notation verwendet, als in Abschnitt 5.3.8 für Abbildung 5.2. Der Satzknoten wird
einheitlich für Classer und Parser in den NLU-Tools mit !S! gekennzeichnet, Tags werden
immer in Kleinbuchstaben, Labels groß geschrieben. Im Classer beschreiben die Labels die
(semantischen) Klassen der entsprechenden Äußerung. Worte, die keiner semantischen Klasse
zuzurechnen sind, werden als word direkt unter den Satzknoten gehängt, in diesem Fall
wird kein Label vergeben. Eine Übersicht der in ShopTel verwendeten Tags und Labels wird
im Anhang in Abschnitt B.2 gegeben.
Abbildung 5.5: Baum der klassifizierten Beispieläußerung
Die Daten des Classers werden im folgenden dem Canonicalizer übergeben, der nur die
jeweiligen Klassen weiterbearbeitet.
5.3.10 Canonicalizer
Der Canonicalizer stellt vor allem die Durchführbarkeit von DB-Abfragen sicher. So werden
im Canonicalizer natürlichsprachliche Ausdrücke auf DB-konforme Ausdrücke abgebildet,
um in der Datenbank aufgefunden zu werden.
Der Canonicalizer erhält die klassifizierten Sätze des Classers zur Verarbeitung und wandelt
die gefundenen Klassen in entsprechende Werte für die DB um. So wird in dem Beispielsatz
(2) aus Abbildung 5.4 NUM in 1, PRODUCT in pc und der Geldbetrag AMOUNT in 5000 EUR
umgewandelt.
(3) ich hätte gerne italienischen wein
(4) ich möchte wein aus italien bitte
Abbildung 5.6: Beispieläußerungen für Bestellungen mit ShopTel
Der Canonicalizer bietet auch die Möglichkeit, verschieden lautende Sätze mit identischem
Informationsgehalt in eine identische Repräsentation zu transformieren. Als Beispiel dafür
dienen die Sätze (3) und (4) aus Abbildung 5.6; der semantische Gehalt der beiden Sätze
ist identisch, allerdings ist in der Datenbank als Herkunftsland für Weine nur italien

5.3. ARCHITEKTUR 49
eingetragen, daher wird im Canonicalizer auch das Wort italienischen auf italien abgebildet,
um im Backend eine richtige Verarbeitung dieses Satztypus zu ermöglichen.
Der Canonicalizer erstellt damit bereits die Suchbegriffe, die dem Backend (über das NLU
ControlCenter und den IVR-Hub) übergeben werden. Diese Terme werden vom Backend in
eine SQL-Abfage eingesetzt.
Die klassifizierten und vom Canonicalizer angereicherten Äußerungen werden als nächstes
dem Parser übergeben.
5.3.11 Dialogverarbeitung in den NLU-Tools
Die Dialogverarbeitung in den NLU-Tools geschieht vor allem im Dialogmanager (DM).
Dieser wird eingehend in Abschnitt 5.3.13 und bei [Papineni et al. 1999] behandelt. Da die
Grundlagen des DM jedoch auch für den Parser von Relevanz sind, werden diese im aktuellen
Abschnitt behandelt.
Der Dialogmanager in den NLU-Tools basiert auf Forms (engl. form-based dialog manager)
(FDM), diese Forms entsprechen den in Abschnitt 2.2.2 eingeführten Segmenten. Bei der
Spezifikation (siehe auch Abschnitt 3.3.1) und Entwicklung von ShopTel waren diese bereits
zu definieren, um bei der Annotation für den Parser vorzuliegen. Ziel des Parsings in den
Tools ist es, einer Äußerung ein Segment zuzuweisen.
Die Forms und Segmente von ShopTel werden in Kapitel 6 näher diskutiert, der Parser wird
im folgenden Abschnitt beschrieben, der FDM in Abschnitt 5.3.13.
5.3.12 Parser
Der Parser erhält die klassifizierten Sätze mit den Klassenwerten des Canonicalizers. Durch
die Vorverarbeitung des Classers sind hier schon viele Sätze verallgemeinert worden, z.B.
wird in allen Sätzen bei ShopTel ein konkretes Produkt durch die Klasse PRODUCT ersetzt,
Zahlenwerte werden durch NUM und Geldbeträge durch AMOUNT dargestellt.
Die grundsätzliche Arbeitsweise des Parsers ist bereits in Abschnitt 5.3.8 eingeführt worden,
auf die funktionellen Grundlagen soll daher hier nicht näher eingegangen werden.
In ShopTel sind für die Verarbeitung einer Bestellung verschiedene Aktionen konzipiert
worden, in die ein Bestellvorgang mit dem System eingeteilt wird (siehe dazu Abschnitt
5.3.11). Ziel des Parsings ist es, einer beliebigen Äußerung die jeweilig korrespondierende
Aktion zuzuordnen. So werden z.B. alle Äußerungen, die einer konkreten Produktauswahl
dienen, vom Parser der Aktion LIST zugeordnet, wie auch der Beispielsatz (1) aus Abbildung
5.3. Die in Abbildung 5.4 dargestellte Form stellt den Input des Parsers dar, zusätzlich
werden allerdings noch die Klassenwerte des Canonicalizers mitgeliefert, diese werden im
Parser aber nicht verarbeitet, sondern nur dem Dialogmanager zur dortigen Verarbeitung
weitergereicht.
Im Parser wird zuerst wieder jedem Wort eine Kategorie zugeordnet. Diese leitet sich entweder
aus der semantischen Klasse des Classer-Outputs ab (wie in Abb. 5.7), oder es werden
bestimmte Signalwörter einem Form zugeordnet (siehe in Abb. 5.8). Für den Parser nicht
relevante Worte werden mit dem Tag null versehen, um dann im folgenden Schritt unter
dem Label NULL zusammengefasst zu werden. Der Parse-Tree unterscheidet sich äußerlich

50 KAPITEL 5. SHOPTEL
Abbildung 5.7: Parse-Tree der klassifizierten Beispieläußerung
vom Class-Tree vor allem durch den am Satz- bzw. Äußerungsende eingefügten Punkt. Ein
weiterer Unterschied besteht in dem Label, unter dem jeder Satz zusammengefasst wird.
Dieses Label gibt das Form für den aktuellen Satz an, über dem höchsten Label ist nur
noch der Satzknoten, der auch den Punkt mit anbindet. Der entsprechende Baum für die
behandelte Beispieläußerung ist in Abbildung 5.7 dargestellt.
Abbildung 5.8: Parse-Tree von ”
liefern sie bitte in die STREET NUM in NUM CITY“
Das Label einer Äußerung wird entweder direkt aus den Signalwörtern oder aber aus den
vorhandenen Klassen abgeleitet. So gibt es in ShopTel nur die Möglichkeit, Produktnamen
dem Form LIST zu zuordnen. Genauso ist es mit Kundennamen, diese werden immer dem
Form INIT zugeordnet, welche der Authentifizierung des Kunden und der Initialisierung
des Systems dient. Wenn einmal eine gesamte Äußerung nicht eindeutig einem bestimmten
Form zugeordnet werden kann, wird ihr entsprechendes Label mit ACTION benannt, eine
solche Äußerung kann dann in jedem Form verarbeitet werden, wenn möglich geschieht diese
Verarbeitung aber im aktuell aktiven Form. Im Anhang in Abschnitt B.2 wird eine Übersicht
der verwendeten Tags und Labels gegeben.

5.3. ARCHITEKTUR 51
5.3.13 Dialogmanager
Der Dialogmanager (DM) der IBM ViaVoice Telephony Natural Language Tools ist das
Herzstück der Tools (siehe auch die allgemeine Beschreibung eines DM in den Abschnitten
3.2.4 und 3.3.4). Wie bereits in Abschnitt 5.3.11 angesprochen, basiert dieser auf Forms,
die den in Abschnitt 2.2.2 eingeführten Segmenten entsprechen und wird daher auch als
formbasierter DM (engl. form-based dialog manager) (FDM) bezeichnet. 10
Die Forms des FDM sind anwendungsabhängig, sie sind die Basis einer jeden Anwendung,
die mit den NLU-Tools erstellt wird, sie korrespondieren mit den Segmenten, aus denen das
Dialogsystem bestehen soll und enthalten Slots, die alle nötigen Angaben für ein Segment
enthalten. Ein Form gilt als erfolgreich abgearbeitet, wenn alle obligatorischen Slots mit
passenden und vom Backend bestätigten Daten gefüllt sind, dabei ist jedoch immer ein
Springen zwischen verschiedenen (aktiven) Forms möglich. Der FDM kommuniziert mit dem
NLU ControlCenter (Abschnitt 5.3.7), um Datenbankanfragen durchführen zu können (vgl.
Abschnitte 5.3.5 und 5.3.10) und bilden somit das Gerüst für den Dialogmanager. Der FDM
selber ist anwendungsunabhängig, er kann durch beidseitige Initiative gesteuert werden und
ermöglicht damit eine kooperative Dialogstrategie (vgl. Abschnitt 2.5). Der FDM ist ferner
Turn-basiert und bietet von sich aus folgende Leistungen an:
• Nachfrage noch fehlender Daten
• Klärung von ambigen Daten
• Bestätigungsfragen bei kritischen Dialogschritten
• kontextsensitive Hilfetexte
• Steuerungsmöglichkeiten durch fest definierte Parsertags und Label 11
Der FDM verarbeitet die gelieferten Daten vom Parser und wandelt diese in Attribut-Wert-
Paare (AWP) um. Aus diesen wird das nächste Form für den FDM abgeleitet. Das AWP
für den Beispielsatz aus Abbildung 5.7 ist in Abbildung 5.9 dargestellt. Der Wert des ersten
Terms ist mit _1 angegeben, dies steht für einen abstrakten Slot, der keine Daten enthält.
Dieser Slot dient nur der Zuordnung zu einem Form. Dabei muß das jeweilige Form allerdings
über den passenden abstrakten Slot verfügen. Die folgenden Terme des AWP stehen für
konkrete Slots, welche mit Daten gefüllt werden können. Im Beispiel wird also der Slot
NUM mit 1, PRODUCT mit PC und AMOUNT mit 5000EUR aufgefüllt. Wenn diese Werte
vom Backend jeweils disambiguiert und bestätigt werden, gelten diese Slots als gefüllt. Im
Beispielsatz wird dies allerdings nicht der Fall sein, da die Produktangabe PC nicht genau
genug ist, daher wird eine Nachfrage vom FDM angestoßen. Der Benutzer wird daraufhin
gebeten, seine Produktwahl zu spezifizieren, um damit eine erfolgreiche Disambiguierung
leisten zu können. Für diese Rückmeldung an den Benutzer wird vom entsprechenden Slot
in den Forms ein Textstring an die TTS-Komponente (siehe Abschnitt 5.3.3) übermittelt.
Dieser Textstring ist als Prompt in dem Slot explizit enthalten, ebenfalls enthalten sind die
Backendaufrufe, die vom ControlCenter und IVR-Hub weitergegeben werden.
Die jeweiligen Slots werden in der jeweils in den Forms implementierten Reihenfolge gefüllt
und disambiguiert, die einzige Ausnahme sind optionale Slots, die nur bei einer Füllung
10 Siehe dazu speziell [Papineni et al. 1999].
11 Siehe im Anhang in Abschnitt B.2.

52 KAPITEL 5. SHOPTEL
(LIST, 1) (NUM,1), (PRODUCT,PC), (AMOUNT,5000EUR)
Abbildung 5.9: Attribut-Wert-Paar der Beispieläußerung
disambiguiert werden. Jeder Slot, der Daten disambiguiert, verfügt über eine sogenannte
RC-List (return code). In dieser sind verschiedene Forms oder Prompts nach dem RC differenziert.
Details über diese RC-Lists sind in Kapitel 6 zu finden.
Die zentrale Aufgabe des FDM ist es, für jede Äußerung (also jedes AWP) ein passendes
Form zu finden. Es ist jedoch auch möglich, zwischen verschiedenen Forms zu wechseln, da
unterschiedliche Forms identische Slots aufweisen können oder auch ganze Forms deaktiviert
sein können. Daher ist diese Suche nicht immer trivial, sie funktioniert grundsätzlich aber
immer nach dem gleichen Schema. Die Daten des Parsers sind dabei insofern hilfreich, als
das nur die Klassen (Labels) des Parsers als Attribut in einem AWP auftauchen können
und daher auch nur diese einen Slot repräsentieren bzw. füllen können. Die Auswahl des
passenden Forms erfolgt mit einer Heuristik (vgl. [Papineni et al. 1999]). Dabei wird m als
Zahl der passenden Slots, n als Zahl der nicht passenden Slots für ein Form angesehen.
Nach diesem Matching wird u als Zahl der ungefüllten und f als Zahl der gefüllten Slots
eines Forms berechnet, die Bewertung für ein Form kann dann z.B. mit folgender Formel
geschehen:
m − n + f − u
Das Form, welches die höchste Bewertung bekommt wird dann im folgenden ausgewählt und
die entsprechenden Slots werden gefüllt.
Die einzelnen Forms von ShopTel mit ihren jeweiligen Besonderheiten werden ausführlich
in Abschnitt 6.3 vorgestellt.
5.4 Konstruktion des Systems
In diesem Abschnitt werden die geleisteten Anpassungen, Eigenentwicklungen und das grobe
Vorgehen bei der Konstruktion von ShopTel dargestellt, um damit abschließend eine
Grundlage für die Aufwandsabschätzung einer Implementation mit den IBM-Tools zu haben.
Dabei muß jedoch darauf hingewiesen werden, daß es sich bei ShopTel nur um einen Prototypen
handelt, die Konstruktion eines marktreifen Systems wäre sehr viel langwieriger und
aufwendiger.
Bei dieser Darstellung wird die Reihenfolge des letzten Abschnitts nicht beibehalten, vielmehr
wird sich dieser Abschnitt an Abschnitt 3.3 orientieren, in dem bereits die Konstruktion
eines allgemeinen Dialogsystems dargestellt wurde.
5.4.1 Spezifikation
Viele Teile der Spezifikation waren für ShopTel bereits vorgegeben, die Domäne war festgelegt
und auch die Konstruktion als Telefonanwendung mit Verwendung der IBM ViaVoice
Telephony Natural Language Tools stand bereits fest. Damit stand auch die Systemarchitektur
fest (vgl. Abschnitt 5.3).

5.4. KONSTRUKTION DES SYSTEMS 53
Im Rahmen der Spezifikation war das Szenario des zu konstruierenden Systems detailiert zu
erstellen (vgl. Abschnitt 5.2). Die notwendigen Forms des Systems mußten differenziert und
grob auf die verschiedenen, zu erstellenden Forms abgebildet werden. Dabei war genauestens
zu klären, welche Schritte einer Bestellung mit dem System abgebildet werden sollten.
Bei dieser Entscheidung wurde zum Beispiel auf die Implementierung von Mengenrabatten
und Sonderangeboten verzichtet. Vielmehr wurde entschieden, zum Anfang nur eine Grundfunktionalität,
wie im Szenario beschrieben, zu implementieren. Dabei sollte allerdings eine
spätere Erweiterung möglich sein.
5.4.2 Dialogmaterial und Parsingkomponente
Wie in Abschnitt 3.3.2 dargestellt, ist die Erhebung und Sammlung von Dialogmaterial eine
Voraussetzung für die Konstruktion eines Dialogsystems. Für ShopTel wurden beispielhafte
Benutzeräußerungen von verschiedenen Testpersonen gesammelt, in diesen wurden dann
verschiedene Worte und Wortgruppen durch Variablen ersetzt (z.B. Produktnamen, Zahlen,
etc.) und die Sätze so verallgemeinert. Insgesamt kamen dabei 1.912 bereinigte Sätze
zusammen, die anschließend von Hand für den Classer (siehe Abschnitt 5.3.9) und Parser
(vgl. Abschnitt 5.3.12) annotiert wurden, gleichzeitig wurde aus diesen Daten ein Sprachmodell
berechnet. Bei der durchgeführten Annotation wurde auf die verschiedenen Klassen
für den Classer und Parser geachtet, um eine spätere Implementation dieser in den Forms
zu ermöglichen.
Die Annotation war sehr zeitaufwendig und häufig zu wiederholen, um neue Äußerungen
aufzunehmen oder neue Klassen einzuführen.
Die knapp 2.000 Sätze, die als Datengrundlage für den Classer dienten, waren bereinigte
Sätze, die Variablen enthielten. Für das Training des Classers wurden die Sätze mit einem
Monte-Carlo-Programm auf das 30fache vervielfältigt und die Variablen mit verschiedenen
Texten ersetzt (so zum Beispiel mit Produktnamen, Zahlenwerten, Geldbeträgen, etc.). Der
Parser wurde mit den klassifizierten Sätzen trainiert, daher war seine Datengrundlage entsprechend
kleiner.
Um die Ergebnisse von beiden Komponenten zu verbessern, wurde die Datengrundlage erweitert,
wobei erhebliche Fortschritte zu beobachten waren. Somit konnte der Classer schließlich
bei einem Regressiontest mehr als 93 % eines unbekannten Testsets korrekt zuordnen, der
Parser kam dabei auf etwas über 90 %.
5.4.3 Dialogkomponente
Da der Dialogmanager (DM) bereits in den NLU-Tools enthalten ist, war dieser nicht mehr
zu erstellen. Allerdings waren die Forms (siehe Abschnitt 5.3.13) für den DM zu konstruieren.
Diese greifen auf die Labels (Klassen) von Classer und Parser zu und enthalten sämtliche
Aktionsmöglichkeiten, die das System bietet. Im Rahmen dieser Implementation war auch
die Anbindung an das Backend (siehe nächster Abschnitt) zu leisten. Die einzelnen Forms
von ShopTel werden in Kapitel 6 näher dargestellt.
Um das System mit dem FDM zu nutzen, waren auch einige Anpassungen am IVR-Hub
(vgl. Abschnitt 5.3.4) und dem NLU ControlCenter (siehe Abschnitt 5.3.7) durchzuführen.

54 KAPITEL 5. SHOPTEL
5.4.4 Backend und Datenbank
Die Konstruktion des Backend-Skripts (siehe Abschnitt 5.3.5) von ShopTel war eine der
größeren Aufgaben im Rahmen der Systemimplementation. Allgemein ist dieses Skript für
die Bereitstellung der Funktionalität zuständig, es wird direkt von den Forms mit den entsprechenden
Daten des Canonicalizers (Abschnitt 5.3.10) und des Parsers (Abschnitt 5.3.12)
versorgt und liefert diesen den return code und einen Datensatz zurück.
Das Backend-Skript mußte komplett neu für ShopTel entwickelt werden. Dabei mußten
für unterschiedliche Anfragetypen auch verschiedene DB-Anfragen ermöglicht werden. Nach
der Erstimplementation offenbarten verschiedene Tests und Benutzeranfragen jedoch Weiterentwicklungsbedarf,
der auch während der letzten Implementationsphase nicht ganz ausgeschlossen
werden konnte.
Die Datenbank, welche als Datengrundlage für das System benötigt wurde, mußte mit echten
Produktdaten gefüllt werden. Diese Daten waren auch im Canonicalizer 5.3.10 zu berücksichtigen.
5.4.5 Ein- und Ausgabe
Für die Spracheingabe wurde der existierende Erkenner des IBM-Toolkits verwendet (siehe
Abschnitt 5.3.2). Dieser ist voll anwendungsunabhängig und verlangte keinen zusätzlichen
Implementations- oder Anpassungsaufwand. Allerdings mußte ein Sprachmodell berechnet
werden, um den ASR in der entsprechenden Domäne funktionsfähig zu machen.
Das aus dem gesammelten Dialogmaterial (siehe Abschnitt 5.4.2) resultierende Vokabular
für ShopTel besteht aus mehr als 2.000 Vollformeinträgen. Unter diesen Einträgen befinden
sich auch alle Zahlen von 1 bis 999, alle übrigen Zahlenwerte werden aus diesen kombiniert. 12
Um den Erkenner, die TTS (Abschnitt 5.3.3) und das Telefoniemodul (Abschnitt 5.3.1) an
die NLU-Tools anzuschließen waren allerdings einige Anpassungen an den Steuerungsskripten
notwendig. Diese Arbeiten waren sehr aufwendig, da in den bisher vorliegenden Skripten
keine Ansteuerung des Erkenners vorgesehen war und nur mit getipptem In- und Output
gearbeitet wurde.
5.4.6 Konstruktionsaufwand
Eine Zusammenfassung der nötigen Eigenentwicklungen und Anpassungen für die Implementation
von ShopTel ist in Tabelle 5.1 wiedergegeben.
Die aufwendigsten Arbeiten stellten im Rückblick die Datensammlung und Annotation für
Classer und Parser, sowie die Erstellung des Backend-Skripts dar. Mit nur etwas kleinerm
Zeitaufwand konnte das Backend-Skript erstellt werden, das zur Hälfte bei laufendem Gesamtsystem
implementiert wurde.
An dritter Stelle dieser Aufwandsrechnung ist die Erstellung der Forms für den FDM zu
nennen, teilweise führten diese Arbeiten auch zu weiteren erforderlichen Änderungen am
Parser.
12 Die Zahl 5.000 wird daher als ”
5 tausend“ interpretiert. Mit diesem Vorgehen konnte die Erkennung für
Zahlen gesteigert werden, wie eine interne IBM-Studie belegt.

5.5. EVALUATION DES SYSTEMS 55
Komponente durchzuführen Kurzbeschreibung der Arbeit
ASR Anpassung Erstellung des Sprachmodells
Telefonie Anpassung Herstellung der Kommunikation
TTS — —
IVR-Hub Anpassung Herstellung der Kommunikation
Backend Eigenentwicklung Bereitstellung der Funktionalität
Datenbank Anpassung Füllen der DB mit Daten
ControlCenter Anpassung Herstellung der Kommunikation
Classer Datenanpassung Sammlung und Annotation der Daten
Parser Datenanpassung Annotation der Daten
Canonicalizer Eigenentwicklung Bereitstellung der Funktionalität
FDM Anpassung Entwicklung der Forms
Tabelle 5.1: nötige Arbeiten bei der Entwicklung von ShopTel
Ansonsten war vor allem die Integration des Telefonie-Moduls mit Erkenner und TTS zeitintensiv,
da bisher in der vorliegenden Version der NLU-Tools nur mit getippten Eingaben
gearbeitet wurde.
Der gesamte Aufwand zur Konstruktion von ShopTel ist allerdings zu einem Teil auch mit
der nötigen Einarbeitung in die Tools und deren Architektur zu erklären. Der momentane
Stand des Systems ist trotz dieses Aufwands nur als prototypisch zu bezeichnen, da für
eine bessere Fehlerbeseitigung der zeitliche Rahmen zu eng war. Mit den im Laufe der
Evaluation angefallenen Daten steht eine gute Grundlage für ein weiteres Tuning des Systems
zur Verfügung. Diese Arbeit muß allerdings anderen überlassen werden.
5.5 Evaluation des Systems
Die Evaluation von Dialogsystemen dient unter anderem der Dokumentation ihrer Leistungsfähigkeit.
Eine Evaluation kann allerdings auch Informationen über die Benutzerakzeptanz
und den subjektiven Eindruck von Benutzern liefern. Im Rahmen der Evaluation
von ShopTel wurden beide Evaluationsarten durchgeführt. Für ShopTel wurde die Evaluation
allerdings nich nur zur Dokumentation und Messung der Benutzerakzeptanz eingesetzt,
vielmehr war es ein erklärtes Ziel, duch die vermehrte Benutzung von Testpersonen, vorhandene
Fehler zu entdecken und zu beheben. Da es sich beim vorliegenden System nicht um
eine Grammatik-basierte Anwendung handelt, konnten in vorherigen Systemtests nicht alle
Eventualitäten abgeprüft werden.
Zuerst wird im nächsten Abschnitt die Performanzevaluation von ShopTel beschrieben, dabei
wird insbesondere auf die Problematik der Evaluation von Dialogsystemen im allgemeinen
eingegangen. Außerdem wird in diesem Abschnitt auch auf die verschiedenen Fehlerursachen
eingegangen und es werden Lösungsmöglichkeiten aufgezeigt. Anschließend wird
die Benutzerevaluation vorgestellt, die insbesondere anhand eines Fragebogens durchgeführt
wurde.

56 KAPITEL 5. SHOPTEL
5.5.1 Performanzevaluation
Die Performanzevaluation von Dialogsystemen orientiert sich an technischen Details, sie
dient der Vergleichbarkeit von verschiedenen Systemen. Jedoch ist diese Vergleichbarkeit
nicht immer herzustellen, da Dialogsysteme sehr unterschiedlich konstruiert werden können,
wie bereits in Kapitel 4 dargestellt wurde. Von daher erscheint die Erhebung eines Meßwertes
zum Vergleichsmaßstab nicht sinnvoll, häufig wird jedoch die Erfolgsrate (engl. success rate)
(SR) eines Dialogsystems zum wichtigsten Kriterium in einer Evaluation erhoben, ähnlich
wie eine Wortfehlerrate (engl. word error rate) (WER) als Vergleichsmaßstab von Spracherkennern
dient. Allerdings ist die Wortfehlerrate bei einem Spracherkenner auch die zentrale
Größe. Bei einem Dialogsystem gibt es bedingt durch die einzelnen Komponenten, aus denen
ein solches System besteht, für jede Komponente einzelne Meßgrößen. Bei ShopTel kann
zum Beispiel für den Erkenner, den Classer und den Parser je ein eigenes Korrektheitsmaß
bestimmt werden. Die einzelnen Werte stehen jedoch nicht für die Leistungsfähigkeit des
Gesamtsystems, sondern nur für die jeweiligen Komponenten.
Aus den vorgenannten Gründen werden für die Evaluation eines Dialogsystems mehrere
Angaben benötigt, die alle im Kontext miteinander gesehen werden müssen (vgl. [Polifroni
et al. 1998]). Die SR wird jedoch als sehr relevante Größe eingestuft. Dabei ist einiges zu
beachten, so ist zum Beispiel bei Übersetzungssystemen (vgl. Abschnitt 4.3) die Berechnung
der Erfolgsrate sehr kompliziert, da die Qualität einer Übersetzung bewertet werden muß
(siehe u.a. [Gates et al. 1997; Tessiore und von Hahn 2000]). Bei reinen Auskunftssystemen,
wie sie beispielsweise in Abschnitt 4.1 vorgestellt wurden, kann eine SR meist aus dem
Vergleich von Benutzereingaben und den dazugehörigen Systemausgaben abgeleitet werden.
Wenn das System genau nach der Intention des Benutzers gehandelt hat, ist das Dialogziel
erreicht worden, der entsprechende Schritt kann also als erfolgreich angesehen werden. Dieses
Vorgehen kann auch bei Aktionssystemen Anwendung finden und wurde daher auch bei der
Evaluation von ShopTel angewandt. Diese Evaluationsmethode ist als end-to-end Evaluation
bekannt [Sikorski und Allen 1997; Tessiore und von Hahn 2000]. Die SR wird in diesem Fall
wie folgt berechnet:
SR = D s
D · 100
wobei D s die Anzahl der erfolgreichen und D die gesamte Anzahl aller Dialoge bedeutet.
Als erfolgreicher Dialog wird dabei ein Dialog angesehen, bei dem das jeweilige Dialogziel
erreicht wurde. Die Berechnung der SR ist im vorliegenden Fall durch manuelle Auswertung
der Eingangs- und Ausgangsdaten von ShopTel geschehen. Es gibt allerdings auch
Methoden, den Erfolg eines Dialogs automatisch zu berechnen bzw. zu ermitteln. [Araki
und Doshita 1997] stellen beispielsweise eine automatische Evaluation von Dialogsystemen
mittels eines automatisierten Benutzers vor und nennen diese Technik system-to-system.
[Walker et al. 1998b; Kamm et al. 1999; Litman und Shimei 1999] stellen mit ihrer Evaluationsumgebung
PARADISE einen Ansatz vor, der zur Leistungsmessung verschiedene
Parameter kombiniert, dies sind im einzelnen Benutzerzufriedenheit, Aufgabenerfolg und
Dialogaufwand. Die Durchführung einer solchen Evaluation ist sehr aufwendig, bietet aber
den Vorteil, ein wirklich aussagekräftiges Maß für die Leistungsfähigkeit eines Dialogsystems
zur Hand zu haben.
Für die Evaluation von ShopTel wurden insgesamt 67 Dialoge als Datengrundlage genutzt,
die zu einem Drittel von erfahrenen, ansonsten von unerfahrenen Benutzern stammen. Die
Dialoge wurden zwischen dem 5. August und dem 6. September geführt. Die Ergebnisse der
Performanzevaluation mit einer Bewertung befinden sich im Anhang in Abschnitt B.3.

5.5. EVALUATION DES SYSTEMS 57
5.5.2 Benutzerevaluation
Da es sich bei ShopTel um einen Prototypen handelt, stand auch die Akzeptanz und Zukunft
eines solchen Systems in Frage. Zur Beantwortung wurde das System daher einer Evaluation
durch verschiedene Benutzer unterworfen. Dabei wurde diesen meist eine kurze Systembeschreibung
und ein Beispieldialog (Abbildung 5.10) vorgelegt, um einen Anhaltspunkt für
die Leistungsfähigkeit des Systems zu geben. 13 Anschließend wurden sie gebeten, das System
auszuprobieren, dabei stellten diese Gespräche häufig auch die Datenbasis für die Performanzevaluation
dar. Nach einem Telefonat mit ShopTel wurden die Anwender nach ihren
jeweiligen Eindrücken befragt, dies geschah an Hand eines Fragebogens, der im Anhang in
Abschnitt B.4 abgebildet ist.
guten tag mein name ist mustermann
die nummer ist 0815
ich moechte einen computer fuer 5000 euro bestellen
mit dvd-laufwerk bitte
geben sie mir bitte die daten
ich nehme den billigsten
ja bitte
ok
zahlen bitte
per kreditkarte
ich zahle mit meiner visa
1 2 3 5 6
bis maerz 2002
auf wiederhoeren
Abbildung 5.10: Beispieldialog für die Systemevaluation (ohne Systemäußerungen)
Es wurden insgesamt 19 Fragebögen beantwortet, die gesammelten Antworten sind in Abschnitt
B.5 im Anhang abgebildet. Bei dieser Anzahl von beantworteten Fragebögen kann
zwar nicht von einer repräsentativen Auswahl gesprochen werden, doch für einen ersten
Eindruck ist das Datenmaterial ausreichend.
Von den 19 befragten Personen haben zehn Personen bereits vor der Benutzung von ShopTel
ein anderes Dialogsystem benutzt. Ebenfalls zehn Personen bezeichneten sich selbst als Computerprofis,
ansonsten wurde sechs mal Anwender und drei mal Laie angegeben.
Insgesamt wurde von den Befragten das System mit durchschnittlichen 2,97 auf einer Skala
von 1 (sehr gut) bis 6 (ungenügend) benotet, dabei wurde die Systembenutzung sogar etwas
besser und damit als eher einfach bewertet. Aus den Kommentaren geht hervor, daß die
synthetisierte Stimme zwar nicht als angenehm empfunden wurde, jedoch verständlich war.
Durchgehend wurde gesagt, daß es Probleme mit der Erkennungsleistung von ShopTel gegeben
hat. Die auf Aufforderung wiederholte Eingabe wurde als störend empfunden, dagegen
wurde die Verarbeitungsgeschwindigkeit des Systems als gut bewertet.
Über die Hälfte der Personen sagte, daß eine Benutzung des Systems auch ohne vorherige
13 Im Anhang in Abschnitt B.1 sind ausgewählte Dialoge mit dem System abgebildet.

58 KAPITEL 5. SHOPTEL
Einführung möglich sei und etwa zwei Drittel der Befragten gab an, ein solches System in
der Zukunft benutzen zu wollen.
Damit kann gesagt werden, daß die Fehler und Schwächen von ShopTel aus Benutzersicht
durchaus mit den bei der Performanzevaluation aufgetretenen und diagnostizierten Mißständen
übereinstimmen. Die TTS konnte dort nicht bewertet werden, da jedoch bedingt
durch die Produktauswahl viele Fremdworte bzw. englische oder französische Ausdrücke vorkamen,
war eine mangelhafte Aussprache oder Betonung mit der derzeitigen TTS nur durch
eine entsprechend geänderte Schreibweise der einzelnen Worte zu beseitigen. Dies hätte allerdings
Änderungen an der gesamten Datenbasis des Systems verlangt, daher wurde auf
diesen Schritt verzichtet.
Als wichtiges Ergebnis der Benutzerbefragung betrachte ich allerdings den großen Anteil von
Personen, die angaben, daß ShopTel auch ohne vorherige Informationen benutzbar sei. Der
noch größere Anteil derjenigen, die ein solches System auch in Zukunft benutzen würden,
kann allgemein als positiv für die gesamte Bandbreite von sprachverarbeitenden Systemen
angesehen werden.
Mit dem Ergebnis dieser Benutzerbefragung kann somit auch nachgewiesen werden, daß die
Ziele für ShopTel, wie sie in Abschnitt 5.1 formuliert worden sind, erfüllt wurden. So wurde
bereits in der Performanzevaluation gezeigt, daß ein Großteil der Bestellungen mit ShopTel
erfolgreich verlief, die Implementation als Aktionssystem ist damit gelungen. Im weiteren
wird die Erreichung der einzelnen Ziele dokumentiert:
• der hohe Anteil der erfolgreichen Bestellungen und die große Zahl von Benutzern, die
eine Systembenutzung auch ohne vorherige Informationen für möglich halten, beweisen
die erfolgreiche Umsetzung eines intuitiven Bestellvorgangs in ShopTel
• die Systemmeldungen wurden als kaum störend bewertet, somit kann gefolgert werden,
daß die Umsetzung der Benutzerführung ohne zu große Einschränkung der Nutzer
gelungen ist
• die Benotung für das Gesamtsystem und die Benutzung zeugen von einer großen Freiheit
bei der Dialogführung, diese wurde sogar in einigen Kommentaren explizit als
positiv bewertet, damit gilt auch das Ziel der freien Dialogführung als erreicht
Daher kann gesagt werden, daß es gelungen ist, bei der Implementation von ShopTel die
Benutzerführung so zu gestalten, daß die Systemnutzung ohne die Einhaltung fester Dialogmuster
möglich ist. Damit wurden alle die Benutzer betreffenden Ziele, inklusive der
Funktionserfüllung, erreicht.
Die Ergebnisse der Benutzerevaluation können als positiv eingestuft werden, da diese sowohl
die Erfüllung der aufgestellten Ziele bestätigen, als auch eine gute Gesamtbewertung des
Systems enthalten. Zusammengenommen mit den Ergebnissen der Performanzevaluation
kann nur gefolgert werden, daß eine Überarbeitung und Verbesserung des Systems zu einer
akzeptierten und noch benutzerfreundlicheren Anwendung führen würde.
5.6 Zusammenfassung
In diesem Kapitel wurde das System ShopTel als prototypische Umgebung für einen automatisierten
telefonischen Bestellservice vorgestellt. Im Rahmen dieser Vorstellung wurden

5.6. ZUSAMMENFASSUNG 59
die Grundlagen des Systems und die Entwurfsziele dargestellt, dabei wurde vor allem die
Benutzerführung während eines Dialogs mit dem System herausgestellt.
Nach einer Einführung in das grundlegende Szenario der Anwendung, folgte eine eingehende
Erläuterung der Systemarchitektur. In diesem Rahmen wurde auf die Besonderheiten
des IBM ViaVoice Telephony Toolkit und der IBM ViaVoice Telephony Natural
Language Tools, auf denen das System basiert, eingegangen. So wurde zum Beispiel der 2-
Wege-Ansatz innerhalb des Parsings der NLU-Tools genau erläutert und auf die Forms und
den dazugehörigen Dialogmanager Bezug genommen. Schließlich wurde die Konstruktion des
Systems grob erläutert und eine Abschätzung des nötigen Aufwands für die Implementation
eines solchen Systems gegeben.
Bei allen Darstellungen wurde, wenn nötig, auf die Unterschiede zu einem allgemeinen Dialogsystem,
wie es in Kapitel 3 vorgestellt wurde, eingegangen.
Abschließend folgte die Evaluation des aktuellen Systemzustandes und eine Präsentation
der Ergebnisse. Dabei wurde sowohl eine Performanz-, als auch eine Benutzerevaluation
vorgenommen. Im Rahmen dieser Untersuchungen konnte der prototypische Charakter des
Systems belegt werden, da zum Beispiel die Verarbeitung von Benutzeräußerungen nur in ungefähr
der Hälfte aller Fälle erfolgreich verlief. Allerdings gelang es im Rahmen der Evaluation
auch, tatsächliche Fehlerquellen zu detektieren und gleichzeitig Vorschläge für zukünftige
Verbesserungen am System zu machen. Außerdem konnte die Erfüllung der Entwurfsziele
nachgewiesen werden und die positive Bewertung des Systems von den Benutzern wurde
hervorgehoben.
Das resultierende System ist nun in seiner grundsätzlichen Arbeits- und Funktionsweise
bekannt. Die jeweiligen Prinzipien der einzelnen Systemmodule sind erläutert und an Beispielen
eingehend behandelt worden. Die aus diesem Kapitel gewonnenen Kenntnisse werden
im folgenden nötig sein, um im nächsten Kapitel die Dialogsegmente und die daraus resultierenden
Forms des Systems behandeln zu können. Auf die eingangs formulierten Ziele für
den Entwurf und die Konstruktion des Systems wird ebenfalls im anschließenden Kapitel
noch einmal Bezug genommen werden.

60 KAPITEL 5. SHOPTEL

Kapitel 6
Dialogsegmente für
Shopping-Anwendungen
Dialogsegmente als Grundlage eines Dialogsystems sind in Abschnitt 2.2.2 eingeführt worden.
Dort wurden Segmente als zusammengehöriger Teil eines Dialogs in einem Dialogsystem
als Äquivalent zur Sequenz aus Benutzersicht eingeführt.
In diesem Kapitel werden zuerst menschliche Dialoge des Bereichs Telefonmarketing beschrieben,
um dabei auf die Unterschiede zu einem Dialog mit einem Telefonsystem eingehen
zu können. Dabei wird vor allem die mögliche Verwendbarkeit von menschlichen Vorgehensweisen
für die Konstruktion von ShopTel geprüft werden.
Ausgehend von der Beschreibung des Systems ShopTel im letzten Kapitel werden im folgenden
die einzelnen Dialogsegmente des Systems vorgestellt, um anschließend das Konzept der
Forms, auf dem der Dialogmanager des Systems beruht (vgl. Abschnitt 5.3.13), aufzugreifen.
Im Anschluß wird eine ausführliche Darstellung der Forms im System ShopTel gegeben, dabei
werden auch die jeweiligen Besonderheiten der einzelnen Forms dargestellt. Als nächstes
werden Strategien für ShopTel vorgestellt, in diesem Rahmen wird auch das graphical
ControlCenter betrachtet, ein Tool, mit dem auf die Forms einer Anwendung zugegriffen
werden kann. Schließlich wird noch eine Zusammenfassung gegeben, in der die wesentlichen
Erkenntnisse dieses Kapitels zusammengefaßt werden und ein kompletter Überblick über
das System ShopTel erfolgt.
6.1 Menschliche Dialoge im Telefonmarketing
Um menschliche Dialoge im Telefonmarketing den Systemdialogen mit ShopTel gegenüberstellen
zu können, erfolgt zuerst eine begriffliche Einordnung. Anschließend werden die Besonderheiten
eines menschlichen Dialogs in diesem Rahmen dargestellt.
Das Telefonmarketing als eine Form des Marketing 1 wird allgemein dem Direktmarketing
zugeordnet [Müller 1994]. Dabei wird letzteres von [Dallmer 1993] als marktgerichtete Ak-
1 Unter Marketing werden laut [Schneider 1993] alle Maßnahmen der ziel- und wettbewerbsorientierten
Ausrichtung der marktrelevanten Aktivitäten eines Unternehmens an ausgewählten Problemfeldern von
Kundenpotentialen unter Einsatz planender, steuernder, koordinierender und kontrollierender sowie marketingpolitischer
Instrumente zusammengefaßt.

62 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN
tivität angesehen, die sich einstufiger (direkter) Kommunikation bedient, um Zielgruppen
in individueller Einzelansprache gezielt zu erreichen. Einstufige Kommunikation bedeutet in
diesem Sinne, daß die Aktivität nur von einer Person, dem Sender, ausgeht, ohne daß der
Empfänger reagieren muß. Ein Beispiel für den Fall einer solchen Kommunikation ist das
klassische Werbemailing.
Grundsätzlich wird aktives und passives Telefonmarketing unterschieden, dabei wird ersteres
als vom Verkäufer ausgehende Marketingmaßnahme definiert, während beim passiven Telefonmarketing
die Initiative beim Kunden liegt. Da dieser Fall auch bei ShopTel vorliegt,
wird im weiteren das aktive Telefonmarketing nicht weiter behandelt. 2
Allen Arten des Telefonmarketing gemein ist die Tatsache, daß bei Telefongesprächen beiden
Gesprächspartnern ausschließlich die auditive Ebene zur Verfügung steht. Eventuelle
Mißverständnisse oder Verständigungsprobleme müssen also über den Kanal gelöst oder
aufgeklärt werden, der auch den Grund der entsprechenden Probleme darstellt. Gerade für
die Verkaufssituation ist dies ein großes Hindernis, da beispielsweise Angebote nicht zusätzlich
auf einer visuellen Ebene schmackhaft gemacht werden können. Von daher kommt zum
Beispiel der Wortwahl in telefonischen Verkaufsgesprächen eine viel bedeutendere Rolle zu,
als in face-to-face Situationen. Dies gilt zwar vor allem, wenn das Interesse eines potentiellen
Kunden für eine Ware erst noch geweckt werden muß, wie es beim aktiven Telefonmarketing
der Fall ist, jedoch auch in der passiven Form sollte es das Ziel sein, einem Anrufenden
möglichst ein positives Bild zu vermitteln. Ansonsten kann es sein, daß ein Kundenauftrag
erfolgreich durchgeführt wurde, der Kunde allerdings wegen des schlechten Eindrucks kein
zweites Mal anruft. So wird unabhängig von der Wahl oder Qualität eines Produkts ein
schlechtes Image produziert, welches sich nachteilig auf die Auftragslage auswirken kann.
Bei [Plog 1996] wird daher mehrfach betont, daß die Art und Weise der Kommunikation mit
einem Kunden insbesondere bei Telefonverkaufsgesprächen sehr entscheidend für den Erfolg
eines Anrufs ist.
Aus den genannten Gründen kommt bei den meisten Einsätzen von Telefonmarketing daher
ausschließlich speziell geschultes Personal zum Einsatz [Weber 1984; Plog 1996]. Dabei wird
vor allem auf Freundlichkeit und Kompetenz eines jeden Mitarbeiters wert gelegt. Außerdem
wird häufig das Anbieten eines Zusatzgeschäfts trainiert, ein Geschäft das nach dem Abschluß
einen Zusatznutzen bei der Kombination mit einem anderen Produkt bringen soll.
Eine telefonische Bestellannahme, die in etwa ShopTel ähnlich wäre, zeichnet sich daher
idealerweise durch eine sehr große Kompetenz in der entsprechenden Produktauswahl aus,
außerdem sollte die Rolle des Annehmenden eher aktiv sein, um z.B. die bereits angesprochenen
Zusatzgeschäfte zu generieren. An Informationen wird in diesem Fall ebenfalls der
Kundenname, die genaue Bestellung, die Bezahlungsart und eine Lieferadresse benötigt.
Häufig wird der Kunde allerdings nur über eine Kundennummer identifiziert, unter der bereits
die genaue Anschrift und die bevorzugte Bezahlungsart gespeichert ist. Eine genaue
Abfolge der einzelnen Segmente in einem Dialog mit einer solchen Bestellannahme ist allerdings
nicht vorhanden, diese Anordnung kann sehr flexibel gehandhabt werden und sich von
Gespräch zu Gespräch unterscheiden. Wichtig ist jedoch, daß für eine effektive Bestellung
alle benötigten Informationen vorliegen.
Bedingt durch die Fähigkeit des Menschen, sich auf andere Mitmenschen einzustellen und
jede Situation selbständig beurteilen zu können, kann bei Telefongesprächen einer Bestellannahme
keine feste Abfolge von Sequenzen (siehe Abschnitt 2.2.1) beobachtet werden.
2 Für Details, insbesondere die verschiedenen Sprechakte des aktiven Telefonmarketings betreffend, wird
auf [Plog 1996] verwiesen. Die Akzeptanz und das rechtliche Umfeld des aktiven Telefonmarketings werden
bei [Müller 1994] dargestellt.

6.2. DIALOGSEGMENTE IN SHOPTEL 63
Grundsätzlich können jedoch zwei bis vier Grundsequenzen einer Bestellung extrahiert werden:
• Sequenz Authentifizierung mit den Komponenten Namensnennung und Nennung der
Kundennummer
• die Sequenz Bestellung mit den Komponenten Produkt und Anzahl, weitere optionale
Komponenten, wie Eigenschaften, Mengeneinheit oder Ausschlußkriterien können
ebenfalls existieren
• die Angabe einer Bezahlungsart, wenn diese nicht beim Versender gespeichert ist, die
Komponenten sind dabei die jeweiligen erforderlichen Daten
• die optionale Sequenz Lieferadresse mit der gleichnamigen Komponente
Neben diesen maximal vier Grundsequenzen kann es allerdings beliebig viele Erweiterungsformen
geben: so ist zum Beispiel eine gezielte Kundenberatung denkbar, es kann ein erster
Support gegeben werden oder ein Vergleich von verschiedenen Produkten kann angestellt
werden.
Da die meisten dieser Problemfelder momentan für ein Dialogsystem sehr schwer zu bearbeiten
sind und außerdem ShopTel in einem engen Zeitrahmen entstanden ist, wurde für die
aktuelle Version keine dieser Erweiterungen aufgenommen. Daher wurde, wie bereits in der
Spezifikation in Abschnitt 5.4.1 festgehalten, das System nur mit einer Grundfunktionalität
ausgestattet, die allerdings erweiterbar ist. Diese Funktionalität konnte im gesteckten Zeitrahmen
implementiert werden und führte auch zu brauchbaren Ergebnissen (vgl. Abschnitt
5.5).
Für ShopTel konnten kaum menschliche Vorgehensweisen übernommen werden. Die Komplexität
des menschlichen Verhaltens ist dafür momentan noch zu groß. Es wurde lediglich
versucht, die Prompts möglichst benutzerfreundlich und informativ zu gestalten, um damit
einen zuvorkommenden und freundlichen Eindruck zu vermitteln. Es werden für eine
Bestellung mit ShopTel die gleichen Informationen benötigt, wie für eine Bestellung mit
einem menschlichen Gesprächspartner. Auch im Falle von ShopTel werden diese solange
nachgefragt, bis eine zufriedenstellende Antwort gegeben wird.
6.2 Dialogsegmente in SHOPTEL
Im letzten Abschnitt wurden die Sequenzen mit ihren jeweiligen Komponenten für eine
Bestelldomäne dargestellt. Diese Sequenzen aus menschlichen Dialogen stellen die Basis für
die Segmente des Konversationssystems ShopTel dar. Dabei werden nur die Segmente einer
Bestellung konstruiert, die für eine Grundfunktionalität benötigt werden. Bereits im Rahmen
der Spezifikation (siehe Abschnitt 5.4.1) sind die mit dem System durchführbaren Aktionen
festgehalten worden, die in Dialogsegmente umgesetzt werden. Die Aktionen gingen vor
allem von dem Szenario aus, das in Abschnitt 5.2 beschrieben wurde. Demnach besteht das
erste für einen Benutzer durchführbare Dialogsegment aus der Authentifizierung. In diesem
Segment müssen der Name und eine Kundennummer geäußert werden. Als zweites Segment
kommt anschließend eine Auflistung und Disambiguierung der verschiedenen Produkte in
Frage. Dieses ist das Hauptsegment von ShopTel, hier sollte ein Produkt disambiguiert
und anschließend in beliebiger Größenordnung bestellt werden können. Schließlich sollte

64 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN
eine Bezahlungsroutine folgen, die ebenfalls als Dialogsegment angesehen wurde. In diesem
Segment stehen verschiedene Bezahlungsmöglichkeiten zur Verfügung unter denen der Kunde
eine auswählt und die dafür nötigen Angaben macht. In einer Einsatzumgebung wäre es
sicherlich sinnvoll, diese Stelle nur einmal von einem Kunden abzufragen, die jeweiligen
Angaben zu speichern und sich diese bei einer erneuten Bestellung nur bestätigen zu lassen.
Um jedoch die Funktionalität und Möglichkeiten des Systems vorzuführen, werden diese
Angaben bei jedem Bestellvorgang individuell abgefragt.
Eine Lieferadresse kann ebenfalls gespeichert und nur nötigenfalls geändert werden, doch
um auch hier die Leistungsfähigkeit des Systems zu demonstrieren und den gesamten Ablauf
einer Bestellung abzubilden, werden auch diese Daten bei jeder Bestellung erneut angefragt.
Damit sind für ShopTel vier verschiedene Dialogsegmente gefunden worden, die für die
Realisierung dieser Grundfunktionalität in die Forms umgesetzt werden müssen. Die Umsetzung
und die daraus resultierenden verschiedenen Forms werden im nachfolgenden Abschnitt
näher beschrieben. Dabei wird auch das Konzept der Forms in den IBM ViaVoice
Telephony Natural Language Tools noch einmal kurz aufgegriffen.
6.3 Forms in SHOPTEL
Bereits in Abschnitt 5.3.13 wurden Forms grundsätzlich dargestellt. Hier soll genauer auf
die Forms im allgemeinen und die Forms von ShopTel im speziellen eingegangen werden.
Grundsätzlich sind die Forms anwendungsabhängig, sie müssen also für jede Anwendung
neu erstellt werden. Die Forms werden vom FDM geladen und ermöglichen diesem die Abwicklung
der jeweiligen Aufgaben. Die Forms sind dabei in einer Datei enthalten, die einen
klar strukturierten Aufbau hat. Wie allgemein in Computerprogrammen üblich, existiert
ein Hauptmenü, in dem alle nötigen Variablen für die Forms definiert werden. So wird zum
Beispiel der erste Systemprompt definiert, der zur Begrüßung eines Benutzers synthetisiert
wird. Desweiteren werden die ersten aktiven Forms definiert, also die Forms, die von Anfang
an aktiviert sind und in die der Benutzer mit seinen Äußerungen springen kann. Anschliessend
werden verschiedene Nachrichten (engl. messages) gesetzt, wie Hilfetexte oder auch die
Rückfragen für nicht verstandene Äußerungen. Es folgen die einzelnen Forms in der Datei. In
einem Form werden üblicherweise zuerst die abstrakten Slots (Slots ohne inhaltlichen Wert 3 )
definiert, danach die konkreten Slots. Die abstrakten Slots dienen nur der Zuordnung einer
Äußerung zu einem Form, die konkreten Slots werden zur Erfassung von Daten eingesetzt.
Für jeden konkreten Slot wird eine Message definiert, die synthetisiert wird, wenn der Slot
nicht gefüllt ist. Desweiteren existiert für jeden dieser Slots ein Backend-Aufruf, der zur Disambiguierung
der Information nötig ist (vgl. Abschnitt 5.3.5). Im Anschluß an jede Backend-
Message existiert eine RC-List (return code), in welcher differenziert nach der Rückgabe des
Backends verschiedene Aktionen ausgeführt werden können. Nach allen Slots enthält ein
Form einen weiteren Backend-Aufruf, in dem eine weitere Disambiguierung erfolgt. In diesem
Aufruf wird nun auf alle Informationen des kompletten Forms zugegriffen, egal ob sie in
einer Äußerung oder in mehreren mitgeteilt wurden. Nach diesem Aufruf existiert wieder eine
RC-Liste, die auch wieder je nach Rückgabe des Backend verschiedene Aktionen erlaubt.
Zusätzlich können hier auch neue Messages definiert werden, somit wird zum Beispiel die
kontextsensitive Hilfe ermöglicht.
3 Ein Beispiel für einen abstrakten Slot wurde in Abschnitt 5.3.13 vorgestellt.

6.3. FORMS IN SHOPTEL 65
Jedes Form muß über mindestens einen Slot verfügen, dabei sind sowohl abstrakte, als auch
konkrete Slots erlaubt. Desweiteren stehen optionale Slots zur Verfügung, die nur nachgefragt
werden, wenn sie mit einer Benutzeräußerung gefüllt werden können. Jeder Slot, der einmal
gefüllt wurde, muß auch disambiguiert werden. Aus diesem Verhalten resultiert die Klärung
von ambigen Daten, wie sie in Abschnitt 5.3.13 erwähnt wurde.
Somit sind die Forms im allgemeinen eingeführt. 4 Dies ist die Voraussetzung, für die folgende
exemplarische Darstellung eines konkreten Forms von ShopTel.
Wie bereits im letzten Abschnitt dargelegt, wurden für ShopTel folgende verschiedene Dialogsegmente
für die in Abschnitt 5.2 beschriebene Grundfunktionalität herausgearbeitet:
• Authentifizierung
• Auflistung
• Bezahlung
• Eingabe der Lieferadresse
Diese Segmente stellen damit auch die ersten zu implementierenden Forms für ShopTel dar.
Das Form für die Authentifizierung wird im folgenden Abschnitt vorgestellt, dabei werden
die jeweiligen Slots und etwaige Besonderheiten zur Sprache kommen. Die anderen Forms
werden kurz im nachfolgenden Abschnitt behandelt.
6.3.1 Form INIT
Wie bereits eingeführt, sollte in ShopTel eine Bestellung nur identifizierten Kunden möglich
sein. Daher wird jeder Benutzer von ShopTel zuerst nach seiner Kundennummer und seinem
Namen gefragt. Diese Abfragen werden von dem Form INIT geleistet. Für die Kundennummer
und den Namen wird jeweils ein Slot benötigt, desweiteren wurde ein abstrakter Slot
geschaffen. Um außerdem bereits bei der Authentifizierung geäußerte Bestellwünsche verarbeiten
zu können, wurde ein optionaler Slot für Produkte vorgesehen.
Die Kundennummer und der Name müssen mit dem Backend (siehe Abschnitt 5.3.5) abgeglichen
werden. Wenn beide Werte bestätigt werden, ist das Form abgearbeitet und ein
anderes Form kann verarbeitet werden. Wie alle Forms, so enthält auch dieses einen eigenen
Hilfetext, der bei Bedarf synthetisiert wird. Außerdem wurde bei diesem Form die Möglichkeit
geschaffen, neue Benutzer zu akzeptieren. Dies wurde durch die Implementierung eines
Musterbenutzers mit einer allgemeinen Kundennummer verwirklicht. Wenn dieser Benutzer
geäußert wird, liefert das Backend einen anderen RC, als wenn ein normaler, bereits registrierter
Benutzer, sich anmelden wollte. Diese Nachricht wird in der RC-List ausgewertet.
Bei einer üblichen Anmeldung wird das Form normal beendet, bei einem neuen Kunden ein
anderer Prompt für das Hauptmenü und außerdem eine interne Variable gesetzt, welche die
weitere Verarbeitung in den Forms beeinflußt. Näheres über diese Abläufe kann Abschnitt
6.4 entnommen werden.
Um einen besseren Überblick zu ermöglichen, ist eine gekürzte Fassung des Forms INIT in
Abbildung 6.1 dargestellt. Die einzelnen Slots des Forms werden in Tabelle 6.1 dargestellt.
Die Tags und Labels des Parsers, die zur Identifikation dieses Forms und für die einzelnen
Slots benötigt werden, sind im Anhang in Abschnitt B.2 abgebildet.
4 Weitere Informationen können [IBM 1999b; Papineni et al. 1999] entnommen werden.

66 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN
\begin{form} INIT
\begin{slots}
\slot INIT ^MatchedBy: INIT
\slot NAME ^MatchedBy: NAME name
\begin{messages}
\msg Prompt: ‘‘bitte nennen sie ihren namen’’;
\msg BEMsg: BE-EXIST {$NAME}
\begin{rclist}
\rc NOT_FOUND \msg Prompt: ‘‘der name ist falsch’’;
\end{rclist}
\end{messages}
\slot PIN ^MatchedBy: NUM num
\begin{messages}
\msg Prompt: ‘‘bitte nennen sie ihre kundennummer’’;
\msg BEMsg: BE-EXIST {$PIN}
\begin{rclist}
\rc NOT_FOUND \msg Prompt: ‘‘falsche kundennummer’’;
\end{rclist}
\end{messages}
\slot PRODUCT ^MatchedBy: PRODUCT product
^Optional: yes
\begin{messages}
\msg BEMsg: BE-SET {$PRODUCT}
\end{messages}
\end{slots}
\begin{messages}
\msg HelpMsg: ‘‘bitte nennen sie den namen und die kundennummer ...’’;
\msg BEMsg: BE-EXAM {$PIN $NAME}
\begin{rclist}
\rc ERROR \msg Prompt: ‘‘falsche angaben, bitte wiederholen’’;
\rc TEST \msg Prompt: ‘‘willkommen als probebenutzer ...’’
\rc OK \msg Prompt: ‘‘hallo $NAME ...’’;
\end{rclist}
\end{messages}
\end{form}
Abbildung 6.1: Form INIT (gekürzt)

6.3. FORMS IN SHOPTEL 67
Slotname Slotart Beschreibung
INIT abstrakt Slot für Auswahl des Forms
NAME konkret Slot für Kundenname
PIN konkret Slot für Kundennummer
PRODUCT optional, konkret Slot für Produktauswahl
6.3.2 Weitere Forms
Tabelle 6.1: Slots im Form INIT
In diesem Abschnitt werden kurz die wesentlichen Merkmalen der wichtigsten übrigen Forms
von ShopTel vorgestellt. Die Darstellungen erfolgen stark vergröbert, da diese Informationen
als IBM Vertraulich eingestuft sind.
Form LIST
Das Form für die Auflistung und Disambiguierung der zu bestellenden Produkte wird mit
LIST bezeichnet. In diesem Form werden vor allem Informationen über die gewünschten
Produkte mit ihren Eigenschaften benötigt. Daneben wird die Angabe einer Anzahl und
einer Größeneinheit gebraucht, um eine Bestellung abwickeln zu können. Um schließlich
auch eine Preisgrenze für eine mögliche Bestellung angeben zu können, wurde ein Slot für
diesen Zweck eingeführt, der letzte Slot dient für Ausschlußkriterien, um beispielsweise ein
Notebook ohne DVD-Laufwerk bestellen zu können.
Die meisten implementierten Slots sind als optionale Slots implementiert worden, da entweder
Default-Annahmen gesetzt werden oder Slots auch ungefüllt bleiben können. Die
Produkteigenschaften sind als ein optionaler Slot implementiert, da so der Benutzer nur
nach dem Produkt, nicht nach seinen Eigenschaften direkt gefragt wird.
Die Auswahl eines zu bestellenden Produkts verläuft normalerweise in mehreren Schritten.
Zuerst wird eine Produktkategorie geäußert, diese wird mit dem Backend abgeglichen und
wenn mehr als fünf mögliche Produkte vorliegen, als longlist zurückgegeben. Bei diesem
RC wird nur die Anzahl der verfügbaren Produkte genannt und nach einer weiteren Spezifizierung
der Auswahl gefragt. Wenn die Auswahlmenge fünf oder weniger Elemente umfaßt,
ist der RC shortlist, nun werden alle Produkte einzeln vorgetragen. Dies läßt sich an
Abbildung 6.2 nachvollziehen, dort ist in einem Ausschnitt aus dem Form LIST der Slot
PRODUCT dargestellt.
Die Unterscheidung zwischen einer shortlist und einer longlist wird bereits vom Dialogmanager
unterstützt. Es muß für diesen nur definiert werden, wieviele Elemente die kurze
Liste enthält, dann bietet der DM diese Unterscheidung selbstätig an.
Selbstverständlich ist es mit diesem Form auch möglich, gezielt ein bestimmtes Produkt
mit seiner Artikelnummer zu bestellen. In diesem Fall wird die Nummer dem Slot PRODUCT
zugeordnet, da bereits der Classer diese Zuordnung durchführt.
Grundsätzlich werden alle Slots nur von passenden Tags und Labels gefüllt. Diese werden
gesondert für jeden Slot aufgezählt. Auf der Abbildung 6.2 ist nicht nur product in dieser
Liste enthalten, num-ord ist ebenfalls aufgezählt, da die Auswahl aus einer Liste sehr
häufig durch Nennung der entsprechenden Position erfolgt, die Positionsnummer steht daher
in diesem Fall für das auszuwählende Produkt. Erst im Backend wird die Unterscheidung

68 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN
zwischen der expliziten Nennung eines Produkts und der seiner Listenposition aufgelöst und
das jeweilige Produkt disambiguiert.
\slot PRODUCT ^MatchedBy: product num-ord
\begin{messages}
\msg Prompt: ‘‘was möchten sie bitte bestellen’’;
\msg BEMsg: BE-EXIST {$PRODUCT}
\begin{rclist}
\rc OK \msg Prompt: ‘‘sie möchten also $PRODUCT bestellen’’;
\rc LONG_LIST \msg Prompt: ‘‘ich habe $::count produkte ...’’;
\rc SHORT_LIST \msg Prompt: ‘‘ich habe $PRODUCT, welches ...’’;
\rc NOT_FOUND \msg Prompt: ‘‘kein passendes produkt gefunden’’;
\end{rclist}
\end{messages}
Abbildung 6.2: Der Slot PRODUCT (Ausschnitt aus dem Form LIST)
Der Dialogmanager handhabt auch Überbeantwortungen, kann also mehr als einen Slot pro
Benutzeräußerung füllen. Wenn jedoch eine wichtige Information fehlt, muß diese nachgefragt
werden. Um diese Nachfragen für den Benutzer möglichst komfortabel zu gestalten,
wurden die Prompts in vielen Slots kontextsensitiv gestaltet. Wenn eine Stückzahl und ein
korrektes Produkt angegeben wurden, kann der Prompt für den RC OK lauten, wie auf
Abbildung 6.2 dargestellt, falls jedoch die Stückzahl fehlt, muß diese nachgefragt werden.
Die Abbildung ist daher stark vereinfacht. Häufig werden, um den Informationsgehalt der
einzelnen Prompts zu maximieren, diese im Backend generiert und nur noch an die Forms
übertragen. Dieser Schritt war zwar sehr aufwendig zu implementieren, erlaubt dem System
jedoch sehr viel benutzerfreundliche Antworten.
Mit diesem Vorgehen wurde versucht, soviel erkannte Information wie möglich dem Benutzer
vorzulegen, um damit möglicherweise aufgetretene Fehler korrigieren zu können. Dieses
Vorgehen entspricht einer robusten und kooperativen Dialogstrategie (vgl. Abschnitt 2.5).
Um eine Bestellung abschließend auch durchzuführen, muß diese noch einmal komplett
bestätigt werden. Da es sich bei einer Bestellung um eine Aktion handelt, die sich finanziell
bei einem Benutzer auswirkt, gilt für diese auch ein gewisser Sicherheitsfaktor. Der
FDM bietet die Möglichkeit, Bestätigungsfragen einfach in ein Form zu integrieren. Nur
bei positiver Beantwortung wird mit dem Form fortgefahren, eine Ablehnung wird einmalig
hinterfragt und hat bei erneuter Ablehnung den Abbruch der Aktion zur Folge, das Form
wird beendet und etwaig gefüllte Slots werden gelöscht. Eine solche Bestätigungsfrage wurde
auch in LIST verwendet, erst nach dieser Bestätigung wird das Form beendet. Die RC-List
des Forms ist sehr kurz, da es nur den Fall einer erfolgreichen durchgeführten Bestellung
gibt. Ein Benutzer kann allerdings jederzeit die Aktion einfach abbrechen und befindet sich
dann wieder im Hauptmenü von ShopTel.
Form PAYMENT
Zur Bezahlung einer erfolgreich durchgeführten Bestellung dient das Form PAYMENT. Wie
schon im Szenario (Abschnitt 5.2) erwähnt, stehen in ShopTel mehrere Bezahlungsmöglichkeiten
zur Auswahl, die alle von einem Form verarbeitet werden. Dies vereinfacht die grundlegende
Struktur der Forms.

6.4. STRATEGIEN FÜR SHOPTEL 69
Die benötigten Slots leiten sich aus den möglichen Bezahlungsmodalitäten ab. Zuerst muß
der jeweils gewählte Modus festgehalten werden. Für die Bezahlung mit der Kreditkarte
werden ferner der Kartentyp, eine Kartennummer und ein Gültigkeitsdatum gebraucht (der
Name ist ja bereits am Anfang erfaßt worden), für einen Bankeinzug bedarf es einer Kontonummer,
einer BLZ und einer Bank. Nur für die Zusendung mit Rechnung oder per Nachnahme
werden keine weiteren Angaben benötigt. Die Adresse wird bei jeder Rechnungsart
benötigt, ist jedoch idealerweise von jedem Kunden bereits bekannt oder wird abschließend
mit der Abfrage der Lieferadresse erfaßt.
Form DELIVERY
Um eine Bestellung schließlich noch zusenden zu können, wird eine Lieferadresse benötigt.
Diese muß nicht mit der Heimatadresse eines Benutzers übereinstimmen, daher wurde das
Form DELIVERY konstruiert, das eine Lieferadresse verarbeiten kann. Neben dem für jedes
Form nötigen abstrakten Slot wurden je ein Slot für einen Straßennamen, eine Postleitzahl
und den Ortsnamen implementiert. Mit diesen Angaben kann eine komplette Adresse
abgefragt werden. Vorteilhaft für den Benutzer ist an dieser Stelle die Möglichkeit einer
Überbeantwortung, es ist nicht nötig, jede benötigte Angabe extra zu äußern.
Hilfsforms
Die bisher aufgeführten Forms reichen für eine Grundfunktionalität von ShopTel aus. Um jedoch
die Funktionalität des Systems zu erweiteren, wurden einige weitere Forms konstruiert,
die hier aus Vertraulichkeitsgründen nicht näher dargestellt werden.
6.4 Strategien für SHOPTEL
Nachdem das Szenario und die Funktionalität von ShopTel vorgestellt und auch die einzelnen
Forms des Systems besprochen wurden, werden in diesem Abschnitt verschiedene Möglichkeiten
für die Abfolge der einzelnen Forms bei einer Bestellung mit dem System diskutiert
und dargelegt. Eine feste Abfolge ist nötig, um eine übersichtliche, einfache und nachvollziehbare
Bestellung mit dem System zu ermöglichen. Zwar ist der DM der NLU-Tools auch in
der Lage, Benutzeräußerungen ohne eine feste Abfolge der Forms richtig zuzuordnen, doch
sank mit Einführung dieser Abfolge die Fehlerrate erheblich. Außerdem kann mit dieser
Maßnahme der doppelten Erhebung von Daten wirksam begegnet werden.
Die Steuerung der einzelnen Forms wird anhand der RC-List vorgenommen, die am Ende
jedes Forms zwingend vorliegen muß. Diese Listen haben die Aufgabe, je nach Rückgabewert
des Backends, eine differenzierte Weiterverarbeitung zu ermöglichen. Am Beispiel des
Forms LIST (Abschnitt 6.3.2) wurde dies für einen Slot verdeutlicht. Eine solche Unterscheidung
ist jedoch auch für ein gesamtes Form, also nach Füllung aller Slots möglich.
Bei ShopTel wurde somit beispielsweise die Differenzierung von bekannten und von Testbenutzern
im Form INIT (Abschnitt 6.3.1) realisiert. Mit den RC-Lists sind jedoch auch
noch andere Maßnahmen durchführbar, so sind in den IBM ViaVoice Telephony Natural
Language Tools auch Befehle zur Aktivierung und Deaktivierung von ganzen Forms enthalten.
Mit diesen können nur bestimmte Forms als aktiv definiert werden, um damit eine
neue Äußerung nur noch in einem der aktiven Forms zu verarbeiten. Die Auswahlmenge

70 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN
für ein passendes Form wird also kleiner. Mittels dieser Kommandos lassen sich somit zum
Beispiel Steuerungsmöglichkeiten in einem Dialogsystem implementieren.
Für die Betrachtung der Strategien ist die interne Arbeitsweise der Forms nicht weiter
wichtig, es wird daher von dieser abstrahiert. Ein Form wird somit in diesem Abschnitt nur
als eine black box angesehen, das eine Aktion oder Aufgabe erfüllen kann. Es wird nur auf
die verschiedenen möglichen Zustände eines Forms nach seiner Abarbeitung eingegangen.
Diese Zustände werden in der RC-List repräsentiert.
In den folgenden Abschnitten wird die Strategie der Steuerungsmöglichkeiten näher dargestellt.
Es werden die verschiedenen Strategien für ShopTel erläutert und deren Einfluß auf
das Benutzerverhalten diskutiert. Desweiteren wird das graphical ControlCenter vorgestellt,
das eine einfache Änderung dieser Strategien erlaubt.
6.4.1 Strategien in SHOPTEL
In diesem Abschnitt wird die Abfolge der Forms für das System dargestellt, wie sie in
der momentan lauffähigen Version vorliegt. Die anderen denkbaren Alternativen werden
anschließend im nächsten Abschnitt behandelt.
Wie bereits erwähnt, sollte eine Bestellung mit ShopTel nur einem authentifizierten Kunden
möglich sein, daher wurde das Form INIT als erstes aktiviert. Sämtliche anderen Forms stehen
am Anfang nicht zur Verfügung. Mit dieser Maßnahme wird ein Benutzer somit gezwungen,
sich zu authentifizieren, ansonsten wird keine Bestellung angenommen, da das System vor
der Abarbeitung dieses Forms über keine weiteren aktiven Forms verfügt.
Wie bereits mehrfach dargestellt, kann INIT auf zwei verschiedene Arten beendet werden.
Zum einen kann sich ein Benutzer mit seiner eigenen Kundennummer anmelden, zum anderen
besteht die Möglichkeit das System als Testbenutzer zu verwenden. Es gibt noch einen
weiteren Fall in der RC-List, der allerdings im folgenden bei allem Forms nicht weiter behandelt
werden wird, die Rede ist von der RC-List ERROR. Sollte der RC diesen Wert aufweisen,
werden die Werte sämtlicher Slots gelöscht und das Form kann wieder von neuem abgearbeitet
werden. Da in diesem Fall keine erfolgreiche Abarbeitung eines Forms geschehen ist,
wird er im folgenden nicht weiter behandelt.
Für jeden Benutzer beginnt ein Gespräch mit ShopTel mit der Initialisierung, die das Form
INIT leistet. Ein Benutzer, der bereits über eine Kundennummer verfügt, wird im Anschluß
daran um die Angabe seines Bestellwunsches gebeten. Um diese Funktionalität bieten zu
können, wird das Forms LIST aktiviert. Desweiteren wird der Prompt des Hauptmenüs
geändert, statt des Eingangstextes wird nun nach der gewünschten Bestellung gefragt.
Für einen Testbenutzer stehen exakt die gleichen Forms zur Verfügung, allerdings ist der
Begrüßungsprompt des Systems nach erfolgter Authentifizierung sehr viel ausführlicher und
es wird eine interne Variable gesetzt, um den Status des Kunden darin abzuspeichern.
Wenn die erste Bestellung erfolgreich durchgeführt wurde, wird automatisch PAYMENT aktiviert,
um somit sicherzustellen, daß die erfolgte Bestellung auch bezahlt wird. Gleichzeitig
wird der Prompt des Hauptmenüs verändert, der nun nicht mehr nur nach einer Bestellung
fragt, sondern auch anbietet, diese bezahlen zu können. Da aber einem Benutzer noch weitere
Bestellungen möglich sein sollen, sind die dafür nötigen Forms keinen Veränderungen
unterworfen.

6.4. STRATEGIEN FÜR SHOPTEL 71
Nach erfolgter Bezahlung der Bestellung in PAYMENT werden zuerst sämtliche Forms für
die Durchführung einer Bestellung deaktiviert. Desweiteren wird in Abhängigkeit des Benutzerstatus
getrennt verfahren. Für Testbenutzer ist an dieser Stelle der Bestelldurchgang
beendet. Der Standardbenutzer wird noch nach einer Lieferadresse befragt, dafür wird das
Form DELIVERY aktiviert, außerdem fordert der Prompt nun die Nennung dieser Adresse.
Abbildung 6.3: Grobes Dialogmodell für Bestelldurchgang eines bekannten Benutzers
Die vorgestellte Strategie für einen bekannten Benutzer ist zur besseren Verdeutlichung
auch der Abbildung 6.3 zu entnehmen, diese enthält das Dialogmodell der vorgestellten
Strategie auf der Basis von Segmenten. In der aktuell laufenden Version von ShopTel ist
diese Strategie implementiert. Beispiele für Dialoge mit dieser Version des Systems sind im
Anhang zu finden.
6.4.2 Alternative Strategien
Neben der im letzten Abschnitt dargestellten Strategie können auch weitere mit ShopTel
umgesetzt werden. So kann zum Beispiel die Authentifizierung erst nach einer erfolgreichen
Bestellung, vor der Bezahlung durchgeführt werden. Die Eingabe einer Lieferadresse
kann eliminiert werden und es können sogar die Aktionen der Forms INIT, PAYMENT und
DELIVERY weggelassen werden und somit ein reines Bestellsystem konstruiert werden. Die
Übermittlung der persönlichen Daten zu dieser Bestellung müßte dann auf anderem Wege
vorgenommen werden.
Eine weitere Möglichkeit besteht darin, nach Durchführung der Bezahlung weitere Bestellungen
mit LIST zuzulassen und somit verschiedene Bezahlungsarten für unterschiedliche
Produkte zu ermöglichen.
Während der Konstruktion von ShopTel wurden einige der erwähnten Alternativen ausprobiert.
Die Implementation der vorhandenen Strategie begündete sich dabei weniger mit einer
hohen Erfolgsrate, sondern mit der größeren Komplexität dieser Lösung. Dies dient nicht nur
der Demonstration der Leistungsfähigkeit von modernen Dialogsystemen, vielmehr konnten
auf dieser Basis auch ansprechendere Dialoge geführt und anspruchsvolle Testdaten gesammelt
werden. Am wichtigsten ist allerdings, daß dieser Verlauf einer Bestellung der Realität
meiner Meinung nach am nächsten ist und somit diese Strategie den schon in Abschnitt 5.1
geforderten Zielen folgt.

72 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN
Die Bandbreite der möglichen Strategien für ShopTel ist sehr groß und zeigt damit die
Flexibilität des Forms-Ansatzes der NLU-Tools. Für den Großeinsatz von Dialogsystemen
in der Praxis heißt dies, daß die teure und langwierige Konstruktion von solchen Systemen
verkürzt werden kann, indem für jeden Zweck auf entsprechende Forms zurückgegriffen wird.
Nach Veränderung der jeweiligen Prompts ist damit nicht nur ein internationaler, mehrsprachiger
Einsatz von Dialogsystemen machbar, auch die Wiederverwendung von einzelnen
Forms in anderen Kontexten ist möglich. Das Form INIT kann beispielsweise auch zur Initialisierung
von Kunden in anderen sicherheitskritischen Bereichen eingesetzt werden, wie
zum Beispiel zum automatischen Telebanking. Für diesen Zweck müssen nur die Prompts
entsprechend angepaßt werden, die Funktionalität ist vorhanden und flexibel einsetzbar.
Um die Implementation von einzelnen Strategien in einem Dialogsystem schnell und einfach
möglich zu machen, wurde ein spezielles Tool entwickelt. Dieses kann dem Einsatz zur Konstruktion
von Dialogsystemen, die auf den NLU-Tools basieren, dienen. Das Tool, graphical
ControlCenter genannt, wird im folgenden Abschnitt vorgestellt.
6.4.3 Graphical ControlCenter
Das graphical ControlCenter (gCC) wurde konstruiert, um verschiedene Strategien in
einem Dialogsystem schnell anwenden zu können. Es handelt sich dabei um eine graphische
Oberfläche (engl. graphical user interface) (GUI), die in Tcl betriebssystemunabhängig
implementiert wurde.
Da die Veränderung von Abläufen in der Forms-Datei eine gewisse Kenntnis der Umgebung
voraussetzt, wurde mit gCC ein Ansatz geschaffen, die Erstellung von Dialogsystemen auf
diesen Tools stark zu vereinfachen und somit zu beschleunigen.
Abbildung 6.4: Ansicht des gCC mit MAINMENU von ShopTel

6.4. STRATEGIEN FÜR SHOPTEL 73
Abbildung 6.5: Ansicht des gCC mit PAYMENT von ShopTel
Das gCC kann Forms-Dateien von verschiedensten Anwendungen einlesen und bereitet deren
Inhalt graphisch auf. In der aktuellen Version werden die einzelnen Forms einer Datei
angezeigt, beginnend mit dem MAINMENU, dem für jede Forms-Datei nötigen Hauptmenü,
in dem die initial aktiven Forms vermerkt werden. Das geöffnete Hauptmenü von ShopTel
in gCC ist auf Abbildung 6.4 dargestellt, dort ist auch zu erkennen, daß nur INIT am Anfang
als initiales Form aktiviert ist.
Die Ansicht von gCC zeigt die geladene Datei shopping.forms und als Karteikartenreiter
die einzelnen Forms der Anwendung. Im ausgewählten Hauptmenü werden neben dem Namen
des Forms auch die Kommentare aus diesem angezeigt. Desweiteren werden alle Slots
des Forms präsentiert, im MAINMENU ist dies nur der Slot MMVARS, in dem die Variablen
für das Haupmenü gesetzt werden. Als letztes werden alle möglichen initialen Forms der
Anwendung angezeigt, der Benutzer kann die jeweils gewünschten Forms per Mausklick aktivieren.
Im Falle von Veränderungen wird diese sofort automatisch im Programmcode der
Forms umgesetzt, es muß also keine separate Speicherung durchgeführt werden.
Es besteht die Möglichkeit, sich den Programmcode in einem Editor anzeigen zu lassen, ein
Druck auf den entsprechenden Knopf in gCC öffnet automatisch die jeweilige Datei in der
aktuellsten Version im Standardeditor.
Wenn ein anderes Form angezeigt wird, stehen dem Benutzer andere Einflußmöglichkeiten
zur Verfügung. In diesem Fall kann die RC-List der einzelnen Forms verändert werden. Es
können in jeder Liste alle Forms jeweils aktiviert oder deaktiviert werden, sie können aber
auch unbehandelt bleiben. Mit dieser Möglichkeit könnnen schnell verschiedene Strategien,
wie sie in den vorherigen Abschnitten angesprochen wurden, zum Einsatz gebracht werden.
Dies wird in Abbildung 6.5 am Beispiel des Forms PAYMENT illustriert. Dort sind die bereits
im Rahmen der Strategie in ShopTel (Abschnitt 6.4.1) erwähnten beiden RC-Lists darge-

74 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN
stellt. Für beide werden die Forms LIST-INF-DATA, LIST-INF-PRICE und LIST deaktiviert,
für TEST wird HANGUP aktiviert und damit das Ende des Gesprächs mit ShopTel eingeleitet.
Für den Standardbenutzer werden in OK DELIVERY und DELIVERY-SPEC aktiviert, um
die Lieferadresse angeben zu können. Außerdem wird für beide Listen das Form PAYMENT
deaktiviert, um eine erneute Frage nach der Bezahlung zu vermeiden.
Bisher nicht in gCC implementiert sind die verschiedenen Prompts der einzelnen RC-Lists.
Diese sind im Fall der beiden vorgestellten Alternativen ebenfalls unterschiedlich, müssen
bisher allerdings noch manuell in der Forms-Datei verändert werden. Die Integration der
Prompts in gCC stellt somit eine angestrebte Erweiterung des Tools dar.
Mit einer zusätzlichen Erweiterung kann gCC auch eine Unterstützung bei der Konstruktion
von neuen Forms darstellen. Das gCC könnte dann mittels einfacher benutzergesteuerter
Auswahl neue Forms aus Standardelementen generieren und somit schnell erstellen. In diesem
Fall muß nur noch die Funktionalität des Backends bereitgestellt werden, um die Forms
erfolgreich einsetzen zu können. Dies wird auf längere Sicht die anspruchsvollere und nicht
vereinfachbare Aufgabe des Konstrukteurs eines solchen Systems bleiben. Mit der teilweisen
oder auch ganzen Wiederverwendung von Forms, die das gCC ebenfalls ermöglicht, können
der Entwurf und die Konstruktion von neuen Dialogsystemen weiter beschleunigt werden.
6.5 Zusammenfassung
Mit diesem Kapitel wurde die Darstellung und Beschreibung des Konversationssystems
ShopTel abgeschlossen, die in Kapitel 5 begonnen wurde. Dort wurden vor allem die technischen
Merkmale des Systems und seiner Architektur beschrieben
In diesem Kapitel wurden zuerst menschliche Dialoge in der Domäne von ShopTel und ihre
Besonderheiten vorgestellt. In diesem Rahmen wurde das Telefonmarketing kurz skizziert
und die Wichtigkeit der Wortwahl in dieser auf einen Kanal reduzierten Kommunikation
dargestellt. Auf Grund dieser Umstände und wegen des zunehmenden Erfolgsdrucks der jeweiligen
Mitarbeiter wurde eingeführt, daß in diesem Beschäftigungsfeld meist ausschließlich
speziell geschultes Personal eingesetzt wird.
Die durch solche Schulungen erworbene Kompetenz in einem Dialogsystem abzubilden erscheint
sehr schwer. Aus diesem Grund wurde für ShopTel ein vereinfachtes Szenario entworfen,
daß bereits in Abschnitt 5.2 thematisiert wurde und für das in diesem Kapitel die nötigen
Sequenzen und Komponenten, sowie die daraus abgeleiteten Dialogsegmente dargestellt
wurden. Letztere wurden auf die Forms abgebildet, die jeweils eine eigene Funktionalität in
Zusammenarbeit mit dem Backend bereitstellen. Dabei wurden einige Forms des Systems
behandelt und in ihrer Funktionalität vorgestellt.
Somit wurden nun alle Komponenten und Bestandteile von ShopTel eingeführt und in ihrer
Funktionsweise dargestellt. Um den Ablauf eines Dialogs mit dem System zu steuern, wurden
die implementierte und auch verschiedene andere Strategien vorgestellt. Erstere besteht
aus einem festen Ablauf der einzelnen Dialogsegmente des Systems. Dieser entspricht meiner
Ansicht nach am besten der bereits in Abschnitt 5.1 gestellten Forderung nach einer sinnvollen
Anordnung der Dialogsegmente mit einem intuitiven Ablauf. Trotz des festen Ablaufs
wird im Rahmen der aktuell während eines Dialogs aktiven Forms dem Benutzer eine Auswahl
unter diesen ermöglicht. So kann beispielsweise nach einer erfolgten Bestellung benutzerinitiativ
zwischen der Aktion ”
weitere Bestellung“ und der Aktion ”
Bezahlung“ gewählt
werden. Die vorgestellte Strategie ermöglicht damit zwar eine Benutzerführung, stellt aber

6.5. ZUSAMMENFASSUNG 75
trotzdem keine zu starke Einschränkung für den Benutzer dar, da sie, trotz ihrer Existenz,
dem Benutzer in vielen Fällen die Wahl der nächsten auszuführenden Aktion überläßt.
Die Erreichung der in Abschnitt 5.1 formulierten Ziele für die Konstruktion des Konversationssystems
ShopTel wird im folgenden noch einmal zusammenfassend dokumentiert. Dabei
wird auf die Erkenntnisse der Kapitel 5 und 6 zurückgegriffen.
• Die implementierte Dialogstrategie (Abschnitt 6.4.1) ordnet die verschiedenen Segmente
von ShopTel in der Weise an, daß ein intuitiver Ablauf des Bestellvorgangs
gewährleistet ist. Dies konnte auch mit der hohen Anzahl erfolgreich durchgeführter
Bestellungen im Rahmen der Evaluation in Abschnitt 5.5 nachgewiesen werden.
• Die Benutzerführung wurde, wie bereits angesprochen, durch die gewählte Strategie
mit den aktivierten und deaktivierten Forms vorgenommen. Dabei wurden gesteuerte
Dialoge nur dann geführt, wenn Angaben zur vollständigen Abarbeitung einer Aktion
fehlten oder aber diese bestätigt werden mußten. Die hierin bestehenden Beschränkungen
des Benutzers werden als sehr schwach bewertet.
• Ansonsten hatte der Benutzer stets die volle Auswahl unter den aktuell zur Verfügung
stehenden Aktionen und konnte somit einen freien Dialog mit dem System führen.
Die formulierten Ziele hinsichtlich der Qualitätseigenschaften von Software konnten ebenfalls
alle erfüllt werden. Die Datenbank mit den enthaltenen Produkten und Kunden kann
jederzeit erweitert werden. Eine Modularisierung der einzelnen Komponenten wurde bereits
von der Architektur der NLU-Tools gefordert und auch umgesetzt.
Die aufgestellte Forderung nach einer Wiederverwendbarkeit einzelner Module konnte ebenfalls
erfüllt werden. Dies wurde bereits bei der Vorstellung der verschiedenen denkbaren
Strategien für ShopTel dargestellt. Dieses Ziel entspricht dem grundlegenden Ziel der gesamten
Arbeit. Es sollten allgemeine Dialogsegmente gefunden werden und die Möglichkeit
für deren Wiederverwendung in anderen Systemen geprüft werden. Dies wurde schon für
das Form INIT positiv beantwortet und kann auch auf andere Forms ausgedehnt werden.
Außerdem bietet das System durch die verschiedenen möglichen Strategien vielfältige Einsatzmöglichkeiten,
die ebenfalls eine ganze oder teilweise Weiterverwendung erlauben.
Mit dem graphical ControlCenter wurde ein Ansatz zur schnellen Aktivierung von unterschiedlichen
Strategien in einem Dialogsystem vorgestellt. Gleichzeitig bietet dieses Tool
einen Rahmen für eine schnellere Konstruktion von zukünftigen Dialogsystemen, die auf
den IBM ViaVoice Telephony Natural Language Tools basieren. Wenn dem gCC noch
ein GUI für die Prompts eines Dialogsystems hinzugefügt werden kann, wird die Konstruktion
von Systemen in unterschiedlichen Sprachen sehr stark vereinfacht. Es müßten nur die
Prompts, der Canonicalizer, die Einträge der Datenbank, die TTS und der Erkenner in einer
anderen Sprachversion vorliegen, schon kann das Dialogsystem auch in einer Fremdsprache
betrieben werden.
Es kann somit festgestellt werden, daß auf der Basis von ShopTel unterschiedliche Konversationssysteme
schnell zur Anwendung gebracht werden können, die durch Erweiterungen
und Anpassungen sehr individuell ausgeführt sein können. Insbesondere die Forms können
als Templates für neue Systeme dienen und im Zusammenhang mit einer Weiterentwicklung
des gCC zu einer Beschleunigung der Konstruktionsphase beitragen.

76 KAPITEL 6. DIALOGSEGMENTE FÜR SHOPPING-ANWENDUNGEN

Kapitel 7
Ausblick
In der vorliegenden Arbeit wurde ein Konversationssystem für eine Shopping-Domäne vorgestellt,
das auf den IBM ViaVoice Telephony Natural Language Tools basiert. Die Konstruktion
mit den Werkzeugen der IBM erforderte einige Besonderheiten, die in dieser Arbeit
dargestellt wurden. Ihre Verwendung bot jedoch auch Vorteile, die sich nicht zuletzt in der
schnellen Konstruktion eines Systems, der einfachen Austauschbarkeit seiner Komponenten
und seiner Flexibilität erschöpfen. Diese Arbeit konnte auch die Wiederverwendbarkeit der
Forms und die einfache Implementation verschiedener Strategien aufzeigen. Mit Verwendung
und Weiterentwicklung des graphical ControlCenter können diese Vorteile konsequent
ausgebaut werden, um so in Zukunft die Implementation eines neuen Konversationssystems
noch weiter zu beschleunigen.
Das vorgestellte System ShopTel ist zwar immer noch ein Prototyp, jedoch konnte innerhalb
von fast acht Monaten ein komplettes System konzipiert und implementiert werden, dessen
Ergebnisse mehr als zufriedenstellend sind. Es konnten einige Verbesserungsmöglichkeiten
aufgezeigt werden und es bleibt zu hoffen, daß dieses sehr komplexe System weiterentwickelt
wird und so vielleicht seinen Beitrag zur Verbreitung von telefonischen Dialogsystemen leistet.
Die Voraussetzungen für die Weiterentwicklung des Systems sind mit dieser Arbeit
gelegt worden.
Wie bereits im vierten Kapitel gezeigt wurde, ist die Bandbreite von Dialogsystemen in der
Fachwelt sehr groß, allerdings werden solche Systeme bisher nur sehr selten in der Praxis
eingesetzt. Die Vorbehalte der Benutzer sind meist zu groß. Dabei wird die Leistungsfähigkeit
solcher Systeme häufig grundlegend falsch eingeschätzt. Diese Beobachtung konnte ich
auch bei der Sammlung der Evaluationsdaten machen: entweder wird einem System zu wenig
zugetraut und es werden nur Einzelworte geäußert oder der Umfang des Vokabulars
und die Leistungsfähigkeit der Dialogkomponente werden als unermeßlich angesehen und
es werden hochkomplizierte Satzkonstruktionen geäußert. Dies Problem ist durch bessere
Datensammlungen und Sprachmodelle, höhere verfügbare Rechenkapazitäten und bessere
sprechende“ Anleitungen, in denen formuliert wird, was das System kann, zu lösen. Ein
”
größeres Problem besteht in der Einstellung vieler Benutzer gegenüber Dialogsystemen im
allgemeinen. Häufig werden solche Systeme abgelehnt, da die Vorstellung der Kommunikation
mit einer Maschine vielen sehr suspekt ist, jeder Besitzer eines Anrufbeantworters weiß
dies nur zu gut. Eine Lösung dieses Problems kann nur in der langsamen Verbreitung der
Technik bestehen, während der die Benutzer zunehmend positive Erfahrungen im Umgang
mit Dialogsystemen sammeln.

78 KAPITEL 7. AUSBLICK
Doch bieten Dialogsysteme, vor allem die telefonischen Varianten, sehr viele Vorteile. Insbesondere
in einfachen Auskunftsdomänen bieten Dialogsysteme eine preiswerte und flexible
Alternative zu menschlichen Call-Centern. Bei ihrem Einsatz entfallen nicht nur Personalund
Schulungskosten für den Betreiber, vor allem die ständige Erreichbarkeit eines solchen
Services ist ein großer Vorteil. Außerdem können Kapazitätsgrenzen schnell erweitert werden,
die Zeit, die Anrufer in Warteschleifen verbringen müssen, kann somit einfach reduziert
und damit eine größere Zufriedenheit der Kunden erreicht werden. Da Betreiber von Call-
Centern häufig heute schon ihre Dienste auch über die Telefongebühren der Anrufer finanzieren,
können die Kosten für ein Dialogsystem bald amortisiert werden, weil die laufenden
Kosten für ein Dialogsystem sehr gering sind. Doch bietet sich auch eine Kombination von
Call-Center und Dialogsystem an, um so beispielsweise die Warteschlangen abzubauen oder
die Dienstzeiten zu verlängern und trotzdem in Bedarfsfällen menschliche Unterstützung zu
liefern. Insbesondere in den nächsten Jahren wird sich dieses Vorgehen durchsetzen. Dies
sieht auch [Steinbiss 2000], der argumentiert, daß die Sprachtechnologie nur wenige der
herkömmlichen Technologien ersetzen, mit den meisten aber koexistieren wird.
Die Zukunft von telefonischen Dialogsystemen wird trotz der formulierten Vorbehalte als
grundsätzlich positiv angesehen. Wichtig für eine steigende Akzeptanz und Nachfrage dieser
Systeme ist allerdings weniger ihre technische Machbarkeit, als die natürlichere Bedienbarkeit,
die einen enormen Vorteil gegenüber anderen Informationsquellen darstellen kann. So
kommt beispielsweise [Cameron 2000] zu dem Schluß, daß die einzige Motivation zur Verwendung
von telefonischen Dialogsystemen in Zukunft die Zeitersparnis ist. Nur wenn die
Nutzung eines sprachgesteuerten Systems einen schnelleren Erfolg verspricht, als die Verwendung
anderer Informationsquellen, wird es auch genutzt werden.
Ich denke, daß neben der Zeitersparnis die intuitive Benutzung von Dialogsystemen, insbesondere
im Telefoniebereich, eine wichtige Grundlage für den Erfolg dieser Systeme darstellen
wird. Einen wichtigen Beitrag dafür leistet auch die Strategie eines Dialogsystems, wie sie
in dieser Arbeit thematisiert wurde. Allerdings wird noch einige Forschungsarbeit geleistet
werden müssen, um die intuitive Benutzung wirklich jedem zu ermöglichen. Die Arbeit an
diesem Ziel wird auch in der nächsten Zeit vor allem durch große Forschungsvorhaben geleistet
werden, die sowohl von der öffentlichen Hand, als auch von der Industrie finanziert
werden. Mit dem EU-Projekt CATCH 2004 1 und dem BMBF-Projekt SmartKom 2 können hier
zwei große Vorhaben mit deutscher Beteiligung genannt werden.
Allerdings bin ich der Überzeugung, daß mit einer zunehmenden Verbesserung der Dialogsysteme,
deren Verbreitung größtenteils auf Grund ihres ernormen Rationalisierungspotentials
einsetzen wird und nicht, wegen der einfachen und intuitiven Benutzbarkeit.
1 Siehe unter www.catch2004.org.
2 Vergleiche hierzu www.smartkom.org.

Anhang A
IBM Tools für Telefoniesysteme
Das in dieser Arbeit vorgestellte System ShopTel wurde mit Hilfe der IBM-Tools für Telefoniesysteme
erstellt, die eine schnelle Konstruktion von telefonbasierten Dialogsystemen
ermöglichen. Im folgenden werden die beiden im Rahmen der Arbeit verwendeten Werkzeuge
kurz vorgestellt.
A.1 IBM ViaVoice Telephony Toolkit
Das IBM ViaVoice Telephony Toolkit (VVT) ist ein Entwicklungswerkzeug, das der Konstruktion
von einfachen, grammatikbasierten Dialogsystemen dient. Das Werkzeug verfügt
bereits über einen Spracherkenner und eine TTS, desweiteren ist ein Telefoniemodul enthalten,
das die Schnittstelle zwischen der Telefonkarte im Rechner und der eigentlichen
Anwendung darstellt. Die steuernden Komponenten des VVT sind der IVR-Hub (Interactive
Voice Response) und der Prozeßmanager. Letzterer dient vor allem der Nutzung mehrerer
(Telefon)Kanäle für verschiedene Anwendungen auf einem Rechner. Der IVR-Hub steht für
die eigentliche VVT-Anwendung und muß für jede Applikation neu erstellt werden. In der
Regel handelt es sich dabei um ein Skript das in Tcl implementiert wird und das mit einem
Backend interagiert. Für die Spracherkennung müssen eine Grammatik und die zu den jeweiligen
Worten korrespondierende Aussprache (Baseforms) erstellt werden. Die Architektur
des VVT ist auf Abbildung A.1 bestehend aus den dunkel eingefärbten Komponenten dargestellt.
Nähere Angaben zum VVT können [IBM 1999a; Günther et al. 2000] entnommen
werden.
A.2 IBM ViaVoice Telephony Natural Language Tools
Die IBM ViaVoice Telephony Natural Language Tools (NLU-Tools) stellen eine Erweiterung
des VVT dar, wie auch aus Abbildung A.1 ersehen werden kann. Die NLU-Tools
bestehen somit aus allen Komponenten, die auch das VVT aufweist. Zusätzlich wurden sie
jedoch um einen Dialogmanager erweitert. Anwendungen, die für diese Tools erstellt werden,
sind nicht grammatikbasiert, sondern werden mit Daten aus einer umfangreichen Treebank
gespeist. Ausführliche Angaben hierzu und zum Parsing-Prinzip der Tools wurden bereits
in Abschnitt 5.3.8 gemacht.

80 ANHANG A. IBM TOOLS FÜR TELEFONIESYSTEME
Abbildung A.1: Architektur des IBM ViaVoice Telephony Toolkit mit NLU-Tools
Die Konstruktion einer Anwendung mit den NLU-Tools bedeutet im Vergleich zur Erstellung
einer Applikation mit dem VVT einen größeren Aufwand. Der IVR-Hub und das NLU-
ControlCenter müssen jeder neuen Anwendung angepaßt werden. Desweiteren müssen die
Daten für den Classer und Parser gesammelt, annotiert und trainiert, sowie der Canonicalizer
konstruiert werden. Bisher wurden auch die Forms für jede Anwendung neu erstellt.
Mit der vorliegenden Arbeit wurde jedoch ein Beitrag geleistet, der die ganze oder teilweise
Wiederverwendung von Forms fördert und somit zu einer Beschleunigung des Konstruktionsprozesses
von zukünftigen Anwendungen führen kann. Für die Spracherkennung wird
aus den gewonnen Daten ein Sprachmodell berechnet, desweiteren werden ebenfalls die Baseforms
der jeweiligen Worte benötigt. Weitere Informationen über die NLU-Tools sind in
[Davies et al. 1999; IBM 1999b; Papineni et al. 1999; Mast et al. 2000] zu finden.

Anhang B
SHOPTEL
B.1 Beispieldialoge mit SHOPTEL
Im folgenden werden einige Beispieldialoge mit ShopTel wiedergegeben, um einen Eindruck
des Systems zu geben. Dargestellt werden die jeweiligen Transkriptionen des Anrufers (A:),
gekürzt um nicht relevante sprachliche Phänomene, und die Systemprompts von ShopTel
(S:).
B.1.1
Dialog I
Um Erkennungsfehler bereinigte Testbestellung bei ShopTel, dem Beispieldialog aus Abschnitt
5.5 folgend.
S: herzlich willkommen bei shoptel, dem automatischen bestellsystem der IBM. wenn sie
noch keine kundennummer haben, melden sie sich bitte mit mustermann und der
nummer 0 8 15 an, ansonsten nennen sie bitte ihren namen und ihre kundennummer,
bevor sie etwas bestellen.
A: hallo hier ist mustermann
S: bitte nennen sie ihre vierstellige kundennummer.
A: 0 8 15
S: hallo sie sind nun als neuer kunde erkannt worden und dürfen das system jetzt zu testzwecken
benutzen. ausgeführte bestellungen sind nicht reell, sie gehen mit benutzung
dieses systems keine verpflichtungen irgendeiner art ein. was möchten sie denn gerne
bestellen? sie haben die auswahl zwischen büchern, notebooks und weinen.
A: ein notebook zu 5 tausend euro bitte
S: ich habe 8 in frage kommende notebooks gefunden. um ihre auswahl einzuschränken, spezifizieren
sie ihre bestellung bitte weiter, indem sie zum beispiel eine produktnummer,
einen produktnamen, eine obere preisgrenze, einen prozessornamen oder ein betriebssystem
sagen, sie können auch ein notebook mit dvd oder cd-rom laufwerk auswählen.

82 ANHANG B. SHOPTEL
A: ich möchte eins mit dvd-laufwerk bitte
S: ich habe IBM-thinkpad-6005-ege und IBM-thinkpad-6009-ege gefunden, welches möchten
sie bestellen?
A: die daten bitte
S: die daten der ausgewählten notebooks: notebook 1: IBM-thinkpad-6005-ege für 9420 DM
hat einen pentium-3 mit 500 mhz, es hat 64 mb sd-ram und kann auf maximal 576
mb erweitert werden, die festplatte ist 12 gb gross, es hat ein dvd laufwerk und als
betriebssystem ist windows-98 vorinstalliert. notebook 2: IBM-thinkpad-6009-ege für
9686 DM hat einen pentium-3 mit 500 mhz, es hat 64 mb sd-ram und kann auf maximal
576 mb erweitert werden, die festplatte ist 12 gb gross, es hat ein dvd laufwerk und
als betriebssystem ist windows-nt vorinstalliert. alle notebooks sind in bewährter IBM
qualität hergestellt und haben ein 13,3 zoll display das maximal eine auflösung von
1024 mal 768 erlaubt. ich habe 2 notebooks gefunden, welches möchten sie bestellen?
A: ich nehme das billigste bitte
S: sie möchten also ein mal IBM-thinkpad-6005-ege zu je 9420 DM bestellen?
A: ja bitte
S: möchten sie ein mal IBM-thinkpad-6005-ege zu 9420 DM bestellen?
A: ja
S: produkt bestellung ok. möchten sie noch eine bestellung aufgeben oder lieber bezahlen?
A: zahlen bitte
S: die summe ihrer einkäufe beträgt: 9420 DM, nennen sie dafür bitte ihre gewünschte
zahlungsweise.
A: per kreditkarte bitte
S: was für eine kreditkarte haben sie bitte?
A: eine eurocard
S: bitte geben sie an, bis zu welchem monat in welchem jahr ihre kreditkarte noch gültig
ist.
A: bis märz 2002
S: bitte nennen sie ihre kreditkartennummer.
A: 1 2 3 4 5 6 7 8 9
S: ok, die bezahlungsmodalitäten sind hiermit abgeschlossen, damit ist der testdurchlauf
von shoptel nun beendet. hoffentlich hat es ihnen gefallen.
A: auf wiederhören
S: vielen dank, daß sie shoptel benutzt haben. bis zum nächsten mal! auf wiederhören. bitte
legen sie jetzt auf! bitte legen sie jetzt auf, das telefonat ist beendet. sie können das
telefonat nun beenden indem sie ende sagen oder einfach auflegen.

B.1. BEISPIELDIALOGE MIT SHOPTEL 83
B.1.2
Dialog II
Erfolgreicher Dialog mit Erkennungsfehlern und Slotfehler (obere Zahlungsgrenze als Stückzahl
interpretiert) eines bekannten Kunden.
S: herzlich willkommen bei shoptel, dem automatischen bestellsystem der IBM. wenn sie
noch keine kundennummer haben, melden sie sich bitte mit mustermann und der
nummer 0 8 15 an, ansonsten nennen sie bitte ihren namen und ihre kundennummer,
bevor sie etwas bestellen.
A: markus klehr
S: bitte nennen sie ihre vierstellige kundennummer.
A: 6 3 6 3
S: hallo markus klehr, sie sind als registrierter kunde erkannt worden. was möchten sie bitte
bestellen?
A: ich wuerde gerne ’n notebook auch mit dvd-laufwerk fuer so 2 äh 5 tausend euro [bestellen]
S: es wurde kein passendes produkt gefunden, bitte geben sie eine neue bestellung auf!
A: ja notebooks mit dvd-laufwerk [will] ich
S: ich habe IBM-thinkpad-6005-ege, IBM-thinkpad-6005-fge, IBM-thinkpad-6009-ege, IBMthinkpad-6005-bge
und IBM-thinkpad-6005-age gefunden, welches möchten sie bestellen?
A: was kostet das 1.
S: sie möchten also 25000 mal IBM-thinkpad-6005-ege bestellen?
A: ja
S: möchten sie 25000 mal IBM-thinkpad-6005-ege zu 235500000 DM bestellen?
A: ja
S: produkt bestellung ok. möchten sie noch eine bestellung aufgeben oder lieber bezahlen?
A: ich moechte bezahlen
S: die summe ihrer einkäufe beträgt: 235500000 DM, nennen sie dafür bitte ihre gewünschte
zahlungsweise.
A: ich zahle mit kreditkarte
S: was für eine kreditkarte haben sie bitte?
A: visa card
[akustische Bewertung zu schlecht]
S: entschuldigung ich habe sie nicht verstanden.

84 ANHANG B. SHOPTEL
A: visa card
[nicht als Kreditkarte verstanden]
S: was für eine kreditkarte haben sie denn?
A: american express
[nicht als Kreditkarte verstanden]
S: was für eine kreditkarte haben sie denn?
A: eurocard
S: bitte geben sie an, bis zu welchem monat in welchem jahr ihre kreditkarte noch gültig
ist.
A: oktober 2 tausend
S: bitte nennen sie ihre kreditkarten nummer.
A: 4 4 4 3 8 9 9
S: ok, die bezahlungsmodalitäten sind hiermit abgeschlossen. bitte geben sie nun noch die
lieferadresse an.
A: friedrich schiller strasse 4 in 6 7 4 5 4 nussloch
[nicht korrekt verstanden, da nicht im Vokabular vorgesehen]
S: in welcher strasse wohnen sie bitte?
A: friedrich schiller strasse
[nicht korrekt verstanden, da nicht im Vokabular]
S: ich habe sie nicht verstanden bitte sprechen sie deutlicher.
A: vangerowstrasse 18
S: nennen sie bitte den namen ihres wohnortes.
A: heidelberg
S: schönen dank, mehr angaben brauche ich nicht mehr. auf wiederhören.
A: [auflegen]
B.1.3
Dialog III
Gescheiterte Bestellung eines Testbenutzers mit einigen Fehlern.
S: herzlich willkommen bei shoptel, dem automatischen bestellsystem der IBM. wenn sie
noch keine kundennummer haben, melden sie sich bitte mit mustermann und der
nummer 0 8 15 an, ansonsten nennen sie bitte ihren namen und ihre kundennummer,
bevor sie etwas bestellen.
A: guten tag mein name ist mustermann ich habe die kundennummer 0 8 1 5

B.1. BEISPIELDIALOGE MIT SHOPTEL 85
S: hallo sie sind nun als neuer kunde erkannt worden und dürfen das system jetzt zu testzwecken
benutzen. ausgeführte bestellungen sind nicht reell, sie gehen mit benutzung
dieses systems keine verpflichtungen irgendeiner art ein. was möchten sie denn gerne
bestellen? sie haben die auswahl zwischen büchern, notebooks und weinen.
A: ich haette gerne ein paar weine bestellt
S: ich habe 20 in frage kommende weine gefunden. um ihre auswahl einzuschränken, spezifizieren
sie ihre bestellung bitte weiter, sie können dafür einen produktnamen, eine
preisgrenze, eine traubensorte, geschmacksrichtung, farbe, ein anbaugebiet oder ein
herkunftsland nennen.
A: ich haette gerne einen roten bordeaux
S: es wurde kein passendes produkt gefunden, bitte geben sie eine neue bestellung auf!
A: ich haette gerne eine palette rotwein
[richtige Verarbeitung obwohl Wort ’Palette’ nicht im Vokabular]
S: ich habe 6 in frage kommende weine gefunden. um ihre auswahl einzuschränken, spezifizieren
sie ihre bestellung bitte weiter, sie können dafür einen produktnamen, eine
preisgrenze, eine traubensorte, geschmacksrichtung, farbe, ein anbaugebiet oder ein
herkunftsland nennen.
A: ich haette gerne einen wein fuer 9 demark
S: ich habe deidesheimer klostergarten und wallertheimer vogelsang kabinett gefunden, welches
möchten sie bestellen?
A: ich moechte gerne einen anderen wein bestellen
[Satz ist nicht in Treebank enthalten, daher falsche Verarbeitung]
S: ich habe deidesheimer klostergarten und wallertheimer vogelsang kabinett gefunden, welches
möchten sie bestellen?
A: keinen der weine moechte ich bestellen
S: ich habe 20 in frage kommende weine gefunden. um ihre auswahl einzuschränken, spezifizieren
sie ihre bestellung bitte weiter, sie können dafür einen produktnamen, eine
preisgrenze, eine traubensorte, geschmacksrichtung, farbe, ein anbaugebiet oder ein
herkunftsland nennen.
A: ich haette gerne einen wein aus frankreich
S: ich habe beaujolais und chateauneuf du pape gefunden, welches möchten sie bestellen?
[frz. Weine wegen deutscher TTS sehr schlecht verständlich]
A: bitte wiederholen sie
S: ich habe beaujolais und chateauneuf du pape gefunden, welches möchten sie bestellen?
A: den beaujolais
[akustische Bewertung von ASR zu schlecht]
S: entschuldigung ich habe sie nicht verstanden.

86 ANHANG B. SHOPTEL
A: hilfe
[als ’11’ verstanden]
S: tut mir leid, ich kann sie nicht verstehen, bitte formulieren sie ihre anfrage um.
A: bitte geben sie mir ihre hilfedatei
[Satz nicht von Classer verarbeitet]
S: was möchten sie gerne tun?
A: ich moechte gerne mit der hilfe sprechen
[Satz falsch geclasst]
S: was möchten sie gerne tun?
A: einen franzoesischen rotwein bestellen
S: ich habe 6 in frage kommende weine gefunden. um ihre auswahl einzuschränken, spezifizieren
sie ihre bestellung bitte weiter, sie können dafür einen produktnamen, eine
preisgrenze, eine traubensorte, geschmacksrichtung, farbe, ein anbaugebiet oder ein
herkunftsland nennen.
A: lesen sie mir bitte alles vor
[Satz nicht in Treebank enthalten, wird als ’NULL’ verarbeitet]
S: ich habe 6 in frage kommende weine gefunden. um ihre auswahl einzuschränken, spezifizieren
sie ihre bestellung bitte weiter, sie können dafür einen produktnamen, eine
preisgrenze, eine traubensorte, geschmacksrichtung, farbe, ein anbaugebiet oder ein
herkunftsland nennen.
A: ich moechte nichts mehr bestellen vielen dank
S: vielen dank, daß sie shoptel benutzt haben. bis zum nächsten mal! auf wiederhören. bitte
legen sie jetzt auf! bitte legen sie jetzt auf, das telefonat ist beendet.
A: [auflegen]

B.2. VERGEBENE TAGS UND LABELS IN SHOPTEL 87
B.2 Vergebene Tags und Labels in SHOPTEL
Dieser Abschnitt wurde als IBM Vertraulich klassifiziert
und darf daher nicht veröffentlicht werden.
B.3 Performanzevaluation
Dieser Abschnitt wurde als IBM Vertraulich klassifiziert
und darf daher nicht veröffentlicht werden.

88 ANHANG B. SHOPTEL
B.4 Fragebogen zur Evaluation von SHOPTEL
Abbildung B.1: Fragebogen zur Evaluation von ShopTel (erste Seite)

B.4. FRAGEBOGEN ZUR EVALUATION VON SHOPTEL 89
Abbildung B.2: Fragebogen zur Evaluation von ShopTel (zweite Seite)

90 ANHANG B. SHOPTEL
B.5 Auswertung des Fragebogens
Dieser Abschnitt wurde als IBM Vertraulich klassifiziert
und darf daher nicht veröffentlicht werden.

Literaturverzeichnis
[Albesano et al. 1996] Albesano, A.; Baggia, P.; Danieli, M.; Gemello, R.; Gerbino, E. und
Rullent, C. Dialogos: A Robust System for Human-Machine Spoken Dialogue on the
Telephone. cmp-lg/9612004, 1996.
[Alexandersson et al. 1995] Alexandersson, J.; Maier, E. und Reithinger, N. A Robust and
Efficient Three-Layered Dialogue Component for a Speech-To-Speech Translation System.
In: Proceedings of the Conference of the European chapter of the Association for Computational
Linguistics (EACL), Dublin, Irland, 1995, S. 188-193.
[Alexandersson et al. 1997] Alexandersson, J.; Buschbeck-Wolf, B.; Fujinami, T.; Maier, E.;
Reihtinger, N.; Schmitz, B. und Siegel, M. Dialogue Acts in Verbmobil-2. Verbmobil
Report 204, DFKI GmbH, Saarbrücken, 1997.
[Alexandersson et al. 1998] Alexandersson, J.; Buschbeck-Wolf, B.; Fujinami, T.; Kipp, M.;
Koch, S.; Maier, E.; Reithinger, N.; Schmitz, B. und Siegel, M. Dialogue Acts in Verbmobil-
2 – Second Edition. Verbmobil Report 226, DFKI GmbH, Saarbrücken, 1998.
[Allen et al. 1982] Allen, J. F.; Frische, A. M. und Litman, D. J. ARGOT: The Rochester
Dialog System. In: Proceedings of the Annual Meeting of the American Association of
Artificial Intelligence (AAAI), Pittsburgh, USA, 1982, S. 66-70.
[Allen et al. 1994] Allen, J. F.; Schubert, L. K.; Ferguson, G.; Heeman, P.; Hwang, C. H.;
Kato, T.; Light, M.; Martin, N. G.; Miller, B. W.; Pocsio, M. und Traum, D. R. The
TRAINS Project: A Case Study in Building a Conversational Planning Agent. Trains
Technical Note 94-3, Department of Computer Science, University of Rochester, Rochester,
USA, 1994.
[Allen 1995] Allen, J. F. Natural Language Understanding. Benjamin Cummings, Redwood
City, USA, 1995.
[Allen et al. 1996] Allen, J. F.; Miller, B. W.; Ringger, E. K. und Sikorski, T. Robust Understanding
in a Dialogue System. In: Proceedings of the Annual Meeting of the Association
for Computational Linguistics (ACL), Santa Cruz, USA, 1996.
[Amtrup et al. 1996] Amtrup, J. W.; Heine, H. und Jost, U. What’s in a Word Graph
– Evaluation and Enhancement of Word Lattices. Verbmobil Report 186, Fachbereich
Informatik, Universität Hamburg, Hamburg, 1996.
[Araki und Doshita 1997] Araki, M. und Doshita, S. Automatic Evaluation Environment for
Spoken Dialogue Systems. In: E. Maier, M. Mast und S. LuperFoy (Hrsg.): Dialogue Processing
in Spoken Language Systems, Bd. 1236 der Lecture Notes in Artificial Intelligence,
Springer Verlag, Berlin, 1997, S. 183-194.

92 LITERATURVERZEICHNIS
[Aust und Schröer 1998a] Aust, H. und Schröer, O. Application Development with the Philips
Dialog System. In: Proceedings of the International Symposium on Spoken Dialogue,
Sydney, Australien, 1998, S. 27-34.
[Aust und Schröer 1998b] Aust, H. und Schröer, O. An Overview of the Philips Dialog
System. Technical Report, Philips Speech Processing, Aachen, 1998.
[Averbuch et al. 1986] Averbuch, A.; Bahl, L.; Bakis, R.; Brown, P.; Cole, A.; Daggett, G.;
Das, S.; Davies, K.; DeGennaro, S.; de Souza, P.; Epstein, E.; Fraleigh, D.; Jelinek, F.;
Katz, S.; Lewis, B.; Mercer, R.; Nadas, A.; Nahamoo, D.; Picheny, M.; Shichman, G.
und Spinelli, P. An IBM PC based Lage-Vocabulary Isolated-Utterance Speech Recognizer.
Research Report RC 11663 (52371), IBM Thomas J. Watson Research Center, Yorktown
Heights, USA, 1986.
[Bahl et al. 1993] Bahl, L.; de Souza, P.; Gopalakrishnan, P.; Nahamoo, D. und Picheny,
M. Context-Dependent Vector Quantization for Continuous Speech Recognition. In: Proceedings
of the International Conference on Accoustics, Speech, and Signal Processing
(ICASSP), Minneapolis, USA, 1993.
[Boros et al. 1997] Boros, M.; Aretoulaki, M.; Gallwitz, F.; Nöth, E. und Niemann, H. Semantic
Processing of Out-of-Vocabulary Words in a Spoken Dialogue System. In: Proceedings
of the European Conference on Speech Communication and Technology (EURO-
SPEECH), Rhodos, Griechenland, 1997.
[Bunt 1981] Bunt, H. C. Rules for the Interpretation, Evaluation and Generation of Dialogue
Acts. In: IPO Annual Progress Report 16, Tilburg University, Tilburg, Niederlande, 1981,
S. 99-107.
[Bunt 1989] Bunt, H. C. Information Dialogues as Communicative Action in Relation to
Partner Modelling and Information Processing. In: M. M. Taylor, F. Néel und D. G.
Bouwhuis (Hrsg.): The Structure of Multimodal Dialogue, North-Holland, Amsterdam,
Niederlande, 1989, S. 47-73.
[Busemann 1995] Busemann, S. (Hrsg.). Sprachverarbeitung. In: G. Görz (Hrsg.):
Einführung in die Künstliche Intelligenz, Addison-Wesley, Bonn, 1995, S. 361-557.
[Cameron 2000] Cameron, H. Speech at the Interface. In: Proceedings of the International
Workshop ‘Voice Operated Telecom Services’, Gent, Belgien, 2000, S. 1-7.
[Constantinides et al. 1998] Constantinides, P. C.; Hansma, S.; Tchou, C. und Rudnicky,
A. I. A Schema based Approach to Dialog Control. In: Proceedings of the International
Conference on Spoken Language Processing (ICSLP), Philadelphia, USA, 1998.
[Crestani 1998] Crestani, F. Vocal Access to a Newspaper Archive: Design Issues and Preliminary
Investigation. cs.DL/9812009, 1998.
[Dallmer 1993] Dallmer, H. Direct Marketing. In: Gabler-Wirtschafts-Lexikon, Gabler Verlag,
Wiesbaden, 1993.
[Davies et al. 1999] Davies, K.; Donovan, R.; Epstein, M.; Franz, M.; Ittycheriah, A.; Jan,
E. E.; LeRoux, J. M.; Lubensky, D.; Neti, C.; Padmanabhan, M.; Papineni, K.; Roukos, S.;
Sakrajda, A.; Sorensen, J.; Tydlitat, B. und Ward, T. The IBM Conversational Telephony
System for Financial Applications. In: Proceedings of the European Conference on Speech
Communciation and Technology (EUROSPEECH), Budapest, Ungarn, 1999.

LITERATURVERZEICHNIS 93
[Denecke und Waibel 1997] Denecke, M. und Waibel, A. Dialogue Strategies Guiding Users
to their Communicative Goals. In: Proceedings of the European Conference on Speech
Communication and Technology (EUROSPEECH), Rhodos, Griechenland, 1997.
[Drosdowski 1990] Drosdowski, G. (Hrsg.). Duden – Fremdwörterbuch. Dudenverlag, Mannheim,
1990.
[Eckert et al. 1995] Eckert, W.; Nöth, E.; Niemann, H. und Schukat-Talamazzini, E.-G. Real
Users behave Weird – Experience made collecting large Human-Machine-Dialog Corpora.
In: Proceedings of the Tutorial and Research Workshop on Spoken Dialogue Systems,
Vigsø, Dänemark, 1995, S. 193-196.
[Ehrlich et al. 1992] Ehrlich, U.; Mast, M. und Niemann, H. Bedeutungsanalyse und Interpretation
von Äußerungen relativ zu einem Dialogmodell im Spracherkennungs- und Dialogsystem
EVAR. In: H. Mangold (Hrsg.): Sprachliche Mensch-Maschine-Kommunikation,
Oldenbourg Verlag, München, 1992, S. 117-130.
[Fischer 1999] Fischer, K. Annotating Emotional Language Data. Verbmobil Report 236,
Fachbereich Informatik, Universität Hamburg, Hamburg, 1999.
[Foth et al. 2000a] Foth, K.; Schröder, I. und Menzel, W. A Transformation-based Parsing
Technique With Anytime Properties. In: Proceedings of the International Workshop on
Parsing Technologies, Trient, Italien, 2000, S. 89-100.
[Foth et al. 2000b] Foth, K.; Menzel, W.; Pop, H. F. und Schröder, I. An Experiment on Incremental
Analysis Using Robust Parsing Techniques. In: Proceedings of the International
Conference on Computational Linguistics (COLING), Saarbrücken, 2000, S. 1026-1030.
[Gallwitz et al. 1998] Gallwitz, F.; Aretoulaki, M.; Boros, M.; Haas, J.; Harbeck, S.; Huber,
R.; Niemann, H. und Nöth, E. The Erlangen Spoken Dialogue System EVAR: A State-ofthe-Art
Information Retrieval System. In: Proceedings of the International Symposium
on Spoken Dialogue, Sydney, Australien, 1998, S. 19-26.
[Gates et al. 1997] Gates, D.; Lavie, A.; Levin, L.; Waibel, A.; Gavaldá, M.; Mayfield, L.;
Woszcyna, M. und Zhan, P. End-to-End Evaluation in JANUS: A Speech-to-Speech Translation
System. In: E. Maier, M. Mast und S. LuperFoy (Hrsg.): Dialogue Processing in
Spoken Language Systems, Bd. 1236 der Lecture Notes in Artificial Intelligence, Springer
Verlag, Berlin, 1997, S. 195-206.
[Glass und Hazen 1998] Glass, J. und Hazen, T. J. Telephone-Based Conversational Speech
Recognition in the Jupiter Domain. In: Proceedings of the International Conference on
Spoken Language Processing (ICSLP), Sydney, Australien, 1998.
[Glass et al. 1999] Glass, J. R.; Hazen, T. J. und Hetherington, I. L. Real-Time Telephone-
Based Speech Recognition in the JUPITER Domain. In: Proceedings of the International
Conference on Accoustics, Speech, and Signal Processing (ICASSP), Phoenix, USA, 1999.
[Grävemeyer 1998] Grävemeyer, A. Spracherkennung und Bildtelefon an jeder Straßenecke.
Computer Zeitung, Nr. 18, 1998, S. 18.
[Grävemeyer 1999a] Grävemeyer, A. Telefonauskunft hört auf jeden Anrufer. Computer
Zeitung, Nr. 15, 1999, S. 20.
[Grävemeyer 1999b] Grävemeyer, A. Software hört Ärzten und Ratsuchenden zu. Computer
Zeitung, Nr. 43, 1999, S. 14.

94 LITERATURVERZEICHNIS
[Günther et al. 2000] Günther, C.; Hamerich, S. W.; Kunzmann, S. und Roß, T. ISA: A
Traffic Jam Information System based on the IBM ViaVoice Telephony Toolkit. In: Proceedings
of the International Workshop ‘Voice Operated Telecom Services’, Gent, Belgien,
2000, S. 63-66.
[von Hahn und Amtrup 1996] von Hahn, W. und Amtrup, J. W. Speech-to-Speech Translation:
The Project Verbmobil. In: Proceedings of the International Workshop ‘Speech and
Computer’, St. Petersburg, Rußland, 1996.
[Hamerich 1999] Hamerich, S. W. Menübasierte Generierung natürlicher Sprache. Studienarbeit,
Fachbereich Informatik, Universität Hamburg, Hamburg, 1999.
[Heeman und Allen 1994] Heeman, P. und Allen, J. F. Detecting and Correcting Speech
Repairs. In: Proceedings of the Annual Meeting of the Association for Computational
Linguistics (ACL), Las Cruces, USA, 1994, S. 295-302.
[IBM 1999a] IBM Corp. (Hrsg.). IBM ViaVoice Telephony Tools – Programmer’s Reference.
Yorktown Heights, USA, 1999.
[IBM 1999b] IBM Corp. (Hrsg.). IBM ViaVoice Telephony Natural Language Tools – Developer’s
Guide and Reference. Yorktown Heights, USA, 1999.
[Jekat-Rommel 1994] Jekat-Rommel, S. J. Zur Struktur gedolmetschter VM-Dialoge. Verbmobil
Memo 11, Fachbereich Informatik, Universität Hamburg, Hamburg, 1994.
[Jekat et al. 1995] Jekat, S. J.; Klein, A.; Maier, E.; Maleck, I.; Mast, M. und Quantz, J. J.
Dialogue Acts in Verbmobil. Verbmobil Report 65, Fachbereich Informatik, Universität
Hamburg, Hamburg, 1995.
[Jekat et al. 1997] Jekat, S. J.; Tappe, H.; Gerlach, H. und Schöllhammer, T. Dialogue Interpreting:
Data and Analysis. Verbmobil Report 189, Fachbereich Informatik, Universität
Hamburg, Hamburg, 1997.
[Jekat und von Hahn 2000] Jekat, S. J. und von Hahn, W. Multilingual Verbmobil-Dialogs:
Experiments, Data Collection and Data Analysis. In: W. Wahlster (Hrsg.): Verbmobil:
Foundations of Speech-to-Speech Translation, Springer Verlag, Berlin, 2000, S. 577-585.
[Jelinek et al. 1994] Jelinek, F.; Lafferty, J.; Magerman, D. M.; Mercer, R.; Ratnaparkhi, A.
und Roukos, S. Decision Tree Parsing using a Hidden Derivation Model. In: Proceedings
of the Human Language Technology Workshop, Princeton, USA, 1994, S. 272-277.
[Kamm et al. 1999] Kamm, C.; Walker, M. A. und Litman, D. Evaluating Spoken Language
Systems. In: Proceedings of the Conference of the American Voice Input/Output Society
(AVIOS), San Jose, USA, 1999.
[Karger und Wahlster 2000] Karger, R. und Wahlster, W. Facts and Figures about the Verbmobil
Project. In: W. Wahlster (Hrsg.): Verbmobil: Foundations of Speech-to-Speech Translation,
Springer Verlag, Berlin, 2000, S. 22-30.
[Komatani und Kawahara 2000] Komatani, K. und Kawahara, T. Flexible Mixed-Initiative
Dialogue Management using Concept-Level Confidence Measures of Speech Recognizer
Output. In: Proceedings of the International Conference on Computational Linguistics
(COLING), Saarbrücken, 2000, S. 467-473.

LITERATURVERZEICHNIS 95
[Krause 1997] Krause, D. Using an Interpretation System – Some Observations in Hidden
Operator Simulations of Verbmobil. In: E. Maier, M. Mast und S. LuperFoy (Hrsg.):
Dialogue Processing in Spoken Language Systems, Bd. 1236 der Lecture Notes in Artificial
Intelligence, Springer Verlag, Berlin, 1997, S. 41-54.
[Lavie et al. 1997] Lavie, A.; Gates, D.; Coccaro, N. und Levin, L. Input Segmentation of
Spontaneous Speech in JANUS: A Speech-to-Speech Translation System. In: E. Maier, M.
Mast und S. LuperFoy (Hrsg.): Dialogue Processing in Spoken Language Systems, Bd. 1236
der Lecture Notes in Artificial Intelligence, Springer Verlag, Berlin, 1997, S. 86-99.
[Lewandowski 1979] Lewandowski, T. Linguistisches Wörterbuch. Nr. 200 in Uni-
Taschenbücher (UTB). Quelle und Meyer, Heidelberg, 1979.
[Linke et al. 1994] Linke, A.; Nussbaumer, M. und Portmann, P. R. Studienbuch Linguistik.
Nr. 121 in Reihe Germanistische Linguistik. Max Niemeyer Verlag, Tübingen, 1994.
[Litman et al. 1998] Litman, D. J.; Pan, S. und Walker, M. A. Evaluating Response Strategies
in a Web-Based Spoken Dialogue Agent. In: Proceedings of the Annual Meeting of
the Association for Computational Linguistics (ACL) and the International Conference
on Computational Linguistics (COLING), Montréal, Kanada, 1998, S. 780-786.
[Litman und Shimei 1999] Litman, D. J. und Shimei, P. Empirically Evaluating an Adaptable
Spoken Dialogue System. cs.CL/9903008, 1999.
[Litman et al. 2000] Litman, D. J.; Kearns, M. S.; Singh, S. und Walker, M. A. Automatic
Optimization of Dialogue Management. In: Proceedings of the International Conference
on Computational Linguistics (COLING), Saarbrücken, 2000, S. 502-508.
[Magerman 1994] Magerman, D. M. Parsing as Statistical Pattern Recognition. Research
Report RC 19443 (84518), IBM T. J. Watson Research Center, Yorktown Heights, USA,
1994.
[Magerman 1995] Magerman, D. M. Statistical Decision-Tree Models for Parsing. cmplg/9504030,
1995.
[Mast 1993] Mast, M. Ein Dialogmodul für ein Spracherkennungs- und Dialogsystem. Dissertation,
Lehrstuhl für Mustererkennung, Universität Erlangen-Nürnberg, Erlangen, 1993.
[Mast et al. 1996] Mast, M.; Kompe, R.; Harbeck, S.; Kießling, A.; Niemann, H.; Nöth, E.;
Schukat-Talamazzini, E. G. und Warnke, V. Dialog Act Classification with the Help of
Prosody. In: Proceedings of the International Conference on Spoken Language Processing
(ICSLP), Philadelphia, USA, 1996.
[Mast et al. 2000] Mast, M.; Günther, C.; Kunzmann, S. und Roß, T. Multimodal Output
for a Conversational Telephony System. In: Proceedings of the International Conference
on Multimedia and Expo, New York, USA, 2000.
[McGlashan 1994] McGlashan, S. The Sundial Spoken Dialogue Systems. Auf:
http://www.sics.se/ scott/sundial/sundialOverview/, 1994.
[Menzel 1998] Menzel, W. Constraint Satisfaction for Robust Parsing of Spoken Language.
Journal of Experimental & Theoretical Artificial Intelligence, Bd. 3, Nr. 4, 1998, S. 77-89.

96 LITERATURVERZEICHNIS
[Menzel und Schröder 1998] Menzel, W. und Schröder, I. Constraint-based Diagnosis for
Intelligent Language Tutoring Systems. Bericht des Fachbereichs Informatik FBI-HH-B
208/98, Fachbereich Informatik, Universität Hamburg, Hamburg, 1998.
[Möller 1999] Möller, J.-U. Dia-MoLE: Modellierung gesprochen-sprachlicher Dialoge unter
Zuhilfenahme eines maschinellen Lernverfahrens. Dissertation, Fachbereich Informatik,
Universität Hamburg, Hamburg, 1999.
[Müller 1994] Müller, W. Ein kundenorientiertes Konzept zur Messung von
Telefonmarketing-Aktionen im Allfinanzbereich, Bd. 29 der Beiträge zu wirtschaftswissenschaftlichen
Problemen der Versicherung. Verlag Versicherungswirtschaft,
Karlsruhe, 1994.
[Ney 1982] Ney, H. Untersuchungen zur automatischen Erkennung kooperativer Sprecher
über Telefon. Dissertation, Fakultät für Maschinenbau und Eletktrotechnik, Technische
Universität Braunschweig, Braunschweig, 1982.
[Ney et al. 1992] Ney, H.; Steinbiss, V. und Paeseler, A. A Research Prototype System for
Large-Vocabulary Continuous-Speech Recognition. In: H. Mangold (Hrsg.): Sprachliche
Mensch-Maschine-Kommunikation, Oldenbourg Verlag, München, 1992, S. 79-90.
[Niedermair 1987] Niedermair, G. T. Syntactic Analysis in Speech Understanding. In: Proceedings
of the European Conference on Speech Technology (EUROSPEECH), Edinburgh,
Großbritanien, 1987.
[Niedermair 1992] Niedermair, G. T. Syntax, Semantik und Dialog in Spicos II. In:
H. Mangold (Hrsg.): Sprachliche Mensch-Maschine-Kommunikation, Oldenbourg Verlag,
München, 1992, S. 91-102.
[Papineni et al. 1999] Papineni, K. A.; Roukos, S. und Ward, R. T. Free-Flow Dialog Management
using Forms. In: Proceedings of the European Conference on Speech Communication
and Technology (EUROSPEECH), Budapest, Ungarn, 1999.
[Peckham 1993] Peckham, J. A new Generation of Spoken Dialogue Systems: Results and
Lessons from the SUNDIAL Project. In: Proceedings of the European Conference on
Speech Communication and Technology (EUROSPEECH), Berlin, 1993, S. 33-40.
[Plog 1996] Plog, K. Telefonmarketing – Ziele und Methoden aus linguistischer Perspektive.
Westdeutscher Verlag, Opladen, 1996.
[Polifroni et al. 1998] Polifroni, J.; Seneff, S.; Glass, J. und Hazen, T. J. Evaluation Methodology
for a Telephone-Based Conversational System. In: Proceedings of the International
Conference on Language Resources and Evaluation, Granada, Spanien, 1998, S. 42-50.
[Ratnaparkhi et al. 1996] Ratnaparkhi, A.; Roukos, S. und Ward, R. T. A Maximum Entropy
Model for Parsing. In: Proceedings of the International Conference on Spoken Language
Processing (ICSLP), Philadelphia, USA, 1996.
[Rudnicky et al. 1999] Rudnicky, A. I.; Thayer, E.; Constantinides, P.; Tchou, C.; Shern, R.;
Lenzo, K.; Xu, W. und Oh, A. Creating Natural Dialogs in the Carnegie Mellon Communicator
System. In: Proceedings of the European Conference on Speech Communication
and Technology (EUROSPEECH), Budapest, Ungarn, 1999, S. 1531-1534.

LITERATURVERZEICHNIS 97
[Schmitz 1997] Schmitz, B. Collaboration in Automatic Dialogue Interpreting. In: Proceedings
of the International Joint Conference on Artificial Intelligence (IJCAI), Nagoya,
Japan, 1997, S. 79-88.
[Schneider 1993] Schneider, D. J. G. Marketing. In: Gabler-Wirtschafts-Lexikon, Gabler
Verlag, Wiesbaden, 1993.
[Seneff et al. 1998] Seneff, S.; Hurley, E.; Lau, R.; Pao, C.; Schmid, P. und Zue, V. Galaxy-II:
A reference Architecture for Conversational System Development. In: Proceedings of the
International Conference on Spoken Language Processing (ICSLP), Syndey, Australien,
1998.
[Sikorski und Allen 1997] Sikorski, T. und Allen, J. F. A Task-Based Evaluation of the
TRAINS-95 Dialogue System. In: E. Maier, M. Mast und S. LuperFoy (Hrsg.): Dialogue
Processing in Spoken Language Systems, Bd. 1236 der Lecture Notes in Artificial Intelligence,
Springer Verlag, Berlin, 1997, S. 207-220.
[Smith und Hipp 1994] Smith, R. W. und Hipp, D. R. Spoken Natural Language Dialog
Systems: A Practical Approach. Oxford University Press, New York, USA, 1994.
[Steinbiss 2000] Steinbiss, V. Speech Dialogue Systems in the Telecom Network. In: Proceedings
of the International Workshop ‘Voice Operated Telecom Services’, Gent, Belgien,
2000, S. 25-28.
[Tessiore und von Hahn 2000] Tessiore, L. und von Hahn, W. Functional Validation of a
Machine Interpretation System: Verbmobil. In: W. Wahlster (Hrsg.): Verbmobil: Foundations
of Speech-to-Speech Translation, Springer Verlag, Berlin, 2000, S. 613-637.
[Vary et al. 1998] Vary, P.; Heute, U. und Hess, W. Digitale Sprachsignalverarbeitung. Teubner
Verlag, Stuttgart, 1998.
[Vuerinckx und Vanpoucke 2000] Vuerinckx, R. und Vanpoucke, F. Evaluation of the Robustness
of ASR Systems on Cellular Phone Speech. In: Proceedings of the International
Workshop ‘Voice Operated Telecom Services’, Gent, Belgien, 2000, S. 91-94.
[Wahlster 1993a] Wahlster, W. Verbmobil – Translation of Face-To-Face Dialogues. In:
Proceedings of the Machine Translation Summit, Kobe, Japan, 1993, S. 127-135.
[Wahlster 1993b] Wahlster, W. Verbmobil: Translation of Face-To-Face Dialogs. In: Proceedings
of the European Conference on Speech Communication and Technology (EURO-
SPEECH), Berlin, 1993, S. 29-38.
[Wahlster 1997] Wahlster, W. Verbmobil – Erkennung, Analyse, Transfer, Generierung und
Synthese von Spontansprache. Verbmobil Report 198, DFKI GmbH, Saarbrücken, 1997.
[Wahlster 2000] Wahlster, W. Mobile Speech-to-Speech Translation of Spontaneous Dialogs:
An Overview of the Final Verbmobil System. In: W. Wahlster (Hrsg.): Verbmobil: Foundations
of Speech-to-Speech Translation, Springer Verlag, Berlin, 2000, S. 3-21.
[Waibel 1996] Waibel, A. Interactive Translation of conversational Speech. Computer,
Bd. 29, Nr. 7, 1996.
[Walker et al. 1997] Walker, M. A.; Hindle, D.; Fromer, J.; Fabrizzio, G. D. und Mestel,
C. Evaluating Competing Agent Strategies for a Voice Email Agent. In: Proceedings of
the European Conference on Speech Communication and Technology (EUROSPEECH),
Rhodos, Griechenland, 1997.

98 LITERATURVERZEICHNIS
[Walker et al. 1998a] Walker, M. A.; Fromer, J. und Narayanan, S. Learning Optimal Dialogue
Strategies: A Case Study of a Spoken Dialogue Agent for Email. In: Proceedings
of the Annual Meeting of the Association for Computational Linguistics (ACL) and the
International Conference on Computational Linguistics (COLING), Montréal, Kanada,
1998.
[Walker et al. 1998b] Walker, M. A.; Litman, D. J.; Kamm, C. A. und Abella, A. Evaluating
Spoken Dialogue Agents with PARADISE: Two Case Studies. Computer Speech and
Language, Bd. 12, Nr. 3, 1998.
[Warnke et al. 1997] Warnke, V.; Kompe, R.; Nieman, H. und Nöth, E. Integrated Dialog Act
Segmentation and Classification usig Prosodic Features and Language Models. Verbmobil
Report 218, Lehrstuhl für Mustererkennung, Universität Erlangen-Nürnberg, Erlangen,
1997.
[Weber 1984] Weber, M. R. Telefonmarketing – Das Telefon im Dienste des Unternehmens
und seiner Kunden. Verlag Moderne Industrie, Landsberg am Lech, 1984.
[Zue et al. 1997] Zue, V.; Seneff, S.; Glass, J.; Hetherington, L.; Hurley, E.; Meng, H.; Pao,
C.; Polifroni, J.; Schloming, R. und Schmid, P. From Interface to Content: Translingual
Access and Delivery of on-line Information. In: Proceedings of the European Conference
on Speech Communication and Technology (EUROSPEECH), Rhodos, Griechenland,
1997, S. 2227-2230.

Erklärung nach § 23 IX DPO
Hiermit erkläre ich, daß ich die vorliegende Arbeit selbständig durchgeführt habe und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe.
Barsbüttel, den 20. Dezember 2000
(Stefan Hamerich)