2 EXPERTENSYSTEME

Expertensysteme sind ein Teilgebiet der Wissenschaftsdisziplinen, die sich mit "Künstlicher Intelligenz" befaßt. Der Begriff "Künstliche Intelligenz" kommt aus dem Englischen als Übersetzung von "Artificial Intelligence". In der internationalen Literatur wird deshalb meist das Kürzel AI verwendet. Wenngleich sich im deutschsprachigen Raum auch das Kürzel KI eingebürgert hat, soll im weiteren gemäß den internationalen Gepflogenheiten als Synonym für "Künstliche Intelligenz" und "Artificial Intelligence" lediglich AI stehen.

Der Begriff der AI kam erstmals im Jahre 1956 auf (DENNING, 1986, S.18). Es gibt (noch) keine geschlossene Definition, was AI überhaupt ist, einen umfassenden Überblick dieser Wissenschaftsdisziplin bietet FEIGENBAUM (FEIGENBAUM et al., 1982).

AI hat ihren Ursprung an Universitäten, denn "AI is an academic research program in the same sense that physics is an academic research program" (HARMON et al., 1988, S.4). Ebenso wie beispielsweise in der zitierten Physik haben sich in AI eine Vielzahl von Forschungsrichtungen etabliert. Kompakter und übersichtlicher lassen sich die AI-Konzepte und -Techniken darstellen, die, zumindest mittelfristig, direkten kommerziellen Erfolg versprechen (vgl. HARMON et al., 1988, S.4):

Diese Fünfgliederung wird von anderen Autoren noch weiter vereinfacht in eine Dreigliederung, die konsistenter erscheint (HARMON und KING, 1985, S.4 ff.):

1. Entwicklung von Computerprogrammen, die Alltagssprache lesen, sprechen und verstehen können.

2. Entwicklung "kluger Roboter", die sich insbesondere an veränderte Umweltbedingungen anpassen können.

3. Entwicklung von Programmen, die sich auf der Grundlage symbolischen Wissens wie menschliche Experten verhalten.

Viele dieser oben genannten fünf (bzw. drei) Kategorien zugrundeliegenden Konzepte und Techniken werden in mehr oder weniger naher Zukunft auch den landwirtschaftlichen Betrieb direkt berühren: Verbesserte Mensch-Maschine-, in erster Linie Computer-Mensch-Computer-Schnittstellen, werden durch natürliche Spracherkennung und einfachere Benutzeroberflächen den Umgang mit Computern erleichtern. "Robotics" - wie die Automation von Produktionsprozessen - ist schon heute aus vielen landwirtschaftlichen Betrieben nicht mehr wegzudenken und wird in Zukunft noch mehr Beachtung finden. Von allen aus AI resultierenden Aktivitäten jedoch haben bis heute die Expertensysteme am meisten Beachtung gefunden.

Diesem Umstand und der aufkommenden, unmittelbaren Bedeutung für landwirtschaftliche Betriebe Rechnung tragend, werden im folgenden Expertensysteme näher betrachtet.

Während der Begriff AI allgemeinerer Natur ist, stellen Expertensysteme Untermengen dar: "AI is simply the transfer of intelligence to machines. Expert systems deal with a small area of expertise that can be converted from human to artificial intelligence" (LEVINE et al., 1986, S.1).

FEIGENBAUM definiert ein Expertensystem als "... an intelligent computer program that uses knowledge and inference procedures to solve problems that are difficult enough to require significant human expertise for their solution. Knowledge necessary to perform at such a level, plus the inference procedures used, can be thought of as a model of the expertise of the best practitioners of the field.

The knowledge of an expert system consists of facts and heuristics. The "facts" constitute a body of information that is widely shared, publicly available, and generally agreed upon by experts in a field. The "heuristics" are mostly private, little-discussed rules of good judgment (rules of plausible reasoning, rules of good guessing) that characterize expert-level decision making in the field. The performance level of an expert system is primarily a function of the size and the quality of a knowledge base it possesses." (FEIGENBAUM, zitiert in: HARMON und KING, 1985, S.5)

In dieser umfassenden, aber dennoch konzisen Definition sind zumindest die Begriffe "knowledge" (im Sinne von Expertensystemen), "inference procedures", "facts" und "heuristics" weiter erklärungsbedürftig.

"Knowledge"

Die Frage, wie das Wissen in Expertensystemen gespeichert bzw. zur Verfügung gestellt wird, führt in das Feld der "Wissensrepräsentation", welches später behandelt wird. Hier soll (allerdings nicht umfassend) die Frage geklärt werden:

Was ist "Wissen"?

Wissen ist komplexer als Information, letztere ist komplexer als Daten. Den Weg von Daten zur Information beschreibt HARSH wie in Abbildung 1 dargestellt. In analoger Weise kann das Entstehen von Wissen aus Informationen verstanden werden. Aus vielen Informationen, die mittels Assoziationen miteinander verknüpft sind, entsteht schließlich Wissen. SCOWN beschreibt diesen Zusammenhang folgendermaßen: "We can think of data as any value available to the system for processing. Information can be described as data that has been selected and organized for a particular purpose. Knowledge in the realm of artificial intelligence, is information structured in a way that brings out and exploits the relationships among the pieces of data" (SCWON, 1985, S.53).

Ein Beispiel soll diesen abstrakten Prozeß verdeutlichen:

Aus vorliegenden Daten über landwirtschaftliche Betriebe können beispielsweise durch Berechnung von Kennzahlen, etwa Gewinn pro ha oder kg Milch pro Milchkuh und Laktation, Informationen gewonnen werden. Ein landwirtschaftlicher Berater kann durch Sammeln (oder "sich Merken") und Verknüpfen der Informationen nach einiger Zeit "Wissen" ableiten. Er weiß somit, daß z.B. eine Milchleistung von 9.000 kg pro Milchkuh und Laktation eine exzellente Leistung darstellt. Er weiß weiterhin, daß es zu einer solchen Milchleistung einer Reihe von begünstigenden Faktoren bedarf, etwa eines fähigen Melkers, ausgezeichneter Hygiene etc.

Das im Beispiel aus zusammengesetzten und assoziierten Informationen (im angelsächsischen Sprachraum als "Chunks" bezeichnet) entstandene Wissen ist bereits verarbeitet und liegt für den Berater abrufbereit vor, d.h. es kann ohne weiteres zur Lösung von Problemen herangezogen werden. Man spricht hier von "compiled knowledge". Dieses Verarbeiten oder "Kompilieren" von Wissen ist der Prozeß des "chunking" (vgl. HARMON und KING, 1985, S.30).

Um kompiliertes Wissen tatsächlich nutzenbringend zur Problemlösung anwenden zu können, bedarf es freilich etwas mehr: nämlich Erfahrung. Kompiliertes, auf Erfahrungen beruhendes Wissen wird als "Heuristics" bezeichnet.

"Heuristics"

"Heuristics" sind Erfahrungswerte oder "rules of thumb", die den Suchraum für Problemlösungen auf ein überschaubares Maß beschneiden (vgl. HARMON und KING, 1985, S.31). Demzufolge können "heuristics" oder Daumenregeln zu fehlerhaften Ergebnissen führen, erhöhen aber hingegen die Wahrscheinlichkeit, das korrekte Ergebnis schneller zu finden (vgl. HARMON et al., 1988, S.7). Der Berater im Beispiel weiß aus seiner Erfahrung, was dazu gehört, eine solch hohe Milchleistung zu erzielen (fähiger Melker, Hygiene etc.). Er kann aber nicht sicher sein, alle diese begünstigenden Faktoren auf jedem landwirtschaftlichen Betrieb mit einer solchermaßen hohen Milchleistung zu finden.

