Phasen beim Knowledge Engineering
Erläuterung der Phasen
• Knowledge Engineering: Gesamter Erstellungs- und War- tungsprozess eines wissensbasierten Systems einschl. Mach- barkeitsstudien, Entwicklung, Anpassung oder Auswahl von Werkzeugsystemen, Wissensakquisition, Integration, Wartung.
• Wissensakquisition: Wissenserhebung aus verschiedenen Wissensquellen (eigene Erfahrung, Experten, Bücher, Hand- bücher, Lexika, etc.) und anschließende Formalisierung, Vali- dierung und Wartung.
• Wissenserhebung: Explizitmachen der für ein WBS not- wendigen Expertise einschl. Dokumentation, z.B. durch Befragen von Experten oder durch Sammlung von (vorhan- denem) relevanten schriftlichen Material. Wissenserhebung ist überwiegend Datensammlung.
• Wissensinterpretation (Wissensidentifikation, Wissens-
analyse): Interpretation des Wissens zu einem "mentalen kon- zeptuellen Modell", das Voraussetzung für die anschließende Formalisierung ist. Wissensinterpretation erfordert viel fach- spezifisches Vorwissen und Allgemeinwissen.
• Rapid Prototyping: Direkte Formalisierung des mentalen konzeptuellen Modells
• Modellbasierte Formalisierung: Explizite Beschreibung des mentalen konzeptuellen Modells. Neukonstruktion oder
Auswahl aus vorhandenen Interpretationsmodellen (Problemlösungsmethoden).
• Wissensoperationalisierung: Umsetzung des interpretier- ten Wissens in operationale Wissensrepräsentationsformalis- men. Bei der Modellbasierten Formalisierung vor allem das Ausfüllen des Modells mit anwendungsspezifischen Wissen.
• Integration des Systems: Kopplung zu anderen DV-Syste- men, Schulung des Personals.
• Wartung des Systems: Kontinuierliche Weiterentwicklung und Aktualisierung; Einbinden neuer Versionen der Basis- software + Wartung und Aktualisierung der Wissensbasis.
Rapid Prototyping versus modellbasierte Formalisierung
Rapid Prototyping
Anhand einer kleinen Menge von erhobenen Fallbeispielen wird ein Prototyp des WBS konstruiert, der aufgrund weiterer
Erhebungen sukzessive erweitert und verfeinert wird, bis er die gewünschten Anforderungen erfüllt. Anschließend wird der Prototyp durch ein strukturiertes Softwaresystem ersetzt.
Vorteile:
• Schnelle Überprüfbarkeit des Wissenstransfers, der Wissensqualität, der Wissensrepräsentation, der
Benutzungsoberfläche und des Gesamtverhaltens durch XP und Wissensingenieur.
• Management und Benutzer können früh einbezogen werden;
kurze Feedback-Zyklen.
Nachteile:
• Mentales konzeptuelles Modell wird sehr früh "vorent- schieden", bleibt implizit und wird durch die verfügbare Implementierungssprache (Wissensrepräsentations- formalismen) beeinflusst. Revisionen sind schwierig.
• Repräsentation der Expertise entspricht wegen schneller Implementierung nicht der Begriffswelt des XP.
Modellbasierte Formalisierung
Wichtigster Unterschied zu Rapid Prototyping: Strenge
Trennung von Datenanalyse bzw. -interpretation einerseits und Repräsentation der interpretierten Daten andererseits. Es
werden Entscheidungen über das Modell auf einer abstrakten Ebene getroffen.
Vor- und Nachteile: umgekehrt wie bei Rapid Prototyping.
Prototyping nach Buchanan et al. (1)
Anforderungen
Konzepte
Strukturen
Regeln
Identifikation: Identifiziere die Eigenschaften des Problems.
Konzeptionalisierung: Finde Konzepte zur Wissensrepräsentation.
Formalisierung: Konkretisiere die Wissensrepräsentation.
Implementierung: Formuliere Regeln für das Wissen.
Testen: Validiere die Regeln und die Wissensrepräsentation
I. Identifikation:
• der Mitwirkenden am Projekt und deren Rollen: Zusammen- stellen einer Projektgruppe: XP, WE, Management, Benutzer.
• des Problems: Problemklasse? Problemcharakterisierung?
Unterprobleme? Verfügbare Eingabedaten? Art der
Problemlösungen? Aspekte menschlicher Expertise? Art des relevanten Wissen des XP?
• der Resourcen? Geld? Entwicklungszeit? Hard/Software- Rahmenbedingungen für Entwicklung und Nutzung?
Verfügbarkeit von XP?
II. Konzeptualisierung
Erhebung und Vorstrukturierung von Konzepten und Relationen aus dem Wissensbereich. Eventuell schon Implementierung eines Prototyp für Teilprobleme.
Prototyping nach Buchanan et al. (2)
III. Formalisierung
Abbildung der vorstrukturieren Daten aus der Konzeptuali- sierungsphase in die Repräsentationsformalismen des aus- gewählten Werkzeuges. Wichtige Faktoren:
• Lösungsraum
¾ Formalisierung der Konzepte und Definition ihrer Relation zu den Hypothesen
¾ Granularität und Struktur von Konzepten
¾ Einteilung der Konzepte in primitive und strukturierte Objekte
¾ Explizite Repräsentation kausaler, räumlicher oder zeit- licher Relationen?
¾ Hypothesenraum: endlich? in Klassen einteilbar?
hierarchisch? unsicher?
¾ Abstraktionsstufen?
• zugrundeliegende Prozessmodell (Problemlösungsmethode)
• Charakteristika der Daten
¾ Daten dünn verteilt & unvollständig oder dicht & redundant?
¾ unsichere Daten?
¾ zeitlich variable Daten?
¾ Kosten zur Datenerhebung?
¾ Datenvorverarbeitung notwendig (z.B. Geräusche, )
¾ Zuverlässigkeit der Daten
¾ Konsistenz und Vollständigkeit der Daten IV. Implementierung
Aus dem formalisierten Wissen wird eine WBS-Prototyp gebaut.
Prototyping nach Buchanan et al. (3)
V. Testen
Überprüfen von Wissensbasis & Inferenzstruktur mit Testbeispielen
• Dialog dauert zu lange, zu teure Untersuchungen
¾ zu viele Fragen, schlechte Dialogsteuerung
¾ zu niedrige Abstraktionsebene
• Falsche Ergebnisse
¾ Falsche Eingabedaten -> unverständliche Fragen
¾ Fehler in Wissensbasis
¾ Mängel in Wissensrepräsentation
¾ Fehler in Kontrollstrategie
¾ Fallbeispiele außerhalb des Kompetenzbereiches
• Ungenaue Ergebnisse
¾ Erfassen von zu wenig Daten,
¾ zu hohe Abstraktionsebene
Grenzen des Rapid Prototyping
Gefahr: Unkritische Wahl von Regeln als uniforme
Wissensrepräsentation, da sich Regeln für Rapid Prototyping besonders gut eignen (Prototyp schon mit wenigen Regeln lauffähig)
• Anfängliche Vernachlässigung von Kontrollwissen, da implizit im Regelinterpreter enthalten. Später werden komplexe Kon- trollstrategien durch Flags, Zähler oder Regelanordnungen erzwungen.
• Vermischung verschiedener Arten von Wissen in Regeln, so dass die eigentliche Bedeutung der Regel nur schwer zu erkennen ist. Daher auch beschränkte Erklärungsfähigkeit.
• Kontinuierliches Wachstum der Regelmenge führt mangels Strukturen zu „Regelspaghetti“. Wegen schwer
durchschaubarer Regelabhängigkeiten änderungsfeindlich.
Gegenmaßnahmen: Je allgemeiner die Wissensrepräsenta- tion, desto dringender Dokumente, die die zugrundeliegenden Ideen festhalten, z.B.
• Zugrunde liegende Problemlösungsmethoden (als „Muster“)
• Strukturierung von Regelvorbedingungen (z.B. Trigger, Kern, Kontext, Ausnahmen) und Regelaktionen (z.B. Inferenz,
Dialogsteuerung)
• Modularisierung der Regeln
• Trennung des Wissens (nach Clancey)
¾ strategisches Wissen: Wissen über Vorgehensweisen wie Dialogsteuerung, Abarbeitungsreihenfolge von
Hypothesen etc.)
¾ strukturelles Wissen: Wissen über die Herleitung von Objekten (Diagnosen, Konfigurationen)
¾ unterstützendes Wissen: Wissen zur Rechtfertigung (z.B. Verweise auf Literatur, Metaphern, kausale
Prozesse, Definitionen etc.)
Rapid Prototyping als Hilfsmittel (nicht als Entwurfsmethode)
Es soll vor der Prototypentwicklung klar sein, was, wie und von wem evaluiert wird. Tests mit nicht-trivialen Problemen.
Explorativer Prototyp zur Abklärung von Anforderungen und wünschenswerten Eigenschaften, auch mit Benutzern, z.B.:
• Festlegung der Anforderungen an Entwurfswerkzeug
• Feststellen der Anforderungen an Benutzungsoberfläche
• Besseres Verständnis für die Problemstellung
Experimenteller Prototyp zur Eignungsprüfung alternativer Ansätze während der Systementwicklung, z.B.:
• Überprüfung der Anwendbarkeit bereits bekannter Softwarelösungen und Algorithmen
• Überprüfung von Softwarelösungen
• Aufwands- bzw. Effizienzabschätzungen
Typen experimenteller Prototypen nach Floyd:
• Volle funktionale Simulation: einfache Anpassbarkeit, Vernachlässigung von Performanz und Spezialfällen
• partielle funktionale Simulation zur Überprüfung unklarer Aspekte, z.B. kritische Annahmen, Performanz,
Ressourcenverbrauch
• Programmieren des Skeletts des Systems zur Überpfüfung der globalen Systemstruktur und Kommunikation zwischen Modulen
• Konstruktion einer Basismaschinerie, um früh Grundfunktionen bereitstellen zu können
Shell-orientierte Wissensakquisition
Vorhandensein von problemspezifischen Werkzeugen (Shells) kann Vorteile von Rapid Prototyping und modellbasiertem Entwurf kombi- nieren, wenn Modell passt, aber birgt die Gefahr des Prokrustesbettes.
BESCHREIBUNG
Identifikation der Problemlösungs- strategie und der Wissensrepräsentation
Bereitstellung eines Expertensystem-Shells mit komfortabler Wissenserwerbs- komponente
Formalisierung des Expertenwissens
Tuning und
Weiterentwicklung, Anpassung an neue oder geänderte Anforderungen
DURCHFÜHRUNG
Wissensingenieur befragt
Experten
Auswahl oder Neuentwicklung durch den
Wissensingenieur
Experte, eventuell unterstützt durch Wissensingenieur
Experte, eventuell unterstützt durch automatische Analysetechniken
HILFSMITTEL
Interviewtechniken und
Protokolle
allgemeines Expertensystem- Werkzeug
Shell
Falldatenbank PHASEN
Problemcha- rakterisierung
Shell- Entwicklung
Aufbau der Wissensbasis
Wartung der Wissensbasis
Zeitersparnis bei der Entwicklung
Beschränkung des Einsatzgebietes universelle Programmiersprachen
1
allgemeine Werkzeuge für Basiswissensrepräsentationen
2
problemspezifische Werkzeuge
3
bereichsspezifische Werkzeuge
4
Werkzeugtypen zur Erstellung wissensbasierter Systeme
• Generalisierung erfolgreicher XPS-Implementierungen
¾ (MYCIN->EMYCIN)
• Wissensbasiseditoren für spezialisierte Architekturen
¾ (TEIRESIAS)
• Allgemeine Werkzeuge für die Erstellung von WBS
¾ (KEE, BABYLON); Nexpert Object, Kappa,...
• Problemspezifische Werkzeuge für die Erstellung von WBS
¾ (MED2, PLAKON, COKE); D3, KONWERK, ...
• Wissensakquisitionswerkzeuge
¾ allgemein: (ETS), PC-PACK
¾ problemlösungsspezifisch: CLASSIKA, PROTEGE
¾ anwendungsspezifisch: (OPAL)
• Wissensmodellierungssprachen: UML, KADS
• Modellbibliotheken
Modellbasierter Entwurf
Modell: (abstrakte) Beschreibung der Schlussfolgerungs- strukturen und dazugehörigen Wissensrepräsentationen.
Grundlegende Unterscheidung:
• Analytische Modelle (Klassifikation, Diagnostik): Auswahl von Lösungen. Charakteristisch ist die endliche und verhältnismäßig kleine Anzahl potentieller Lösungen.
• Synthetische Modelle (Konstruktion): Lösung wird nicht ausgewählt sondern (aus Bausteinen) konstruiert.
Wichtige Aspekte der Klassifikation
• Wissensarten:
¾ Sicheres Wissen: Entscheidungsbäume und -tabellen
¾ Heuristisches Wissen: Lösung akkumuliert Evidenzen von Merkmalen (Diagnosescore, heuristische Entscheidungs- bäume und -tabellen)
¾ Modellbasiertes Wissen: Lösung soll in einem (struktu- rellem, funktionalem, überdeckendem) Modell alle Merkma- le erklären
¾ Fallbasiertes Wissen: direkter Fallvergleich, statische Aus- wertung, neuronale Netze, induktives Lernen
• Vorgehensweisen:
¾ Hierarchisches Verfeinern (Establish Refine)
¾ Hypothesize-and-Test
¾ Vorwärtsverkettung
¾ Rückwärtsverkettung
• Zwischenstufen im Wissensmodell
¾ keine (bipartiter Graph)
¾ Merkmalsabstraktionen
¾ Lösungsheterarchien
• Problemtypen
¾ statische Fehlersuche
¾ dynamische Fehlersuche
¾ einfache Bewertung
¾ multiple Bewertung
¾ Präzedenzauswahl
¾ Objekt-Identifikation
• Problemeigenschaften
¾ Mehrfach-Lösungen
¾ Unzuverlässige Merkmale (z.B. unsicher, subjektiv, falsch)
¾ Parametrisierbare Merkmale und Lösungen (Varianten)
Wichtige Aspekte der Konstruktion
• Schwierigkeitsgrad:
¾ Kreativer Entwurf: völlige Neuschöpfung (patentierbar)
¾ Innovativer Entwurf: Neuartige Kombination bekannter Teillösungen
¾ Routineentwurf: Entwurfsprinzip und Teillösungen bekannt
• Problemeigenschaften
¾ Auswahl bzw. Instanziierung von Konstruktionselementen notwendig?
¾ Spezialisierung von Konstruktionselementen notwendig (in Teil/Ganzes und/oder Verfeinerungshierarchien)?
¾ Parametrierung von Konstruktionselementen notwendig?
¾ Anordnung der Konstruktionselemente notwendig (insbesondere: zeitliche oder räumliche Anordnung)?
¾ harte und oder weiche Randbedingungen?
¾ lokale oder globale Randbedingungen?
• Aufgabentypen für Routineentwurf:
¾ Anordnung: Parameter festgelegt oder unwichtig; (ein-, zwei- oder dreidimensionale) Anordnung der Objekte gesucht
¾ Parametrierung (Dimensionierung): Anordnung unwichtig oder bekannt, Werte für Parameter gesucht.
¾ Konfigurierung: Auswählen, instanziieren, zusammensetzen
& parametrieren von Objekt(Komponenten)typen.
¾ Planung: Finden einer Folge von Operationen, die einen Start- in einen Zielzustand überführen
¾ Zuordnung (Scheduling): Abbildung einer diskreten Menge von Objekten auf eine diskrete oder (zeitlich) kontinuierliche zweite Menge unter Beachtung von Randbedingungen.
• Vorgehensweisen
¾ Skelett-Konstruieren
¾ Vorschlagen-und-Verbessern / Vorschlagen-und-Vertauschen
¾ Constraint-Propagieren
¾ Fallbasiertes Änderungskonfigurieren
¾ Allgemeine und Heuristische Suchtechniken
¾ Planungstechniken, z.B. Regressionsplanen, Partial Order Planning
KADS / COMMONKADS
Knowledge Acquisition Documentation and Structuring Knowledge Analysis and Design System
Entwicklung in zwei Esprit-Projekte mit zahlreichen Partnern (Hauptpartner: Universität Amsterdam):
• KADS: 1983-1989
• KADS II (COMMONKADS): 1989-1994
Ziel: Strukturierte, modellbasierte Entwicklung von Wissensbasierten Systemen:
• Ergebnisperspektive: Eine Menge von Modellen von verschiedenen Aspekten von WBS und seiner Umgebung, die kontinuierlich während des Lebenszyklus verbessert werden
• Projekt Management Perspektive: Eine risiko-orientiertes, an spezifische Projekte anpassbares Spiralmodell
Stand: Gut dokumentierte, praktisch eingesetzte Methodologie
Literatur: S. Schreiber et al.: Knowledge Engineering and Management: The COMMONKADS Methodology, MIT-Press, 2000.
Modelle in COMMONKADS zur Spezifikation von WBS
Unterschied zwischen Daten, Information und Wissen:
Charakterisierung Beispiel
Daten: uninterpretierte Rohdaten …---…
Information: Daten mit Bedeutung SOS
Wissen: Information über Informationen Notfall → Starte Rettungsaktion
(zielorientiert, generativ)
Beispiel zu Unterschied zwischen Information und Wissen aus Bankapplikation:
Information (Klassendiagramm mit Instanzen):
John has a loan of 1750 €.
Harry has a loan of 2500 €.
Wissen (in Form von Regeln der Bank):
Eine darlehensfähige Person sollte mindestens 18 Jahre alt sein.
Eine Person mit einem Jahreseinkommen von 10000 € kann maximal 2000 € Darlehen bekommen.
Bei 10000 und 20000 € Einkommen kann man maximal 3000 € Darlehen bekommen.
Wissensstrukturierung
Warum nicht alle Regeln in einer flachen Wissensbasis ablegen? → zu unstrukturiert
→ Wissensmodellierung erforderlich!
Wissenskategorien im Wissensmodell
Notationen für Wissensmodellierung
Domänen-Ebene: Ähnlich wie UML-Klassendiagramm (ohne Operationen) Inferenz-Ebene: Inferenz-Diagramme
Task-Ebene: Dekompositionsdiagramme, Aktivitätsdiagramme, Pseudocode
Domänen-Wissen
statisches Wissen, bestehend aus:
1. Domänen-Schema (Wissensrepräsentation) 2. Wissensbasis
Kernelemente zur Spezifikation des Domänen-Schemas:
• Konzepte: Attribute, Werttypen (ähnlich wie in UML-Klassendiagrammen)
• Relationen: Beziehungen zwischen Konzepten, Kardinalität; ähnlich wie in UML)
• Regel-Typen: neu im Vergleich zu UML; spezieller Typ von Relationen; aber nicht zwischen Konzepten, sondern zwischen (logischen) Ausdrücken über Konzepten
Beispiel für Wissenselemente (Auto-Diagnose)
Grafische und textuelle Spezifikation von Konzepten
Vererbung zwischen Konzepten
Regeltypen (causes: 2,3,6,7,8,9; has manifestation: 1,4,5)
Regeln drücken nicht Beziehungen zwischen Konzepten wie Relationen aus, sondern Beziehungen zwischen Ausdrücken über Konzepten (z.B. Fuel-tank.status = empty → Gas-in-Engine.status = false)
Rule-type:
State-dependency Antecendent:
Invisible-car-state Cardinality: 1 Consequent:
Car-state Cardinality: 1 Connection- symbol: causes
Regeltypen (2)
Notation für Wissensbasis (Auto-Diagnose-Domäne)
KNOWLEDGE-BASE car-network;
USES:
state-dependency FROM car-diagnosis-schema, manifestation-rule FROM car-diagnosis-schema;
EXPRESSIONS:
/* state dependencies */
fuse.status = blown CAUSES power.status = off;
battery.status = low CAUSES power.status = off;
power.status = off CAUSES engine-behavior.status = does-not-start;
fuel-tank.status = empty CAUSES gas-in-engine.status = false;
gas-in-engine.status = false CAUSES engine-behavior.status = does-not-start;
gas-in-engine.status = false CAUSES engine-behavior.status = stops;
/* manifestation rules */
fuse.status = blown HAS-MANIFESTATION fuse-inspection.value = broken;
battery.status = low HAS-MANIFESTATION battery-dial.value = zero;
fuel-tank.status = empty HAS-MANIFESTATION gas-dial.value = zero;
END KNOWLEDGE-BASE car-network;
Inferenzwissen
beschreibt, wie statisches Domänen-Wissen für die Wissensverarbeitung genutzt wird.
Inferenzen: primitive informationsverarbeitende Einheiten, die Wissen nutzen, um aus Informationen neue Informationen herzuleiten.
Inferenzen beziehen sich auf Wissensrollen (funktionale Rollen von Konzepten).
Beispiel:
INFERENCE cover; ROLES: INPUT: complaint; OUTPUT: hypothesis; STATIC: causal-model;
SPECIFICATION: "Each time the inference is invoked, it generates a candidate solution that could have caused the complaint. The output should be an initial state in the state-dependency network which causally Icovers' the input complaint.“
END INFERENCE cover;
KNOWLEDGE-ROLE complaint; TYPE: DYNAMIC; DOMAIN-MAPPING: visible-state;
END KNOWLEDGE-ROLE complaint;
KNOWLEDGE-ROLE hypothesis; TYPE: DYNAMIC; DOMAIN-MAPPING: invisible-state;
END KNOWLEDGE-ROLE hypothesis;
KNOWLEDGE-ROLE causal-model; TYPE: STATIC;
DOMAIN-MAPPING: state-dependency FROM car-network;
END KNOWLEDGE-ROLE causal-model;
Grafische Darstellung von Inferenzen
Transfer-Funktionen: Kommunikation mit externer Welt
Beispiel für Inferenzstruktur (überdeckende Diagnostik)
Beispiel für Inferenzstruktur mit Domänen-Bezug
Aufgabenwissen (Task knowledge)
Beschreibt
• Task: Ziele (was muß getan werden) mit Input-Output-Beziehung
• Task Method: Strategien zur Erreichung der Ziele (wie wird es getan); umfasst Dekomposition in Inferenzen und Kontrollwissen).
Beispiel für Dekomposition:
Beispiel für Spezifikation der Car-Diagnosis-Task
Beispiel für Spezifikation einer Car-
Diagnosis-Method
Grafische Darstellung einer Task-Methode als
Aktivitätsdiagramm (UML)
Beispiele für Modellbibliotheken (Auszug):
Inferenzdiagramme für verschiedene Problemlösungsmethoden
1. Diagnose durch Ausschluss 2. Bewertung (Assessment) 3. Monitoring
4. Vorschlagen & Verbessern
Beispiel 1: Diagnose durch Ausschluss
Beispiel 2: Bewertung (Assessment)
Beispiel 3: Monitoring
Beispiel 4: Vorschlagen & Verbessern
Zentrale Domänen-Konzepte für Vorschlagen&Verbessern
Unterschiede KADS vs. andere Modellierungssprachen (z.B. UML)
1. „Datenmodell“ vom Wissensmodell enthält sowohl Daten als auch Wissen Æ Regeltyp
2. „Funktionen“ werden unabhängig vom Datenmodell beschrieben: Inferenzen beziehen sich auf Rollen, die nicht unbedingt Datenmodell-Elemente sind.
3. Notwendigkeit der Repräsentation „interner“ Kontrolle: Task-Kontollstruktur 4. Wissensmodell abstrahiert von Kommunikationsaspekten
