8 Einführung in Expertensysteme

Transkript

1 # # # 8 Einführung in Expertensysteme 23. Vorlesung: issensmodellierung: Rapid Prototyping und Modellbasierter Ansatz Begriff von Edward Feigenbaum geprägt (Referenz: The art of artificial intelligence: Themes and case studies of knowledge engineering, IJCAI 5,1977) Ziel: Transfer von Expertise auf maschinelle Systeme zwecks Nutzung Hauptaspekte: Akquisition + Operationalisierung von Expertenwissen Erklärung des Reasoning an menschliche Benutzer Aufgabe: Problemlösewissen (für einen eingegrenzten Aufgabenbereich) ist von menschlichen Experten zu erheben und so zu repräsentieren, daß sich Probleme maschinell bearbeiten lassen. Schwierigkeiten: $ Teile des fachlichen und des (schwer verbalisierbaren) Erfahrungswissens von Experten sollen operationalisiert werden $ Konflikte zwischen weichen Erhebungsmethoden und harten Formalisierungen! "

2 Beobachtungen E L T Aktionen Schwere Aufgabe: Implizites Expertenwissen ist in ein operationales Modell für ein Expertensystem zu überführen. Fakten Annahmen abgeleitetes issen issenserhebung: "weiche", interpretative Methoden Experte System Formalisierung und Operationalisierung: "harte" Methoden Fakten Annahmen abgeleitetes issen! " Techniken zur Erhebung von Expertenwissen (in der Regel verbale Daten) >>>issensebene Analyse und Interpretation der Daten: elcher Schlußfolgerungsprozeß liegt zugrunde? as für issen wird dabei eingesetzt? >>>Symbolebene Formale Beschreibung: der Problemlösestrategie(n) des spezifischen Domänenwissens Entwurf und Implementierung eines operationalen issensmodells! " %