Zusammen machen "heuristics" und "compiled knowledge" die Kompetenz eines Experten aus. Diese beiden Komponenten sind es auch, die in ein Expertensystem einfließen. Da "heuristics" auch Entscheidungen unter unsicherer bzw. unvollständiger Information ermöglichen, gilt dies auch für Expertensysteme. Somit können mit diesem Instrument auch weniger strukturierte Probleme (zur Terminologie von strukturierten vs. unstrukturierten Problemen (vgl. BAXTER, 1983, S.63) oder auch "fuzzy problems" mit unzureichendem oder unsicherem Wissen auf der Basis von "Vertrauensfaktoren" analysiert werden.

"Facts"

Die Fakten in einem Expertensystem repräsentieren die dem Modell innewohnende Information.

Generell kann das, was als Intelligenz betrachtet wird (und das trifft auch für Expertensysteme zu) in zwei Komponenten geteilt werden (vgl. LEVINE et al., 1986, S.5):

1. Eine Sammlung von Fakten und

2. ein Instrument, um diese Fakten für Problemlösungen nutzbar zu machen (weiter unten als Schlußfolgerungsmechanismus beschrieben).

Fakten sind, im Sinne von Expertensystemen, in bestimmter Weise beschriebene Sachverhalte. Eine verbreitete Methode, Fakten darzustellen, ist der Objekt-Attribut-Wert-Ansatz (oder object-attribute-value-triplets, im folgenden OAV-triplets genannt). Objekte sind physikalische Einheiten wie eine Kuh, ein Stall, ein landwirtschaftlicher Betrieb. Attribute sind generelle, mit einem Objekt assoziierte Eigenschaften wie die Größe, die Farbe oder der Zinssatz. Werte schließlich sind die Ausprägungen der Attribute. Der Wert beschreibt das Attribut eines Objekts in einer spezifischen Situation. Objekt und Attribut sind konstant oder fix, der Wert ist variabel. Ein Beispiel mag dies verdeutlichen:

Die Kuh Lisa hat eine Milchleistung von 6000 kg/Jahr. Dieser Satz beinhaltet ein OAV-triplet, wie in Übersicht 1 dargestellt.

Alle diese angeführten OAV-triplets sind Fakten oder Informationen, die in einem Expertensystem repräsentiert sein könnten.

"Inference Procedures" (Schlußfolgerungsmechanismen)

Im Zusammenhang mit AI und Expertensystemen sind zwei "inference procedures" oder Schlußfolgerungsstrategien gebräuchlich: Modus ponens und Modus tollens.

Viele der heute eingesetzten Expertensysteme basieren ausschließlich auf Modus ponens. Diese Strategie bedeutet, daß vorausgesetzt A ist wahr - und eine wahre Regel sagt: "Wenn A, dann B" - gefolgert werden kann, daß auch B wahr ist.

Beispiel:

R e g e l: Wenn eine Kuh ein Kalb hat, dann gibt sie Milch.

Falls nun wahr ist, daß eine (bestimmte) Kuh ein Kalb hat, wissen wir der Regel folgend, daß sie auch Milch gibt.

Modus tollens ist die Umkehrung des Modus ponens. Modus tollens bedeutet, daß vorausgesetzt B ist unwahr - und eine wahre Regel sagt: "Wenn A, dann B", gefolgert werden kann, daß A auch unwahr ist. Auf das Beispiel bezogen: Falls eine (bestimmte) Kuh keine Milch gibt, wüßten wir nach Modus tollens, daß sie auch kein Kalb hat. Diese Schlußfolgerung kann allerdings, wie gesagt, von den meisten heute gebräuchlichen Expertensystemen nicht erreicht werden.

Die kurzen Ausführungen zu den grundlegendsten Begriffen der Definition eines Expertensystems und die Definition selbst geben einen groben Überblick über den Begriff der Expertensysteme.

Um die Unterschiede zwischen Expertensystemen und konventionellen Programmen und insbesondere die Arbeitsweise von Expertensystemen zu verstehen, bedarf es weiterer Ausführungen: Es muß geklärt werden, wie Expertensysteme aufgebaut sind, wie das "Wissen" in Expertensystemen bereitgehalten werden kann und welche Mechanismen den Begründungsprozeß und den Ablauf in Expertensystemen kontrollieren. Weiterhin muß die Frage der Expertensystementwicklung beleuchtet werden. Alle diese Punkte sind Gegenstand der folgenden Betrachtungen.

2.1 Struktur von Expertensystemen

Expertensysteme haben eine allgemeingültige Struktur, dies gilt für Expertensysteme, die unter einer AI-Sprache wie LISP oder PROLOG entwickelt werden, wie auch für Expertensysteme, bei deren Entwicklung sogenannte "Expert System Building Tools" (ESBT's(1)) Anwendung finden. ESBT's sind kommerzialisierte Abkömmlinge von AI-Systemen, die an Universitäten und Forschungseinrichtungen entwickelt wurden. Diese ESBT's sind gleichsam "Werkzeuge", mit denen Expertensysteme als eigene, individuelle Anwendung einfacher und i.d.R. schneller entwickelt werden können als dies beispielsweise mit PROLOG möglich wäre. ESBT's sind vergleichsweise weniger flexibel als eine reine AI-Programmiersprache. ESBT's können von der Idee her mit Tabellenkalkulationsprogrammen (TKP) verglichen werden. Mit diesen TKP's programmiert der Benutzer im originären Sinne seine Anwendung. Wie die TKP's sind ESBT's lediglich eine sehr hoch entwickelte Programmiersprache, die dem Anwender erlaubt, eine bestimmte Aufgabe (einfacher) auszuführen, im vorliegenden Fall die Entwicklung eines Expertensystems. Somit sind ESBT's die idealen Werkzeuge für Anwender, die nicht im Bereich der AI forschen, aber dennoch einen Nutzen aus Expertensystemen ziehen wollen.

Auch zur Entwicklung von FARMEXPERT wurde ein ESBT benutzt. Daher soll im folgenden näher auf diese "Programmierwerkzeuge" eingegangen werden.

Der Kern eines ESBT's besteht aus der Wissensbasis und dem assoziierten Schlußfolgerungsmechanismus, der unter Inanspruchnahme der Wissensbasis versucht, das gewünschte Ergebnis abzuleiten. Die Wissensbasis in einem ESBT ist im Gegensatz zur Wissensbasis in einem Expertensystem leer.

Dieser Kern muß für die Verbindung mit der Außenwelt eine Schnittstelle zum Benutzer oder eine Schnittstelle zu Sensoren und Aktoren aufweisen. Diese Schnittstelle ist Bestandteil eines ESBT's, die konkrete Ausgestaltung jedoch obliegt dem Programmentwickler. Ebenso bedeutsam ist die Schnittstelle zum Programmentwickler, so daß ein Expertensystem überhaupt programmiert, die Wissensbasis eingerichtet und eine geeignete Endbenutzer-Oberfläche geschaffen werden kann. In vielen Fällen ist auch eine Schnittstelle zu anderen Programmen (bzw. zum Betriebssystem) von ausschlaggebender Bedeutung, deren Gestaltung wiederum dem Programmentwickler überlassen ist. Das ESBT stellt auch hier lediglich wieder das Potential zur Verfügung. In Abbildung 2 sind die Struktur und die Bausteine eines ESBT zusammengefaßt. Diese einzelnen Bausteine finden in den weiteren Punkten Erläuterung.

Ein ESBT selbst ist wiederum ein benötigter Baustein für die Entwicklung eines Expertensystems. Abbildung 3 faßt die Bausteine auf diesem Entwicklungspfad zusammen.

Was in FEIGENBAUM's Definition nicht explizit gesagt ist, wird hier klar: Das Wissen, die "Facts" und "Heuristsics" in einem Expertensystem werden von einem Experten gewonnen. Der Entwicklungsprogrammierer (Wissensingenieur) hat die Aufgabe, dieses Wissen mittels bestimmter Techniken, die weiter unten in Kapitel 2.8.2 Erläuterung finden werden und wo auch der Begriff des "Wissensingenieurs" mit Inhalt gefüllt wird, zu "gewinnen" und in einer maschinenverständlichen Form zu bringen.

Nach befriedigenden Testergebnissen und der Ausstattung mit anwendungsspezifischen Daten kann das Expertensystem vom Endbenutzer oder Anwender genutzt werden.

2.1.1 Repräsentation von Wissen in Expertensystemen: Die Wissensbasis

In der Literatur werden mannigfaltige Ansätze herangezogen, um die unterschiedlichen Methoden der Wissensdarstellung in Expertensystemen zu veranschaulichen. Es existiert dazu kein einheitliches Schema, da viele dieser Methoden auf unterschiedlichen Ebenen ansetzen. Bei einem Vergleich allerdings kristallisieren sich drei wesentliche Strategien zur Repräsentation von Wissen in Expertensystemen bzw. hier besser ESBT's(2) heraus, die im einzelnen erläutert werden sollen. Wissen kann abgelegt sein in Form von:

- Beispielen (Examples),

- Regeln (Rules) und

- Rahmen (Frames, auch Objects, Schemes (vgl. HARMON et al., 1988, S.143))

Ergänzend seien noch andere Ansätze mit einigen Literaturhinweisen erwähnt (es finden hier ausschließlich die englischsprachigen Begriffe Verwendung, da eine Eindeutschung bisher noch kaum stattgefunden hat):

- semantic networks (SCWON, 1985, S.66, HARMON und KING, 1985, S.35)

- logical expressions (SCWON, 1985, S.62, MISHKOFF, 1986, S.7-19, HARMON und KING, 1985, S.46)

- object-attribute-value-triplets (HARMON und KING, 1985, S.38)

- multiple worlds (GEVARTER, 1987, S.25, HARMON et al., 1988, S.59)

- certainties (HARMON und KING, 1985, S.41, GEVARTER, 1987, S.25, HARMON et al., 1988, S.59)

- demons (HARMON et al., 1988, S.143, GEVARTER, 1987, S.25)

Diese Liste ist nicht vollständig, und die Reihenfolge stellt keine Wertung dar. Die Übergänge sind teilweise fließend wie auch die unterschiedlichen Ansätze bzw. Methoden nicht gleichberechtigt nebeneinander stehen. Dies bedeutet beispielsweise, daß OAV-triplets wohl eine Möglichkeit sind, Wissen darzustellen, daß aber andere Ansätze sich dieser Methode bedienen können (z.B. können Regeln oder semantische Netze ihre Information mit Hilfe der OAV-triplets darstellen).

Die drei näher zu beleuchtenden Ansätze münden jeweils in "induktive Expertensysteme", "regelbasierte Expertensysteme" und "Frame- bzw. objektbasierte Expertensysteme". Diese sind sehr pragmatischer Natur. Sie werden hier eingehender betrachtet, da sie direkte Anwendung in ESBT's finden.

Die anderen, hier lediglich erwähnten Methoden sind teilweise sehr theoretischer Natur und mögen in der Zukunft zu interessanten Anwendungen führen bzw. finden stillschweigend Verwendung in den drei zu schildernden Strategien. Wo es angepaßt erscheint, werden sie dann Erwähnung finden. Ebenfalls werden jeweils kurz die Vor- und Nachteile der Ansätze bzw. der darauf basierenden ESBT's angerissen.

2.1.1.1 Beispiele / Fallstudien

2.1.1.1.1 Induktive Systeme

Induktive Systeme beziehen ihr Wissen aus Beispielen oder Fallstudien. Sie werden auch als "Inductive Systems" bezeichnet. Um zu einer Schlußfolgerung oder Empfehlung zu gelangen, ist ein Algorithmus notwendig, der, aus den vom Expertensystem-Entwickler in großer Zahl zur Verfügung gestellten Beispielen (Daten und Fakten), Regeln ableitet. Anhand der so verarbeiteten Beispiele wird nun versucht, übereinstimmende oder ähnliche Merkmale zwischen dem vorhandenen und dem aktuell zu lösenden Fall zu finden.

Die Beispiele müssen oft in Matrixform (auch "Induction Tables" genannt) dargestellt werden, um für die Wissensbasis eines Expertensystems aufbereitet werden zu können.

Zur Veranschaulichung diene ein Beispiel:

Eine einfache Induktionstabelle zur Auswahl einer bestimmten Käsesorte, je nachdem, ob sie als Appetitanreger oder Nachtisch gereicht werden soll und in Abhängigkeit der bevorzugten Konsistenz, könnte so aussehen (vgl. MOOSE und SHAFER, 1987, S.3.1 ff.):
CourseConsistencyThe Cheese
AppetizerSoftMontrachet
AppetizerFirmStilton
DessertSoftCamembert
DessertFirmItalian Fontina
*SoftBrie
*FirmCheddar

Die daraus maschinell erstellten Regeln würden dann beispielsweise so aussehen:

IF Course is Appetizer and Consistency is Soft, THEN
The Cheese is Montrachet.

IF Course is Appetizer and Consistency is Firm, THEN
The Cheese is Stilton.

IF Cheese is Dessert and Consistency is Soft, THEN
The Cheese is Camembert.

IF Course is Dessert an Consistency is Firm, THEN
The Cheese is Italian Fontina.

IF Consistency is Soft, THEN The Cheese is Brie.

IF Consistency is Firm, THEN The Cheese is Cheddar.

Anhand dieser Regeln schließlich kann der noch eingehender zu behandelnde Schlußfolgerungsmechanismus versuchen, eine Lösung des Wahlproblems anzubieten.

2.1.1.1.2 Vor- und Nachteile

Die Vorteile dieses Ansatzes sind, daß der Programmentwickler nicht wissen muß, welches Vorgehen bei der Lösung eines bestimmten Sachproblems zu wählen ist. Er hat lediglich passende Beispiele zu finden und sie in sachgerechter Form aufzubereiten.

Nachteilig ist, daß auf diese Art nur einfache Probleme von nicht zu großem Umfang bearbeitet werden können, daß das System wenig flexibel ist und nur eine wenig benutzerfreundliche Oberfläche aufweist. Für ein konkretes Beispiel der Entwicklung eines Expertensystems mit einem induktiven Tool und dessen Verwendung für Probleme in den Agrarwissenschaften sei weiter unten auf das Kapitel 3.2.1.2 "An Expert System for Soybean Diseases" verwiesen.

2.1.1.2 Regeln

2.1.1.2.1 Regelbasierte Systeme

Der Begriff der "Regel" oder "Rule" hat - betreffend Expertensysteme - eine sehr viel engere Bedeutung als in der Alltagssprache. Regeln eignen sich dazu, in formaler Weise Empfehlungen, Anweisungen, Strategien und auch Vermutungen auszudrücken.

Die Repräsentation von Wissen in Form von Regeln ist bis heute die bei weitem gebräuchlichste Technik für Expertensysteme. Ausführliche Darstellungen speziell dieser Technik und aller damit verbundenen Probleme finden sich bei PEDERSEN (1989b) und CARRICO et al. (1989).

Generell werden durch Regeln Beziehungen ausgedrückt, wofür entweder der Attribut-Wert (An Attribute Value:A-V) oder der bereits erläuterte Ansatz der OAV-triplets gebräuchlich ist. Dazu werden IF - THEN statements verwandt. Eine Regel besteht aus einer Prämisse (IF-Teil) und einer Schlußfolgerung (THEN-Teil), wobei jeder Teil aus mehreren Klauseln (IF-clause bzw. THEN-clause) bestehen kann, die über logische Operationen verknüpft sind.

Folgende Regel mag dies verdeutlichen:

R E G E L

Prämisse: IF die Futterverwertung von Mastschweinen geringer ist als 3:1

     AND die tägliche Zunahme von Mastschweinen geringer ist als 500g

     OR das Aussehen von Mastschweinen schlecht ist

Folgerung: THEN ist die Hygiene im Schweinestall nicht in Ordnung. (.8)

Jede Klausel dieser Regel besteht aus einem OAV-triplet:

AttributeObjectValue
---------------------------------------------------------------------------
IFFutterverwertungMastschwein< 3:1
tägliche ZunahmeMastschwein< 500g
AussehenMastschweinschlecht
THENHygieneSchweinestallnicht in Ordnung

(Diese Regel, für ein A-V-System geschrieben, würde einfach kein Objekt enthalten. Um Informationsverluste zu vermeiden, würde das Attribut der ersten Klausel beispielsweise mit "Mastschweinefutterverwertung" bezeichnet.)

Die Schlußfolgerung dieser Regel wird nur dann "erreicht", wenn die Prämisse "wahr" ist. In diesem Fall sind in der Prämisse drei Klauseln enthalten, die über zwei logische Operationen (hier: AND/OR) verknüpft sind. Auch die Folgerung könnte mehr als eine Klausel enthalten. Wann die Prämisse als "wahr" betrachtet wird, hängt von den verwendeten logischen Operationen ab. Für das Beispiel sei dies in folgender Wahrheitstafel gezeigt, die Regeln zur Aufstellung solcher Tafeln unterliegen den Gesetzen der Bool'schen Algebra:
IF Klausel 1 .AND. Klausel 2 .OR. Klausel 3 THEN Prämisse
W W W W
W W F W
W F W W
F W W F
W F F F
F W F F
F F W F
F F F F

W = Wahr
F = Falsch

Klausel 1 = )
Klausel 2 = ) Hier ist der Text der jeweiligen Klausel einzusetzen
Klausel 3 = )

Die Folgerung, daß die Hygiene nicht in Ordnung ist, wenn die Prämisse wahr ist (oder passiert hat) ist höchstwahrscheinlich richtig. Es mag allerdings auch Fälle geben, in denen die Hygiene in Ordnung ist, aber die Prämisse trotzdem wahr, etwa verursacht durch hohe Sommertemperaturen. Diese Unsicherheit wird durch einen Vertrauensfaktor (Confidence Factor = CNF) ausgedrückt: (.8) im Beispiel.

2.1.1.2.2 Berechnung von Konfidenzfaktoren in regelbasierten Systemen

Die etwas ausführlicheren Erläuterungen dieses Kapitels sind vor dem Hintergrund zu sehen, daß die im folgenden dargestellte Theorie zur Berechnung von Konfidenzfaktoren für die Entwicklung von FARMEXPERT, insbesondere bei der weiter unten vorgestellten Methode zur Ermittlung der Signifikanzschwelle, eine tragende Rolle gespielt hat.

Der Begriff "Konfidenzfaktor" steht synonym für "CoNfidence Factors (CNF)" oder auch "Certainty Factors". Die Frage, was CNF eigentlich sind, beantwortet HARMON: "Certainty factors are not probabilities. They are informal measures of confidence or certainty for a piece of evidence. They represent the degree to which we believe that evidence is, in fact, true." (HARMON und KING, 1985, S.42). In Expertensystemen treten üblicherweise zwei Arten von CNF auf (vgl. HARMON et al., 1988, S.74). "Expert Confidence" ist die Sicherheit, die der Experte einer Aussage oder Schlußfolgerung zumißt. "User Confidence" ist die Sicherheit, die der End-Benutzer seiner spezifischen Antwort zumißt.

Gleichwohl CNF im Sinne des Begriffs keine Wahrscheinlichkeiten darstellen, werden sie nach den Gesetzmäßigkeiten des Bayes-Theorems (Konzept der bedingten Wahrscheinlichkeiten) berechnet (vgl. SHORTLIFFE und BUCHANNAN, 1985, S.235, zum Bayes-Theorem selbst BHATTACHARYYA, 1977, S.94 ff. oder BORTZ, 1979, S.72 ff.). Prinzipiell treten in regelbasierten Systemen drei Fälle auf, die jeweils unterschiedliche Wege der Berechnung von CNF erfordern (vgl. HARMON und KING, 1985, S.51):

- Folgerungen (Facts) können durch mehr als eine Regel gezogen werden. Ein Algorithmus berechnet dann den kombinierten CNF.

- Zusammengesetzte Prämissen mit mehreren Klauseln jeweils mit logischen Operatoren (AND oder OR) verbunden, können selbst unsichere Fakten enthalten; eine unsichere Prämisse führt zu einer unsicheren Schlußfolgerung.

- Regeln selbst können weniger als 100% sicher sein. CNF werden üblicherweise im Bereich von 0.0 (Behauptung ist falsch) bis 1.0 (Behauptung ist vollkommen sicher) angegeben.

Folgende Beispiele anhand einfach formulierter Regeln mögen dies verdeutlichen:

1. Einfache Regeln

REGEL 1

IF Wetter = warm
THEN Jahreszeit = Sommer

Wenn eine Schlußfolgerung und/oder Klausel ohne CNF geschrieben ist, wird von einem CNF = 1.0 ausgegangen.

REGEL 2

IF Wetter = warm
THEN Jahreszeit = Sommer (.75)

