3.3.3. Canned Text
Eine weitere Methode, Erklärungen zu erstellen, besteht darin, alle möglichen Fragen der Benutzer im voraus zu antizipieren und die entsprechenden Antworten als Text zu speichern.144 Wenn eine Frage gestellt wird, präsentiert die Erklärungskomponente die im voraus vom Knowledge Engineer oder dem Experten erstellte Antwort. Diese statischen Beschreibungen werden z.B. mit den Regeln oder Frames der Wissensbasis verbunden.145
Abb. 6: Einbettung von Erklärungstexten in Frames146
Canned Text Erklärungen bieten das Potential für verständlichere Erklärungen als die Regel Trace Technik.147 Besonders für naive Benutzer wirkt sich die Möglichkeit, Definitionen und Hintergrundwissen in die Erklärungen einzubetten, positiv aus.148 Darüber hinaus können unwichtige Details der Schlußfolgerung ausgelassen und die Erklärung damit erheblich kürzer und verständlicher gestaltet werden.149 Mit dieser Technik ist auch eine Berücksichtigung der unterschiedlichen Anforderungen der Benutzer möglich, indem für unterschiedliche Benutzerklassen verschiedene Erklärungen bereitgestellt werden.150 Die Erstellung von Erklärungen in verschiedenen Sprachen, wie sie für unterschiedliche nationale Versionen notwendig sind, lassen sich ebenso sehr leicht realisieren.151 Es müssen nur die Erklärungstexte übersetzt werden. Eine Übersetzung des gesamten Programmcodes, wie er im Fall eines Trace oder der Rule Expansion Technik notwendig wäre, entfällt.
Die Erstellung von Canned Text Erklärungen bringt die Problematik mit sich, daß alle potentiellen Fragen an das System von dem Systementwickler vorhergesehen werden müssen.152 Dies ist bei größeren Systemen besonders dann sehr schwierig, wenn zusätzlich auch Erklärungen auf unterschiedlichen Niveaus erstellt werden sollen.153 Ein weiterer Nachteil ist eine fehlende economy of scale. Für 100 Regeln müssen 100 Erklärungstexte generiert werden. Der Aufwand nimmt nicht mit zunehmender Anzahl ab.154 Diese Tatsache zusammen mit der häufig großen Zahl an Regeln155 in wissensbasierten Systemen ist der Grund dafür, daß die Wissensbasis durch die Erklärungstexte sehr groß wird. Dies kann zu Problemen mit der Größe des Arbeitsspeichers führen. Es existieren zwar Techniken, wie z.B. die Indizierung von Regelteilen oder die Verwendung von Pointern, die auf andere Regeln aus dem Kontext verweisen, um den Speicherbedarf zu verringern.156 Sie bringen aber den Nachteil mit sich, daß die Regeln und die Erklärungen getrennt voneinander abgespeichert werden.157 Diese expliziten Dialogtexte158, eventuell verbunden mit weiteren Techniken der Speicherplatzeinsparung, sind schon bei der Ersterstellung der Wissensbasis aufwendig. Eine Wartung wird durch solche Methoden nahezu unmöglich.159
Die Wartung und die Erweiterung des wissensbasierten Systems stellt sowieso bei der Verwendung der Canned Text Technik ein Problem dar. Dadurch, daß der Code unabhängig von den Erklärungen geändert werden kann, ist es schwierig, Konsistenz zwischen den Erklärungen und dem Verhalten des Programms zu garantieren.160 Eine Änderung in der Wissensbasis erfordert häufig eine Vielzahl von Korrekturen bei den Erklärungstexten, da das Systemverhalten sich geändert hat.
Canned Text Erklärungen können sehr gute Erklärungen der Regeln liefern. Ihre Schwäche liegt darin, daß sie nicht erläutern können, warum eine Regel gerade in einem bestimmten Augenblick verwendet wurde.161 Auch ist es nahezu unmöglich, einen Erklärungstext zu schreiben, der in jeder Situation angemessen ist.162 Dadurch, daß das System kein konzeptionelles Modell von den Erklärungen hat163, sondern nur mit Textstrings arbeitet, sind die Erklärungen häufig redundant, uninformativ und kommunikativ inadäquat.164 Eine Canned Text Erklärung ist darüber hinaus ungeeignet für den Knowledge Engineer, da nach Änderungen das Systemverhalten eventuell falsch dargestellt wird.165
141 Vgl. JABLONSKI, K.: Generierung konjugierter Verben mit
TWAICE, a.a.O., S. 19.
142 Vgl. SWARTOUT, W.R.: XPLAIN: a System for Creating and
Explaining Expert Consulting Programs, a.a.O., S. 293.
143 Vgl. SAVORY, S.E.: What is an Explanation?, in: KBS 86,
Knowledge Based Systems, Proceedings of the International
Conference, London, July 1986, Online 1986, Advanced
Computing Series: 2, 1986, S. 233 (231-238).
Vgl. auch SWARTOUT, W.R.: XPLAIN: a System for Creating and Explaining Expert Consulting Programs, a.a.O., S. 292.
144 Vgl. SWARTOUT, W.R.: Producing Explanations and
Justifications of Expert Consulting Programs, a.a.O., S. 15.
145 Vgl. BOLAM, W.J.: Explanation in Expert Systems, a.a.O.,
S. 904.
145 FRANK, U.: Expertensysteme: Konzepte, Probleme und Potentiale - Ein kritischer Überblick, in: KRUSE, H.-G.; FRANK, U., (HRSG.): Praxis der Expertensysteme, München/ Wien 1989, S. 14 (1-36).
147 Vgl. ROGERS, Y.: User Requirements For Expert System
Explanation: What, Why and When, in: JONES, D.M.; WINDER,
R. (EDS.): Proceedings of the 4th Conference of the British
Computer Society Human Computer Interaction Spechialist
Group, Manchester (UK), 5.-9. Sep. 1988, Camebridge/New York
1988, S. 550 (547-564).
148 Vgl. BERRY, D.C.; BROADBENT, D.E.: Expert Systems and the
Man-Machine Interface. a.a.O., S. 21.
149 Vgl. DAALEN, C. VON; JASPERS, R.B.M.: Explanation
Improvement to Enhance Acceptance of the PLEXUS System,
a.a.O., S. 293,
150 Vgl. ROGERS, Y.: User Requirements For Expert System
Explanation, a.a.O., S. 550.
151 Vgl. FRANK, U.: Expertensysteme: Konzepte, Probleme und
Potentiale - Ein kritischer Überblick, a.a.O., S. 14.
152 Vgl. BERRY, D.C.; BROADBENT, D.E.: Expert Systems and the
Man-Machine Interface. a.a.O., S. 21.
153 Vgl. MORRIS, A.: Expert Systems - Interface Insight, a.a.O.,
S. 318.
154 Vgl. SAVORY, S.E.: What is an Explanation?, a.a.O., S. 232f.
155 Das Wissensbasierte System MYCIN enthält ca. 500 Regeln
und PLAN-POWER ca. 6000 Regeln; Vgl. NEBENDAHL, D.:
Expertensysteme, Teil 1, Einführung in die Technik und
Anwendung, 2. Aufl., Berlin/München, 1990, S. 226/228.
156 Vgl. DAALEN, C. VON; JASPERS, R.B.M.: Explanation
Improvement to Enhance Acceptance of the PLEXUS System,
S 291-293
Vgl. auch SCHNUPP, P.; NGUYEN HUU, CT.: Expertensystem-Praktikum, Berlin/Heidelberg/New York/London/Paris/ Tokyo 1987, S. 44.
157 Vgl. SCHNUPP, P.; NGUYEN HUU, CT.: Expertensystem-
Praktikum, a.a.O., S. 69.
158 SCHNUPP und NGUYEN HUU unterscheiden zwischen expliziten
und impliziten Dialogtexten. Wobei bei den impliziten
Dialogtexten keine Trennung der Texte von den Regeln
erfolgt.
159 Vgl. SCHNUPP, P.; NGUYEN HUU, CT.: Expertensystem-Praktikum, a.a.O., S. 48.
160 Vgl. SWARTOUT, W.R.: Producing Explanations and Justifications of Expert Consulting Programs, a.a.O., S. 15.
161 Vgl. BOLAM, W.J.: Explanation in Expert Systems, a.a.O.,
S. 904.
162 vgl. BOLAM, W.J.: Explanation in Expert Systems, a.a.O.,
S. 910.
163 Vgl. SWARTOUT, W.R.: XPLAIN: a System for Creating and
Explaining Expert Consulting Programs, a.a.O., S, 291.
Vgl. auch BOLAM, W.J.: Explanation in Expert Systems, a.a.O., S. 910.
164 Vgl. WAHLSTER, W.: Erklärungskomponente als Dialogwerkzeuge, a.a.O., S. 45.
Vgl. YASDI, R.: Design of the EXIS's Explanation Component, in: COMPUTERS IN INDUSTRY, Vol. 13, No. 1, 1989, S. 16 (15-21).
|