Wissensakquisition für Expertensysteme

Peter Wagner(1)

1. Einleitung

Basis für Expertensysteme ist Expertenwissen: Wissen um die benötigten Fakten und Wissen um die Regeln ihrer Verknüpfung. Ein Schlüsselproblem bei der Entwicklung von Expertensystemen ist die "Extraktion" dieses Wissens von den Experten. "Bei dieser Extraktion wird zur Zeit in der Realität noch wenig professionell vorgegangen" (HAUSCHILDT, 1990, S.525). Dies ist auf der einen Seite unverständlich, da die empirische Forschung ein breites und gut bewährtes Instrumentarium für diese Aufgabe bereitstellt. Auf der anderen Seite ist dies verständlich, gibt es doch sehr viele Möglichkeiten des konkreten Vorgehens zur Wissensakquisition; denn diese Möglichkeiten beschränken sich nicht nur auf die Wahl eines geeignet erscheinenden Instruments aus dem Angebot der empirischen Sozialforschung, sondern stellen den, der sich mit der Entwicklung von Expertensystemen beschäftigt, vor viele weitere Fragen.

Dieser Beitrag versucht auf diese Fragen bewertend einzugehen und auch die Instrumente zur Extraktion von Expertenwissen erschöpfend darzustellen.

2. Wissensakquisition

Abbildung 1: Entwicklungsablauf eines Expertensystems (vgl. HARMON und KING, 1985, S. 196ff., WATERMAN, 1986, S.135 ff., BUCHANAN et al., 1983, S. 138 ff., WEISS und KULIKOWSKI, 1984, S. 11 ff.)

Die in Abbildung 1 skizzierte Entwicklung eines Expertensystems ist für gewöhnlich ein evolutionärer Prozeß, auf den hier nicht im einzelnen eingegangen werden soll (vgl. dazu etwa WAGNER, 1992, S.10ff und die dort angegebene Literatur). Es bleibt festzuhalten, daß in diesem Prozeß die Wissensakqusition eine zentrale Rolle spielt. In fast allen Entwicklungsschritten (vgl. etwa HARMON und KING, 1985, S.196ff., WATERMAN, 1986, S. 135 ff., BUCHANAN et al., 1983, S.138 ff., WEISS und KULIKOWSKI, 1984, S.11 ff.) ist der Knowledge Engineer auf die Interaktion mit Sachgebietsexperten und/oder Endbenutzern angewiesen.

2.1 Phasen der Wissensakquisition

Abbildung 2: Phasen der Wissensakquisition (in Anlehnung an WATERMAN, 1986, S.137 und BUCHANAN et al., 1983, S.139)

Wissensakquisition wird in der Literatur durchgängig in fünf Phasen gegliedert (vgl. WATERMAN, 1986, S.137, BUCHANAN et al., 1983, S.139), die in Abbildung 2 präsentiert sind. Begründet in der Parallelität der Wissensakquisition und der Entwicklung eines Expertensystems gibt es gemeinsame Schnittmengen. Eine vollständige Trennung beider Prozesse erscheint nicht sinnvoll.

2.1.1 Identifizierungsphase

In der Identifizierungsphase werden alle wichtigen Aspekte des Problems aufgedeckt. Dies ist die Identifikation der Partizipanten und deren Bedürfnisse, der zu lösenden Teilprobleme und der Ressourcen. Hier muß abgesteckt werden, welche Experten benötigt werden bzw. auf welchen (anderen) Wegen das benötigte Wissen erworben werden kann (z.B. Bücher, Fallstudien, Datenbanken), ebenfalls muß die benötigte Software, Hardware und die finanziellen Mittel sowie der Zeitraum definiert werden.

Zur Identifikation des Problems führen BUCHANAN et al. einige Fragen an, die hinreichend beantwortet werden müssen (vgl. BUCHANAN et al., 1983, S.141 ff.):

Hier muß hinzugefügt werden, daß bereits in dieser Phase der Umfang des Problems auf ein zu handhabendes Maß beschränkt werden muß. Ein klarer, modularer Aufbau der Wissensbasis und die Natur eines Expertensystems selbst, ermöglichen bzw. leiten sich selbst zu einer späteren Ausdehnung des Problemraumes, je nach den Bedürfnissen, die eventuell erst im Laufe der Entwicklung offenkundig werden. Die Phasen des Expertensystem-Entwicklungsprozesses sind dann einfach wiederholt zu durchlaufen. Eine spätere, offensichtlich wünschenswerte Ausdehnung des Problemraumes kann, muß aber nicht, bereits in dieser ersten Phase festgelegt werden.

Die beiden vorgenannten Aspekte, Festlegung der Ressourcen und Definition bzw. Umfang des Problems können maßgeblich von den Adressaten des zu entwickeln beabsichtigten Expertensystems determiniert werden.

