Professioneller Einsatz von Expertensystemen bleibt zunächst eng begrenzt:

Erst DBMS-Ehe bringt KI. einen Schritt weiter

06.12.1985

Die Einsatzmöglichkeiten logischer Programmiersysteme sind oft auf Teile von Gesamtlösungen begrenzt. Erst In Kombination Mit anderer Software, beispielsweise mit Datenbanksystemen, lassen sich größere Anwendungsgebiete erschließen. Hermann Bense* versucht in seinem Beitrag, die Erwartungshaltung an Expertensysteme auf ein realistisches Maß zurückzuschrauben.

Gegen Ende der sechziger Jahre kamen die ersten Produkte auf, von denen man heute sagen würde, es handelt sich um Expertensysteme. "Dendral", ein in Standford entwickeltes System zur Analyse von Massenspektren und "Mycin", ein System zur Diagnose und Therapie von bakteriellen Infektionen, das ebenfalls in Standford entwickelt wurde, sind die vielzitierten Beispiele für den Beginn dieser Entwicklung. Ein Gebiet, welches anerkanntermaßen zur KI gezählt wird, ist die Spracherkennung. Auch hier gibt es frühzeitige Entwicklungen, die mit dem Projekt "Hearsay-I" begannen. Die von MacCarthy entwickelte funktionale Programmiersprache Lisp diente fast ausschließlich als Implementierungswerkzeug der frühen Expertensysteme.

Mittlerweile hat die hauptsächlich von den Japanern favorisierte logische Programmiersprache Prolog ,die Ende der 70er Jahre ihren. Ursprung in Europa hat, enorm an Bedeutung gewonnen. Im Rahmen der FGCS (Fifth Generation Computer Systems) bildet sie den Kern, um den neue Computerarchitekten mit enormen Rechengeschwindigkeiten und Speicherkapazitäten entwickelt werden. Die Einheit, in der Computerleistungen nunmehr gemessen werden, sind die LIPS (Logical Inferences per Second). Damit wird die Anzahl der Ableitungsschritte eines logischen Programmes bezeichnet. Heute werden bereits von Prototypen mehrere 10 000 LIPS erreicht.

Minimalanforderungen stehen bereits fest

Obwohl hier und da noch Uneinigkeiten bestehen, wann man ein System als Expertensystem bezeichnen darf, haben sich einige Funktionen und Komponenten solcher Systeme herauskristallisiert, die man als Minimalforderung gerne realisiert hätte. In der Wissensbasis werden große Mengen von Fakten, Regeln und Metaregeln (Regeln über Regeln) in geeigneter Form abgelegt. Eine Problemlösungskomponente (andere Begriffe: Deduktions-/Ableitungskomponente, Inference Machine) verarbeitet die gestellten Anfragen aufgrund des vorgefundenen Wissens. Gegenüber den meisten anderen Programmsystemen ist ein Expertensystem dann auch in der Lage, mit seiner Erklärungskomponente den Hergang der Lösung zu dokumentieren und dem Anwender andere Lösungswege leicht zugänglich zu machen.

In jüngster Zeit ist ein starkes Engagement der Datenbänkler-Gemeinde im KI-Bereich feststellbar. Mehr als 40 Prozent der Beiträge zur VLDB-Konferenz (Very Large Data Base), die im August 1985 in Stockholm stattfand, befaßte sich direkt oder indirekt mit diesem Thema. Nicht ohne Grund - denn beide Bereiche wollen natürlich voneinander profitieren.

Dabei ergeben sich folgende Perspektiven: Auf der Datenbankseite ist man an Abfragesprachen und Methoden zur Wissensspeicherung interessiert, die über das hinaus gehen, was derzeit mit den Standard-Datenmodellen, wie dem Relationen- oder Netzwerk-Ansatz möglich ist. Insbesondere besteht Interesse an Abfragesprachen, die auch rekursive Sprachelemente bereitstellen. Damit könnte man dann auch Abfragen formulieren wie, "Finde zu einer Person alle Nachkommen". Diese Anfrage läßt sich nicht in einem geschlossenen Ausdruck in einer der relationalen Abfragesprachen wie SWL, QBE oder QUEL ausdrücken. Auf der Seite der Datenmodelle ist man sich der Unzulänglichkeit der existierenden Ansätze bewußt. Aus der Not wurden die sogenannten sematischen Datenmodelle geboren, die bisher aber nur Bedeutung im Wissenschaftsbereich gefunden haben. Sie ermöglichen die Strukturierung komplexer Objekte und die Formulierung von Integritätsbedingungen, die konsistente Zustände von Datenbanken beschreiben. In den zuletzt erwähnten Bereichen gibt es dann auch die direkten Berührungspunkte zur KI.