3 ' ' ' ' Unstrukturiertes ( Interview issensingenieur befragt Experten (spontan) über sein issen, auch während der Lösung von Testfällen Introspektion ( Experte beschreibt, wie er Fälle löst/welche Strategie er benutzt Laut-Denken-Protokoll ( Experte verbalisiert sein Denken, während er ein Problem löst Strukturiertes ( Interview Vorgeplante Erhebung bzw. nachträgliche Ergänzung anderweitig gewonnener Protokolle Testfälle: Routine / begrenzte Information / beschränkte Zeit / schwierige Fälle! " & 1) Identifikation des Problems, der Anforderungen, der Beteiligten 2) Konzeptualisierung für die Problemlösung benötigte Konzepte, Relationen etc. herausfinden 3) Formalisierung $ prototypischen Problemlöseprozeß identifizieren $ issensrepräsentation konkretisieren $ Schlüsselkonzepte und Relationen im Formalismus ausdrücken 4) Operationalisierung Formalisiertes issen in lauffähiges Computerprogramm überführen 5) Testen (nach aterman: A Guide to Expert Systems, 1986) Performanz/Nützlichkeit bewerten (führt u.u. zur Iteration früherer Schritte)! " )

4 Der Sektflaschenfall Es geht um ein System zur Einschätzung des Schadenersatzanspruches bei Produkthaftungsfällen. (nach aterman: A Guide to Expert Systems, 1986) Verwendung eines Phasenmodells, insbesondere: Konzeptualisierung Herausfinden der für die Problemlösung benötigten Konzepte, Relationen, Kontrollmechanismen, Strategien, Teilaufgaben, Nebenbedingungen Formalisierung Identifikation des prototypischen Problemlöseprozesses Konkretisierung der issensrepräsentation Ausdrücken der Schlüsselkonzepte und Relationen in einem Formalismus! " * Quelle: atermann, A Guide to Expert Systems, 1986, Fall: Ein 30-jähriger bekam beim Öffnen einer Sektflasche, was er nie vorher getan hatte, den Korken ins Auge. Die Folge war u.a. eine partielle Netzhautablösung, die chirurgisch nicht ganz vollständig behoben werden konnte. Spätere Komplikationen sind möglich. (Einzelheiten im Interview) KNOLEDGE ENGINEER: Lassen Sie uns den Sektflaschenfall betrachten. ir wissen, daß der spezielle Schaden - Arztrechnung und Einkommensausfall - $4.500 beträgt, können uns also auf den allgemeinen Schaden konzentrieren. as glauben Sie ist der allgemeine Schaden in einem solchen Fall? Klärung des Begriffs "allgemeiner Schaden" EXPERTIN: Nun ---- (Pause), der würde wahrscheinlich ungefähr $ äh, nein, sagen wir $ betragen. KNOLEDGE ENGINEER: ie sind Sie zu dieser Zahl gelangt? EXPERTIN: Ich habe viele Jahre Erfahrung mit solchen Fällen. Ich benutze da nicht irgendwelche festen Regeln wie "Schmerzen und Leiden gleich drei mal die Arztkosten." Ich sehe mir einfach die Fakten des Falles an und schätze den ert ein.! " +

5 C D EF G H I EJ K J L EG MG N G M O Der Knowledge Engineer fragt gleichwohl nach, um Vorgehen und Konzepte der Expertin zu ergründen. KNOLEDGE ENGINEER: elcher Faktor schien in diesem Fall für den allgemeinen Schaden entscheidend zu sein? EXPERTIN: Nun, äh, wahrscheinlich war hier der wichtigste Faktor, äh, daß es eine Augenverletzung war. Das kann einen nachteiligen Effekt auf den Kläger haben. Dafür verdient er eine Entschädigung. KNOLEDGE ENGINEER: $60.000? EXPERTIN: Nein, die Verletzung selbst war nur etwa $ wert. KNOLEDGE ENGINEER: Verstehe. Sie sagen, der Kläger sollte dafür entschädigt werden, daß er eine Verletzung erlitt, ähnlich wie Schmerz und Leiden zu bezahlen sind. EXPERTIN: Ja, das ist richtig. KNOLEDGE ENGINEER: Und Schmerz und Leiden waren $ wert. EXPERTIN: Nicht ganz so. Ich denke, das Trauma der Verletzung selbst war nur etwa $ wert., -. / : 0 ; 3 6 ; 3 1 < = >? : > A B C D EF G H I EJ K J L EG MG N G M O KNOLEDGE ENGINEER: Aber Sie haben von $ gesprochen. EXPERTIN: Ja, die anderen $8.000 waren dafür, daß der Kläger vier Tage auf einem Auge blind war. Die Ärzte wußten nicht, ob er auf dem Auge wieder sehen würde. Sowas kann recht erschreckend sein. KNOLEDGE ENGINEER: Sie sagen also, daß der Kläger $ für die Verletzung selbst und nochmal $8.000 für die ertragene Angst haben sollte. Dann sind die $8.000 also für die Unannehmlichkeiten des Klägers und die $ für den tatsächlichen Schmerz und Schock der Verletzung. EXPERTIN: Richtig, außer daß ich seine Angst, blind zu sein, nicht als Unannehmlichkeit bezeichnen würde. Die Tatsache, daß er nach der Verletzung eine Brille tragen mußte, was er vorher niemals brauchte, wäre ein Beispiel für eine Unannehmlichkeit, die durch die Verletzung verursacht ist. KNOLEDGE ENGINEER: ürde das zum allgemeinen Schaden hinzukommen?, -. / : 0 ; 3 6 ; 3 1 < = >? : > A P Q

6 C D EF G H I EJ K J L EG MG N G M O EXPERTIN: Ja, ich würde sagen, das wäre $2.500 wert. Der Knowledge Engineer erkennt ansatzweise ein der Schätzung zugrunde liegendes Muster von verschiedenen Aspekten einer Verletzung und ihnen zugeordneten erten. Er interessiert sich jetzt besonders für die Begründungen einzelner Einschätzungen der Expertin. KNOLEDGE ENGINEER: Das heißt, der Kläger sollte mit $2.500 für das Brilletragen entschädigt werden. EXPERTIN: Nicht genau. Er sollte $2.500 für die Unannehmlichkeit, eine Brille zu tragen, bekommen. Er sollte nochmal $2.500 für den Teilverlust des Sehens bekommen. Seine Sehschärfe ist durch die Verletzung leicht gemindert. KNOLEDGE ENGINEER: Fünftausend Dollar klingt nach viel Geld nur für das Brilletragen. EXPERTIN: Nicht wirklich. Es wäre mehr, wenn das Aussehen für seine Arbeit besonders wichtig wäre wie bei Film- oder Fernsehstars. KNOLEDGE ENGINEER: Sekunde - (sieht Papiere durch), es hieß hier, der Kläger ist Rundfunksprecher bei einer lokalen Radiostation, aber vor der Verletzung hatte er sich als Fernseh-Sportreporter beworben. Er behauptet, er habe die Stelle nicht bekommen, weil er jetzt Brillenträger ist., -. / : 0 ; 3 6 ; 3 1 < = >? : > A P P C D EF G H I EJ K J L EG MG N G M O EXPERTIN: Ja, davon spreche ich. Sein Aussehen ist Geld wert. Das könnte den allgemeinen Schaden um $5.000 erhöhen. KNOLEDGE ENGINEER: enn von der Verletzung eine Narbe im Gesicht geblieben wäre, würde das ähnlich sein? EXPERTIN: Nun, das wäre beträchtlich mehr wert, fiele aber in die gleiche Kategorie einer Entstellung. KNOLEDGE ENGINEER: Lassen Sie uns mal sehen: $ für das Trauma der Verletzung, $8.000 für Angst, $2.500 für Unannehmlichkeit, $2.500 für Sehverlust und $5.000 für Entstellung. Haben Sie noch irgendwelche Faktoren, auf die wir noch nicht gekommen sind? EXPERTIN: Ich erinnere mich, daß der Arztbericht die Möglichkeit eines durch die Verletzung verursachten Glaukoms erwähnte. Ich glaube, 10 Prozent ahrscheinlichkeit war es. KNOLEDGE ENGINEER: Ja, davon war die Rede. ürde das den allgemeinen Schaden betreffen?, -. / : 0 ; 3 6 ; 3 1 < = >? : > A P,

7 C D EF G H I EJ K J L EG MG N G M O EXPERTIN: Das würde signifikante Auswirkung haben; es sollte $ wert sein wegen der Chance, daß der Kläger wirklich Star bekommt. Das ist eine ernste Krankheit. KNOLEDGE ENGINEER: Die Möglichkeit eines späteren Glaukoms sollte also in jedem Fall veranschlagt werden? EXPERTIN: Absolut. KNOLEDGE ENGINEER: enn man den zukünftigen Faktor einbezieht, kommt als Summe $ heraus. Das ist fast genau, was Sie anfangs geschätzt hatten. EXPERTIN: Ja, $ ist ein guter Ansatz für den allgemeinen Schaden in diesem Fall. * * *, -. / : 0 ; 3 6 ; 3 1 < = >? : > A P - C D EF G H I EJ K J L EG MG N G M O Auflistung der für relevant gehaltenen Konzepte Task: Bewertung einer Verletzung Attribute der Verletzung: Typ der Verletzung: Auge ert der Verletzung: bestimmter $-Betrag Umfang der Verletzung: Ein Auge Folgen der Verletzung: Sehschärfe leicht beeinträchtigt temporäre Erblindung einseitig Dauer der Erblindung vier Tage Ungewißheit über Permanenz 10 Prozent Chance für Glaukom Brille erforderlich Attribute des Klägers: Trug er vorher eine Brille? Ist sein Äußeres wichtig für die Arbeit? Attribute eines Glaukoms Typ: Krankheit Grad: ernst Faktoren zur Bewertung der Verletzung Traumafaktor Angstfaktor Unannehmlichkeitsfaktor Sehverlustfaktor Entstellungsfaktor zukünftiges_traumafaktor, -. / : 0 ; 3 6 ; 3 1 < = >? : > A P R

8 U V V V C D EF G H I EJ K J L EG MG N G M O Tentative Regeln, die Relationen zwischen Konzepten ausdrücken (nach atermann 1986, S.171) [1] enn der Kläger eine Augenverletzung erfahren hat und die Sehschärfe des Klägers leicht reduziert ist, erhöhe dentraumafaktor um $ [2] enn die Verletzung zeitweilige Erblindung eines Auges verursacht hat und der vorübergehende Charakter der Erblindung ungewiß war, erhöhe den Angstfaktor um $8000. [3] enn für den Kläger die Chance eines späteren Glaukoms besteht und diese Chance durch die Verletzung des Klägers bedingt ist und der ert der Chance = 10% ist, erhöhe den zukünftiges_traumafaktor um $ [4] enn der Kläger eine Augenverletzung erfahren hat und die Verletzung des Klägers nur ein Auge betrifft und des Klägers Sehschärfe durch die Verletzung leicht gemindert ist erhöhe den Sehverlustfaktor um $2500. [5] enn die Verletzung des Klägers das Tragen einer Brille erfordert und der Kläger vor der Verletzung keine Brille tragen mußte, erhöhe den Unannehmlichkeitsfaktor um $2500. [6] enn die Verletzung des Klägers das Tragen einer Brille erfordert und das Aussehen des Klägers für seine Arbeit von Bedeutung ist und der Kläger vor der Verletzung keine Brille tragen mußte, erhöhe den Entstellungsfaktor um $5000. [7] Für jeden Faktor, der zur Bewertung der Verletzung beiträgt, addiere diesen Faktor zum allgemeinen Schaden., -. / : 0 ; 3 6 ; 3 1 < = >? : > A P S C D EF G H I EJ K J L EG MG N G M O Ziel: Die tentativen (low-level) Regeln sollen begutachtet und wenn möglich verallgemeinert werden (higher-level principles) Besprechung der Regel 3 (in strukturiertem Interview mit der Expertin) liefert: Expertin unterscheidet Kategorien der Verletzungsfolgen (mit differenzierten Schadensbewertungen) moderate (z.b. verkürztes Bein) ernste (z.b. Glaukom) katastrophale (z.b. Querschnittslähmung) Der Knowledge Engineer führt zwei neue Konzepte ein: Klasse als ernst bewerteter Krankheiten ert einer tatsächlich zugezogenen Krankheit Glaukom, Epilepsie, Herzkrankheit werden als ernste Krankheiten klassifiziert,, -. / : 0 ; 3 6 ; 3 1 < = >? : > A P T Glaukom, Epilepsie, Herzkrankheit der ert einer 5-15% wahrscheinlichen gehören in eine Kategorie Verletzungsfolge mit 30% der bei 5-15% Chance späterer Krankheit tatsächlich zugezogenen Krankheit kostet Glaukom $ festgelegt. Glaukom als unmittelbare Verletzungsfolge Dies ergibt allgemeinere Regel- kostet $ formulierungen etc.

9 p q rs t u v rw x w y rt zt { t z Idee: Vorteile: Nachteil: Problem: So früh wie möglich eine Mini-Version des in Angriff genommenen Systems bauen, das als Referenz für die weitere Entwicklung dient. Beschränkung auf das zur Behandlung weniger ausgewählter Fälle notwendige issen. Fokussierung bei der issenserhebung und -interpretation; Überzeugungsfaktor gegenüber beteiligtem Experten und Management für die Durchführbarkeit des Projekts. Fast grundsätzlich Gefahr, daß vor tiefergehender Analyse und Charakterisierung des Problems Design-Entscheidungen getroffen werden, die nicht adäquat sind und den weiteren Ausbau des Systems eher behindern als fördern. Der konzeptionelle Abstand zwischen erhobenen Daten und Implementierungen ist in der Regel für einen solchen Ansatz zu groß. X Y Z [ \ ] ^ _ ` a b c d _ e f \ g _ b g _ ] h i b ` e ^ j k f _ b l b e _ ^ ^ j c _ b m n o p q rs t u v rw x w y rt zt { t z Sämtliches Bereichswissen kann in Form von Bedingungs- Handlungs-Paaren (Regeln) ausgedrückt werden. Regeln sind voneinander unabhängige ("modulare") Aussagen über einen Bereich. Sie werden mit einem Standard-Interpreter ausgeführt. (Stanford Heuristic Programming Project) Die Form der Darstellung von Bereichswissen ist unabhängig von seinem Gebrauch. Kritikpunkte: Regelbasierte Systeme zwar einfach zu konstruieren, im Großen aber schwer vorherzusagen und zu warten Bereichswissen und Kontrollstrategie vermischen sich Unadäquater Zugang erfordert falsch verstandenes Knowledge Engineering, nämlich Hinprogrammieren X Y Z [ \ ] ^ _ ` a b c d _ e f \ g _ b g _ ] h i b ` e ^ j k f _ b l b e _ ^ ^ j c _ b m n }

10 p q rs t u v rw x w y rt zt { t z Die Repräsentation von issen zum Zweck, bestimmte Probleme damit zu lösen, wird stark von der Natur des Problems und der auf das issen angewandten Inferenzstrategie beeinflußt ("interagiert" damit) => Modell des Problemlöseprozesses diktiert Form der Repräsentation von Bereichswissen (Bylander & Chandrasekaran) Modellbasierter Ansatz: Offenlegung des mentalen konzeptuellen Modells des Knowledge Engineers vor Schritten zur Implementierung strenge Trennung zwischen Datenanalyse / -interpretation und Repräsentation der interpretierten Daten Erstellung eines Modells (als Papierdokument) in einer dem Experten verständlichen eise (auf der "issensebene") X Y Z [ \ ] ^ _ ` a b c d _ e f \ g _ b g _ ] h i b ` e ^ j k f _ b l b e _ ^ ^ j c _ b m n ~ p q rs t u v rw x w y rt zt { t z Klare Trennung von Analyse und Implementierung (evtl. von verschiedenen Personen durchführbar) nach der Analysephase relativ vollständige Beschreibung der Expertise Aufbau des mentalen Modells wird transparent und dokumentierbar generische Modelle von Teilaufgabenstrukturen können die Interpretation und die issensakquisition leiten ("generic tasks") Fehler der Interpretation resultieren nicht in unnötiger Implementierungsarbeit; Änderungsaufwand geringer Nachteil: Vorteile des Prototyping entfallen, insbesondere kann die Dynamik des Modells nicht direkt überprüft werden X Y Z [ \ ] ^ _ ` a b c d _ e f \ g _ b g _ ] h i b ` e ^ j k f _ b l b e _ ^ ^ j c _ b m X

11 p q rs t u v rw x w y rt zt { t z hier nach Hayes-Roth et al. (1983), Karbach (1993) Vorausschau Konsequenzen einer bestehenden Situation voraussagen Eingabe: Beschreibung des Zustands eines Systems Ausgabe: zukünftiger Zustand des Systems Überwachung Vergleich von Beobachtungen mit vorgegebenen Normen Eingabe: der Zustand eines Systems und eine Norm Ausgabe: die Abweichung zwischen der Norm und dem aktuellen Zustand des Systems Diagnose Fehlfunktionen aufgrund von Beobachtungen feststellen Eingabe: Beschreibung des Systems anhand von Symptomen Ausgabe: entweder die Ursache der Fehlfunktion oder ein Begriff, der den Zustand des Systems beschreibt Design Konfigurierung von Objekten, die bestimmten Anforderungen genügen sollen Eingabe: Anforderungen, die an das fertige System gestellt werden Ausgabe: ein Artefakt, das die spezifizierten Anforderungen erfüllt X Y Z [ \ ] ^ _ ` a b c d _ e f \ g _ b g _ ] h i b ` e ^ j k f _ b l b e _ ^ ^ j c _ b m X n š œ ž Ÿ ž hier nach Hayes-Roth et al. (1983), Karbach (1993) Planung Design von Aktionen Eingabe: der Anfangszustand, die verfügbaren Operatoren und die Zielzustandscharakterisierung Ausgabe: ein fertiger Plan mit der Reihenfolge der Operatorenanwendungen Steuerung Überwachung, Diagnose und Reparatur von Systemverhalten Eingabe: der Zustand eines Systems Ausgabe: Beseitigung von Fehlerursachen oder Unterdrückung von Symptomen, die durch Fehler entstehen Reparatur Ausführung eines Plans, um eine Fehlfunktion zu beseitigen Eingabe: eine Fehlerursache oder eine Zustandsbeschreibung des Systems Ausgabe: Maßnahmen zur Beseitigung des Fehlers oder die Unterdrückung von Symptomen Einschätzung Einstufung eines Systems anhand Bewertungskriterien Eingabe: Beschreibung des Systems und eine Norm Ausgabe: die Einordnung des Systems in eine qualitative Entscheidungsklasse, z.b. schlecht, mittel oder gut ƒ ˆ Š Œ Ž Š Š ˆ k Ž Š l Š Š

12 š œ ž Ÿ ž Knowledge Acquisition and Documentation System B.J. ielinga et al., Amsterdam Methodologie zur Entwicklung wissensbasierter Systeme mit entwickelten Vorgehensweisen zur issenserhebung (Elizitation) sowie der Interpretation und Dokumentation Betonung der issensebene: Mit der Erstellung eines im Prinzip vollständigen konzeptuellen Modells vor allen Implementierungserwägungen steht KADS im bewußten Gegensatz zum Rapid Prototyping (implementationsunabhängige Modellierung von Expertenwissen) ƒ ˆ Š Œ Ž Š Š ˆ Ž Š l Š Š š œ ž Ÿ ž Unterstützung der Konstruktion von issensmodellen durch Beschreibungssprachen und darin beschriebenen Katalogen von Standardmodellen: Interpretationsmodelle Interpretationsmodelle geben für bestimmte Aufgabenklassen (ähnlich den generischen Aufgaben) einen Problemlösemechanismus an. Sie sind auf mehreren Ebenen spezifiziert. Auf dieser Basis modellgeleitete Analyse des Experten- (problemlösungs-)wissens anhand der erhobenen Daten ("model-driven" statt "data driven") Das konzeptuelle (Beschreibungs-)modell ist die Grundlage für ein sog. Designmodell des zu erstellenden Systems. ƒ ˆ Š Œ Ž Š Š ˆ Ž Š l Š Š

13 š œ ž Ÿ ž Beobachtungen E E L L T T Aktionen Beschreibung der Expertise: gesehen durch die "KADS-Brille" (Bibliothek von Interpretationsmodellen) Experte Fakten Annahmen abgeleitetes issen System Konzeptuelles Modell Designmodell Externe Anforderungen an das zu entwerfende System Fakten Annahmen abgeleitetes issen ƒ ˆ Š Œ Ž Š Š ˆ Ž Š l Š Š š œ ž Ÿ ž Strategieebene Aufgabenebene Inferenzebene Bereichsebene Analyse > Design Funktionale Schicht Behaviorale Schicht Strukturelle Schicht ƒ ˆ Š Œ Ž Š Š ˆ Ž Š l Š Š

14 š œ ž Ÿ ž Bereichsebene (domain level) Beschreibung von Fachbegriffen und Relationen dazwischen (in Form von Regeln) Inferenzebene (inference level) Einteilung der Fachbegriffe und Relationen gemäß ihrer Rolle beim Problemlösen in Metaklassen und issensquellen Aufgabenebene (task level) Formulierung generischer Problemlösungsstrategien mit den definierten Metaklassen und issensquellen Strategieebene (strategic level) Erfolgsüberwachung und echsel zwischen verschiedenen Problemlösungsstrategien ƒ ˆ Š Œ Ž Š Š ˆ Ž Š l Š Š À ÁÂ Ã Ä Å ÁÆ Ç Æ È ÁÃ ÉÃ Ê Ã É Ë Metaklassen teilen die auf Bereichsebene identifizierten Fachbegriffe ein. Beispiele für typische Metaklassen in der Diagnostik: Ì Symptome (z.b. Brustschmerz) Ì Prädispositionsfaktoren (z.b. Alter) Ì Verdachtsdiagnosen Ì Enddiagnosen Ì Therapien ACHTUNG: Fachbegriffe können in verschiedene Metaklassen fallen, z.b. Infektion : Ì Verdachtsdiagnose (zu bestätigen) Ì Enddiagnose (Therapie auswählen) Ì Symptom (für andere Diagnosen) ª «± ² ³ µ ² ¹ ² µ º» ² ¼ ² µ º ³ ² ½ ¾

15 À ÁÂ Ã Ä Å ÁÆ Ç Æ È ÁÃ ÉÃ Ê Ã É Ë issensquellen setzen Metaklassen in Beziehung und klassifizieren Inferenzwissen, z.b. als verschiedene Typen von Regeln: Î Verdachtgenerierungsregeln Î Verdachtüberprüfungsregeln Î Indikationsregeln Metaklassen und issensquellen sind das Vokabular für die Charakterisierung der Problemlösestrategie auf der Aufgabenebene. ª «± ² ³ µ ² ¹ ² µ º» ² ¼ ² µ º ³ ² ½ Í À ÁÂ Ã Ä Å ÁÆ Ç Æ È ÁÃ ÉÃ Ê Ã É Ë Beispiel: Inference-level-Skizze der Hypothesize-and-Test-Strategie Metaklassen gruppieren die auf der Bereichsebene identifizierten (durch Fachbegriffe beschriebenen) Objekte/Merkmale in Klassen, die im Hinblick auf die Problemlösung signifikant sind. issensquellen gruppieren die auf der Bereichsebene identifizierten Relationen zwischen Bereichsobjekten (z.b. bereichsspezifische Inferenzregeln) nach Typen, die für die Problemlösung signifikant sind. Indikationsregeln Symptome Verdachtsdiagnosen Verdachtgenerierungsregeln Verdachtüberprüfungsregeln Etablierte Diagnosen ª «± ² ³ µ ² ¹ ² µ º» ² ¼ ² µ º ³ ² ½ Ï

16 À ÁÂ Ã Ä Å ÁÆ Ç Æ È ÁÃ ÉÃ Ê Ã É Ë KADS ist mittlerweile in einem großangelegten europäischen Programm weitgehend ausgearbeitet und standardisiert worden ("Common KADS"), wenn auch mit Abstrichen: Strategieebene wurde nicht umgesetzt. Die Bedeutung der konzeptuellen Modelle beruht darin, daß eine Problemanalyse schwer ohne Vorwissen durchführbar ist: Das Vorwissen sind die auf vergleichende Interpretation vieler Domänen bezogenen Interpretationsmodelle. Die Anwendung dieses Repertoires bleibt der Interpretationsund Urteilsfähigkeit der Knowledge Engineers vorbehalten. ª «± ² ³ µ ² ¹ ² µ º» ² ¼ ² µ º ³ ² ½ Ð À ÁÂ Ã Ä Å ÁÆ Ç Æ È ÁÃ ÉÃ Ê Ã É Ë als Überblickstext siehe in Görz, Einführung in die Künstliche Intelligenz, Kapitel ª «± ² ³ µ ² ¹ ² µ º» ² ¼ ² µ º ³ ² ½