Diese Schlußfolgerung sagt, daß wenn das Wetter warm ist, eine 75%ige Sicherheit besteht, die Jahreszeit Sommer anzutreffen. Nach Regel 1 ist der CNF für die IF Klausel = 1.0. Um zu einem endgültigen CNF für eine Folgerung zu gelangen, werden die einzelnen CNF miteinander multipliziert:

1.0 * .75 = .75

Mit 75%iger Sicherheit ist also nach Regel 2 bei warmem Wetter Sommer.

REGEL 3

IF Jahreszeit = Sommer
THEN Feldarbeit = ja (.8)

Feldarbeit hat nun nach der Berechnung einen CNF von .6, da die IF Klausel bereits mit einem CNF von .75 aus Regel 2 besetzt ist:

.75 * .8 = .6

2. 'AND' Verknüpfungen in Regeln

Regel 4 und 5 zeigen den Einfluß von logischen Operatoren in der Prämisse:

REGEL 4

IF Wetter = warm
AND Himmel = wolkenfrei
AND Feuchtigkeitsgehalt im Korn < 16%
THEN Feldarbeit = Ernte

Wenn eine oder mehrere IF Klauseln einen CNF von weniger als 1.0 aufweisen und alle IF Klauseln durch den logischen Operator AND verbunden sind, wird der Folgerung der niedrigste CNF zugewiesen. Würden also den IF Klauseln 1 bis 3 jeweils CNF von 1.0, .6 bzw. .8 zugewiesen, hätte der endgültige CNF für "Feldarbeit = Ernte" den Wert .6.

3. 'OR' Verknüpfungen in Regeln

REGEL 5

IF Himmel = wolkenverhangen
OR Feuchtigskeitsgehalt im Korn > 16%
THEN Feldarbeit = nicht Ernte (.8)

Die allgemeine Formel zur Berechnung solcher CNF lautet:

CNF 1 + CNF 2 - (CNF 1 * CNF 2) = endgültiger CNF

Angenommen, die IF Klauseln hätten in der Regel 5 die Werte

Klausel 1 = CNF .6

Klausel 2 = CNF .7

wäre der endgültige CNF für "Feldarbeit = nicht Ernte" zu berechnen wie folgt:

.6 * .8 = .48

.7 * .8 = .56

.48 + .56 - (.48 * .56) = .7712

Hierbei ist bemerkenswert, daß der endgültige CNF höher ist als jeder der beiden Ursprünglichen. Dies ist logisch, da die Schlußfolgerung praktisch zweimal erhalten wurde, die Folgerung ist "gestärkt" worden und somit "mit größerer Sicherheit" wahr.

4. Kombination von mit Unsicherheit behafteten Schlußfolgerungen

Die letzten beiden Regelsätze veranschaulichen die Kombination von CNF in Schlußfolgerungen, zuerst der einfachere Fall:

REGEL 6

IF Himmel = strahlend blau
THEN Feldarbeit = Ernte (1.0)

REGEL 7

IF Wetter = sonnig
THEN Feldarbeit = Ernte (1.0)

Ein CNF für die IF Klausel der Regel 6 von .6 und von .4 für Regel 7 ergibt nach der Formel

.6 + .4 - (.6 * .4) = .76

eine Sicherheit von .76 dafür, daß bei strahlend blauem Himmel und bei sonnigem Wetter geerntet wird. Diese Berechnung ist in Abbildung 4 graphisch dargestellt (vgl. HARMON und KING, 1985, S.51). Durch das Hinzufügen des zweiten CNF von .4 nähert sich der endgültige CNF 40% mehr der "absoluten Sicherheit".

Das gleiche Ergebnis hätte aus der Zusammenfassung der beiden IF Klauseln und deren Verknüpfung mit einem logischen OR resultiert; die Verknüpfung mit einem logischen AND hätte allerdings ein anderes Ergebnis erzielt.

Hätte auch nur eine der beiden IF Klauseln, z.B. die erste, ein CNF von 1.0 gehabt, wäre natürlich auch die Schlußfolgerung nach diesem Regel-Konstrukt absolut sicher (CNF = 1.0) gewesen, denn:

1.0 + .4 - (1.0 * .4) = 1.0

Ein etwas komplizierterer Fall soll aus den Regeln 8 und 9 abgeleitet werden.

REGEL 8

IF Himmel = strahlend blau
AND Feuchtigkeitsgehalt des Korns < 16%
THEN Feldarbeit = Ernte (.8)

REGEL 9

IF Wetter = sonnig
AND Feuchtigkeitsgehalt des Korns < 16%
THEN Feldarbeit = Ernte (.8)

REGEL 10

IF Himmel = strahlend blau
OR Wetter = sonnig
AND Feuchtigkeitsgehalt des Korns < 16%
THEN Feldarbeit = Ernte (.8)

Angenommen, die CNF's für die drei IF Klauseln wären .5, .7 und .6, dann würde sich der CNF für die Folgerung der Regeln 8 und 9 berechnen nach(3):

.5 * .8 = .4

.6 * .8 = .48

.4 + .48 - (.4 * .48) = .69

Genauso würde auch der endgültige CNF für Regel 10 berechnet.

Die hier gezeigte Methode von CNF ist eine Vorgabe, ein SOLL, den bisher bei weitem nicht alle ESBT's erfüllen. HARMON bemerkt dazu: "Most small and mid-sized rule-based tools either lack confidence factors or implement them using standard probabilities, which makes them more undesirable if you are serious about using confidence factors" (HARMON et al., 1988, S.84). Dieser Umstand sollte bei der Auswahl eines geeigneten ESBT's zur Entwicklung eines Expertensystems beachtet werden (vgl. Kapitel 2.6 "Auswahl des geeigneten Tools ...").

In einigen Fällen können durch diese Art der Kombination CNF aus Schlußfolgerungen Probleme auftreten, da sich die endgültigen CNF's, ungeachtet ihrer Ausprägung, schnell asymptotisch dem Wert 1.0 nähern. Dies gilt insbesondere für Expertensysteme, in denen die endgültigen CNF's aus mehreren bis vielen Regeln zusammengesetzt sind. Dieses Problem veranschaulicht Abbildung 5.

In der Praxis kann dieser Fall weitgehend vermieden werden, insbesondere wenn der Wissensingenieur sich des Problems bewußt ist und dies bei der Konstruktion der Wissensbasis berücksichtigt.

Schon die hier verwendeten, sehr eingeschränkten Beispiele zeigen, daß die Berücksichtigung von Unsicherheit sehr schnell zu komplexeren Berechnungen führt, mangelnde Übersicht wäre in konventionellen Programmen die Konsequenz davon. Durch den Gebrauch von Regeln in der hier gezeigten Art und eines geeigneten ESBT's bleiben selbst kompliziertere Systeme überschaubar.

Die Abstufung der CNF braucht nicht besonders fein zu sein. Untersuchungen (vgl. DAVIS, 1986, S.958) haben gezeigt, daß eine grobe Abstufung, wie z.B. definitiv (1.0), fast sicher (.8), wahrscheinlich (.6), vielleicht (.4), wahrscheinlich nicht (.2) genügen, um Situationen einzuschätzen, dies ist mit Rücksicht auf den Anwender solcher Systeme ein nicht zu unterschätzender Faktor. Darüber hinaus kann so das ohne Zweifel vorhandene Risiko der Zuordnung unterschiedlicher Wahrscheinlichkeiten verschiedener Personen bei gleichen Sachverhalten vermindert werden.

Ob der offensichtlichen Problematik der Verwendung von CNF wird teilweise vorgeschlegen, ganz auf den Gebrauch von Wahrscheinlichkeiten zu verzichten (vgl. etwa PEDERSEN, 1989a, S.55). Dieser radikale Ausweg ist allerdings ebensowenig sachdienlich wie der übertriebene Gebrauch von CNF. Unabhängig von dieser Diskussion ist weiter unten (anhand der Exponentialgleichungen als Grundlage der Kalkulation von Konfidenzfaktoren in FARMEXPERT, Kapitel 5.2.2.3.1) gezeigt, daß der sinnvolle Gebrauch von CNF auch vollkommen ohne subjektive Beurteilungen seitens des Anwenders möglich ist.

Als generelle Leitlinie kann also nicht gelten, den Gebrauch von Wahrscheinlichkeiten von vornherein zu verdammen, sondern lediglich nur soviel probabilistisches Schließen wie nötig Anwendung finden zu lassen.

2.1.1.2.3 Arten von regelbasierten Systemen

Es gibt zwei Klassen von regelbasierten Systemen, die direkten Einfluß auf die Art der "Wissensspeicherung" in der Wissensbasis haben: Einfache regelbasierte Systeme und strukturierte regelbasierte Systeme (vgl. HARMON et al., 1988, S.47). Beide machen Gebrauch von IF-THEN-Regeln, wobei erstere bis zu 500 Regeln handhaben können, die alle in einer unbestimmten Reihenfolge geschrieben sein können und im Gegensatz zu den strukturierten regelbasierten Systemen keine Struktur aufweisen bzw. keine Unterstützung einer bestimmten, strukturierten Art der Programmierung aufweisen.

Die zweite Kategorie weist diese Möglichkeit auf, bietet sogenannte "Context Trees" als Hilfe (d.h., daß die Regeln als separate Gruppen (Contexts) arrangiert sein können), verfügt über weitergehende Möglichkeiten, CNF zu verarbeiten und kann "multiple instantiation" handhaben (d.h., daß eine Regel während eines Expertensystemlaufs nach Maßgabe einer übergeordneten Regel mehrmals mit unterschiedlich besetzten Variablen benutzt werden kann). Insbesondere durch die Möglichkeit der Regelanordnung in Untergruppen unterstützen solche Systeme bis zu 3000 Regeln oder auch mehr, je nach Computertyp.

2.1.1.2.4 Vor- und Nachteile

Im Gegensatz zu den induktiven Systemen muß der Wissensingenieur bei den regelbasierten Systemen genau über den Weg der Entscheidungsfindung informiert sein und diesen in einem Regelwerk nachvollziehen. Obwohl durch flexible Regeln (multiple instantiation) und den Gebrauch von CNF (Einbezug der Komponente "Unsicherheit") bereits eine Vielzahl von komplizierteren Problemen befriedigend gelöst werden können, sind diese Systeme nicht für sehr komplexe Sachverhalte geeignet.

Vorteilhaft ist die gute Überschaubarkeit (nah an der Alltagssprache) und die relativ leichte Erlernbarkeit dieser Art der Wissensrepräsentation. Die Modifikation solcher Expertensysteme bereitet im allgemeinen keine Probleme, der Inhalt der Wissensbasis ist in einer, dem Menschen sehr vertrauten Form, dargestellt. Schwierigkeiten können allerdings mit unstrukturierten Systemen auftreten, oder wenn die Zahl der verwendeten Regeln sehr groß ist (3000 und mehr).

2.1.1.3 Frames

2.1.1.3.1 Frame Based Systems

Frame Based-(4) oder auch "Object Oriented Systems" stellen sowohl an den Programm-Entwickler, den Wissensingenieur, als auch an die Hardware die höchsten Ansprüche der drei diskutierten Methoden. Die Werkzeuge (Tools), die sich bei der Entwicklung von Expertensystemen auf die Darstellung von Wissen mit Frames/Objects stützen, werden als "Hybrid Tools" bezeichnet. Ihnen gehört ohne Zweifel die Zukunft (vgl. HARMON et al., 1988, S.142), denn sie erlauben die eleganteste und flexibelste Wiedergabe von Wissen in computerverständlicher Form. Die Methode dieser Art von Wissensdarstellung an sich ist einfach, wenn auch abstrakt, wird aber mit zunehmender Komplexität des Sachproblems komplizierter. Die folgenden Ausführungen stützen sich im wesentlichen auf HARMON (HARMON et al., 1988, S.142 ff.).

Das Frame-Konzept wurde in den siebziger Jahren von MINSKY entwickelt: "A Frame is a data structure for representing a stereotyped situation, like being in a certain kind of living room, or going to a child's birthday party. Attached to each frame are several kinds of information. Some of this information is about how to use the frame. Some is about what one can expect to happen next. Some is about what to do if these expectations are not confirmed" (WATERMAN, 1986, S.75).

Ein Frame kann im weitesten Sinne mit einem Aktenordner oder einer Karteikarte verglichen werden. Er hat einen Namen und enthält Informationen und evtl. Verweise über das benannte Objekt. Abbildung 6 zeigt einen typischen Frame. Slots können, wie Attribute eines OVA-triplets, Werte speichern, sie können vorbesetzte Werte enthalten (default values), Zeiger zu anderen Objekten, Sätze von Regeln (wie etwa bei regelbasierten Systemen zu finden) oder auch Prozeduren (Kommandofolge, etwa um Werte von Variablen zu bestimmen). Die Slots stellen gewissermaßen Schnittstellen zu anderen Frames dar.

Diese Art der Wissensdarstellung setzt voraus, daß ein Satz von Objekten (Childs) eine Unterklasse eines anderen Objektes (Parent) ist. Diesen Sachverhalt versucht Abbildung 7 zu verdeutlichen. Ein spezifisches Objekt erhält (inherits) seine Information von anderen spezifischen Objekten. Wie die Abbildung zeigt, hat das allgemeine Objekt den Namen TRAKTOR mit der Beschreibung allgemeiner Eigenschaften. Abbilder dieses Objekts enthalten die gleichen Eigenschaften, sind aber mehr spezifisch, da die Werte konkrete Formen annehmen, wo angebracht entstehen die Objekte "FENDT" und "DEUTZ". Ein Abbild von DEUTZ stellt ein nächstes Objekt dar: OTTO'S DEUTZ.

Ein DEUTZ als allgemeines Objekt über OTTO'S DEUTZ besitzt einen Slot für Ausstattung mit 4 verschiedenen PS-Klassen, aber keiner speziell zugeordneten PS-Zahl. OTTO'S DEUTZ "erbt" (inherits) gewissermaßen diesen Slot des allgemeinen DEUTZ Objekts, hat aber jetzt eine bestimmte, einzigartige Ausstattung für diesen Slot:

180 PS