Der eigentliche Punkt, der Datenbankanwendungen rein quantitativ von KI-Anwendungen unterscheidet, liegt darin, daß es in Datenbanksystemen sehr viele Objekte des gleichen Typs gibt (Datei, Relation), während es umgekehrt im KI-Bereich "normalerweise" sehr viele Typen mit nur wenigen Objektausprägungen gibt. In dem "normalerweise" steckt nun der kritische Punkt für KI-Systeme. Die älteren eingangs zitierten Expertensysteme entsprachen tatsächlich der gerade beschriebenen Charakteristik.

Immer mehr zeichnet es sich allerdings ab, daß in KI-Anwendungen er neblige Mengen von Fakten verwaltet werden müssen. Zum anderen ist abzusehen, daß das Expertenwissen in Zukunft nicht nur einer einzelnen Person, sondern ganzen Benutzergruppen abrufbar gemacht werden muß. Die Mehrbenutzerfähigkeit, mit allen damit verbundenen Aspekten wie Transaktionen, Backup und Recovery, ist in der Regel eine Domäne der DBMS. Natürlich sind Datenbanksysteme auch von Haus aus dafür prädestiniert, sehr große Datenmengen zu verwalten.

Integrationsansätze gemeinsam entwickeln

Die Frage, die sich nun stellt ist: Wie weit kann man aus beiden Ansätzen die Tugenden herauslösen und in ein integriertes System einbringen, das die Vorteile beider Systeme an den Benutzer weitergibt? Innerhalb des von der Europäischen Gemeinschaft geförderten Esprit-Projektes (European Strategic Programme for Research and Development in Information Technology) versuchen Wissenschaftler aus Italien (Pisa, Mailand), Frankreich, (Lyon, Grenoble) und Deutschland (Dortmund). Ansätze für die Integration von Datenbank- und Expertensystemen zu entwickeln. Dabei werden verschiedene alternative Linien verfolgt, je nach dem, ob an der Benutzeroberfläche mehr eine logische Programmierumgebung oder eine Datenbankumgebung gewünscht wird.

Die grundsätzliche Problematik soll in der Abbildung veranschaulich werden: Zwischen beiden Systemtypen klafft nämlich eine erhebliche technologische Lücke. Während logische Programmiersysteme eine relativ kleine Menge von Objekten (bis zirka 100) sehr schnell verknüpfen (103 bis 104 LIPS), können Datenbanksysteme sehr große Mengen von Objekten nur mit mäßiger Geschwindigkeit verarbeiten (maximal zirka 100 Transaktionen pro Sekunde). Jeder Versuch, eine Kombination aus beiden Systemtypen zu schaffen, kann von der Leistungsfähigkeit gesehen nur zwischen den beiden Extremen liegen. Folgende Ansätze sollen daher in dem Esprit-Projekt auch unter Leistungsaspekten untersucht werden.

Konzept gilt für alle DBs

Die Abfragesprache eines Datenbanksystems wird erweitert, so daß auch rekursive und deduktive Anfragen beantwortet werden können. Bei deduktiven Systemen ist es auch möglich, durch Anwendung von Regeln auf Sätze der Datenbank neues Wissen abzuleiten. Der Benutzer braucht in seiner Datenbankabfrage nicht zu unterscheiden, ob er mit tatsächlich abgespeicherten Daten arbeitet, oder ob die Daten erst bei der Beantwortung der Abfrage gewonnen werden. Für die Realisierung eines solchen Konzeptes ist es unwesentlich, welches Datenbanksystem und welche Abfragesprache zum Einsatz kommt. An der Universität Lyon wurde zum Beispiel das Netzwerk-Datenbanksystem IDMS nach Codasyl-Norm um eine entsprechende deduktive Komponente erweitert. Einen vergleichbaren Versuch führten Wissenschaftler an der Universität Dortmund in der Projektgruppe "Dedudab" (Deduktive Datenbanken) für das relationale Datenbanksystem "Ingres" und die Abfragesprache "Quel/Equel" durch. Die Meßergebnisse im letzten Fall gaben keinen Anlaß zu der Hoffnung, daß unter den damals bestehenden Voraussetzungen vernünftige Antwortzeiten zu erwarten waren.

Mehr Erfolg verspricht der korrespondierende umgekehrte Ansatz. Ausgehend von einer logischen Programmiersprache wie Prolog versucht man den Zugriff auf die Wissensbasis durch Datenbanksysteme zu unterstützen. Insbesondere verfolgen die Japaner im ICOT (Institute for New Generation Computer Technology) diesen Ansatz unter massivem Einsatz von Entwicklungspotential der japanischen Großindustrie. Die Prolog-Programme laufen in sogenannten Personal Sequential Interference Machines (PSI) ab, die über ein lokales Netzwerk verbunden sind.