Für eine landwirtschaftliche Zielgruppe beispielsweise gelten andere Maßstäbe als für ein Expertensystem in der Medizin oder anderen Bereichen. Soll ein Landwirt Nutznießer des Expertensystems sein, so ist a priori zu berücksichtigen, welche Hardware auf dem landwirtschaftlichen Betrieb zum Zeitpunkt der Freigabe des Systems voraussichtlich vorhanden sein wird, welche Software vorhanden sein oder zusätzlich benötigt wird (Laufzeit-Lizenzen, Kompilationsfähigkeit des Expertensystems, Programmumgebung, ...). Nach Maßgabe dieser Kriterien scheiden viele Möglichkeiten bereits aus, die etwa für eine Zielgruppe wie Mediziner wohl in Betracht kommen würden. Beispielsweise scheidet für eine benutzerfreundliche und kostengünstige Lösung im Bereich der Landwirtschaft ein lediglich auf einem Großrechner oder auf einer für solche Anwendungen speziell entwickelten symbolverarbeitenden Maschine (LISP/UNIX Workstations) lauffähiges System eigentlich gänzlich aus. Auch derzeit (1992) bleiben hier die Möglichkeiten für den Bereich der Agrarwissenschaften - will man nicht von vornherein auf die Unterstützung speziell geeigneter Werkzeuge verzichten - noch weitgehend auf die regelbasierten Expert-System-Building-Tools (ESBT's), die auf Industriestandard entsprechenden Computern zugeschnitten sind, beschränkt. Diese sehr pragmatischen Aspekte werden im Laufe der Zeit einem Wandel unterliegen und werden zu jedem bestimmten Zeitpunkt auf der Zeitachse den Problemraum und Umfang, ja sogar die Art des zu lösenden Problems und die Zielbestimmung maßgeblich determinieren.

2.1.2 Konzeptualisierungsphase

Für die Konzeptualisierungsphase erachten BUCHANAN et al. die Beantwortung der folgenden auszugsweise wiedergegebenen bzw. ergänzten Fragen als notwendig (vgl. BUCHANAN et al., 1983, S.143 ff.):

Bereits in dieser Phase kann es sehr hilfreich sein, einen ersten, sehr beschränkten Prototypen für ein bestimmtes Problem einer bestimmten Unteraufgabe zu entwickeln. Hier kann Aufschluß darüber gewonnen werden, ob die theoretisch erarbeiteten Konzepte praktisch umsetzbar sind. Erkenntnisse dieser Art können viel Zeit ersparen und Irrwege vermeiden helfen. Persönliche Erfahrung und Gespräche mit erfahrenen Expertensystem-Entwicklern haben gezeigt, daß es in vielen Fällen zeitraubender und ineffizienter ist, das Problem zuerst vollständig und korrekt analysieren und konzeptualisieren zu wollen, bevor die Entwicklung eines Prototypen begonnen wird.

In dieser Phase sollte ferner über Fragen der "Granularität" der Repräsentation des Wissens befunden werden, d.h. bis zu welchem Detailierungsgrad das problemspezifische Wissen Eingang in die Wissensbasis finden soll. Die "Körnung" des Wissens sollte so grob wie möglich sein, um den Anforderungen und Zielen noch gerecht zu werden. Unnötig umfangreiche Wissensbasen wären anderenfalls die Folge.

2.1.3 Formalisierungsphase

Die Formalisierung ist gekennzeichnet durch das Ausdrücken der Schlüsselkonzepte und -beziehungen in einem, dem gewählten ESBT gerecht werdenden, formalen Rahmen. Falls beispielsweise ein regelbasiertes System gewählt wurde, muß versucht werden, die Expertise in IF-THEN Regeln auszudrücken. Für ein induktives System ist hier die Definition geeigneter Matrizen bzw. Tabellen erforderlich. Die Formalisierungsphase kann mit dem generieren eines Pseudocodes in der konventionellen Programmiertechnik verglichen werden.

2.1.4 Implementierungsphase

Der nächste Schritt der Implementation hat ebenfalls eine Parallele in der konventionellen Programmiertechnik: Es ist die Umsetzung des formalisierten Wissens in ein maschinenlesbares Programm. In dieser Phase wird ein endgültiger Prototyp erstellt. Durch die Implementierung des Prototypen wird die Effizienz des in den vorherigen Phasen entwickelten Designs überprüft. Mit hoher Wahrscheinlichkeit bedarf das Design mehrerer Revisionen.

2.1.5 Testphase

Dies führt nun unmittelbar zu der Phase der Tests. Neben den bereits erwähnten Leistungsmaßstäben wird hier das System insbesondere auf Fehler in der Wissensbasis überprüft. Die häufigste Fehlerursache liegt in den schlußfolgernden Regeln. Diese Regeln sind selten unabhängig voneinander, wenn es auch sehr bequem ist, sie als unabhängig zu betrachten. Neben solchen Konsistenzfehlern können Prämissen von Regeln fehlerhaft oder Schlußfolgerungen schlicht falsch sein. Dies führt zu unlogischen Ergebnissen. Regeln können unvollständig sein oder ganz fehlen. In jedem Fall ist, außer wenn offensichtliche Tippfehler in einer Prämisse oder einem Variablennamen zu identifizieren sind, in eine neue Phase der Wissensakquisition einzutreten.

Die endgültigen Tests des fertig entwickelten Expertensystems müssen u.a. auch die Akzeptanz durch den Benutzer berücksichtigen.

Schließlich sollten die gewählten Testbeispiele (oft konkrete Fallstudien) nicht zu "einfach" sein. Sie sollten in ihrer Komplexität mindestens den Problemen der realen Welt entsprechen.

3 Möglichkeiten der Wissensakquisition

Das Schlüsselelement zur Erstellung einer Wissensbasis ist der Transfer von Wissen (meist menschliche Expertise) in das Computerprogramm(2). Der Prozeß des Extrahierens von Wissen aus einem Experten und die Codierung in eine maschinenlesbare Form wird als "Knowledge Engineering" bezeichnet. Eine Person mit diesen besonderen "Knowledge Engineering" Fähigkeiten (zur Beschreibung dieser besonderen Fähigkeiten vgl. Abschnitt 3.2.3) wird "Wissensingenieur" genannt.

Nicht in allen Fällen, in denen die Entwicklung eines Expertensystems angestrebt wird, kann allerdings davon ausgegangen werden, daß die idealisierte Zusammenarbeit Experte - Wissensingenieur (oder sogar mehrere Experten und/oder mehrere Wissensingenieure in einem Projekt) zustandekommen kann. Vielmehr ist eine Entwicklung abzusehen: Es gilt auch in starkem Maße für die Agrarwissenschaften, daß, insbesondere für in näherer Zukunft zu erarbeitende Teilmodelle, der Experte sein eigener Wissensingenieur sein muß. So müssen prinzipiell zwei Möglichkeiten unterschieden werden (vgl. HARSH, 1988, S.20 ff.):
1.) Der Experte ist selbst der Wissensingenieur und
2.) der Wissensingenieur arbeitet mit dem Experten zusammen.

3.1 Experte mit Wissensingenieur-Fähigkeiten