Ähnlich erbt OTTO'S DEUTZ Information vom Objekt EIGENTUM, welches mit OTTO'S DEUTZ in hierarchischer Beziehung steht, da diese Information nicht im allgemeinen Objekt DEUTZ zur Verfügung gestellt wird. Allen Variablen im Objekt OTTO'S DEUTZ sind nun spezifische Werte zugeordnet (Instantiation).

2.1.1.3.2 Vor- und Nachteile

Frames erlauben eine mannigfaltigere Präsentation von Wissen als etwa die OAV-triplets in den regelbasierten Systemen, die hier lediglich eine Untergruppe darstellen (Rules können auch in Frames implementiert werden). Der Preis dafür ist, daß sie erheblich komplexer und somit schwieriger zu entwickeln sind.

Ebenso wie bei den regelbasierten Systemen muß der Wissensingenieur ein gründliches Verständnis von dem zu beschreibenden System haben und des weiteren über ausreichende Kenntnisse in LISP und/oder PROLOG (bzw. anderen AI-Sprachen) verfügen.

Wegen der Flexibilität dieser Art der Wissensrepräsentation werden Frame Based Systems allerdings trotz der damit verbundenen Schwierigkeiten in der Zukunft eine bedeutende Rolle spielen.

2.1.2 Der Schlußfolgerungsmechanismus

Die grundlegende Strategie der Schlußfolgerung in Expertensystemen stellt in aller Regel die Verwendung der logischen Regel Modus Ponens dar, wie bereits bei der Definiton von Expertensystemen beschrieben. Modus Ponens entscheidet darüber, wie eine Schlußfolgerung innerhalb einer Regel aussehen wird.

Das Kernproblem, welches der Schlußfolgerungsmechanismus zu lösen hat, ist aber nicht nur das Vorgehen innerhalb einer Regel, sondern auch:

1) Es muß eine Entscheidung gefällt werden, wo der Standpunkt eines Expertensystemlaufes ist, m.a.W., welche Frage zuerst gestellt wird, welche Regel zuerst überprüft wird oder bei welchen Objekten (in Frame Based Systems) begonnen wird.

2) Es müssen Konflikte gelöst werden, die auftreten, wenn alternative Begründungsmöglichkeiten bestehen, d.h., wenn das Expertensystem einen Punkt erreicht, an dem gleichzeitig zwei oder mehrere Regeln (oder Objekte) betrachtet werden könnten. Es muß dann eine Entscheidung gefällt werden, welche Regel zuerst examiniert wird.

Folgendes Beispiel (in Anlehnung an HARMON und KING, 1985, S.54) versucht die geschilderten Probleme zu erklären: In Übersicht 2 ist eine Miniatur-Wissensbasis dargestellt, die sieben Regeln zum (sehr trivialen, aber zu Anschauungszwecken geeigneten) Problem "wie erreiche ich am besten ein Feld für einen Kontrollgang" enthält.

In einem Object-Attribute-Value oder auch Attribute-Value-System ist es üblich, ein generelles Ziel (Goal) zu definieren und dann im Laufe der Expertensystem-Sitzung dafür einen Wert zu erhalten. In der Beispiels-Wissensbasis können die Attribute "Distanz", "Zeit bis zum Mittagessen" und "Wetter" verschiedene Werte annehmen, wie eine Zahl für die ersten beiden Attribute und "Gut" bzw. "Schlecht" für das Attribut "Wetter". Der Zweck (Goal) des Mini-Expertensystems ist es, eine passende Aktivität aus vier "Aktions"-Möglichkeiten nach Maßgabe der Attributwerte herauszufinden.

Der Startpunkt für den Schlußfolgerungsmechanismus ist nun die Regel, die als erstes erlauben würde, das Goal "Aktion" zu besetzen, Regeln 4-7 kommen dazu in Frage; begonnen wird bei der ersten Regel dieser Sequenz, der Regel Nummer 4. Diese Regel besagt, daß "wenn die Fortbewegung 'fahren' entspricht und die Strecke über Feldwege führt, ein Traktor zu nehmen ist".

Modus ponens erlaubt diese Schlußfolgerung, wenn die Prämisse wahr ist. Die Prämisse der Regel 4 enthält allerdings zwei Attribute, deren Wert dem Schlußfolgerungsmechanismus unbekannt sind. Eine Strategie, die der Schlußfolgerungsmechanismus nun verfolgen könnte, ist das sogenannte Back- oder Backward Chaining (Rückwärtsverkettung). Diese gebräuchliche Methode startet - wie der Schlußfolgerungsmechanismus im Beispiel - bei der Regel mit dem Begründungsprozeß, in der zum erstenmal das generelle Ziel (hier: "Aktivität") gefunden und erklärt wird. Das erste in dieser Regel auftretende, unbekannte Attribut als Unterziel ist "Fortbewegung". Der Wert dieses Attributes gilt es als nächstes zu finden. Zur Ermittlung eines Wertes für dieses Attribut bieten sich Regel 1 bis 3 an, in deren Schlußfolgerung dem Attribut Fortbewegung jeweils einen Wert zuweist. Regel 1 testet den Wert des numerischen Attributes "Distanz". Da dieses Attribut in keiner anderen Regel mehr als Schlußfolgerung gefunden werden kann, wird hier der Benutzerdialog eingesetzt. Gesetzt den Fall, es würden 2 km angegeben, so ergibt die Überprüfung der ersten Regel, daß die Prämisse nicht wahr ist, somit kann (nach Modus Ponens) dem Attribut "Fortbewegung" hier kein Wert zugeordnet werden. Um zur Schlußfolgerung in Regel 2 zu gelangen, muß der Schlußfolgerungsmechanismus zuvor für das Attribut "Zeit-bis-zum-Mittagessen" einen Wert finden. Da auch dieses Attribut in keiner Schlußfolgerung der Mini-Wissensbasis mehr vorkommt, wird der Benutzer nach einem Wert gefragt, es seien hier 20 Minuten angenommen. Regel 2 besetzt nun das Attribut Fortbewegung mit dem Wert "Fahren", da die Prämisse erfüllt ist. An diesem Punkt muß nun der Schlußfolgerungsmechanismus entscheiden, ob sie den Begründungsprozeß mit Regel 4 fortsetzt, oder ob sie die Suche nach anderen Werten für das Attribut "Fortbewegung" fortsetzen soll. Dies hängt von der Natur des Attributes ab. Falls das Attribut definiert ist, mehr als einen Wert annehmen zu können, wird der Begründungsprozeß mit Regel 3 fortgesetzt, weil die Suche nach zusätzlichen Regeln, die einen Wert für "Fortbewegung" liefern könnten, weitergehen würde. Ist das Attribut definiert, nur einen Wert annehmen zu können, geht der Begründungsprozeß mit Regel 4 weiter. Dies sei für das Beispiel angenommen. Der Schlußfolgerungsmechanismus überprüft also die Prämisse der Regel 4 und stößt auf ein weiteres unbekanntes Attribut, welches in keiner Schlußfolgerung einer anderen Regel zu finden ist. Wiederum tritt der Benutzer in den Dialog ein, um anzugeben, daß keine Feldwege zu nehmen sind. So passiert die erste IF-Klausel der Regel 4, nicht aber die zweite, so daß auch diese Prämisse "Falsch" ist. In Regel 5 hingegen passieren alle beiden IF-Klauseln, das Oberziel "Aktion" erhält den Wert "Nehme Auto".

Angenommen, das Attribut "Aktion" wäre als "Mehrfachwert-Attribut" definiert, also mehrere Werte annehmen könnte (andernfalls wäre die Sitzung zu Ende, da das Ziel erfüllt ist), führte der Begründungsprozeß zur Regel 6, die allerdings versagen würde, genauso wie Regel 7; der Begründungsprozeß ist zu Ende, die Empfehlung für den Weg zum Feld ist "Nehme Auto", da für das Attribut "Aktion" keine anderen Werte mehr gefunden werden konnten.

2.1.2.1 Rückwärts- und Vorwärtsverkettung

Das Beispiel hat bereits exemplarisch gezeigt, wie der Schlußfolgerungsmechanismus sich "rückwärts" durch die Mini-Wissensbasis arbeitet. Die meisten Expertensysteme benutzen diese Strategie in ihrem Begründungsprozeß. Wenn die Zahl der möglichen Ergebnisse eines Expertensystemlaufes (die Zahl der möglichen Werte eines Multi-Value-Attributes) begrenzt und nicht zu hoch ist, dann ist die Rückwärtsverkettung sehr effizient. Rückwärtsverkettende Systeme werden oft auch "Goal-Directed-Systems" genannt. Im Gegensatz dazu steht die "Vorwärtsverkettung", die für den Fall, daß die Zahl der möglichen Ergebnisse groß ist, bessere Dienste leistet.

In vorwärtsverkettenden Expertensystemen werden, beginnend von der ersten Regel, alle Prämissen anhand der vorhandenen Informationen auf ihren Wahrheitsgehalt überprüft, bis die erste Prämisse passiert, also wahr ist. Diese Schlußfolgerung wird dann zu einer Faktenliste hinzugefügt (in der alle bisher gefundenen, wahren Schlußfolgerungen stehen), und das System beginnt von neuem mit der Überprüfung der Regeln von Regel 1 an. Solche Systeme werden oft auch als "Data-Driven-Systems" bezeichnet. Vorwärtsverkettung soll ebenfalls am Beispiel der Mini-Wissensbasis zur Arbeitsplanung illustriert werden.

Dem System liegen als Daten vor, - aus Demonstrationsgründen anders als im ersten Beispiel - daß die Distanz 6 Kilometer, die Zeit bis zum Mittagessen 20 Minuten beträgt und keine Feldwege zu erwarten sind. Die Überprüfung der ersten Regel ergibt "wahr", die zweite Regel passiert ebenfalls, aber keine der anderen Regeln mehr (tatsächlich werden alle Regeln überprüft, vgl. DAVIS, 1986, S.958). Da mehr als eine Regel passieren konnte, muß der Schlußfolgerungsmechanismus entscheiden, welche Schlußfolgerung welcher Regel in die Faktenliste eingefügt werden soll. Die bereits stillschweigend erwähnte Technik, in einem solchen Fall die erste der Regeln zu nehmen, ist gängige Praxis (vgl. HARMON und KING, 1985, S.56). Für das Attribut "Fortbewegung" wird also der Wert "Fahren" in der Liste gespeichert, der Zyklus beginnt von neuem. Anhand der gegebenen Daten (inkl. der in der Liste gespeicherten Werte) würden wiederum Regel 1 und 2, aber auch Regel 5 passieren. Gängige Praxis für diesen Fall ist, solche Regeln außer Betracht zu lassen, die bereits passiert haben, also Regel 1. Demzufolge wird als nächstes der Wert "Fahren" zu der Liste addiert. Im dritten Zyklus passieren wieder Regeln 1, 2 und 5, wobei nun Regeln 1 und 2 nicht beachtet werden, da sie ja bereits passiert haben. Der Wert "Nehme Auto" für das Goal "Aktion" wird in der Liste hinzugefügt, und da keine anderen Regeln in einem nächsten Zyklus aus dem vorhandenen Datenbestand mehr passieren könnten, ist die Empfehlung: "Nehme Auto".

Die Konflikte, die für den Schlußfolgerungsmechanismus in einem vorwärtsverkettenden System auftreten können, sind i.d.R. komplizierter als bei einem rückwärtsverkettenden System, das Beispiel, obwohl einfachster Natur, hat davon bereits einen Einblick gegeben. Dennoch gibt es Anwendungen, wo eine Art des Begründungsprozesses dem anderen vorzuziehen ist. Darüber entscheidet im wesentlichen der Suchraum für die Problemlösung. In Abbildung 8 sind zwei unterschiedliche Suchräume/Suchstrategien dargestellt.

In Spalte A sind eine Reihe von Attributen über Regeln mit einer endlichen Zahl von Schlußfolgerungen (Goals) verbunden. Solch ein Suchraum kann beispielsweise bei der Entscheidung für die beste Verwendungs- bzw. Vermarktungsmöglichkeit für Getreide auftreten. Hier würde eine begrenzte Zahl von Möglichkeiten (Goals) offenstehen, von denen die den Umständen entsprechend beste von dem Expertensystem zu finden wäre (vgl. z.B. "Grain Marketing Analysis with an Expert System", (THIEME et al., 1985), beschrieben in Kapitel 3.2.1.3).

In Spalte B ist ein Problem symbolisiert, dessen Goal zu Beginn der Expertensystem-Sitzung noch nicht konkret formuliert ist, d.h., es steht keine vorformulierte Lösung irgend einer Art a priori fest. Dies ist beispielsweise ein typisches Merkmal eines Planungsprozesses. Der endgültige Plan steht erst fest, wenn der Begründungsprozeß abgeschlossen ist. Da kein definiertes Goal feststeht, gibt es keine Möglichkeit für Rückwärtsverkettung, da (schon wieder) kein Startpunkt fixiert werden kann.

Solcherart Probleme werden also durch Vorwärtsverkettung gelöst. Des weiteren findet diese Technik auch für Überwachungsprobleme (Prozeßsteuerung / Prozeßregelung) Verwendung (vgl. HARMON und KING, 1985, S.57).

In vielen Fällen ist die Kombination beider Techniken die sinnvollste Lösung, tatsächlich wurden auch beide Methoden bei der Programmierung von FARMEXPERT implementiert.

2.1.2.2 Tiefensuche vs. Breitensuche

Neben Rückwärts- und Vorwärtsverkettung wird bei Expertensystemen zusätzlich nach der Richtung der Suche im Suchraum unterschieden. Wiederum bestehen zwei Möglichkeiten: Die Suche geht zuerst in die Tiefe (Depth First Search) oder die Suche geht zuerst in die Breite (Breadth First Search). In den meisten Fällen findet die erstgenannte Technik Anwendung. Diese Technik "gräbt" sich tiefer und tiefer in die Details eines Problems ein. Dabei ist die Art der Verkettung dafür verantwortlich, daß die Fragen, die von dem Expertensystem an den Benutzer gestellt werden, in einer sinnvollen Reihenfolge präsentiert werden. So würde beispielsweise ein Expertensystem zur Erfolgsanalyse eines landwirtschaftlichen Betriebes möglicherweise mit den Pflanzenbau betreffenden Fragen beginnen, immer detailliertere Antworten erwartend und erst nachdem alle notwendigen Informationen vorliegen, zur Tierproduktion übergehen. Ein Expertensystem, welches die Technik der "Breadth First Search" anwendet, würde möglicherweise Fragen aus pflanzlicher und tierischer Produktion gemischt stellen, die Fragen würden nach einem Zufallsprinzip gestellt aussehen. Dem Benutzer mag dies eher suspekt vorkommen. Diese Sachverhalte sind ebenfalls in Abbildung 8 verdeutlicht.