VLSI-Chips enthalten die Systemkomponenten

Diese Maschinen sind so ausgelegt, daß unter Ausnutzung von möglichst hoher Parallelität in der Abarbeitung (und/oder-Parallelismus in Prolog-Programmen) der Ableitungsprozeß beschleunigt wird. Gewisse Systemkomponenten werden dazu in spezielle VLSI-Chips gegossen.

Genausowenig läßt man sich auf der Seite der Datenbankverwaltung auf Kompromisse ein. Innerhalb eines lokalen Netzwerkes stehen Datenbankserver zur Verfügung (Delta), die als relationale Datenbankmaschinen in Hardware realisiert wurden. Hier will man nicht nur ausnutzen, daß der Zugriff auf einzelne Sätze (Tupel) von Relationen sehr schnell ist, vielmehr wird auch die Optimierungsfähigkeit echter relationaler Datenbanksysteme bei Abfragen ausgenutzt. Oft können nämlich in Prolog gestellte Anfragen leicht in entsprechende Datenbankanfragen umgewandelt werden, wobei das Auffinden passender Variablenbelegung über Joints (Verbunde) der relationalen Abfragesprache realisiert werden kann. Ob diese Systeme die in sie gesetzten Erwartungen erfüllen, darüber ist bisher noch nicht viel bekannt. Bis zur industriellen Fertigung ist es noch ein sehr weiter Weg.

Ein weiterer Ansatz wurde an der Universität Dortmund und im Technologiezentrum Dortmund ebenfalls im Rahmen des oben genannten Esprit-Projektes verfolgt: Die Implementierung eines Prolog-Interpreters für Personal Computer, der auf dem Mikrocomputer Datenbanksystem "System B" aufbaut. Bei diesem unter dem Namen CPDB (Controlled-Prolog-Data-Base) entwickelten System wurden im Unterschied zu den beiden vorher dargestellten Ansätzen folgende Anforderungen in den Vordergrund gesetzt und realisiert: Fakten und Regeln sollen zusammen in der Datenbank abgelegt werden. Das ermöglicht eine einheitliche Verwaltung der virtuellen Speicherverwaltung. Über einen zusätzlichen Literal-Cache wird der Zugriff auf Prolog-Programmteile beschleunigt. Die Komplexität der Ableitung sollte nicht begrenzt sein. Dies wird dadurch erreicht, daß Laufzeit, Stacks ebenfalls extern in der Datenbank verwaltet werden. Schließlich soll der Ableitungsvorgang auch durch geeignete Ausnutzung von Datenbank-Indexen unterstützt werden. Ein interessantes Implementierungsdetail ist, daß die Fakten und Regeln der Prolog-Programme in die Relationen des Datenbanksystems abgelegt werden. Eine Prototyp-Version ist bereits unter dem Namen "MaxProlog2" auf Macintosh-Computern lauffähig.

Wenn man den derzeitigen Entwicklungsstand von Expertensystemen kritisch resümiert, so kann man sagen, daß man gerade am Anfang einer Entwicklung steht. vielfach verhindert einfach die fehlende Geschwindigkeit den praktischen Einsatz auf breiter Basis. Insbesondere fehlen auch benutzerfreundliche Implementierungen für Personal Computer, die einen Durchbruch ermöglichen, wie etwa bei den Spreadsheets und den Datenbanksystemen. Solange hier nichts Grundlegendes passiert, wird der professionelle Einsatz von Expertensystemen zunächst wohl nur einer relativ kleinen Gruppe von "Experten" und den Hochschulen vorbehalten sein.

- Hermann Bense ist Geschäftsführer der Bense KG, Coesfeld.

Literatur:

(ApBe82) Hans-Jürgen Appelrath, Hermann Bense, Abschlußbericht der Projektgruppe Deduktive DB-Systeme- Interner Bericht der Abteilung Informatik, Universität Dortmund, 1982

(ApBe85) Hans-Jürgen Appelrath, Hermann Bense, Zwei Schritte zur Verbesserung von Prolog-Programmiersystemen: DB-Unterstützung und Meta-Interpreter in (B I Pi85), S. 161-176

(Appe85) Hans-Jürgen Appelrath, Von Datenbanken zu Expertensystemen, Informatik Fachberichte 102, SpringerVerlag, Berlin, 1985

(B1 Pi85) Albrecht Blaser, P. Pistor (Hrsg.), Datenbank-Systeme für Büro, Technik und Wissenschaft, GI-Fachtagung, Karlsruhe .20 - 22. 3. 1985, Informatik Fachberichte Nr 34, Springer-Verlag, Berlin ,Heidelberg, New York ,1985

(C1Me81) William F. Clocksin, Christopher S Mellish Programming in Prolog, Springer-Verlag , Berlin, Heidelberg, New York, 1981