Dieser Ansatz verlangt von dem jeweiligen Experten das Erlernen von Fähigkeiten, die normalerweise nur für den Wissensingenieur erforderlich sind. Er muß sich in die Lage versetzen, einen Computer zu bedienen, vorzugsweise ESBT's (anstelle von höheren AI-Sprachen wie LISP oder PROLOG) zu beurteilen und zu beherrschen, sowie ein Expertensystem zu entwerfen, entwickeln und testen. Er muß darüber entscheiden, welches Wissen problemrelevant, welche Art der Repräsentation des Wissens geeignet ist, etc.; kurz: Er muß alle Entwicklungsphasen eines Expertensystems alleine zu durchschreiten in der Lage sein. Vorausgesetzt, der Experte verfügt bereits über all diese Fähigkeiten, so ist der Hauptvorteil dieses Ansatzes im raschen Erstellen eines Prototypen zu sehen sowie darin, daß der Experte die Testläufe des Expertensystems unmittelbar und ohne langwieriges Feedback mit einer weiteren Person beurteilen kann. Neues, problemimmanentes Wissen kann so schnell zur Wissensbasis addiert und Reibungsverluste können vermieden werden. Oft wird dieser Ansatz der einzige Weg überhaupt sein, ein Expertensystem zu entwickeln. Dies ist nicht nur eine Frage der finanziellen Mittel, vielmehr ist das derzeit eher limitierte Angebot an Wissensingenieuren bestimmend.

Demgegenüber stehen nicht zu übersehende Nachteile, besonders falls der Experte nicht bereits über Wissensingenieur-Fähigkeiten verfügt. Der enorme Zeitaufwand zur Entwicklung dieser Fähigkeiten liegt nicht nur in den theoretischen Anforderungen begründet, sondern auch darin, daß ein effizientes Nutzen von selbst relativ einfach zu erlernenden ESBT's viel Übung und Erfahrung voraussetzt. Auch wenn alle diese Voraussetzungen gegeben sind: Dadurch, daß der Experte selbst "sein" Expertensystem entwickelt, kann der Fokus auf das Wesentliche, das Sachproblem verschwimmen. In der Literatur wird oft generell davor gewarnt, daß Experte und Wissensingenieur in einer Person vereint sind (vgl. etwa WATERMAN, 1986, S.154, JONES et al., 1986, S.3, BRACHMAN et al., 1983, S.43 ff.). Dieses Problem kann gemildert werden, indem der das Expertensystem entwickelnde Experte häufiger das Gespräch und die Beurteilung der geleisteten Arbeit sucht. Gesprächspartner können sowohl andere Fachexperten als auch potentielle Anwender sein. Nach diesem Ansatz würde der Experte eher die Rolle des Wissensingenieurs als die des Experten einnehmen, obgleich er dennoch Experte ist. Dieses Vorgehen nimmt gleichsam eine Zwischenstellung zwischen den beiden hier geschilderten Konzepten ein.

3.2 Experte und Wissensingenieur in Zusammenarbeit

Abbildung 3: Wissensakquisition zur Entwicklung eines Expertensystems (in Anlehnung an WATERMAN, 1986, S.153)

Dieser Ansatz setzt die Existenz eines Wissensingenieurs voraus, der dann mit einem (oder mehreren) Experten eines Fachgebietes zusammenarbeitet. Er kann, wie in Abbildung 3 skizziert, dargestellt werden.

Der Hauptvorteil dieses Ansatzes ist die Arbeitsteilung: Der Fachgebietexperte stellt sein Wissen und seine Erfahrung zur Verfügung, der Wissensingenieur entwickelt das Expertensystem. So braucht der Experte sich nicht des mühevollen Prozesses zu unterziehen, den Umgang mit ESBT's zu erlernen, ihm bleibt mehr Zeit für andere Aufgaben. Der Wissensingenieur, der auf das Entwickeln von Expertensystemen spezialisiert ist, sollte in der Lage sein, ein Expertensystem zu programmieren, welches den Anforderungen und auch Änderungswünschen des Experten bzw. der Anwender entspricht. Wie auch bei der Entwicklung konventioneller Programme wird das allerdings nicht immer der Fall sein. Besonders (unbequeme, aber sinnvolle) Änderungswünsche können vom Programmentwickler als "technisch nicht durchführbar" hingestellt werden, ohne daß dem, der die Änderung wünscht, die Möglichkeit gegeben ist, dies zu beurteilen. Reibungsverluste dieser Art entstehen nicht, solange der Experte "sein eigener" Wissensingenieur ist.

Die weitaus größte Hürde allerdings ist der Prozeß der Wissensextraktion von dem Experten, beginnend mit der Wahl eines geeigneten Experten und sich fortsetzend in der Art der Interaktion zwischen Wissensingenieur und Experte. Insbesondere die Interaktionsproblematik verdient nähere Betrachtung, wobei einige der zu erwähnenden Punkte auch dann von Bedeutung sein können, wenn der Experte "sein eigener" Wissensingenieur ist; auch ein solchermaßen entwickeltes Expertensystem sollte verständlich und nachvollziehbar sein. Das Programm wird u.U. von anderen Personen weiterentwickelt bzw. gewartet, und der Benutzer soll sich in der Programmumgebung wohlfühlen. Demzufolge ist auch in diesem ersten geschilderten Ansatz Interaktion auf unterschiedlichen Ebenen notwendig, insbesondere wenn der Programmentwickler nicht auf die Expertise und Beurteilung anderer Fachgebietsexperten verzichten will. Unter diesem Gesichtspunkt sollen im folgenden die wichtigsten Probleme angerissen werden (vgl. BUCHANAN et al., 1983, S.153 ff. und WATERMAN, 1986, S.192 ff.).

3.2.1 Die Wahl geeigneter Experten

Von der Wahl des Experten oder der Expertengruppe ist das Gelingen des Projektes maßgeblich beeinflußt. Einen ausführlichen Überblick aller damit verbundenen Probleme liefern McGRAW und HARBISON-BRIGGS (1989, S.95 ff.).

Grundsätzlich ist zu entscheiden, ob ein Experte oder eine Gruppe von Experten ihr Wissen zu Verfügung stellen sollen. Dies ist zum einen abhängig davon, ob es überhaupt mehr als einen wirklichen Experten für das Sachproblem gibt, und zum anderen von dem geplanten Expertensystem selbst. Umfangreiche Expertensysteme können aus mehreren Unter-Systemen bestehen, so daß als generelle Leitlinie festzuhalten bleibt: Je umfangreicher das Expertensystem, desto mehr Experten werden benötigt (vgl. McGRAW und HARBISON-BRIGGS, 1989, S.100).

Allerdings stellt sich die Frage nach der Zahl der Experten auch für die Entwicklung kleinerer Systeme. Hier werden in der Literatur höchst gegensätzliche Auffassungen vertreten. HAUSCHILDT befindet, daß die Befragung oder die Beobachtungen von einzelnen Experten zur Gewinnung der Wissensbasis einseitig seien und daß die Erfassung des Informationsbedarfes über die Befragung von Einzelpersonen hinauszugehen habe (HAUSCHILDT, 1990, S.531).