2.1.2.3 Monotoner vs. nicht monotoner Begründungsprozeß

Ein letztes Klassifizierungsmerkmal eines Schlußfolgerungsmechanismus ist die Fähigkeit zur Veränderung bereits gefundener Schlußfolgerungen. Falls alle bereits gefundenen Fakten oder Schlußfolgerungen wahr bleiben und keine Möglichkeit besteht, dies zu "überdenken" oder rückgängig zu machen, ist die Rede von "Monotonic Reasoning", die Menge an "wahrer" Information im System wächst stetig (monoton). Systeme hingegen, bei denen es möglich ist, die bisher gefundene Information in Frage zu stellen oder einem neuerlichen Bewertungsprozeß zu unterziehen und evtl. wahre Fakten als unwahr zu deklarieren (aufgrund neu hinzugekommener Information), werden als "Nonmonotonic Reasoning Systems" bezeichnet. Dieser Vorgang ist allerdings nur mit erheblichem Mehraufwand und u.U. großen Schwierigkeiten zu vollziehen. Zur Verdeutlichung sei nochmals die Mini-Wissensbasis dieses Kapitels herangezogen. Angenommen, die Empfehlung sei "Nehme Traktor" gewesen, spätere Informationen aber signalisieren, daß der Traktor für andere Aufgaben nötiger gebraucht wird, müßte der Schlußfolgerungsmechanismus alle betroffenen Regeln zurückverfolgen und die Schlußfolgerungen revidieren. Bedingt durch die Komplexität dieses Vorgangs ist diese Technik selten in der Praxis zu finden. Hingegen gibt es häufiger die Möglichkeit, die Werte eines einzelnen Attributes zu ändern und gleichsam zu simulieren "Was wäre, wenn".

2.1.3 Schnittstelle zum Programmentwickler

Dieser Bestandteil eines ESBT's wird (lediglich) zur Programmentwicklung, der Kreation der Wissensbasis und zur Programmpflege benötigt. Dennoch wird bereits hier der Grundstein zur erfolgreichen Entwicklung eines Expertensystems gelegt.

Die Entwicklung und das Design der Wissensbasis wird entweder mit einem in dem ESBT integrierten oder externen Programmeditor oder Textbearbeitungssystem vollzogen. So ist auch eine große Zahl von Regeln relativ schnell zu editieren. Die zur Verfügung gestellten Programmeditoren spielen eine nicht zu unterschätzende Rolle für die Leistung des Programmentwicklers bei der Erstellung sowie der Modifikation der Wissensbasis. Ein maßgeblicher Teil dieses Prozesses besteht in Kopier- und Suchen/Ersetzen-Vorgängen. Diesbezüglich schwache (eingebettete) Editoren erschweren und verlangsamen die Arbeit erheblich. Aus diesem Grund sollte in jedem Fall die Möglichkeit bestehen, externe Editoren für die Erstellung bzw. Modifikation der Wissensbasis benutzen zu können.

Neben einem mehr oder weniger den Programmentwickler unterstützenden Hilfe-System ist die Möglichkeit des Zurückverfolgens von Begründungswegen (Inference Tracing) von ausschlaggebender Bedeutung. Dies kann sehr wichtig sein, wenn das Expertensystem während der Programmentwicklung zu unvorhergesehenen Schlußfolgerungen gelangt. Der Weg des Schlußfolgerungsmechanismus ist auf dem Papier nur schwer nachzuvollziehen, so daß hier die Unterstützung von dem ESBT Voraussetzung für eine zeitsparende Programmentwicklung ist. Eine wertvolle Hilfe für die Programmentwicklung kann die Ermöglichung des Anlegens einer "Fallstudien-Bibliothek" sein. Dies ist hilfreich, um nach einer Modifikation bzw. Erweiterung der Wissensbasis zu prüfen, ob bereits korrekt gelöste Probleme (Fälle) noch zu den gleichen Ergebnissen wie vor der Änderung gelangen.

Weiterhin ist die Fähigkeit des ESBT's, "Wie" und "Warum" Fragen (vgl. Kapitel 2.1.5.4 "'Wie', 'Warum', ...") zu beantworten auch für den Programmentwickler von Bedeutung. Daneben spielen noch einige technische Merkmale, wie Unterstützung bei der Bildschirmgestaltung, eine Rolle für die Beurteilung der Schnittstelle zum Programmentwickler.

2.1.4 Schnittstelle zu anderen Programmen und dem Betriebssystem: Die Frage nach den "Interfaces"

Diese außerordentlich bedeutsame Komponente ist in den Anfängen der AI/ES- Entwicklung wenig bis überhaupt nicht beachtet worden. "...access to Databases, so fundamental now ..., was not forseen as a customer need by early AI researchers" (MARTONELLI, 1988, S.60). Es hat sich allerdings immer deutlicher herauskristallisiert, daß Expertensysteme nicht isoliert zu betrachten sind. Heute sind Schnittstellen (Interfaces) zur "Außenwelt", insbesondere zu Datenbanken, mit das wichtigste Beurteilungskriterium für ESBT's. Es wird sogar von der "Ehe" zwischen AI und Datenbanktechnologie gesprochen (vgl. HARRIS, 1987). "One of the promising applications of the AI with the database component is the use of natural language interface in conjunction with a database management system" (HARSH, 1988, S.6). Dieser Aspekt dürfte auch für Anwendungen in der Landwirtschaft eine große zukünftige Bedeutung haben. Der Gebrauch solcher Eigenschaften, beispielsweise eines Expertensystems mit Datenbankverbindung, erlaubt dem Benutzer Sofortabfragen, etwa von Preisinformationen, in einem der natürlichen Sprache entsprechenden Dialog. Doch nicht nur Datenbankabfragen können so vereinfacht werden, die Entwicklung von Expertensystemen ist durch die Verbindung zu externen Programmen, insbesondere Datenbanken, erheblich vereinfacht worden. Alles veränderliche Wissen, alle veränderlichen Fakten, können in einer Datenbank gespeichert werden, wohingegen die eigentliche Wissensbasis nur noch die "Heuristics", etwa in Form von Regeln, enthalten muß. Dies geht bereits soweit, daß in Verbindung mit Expertensystemen nicht mehr von "data base", sondern "information base" und nicht mehr von "knowledge base", sondern von "rule base" gesprochen wird; zusammen erst wird so die Wissensbasis definiert (vgl. MOOSE und SHAFER, 1987, S.5-4).

Neben dieser, gerade auch für die Agrarwissenschaften bedeutsamen Entwicklung ist wiederum für landwirtschaftliche Anwendungen - wie Prozeßüberwachung und -kontrolle - die Schnittstelle zu Sensoren und Aktoren von Bedeutung (vgl. dazu etwa einige der in Kapitel 3.2 beschriebenen Anwendungen von Expertensystemen in der Landwirtschaft). Verbindungen zu anderen Programmiersprachen können mathematische Operationen mit Expertensystemen sehr erleichtern, wie auch die Anwendung eines Expertensystems als "front-end" zu einem bereits bestehenden Programm, etwa einem Simulationsprogramm.

2.1.5 Schnittstelle zum Endbenutzer

Die Funktionalität und der Gebrauchswert eines fertig entwickelten Expertensystems wird größtenteils von der Benutzeroberfläche bestimmt. Eine Übersicht der wichtigsten Merkmale von Expertensystem-Benutzerschnittstellen stellt Abbildung 9 dar. Diese Merkmale sind in den folgenden Kapiteln näher beschrieben.

2.1.5.1 Antwortmöglichkeiten auf Programmfragen

Prinzipiell ist dieser Teil des Dialoges über Menues (wie bei konventionellen Programmen) oder direkte Texteingabe denkbar. Menues können benutzerfreundlicher und schneller sein, während teilweise freie Texteingabe der Natur der AI eher entspricht. Texteingabe kommt insbesondere für Datenbankabfragen in Betracht, wo ein Expertensystem als intelligentes Front-End-System auf eine Datenbank aufgesetzt ist. Es sollte allerdings nicht übersehen werden, daß freie Texteingaben für den Programmanwender ermüdend sein können und einen erheblich höheren Programmierungsaufwand erfordern.

2.1.5.2 Akzeptanz von Mehrfach- und mit Unsicherheit behafteten Antworten

Die Fähigkeit eines Expertensystems, Mehrfachantworten zu akzeptieren, ist eng verwandt mit der Möglichkeit, auch Antworten mit "Unsicherheit" zu behaften. Tritt beispielsweise der Fall ein, daß der Benutzer auf eine Frage des Expertensystems zu entscheiden hat, ob er für einen bestimmten Schlag die Erntereste einarbeiten oder auf der Oberfläche belassen wird, der Anwender sich dessen aber noch nicht sicher ist, ist es eines der hervorragenden Merkmale guter Expertensysteme, genau diese Unsicherheit zu akzeptieren und trotzdem zu einer (natürlich auch mit einer bestimmten Unsicherheit behafteten) Schlußfolgerung zu gelangen. Das Expertensystem muß also in der Lage sein, etwa eine Antwort wie "Erntereste einarbeiten 70%, Erntereste nicht einarbeiten 30%" oder sogar ein "Ich weiß noch nicht" zu verarbeiten. Die meisten Probleme, die ein gewisses Maß an Urteilsvermögen verlangen, sind mit solchen Unsicherheiten behaftet und somit idealerweise zur Bearbeitung durch ein Expertensystem prädestiniert.

2.1.5.3 Grafik

Grafik ist wünschenswert zur Verdeutlichung komplexer Sachverhalte. Grafik ist schwierig in ein Expertensystem selbst zu integrieren, eine Möglichkeit stellt die Verbindung zu externen Programmen (vgl. Kapitel 2.1.4) dar. Eine andere Anwendung bietet sich in der grafischen Darstellung des Begründungsprozesses auf die Frage an: "Wie ist diese Schlußfolgerung erreicht worden?", indem etwa alle bisher erfolgreich durchlaufenen Regeln angezeigt werden.

2.1.5.4 "Wie", "Warum" und "Was wäre, wenn..."

Insbesondere die Fähigkeit des Expertensystems zur Klärung der Benutzerfragen "Wie ist diese Schlußfolgerung erreicht worden?" und "Warum wird diese Frage (jetzt) gestellt?" ist von ausschlaggebender Bedeutung für die Akzeptanz und das Vertrauen des Anwenders in das System. In vielen Fällen werden hierzu einfach die Regeln gezeigt, die zu einer bestimmten Schlußfolgerung geführt haben, oder ein vom Programmentwickler bereitgestellter Text eingeblendet. Diese Texte sollten wegen ihrer Bedeutung sehr sorgfältig formuliert werden.

Die Antwort des Expertensystems auf die Frage "Was wäre, wenn..." zeigt, wie das Systemverhalten gewesen wäre, wenn der Wert einer bestimmten Variablen geändert würde (vgl. Kapitel 2.1.2.3). Somit kann in begrenztem Umfang Systemverhalten "simuliert" werden.

2.1.5.5 Eingrenzung des Suchraumes

Ein nicht unwesentlicher Beitrag zur Benutzerfreundlichkeit kann die Begrenzung des Suchraums (Search Space) auf die Lösungen bedeuten, die der Anwender für relevant hält. Auf diese Weise lassen sich Fragen des Expertensystems vermeiden, die nicht zur Lösung des Problems beitragen würden. Ein Expertensystem zur ökonomischen Analyse eines landwirtschaftlichen Betriebes könnte so auf Anwenderwunsch lediglich auf die Schweinemast beschränkt werden, ohne daß die Notwendigkeit besteht, auch alle anderen Betriebszweige zu analysieren. Falls solche Möglichkeiten fehlen, somit überflüssige Fragen beantwortet werden müssen, kann dies die Nutzung und Akzeptanz eines Expertensystems erheblich einschränken.

2.2 Funktionelles Potential von Expertensystemen

Die auch als "Consultation Paradigm" (HARMON und KING, 1985, S.92) bezeichnete Konzeptualisierung von Expertensystem-Anwendungen, behandelt die prinzipielle Art von Problemen, für die Expertensysteme geeignet sind. Die Bezeichnung dieser Problemklassen ist unabhängig von der spezifischen (Wissenschafts-)Disziplin, in der Expertensysteme Anwendung finden. So ist eine dieser Problemklassen als "Diagnostic/Prescription" bezeichnet, was ursprünglich aus der Medizin stammt. Dessen ungeachtet finden sich solche Diagnose-/Therapieprobleme auch in vielen anderen Bereichen, so kann etwa die Schwachstellenanalyse eines landwirtschaftlichen Betriebes als Diagnoseproblem angesehen werden.

In der Literatur existieren mannigfaltige Ansätze, Aufgaben bzw. Funktionen von Expertensystemen zu charakterisieren. HARMON nennt drei klar identifizierte Aufgabenbereiche: "Diagnosis/Prescription (alternative Bezeichnung: Structured Selection, Classification)", "Planning (alternative Bezeichnung: Constraint Satisfaction)" und "Design (alternative Bezeichnung: Discovery)" (HARMON und KING, 1985, S.94) und erweitert diese Liste um sieben weniger erforschte Bereiche. STEFIK beschreibt sechs abgegrenzte Funktionen von Expertensystemen: "Interpretation, Diagnosis, Monitoring, Prediction, Planning, Design" (STEFIK et al., 1983, S.83 ff.), GEVARTER unterscheidet deren 13 (1987, S.29 ff.), HAYES-ROTH unterscheidet 10 verschiedene Funktionen (HAYES-ROTH et al., 1983, S.14) und in dem Bericht der Enquete Kommision zu Chancen und Risiken des Einsatzes von Expertensystemen werden sieben vordergründige Aufgabenbereiche von Expertensystemen aufgezählt (DEUTSCHER BUNDESTAG, 1990, S.19). Es besteht somit keine einheitliche Auffassung spezifischer Funktionen von Expertensystemen. Dennoch lassen sich bestimmte Trends herausfiltern, die in Übersicht 3 zusammengefaßt sind.

