Mit ihrer zunehmenden Verbreitung kommen Expertensysteme immer mehr auch in "senitiven" Bereichen zum Einsatz. Aus diesem Grund ist es, so Eberhard Schöneburg*. dringend nötig, neue Methoden und Verfahren zu entwickeln, mit deren Hilfe die Zuverlässigkeit von Expertensystemen überprüft werden kann.
Expertensysteme sind auf dem Vormarsch. Daran kann kein vernünftiger Mensch mehr zweifeln. Das Marktpotential ist riesig, und die Anwendungsgebiete sind so vielfältig, daß fast täglich neue Einsatzformen und Prototypen vorgestellt oder angekündigt werden. Unter den Einsatzgebieten von Expertensystemen sind zunehmend auch Anwendungen in sicherheitskritischen Bereichen zu finden. So plant zum Beispiel das Militär den Einsatz und die Entwicklung autonomer Kampfgeräte (Panzer und Fluggeräte), die zumindest teilweise von Expertensystemen gesteuert und überwacht werden. In der Chemie- und Pharmaindustrie kommen Expertensysteme bei der Produktionsüberwachung zum Einsatz; die Luft- und Raumfahrtindustrie verwendet solche Systeme zur Unterstützung bei Wartungs- und Diagnosearbeiten .
Piloten werden demnächst von sogenannten "Pilots Associates" unterstützt, also von Expertensystemen, die die Aktionen des Piloten überwachen und ihn von Routinearbeiten entlasten sollen. In kerntechnischen Anlagen wird daran gedacht, mit Expertensystemen die Störfalldiagnose zu verbessern. Und schließlich werden in vielen großen Industriebetrieben, die ihre Produktion mit CIM-Methoden verbessern wollen, Expertensysteme zentrale Aufgaben übernehmen und dabei firmenvertrauliche Daten manipulieren. Soweit, so gut. Warum sollten Expertensysteme nicht auch in sicherheitssensitiven Bereichen eingesetzt werden, wenn dadurch eine Effizienzsteigerung möglich ist; und warum sollte man diese, falls notwendig, nicht mit vertraulichen Daten operieren lassen?
Was aber heute gegen den Einsatz von Expertensystemen in sicherheitssensitiven Bereichen spricht, ist die einfache Tatsache, daß es bislang kaum akzeptable Methoden und Verfahren gibt, die korrekte Funktionsweise von Expertensystemen zu garantieren. Die Probleme, die bei dem Versuch Expertensysteme zu verifizieren oder zu validieren, auftauchen, sind extrem vielfältig und komplex.
Die Schwierigkeiten fangen bereits bei den grundlegenden Definitionen an, zum Beispiel bei der Frage, wann ein Expertensystem korrekt arbeitet. Der naheliegende Gedanke, es arbeite dann korrekt, "wenn es tut, was es soll", führt nicht weiter, denn er ist zu stark an konventionellen Programmsystemen orientiert. Ein konventionelles Programm wird im allgemeinen als korrekt in Relation zu seiner Spezifikation angesehen. Es arbeitet dann korrekt, wenn es ausführt, was in der Spezifikation beschrieben, beziehungsweise gefordert wird. Dieser Ansatz führt bei Expertensystemen aber nicht zum Ziel.
Expertensysteme sind nur in den seltensten Fällen "fertige, abgeschlossene" Systeme. Ihr großer Vorteil gegenüber herkömmlichen Programmen liegt darin, daß sie sehr leicht modifizier- und erweiterbar sind, weshalb sie sich schnell veränderten Randbedingungen anpassen lassen.
Künftig werden Expertensysteme sich zunehmend selbst ihrer Umwelt anpassen, indem sie ihre Wissensbasis erweitern oder aus bestimmten Ereignissen und eigenen Reaktionen lernen. Dies ist zum Beispiel sehr sinnvoll für Selbstreparaturmechanismen in Raumstationen und Satelliten. Wenn dem aber so ist, dann macht es keinen großen Sinn, Expertensysteme gegen fixe Spezifikationen zu validieren. Man müßte die Spezifikationen nämlich zyklisch der Systemleistung anpassen. Ein solcher wechselnder Maßstab verfehlt aber ebenso seinen Zweck wie ein Metermaß aus Gummi.
Die Referenz auf eine Spezifikation führt noch aus einem anderen wichtigen Grund nicht zum Ziel. Gewöhnlich ist keineswegs von vornherein klar, welche Aufgaben ein Expertensystem genau erfüllen soll - speziell dann, wenn es eingesetzt werden soll, weil das Anwendungsgebiet nur sehr schwer vollständig zu überschauen ist. In diesem Fall ist nämlich zu Beginn der Entwicklung eventuell noch völlig unklar, inwieweit ein Expertensystem überhaupt das angestrebte Ziel erreichen kann.
Eine Hilfe ist es hier, das Expertensystem in Zyklen schrittweise immer weiter aufzubauen (Schlagwort: Rapid Prototyping) bis der Punkt erreicht wird, an dem die Leistung des Systems zufriedenstellend ist. Die Spezifikation, wenn man sie dann noch so nennen kann, wird nachträglich angefertigt und verliert damit wieder ihren klassischen Sinn als Maßstab.
Prinzipiell ist der Ansatz, ein Programm (ob konventionell oder auf Basis eines Expertensystems) gegen seine Spezifikation zu verifizieren sowieso nicht sehr sinnvoll. Denn selbst wenn man beweisen könnte daß das System in allen Punkten das ausführt, was in der Spezifikation gefordert wird, so bleibt doch das Problem: Wie kann die Korrektheit und Vollständigkeit der Spezifikation überprüft werden? Wenn die Spezifikation unvollständig ist und Fehler enthält, nützt selbst der beste Beweis wenig, daß das Programm ausführt was die Spezifikation verlangt. Das Verifikationsproblem wird nur auf eine andere Ebene verlagert.
Es gibt zwar noch mehr Ansätze, die Verifikation gegen die Spezifikation zu prüfen; sie weisen aber alle ähnliche Schwächen auf. So liegt zum Beispiel der Gedanke nahe, die Leistung von Expertensystemen den Leistungen menschlicher Experten gegenüberzustellen. Falls das System so reagiert wie die menschlichen Experten, funktioniert es korrekt, im anderen Fall inkorrekt. Dies führt aber zu einer schier unüberschaubaren Fülle von Problemen, von denen hier nur einige kurz angerissen werden sollen:
- Experten sind, das hat sich wohl mittlerweile herumgesprochen, nicht immer einer Meinung. Würde man nun ein Expertensystem gegen den Experten X validieren, so könnte es zwar mit dessen Ansichten übereinstimmen, mit denen des Experten Y eventuell aber nicht. Es hängt hier alles davon ab, wessen Meinung bei der Erstellung der Wissensbasis am stärksten eingeflossen ist.
- Experten können sich irren. So werden zum Beispiel bei der Überprüfung der Arbeitsweise Korrekturen vorgenommen, obwohl das Expertensystem "objektiv" im Recht war. Es kann auch vorkommen, daß Fehler vom Experten nicht bemerkt werden, da er glaubt, das Ergebnis sei korrekt.
- Experten haben eventuell kein Interesse an der korrekten Arbeitsweise des Expertensystems. Dies kann besonders in solchen Fällen relevant werden, wo sie Konkurrenz befürchten (beispielsweise Arbeitsplatzverlust). Durch die Objektivierung des Expertenwissens in der Wissensbasis kann der "Marktwert" der Experten sinken, da ihr Wissen auch Nicht-Experten zugänglich wird. Experten können deshalb ein inkorrekt arbeitendes Expertensystem als korrekt validieren, um es dadurch, wenn sich beim späteren Einsatz Mängel zeigen, zu diskreditieren; sie können aber auch von Anfang an die Erstellung der Wissensbasis unbemerkt sabotieren, indem sie bewußt falsche Regeln eingeben beziehungsweise an einen Knowledge-Engineer weitergeben. Oder die Fachleute geben ihr Wissen nur unvollständig wieder, so daß das Expertensystem bei einem komplexen Problem nicht über das nötige Wissen verfügt.
Selbst wenn man annimmt, daß diese Gefahren bei der Validierung eines Expertensystems gegen einen Experten oder eine Gruppe von Experten vernachlässigt werden können, bleiben oft weitere prinzipielle Probleme ungelöst oder unlösbar. So stellt sich die Frage, wie ein Expertensystem für einen Anwendungsbereich zu validieren ist, wo selbst die Experten nicht mit Sicherheit sagen können, welche Reaktion in einer bestimmten Situation richtig ist.
Ein Problem betrifft zum Beispiel die Pilotenunterstützung: Man braucht nur daran zu denken, was ein Expertensystem bei einem plötzlichen Notfall während eines Fluges berücksichtigen müßte. Neben den physikalischen Zwängen, die durch die spezielle Flugsituation und den aktuellen Zustand der Maschine zustande kommen, müßte das System eventuell noch Aktionen des Piloten korrigieren, der aufgrund der Streßsituation falsch reagiert.
Da aber nicht alle möglichen Notsituationen durchgetestet oder durchgespielt werden können, gibt es immer wieder Situationen, in denen selbst erfahrene Piloten nicht sagen können, welche Reaktion des Systems unter den gegebenen Umständen optimal wäre - zumal immer davon ausgegangen werden muß, daß kritische Informationen nicht zur Verfügung stehen oder, aufgrund eines Maschinenschadens, eventuell verfälscht sind.
Die Heuristik entzieht sich der Beweisführung
Expertensysteme werden vorwiegend dort eingesetzt, wo Probleme auftreten, deren Lösung wegen des exponentiell großen Lösungsraums den Einsatz sogenannter Heuristiken oder Daumenregeln nötig machen. Und damit ergibt sich ein weiteres prinzipielles Problem: Wann ist eine Daumenregel korrekt? Diese Frage suggeriert einen inhärenten Widerspruch. Und der ist in der Tat auch vorhanden, denn eine Daumenregel wird nur dann angewandt, wenn ein deterministisches Verfahren als Alternative nicht zur Verfügung steht. Die Begriffe "Korrektheit" und "Heuristik" verhalten sich geradezu konträr. Die Korrektheit einer Heuristik ist im allgemeinen nicht beweisbar.
Die Heuristiken sind der Grund für zwei weitere Probleme: Bei ihrer Implementierung wird meist so vorgegangen, daß sogenannte "Certainty-Factors" oder "Gewißheitsfaktoren" verwendet werden. Erreichen speziell zu diesem Zweck überwachte und eingerichtete Parameter einen gewissen Schwellenwert, so werden Regeln abgearbeitet, deren Ausführung dann die Umsetzung der Heuristik darstellt.
Hier stellt sich zunächst die Frage, wie das System zu den Gewißheitsfaktoren kommt. Gewöhnlich spiegeln diese Faktoren rein subjektive Einschätzungen von Experten wider und unterliegen damit allen oben erwähnten Unwägbarkeiten. Nur in sehr seltenen Fällen gibt es dafür hinreichende statistisch auswertbare Grundlagen.
Das zweite Problem betrifft die interne Handhabung der Gewißheitsfaktoren durch eine Wahrscheinlichkeitslogik. Ihre Aufgabe besteht zum Beispiel darin, die Gewißheitsfaktoren zweier Parameter nach einer bestimmten Gesetzmäßigkeit miteinander zu verknüpfen. Die Frage ist hier, wer die Korrektheit dieser Methoden beurteilt. Im abstrakten Sinne wird diese Korrektheit natürlich durch die Methoden selbst definiert, das heißt, die Wahrscheinlichkeitslogik verwendet bestimmte Mechanismen und ist durch diese definiert. Solange die Logik also nachweisbar korrekt nach diesen Methoden arbeitet, ist auch ihr Ergebnis korrekt.
Aber das ist nicht das eigentliche Problem. Die Frage zielt in eine andere Richtung: Wer will überprüfen, ob die speziell verwendete Wahrscheinlichkeitslogik dem Problem angepaßt ist, und wie will man garantieren, daß die Akkumulation von Gewißheitsfaktoren der tatsächlichen Evidenzzunahme entspricht? - Diese Fragen sind im allgemeinen nicht lösbar. Es kann nicht festgelegt werden welche Repräsentation eines Problems die "richtige" ist. Gewöhnlich gibt es nur effiziente oder ineffiziente Repräsentationen, nicht aber richtige und falsche.
Es ist zwar richtig, daß die Validation eines Expertensystems zumindest dann keine Schwierigkeiten bereitet, wenn es gewisse "harte" Kriterien für ein korrektes Verhalten gibt, beispielsweise physikalisch-technische oder mathematische Sachverhalte. Das geht aber am Problem vorbei, da es dort, wo solche harten Fakten vorliegen, nur sehr bedingt sinnvoll ist, tatsächlich Expertensysteme einzusetzen und nicht deterministische Algorithmen.
Abgesehen von solchen Randfällen mag es aber auch in anderen Bereichen scheinbar klar sein, wie die Arbeitsergebnisse eines Expertensystems zu überprüfen sind. So könnte beispielsweise ein Expertensystem gegen aus der Vergangenheit bekannte Daten verifizieren oder validiert werden. Ein Expertensystem für die Vorhersage von Aktienkursen wäre demnach dadurch zu validieren, daß man es auf Börsenkurse vergangener Tage anwendet und überprüft, ob es den Kursverlauf der nächsten Tage wirklich korrekt vorhergesagt hätte.
Bislang war nur die Rede davon, wogegen ein Expertensystem validiert werden kann und welche Probleme möglicherweise dabei auftreten. Dies ist aber nur ein Problem von vielen. So stellt sich zum Beispiel noch die Frage, was eigentlich validiert werden soll. Es wurde implizit davon ausgegangen, daß die Leistung des Expertensystems der Gegenstand der Prüfung sein müßte. Aber dies ist nicht immer sinnvoll
und notwendig. Es gilt ferner zu untersuchen, ob man sich nicht auf die Korrektheit der Verarbeitungsmechanismen beschränken könnte und ob es nicht ausreichen würde, zu wissen, ob die Inferenzkomponente korrekt arbeitet. Nun, diese Fragen sind leicht zu beantworten: Es würde nicht genügen. Denn die Korrektheit eines Expertensystems ist eben keine direkte Funktion der Korrektheit aller seiner Komponenten. Dies gilt natürlich auch für konventionelle Programmsysteme .
Vielleicht ist aber der ganze bisherige Ansatz falsch und die Forderung, Korrektheit oder Inkorrektheit der Arbeitsweise beurteilen zu wollen, zu einfach. So sind ja Expertensysteme Menschen in dem Sinne ähnlich, daß sie komplexe Entscheidungen unter Berücksichtigung einer Fülle von Randbedingungen fällen. Wäre es daher nicht viel angemessener, nur von "mehr oder weniger korrekten" Reaktionen der Expertensysteme zu reden?
Diese Argumente haben eine gewisse Berechtigung. Insbesondere bei Beratungssystemen wird man im allgemeinen wohl kaum sagen können, daß eine Empfehlung des Systems definitiv wahr oder falsch war. Auch die Entscheidung eines Richters kann nicht immer als richtig oder unrichtig beurteilt werden. Wenn jedoch ein Patient aufgrund einer falschen Diagnose stirbt, so gibt es keine Entschuldigung: Die Diagnose war falsch und keineswegs "nicht ganz richtig".
Der letzte Punkt dieser Aufzählung weist bereits auf zwei zusätzliche Aspekte hin, die speziell bei der Validation von Expertensystemen beachtet werden müssen, wenn diese in sicherheitskritischen Anwendungen eingesetzt werden sollen. So müssen die prinzipiellen Schwächen des gewählten Verifikations- oder Validationsverfahrens zusätzlich, sozusagen auf einer Meta-Ebene, abgeschätzt werden.
Auf dieser Ebene ist das Verifikations- beziehungsweise Validationsverfahren selber Gegenstand der Untersuchung, um die Problemfelder lokalisieren zu können, die durch die gewählte Methodik nicht abgedeckt werden können. Ferner bedarf es einer Risiko- und Folgeabschätzung. Dies ist geradezu eine Voraussetzung bei sicherheitskritischen Anwendungen. Es muß jedem klar sein, was alles passieren kann, wenn das Expertensystem nicht korrekt funktioniert.
Zwischen diesen beiden Aspekten besteht ein enger Zusammenhang. Auf der Meta-Ebene müssen gerade die Schwachstellen des Validationsverfahrens gefunden werden, denn sie können zu den gravierendsten Folgen führen. Und umgekehrt kann die Risikoabschätzung eine wichtige Anleitung für die Mängelsuche darstellen.
Sind die obigen Voraussetzungen geklärt, kann mit der Validation begonnen werden. Von nun an soll die Verifikation als der formale, exakte, eventuell mathematisch-logische Teil der Validation verstanden werden. Die Validation besteht also aus einer quantitativen Validation und einer qualitativen Validation. Die quantitative Validation hat zum Ziel, die Leistung des Expertensystems mit der Leistung menschlicher Experten quantitativ zu vergleichen und die Übereinstimmung mit ausgewählten Testfällen zu messen. Als Resultat erhält man ein Maß für die relative Abweichung des Systems vor der vorgesehenen Leistung.
Der methodische Ansatz der quantitativen Validation besteht im wesentlichen darin, mittels mathemalisch-statistischer Methoden die Diskrepanz zwischen dem Systemverhalten und dem Referenzobjekt (Experten/Expertengruppe oder Testdaten) zu erfassen. Es wird nur dann die Leistung des Systems akzeptiert wenn die statistische Abweichung kleiner ist, als die in den Voraussetzungen festgelegte zulässige Leistungsabweichung.
Eine quantitative Validation ist nur dann akzeptabel, wenn für die Leistung des Expertensystems tatsächlich nur die statistische Abweichung relevant ist. Das wird etwa bei Expertensystemen der Fall sein, die Fehler in Hardwarebauteilen zu diagnostizieren haben. Kommt es jedoch darauf an, daß jedes einzelne Ergebnis möglichst korrekt ist, so ist die quantitative Validation nur dann akzeptabel, wenn die Abweichung in jedem Testfall Null oder insgesamt sehr klein ist (bei Anwendungen in der Luftfahrt etwa in einer Größenordnung von 10 -12).
Die qualitative Validation beruht im allgemeinen stärker auf subjektiven Bewertungen der Expertensysteme und ist damit den oben angeführten prinzipiellen Beschränkungen unterworfen. Zu den wichtigsten Formen der qualitativen Validation gehört zum Beispiel die "Face-Validation". Hierbei wird das Expertensystem dem Projektteam, den Anwendern, Experten und anderen zur Beurteilung vorgelegt. Aus der Kritik dieser Tester ergeben sich eventuelle Ansätze für die noch notwendigen Modifikationen des Systems. Eine weitere Form ist die "Vorhersage-Validation", in der das System gegen Testdaten geprüft wird, für die der korrekte Output bekannt ist.
Unter die qualitative Validation fallen auch die "Turing-Validation" und die "Feldtest-Validation". Bei der Turing-Validation wird in Anlehnung an den berühmten Turing-Test für die Intelligenz einer Maschine der Output des Systems einer Bewertungsinstanz des Expertensystems zur Beurteilung gegeben. Der Beurteilende weiß hier nicht, ob der Output vom Expertensystem oder von einem menschlichen Experten stammt. Kann der Beurteilende keine eindeutige Identifizierung das Expertensystem angeben, so wird dieses als ebenso leistungsfähig betrachtet wie der Experte, mit dem es in diesem Fall konkurrierte.
Bei der Feldtest-Validation wird das Expertensystem in der realen Anwendungsumgebung im Prototypen-Status ausgetestet. Die sich dabei abzeichnenden Mängel können als eine Art Feedback für neue, bessere Prototypen verwendet werden. Es versteht sich, daß bei sicherheitskritischen Anwendungen Feldtests im allgemeinen nur in simulierten Umgebungen möglich sind, was bereits auf die prinzipiellen Schwächen dieses Ansatzes hinweist.
Zu guter Letzt kommen noch die "Subsystem-Validation" und die "Sensitivitäts-Validation" hinzu. Die erstere setzt voraus, daß die zu validierenden Subkomponenten hinreichend von anderen Komponenten des Systems getrennt werden können. So kann man zwar die Inferenzmaschine von der Wissensbasis trennen, meist aber nicht Teile der Wissensbasis isoliert validieren.
Die Sensitivitäts-Validation ist eine der mächtigsten und objektivsten Validationsmethoden. Die Vorgehensweise besteht hier darin, Input-Parameter zu modifizieren und das Output-Verhalten des Systems damit zu vergleichen. Viele Folgerungen eines Expertensystems müssen gleich bleiben, wenn sich nur wenige der Input-Daten ändern. Mit der Sensitivitäts-Validation läßt sich dies überprüfen. Gewöhnlich aber werden mehrere qualitative Validationsmethoden parallel angewandt.
Sollen Expertensysteme künftig einmal in sicherheitskritischen und sicherheitssensitiven Anwendungen zum Einsatz gelangen, so muß so wohl die Forschung als auch die Industrie sehr viel mehr als bisher dafür tun, daß diesen Systemen auch in solchen Anwendungen vertraut werden kann. Es fehlt noch an Kriterien, Definitionen, Methoden und Verfahren für die Validation der Systeme. Solange keine solchen Maßstäbe existieren, kann niemand ruhigen Gewissens empfehlen, Expertensysteme dort einzusetzen, wo direkt oder indirekt Menschenleben von ihnen abhängen.
Validationskriterien
Trotz der Fülle prinzipieller Bedenken die Möglichkeit, Expertensysteme zu validieren oder zu verifizieren, lassen sich zumindest bei entsprechenden freiwilligen Beschränkungen in der Anwendung der Systeme erste Lösungsansätze und Validationskriterien finden.
Die wesentliche Voraussetzungen für solche Ansätze sind:
- die Definition der gewünschten Leistung des Systems und der zulässigen Leistungsabweichung,
- ein überschaubarer und modellierbarer Anwendungsbereich,
- die Festlegung der Vorgehenweise bei der Validation beziehungsweise Verifikation des Testumfanges und der Testtiefe und
- die Bestimmung dessen, was durch die vorgenommenen Tests nicht überprüft wird.
Eberhard Schöneburg ist Programmleiter Expertensysteme und Neue Software-Technologien bei der Dornier System GmbH, Friedrichshafen.