Andererseits ist vorstellbar, daß für gewisse Problem, gerade im Diagnose-/Therapie-Bereich, ein einzelner, wirklicher Experte allen Ansprüchen gerecht werden kann. Dies schließt nicht aus, daß zu einem späteren Entwicklungsstadium noch andere Experten hinzugezogen werden, etwa zur Evaluierung des Prototypen.

Als Opponent zu einer Expertengruppe steht der bereits diskutierte Ansatz einer "Personalunion" von Experte und Wissensingenieur, worin beispielsweise HARSH (1988, S.20) einige Vorteile sieht.

Ungeachtet aller für und wider der verschiedenen Philosophien erscheint unter pragmatischen Gesichtspunkten vernünftig, ein dafür geeignetes Problem vorausgesetzt, zunächst nur die Expertise eines einzelnen Experten einzuholen und in die Wissensbasis des Expertensystems einzubringen. Mehrere Experten der gleichen Domäne können gegensätzlicher Auffassung sein, was die Umsetzung des Wissens in eine computerverständliche Form sehr erschweren kann (Techniken zur Lösung solcher Konflikte sind in Abschnitt 4 aufgezeigt) und den Prozeß des "prototyping" unnötig verlängert (vgl. NOVOA und ÖHLMÉR, 1988, S.187).

Der so programmierte Prototyp kann dann in einer zweiten Runde von verschiedenen Experten kritisiert werden.

Zusätzlich kann eine erhöhte Effektivität der Wissensakquisition erreicht werden, wenn diese am Beispiel konkreter Fälle erfolgen kann, da es dem Experten so wesentlich einfacher gelingt, sein Wissen preiszugeben (vgl. JONES et al., 1986, S.10 ff.).

Die Frage nach der "richtigen" Anzahl der Experten kann hier nicht abschließend beantwortet werden. Dem Argument, daß mehrere Experten den Fortschritt der Entwicklungsarbeiten hinderlich sein können, steht entgegen, daß für manche Sachprobleme unter Umständen erst mehrere Experten in der Lage sind, das damit verbundene Wissen vollständig zu erfassen.

Unabhängig von der Anzahl der Experten, muß jeder in Frage kommende Experte unbedingt hochbefähigt und "sattelfest" im gewählten Sachgebiet sein. Anderenfalls wird der Wissensingenieur nicht ohne weiteres die gewünschten Regeln aus den Interviews mit dem Experten ableiten können. Gleiches gilt für den Experten, der sein eigener Wissensingenieur ist, möglicherweise wird er auf Gespräche mit anderen Experten angewiesen sein. Kompetenz im relevanten Fachgebiet ist das wichtigste Kriterium zur Auswahl des Experten. Der Experte sollte weiterhin offen sein und die Fähigkeit besitzen zu artikulieren, also sein Vorgehen bei der Lösung eines Problems in verständlicher Form zu vermitteln. Der Experte sollte ebenfalls der Computertechnologie aufgeschlossen gegenüberstehen und von der Zweckmäßigkeit des Projektes bzw. Expertensystems im allgemeinen überzeugt sein. Je mehr der Experte über Computer und Programmierung weiß, desto besser. Schließlich muß der Experte über genügend Zeit verfügen und gewillt sein, diese dem Wissensingenieur zur Verfügung zu stellen. Diese Zusage sollte vor dem Start des Projektes vorliegen.

Als letzter Punkt dieses Abschnitts sei die Expertenauswahl für die konkret vorliegende Problematik der Betriebsanalyse angeschnitten.

Die Betriebsanalyse wird vornehmlich von Beratern durchgeführt. Es liegt also nah, auf einen oder mehrere Berater mit bester Reputation für die Wissensakquisition zurückgreifen zu wollen. Auf einem Terrain wie der Betriebsanalyse allerdings, wo im Gegensatz zu vielen anderen Diagnose-/Therapie-Problemen keine allgemein anerkannte Vorgehensweise existiert, über die Auswahl der Kennzahlen und die Methode der Analyse kein Konsens besteht, stellt sich die Frage, ob die Gruppe der Berater, gewissermaßen als "Umsetzungsexperten", tatsächlich geeignete Experten zu stellen in der Lage ist. Geht es bei der Konzeption eines Expertensystems - wie im vorliegenden Fall - auch darum, innovative Ansätze einzubringen und sie einer Diskussion zu stellen, dann erscheint es sinnvoller, einen Ansprechpartner eher in der Gruppe der "Schöpfungsexperten" zu suchen, also dort, wo neue Konzepte erdacht, umgesetzt und erprobt werden. Mit anderen Worten: Ist an die Entwicklung eines Expertensystems ein wissenschaftlicher Anspruch geknüpft, erscheint die Befragung eines einzelnen Experten vorzüglicher.

3.2.2 Interaktion zwischen Projektmitgliedern

Das Umsetzen des extrahierten Wissens in ein Computerprogramm erfordert ein gewisses Maß an Codierung. Das dem Computer präsentierte Wissen liegt also in einer anderen Form vor, als es dem Experten geläufig ist. Dennoch müssen sowohl Computer als auch Experte in der Lage sein, beispielsweise in einem regelbasierten System, die Regeln zu verstehen. Es ist Sache des Wissensingenieurs, diese Kompatibilität herzustellen. Zur Beurteilung des Expertensystems durch den Experten muß dieser in der Lage sein, die Regeln zu verstehen, das Programm muß also lesbar und verständlich sein. Der Wissensingenieur sollte die gleiche Terminologie für das Programm wie der Experte benutzen. Gleiches gilt, wenn ein Experte alleine ein Expertensystem entwickelt. Für Wartung und Weiterentwicklung sollte ein Programm lesbar sein. Darüber hinaus bieten viele ESBT's für den Benutzer die Möglichkeit, die Regeln, die während des Begründungsprozesses zu einer bestimmten Schlußfolgerung geführt haben, zu evaluieren. Lesbare und verständliche, der Alltagssprache nahe Regeln sind nicht zuletzt auch aus diesem Grund erforderlich. Die Wahl des ESBT's beeinflußt diesen Sachverhalt erheblich. Die Entwicklung eines Expertensystems muß einhergehen mit der Lösung von Problemen aus der realen Welt. Vereinfachte Fallstudien haben simplifizierte Regeln zur Folge. Dies gilt sowohl für den Experten und den Wissensingenieur als Team als auch für den allein entwickelnden Experten. Bei der Auswahl der zu lösenden Probleme ist ebenso systematisch vorzugehen (der ganze Suchraum sollte abgedeckt sein) wie bei der Änderung der Daten für jedes Problem.