2.3 Expertensysteme vs. konventionelle Programme

Die mannigfaltigen Funktionen, die von Expertensystemen ausgefüllt werden können, zeigen bereits die oberflächlichen Unterschiede zwischen den beiden Programmtypen. Die wichtigsten Unterschiede sollen im folgenden weiter ausgeführt werden.

Die Erörterung der Unterschiede soll mit einer Gemeinsamkeit beginnen: "A standard program can do everything, an artificial intelligence program can do, but it cannot be programmed as easily or as quickly" (LEVINE et al., 1986, S.4).

Diesen - eben zitierten - Sachverhalt auf die weiter oben als Beispiel verwendete Mini-Wissensbasis übertragen bestätigt, daß ein "konventioneller Programmierer" ohne weiteres ein Programm, beispielsweise in FORTRAN schreiben könnte, das sich an der Benutzeroberfläche genauso verhalten und zu den gleichen Resultaten (vgl. MISHKOFF, 1986, S.7-17, HARMON und KING, 1985, S.185) kommen würde, wie das kleine Expertensystem aus Kapitel 2.1.2. Er würde allerdings große Schwierigkeiten haben, ein Programm zu entwickeln, welches es erlaubt, jede beliebige Regel einzugeben, Fragen zu stellen und die richtigen Schlußfolgerungen zu erreichen (was dann einem ESBT gleich käme).

Diesem Umstand ist es zuzuschreiben, daß Probleme, die mit ESBT's relativ einfach zu handhaben sind, mit konventionellen Programmiersprachen bisher nicht in Angriff genommen wurden, da dies einen nicht zu rechtfertigenden Aufwand nach sich gezogen hätte. Es ist daher gerechtfertigt, von grundlegenden, von der Vernunft regierten Unterschieden zu reden.

Ein Beispiel für die grundlegenden Differenzen, vielleicht das wichtigste, ist, daß in konventionellen Programmen alle notwendige Information zur Verfügung gestellt wird, bevor überhaupt Berechnungen beginnen können. Es macht keinen Sinn, Aktiva und Passiva einer Bilanz ausgleichen zu wollen, wenn Daten fehlen oder nicht exakt vorliegen. Für AI-Programme, oder hier spezieller für Expertensystem-Programme, gelten diese Voraussetzungen nicht notwendigerweise. Es würde auch niemand versuchen, mit einem Expertensystem eine Bilanz aufzustellen. So wie Berater typischerweise ihre Expertise gerade in Fällen mit unvollständiger oder unsicherer Information abgeben müssen, so ist es die Aufgabe des Schlußfolgerungsmechanismus (oder des Expertensystems als Ganzes), mit fehlender oder unsicherer Information fertig zu werden. Dies geschieht, indem unsichere oder fehlende Information nach Maßgabe einer vom Programmentwickler zu wählenden "Wahrheitsschwelle", die Prämisse einer Regel "unwahr" setzt, falls die vorhandene Information für den Begründungsprozeß nicht ausreicht. Expertensysteme können Unsicherheit allerdings nur prinzipiell handhaben, für den konkreten Fall muß der Programmentwickler, auch für den Fall fehlender bzw. unsicherer Information, Regeln vorsehen.

Dadurch, daß Expertensysteme in der Lage sind, unsichere Information zu verarbeiten, wird die Bearbeitung einer neuen Dimension von Problemen möglich, die konventioneller Programmierung weitgehend verschlossen war.

WATERMAN unterscheidet, wie in Übersicht 4 dargestellt, zwischen "Data Processing" und "Knowledge Engineering", um die verschiedenen Merkmale zu zeigen. Obwohl die Übersicht für sich selbst spricht, soll der wesentliche Unterschied zwischen der Verwendung von Algorithmen und Heuristik noch eingehender betrachtet werden. Während Heuristik weiter oben bereits behandelt wurde, wird in Übersicht 5 der Unterschied zwischen Heuristik und Algorithmus an einem Beispiel herausgearbeitet.

Nicht nur die Art der Problemlösung unterscheidet sich beträchtlich; in konventionellen Programmen ist das Wissen über ein Problem und die Prozeduren dieses Wissens zu manipulieren sowie das Problem zu lösen im Programmcode gemischt (aus diesem Grund ist es oft schwer, einen nicht selbstgeschriebenen Programmcode nachzuvollziehen). In Expertensystemen ist das Wissen von den Prozeduren zur Problemlösung (Schlußfolgerungsmechanismus und Programmablaufkontrolle) voneinander getrennt. Dies erleichtert die Programmierarbeit erheblich, die Konzentration kann somit auf das Wesentliche gerichtet bleiben. Nachteilig sind die etwas höheren Ansprüche der Expertensysteme an Hard- und Software, die aber immer leichter von rasant fortschreitender Computertechnologie erfüllt werden können.

Die Konzentration auf das Wesentliche wird zusätzlich erleichtert durch den praktischen Gebrauch von Prototyp-Systemen. Bedingt durch den Umstand, daß die Lösung oder der Weg zum Ergebnis beim Design eines Expertensystems im voraus selten oder nie bekannt ist, müssen vorläufige Näherungen an die Problemlösung (Prototypen) immer wieder begutachtet, mit dem tatsächlichen Expertenverhalten verglichen, diskutiert und überarbeitet werden.

Diese "sukzessiven" Prototypen führen schließlich zu einem System mit allen gewünschten Eigenschaften. Dieser Prozeß bringt einen weiteren Vorteil mit sich: Ein Expertensystem kann wesentlich früher in die praktische Anwendung gehen als ein konventionelles Programm. Es kann bereits einen Gebrauchswert haben, wenn es lediglich 30-50% der endgültigen Kapazität aufweist, der frühe Feedback von einer (kleinen) Gruppe von Anwendern kann sehr effizient sein und viel Entwicklungszeit sparen. Ganz konkret: Praktizierende Landwirte können als Endbenutzer bei der Entwicklung von Expertensystemen schon sehr frühzeitig mit einbezogen werden und so die Wissensbasis mit evtl. fehlendem Wissen ergänzen helfen. Schließlich ist ein weiterer Vorteil früher Prototypen, daß nicht nur das Potential, sondern auch die Limits früh erkannt werden und die Programmentwicklung gestoppt oder in andere Wege geleitet werden kann, bevor eine Menge an Ressourcen verbraucht worden sind.

Dem gegenüber steht die Warnung HAUSCHILDT's, einen Prototypen zu früh aus dem Computerlabor zu entlassen: "Ein System, das man bewußt als 'unreif' einführt, wird mangels Vertrauen gar nicht erst genutzt" (HAUSCHILDT, 1990, S.526).

Expertensysteme machen Fehler. Auch konventionelle Programme machen Fehler, aber dies sind dann "bugs", also Programmierfehler, die beseitigt werden müssen. Expertensysteme, einwandfreie Programmierung vorausgesetzt, machen Fehler, die keine "bugs" sind, sie treten ebenso auf wie menschliche Experten Fehler machen. Eine Problemlösung, die auf teilweise unsicheren Daten beruht, läuft in Gefahr, falsch zu sein. Gerade das ist die neue Dimension, die mit Expertensystemen erschlossen wird: Probleme werden computerzugänglich, deren Lösung früher mit Hilfe eines Computers schwerlich möglich war.

2.4 Expertensysteme vs. wissensbasierte Systeme

Wissensbasierte Systeme werden oft mit Expertensystemen mehr oder weniger eng in Verbindung gebracht.

In der Literatur herrscht bezüglich der Abgrenzung Expertensysteme vs. wissensbasierte Systeme (Knowledge Based Systems) oder Wissenssysteme (Knowledge Systems) eine Definitionenvielfalt. Oft ist auch von "Knowledge Based Expert Systems" die Rede (vgl. HARMON und KING, 1985, S.5 und S.34). Für HARMON und KING stellen die Begriffe "Expert System" und "Knowledge System" (die Autoren benutzen "Knowledge System" als Synonym zu "Knowledge Based System") eine Untermenge von "Knowledge Based Expert Systems" dar. "Expert Systems" werden als die umfassenderen Systeme betrachtet, wohingegen "Knowledge Systems" als weniger mächtig angesehen werden (HARMON und KING, 1985, S.177 und HARMON et al., 1988, S.7). Somit enthalten nach dieser Definition wissensbasierte Systeme weniger umfassendes Sachgebietswissen und insbesondere weniger Heuristik als Expertensysteme.

WATERMAN (1986, S.18) stellt diesen Zusammenhang in ein anderes Licht. Für ihn sind wissensbasierte Systeme umfassender als Expertensysteme, letztere stellen immer eine Untermenge dar, wie in Abbildung 10 skizziert.

So ist der Umkehrschluß nach WATERMAN nicht immer zulässig. Nicht alle wissensbasierten Systeme sind notwendigerweise Expertensysteme! Dennoch weisen beide Arten von Systemen nach der Mehrzahl amerikanischer Autoren wenigstens eine wichtige Gemeinsamkeit auf: Das inkorporierte Sachgebietswissen, abgebildet in der Wissensbasis, ist immer vom restlichen System (Kontroll- und Schlußfolgerungsmechanismen) getrennt.

Wenn auch andere Autoren oft nicht explizit zwischen Expertensystemen und wissensbasierten Systemen unterscheiden (vgl. etwa LENAT et al., 1983, S.219), so sind doch in den allermeisten Fällen nichtkonventionelle (d.h. nichtprozedurale) Systeme Gegenstand der Betrachtung, also Systeme, bei deren Erstellung entweder eine symbolische Programmiersprache (OPS5, PROLOG, ...) oder eine Expert System Shell (Insight 2+ (heute LEVEL 5), Personal Consultant, ...) zur Programmentwicklung gedient hat. DAVIS (1986, S.959) macht hier eine Ausnahme: In seinen Augen können auch eher als konventionell anzusehende Programme sehr wohl auf die Ebene wissensbasierter Systeme gestellt werden. Er führt dazu Arbeitsblätter (Templates) von Tabellenkalkulationsprogrammen an, die ganz sicher nicht mittels einer symbolischen Programmiersprache oder einem ESBT erstellt werden, aber dennoch Sachgebietswissen enthalten (in Form von mathematischen, Beziehungen ausdrückenden Formeln), welches sehr wohl von dem zugrundeliegenden, im Hintergrund arbeitenden Kontrollmechanismus getrennt ist.

LEVINE et al. (1986) gehen sogar noch einen Schritt weiter, indem sie zur Erstellung von Expertensystemen (die Autoren treffen keine Unterscheidung bezüglich wissensbasierter Systeme) mittels der Programmiersprache BASIC anleiten. Spätestens hier wird die Forderung nach Trennung des Sachgebietswissens von den Kontroll- und Schlußfolgerungsmechanismen nicht mehr zu erfüllen sein.

Allen Autoren gemeinsam jedoch ist, daß wissensbasierte Systeme immer eine "problem domain" behandeln bzw. "domain knowledge" beinhalten (vgl. etwa WATERMAN, 1986, S.18 oder DAVIS, 1986, S.957: "The term knowledge-based is primarily a label for ... the source of the system's power: task-specific knowledge, rather than the domain-independent methods ...").

Nach den bisherigen Ausführungen werden zumindest zwei Aspekte deutlich. Zum einen ist dies die Abgrenzung zwischen wissensbasierten Systemen und solchen, die nicht als wissensbasierte Systeme angesehen werden dürften. Demnach würde etwa ein Programm zur linearen Programmierung oder eine Finanzbuchhaltung kein wissensbasiertes System darstellen, denn solche Programme enthalten a priori kein Sachgebietswissen, sie sind vielmehr unabhängig von einem speziellen Sachgebiet einzusetzen, da sie über eher generelle Problemlösungsmechanismen, wie etwa den Simplex-Algorithmus, verfügen.

Zum anderen wird gerade am letzten Beispiel klar, daß der Begriff "wissensbasierte" Systeme nicht wirklich geeignet ist, die oben gezeigte Abgrenzung deutlich zu machen; denn auch hinter dem zitierten Simplex-Algorithmus verbirgt sich "Wissen", was aber aus einem Programm zur linearen Programmierung noch kein wissensbasiertes System werden läßt. Zur klareren Begriffsbestimmung spricht KUHLMANN (1988, S.750) von "sachwissensbasierten" Systemen. Um allerdings den gewünschten Sachverhalt exakt im Sinne der Bedeutung zu umreißen, müßte eigentlich von "sachgebietswissensbasierten" Systemen gesprochen werden. Hierbei jedoch erscheint die Wortschöpfung hinsichtlich des Sprachgebrauchs etwas unglücklich, so daß im weiteren Verlauf dieser Arbeit von wissensbasierten Systemen gesprochen werden soll, ohne aus den Augen zu verlieren, daß eigentlich sachgebietswissensbasierte Systeme gemeint sind.

Abbildung 11 macht den Versuch, die eben dargelegte Definition von wissensbasierten Systemen noch einmal zu verdeutlichen.

Heute zeichnen sich deutlich zwei Hauptgruppen von wissensbasierten Systemen ab, regelbasierte Systeme zum einen und funktionenbasierte Systeme zum anderen, wobei hier schon darauf hingewiesen sei, daß auch eine Vermischung beider Konzepte möglich ist. Solche Systeme werden dann als hybride Systeme bezeichnet (CARRICO et al., 1989, S.63, GUM und BLANK, 1990, S.540).

Die Vor- und Nachteile sowie an zwei Beispielen veranschaulichte Unterschiede zwischen funktionenbasierten und regelbasierten Systemen sind ausführlicher dargestellt bei WAGNER (1990).

2.5 Grundlagen für die Entwicklung von Expertensystemen

Bevor an die Entwicklung eines Expertensystems gedacht wird, sollte die Frage beantwortet werden: Ist ein Expertensystem das geeignete Mittel zur Lösung meines Problems? Die Entwicklung eines Expertensystems sollte nur in Betracht gezogen werden, wenn die Entwicklung
- möglich,
- gerechtfertigt und
- geeignet

ist. So leicht diese Forderung gestellt ist, so schwierig ist diese Frage zu beantworten. WATERMAN stellt heraus, daß selbst AI-Wissenschaftler es als schwierig erachten, generelle Richtlinien zu erarbeiten, die ein Urteil zulassen, ob ein Expertensystem das geeignete Werkzeug für eine Problemlösung ist. Oft sei es einfacher, anhand des konkreten Problems ein Urteil zu fällen. WATERMAN geht noch einen Schritt weiter, indem er sagt: "Often the right question is not 'will expert systems work for my problem area?' but rather 'what aspect of my problem area lends itself to expert system development'" (WATERMAN, 1986, S.12). So sollen im folgenden keine generellen Richtlinien ausgearbeitet werden, sondern in Anlehnung an WATERMAN (1986, S.127 ff.) die drei Fragen beantwortet werden:

- Wann ist eine Expertensystem-Entwicklung möglich?

- Wann ist eine Expertensystem-Entwicklung gerechtfertigt?

- Wann ist eine Expertensystem-Entwicklung geeignet?

2.5.1 Möglichkeitsfeld der Entwicklung

Die Entwicklung eines Expertensystems wird als möglich betrachtet, wenn folgende Kriterien zutreffen:

- Die Lösung des Problems sollte keinen (oder nur wenig) "gesunden" Menschenverstand erfordern. Dies meint das generelle, allgemeine Wissen, welches mehr oder weniger in allen Menschen vorliegt. All dieses Wissen kann nicht in einem Expertensystem, basierend auf heutiger Technologie, vereint sein. Wird beispielsweise einem Landwirt eine Lieferung von fünf Ferkeln zu einem Gesamtgewicht von 300 kg angeboten, so weiß er sofort, daß hier ein Mißverständnis vorliegt. Nicht, daß eine Ferkellieferung nicht aus fünf Ferkeln bestehen oder 300 kg wiegen könnte, die Kombination der beiden Fakten erst wird ihn stutzig machen. Ein Expertensystem, welches beispielsweise konzipiert wurde, die Entscheidungsfindung im Bezugs- und Absatzbereich eines landwirtschaftlichen Betriebes zu unterstützen, würde diesen Fehler wahrscheinlich nicht erkennen, es sei denn, es wäre explizit programmiert worden, solche Mißverständnisse aufzudecken.

- Die Lösung des Problems darf nur erkenntnisfähige (kognitive) Fähigkeiten, keine physikalischen Aktivitäten erfordern. Dies heißt nicht, daß solche Probleme Expertensystemen generell verschlossen bleiben; soll beispielsweise das Klima eines Schweinestalles geregelt werden, so kann der Überwachungsprozeß als kognitive Tätigkeit wohl von einem Expertensystem vollzogen werden, das Verstellen der Lüftungsklappen und Ventilatoren allerdings wird besser mit konventionellen Methoden bzw. Programmen durchgeführt.

- Die Lösung des Problems darf nicht zu schwierig sein und über die Lösung des Problems müssen bereits gesicherte Erkenntnisse vorliegen. Falls das Problem so schwierig oder ungewöhnlich ist, daß selbst der erfahrenste Experte Tage benötigen würde, sich einer Lösung zu nähern, oder wenn dieser Experte nicht direkt in der Lage wäre, einem Laien den Weg zur Lösung zu erklären, ist die Aufgabe mit hoher Wahrscheinlichkeit nicht mit zu rechtfertigendem Aufwand von einem Expertensystem zu lösen. Ebenfalls muß der Lösungsweg gut strukturiert und exakt nachvollziehbar sein. Falls eine Aufgabe so neu ist, daß keine gesicherten Erkenntnisse darüber vorliegen, wird die Entwicklung eines Expertensystems nicht möglich sein.

- Experten müssen in der Lage sein, ihre Problemlösungsmethoden darzulegen und sich mit den vom Expertensystem vorgeschlagenen Lösungen einverstanden erklären. Falls es für einen Experten nicht möglich ist, seine Lösungsansätze exakt zu artikulieren und zu erklären, ist es für den Wissensingenieur(5) nur schwerlich möglich, das Expertenwissen zu extrahieren und in das Expertensystem einzubringen. Darüber hinaus muß der Experte, wenn das Expertensystem programmiert ist, mit den präsentierten Lösungen und deren Genauigkeit einverstanden sein, da sonst die Fähigkeiten des Expertensystems von Experten nicht bewertet werden kann.

- Für das gewählte Problem muß ein Experte vorhanden sein, der gewillt ist, sein Wissen zur Verfügung zu stellen; dies letztendlich ist die grundlegendste Bedingung, die erfüllt sein muß, um eine Expertensystem-Entwicklung möglich zu machen.

2.5.2 Rechtfertigung der Entwicklung

Es gibt viele Möglichkeiten, die Entwicklung eines Expertensystems zu rechtfertigen, aber zumindest sollten folgende Kriterien zutreffen:

- Ein Expertensystem ist grundsätzlich dann gerechtfertigt, wenn dessen Einsatz zu einer Verbesserung des Status quo führt. Dies kann alleine schon dadurch bedingt sein, daß menschliche Experten eines speziellen Fachgebietes selten und somit teuer sein können.

- Ebenso dürfte ein Expertensystem Vorteile bringen, wenn ähnliche Probleme an vielen Orten in gleicher Manier und oder zur gleichen Zeit gelöst werden sollen, etwa Unterstützung der Entscheidungsfindung für die Getreidevermarktung landwirtschaftlicher Betriebe. Ein Expertensystem kann alleine dadurch zu rechtfertigen sein, um das Wissen eines Experten "zu erhalten", sei es, daß der menschliche Experte den Arbeitsplatz verläßt oder daß er aus anderen Gründen sein Wissen nicht mehr zu Verfügung stellen kann.

Das in ein Expertensystem eingebrachtes Wissen ist permanent, einfach zu übertragen, einfach zu dokumentieren, konsistent und "preiswert", menschliches Wissen ist hingegen vergänglich, schwierig zu transferieren und dokumentieren, schwer vorausschaubar (nicht immer in der gleichen Qualität verfügbar) und teuer (vgl. WATERMAN, 1986, S.12).

Was hier wie ein Plädoyer für Expertensysteme klingt, hat natürlich auch eine Kehrseite: Im Gegensatz zu Expertensystemen sind menschliche Experten kreativ, an neue Situation anpassungsfähig, haben ein breites Wissen und verfügen über einen gesunden Menschenverstand. BRACHMAN et al. formulieren: "... todays' expert systems fall very short on dimensions requiring general intelligent behaviour" (BRACHMAN et al., 1983, S.55). Expertensysteme dienen im allgemeinen nicht dazu den menschlichen Experten zu ersetzen, sondern dazu, ihm die Arbeit zu erleichtern!

Die Frage der Rechtfertigung von Expertensystemen wirft natürlich unmittelbar die Frage auf: Warum überhaupt Expertensysteme? Neben vielen bereits offensichtlich gewordenen Gründen (vgl. Kapitel 2.3 "Expertensysteme vs. konventionelle Programme") und der Tatsache, daß Expertensysteme dort ansetzen, wo die Algorithmen der konventionellen Programme versagen (vgl. nächstes Kapitel), ist ein aus wissenschaftlicher Sicht bedeutender Faktor die Formalisierung und Erschließung von Wissen in maschinenlesbarer Form. DAVIS spricht in diesem Zusammenahng von "Mental Hygiene" (DAVIS, 1986, S.960). Dieses Wissen liegt zwar erschlossen mit gewissen Einschränkungen meist auch in Lehrbüchern vor, doch WEISS bemerkt dazu: "...rarely if ever we do find (in textbooks) details how to apply this knowledge in an expert fashion" (WEISS und KULIKOWSKI, 1984, S.7).

Diese Argumentation geht in Hand mit der Tatsache, daß vorliegendes Wissen in vielen Fachgebieten bereits heute oft unüberschaubar umfassend ist und in zunehmenden Raten wächst. MICHALSKI und CHILAUSKY sehen hier die Möglichkeit, daß Expertensysteme die damit verbundenen Probleme lösen helfen: "They can provide an interactively accessible source of updated and well organized knowledge on specific subjects, and can conduct a certain amount of inference to help user with decision making" (MICHALSKI und CHILAUSKY, 1980, S.126). Darüber hinaus bieten Expertensysteme wie bisher noch kein anderes Instrument die Möglichkeit der Integration verschiedener Wissensquellen. Alle die hier angeführten Punkte münden schließlich in einen langfristig kostensenkenden, gewinnsteigernden und somit ökonomischen Aspekt (WEISS und KULIKOWSKI, 1984, S.7).

2.5.3 Eignung für eine Entwicklung

Die Entwicklung eines Expertensystems mag möglich und auch gerechtfertigt erscheinen, dennoch kann das zur Lösung anstehende Problem für ein Expertensystem ungeeignet sein.

- Es gilt hier, die Natur des Problems richtig zu bewerten. Wie bereits in Punkt "Expertensysteme vs. konventionelle Programme" dargelegt, lösen Expertensysteme Probleme in anderer Weise: Expertensystemlösbare Aufgaben basieren auf Manipulation von Symbolen, wobei die Symbole für reale Probleme stehen. Dies bedeutet, daß die Problemlösung u.a. durch wenn-dann-Beziehungen (gilt im wesentlichen für regelbasierte Systeme) und Heuristik, also "Rules of Thumb", zu finden ist. Dies trifft für die meisten realen Probleme zu. Ausnahmen sind hier die Probleme, die durch mathematische Manipulationen zu lösen sind. Dies bedeutet dann auch, daß alle Probleme, die sich in Form von mathematischen Gleichungen oder/und Funktionen ausdrücken lassen, sollten besser mit konventionellen Methoden bearbeitet werden. Wenn das Wissen über die mathematischen Zusammenhänge eines realen Problems bereits vorliegt oder zu erarbeiten ist, sind konventionelle Methoden immer exakter. Ist das Problem allerdings der Mathematik oder einem "cleveren" Algorithmus verschlossen, kann ein Expertensystem das geeignete Mittel sein.

- Das Problem sollte nicht zu einfach sein, es sollte ein Gebiet abdecken, für welches ein Experte einige Jahre Erfahrung und Praxis braucht, um dieser Experte zu werden. Anderenfalls ist das anstehende Problem weniger geeignet, da die Lösung mehr oder weniger trivial ist.

- Ein für ein Expertensystem geeignetes Problem sollte andererseits einen überschaubaren Umfang haben. WATERMAN schreibt dazu, daß es einer der häufigsten Fehler bei der Entwicklung eines Expertensystems sei, das Problem zu breit oder/und zu generell zu wählen (WATERMAN, 1986, S.133).

2.6 Auswahl des geeigneten Tools zur Entwicklung eines Expertensystems

Wie für die Entwicklung eines konventionellen Programms die Wahl der zu verwendenden Programmiersprache (z.B. BASIC, FORTRAN, COBOL, dBASE, ...) vom jeweiligen Problem und der Verfügbarkeit der Ressourcen abhängig ist, gilt analoges für die Entwicklung eines Expertensystems.

Grob können ESBT's nach der Art der Wissensdarstellung (vgl. Kapitel 2.1.1 "Repräsentation von Wissen ...") unterschieden werden. HARMON et al. differenziert (1988, S.45):

- inductive tools

- simple rule based tools

- structured rule based tools

- hybrid tools

- domain specific tools

- (symbolic programming languages)

Wie diese Tools arbeiten ist prinzipiell weiter oben bereits abgehandelt. Aus diesem Grund soll hier lediglich noch angesprochen werden, was diese Tools neben der prinzipiellen Arbeitsweise unterscheidet; eine umfassende Abhandlung liefert beispielsweise HARMON et al. (1988, S.27-156) oder GEVARTER (1987).

Die Abgrenzung zwischen originären Werkzeugen (Tools) und etwa Programmierungsumgebungen (Environments) oder symbolischen Programmiersprachen ist fließend, wie versucht ist, in Abbildung 12 zu zeigen.

So sind die weiter oben in Klammern gesetzten, symbolischen Programmiersprachen nicht als eigentliche Tools zu verstehen, obwohl sie sehr wohl zur Entwicklung von Expertensystemen herangezogen werden können. Die fachgebietsspezifischen Programmierwerkzeuge gestatten es, in bestimmten Fachgebieten, auf die sie speziell zugeschnitten sind, Expertensysteme vergleichsweise einfacher und schneller zu entwickeln. Sie sind für Expertensystementwicklungen in anderen Fachgebieten nicht geeignet.

Eine andere Möglichkeit der Differenzierung ist die "Größe" oder "Mächtigkeit" der Tools, wie in Abbildung 13 gezeigt. Generell ist gültig, daß je mächtiger die Tools, desto höher sind die Anforderungen an die Hardware und den Programmentwickler. In der Literatur (vgl. MARTONELLI, 1988, S.58 ff., HARMON und KING, 1985, S.92 ff., GEVARTER, 1987, S.28 ff., WATERMAN, 1986, S.142 ff., WATERMAN und HAYES-ROTH, 1983, S.169 ff.) werden eine Reihe idealerweise zu beurteilende Kriterien für die Wahl eines geeigneten Tools angeführt, dazu zählen unter anderem:

Eine generelle Checkliste für den Vergleich verschiedener ESBT's könnte in Anlehnung an HARMON und KING etwa wie in Übersicht 6 dargestellt aussehen. Diese Übersicht bietet gleichzeitig zusammenfassend noch einmal die wichtigsten bisher besprochenen Charakteristika von Expertensystemen auf einen Blick.