Weitere relevante Probleme speziell für den hier näher betrachteten Ansatz eines Teams von Experte und Wissensingenieur betreffen unter anderem: Regelmäßige Zusammenkünfte des Teams, Verwendung elektromagnetischer Tonaufzeichnung, Zusammenkünfte nur an Plätzen, wo sicher keine Störungen zu erwarten sind, Vertrautheit des Wissensingenieurs mit Methoden der empirischen Sozialforschung und der Anwendung unterschiedlicher Interviewtechniken, Beobachtung, Experiment ...). Falls der Prozeß der Extraktion des Wissens nichts reibungslos verläuft, kann dieser hier beleuchtete Ansatz nachteilig sein.

3.2.3 Notwendigkeit und Charakteristika eines Wissensingenieurs

Neben den zur Verfügung stehenden Personen ist für die Notwendigkeit eines Wissensingenieurs insbesondere das Ausmaß des Problems relevant; davon wiederum kann direkt - wie im letzten Punkt gezeigt - die Wahl des ESBT und letztlich der Bedarf an einem Wissensingenieur abhängen. Diese Zusammenhänge sind in Abbildung 4 dargestellt.

Abbildung 4: Bedarf für einen Wissensingenieur (in Anlehnung an HARMON et al., 1988, S.162)

Wenn nun ein Wissensingenieur gebraucht wird, stellt sich die Frage: "Was sind die Aufgaben eines Wissensingenieurs?" Oder: "Was unterscheidet den Wissensingenieur von einem konventionellen Programmierer?" In der Tat wird in der Literatur dieser Vergleich gezogen, der aber nur teilweise zutrifft. ROLANDI beispielsweise bemerkt dazu, daß eine wichtige Aufgabe eines Wissensingenieurs - wie auch für konventionelles Programmieren - die Systemanalyse ist: "... the tools and the methods of the system analyst are largely the same as those of the knowledge engineer" (ROLANDI, 1986, S.59). Einige Aufgaben eines Wissensingenieurs sind also mit denen eines konventionellen Programmierers identisch, andere vollkommen unterschiedlich.

Definitionen für Wissensingenieure reichen von: "The person who designs and builds the expert system" bis zu längeren Beschreibungen. Eine der griffigsten Definitonen ist bei HARMON et al. zu finden:

"A knowledge engineer works with a human expert to identify and refine the knowledge needed to solve a particular type of problem. The ability to obtain the knowledge from a human expert during repeated interviews and then work with the human expert to study jointly how the system handles cases and determine how to improve the system is the essence of the knowledge engineer's job.

The knowledge engineer is part student, part teacher, part consultant, part model builder, and part programmer. If knowledge engineers do their jobs right, human experts are led through what could be a painful, confusing process in a reasonably efficient, pleasant manner" (HARMON et al., 1988, S.163).

Um den "job" des Wissensingenieurs in dieser Weise vollziehen zu können, formuliert ROLANDI einige Anforderungen, die er a priori erfüllen muß (ROLANDI, 1986, S.62). Dennoch muß ein Wissensingenieur eine breit angelegte Ausbildung und eine umfassende Allgemeinbildung aufweisen. Die selbstverständliche Computerqualifikation sollte begleitet werden von einem "gesunden Verhältnis" zu den Humanwissenschaften. Darüber hinaus sollte der Wissensingenieur mit grundlegenden Kenntnissen der Systemanalyse, Psychologie, Logik, Linguistik und Methoden der empirischen Sozialforschung gewappnet sein.

All dies ist notwendig, um die drei wesentlichen Aufgaben eines Wissensingenieurs

zufriedenstellend erfüllen zu können. Diese Aufgaben sind bereits stillschweigend weiter oben bei der Darstellung der einzelnen Phasen der Wissensakquisition beschrieben worden.

Diese relativ präzisen Tätigkeitsbeschreibungen sollen allerdings nicht darüber hinwegtäuschen, daß die Anforderungen an einen Wissensingenieur noch lange nicht vollständig definiert sind. DIEDRICH bemerkt dazu folgendes:

"Es ist bisher noch nicht gelungen, eine funktional vollständige Definition des Aufgabenbereiches eines Wissensingenieurs zu liefern. Tatsächlich wird dem Wissensingenieur die Wahrnehmung einer Vielzahl äußerst heterogener Funktionen aufgebürdet. Dazu gehören Aufgaben, die traditionell von der Systemanalyse bewältigt werden, aber auch die Datensammlung und -interpretation in den verschiedensten Bereichen. Das Spektrum reicht weiterhin von der psychologischen Einflußnahme auf den Experten bis zur fortgeschrittenen KI-Programmierung. Dieses erfordert von der entsprechenden Person ein großes Hintergrundwissen, nicht nur was Techniken der KI angeht, sondern auch hinsichtlich der Motivierung derjenigen Personen, deren Mitarbeit unverzichtbarer Bestandteil des knowledge engineering ist" (DIEDRICH, 1987, S.9).

4. Methoden der Wissensakquisition

Die Wissensakquisition ist als ein iterativer Prozeß der Formalisierung aufzufassen (vgl. DIEDERICH, 1987, S.41), also direkt in diese Entwicklungsphase eines Expertensystems einzuordnen. Die Wissensakquisition selbst kann ebenfalls in verschiedene Phasen, je nach Entwicklungsstadium des Expertensystems, unterteilt werden. In jeder dieser Phasen können jeweils andere Methoden der "Extrahierung" von Wissen angemessen sein. In aller Regel werden mehrere Wissenserwerbsmethoden eingesetzt, um ein zufriedenstellendes Ergebnis zu erreichen. Dem Umstand Rechnung tragend, daß der Prozeß der Wissensakquisition einer der kritischsten Punkte bei der Entwicklung von Expertensystemen ist, werden im folgenden diese Methoden näher beschrieben.