Wie noch in Kapitel 2.8.1.1 "Identifizierungsphase" darzustellen ist, werden nicht alle die hier angesprochenen Punkte gleichermaßen Berücksichtigung bei der Auswahl eines Tools finden können. Soll beispielsweise in den Agrarwissenschaften nicht nur aus reinen Forschungszwecken ein Expertensystem entwickelt werden, so scheiden jene ESBT's weitgehend aus, die eher als "Programmierumgebungen" aufgefaßt werden können (wie etwa ART, KEE, Knowledge Craft), da einfache Lizenzen einige zehntausend DM kosten und nur selten auf Computern des Industriestandards (PC's) lauffähig sind. HARSH bemerkt dazu: "To design a system that assumes a much more sophisticated computer technology available to the decision maker (Landwirt, Anm. d. Verf.) than he actually has, would be wasted effort" (HARSH et al., 1988, S.6). Darüber hinaus sind Programmierumgebungen wie die oben erwähnten, aufgrund ihrer Komplexität und Flexibilität in der Wissensdarstellung relativ schwierig zu erlernen und somit sicher eher für professionelle Wissensingenieure geeignet. Für den gerade in den Agrarwissenschaften derzeit und in naher Zukunft wichtigeren Ansatz, daß Experte und Wissensingenieur in einer Person vereint sind, werden solche Tools/Environments auch aus diesem Grunde eher nur sehr eingeschränkt Verwendung finden.

Für die weitere Zukunft werden diese Nachteile geringeres Gewicht erhalten, der Preistrend ist deutlich nach unten gerichtet und Landwirte werden leistungsfähigere Computer benutzen.

So bleiben als wichtige Kriterien zur Auswahl eines ESBT's für Anwendungen in den Agrarwissenschaften beispielsweise zu betrachten:

- Welche Anwendung soll programmiert werden?

Falls eine Real-Time Überwachungs- und Steuerungsapplikation geplant ist, spielt die Frage nach der Schnittstelle zum Betriebssystem des Computers eine maßgebliche Rolle. Gleiches gilt für geplante Verbindungen zu Datenbanken oder bereits vorhandenen Programmen.

- Genügt die zum geplanten Zeitpunkt der Distribution des entwickelten Expertensystems vom Adressatenkreis verwendete Hardware zumindest annähernd den Anforderungen des Tools?

- Ist der Adressatenkreis in der Lage bzw. gewillt, die Kosten für Laufzeitlizenzen zu tragen?

Stehen nach positiver Beantwortung dieser Fragen noch mehr als ein ESBT zur Auswahl, können die bereits angesprochenen Gesichtspunkte wie

über die Wahl entscheiden. Nur in den wenigsten Fällen wird ein Programmentwickler im Bereich der Agrarwissenschaften in der Lage sein, mehr als zwei bis drei ESBT's auf all diese Kriterien eingehend zu testen. Ein Informations- und Erfahrungsaustausch auf dieser Ebene ist somit unabdingbar. Dies gilt insbesondere, wenn unterstellt wird, daß DAVIS' Aussage zutrifft: "For every tool there is a task perfectly suited for it. Unfortunately, the converse isn't true" (zitiert in WATERMAN, 1986, S.142). So gibt es also nicht für jede gewünschte Applikation das geeignete Tool, Abstriche müssen gemacht und Kompromisse eingegangen werden.

2.7 Ablauf von Expertensystem-Entwicklungen

Die Entwicklung eines Expertensystems ist für gewöhnlich ein evolutionärer Prozeß. Sobald der Programmentwickler über genügend Wissen bezüglich des Problems verfügt, kann er beginnen, ein, wenn auch sehr vereinfachtes System, zu realisieren. Durch Testläufe gewonnenes Feedback trägt zur ständigen Verbesserung oder auch zur Revision des Systems bei. In einem bestimmten Grad assistiert und unterstützt so das in der Entwicklung befindliche Expertensystem selbst den Entwicklungsprozeß. Es existiert (noch) kein "Rezept" oder eine Reihe wohldefinierter Schritte zur Entwicklung von Expertensystemen (vgl. WATERMAN, 1986, S.135). In der Literatur findet sich somit kein Konsens bezüglich des Entwicklungsablaufes eines Expertensystems, ein allgemein gültiges, wenn auch nicht verbindliches, Konzept ist in Abbildung 14 dargestellt.

Die Selektion und Analyse des Problems umfaßt alle Kriterien, die im vorhergehenden Punkt angesprochen wurden. Darüber hinaus müssen hier die Ziele des Expertensystems und die Anforderungen, denen es genügen soll, definiert werden. Dazu gehören erste Treffen mit geeigneten Experten und eventuell bereits Gespräche mit potentiellen Endbenutzern. Die Beantwortung der Frage, welche Daten für das Expertensystem benötigt werden, und wie sie für das System bereitgestellt werden können, gehört ebenfalls in diese erste Phase.

Die Entwicklung eines Prototypen sollte bereits einen guten Teil des Wissens beinhalten, welches mehr oder weniger typisch für das fertige Expertensystem sein wird. Andererseits dürfen die zu lösenden Probleme für den Prototypen zu Testzwecken nicht zu kompliziert sein. Letztendlich dient diese Phase zur Bewertung der Durchführbarkeit der geplanten Expertensystem-Entwicklung. Die Entwicklung eines Prototypen beschließt endgültig über die Wahl der geeigneten Software (ESBT, symbolische Programmiersprache) und Hardware und damit der Art der Wissensrepräsentation. Hier beginnt die Identifikation und Dokumentation des Begründungsprozesses, die den Experten zur Lösung des Problems führt. Durch die Entwicklung des Prototypen muß klar werden, welche Probleme bei der Entwicklung des endgültigen Expertensystems auftreten können, ob an den ursprünglichen Zielen festgehalten werden kann, oder ob sie einer Revision bedürfen. Diese Phase sollte mit einem detaillierten Design für das vollständige Expertensystem abschließen. Die Erweiterung und Verbesserung des Prototypen zur Reife, also die Entwicklung des vollständigen Expertensystems umfaßt die möglichst vollständige Erschließung des für das Expertensystem benötigten Wissens und dessen Übertragung in die Wissensbasis. Diese Phase kann einen beträchtlichen Zeitraum beanspruchen. HARMON spricht von 12-18 Monaten, während er für die Prototypentwicklung 6-9 und für die erste Phase 1-3 Monate veranschlagt (HARMON und KING, 1985, S.197). In dieser Phase muß alles getan werden, um die gesteckten Ziele zu erreichen; nicht nur die Wissensbasis wird hier erheblich erweitert, sondern auch die Benutzeroberfläche und die Schnittstellen zu anderen Programmen bzw. Datenbanken erhalten nun ihre endgültige Form. Ein guter Start in diese Phase wird in vielen Fällen sein, den Prototypen "wegzuwerfen" und - basierend auf den im Prototypenstadium gemachten Erfahrungen - neu zu beginnen. Ein vollständiger Neubeginn kann zu wesentlich eleganteren Lösungen und einfacheren Strukturen führen und unter Umständen, besonders in der Phase der Prototypenentwicklung, mehr als einmal notwendig sein.

Die Entwicklungsphasen bis zu diesem Punkt sind in Übersicht 7 noch etwas detaillierter als Drei-Phasen-Prozeß dargestellt, dessen Phasen jeweils aus drei gleichen Stufen bestehen (dieser Prozeß ist nicht verbindlich, ist aber insbesondere für interaktive, regelbasierte Systeme angebracht). M.a.W.: Die drei Stufen sind jeweils dreimal zu durchlaufen. Die Stufen sind im einzelnen:

1. Declarative Knowledge Acquisition

- Extraktion von Wissen und Einbringung in das System

2. Procedural Arrangement

- Neuordnung der Klauseln zu einer sinnvollen Reihenfolge

- Wahl und Zuordnung von CNF

- Gewährleistung eines reibungslosen Dialoges

3. Interface Development

- Formulierung der Regeln in verständlicher Form

- Hinzufügen von erklärenden Texten für "Wie-" und "Warum-Fragen"

- Tests mit Endanwendern.

Nachdem diese Stufen in allen Phasen durchlaufen sind, bedarf das System umfassender Tests.

Erfolgsmaßstäbe für diese Tests können beispielsweise sein: "... erreicht das Expertensystem in 10 verschiedenen Fällen die gleichen Ergebnisse wie ein Experte, oder zumindest Ergebnisse, mit denen sich der Experte ebenfalls hätte identifizieren können" oder "erreicht das Expertensystem in 5 verschiedenen Fällen das gleiche Ergebnis wie 5 verschiedene Experten", wobei es unter Umständen sinnvoll ist, die Ergebnisse der Experten nicht nur gegen die des Expertensystems, sondern auch untereinander zu vergleichen. Andere Leistungskriterien könnten sein: "..in welchem Maße vertraut der Endanwender den Ergebnissen des Expertensystems", was maßgeblich von der Fähigkeit des Expertensystems abhängt, wie es seinen Begründungsprozeß plausibel machen kann und, in welchem Maße es die Antworten auf die weiter oben bereits angesprochenen Benutzerfragen "Wie (wurde diese Schlußfolgerung erreicht)", "Warum (wurde diese Schlußfolgerung erreicht)" und "Was wäre wenn..." zu befriedigen in der Lage ist.

Wenn alle gesteckten Ziele erreicht und alle Tests zufriedenstellend verlaufen sind, kann das Expertensystem für die uneingeschränkte Benutzung freigegeben, je nach Programmumgebung implementiert und benutzt werden. Die Wartung des Expertensystems hängt davon ab, wie sehr das in die Wissensbasis eingebettete Wissen Änderungen oder Aktualisierungen unterliegen wird. Dies steht von Fall zu Fall in enger Beziehung mit dem Sachproblem. Ein Expertensystem zur Konfiguration von Computersystemen, z.B. DIGITAL's XCON (eXpert CONfiguration, vgl. SCWON, 1985, S.19), wird erheblich häufiger zu modifizieren sein als ein Expertensystem zur Fehleranalyse und Reparaturanleitung bei Lokomotiven, etwa GENERAL ELECTRIC's DELTA (Diesel-Electric Locomotive Troubleshooting Aid, vgl. HARMON und KING, 1985, S.160).

Im günstigsten Fall hat ein zu wartendes Expertensystem eine gut entwickelte Schnittstelle zu einer Datenbank, so daß idealerweise die Datenbank aktualisiert werden kann, ohne daß die Wissensbasis einer Änderung unterliegen muß, ein Konzept, das auch für FARMEXPERT verwirklicht worden ist. Die gesamte Entwicklung eines Expertensystems wird von der Interaktion zwischen Programmentwickler, Experten und potentiellen Endanwendern geprägt. Das "Gewinnen" oder "Extrahieren" von Wissen wird als "Wissensakquisition" bezeichnet.

2.8 Wissensakquisition

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 15 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.8.1 Phasen der Wissensakquisition

2.8.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 müssen andere Maßstäbe angesetzt werden als für ein Expertensystem im Bereich der Medizin. 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 - vgl. Kapitel 2.6 "Auswahl des geeigneten Tools ..."). 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. Derzeit (1990) bleiben hier die Möglichkeiten für den Bereich der Agrarwissenschaften weitgehend auf den regelbasierten ESBT's, die auf dem 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.8.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 (etwa zur Bestimmung der in Kapitel 5.2.2.3.1 beschriebenen Exponentialfunktionen als Grundlage der Kalkulation von Konfidenzfaktoren in FARMEXPERT). 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.8.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.8.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.8.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 auch die Akzeptanz durch den Benutzer berücksichtigen. Die maßgeblichen Kriterien hierfür haben bereits im Punkt "Schnittstelle zum Endbenutzer" und "Tiefensuche vs. Breitensuche" Erwähnung gefunden.

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.

2.8.2 Möglichkeiten der Wissensakquisition

Das Schlüsselelement zur Erstellung einer Wissensbasis ist der Transfer von Wissen (meist menschliche Expertise) in das Computerprogramm(6). 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. Kapitel 2.8.2.2.3 "Notwendigkeit und Charakteristika ...") 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.

2.8.2.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., 1986b, 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.

2.8.2.2 Experte und Wissensingenieur in Zusammenarbeit

Dieser Ansatz setzt die Existenz eines Wissensingenieurs voraus, der dann mit einem (oder mehreren) Experten eines Fachgebietes zusammenarbeitet. Er kann, wie in Abbildung 16 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.).

2.8.2.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 Kapitel 2.8.3 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., 1986b, S.10 ff. und Kapitel 3.2.1.4).

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 Kapitels 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.

2.8.2.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 (vgl. Kapitel 2.1.5.4 "'Wie', 'Warum', ..."). 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.

2.8.2.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 17 dargestellt.

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 in den einzelnen Phasen des Kapitels 2.8 "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).

2.8.3 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.

2.8.3.1 Interview

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

2.8.3.1.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.

2.8.3.1.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.

2.8.3.2 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.

2.8.3.3 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. Kapitel 2.8.3.6) 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.

2.8.3.4 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.

2.8.3.5 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.

2.8.3.6 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.

2.8.3.7 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.

2.8.3.8 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.

2.8.3.9 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.

2.8.3.10 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.

2.8.3.11 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 (vgl. Kapitel 2.1.1) und ist relativ einfach zu automatisieren (vgl. DIEDERICH, 1987, S.18 ff.).

2.8.3.12 Induktion

Von Induktion war bereits in Kapitel 2.1.1.1.1 die Rede. Tatsächlich bietet sich auch dieses Verfahren der maschinellen Erschließung von Wissen 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, vgl. Kapitel 2), 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.


Fußnoten:

(1) Diese Bezeichnung soll auch im weiteren Verwendung finden, da eine elegante Übersetzung nicht bekannt ist
(2) Ein ebenfalls gebräuchliches Schema ist die Unterteilung in "Logic Systems", "Rule Based Systems" und "Frame Based Systems" (vgl. etwa DENNING, 1986, S.19). Dieses Schema gibt allerdings eher die allgemeine Klassifizierung von Wissensrepräsentation in Expertensystemen wieder und ist weniger speziell für ESBT's typisch.
(3) Bei AND Verknüpfungen gilt der jeweils niedrigere CNF, vgl. Regel 4
(4) Für den Begriff 'frame' hat sich noch kein entsprechender deutscher Ausdruck eingebürgert.
(5) Nicht immer wird diese Zusammenarbeit zustande kommen können, in vielen Fällen wird der Experte und der Wissensingenieur ein und dieselbe Person sein, dennoch gilt das hier Gesagte entsprechend. Zum Zusammenwirken Experte/Wissensingenieur siehe auch Kapitel 2.8 "Wissensakquisition".
(6) 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 dieser Arbeit verfolgten Zwecke hinreichend, die ersten beiden der angeführten Punkte näher zu untersuchen.


Zurück  Inhalt  Weiter