Allgemein gilt es hinsichtlich Mensch-Mensch- und Mensch-Maschine-Kommunikation zu unterscheiden. Letztere bezeichnet eine automatisierte Akquisition von Wissen, d.h. der Experte kommuniziert über eine spezielle "Akquisitons-Software" mit einem Computer. Diese Art des Wissenserwerbs steckt noch "in den Kinderschuhen" und steht, diese Prognose kann gewagt werden, für agrarwissenschaftliche Anwendungen in den nächsten Jahren noch nicht zur Verfügung. Eine ausführliche Darstellung des Status Quo findet sich in einem Beitrag von DIEDERICH (1987), eine Bewertung der verschiedenen Techniken bei HAUSCHILDT (1990).

Mensch-Mensch-Kommunikation bezeichnent die "traditionelle" Wissensakquisition über einen Wissensingenieur, die Gegenstand der folgenden Ausführungen ist.

In der Welt der Datenverarbeitung ist es schwierig, wenn nicht ungewöhnlich, mit unstrukturiertem, unsystematischem, menschlichem Wissen zu arbeiten. Hingegen ist in der empirischen Sozialforschung die Erhebung von Wissen bzw. Meinungen, der Umgang mit mündlicher, nicht formalisierter Expertise ein weithin gelöstes Problem. Es liegt daher nah, die dort erprobten und bewährten Methoden zumindest im Ansatz als Techniken für die Wissensakquisition zu verwenden.

Eine konzise Darstellung wird von SCHIRMER (1988, S.68 ff.) geboten, die hier verkürzt wiedergegeben werden soll, wobei der Schwerpunkt ausschließlich auf den für die Wissensakquisition für Expertensysteme relevanten Aspekten liegt (zu den gängigen Methoden im einzelnen, ihren Merkmalen, Vor- und Nachteilen an sich vgl. etwa KÖNIG (1967) oder ATTESLANDER (1975)).

Wissen ist nicht zwingend mit Menschen oder Experten verbunden, es kann ebenfalls mehr oder weniger "versteckt" beispielsweise in Textform, Grafiken, Fallstudien oder mathematischen Formeln vorliegen; daher sind Methoden zur Extraktion dieser Art von Wissen ebenfalls Gegenstand der folgenden Betrachtung.

Mensch-Maschine-Kommunikation

4.1 Induktion

Dieses Verfahren der maschinellen Erschließung von Wissen bietet sich zur Wissensakquisition an. Die Rechtfertigung des induktiven Vorgehens liegt darin begründet, daß der Experte kaum über das für den Wissensingenieur so notwendige Regelwissen verfügt, sondern eher ein Anwendungswissen (compiled knowledge), zumindest bei der Lösung von Routinefällen, zur Anwendung bringt. Die Arbeitsweise des Experten ist so sehr effizient, nur hat er die seiner Arbeitsweise zugrunde liegenden Regeln nicht präsent, weil er sie entweder nie gelernt hat, oder sie durch intuitives Vorgehen oder Heuristiken ersetzt wurden. Oft können schon aus wenigen Beispielen Regeln abgeleitet und erhärtet werden, die so vorher dem Experten nicht bewußt waren.

Mensch-Mensch-Kommunikation

4.2 Interview

Das Interwiew in seinen beiden Ausprägungen "strukturiertes Interview" und "Intensivinterview" ist die zentrale Akquisitionstechnik bei der Tätigkeit des Wissensingenieurs.

4.2.1 Strukturiertes Interview

Typisch für diese Art von Interview ist eine feste Vorgabe der Struktur (Fragethema und Fragenreihenfolge ist festgelegt) und/oder auch der Fragenformulierung. Die Konkretheit dieses Vorgehens bedingt den Einsatz dieser Technik erst im fortgeschrittenen Projektstadium, sowohl die fachlichen Hintergründe als auch die Terminologie müssen dem Wissensingenieur vertraut sein. Diese Technik bietet sich an zur Vertiefung bereits behandelter Wissensbereiche, insbesondere zur Befragung mehrerer Experten zu einem Thema.

4.2.2 Intensivinterview

Für Intensivinterviews wird lediglich ein mehr oder weniger begrenztes Gesprächsthema vorgegeben. Ziel dieser Fragetechnik ist es, genauere Informationen vom Befragten hinsichtlich des zu behandelnden Themas, seiner Terminologie, Konzepte und Probleme zu erhalten. Intensivinterviews eignen sich in hervorragendem Maße für den Wissensingenieur - neben dem Literaturstudium -, um erste Erfahrungen bezüglich des Themengebietes zu sammeln. Ein weiterer Grund für die Anwendung dieser Technik im Anfangsstadium der Erhebung ist in der Motivationssteigerung des Experten zu sehen.

4.3 Schriftliche Befragung

Wie beim strukturierten Interview sind hier Thema und Reihenfolge, und auch zwingend der konkrete Wortlaut der Fragen, festgelegt. Die Rechtfertigung dieses für die Wissensakquisition eher unüblichen Verfahrens liegt in einer Zeit- und/oder Kostenersparnis, mangelnder lokalen Verfügbarkeit von Experten und schließlich der Möglichkeit, eine größere Gruppe von Experten zu befragen.

4.4 Gruppendiskussion

Im Laufe der Erhebung können sich durch unterschiedliche Expertenaussagen Widersprüche ergebenen. In diesem Fall, oder bei einem Auseinanderklaffen von Theorie und Praxis der Expertise, ist die Methode der Gruppendiskussion neben der Delphi- Methode (vgl. Aschnitt 4.7) geeignet, einen Klärungsprozeß in Gang zu setzen. Eine Gruppe von Experten wird gebeten, über ein genau definiertes Thema unter der Leitung des neutralen Wissensingenieurs zu diskutieren. Strittige Meinungen prallen in offener Auseinandersetzung aufeinander, mit der Bitte um Einigung wird ein Meinungsbildungsprozeß angestoßen, wie er sich auch im Alltag vollzieht. Hieraus ergeben sich Anhaltspunkte für die Validität des erhobenen Wissens.

4.5 Beobachtung und "lautes Denken"

Die Methode der Beobachtung umfaßt auch die Protokollanalyse und des think-aloud-protocol (Lautes Denken). Das Zusammenspiel dieser Ansätze zeigen BIEKER und SCHMIDT am Beispiel des Wissenserwerbs für einen "Experten-Regler" (1986, S.495 ff.). Beobachtung ist erforderlich, wenn komplexe Interaktionen ermittelt werden sollen, die von den einzelnen Akteuren und/oder Experten nicht explizit wahrgenommen oder über die nicht zuverlässig berichtet werden können. Beobachtung ist immer dann unabdingbar, wenn verbale Auskünfte nicht möglich oder mangelhaft sind.

Ausgangspunkt der Überlegung ist die Erfahrung, daß es Experten oft schwer fällt, die ihren Handlungen zugrundeliegenden Regeln zu formulieren. Der Experte wird daher bei der Lösung eines (vom Wissensingenieur gestellten) Problems aus der täglichen Praxis beobachtet. Zusätzlich wird er angewiesen, bei der Ausführung der Arbeit "laut zu denken". Ziel ist es, über den Weg der Untersuchung der Äußerungen von Experten während der Arbeit, deren Wissen über den Ablauf von Vorgängen zu erfassen.

Voraussetzungen sind hier

Die Äußerungen des Experten und auch seine Handlungen (Denkpausen etc.) müssen akribisch protokolliert werden.

Im idealen Fall erhält der Wissensingenieur so Aufschluß über Problemlösungs-und Schlußfolgerungsstrategien, Heuristiken und über die Zerlegbarkeit der Aufgabe. Diese Methode eignet sich als Ergänzung zum Interview.

4.6 Brainstorming

Brainstorming ist für die Vorstrukturierung der Domäne für den Wissensingenieur und die Sammlung von Problemlösungsstrategien geeignet; somit eher eine Methode, die zu Beginn eines Projektes Anwendung finden kann, insbesondere wenn der Wissensingenieur nicht oder sehr wenig mit der Domäne vertraut ist.

4.7 Delphi-Methode

Die Delphi-Methode dient der mehrstufigen Ermittlung von Gruppenmeinungen und im weiteren Gegensatz zur Gruppendiskussion bei Anonymität und nicht-personalem Kontakt der Experten. Durch kontrollierte Rückkopplung der Ergebnisse mehrerer Befragungsrunden wird versucht, einen Konsens zu erreichen.

Der besondere Wert dieser Methode, wie auch der weiter oben erläuterten Gruppendiskussion, liegt in der Auflösung widersprüchlicher Expertenmeinungen. Wird dieses Ziel auch nach mehrmaliger Durchführung nicht erreicht, muß durch intensive Einzelbefragung oder Gruppendiskussion versucht werden zu klären, aus welchen Gründen kein Konsens erzielt werden kann.

4.8 Soziometrie

Hierunter sind eine Reihe von Verfahren zu verstehen, die Beziehungen der Mitglieder einer Gruppe ermitteln. Diese Methoden dienen also weniger der Akqusition von Wissen als der Ermittlung geeigneter Experten bzw. Expertengruppen.

4.9 Inhaltsanalyse und Sekundäranalyse

Inhaltsanalyse als systematisches Auswertungsverfahren schriftlicher Ablagen der Domäne (Handbücher, Vorschriften, etc.) und die Sekundäranalyse als Methode, vorhandenes Datenmaterial einer Primärerhebung nach anderen Kriterien auszuwerten, dienen hauptsächlich dem Wissensingenieur, sich mit der Domäne vertraut zu machen.

4.10 Review

Die Bewertung durch den Experten dessen, was der Wissensingenieur verstanden und in Regelform abgelegt hat, wird als Review bezeichnet. In diesem fortgeschrittenen Stadium der Akquisition, gleichsam dem Test der bisher implementierten Wissensbasis, wird bereits das gewählte ESBT eingesetzt, um über ein Feedback fehlerhaft inkorporierte Regeln auszumerzen oder neues Wissen zu akquirieren.

4.11 Dialoge

Die Analyse von Dialogen des Experten mit seinem Kunden/Mandanten ist sinnvoll einzusetzen, wenn die Expertentätigkeit eine stark interaktive Komponente aufweist. Dabei können sich Tonbandaufnahmen als sehr hilfreich erweisen.

4.12 Konstruktgitterverfahren

Bei diesem Verfahren wird der Experte aufgefordert, semantisch ähnliche Elemente (z.B. Huhn, Kuh, Gans, Esel ...) einer Klasse (z.B. Tier) zu benennen. Aus dieser Menge werden Tripel gebildet, die dem Experten dargeboten werden. Dieser hat nun ein Attribut oder eine Eigenschaft zu nennen, die zwei Elemente dieses Tripels teilen, das Dritte aber nicht besitzt. Zur Veranschaulichung:

Gibt es ein Merkmal welches Huhn und Gans gemeinsam haben, aber welches kein Merkmal von Kuh ist?

(Beispielsantwort: Federn)

Dieses Vorgehen wird bei allen mögliche Tripel-Kombinationen wiederholt um eine Beziehungsstruktur der im Wissensgebiet vorhandenen Faktoren zu erhalten. Diese Methode eignet sich zur Erstellung semantischer Netze und ist relativ einfach zu automatisieren (vgl. DIEDERICH, 1987, S.18 ff.).

Resümee

Der Beitrag beschreibt die Phasen, Möglichkeiten und Techniken der Wissensakquisition für Expertensysteme. Dabei werden implizit sechs Hauptthesen formuliert:

THESE 1: Ein Expertensysteme erbringt keinen wissenschaftlichen Fortschritt, wenn lediglich geeignete Sachgebietsexperten zu Rate gezogen werden; Input von wissenschaftlicher Seite ist dazu unbedingt notwendig. Nicht alle Expertensysteme jedoch müssen notwendigerweise zum Zwecke des wissenschaftlichen Fortschritts entwickelt werden.

THESE 2: Eine sinnvolle Lösung zur Anzahl der Experten zur Wissensaquisition ist, zuerst einen einzelnen Experten zur Wissensakquisition heranzuziehen, zur Evaluierung des Expertensystems dann aber mehrere Experten.

THESE 3: Die Wissensakquisition selbst erfolgt in verschiedene Phasen, je nach Entwicklungsstadium des Expertensystems.

In jeder dieser Phasen können jeweils andere Methoden der "Extrahierung" von Wissen angemessen sein.

In aller Regel werden müssen mehrere Wissenserwerbsmethoden eingesetzt werden, um ein zufriedenstellendes Ergebnis zu erreichen.

THESE 4: Wissen ist nicht zwingend mit Menschen oder Experten verbunden, es kann ebenfalls mehr oder weniger "versteckt" beispielsweise in Textform, Grafiken, Fallstudien oder mathematischen Formeln vorliegen; daher müssen Methoden zur Extraktion dieser Art von Wissen ebenfalls Berücksichtigung finden.

THESE 5: Wissensakquisition wird durch technische Hilfsmittel (etwa Bandaufzeichnungen) erleichtert.

THESE 6: Wissensakqusition wird durch konkrete Aufgabenstellungen an den Experten erleichtert.

Eine Sitzung, in der der Wissensingenieur mit leeren Händen auftritt, ist verschwendete Zeit.

Es wird deutlich, daß ein "Patentrezept" zur Wissensakquisition nicht existiert, es muß vielmehr von Fall zu Fall eine bestmögliche Lösung gesucht werden.

Résumé

The paper discusses phases, possibilities and techniques of knowledge acquisition for Expert Systems. The six main hypotheses postulated are listed below:

  1. Expert Systems will not bring any progress in science if just domain experts are referred to for knowledge acquisition. But (some) Expert systems may have a different aim than to contribute to scientific progress.
  2. Concerning the question of how many experts to ask for developing an Expert System, a convenient way is to ask only one expert to develop a prototype and consult other (more) experts for evaluation.
  3. The different phases of knowledge acquisition for expert systems may require different methods of knowledge acquisition.
  4. "Knowledge" exists in many different forms. It must not necessarily be extracted from experts. A lot of useful information is to be found in text books, figures, case studies or mathematical formulas, for example.
  5. There are many technical aids which may be used for knowledge acquisition, e.g. tape recorders.
  6. Knowledge acquisition will be more successful if the expert is confronted with precise questions or tasks, unstructured interviews may be wasted time.

There is no pat solution to be applied for knowledge acquisition. The best solution must be sought for every case individually.

Literaturverzeichnis

ATTESLANDER, P.
Methoden der empirischen Sozialforschung. Berlin, New York, 1975

BIEKER, B. und SCHMIDT, G.
Eine einfache Experten Regelung - Wissenserwerb, Implementierung und Anwendungserfahrungen. In: Fortschritte in der Mess- und Automatisierungstechnik durch Informationstechnik. Berlin, 1986, S.493-502

BRACHMAN, R.J. et al.
What are Expert Systems. In: HAYES-ROTH, F., WATERMAN, D.A. und LENAT, D.B. (Hrsg.). Building Expert Systems. Reading, 1983, S.31-58

BUCHANAN B.G. et al.
Constructing an Expert System. In: HAYES-ROTH, F., WATERMAN, D.A. und LENAT, D.B (Hrsg.). Building Expert Systems. Reading, 1983, S.127-168

DIEDRICH, J.
Wissensakquisition. Arbeitspapiere der GMD #245. St. Augustin, 1987

HARMON, P., MAUS, R. und MORRISSEY, W.
Expert Systems - Tools and Applications. New York, 1988

HARMON, P. und KING, D.
Expert Systems - Artificial Intelligence in Business. New York 1985

HARSH, S.B.
Artificial Intelligence - Methods, Tools and Importance of Knowledge Acquisitation. Michigan State University Staff Paper No.88-43, East Lansing, 1988

HAUSCHILDT, J.
Methodische Anforderungen an die Ermittlung des Wissensbasis von Expertensystemen. In: Die Betriebswirtschaft 4/1990, S.525-537

JONES, P. et al.
Knowledge Aquisitation: A Case History of an Insect Control Expert System. In: Papers of the American Society of Agricultural Engineers. St.Joseph MI, 1986, Paper #86-5041

KÖNIG, R.
Handbuch der empirischen Sozialforschung. 1. und 2. Band. Stuttgart, 1967

McGRAW, K.L. und HARBISON-BRIGGS, K.
Knowledge Acquisition: Principles and Guidelines. New Yersey, 1989

NOVOA, V. und ÖHLMÉR, B.
Wirtschaftlichkeitsanalyse für einen landwirtschaftlichen Betrieb. In: DLG (Hrsg.), Wissensbasierte Systeme in der Landwirtschaft, Internationaler Computerkongreß. Frankfurt, 1988, S.178-188

ROLANDI, W.G.
Knowledge Engineering in Practice In: AI-Expert, December 1986, S.58-62

DIEDERICH, J.
Wissensaquisition. Arbeitspapiere der GMD #245. St.Augustin, 1987

SCHIRMER, K.
Techniken der Wissensaquisition. In: Künstliche Intelligenz, Heft 4/1988, S.68-71

WAGNER, P.
Methodische Grundlagen und praktische Entwicklung eines Expertensystems für die Wirtschaftlichkeitsanalyse landwirtschaftlicher Betriebe. Agrarwirtschaft, Sonderheft 132. Frankfurt, 1992

WATERMAN, D.A.
A Guide to Expert Systems. Reading, 1986

WEISS, S.M. und KULIKOWSKI, C.A.
A Practical Guide to Designing Expert Systems. Totowa NJ, 1984

Kurzangaben zum Autor:

Priv. Doz. Dr. Peter Wagner
Institut für landwirtschaftliche Betriebslehre
Justus-Liebig-Universität Gießen
Senckenbergstr. 3
W-6300 Giessen

vorwiegender Tätigkeitsbereich:

Forschung und Entwicklung im Bereich einzelbetrieblicher Entscheidungs-Unterstützungsmodelle und Expertensysteme für die Betriebsführung, sowie deren Zusammenführung zu integrierten Entscheidungs-Unterstützungs-Systemen.


(1) Institut für landwirtschaftliche Betriebslehre, Justus-Liebig-Universität, Senckenbergstr. 3, W-6300 Giessen

(2) Für Wissenstransfer sehen BUCHANAN et al. (1983, S.129 ff.) vier prinzipielle Möglichkeiten:

  1. Knowledge Engineering - expert to knowledge base via knowledge engineer.
  2. Knowledge Engineering - expert to knowledge base via an intelligent editing program (vgl. hierzu auch DAVIS, 1985).
  3. Induction-Data to knowledge base via an induction program.
  4. Text understanding - text to knowledge base via text understanding program.
Es ist für die in diesem Beitrag verfolgten Zwecke hinreichend, die ersten beiden der angeführten Punkte näher zu untersuchen.