up

Künstliche Intelligenz im Netzwerkmanagement

Vortrag am
Fachbereich Informatik (20) der
Johann Wolfgang Goethe-universität Frankfurt am Main im Rahmen des
Seminars "Neue Architekturen für das Management verteilter Systeme" der
Professur Verteilte Systeme und Betriebssysteme im
Sommersemester 1997.
(Der Vortrag findet/fand statt am 2.7.1997 im Seminarraum 307 des Fachbereichs.)

Andreas Wagner
Frankfurt/Main (Germany)
E-Mail: A.Wagner@stud.uni-frankfurt.de

Abstract

Dieser Vortrag will die Möglichkeiten erörtern, die sich im komplexen Aufgabenfeld des Netzwerkmanagements (NM) für die Ersetzung menschlicher Arbeit durch Computerprogramme ergeben, wenn man nicht den schon gescheiterten algorithmischen Ansatz verfolgt, sondern versucht, die menschliche Arbeitskraft möglichst "originalgetreu" nachzubilden - genau dies meint Künstliche Intelligenz (KI oder AI).
Zuerst will ich die Funktionen, Aufgaben und Probleme des Netzwerkmanagements, die aktuelle Situation der Verwendung und des Bedarfs von bzw. an KI-Systemen erläutern, dann Bedingungen anführen, die Fälle bezeichnen, in denen die KI-Technologie zu Hoffnungen berechtigt. Ich werde Vorteile und Nachteile von Systemen künstlicher Intelligenz (im NM) erklären und dann spezifizieren, welche Anforderungen an ein solches System ergehen bzw. welchen Forderungen die Systementwicklerin nachgehen sollte. Das lenkt den Blick auf die auch im "Forschungsgebiet KI" noch offenen, aber für unseren Zusammenhang wichtigen Fragen und Probleme. Es werden Forschungsprojekte erwähnt, deren Resultate wohl weitreichende Konsequenzen für die Entwicklung, Implementierung und konzeptuelle Konstitution von KI-Systemen haben werden. Schließlich will ich nach einer Erklärung verschiedener AI-Paradigmata an einem Beispiel das Potential und gleichzeitig die schon weit fortgeschrittene praktische Einbindung von Expertensystemen in die regulären Arbeitsprozesse des Netzwerkmanagements aufzeigen. Dieses Beispiel ist ein nicht existierendes Konglomerat existierender Systeme, die ich lediglich zu Zwecken der Demonstration, Präsentation und Verdeutlichung der Möglichkeiten zusammenfasse.
Die Schlußfolgerung bekräftigt die Überzeugung, daß KI als wesentlich bestimmendes Paradigma in komplexen Aufgabenzusammenhängen1 eingesetzt werden kann, bereits eingesetzt wird und in noch stärkerem Maße eingesetzt werden wird, daß KI sich zu einer Querschnittstechnologie entwickeln wird, die um so prominenter hervortreten wird, je komplexer das Problem wird.

Einführung

Netzwerkmanagement2

Netzwerkmanagement umfaßt in einem Oberbegriff eine Vielfalt von Funktionen, Aufgaben und Problemen. Der Endbenutzerin stellt das Netzwerk grundsätzlich zwei Funktionen zur Verfügung: Kommunikation und Information. Die Benutzerin erwartet die Verfügbarkeit eines Kommunikationspfades, d.h. einen Datenübertragungsmechanismus zum Ziel ihrer Wahl und eventuell auch die für die Nutzung nötige Hard- und Software, und sie erwartet Informationsangebote z.B. über ihre Inanspruchnahme des Netzes, diverse Adreßrecherchemöglichkeiten, oder neuere, "intelligente" Nutzungsangebote (ISDN). Das Netzwerkmanagement soll natürlich für die effektive und reibungslose (und billige) Realisierung dieser Funktionen sorgen.
Die tägliche Arbeitspraxis des Netzwerkmanagements, die dies bewerkstelligen soll, läßt sich dabei unterteilen in folgende Aufgaben: Im folgenden wird uns immer wieder das Traffic Management besonders interessieren. Was es so besonders macht: Traffic Management ist "one of the most time critical functions in network management. Most information is updated every 5 minutes3; some information (alarm status) is updated continously and summarized every 30 seconds4. Except for the switching function itself, nothing in telephony is faster."5
In diesem Aufgabenbereich lassen sich die Probleme so typisieren:
  1. Der "routine capacity exhaust" ist eine regelmäßig auftretende Überlastung bestimmter Netzsegmente, die ihre Ursache in den allermeisten Fällen in einer unangemessenen, das heißt nicht ausreichenden Hardware hat. Die Aufgabe des NM besteht hier natürlich darin, diesen Handlungsbedarf (an Aufrüstung) zu erkennen (traffic management), geeignete neue Netzstrukturen zu entwerfen (capacity planning), zu ordern (administration) und zu installieren (engineering/construction).
  2. Der "focused overload" ist die ausnahmsweise Überlastung eines einzelnen Netzsegments - etwa durch Stromausfälle oder Naturkatastrophen wie Überflutungen und Stürme oder aber auch durch Massen-Anrufsveranstaltungen, die ein bestimmtes Zielschaltwerk überfordern. Die Aufgabe des Netzwerkmanagements besteht hier darin, Teile des Datenverkehrs umzuleiten, d.h. andere Routingprioritäten und Routingrichtlinien ein- und zu gegebenem Zeitpunkt wieder auszusetzen.
  3. Der "general overload" ist eine ausnahmsweise auftretende Überlastung des gesamten Netzwerkes - oder wenigstens sehr großer Bereiche. Ursachen können Anrufsmuster sein, wie sie an Feiertagen auftreten oder ein örtlich begrenztes Problem ("focused overload"), welches aber eskalierte. Das für die Netzmanagerin Problematische hier ist eine Einschränkung der Kontroll- und Routingalternativen.
  4. Die "facility failures" - Ausfälle von Hard- und Software - ähneln den "focused overloads", mit dem Unterschied, daß nicht bloß ein Teil, sondern der gesamte Verkehr umgeleitet werden muß (und natürlich Reparaturmaßnahmen durchgeführt werden müssen).

Aktuelle Situation

Künstliche Intelligenz wird bereits im Netzwerkmanagement angewandt6. Zumeist auf Produktions- (Regel-) Wissensrepräsentation, forward-chaining (data-driven) inferencing und Mustererkennung7 basierende, in der Regel in PROLOG oder in LISP geschriebene Systeme werden schon jetzt häufig zu diagnostischen Zwecken, also im Aufgabenbereich "repair & maintenance" eingesetzt. So wird etwa AT&T's diagnostisches AI-System ACE seit 1984 kommerziell vertrieben8. Viele der Systeme ordnen bestimmten Konstellationen von Fehler- und Statusmeldungen jeweils bestimmte Ursachen zu und legen den Operatorinnen eine Liste mit Vorschlägen zur Erklärung und zur Behebung der Probleme vor. Das Wissen gelangt über automatische Induktion oder über Interviews zwischen Expertin und Knowledge Engineer in das System, das dann entsprechend Expertensystem heißt.
Für einen steigenden Bedarf an KI-Systemen spricht die Annahme, daß in (naher) Zukunft Netzwerke zunehmend selbst "intelligenter" werden, Funktionen wie "Wissen" über die Benutzerin inkorporieren und dabei 24h real-time response liefern sollen. Hinzu kommt ein geringes Angebot an Arbeitskräften mit entsprechender (traffic management) Expertise.

Vorteile und Anwendungsbereiche von AI-Systemen

Drei Bedingungen für die Anwendbarkeit und den Einsatz von Expertensystemen lauten: Das Problem muß eng umgrenzt sein, Test- und Verifikationsdaten müssen leicht zugänglich sein und das Problem soll nach bestem Wissen nicht (effizient) algorithmisch lösbar sein. Daraus ergeben sich vier Gebiete für den Einsatz von KI-Systemen: Problemisolation und -korrektur (traffic management / repair & maintenance), Performance (traffic management), Engineering und Training. Da bei Expertensystemen eigentlich immer irgendwo wissensbasierte Komponenten ins Spiel kommen, ist es nötig, auch hier Klarheit zu schaffen. Den Systemen stehen als Informationsquellen etwa zur Problembestimmung oder zur Findung von Lösungsvorschlägen zur Verfügung: Detaillierte Statusinformationen und Beschreibungen, Aufzeichnungen gerade aktiver und schon abgeschlossener Verbindungen und Interaktionen, Konfigurationsdatenbanken, die schon erfolgreiche oder auch fehlgeschlagene Reaktionsschemata zugänglich machen, Reports und Logfiles und schließlich eine (KI-) Routingsimulation, die die Konsequenzen einer neu erarbeiteten und vorgeschlagenen Lösungsalternative abschätzen hilft. Das benutzte Wissen läßt sich klassifizieren in "communications (nature of information flow), messages (states of subnetworks), patterns, clusters, problems, analyses, suggestions, network topology"9.
Die Vorteile von AI-Systemen sind zahlreich:

Nachteile von AI-Systemen

Was allerdings Erwähnung finden sollte, gleichwohl in der Literatur naiv oder skrupellos euphemisiert wird, ist der Verlust von Arbeitsplätzen! Da wird ohne jede Ironie davon gesprochen, daß - wie bei jeder Automation (also quasi sich ganz natürlich ergebend) - eventuell mit der Einführung von Expertensystemen künstlicher Intelligenz ein Gefühl der "Unsicherheit" sich bei den Arbeiterinnen bemerkbar machen könnte. Dem gelte es durch behutsame step-by-step-Einführung entgegenzuwirken. Die (menschlichen) Expertinnen würden schließlich für die og. Funktionen nicht mehr benötigt und "frei" für "kreativere Aufgaben" - eine, wie ich meine, doch sehr blauäugige Vorstellung. Man sollte bei der Überlegung zu KI-Expertensystemen wenigstens sich von Illusionen sozialer Problemlosigkeit freimachen - um schließlich wohlinformiert Abwägungen treffen zu können.

Anforderungen

An ein Expertensystem zur Unterstützung oder Wahrnehmung von Netzwerkmanagementaufgaben richten sich somit folgende (Maximal-)Anforderungen:

Echtzeit-Operation
Da sowohl ein großer Vorteil der AI-Systeme in ihrer (nahezu) real-time response, als auch ein gewichtiger Aufgabenbereich des Netzwerkmanagements (Traffic management ebensosehr wie Repair & Maintenance) fundamental auf schnelle Reaktionszeiten und schnelle Problembestimmung und -lösung angewiesen ist, soll das System sich an der Maßgabe der real-time Operation orientieren.
Offene und flexible Architektur
Um mit der wechselnden Nachfrage nach verschiedenen Netzdiensten und mit der fortschreitenden technischen Entwicklung Schritt halten zu können, ist eine offene Architektur und die Erkennung und Implementierung von offenen Standards wünschenswert (z.B. "PnP" bei der Installation neuer Netzhardware).
Zugang zu hetreogenen, verteilten Datenbanken
Um überhaupt sinnvoll arbeiten zu können, muß das System selbständig auf möglichst allgemein spezifizierte, das heißt im durchaus nicht selten auftretenden Fall auf heterogene, verteilte Datenbanken zugreifen können. Ein Wissen um die verfügbaren Datenbanken, ihre Syntax, Inhalte und eventuell Datenstrukturen (Objekte/Indexe) muß sich in einem Interface niederschlagen, das Geschwindigkeit und Flexibilität vereint.
Daten ordnen und gruppieren
Das System muß in diesen verteilten, heterogenen Datenbanken relevante Daten erkennen, extrahieren und zu sinnvollen Mustern gruppieren können.
Feldversuche, Simulation und Überprüfung durch Expertinnen
Da Evaluation und Verifikation konstitutive Prozesse für den Entwurf und das Funktionieren von Expertensystemen sind, selbst wo diese nicht im eigentlichen Sinne "lernfähig" sind, muß für kontinuierliche Überwachung nicht nur eine Schnittstelle vorgesehen, sondern auch tatsächlich benutzt werden.
Bereichsspezifisches Wissen
Dem System verfügbares und von ihm verwendbares domänenspezifisches Wissen (z.B. über Netzwerktopologie u.ä.) verbessert im Allgemeinen die Performance und sollte implementiert werden.
Flexibilität, zwischen optimalen und befriedigenden Lösungen zu unterscheiden
Das System soll entscheiden können, ob es eine schnelle Diagnose liefert, die eventuell riskant und nicht ausreichend entwickelt ist und während des weiteren Verlaufs eine komplettere, tiefere Analyse "nachreicht". Es soll natürlich dann auch die Fähigkeit besitzen, beide Arten von Analysen durchzuführen.
Zyklischer Überlegungsvorgang
Die - erwünschten oder unerwünschten - Folgen einer beabsichtigten Diagnose oder Aktion sollen bereits in den tatsächlich unterbreiteten Vorschlag eingehen. Ein zyklischer Entscheidungsprozeß, der auf die ja auch weiterhin eintreffenden Daten und eine eigene Simulation der Folgen eingeht, muß eingebunden werden.
Vorwärts- und rückwärts schließen
Das System soll sowohl Problemstellungen der Art "Was kann passiert sein, das uns in den spezifizierten Zustand gebracht hat?" bzw. "Was muß ich tun, um zum Zustand x zu gelangen?" (backward chaining), als auch der Art "Was passiert, wenn ich die Aktion y durchführe?" (forward chaining) bewältigen können.
Gewichtung bzw. Verwaltung von Prioritäten
Die verschiedenen Korrekturmaßnahmen müssen mit Prioritäten versehen werden, deren Berechnung unter Berücksichtigung von Wahrscheinlichkeit des Fehlers, Wahrscheinlichkeit des gewünschten Korrekturerfolgs, Aufwand (u.a. von Zeit und Finanzen) und Risiko der Korrekturaktionen (z.B. negative Nebenfolgen für andere Aspekte des Netzbetriebs) erfolgen soll.
Fehlerbestimmung
Geradezu die Definition eines Einsatzgebietes, sollte das System in der Lage sein, Netzfehler sicher zu bestimmen, d.h. das Auftreten von Symptomen sofort (oder möglichst schnell) registrieren, eine Wahrscheinlichkeitsabwägung der verschiedenen möglichen Ursachen durchführen, eventuell weitere Diagnosen oder detailliertere Informationen anfordern, eine gewichtete Liste mit typischen Beschreibungen jener Fehler, Fehlerursachen und angemessener Korrekturvorschläge liefern, und im Idealfalle selbst initiieren.
Aktionen kombinieren
Die Korrekturaktionen sollen - wo möglich - kombiniert werden.
Natural language oder andere benutzerfreundliche Oberfläche
Da das System in Kontakt mit Operatorinnen und eventuell auch Netzbenutzerinnen treten können soll - ganz zu schweigen von Ratschlägen "dritter Seite" -, muß ein Interface vorgesehen werden, welches der Benutzerin sowohl die Logik und die Ideen des AI-Systems "ansprechend" oder zumindest verständlich und nicht abschreckend als auch dem System den Sinn von Benutzerinneneingaben oder -verhalten zugänglich macht (syntaktische, semantische und pragmatische Analyse).
Kommentierte und verständliche Ausgabe, Dokumentation
Sowohl für die Evaluation durch Expertinnen als auch für die Verwendung des Systems als Trainer oder Tutor bei der Einarbeitung neuer Kräfte ist es notwendig, daß es seine "Überlegungen" und seine Logik verfügbar macht und dabei verschieden weit "ausholen" bzw. verschieden tiefe Erklärungen liefern kann.
Für die Softwareentwicklerin ist natürlich weiter von Bedeutung, welche Kapazitäten ein sog. "Shell"-Produkt bereitstellen soll, also ein Software-Produkt, welches eine Entwicklungsumgebung zur Realisierung von AI-Expertensystemen in verschiedensten Bereichen darstellen soll. Wenn man die Käuferin des Produktes, d.h. die Entwicklerin des letzten Endes installierten AI-Systems nicht in den Designmöglichkeiten einschränken will, muß eine solche Software unterstützen:
Das konzeptuell für den im Vergleich zu oben größten Mehraufwand verantwortliche Paradigma der Multi-Agenten-Systeme. Daraus ergeben sich weitere Forderungen - ein weites Spektrum von Kontollflußschemata (master/slave über non-absolute control bis hin zu voll autonomen Subsystemen), verschiedene Schichten von Kommunikationsinterfaces und Protokollen (intermodul, interprozeß, intrabetrieblich, interbetrieblich), mehrere "reasoning schemes", Synchronisationsinterfaces und Interfaces zu Expertensystemen / Shells anderer Hersteller.
Sie sollte das Design kanalisieren in portablen "virtual machine" Plattformen (Java?), maßgeschneiderten Modulen, zu erzeugenden und grundlegenden Basiselementen (generic elements) und Agenten-Koordination (aop - agent0).

Probleme / Forschungsbedarf

So wie die Künstliche Intelligenz noch immer ein weites Forschungsfeld ist, so natürlich auch das der Anwendung von KI. Von Interesse dürften folgende Punkte sein, egal, ob sie in Anwendungsdiskursen oder in eher akademischen Forschungsprojekten untersucht werden.

Forschung im Bereich von "common sense"- oder "evidential" reasoning. So gibt es etwa Versuche, das Wissen zu codieren, daß man benötigt, um ein Lexikon verstehen zu können. Es liegt auf der Hand, daß eine solche Logik die Geschwindigkeit der Systeme enorm steigern könnte, wie auch hinsichtlich Autonomie, Koordination und Kooperation von Agenten aufschlußreich wäre. "What factors should go into the weighing of evidence in arriving at a conclusion? How do you discover the worth of other agent's conclusions? How do you keep reasoning about evidence from overshadowing the cost of reasoning with evidence?"10 Weiter ist zu untersuchen, inwiefern anhand von Kulturellen Artefakten und in ihnen einbeschriebenen Praxen bei der Erreichung von Zielen auf Planung verzichtet werden kann11.
Es wäre interessant, wenn man Methoden entwickelte, die ein Expertensystem vor "reasoning failures" schützen. Das System sollte selbst erkennen lernen, wann es sich in Paradoxien oder Irrelevanzen verrennt und (rechtzeitig) keinen Ausweg finden kann.
Im Bereich Machine Learning ist noch vieles offen, was die Systeme befördern könnte. Wenn etwa KI-Systeme aus Erfahrung heraus die Parameter ihrer eigenen Logik anpassen könnten, wäre eine Verbesserung der "Überlegungen" die Folge. Weitere Forschungsfelder, deren Ergebnisse den Lernprozeß der Systeme ohne Zweifel beeinflussen werden, sind Mustererkennung (Situationserfassung), die selbständige Unterscheidung von Beispiel und Ausnahme, die Regeln der Regelerzeugung und die Erkennung von Irrelevanz.
Wenn schließlich die Agenten ihre Koordination und Kommunikation autonom und gemeinsam organisieren sollen, wie soll dann dies verhandelt werden? "Organizations are restrictions of choice made to speed up joint activity. Communication protocols are perhaps the simplest organizations. Can individual agents build organizations to meet problem demands? Can they tear them down when they become counterproductive? And, how do you find out that organizations are counterproductive?"12

"fiktives" Anwendungsbeispiel

Als Anwendungsbeispiel will ich ein System entwerfen, daß zwar als solches nicht existiert, aber verschiedene schon im Einsatz sich befindende KI-Systeme zusammenfaßt. Damit will ich erstens einen Überblick über die in unserem Zusammenhang meistversprechenden KI-Paradigmata und ihre mögliche Implementierung geben, zweitens auf die Möglichkeiten und das große Potential des KI-Ansatzes aufmerksam machen und drittens die Konkretheit, Realitätsnähe, Praktikabilität und Bedeutsamkeit, den dieser Ansatz bereits jetzt darstellt, verdeutlichen, indem ich daran erinnere, daß das "fiktive" System sich aus "realen" Komponenten zusammensetzt. Alle Komponenten werden 1993 als zu diesem Zeitpunkt im Testlauf oder schon im endgültigen Betrieb laufende Systeme präsentiert13.

Verwendete Paradigmata

CBR/KBR

- KBR (Knowledge Based Reasoning) war eine der ersten Formen der Logik von Expertensystemen. Aus dem Wissen einer Expertin wurden in Interviews mit der sog. Knowledge Engineer Regeln formuliert, die die Expertin zur Bewältigung ihrer Aufgaben verwandte, und die die KE dann codierte und im System implementierte. Daraus ergab sich mitunter, insbesondere bei komplexen Aufgaben das Problem, daß die Expertin sich selbst und der KE gegenüber keine Rechenschaft über das verwendete Wissen ablegen konnte. Der sogenannte "Feigenbaum Bottleneck" beschreibt die Schwierigkeit, das nach langer Erfahrung intuitiv verwendete Wissen explizit zu machen, sowie den Aufwand, den diese Interviews mit sich führten. Als Alternative wurden die Systeme damit betraut, aus Beispielen der täglichen Arbeitspraxis der Expertin zu lernen und sich - ganz wie ein Lehrling - die Regeln selbst zu erschließen. KBR und Regel-Induktion ergaben bald eine Zuverlässigkeit, die der der Expertin mindestens gleichkam. Als Entwicklungsumgebung gibt es zum Beispiel C4, ein Unix-C-Programm, das aus Beispielen einen Entscheidungsbaum aufbaut (,komprimiert) und daraus dann erst das eigentliche Expertensystem zurechtschustert14.

- CBR (Case Based Reasoning) ist in komplexen Aufgaben noch schneller als KBR. Die Beispiele werden hier nicht mehr in einen Entscheidungsbaum verarbeitet, sondern mit ihren jeweiligen Schlüsselkriterien in einer Datenbank organisiert, auf die das Expertensystem dann zugreift. Der CBR-Cycle Der Zugriff erfolgt also auf einen fix und fertigen Fall, mit Fallbeschreibung, Schlüsselkriterien und meistens auch der in diesem Fall erforderlichen Reaktion des Systems. Die Performance eines CBR-Systems hängt natürlich kritisch von der Organisation und vor allem der Indexierung der Datenbank, sowie von einer Komponente namens Case Adaptor oder Modifier ab, die die aktuelle Situation mit den gespeicherten auf hinreichende Analogien vergleicht und den gespeicherten Fall bzw. die gespeicherten Reaktionsschemata den Parametern der aktuellen Situation anpaßt15.

AOP

Ein weiteres Paradigma, daß die Leistungsfähigkeit von Systemen künstlicher Intelligenz steigern soll, ist das des Agent-Oriented Programming. Als Erweiterung des divide-and-conquer-Prinzips ist hierbei vorgesehen, daß ein Problem in Unterprobleme oder ein Aufgabenbereich (Netzwerkmanagement) in Teilzuständigkeiten (routing, repair, fault diagnosis usw.) aufgeteilt wird, die von jeweils eigenen, autonomen Programmen/Systemen bewältigt werden, die dann auch selbständig sich Informationen und Ressourcen besorgen können. Als Folge der konzeptuellen Unabhängigkeit der Agenten und einer Bemühung um ein konzeptuell einheitliches Interface werden alle anderen Objekte, Sensoren, Programme, Maschinen, Operatoren usw. auch als Agenten behandelt, an die dann Anforderungen und Dienstleistungen übermittelt werden können.
Oft auch als "virtual entities" bezeichnet, bestehen diese Agenten - insofern es sich um Programme handelt - aus einem speicherresidenten "Listener", der die eigentliche Instanz wachrufen kann, und eben dieser Instanz. Sie können im Idealfalle Klone ihrer selbst erzeugen, wenn sie gerade überlastet sind, sie können sich deaktivieren, "schlafenlegen", wenn sie nichts zu tun haben / finden und sie haben ein Wissen, "Meta-Knowledge", über ihre Fähigkeiten und die Fähigkeiten anderer Agenten.

Abgesehen von systemspezifischen Vorteilen wie Effektivität, hohe Datenverarbeitungsrate, "flexible Arbeitszeit", "geringe Ansprüche am Arbeit und Arbeitsplatz" und "bescheidene Lohnforderungen", fungiert als Vorbild natürlich der Mensch. Jeder als autonom entworfene Agent soll daher diese, dem Menschen abgeschauten kognitiven Funktionen inkorporieren: Ein typischer Ablauf von Problembewältigung durch einen solchen Agenten innerhalb des Agenten sieht dann so aus: "Die Aufgabe gelangt in den Spezialisten als vom Communicator/Network Listener decodierte Nachricht und wird in die Schlange anderer Aufgaben für diesen Spezialist auf das Internal Blackboard geschrieben. Zuerst kontaktiert der Negotiator die Metaknowledge and Learner um zu bestimmen, ob die Aufgabe tatsächlich intern gelöst werden kann und dann bestimmt Chair, mit der Hilfe von Fusion/Situation Recognizer die Reihenfolge der zu bearbeitenden Aufgaben. Anomaliefreie Aufgaben werden generell durch den Real-Time Controller behandelt, der die nötigen Schritte unternimmt, um die Aufgabe zu lösen, die Ergebnisse zusammen mit Aufgaben für andere Spezialisten auf das Internal Blackboard ablegt und für den Accounter/Logger nützliche Aufgabenlösungsinformation generiert. Anomale Aufgaben andererseits, wenn sie denn angenommen werden, werden vorbearbeitet durch den Problem Solver and Planner, der versucht, alternative Lösungen abzuwägen und die richtige Sequenz herauszufinden, die der Real-Time Controller dann ausführt. Metaknowledge and Learning dient als Depot von Informationen darüber, welche Alternativen der Problem Solver and Planner in Betracht ziehen sollte, inklusive der Möglichkeit, die Aufgabe einem ganz anderen Spezialist zwecks Hilfe, Lösungsteilung oder Unteraufgabenzuweisung zuzuweisen. Negotiator wird wieder benutzt für Interaktionen der Unteraufgabenzuweisung (z.B. 'subcontracting'). Metaknowledge and Learning 'lernt' mit fortschreitender Zeit, welche Alternativen, welche Lösungen und welche anderen Spezialisten am nützlichsten und welche am ehesten kontraproduktiv sind, je nach dem Typen des Austauschs."16

Wenn nun die Agenten nicht nur autonom, sondern auch selbst auf KI basierend implementiert werden sollen, ist zu erwähnen, daß mit "agent0" eine Programmiersprache, bzw. ein Interpreter17 bereits recht etabliert ist, der einen weiteren AOP-Aspekt verwirklicht: In vielen Konzepten wird AOP - vom bisher gesagten abweichend - eingeführt als fundamental auf das Prinzip von "beliefs and commitments" abgestellt. Ohne auf diese Differenzen in den Grundsätzen einzugehen, soll doch festgehalten werden, daß sie sich durchaus vertragen.
Agent0 bietet die Möglichkeit, in einer Abwandlung des Internen Blackboards verschiedene Vorhaben, Verpflichtungen und Schuldigkeiten gegenüber anderen Agenten und gegenüber der eigenen Aufgabe als Liste von "Commitments" abzulegen. Zu jedem Taktzyklus werden alle in den "reifen" Commitments festgelegten Regeln und Aktionen ausgeführt.
Die "Beliefs" sind eine Menge von Fakten, wobei jeder Fakt mit einem Prädikat und einer Fakt-Status-Liste verknüpft ist. Auch sie sind sozusagen auf dem Internen Blackboard repräsentiert. Ein Faktum ist eine Aussage über den Status einer Proposition zu einer gegebenen Zeit. Die Liste beschreibt die Veränderung der Wahrheitswerte von Sachverhalten über die Zeit. Einige Implementationen versehen jeden Belief noch mit einer "Stärke", die die variierende Überzeugung des Agenten von der jeweiligen Proposition ausdrücken soll, andere Implementationen versehen jeden Belief mit einem Vermerk, wer diesen Belief teilt18.
Die Agenten können Informationen über Fakten und Anforderungen von Commitments an andere Agenten senden, sie "glauben" alle Fakten, die ihnen mitgeteilt werden. Diese Architektur führt uns zum nächsten Paradigma:

DAI/CPS

Distributed Artificial Intelligence (DAI) und Cooperative Problem Solving (CPS) werden oft als relativ autonome eigene Forschungsbereiche innerhalb der KI betrachtet, was - abgesehen davon, ob das sinnvoll ist oder nicht - die Bedeutung dieses Themas illustriert. Hierher gehören Untersuchungen und Methoden, die Kooperation zwischen Agenten zu organisieren. Interoperabilität kann auf mehreren Ebenen hergestellt werden, von der Transportebene bis zur End-User-Ebene. Dies wird durch Konzepte wie Metaknowledge, Beliefs, Responsibility und Kommunikationsprotokolle erreicht.
Wegen der Tragweite und der Bedeutung dieses "AI-Paradigmas" erfolgt hier eine erneute Auflistung von Vorteilen und Nachteilen. Zuerst die Vorteile:
Hier nun die Nachteile oder Bedenken:
Hier ist abzuwägen zwischen verschiedenen Schemata der Kontrollorganisation. Vom wohl trivialen Fall der "slavelike" absoluten Unterordnung unter den Agenten des jeweils höheren Levels zur völlig dezentralisierten, quasi "autopoietischen" Organisation zwischen völlig autonomen Agenten muß die Wahl in einem breiten Spektrum von Zwischenformen erfolgen20. Ich will kurz die letztere, maximal dezentralisierte Organisationsform umreißen, wobei von ihr in der Praxis wahrscheinlich immer Abstriche gemacht werden müssen zugunsten einer zuverlässigeren top-level-Kontrollstruktur und eines geringeren Kommunikationsaufwandes:
Charakter der Wahl
Jeder Agent weiß um die Agenten, denen er antworten und denen er etwas abfordern kann, und er kann zwischen ihnen auswählen. Jeder Agent kann auf eine Anforderung antworten oder es unterlassen.
Typ der Information für die Wahl
Komplexe, dynamische Informationen bestimmen flexibel und durch wechselnde Mechanismen das Frage- / Antwortverhalten und den Gesprächspartner. Adaption und Learning gehen in diese Überlegungen ein.
Informationstransfer und Transmission
Agenten haben umfangreiche Gelegenheit zu Konversation, Freiheit zu antworten und können autonom und kollektiv Protokolle oder Formate (um-) definieren.
Auswahl des "Ansprechpartners"
Es finden lokale, kontext- und agentenabhängige Evaluationen statt. Eventuell findet der Agent momentan niemanden, den er für geeignet hält und kann die Anfrage später erneut initiieren.
Selektionsprozeß
Die Agenten wählen sich in wechselseitigem Einverständnis gegenseitig aus, alle Resultate und Informationen, die ihnen zur Verfügung stehen, werden in diesen Prozeß einbezogen (eventuell, um einen anderen Agenten zur Aufnahme von Interaktion/Kommunikation zu "überreden").

Dieses Konzept erlaubt Agenten, selbst zu entscheiden, wen sie mit der Erledigung von Subtasks betrauen "wollen" und für wen sie selbst wiederum arbeiten "wollen". Sie können Arbeitsaufwand delegieren, wenn sie beschäftigt sind oder freiwillig und selbständig übernehmen, wenn sie gerade nichts zu tun haben. Durch ihr Metawissen um sich selbst und um die anderen Agenten werden sie Aufgaben, von denen sie wissen, daß sie sie nicht gut erfüllen können, gar nicht erst annehmen. In einem "kollektiven Lernprozeß" finden sich allmählich die dem jeweiligen Fall angemessenen, produktiven Kombinationen; Hierarchien, Spezialisierungen und "interagentive" Anerkennung bilden sich autonom. Bemühungen laufen natürlich dahin, diese Freiheiten so zu begrenzen, daß die "Kreativität" und Produktivität nicht gehemmt wird, daß aber dennoch sich ein Agent oder die System-Operatorin auf die Kooperation verlassen kann. Ein Beispiel, welches dies mit interner Intentionsrepräsentation, "Verantwortlichkeit" und einem vorher vereinbarten "code of conduct" zu lösen versucht, findet sich im Anhang C.

Ein zentraler und mittlerweile weitgehend etablierter Mechanismus zur Koordination und Informationsübermittlung zwischen Agenten ist das sogenannte Blackboard System (z.B. Hearsay II). Dabei werden die vorgeschlagenen Lösungen, eventuell mit der dazugehörigen Erklärung, übertragen. Dies soll das Kommunikationsinterface dahingehend entlasten, daß die Information, die kommuniziert wird, solche eines Typs ist, mit dem das System sowieso hantiert. Ein kleines Beispiel: Drei Systeme sollen eine Routingaufgabe kooperativ lösen, wobei eines der Systeme für das gesamte Netz zuständig ist, die beiden anderen für Subnetze. Nachdem alle sich des Problems vergewissert haben, erarbeitet jeder Agent für sich eine Lösung und schickt die vorgeschlagene Route an das "Obersystem". Dieses vergleicht die eigene Lösung mit denen der anderen Agenten, versucht sie zu integrieren und schickt ein verfeinertes Routingschema an die Agenten, die dann dafür zuständig sind, innerhalb ihres autonomen Bereiches, die Vorgaben irgendwie zu erfüllen. Die Lösungsvorschläge, sowie die Information, die zwischen den Agenten hin- und hergereicht wird (wenn man von Hierarchie-, Status- und Koordinationsinformationen absieht), sowie das, was die Agenten anschließend an Aktionen durchzuführen haben, sind alle im selben Format (Routingtabellen).
Noch Bedarf an Methoden und Mechanismen besteht auf den Gebieten der Aufgabenzuweisung, des Zeitplanprotokolls und der Strukturierung von Systemen intelligenter Agenten.

Das System21

Ich will ein im Netz verteiltes System von Agenten entwerfen, die kooperativ mit Netzmanagement betraut sind und die sich auf jeweils eine der Aufgaben des NM spezialisiert haben.

Jeder Agent kann auf verschiedene (objektorientierte) Datenbanken / Ressourcen zugreifen. Dazu besitzt er ein "Lokales Application Interface", welches in Verbindung mit einem "Distributed Object Manager" die Datenobjekte in seinen Arbeitszusammenhang einbettet und über das er auf die Datenbanken zugreift. Dieses Interface ist zuständig für:

Das Interface ist ein eigenes System künstlicher Intelligenz, das aber gegenüber dem Expertensystem verpflichtet, d.h. in seiner Autonomie extrem eingeschränkt ist22.

Greifen wir nun einen Agenten heraus - den, der sich auf Traffic Management spezialisiert hat. Er ist in Agent0 programmiert und unterhält eine interne Datenbank (Internal Blackboard) aus Beliefs und Commitments. Er erhält von anderen Agents - z.B. von den regional verteilten Netzwerkswitch-Relais oder vom Kundendienst, dem das Problem berichtet wurde - die Aufforderung, ein Problem des Verkehrsflusses zu beheben, oder er erhält Statusinformationen von Sensoren, die zuerst als Belief gespeichert werden, dann infolge eines Commitments des Agenten sich selbst gegenüber analysiert werden, und aus denen er den weiteren Belief zieht, daß ein Problem seines Zuständigkeitsbereichs vorliegt. Er sendet eine Anforderung an ein weiteres intelligentes, ihm untergeordnetes System das Problem genauer zu analysieren und zu planen, wie es zu beheben wäre. Die ihm vorgeschlagene Lösung - z.B. ein Routingschema mit Erklärungen - wird über ein (externes) Blackboardsystem mit anderen Agenten (anderen Netzwerkoperationszentralen oder dem Repair&Mainntenance-Agenten) abgestimmt und schließlich in Subschemata und Routingtabellen aufgeteilt und an die Netzwerkswitches zur Durchführung gegeben. Ein Commitment wird gespeichert, das den Agenten dazu verpflichtet, von Zeit zu Zeit nachzuschauen, ob nicht das Problem sich erledigt hat und das installierte Schema besser wieder aufzuheben wäre.

Das für diesen Agenten arbeitende Analyse- und Planungssystem namens NetTrac basiert auf Case-Based Reasoning. Es erhält vom Agenten die Sensordaten (oder es erhält sie nach Autorisierung durch den Agenten direkt aus dem Netzwerk) und versucht, über die Komponenten Monitor, Kategorien-Index und Fall-Selector in der Falldatenbank einen Fall zu finden, der hinreichende Analogien aufweist23. Die letztendliche Auswahl erfolgt dahingehend, welcher Fall dem aktuellen am ähnlichsten ist und welcher zu einem wünschenswerten Ergebnis geführt hat. Dann wird die erprobte Lösung des gefundenen Falls an die aktuell vorgefundene Situation angepaßt, Parameter werden aktualisiert, etc. - dies nimmt der Modifier vor, indem er festlegt, welche Eigenschaften von einem etwas ähnlichen Fall "geborgt" werden können. Diese Fähigkeit reduziert natürlich den notwendigen Umfang der Datenbank. Sich abzeichnende Muster werden erkannt und in ein adaptives Indexing kanalisiert. Schließlich geht der Lösungsvorschlag wieder zurück an den Agenten und gleichzeitig an den Learner, um als neuer (oder alter) Fall mit alter (oder neuer) Lösung in die Datenbank eingepaßt zu werden. Außerdem erhält der Learner auch Rückmeldungen vom Agenten selbst über Erfolg oder Fehlschlag eines Fall-Lösungs-Paares, die er in die Datenbank integriert.

Der Learner schließlich erweitert die Falldatenbank nicht nur aufgrund von Feedback, sondern er setzt auch ein weiteres intelligentes System aktiv ein, ein Integriertes LernSystem. Dieses erstellt mithilfe verschiedener Machine-Learning-Paradigmata neue Fall-Lösungs-Paare, die nach einem Probelauf in wieder einem anderen intelligenten Simulations-System oder in der Praxis der Datenbank hinzugefügt werden. Die verschiedenen Lernmechanismen sind: MACLearn, die Erprobung, ob sich verschiedene Kombinationen aus Sensordaten oder Routing-Aktionen zu Makros zusammenfassen lassen, die die Suche erheblich beschleunigen; NetMan, die Entwicklung einer Strategie und die Zuordnung von verschiedenen Informationen zu Lösungsstrategien aus kausalem Wissen, aus domänenspezifischem Wissen um Kontrolloperationen und aus Wissen um die Netzwerktopologie: aus Regelbefolgungen, die zu nützlichen Ratschlägen führten werden Makros gespeichert, Aktionen werden mit einer gewichteten Beschreibung ihres Erfolgs versehen - diejenigen, die sich als wertvoll bewiesen haben, werden wahrscheinlich in Zukunft wiederverwendet werden und es findet eine Registrierung von möglichen Ursachen von Fehleinschätzungen statt; Function based induction (FBI), eine Erweiterung von ID3, die generalisierende und komprimierende Entwicklung von Entscheidungsbäumen aus Situationsmerkmalen und Beispielen in den umfangreichen verteilten Reports und Logs des gesamten Netzwerks. Es lassen sich nahezu beliebige und nahezu beliebig viele weitere Lernmechanismen integrieren.
Es gibt einen Learning Coordinator (TLC), der die einzelnen, als Agenten implementierten Lernstrategien koordiniert. Dazu durchläuft er alle fünf Minuten folgenden Zirkel:
Er fordert die Agenten auf, ihm Rat zu erteilen, wie das Netz im Moment verbessert werden könnte. Die Agenten antworten und versehen ihre Ratschläge mit Wertungen von 1 bis 5, je nachdem, für wie wertvoll, verläßlich und nützlich sie ihren Vorschlag halten. Dann übermittelt der Coordinator die Vorschläge an die jeweils anderen Agenten mit der Aufforderung zur Stellungnahme. Die Antwort besteht wiederum aus einer Wertung von 1 bis 5. Der Coordinator mittelt dann die drei Bewertungen für jeden Vorschlag, wählt den mit dem höchsten Resultat aus und schickt ihn an den Netz-Simulations-Agenten oder an das Traffic-Management-Expertensystem. Wenn er von diesen ein Feedback erhält, informiert er die Agenten, welcher der Lösungsvorschläge gewählt wurde und gewährt diesen Zugriff auf die aktualisierten Performance-Daten. Sie erklären schließlich, wenn sie die Daten fertig bearbeitet haben und der Kreislauf beginnt von vorne. Das ganze Lern-System ist ein vollständig verteiltes, heterogones System, das via TCP/IP kommuniziert und interagiert.

Schlußfolgerung

Wie ich versucht habe deutlich zu machen, sind Systeme, die auf Künstlicher Intelligenz aufbauen bereits im Einsatz, und sie erledigen ihre Arbeit mit einer verblüffenden Zuverlässigkeit. In Sektoren, die weniger komplex als das Netzwerkmanagement sind, liefern sie diagnostische Trefferraten von über 90%, und auch im Netzwerkmanagement sind sie besser als die durchschnittlichen Netzwerkexpertinnen - mindestens jedoch genauso gut.
Ich möchte trotz aller Begeisterung noch einmal an den nun auch in diesem bisher auf hohe Spezialisierung und langjährige Erfahrung und Berufspraxis angewiesenen Arbeitsfeld drohenden - und wohl gar nicht aufzuhaltenden - Arbeitsplatzverlust und eine ethische Frage erinnern, die letzten Endes aber jede mit sich selbst ausfechten muß.
Die diversen Anstrengungen im Bereich der Künstlichen Intelligenz laufen parallel in dem Bemühen, menschliche Kapazitäten nachzubilden24. Die Fortschritte sind enorm, und was nach meinem Dafürhalten die größte noch ausstehende Aufgabe ist, ist die Integration und Standardisierung der verschiedenen Methoden, Paradigmata, Ansätze und Forschungsergebnisse. Wie der letzte Teil, das "fiktive" Beispiel wohl gezeigt hat, dürfte auch dies (technisch) nicht allzu schwer fallen. Was wahrscheinlich eher der Hemmschuh sein wird, ist die "langsame" Entwicklung und Anpassung an innovative, progressive Forschungsergebnisse der Netzwerke und Organisationen selbst25. Immerhin ein Vorteil, daß AI-Systeme so schnell nicht ohne menschliche Supervision und Arbeitskraft ihren Dienst versehen werden.
Verschiedentlich wurde die Meinung geäußert, der leistungsfähigste Computer der Welt sei ein Verbund von Computern: das Internet. Solch ein Verbund von Computern stellt tatsächlich die Hardware-Plattform dar, auf der sich (D)AI erst effektiv einsetzen läßt. Umgekehrt kann nur (D)AI das Potential dieses Verbundes ausnutzen - das Betriebssystem und die Applikationen auf dem leistungsfähigsten Computer der Welt werden KI-Systeme sein.
Jedenfalls - und nun ohne Pathos - bietet KI genügend Computing Power, und zwar deutlich mehr als konventionelle, algorithmische Ansätze, um zu DER Querschnittstechnologie zu werden, gerade was komplexe Aufgaben angeht. Eine solche ist eben das Netzwerkmanagement.

Anhang

A - Der C4-Algorithmus26: 


repeat several times:

GROW:

	initialise working set

	repeat FORM TREE for working set:

		if stopping criterion satisfied,

			choose best class

		otherwise

			choose best attribute test

			divide working set accordingly

	 		invoke FORM TREE in subsets

		test on remainder of class

		add some misclassified items to working set

	until no improvement possible

PRUNE:

	while decision tree contains subtrees that are both complex 

	and of marginal benefit,

		replace subtree by leaf

	select most promising pruned tree
Der Entscheidungsbaum wird rekursiv aufgebaut. Dabei wird eine Menge von Items daraufhin untersucht, ob sie eine Klasse bilden. Wenn ja, so ist der Entscheidungsbaum für diese Menge ein einziges Blatt bestehend aus eben der Menge. Wenn nicht, wird ein Test bezüglich eines Attributs ausgeführt, der die Menge in n Untermengen unterteilt. Dies wird rekursiv wiederholt, bis wir einen Entscheidungsbaum mit Tests und Blättern für die ursprüngliche Menge haben. Ein stopping criterion soll den Algorithmus gegen Noise absichern, ein gain ratio criterion wählt den besten Test aus. Normalerweise wird eine Untermenge von 10% der Beispieldaten ausgewählt, um den Baum zu erstellen, mit dem dann der Rest klassifiziert wird. Schlägt dies fehl, so wird eine geringe Anzahl von "misclassified items" der Untermenge hinzugefügt und ein komplett neuer Baum erstellt. Der Prune-Algorithmus wird ebenfalls iterativ durchlaufen: Der Unterbaum, dessen Verhältnis von Komplexität des Unterbaumes (gemessen als durchschnittliche Pfadlänge von der Wurzel zu den Blättern des Unter-baumes) und Fehlerzunahme bei Ersetzung durch ein Blatt am schlechtesten ist, wird durch ein Blatt ersetzt, wenn dieses Verhältnis bedeutend schlechter ist als das durchschnittliche des Gesamtbaumes.

B - Case-Based Reasoning Process:

Ein weiteres Bild des CBR-Zyklus' (16KB)

C - Agenten-interne "Intention Representation" - GRATE* 27


Name: 		(Diagnose-Fault)

Motivation: 	((Diagnose-Network-Fault))

Chosen Recipe:	(((Start(Identify-Initial-BOA)) 

		(Start(Generate-Tentative-Diagnosis)) 

		(Start(Monitor-Disturbance))) 

		((Start(Perform-Final-Diagnosis)))

Start Time: 	8	Max. End Time: 	82

Duration:	74	Priority:	20

Status: 	Executing-Joint-Action 

Outcome: 	(Validated-Fault-Hypotheses)

Participants: 	((SELF Proposer Executing-Joint-Action) 

		(AGENT3 Team-Member Executing-Joint-Action) 

		(AGENT9 Team-Member Executing-Joint-Action))

Bindings: 	((Agent3(Identify-Initial-Boa)19) 

		(Self(Generate-Tentative-Diagnosis)19) 

		(Agent9(Monitor-Disturbance)19) 

		(Self(Perform-Final-Diagnosis)35))

Contribution:	((Self((Generate-Tentative-Diagnosis)(YES Selected))

			((Perform-Final-Diagnosis)(YES Selected))) 

		(Agent3((Identify-Initial-BOA)(YES Selected)))

		(Agent9((Monitor-Disturbance)(YES Selected))))
Chosen recipe ist Reihe von (verteilten) Aktionen, die das angezielte Outcome erreichen sollen. Für individuelle Intentionen ist es der Name der lokalen Prozedur. Der Status bezeichnet die Phase, in der sich die Ausführung gerade befindet: forming-group, developing-solution oder executing-joint-action. (Bei individuellen Aktionen/Intentionen: executing oder pending) Participants bezeichnet die Organisationsstruktur der Gruppe. Bindings benennen die Agenten, die zur Lösung beitragen sollen, zusammen mit der jeweils erforderlichen Aktion und der angezielten Zeit. Contribution benennt die Agenten, die Interesse an Kooperation bekundet haben, mit den Aktionen, die sie durchführen können, und ob sie diese Aktionen bereit sind auszuführen.
Wenn alle potentiellen Team-Members ihr Einverständnis und ihre Teilnahme erklärt haben, beginnt der Proposer, auf einem Recipe basierend, einen detaillierten Plan zu erstellen. Dabei sollen unter anderem genauere Timing-Angaben gefunden werden. Der Algorithmus hierfür:

For all actions in recipe do

	select Agent A to carry out action a  

		(criteria: minimize group members)

	calculate time t(a) for a to be performed based on 

						temporal orderings

	send (a,t(a)) proposal to A

	A evaluates proposal against existing commitments (C's):

	if no-conflicts (a,t(a)) then 

		create commitment C(a) for A to (a,t(a))

	if conflicts ((a,t(a)), C) and priority(a) > priority(C) then 

		create commitment C(a) for A to (a,t(a)) and reschedule C

	if conflicts ((a,t(a)), C) and priority(a) < priority(C) then 

		find free time (t(a)+Dt(a)) 

		note commitment C(a) 

		return updated time to leader

	if time proposal modified, update remaining action times by Dt(a)

Wobei ein commitment zu kreieren heißt, eine individuelle Intention (s.o.) zu registrieren:

Name:	 	(Achieve(Identify-Initial-BOA)

Motivation:	(Satisfy-Joint-Action(Diagnose-Fault))

Chosen Recipe:	(Identify-Initial-BOA)

Start Time:	19		Max. End Time:	34

Duration:	15		Priority:	20

Status:		Pending		Outcome:	(Black-Out-Area)
Dieser "code of conduct" führt zu geringerer Ressourcenverwendung, größerer Flexibilität (gemessen daran, wann Kooperation für die einzelnen Agenten untragbar/unrentabel wird) und braucht nicht mehr Rechenaufwand als die implizite Erschließung von Verhaltenscodes - der Nachteil ist der größere Kommunikationsoverhead.

D - Ein verteiltes System zum Netzmanagement

Das komplette Szenario (20KB)

E - Die Abarbeitung von Aufgaben im Agenten

Die interne Funktionsweise eines Agenten (21KB)

Literatur

Fußnoten:

1 Einfachere Probleme lassen sich auch konventionell / algorithmisch lösen.

2 Die verfügbare Literatur bezieht sich fast ausschließlich auf Telefonnetzwerke. Dies ist aber kein Nachteil, da a) diese bezüglich des Managements nicht konzeptuell von packet-switched (data) networks sich unterscheiden, b) die hier beschriebenen Aufgaben eine wichtige Untermenge der Aufgaben im Management von Computer-Netzwerken sind (z.B. Routing und Fehlerdiagnose) und c) die Telefonnetzwerke (noch jedenfalls) ungleich komplexer sind.

3 Damit sind Registerdaten gemeint, die sog. Pegcounts, die in regelmäßigen Intervallen von den Netzschaltrelais an die Netzwerkzentrale geschickt werden.

4 Damit sind binäre Statusindikatoren gemeint, in denen die Relais der Zentrale z.B. ihren Status mitteilen.

5 S. Goyal, R. Worrest: Expert System Applications to Network Management. In: J. Liebowitz (Ed.): Expert System Applications to Telecommunications. New York 1988. S. 23.

6 Vgl. S. Hedberg: AI's Impact in Telecommunications: Today and Tomorrow. Http://www.computer.org/pubs/expert/1996/insight/x10006/insight.htm

7 Zu diesen AI-Technologien s.u.

8 Automated Cable Expertise (ACE) ist ein Diagnosesystem von AT&T, das unter UNIX OPS4 und LISP C läuft und hauptsächlich auf forward chaining rules beruht. Es wird bereits in über 100 Regional Bell Operating Company (RBOC) Zentren eingesetzt.

9 vgl. S. Goyal, R. Worrest: Expert System Applications to Network Management. A.a.O.

10 S. Goyal, R. Worrest: Expert System Applications to Network Management. A.a.O. S. 39.

11 vgl. P. Agre, I. Horswill: Cultural Support for Improvisation. In: Proceedings of the Tenth National Conference on Artificial Intelligence, AAAI-92. Menlo Park 1992.

12 S. Goyal, R. Worrest: Expert System Applications to Network Management. A.a.O. S. 39.

13 S. Goyal: Artificial Intelligence in Support of Distributed Network Management. in: Sloman (ed.): Network and Distributed Systems Management. Addison-Wesley 1994

14 vgl. D. Michie: Current Developments in Expert Systems; J.R. Quinlan et al.: Inductive Knowledge Acquisition: a Case Study; S. Hood, K. Mason: Knowledge-based Systems for Real-time Applications. Alle in: R. Quinlan (ed.): Applications of Expert Systems. Addison-Wesley 1987. Hier werden verschiedene Beispiele aus Agrarwirtschaft und Humanmedizin (1+3 Bsp.) angeführt, in denen diagnostische Systeme, die auf Induktion zurückgingen jeweils über 99%ige Trefferquote aufweisen. Theoretisch hängt die Zuverlässigkeit von mit ID3 - dem Vorgänger von C4 - generierten Systemen nur von der Menge der Beispiele ab, nicht von der Größe des "Falluniversums". Überraschend ergibt sich übrigens bei ID3 der Nachteil, daß sich in den maschinell generierten (funktionierenden) Regeln auch von Expertinnen nur schwer ein Sinn erkennen läßt, ein Nachteil, der bei C4 durch die Komprimierung, das "Pruning" des Entscheidungs-baumes inzwischen weitgehend aufgehoben wird. Im Anhang A findet sich der C4 - Algorithmus.

15 Vgl. A. Aamodt, E. Plaza: Case-Based Reasoning: Foundational Issues, Methodological Variation, and System Approaches (AICom Paper) Http://www.iiia.csic.es/People/enric/AICom.html sowie I. Watson: Case-Based Reasoning Development Tools: A Review. http://www.salford.ac.uk/docs/depts/survey/staff/IWatson/cbrtools.htm Ein weiteres Schema des CBR-Prozesses findet sich im Anhang B.

16 B. Silverman et al.: Distributed expert systems: Facility Advisor. In: J. Liebowitz (1988) S. 315f. Ein Diagramm, das diesen Prozeß darstellt, findet sich im Anhang E.

17 Agent0 ist ein Interpreter, der auf Common Lisp aufsetzt. Vgl. Http://www.scs.ryerson.ca/~dgrimsha/courses/cps720/agent0.html

18 Vgl. D. Novick, K. Ward: Multiple Beliefs of Multiple Conversants: A Computational Model of Collaboration in Air Traffic Control. In: Proceedings of the Eleventh National Conference on Artificial Intelligence, AAAI-93, Menlo Park 1993

19 Die "combinatorial explosion" bezeichnet das mit den Variablen/Parametern exponentielle Anwachsen von durchzuspielenden/auszuprobierenden Kombinationen, um eine günstige Lösung zu finden.

20 Vgl. E. Ephrati, J. Rosenschein: Constrained Intelligent Action: Planning Under the Influence of a Master Agent. In: AAAI-92. Oder B. Silverman, H. Hexmoor, J. Chang: Distributed Expert Systems: Facility Advisor. A.a.O.

21 Ich beziehe mich hier fast ausschließlich auf den Aufsatz von S. Goyal: AI in Support of Distributed Network Management, a.a.O. Es werden dort verschiedene Forschungsprojekte und laufende Systeme der Firma GTE Laboratories referiert. (Allerdings fand ich keinen aktuelleren Stand als eben disen Aufsatz - 1993) Siehe Anhang D.

22 Vgl.: S. Goyal, R. Worrest: Expert System Applications to NM. A.a.O. Dort wird das Beispiel eines Intelligent Database Assistant (IDA) beschrieben, der eben diese Funktion (als Agent) erfüllen soll.

23 In der (mir verfügbaren) Literatur wird leider verschwiegen, wie die Indizierung der Fälle genau verläuft. Es wird lediglich gesagt, NetTrac selbst indiziere die Fälle "den kritischen Eigenschaften der Situation entsprechend, die zusammengenommen die mögliche Anwendbarkeit jedes Falls anzeigen". (S. Goyal: AI in Support of Distributed Network Management, a.a.O. S.561) - Die unbeantwortete Frage ist jedoch, wie NetTrac herausfindet, welches die kritischen Eigenschaften einer Situation sind.

24 Vgl. E. Durfee: What Your Computer Really Needs to Know, You Learned in Kindergarten. In: AAAI-92.

25 Vgl. H. Kitano et al.: Builing Large-Scale and Corporate-Wide Case-Based Systems: Integration of Organizatio-nal and Machine Executable Algorithms. In: AAAI-92.

26 Siehe J.R. Quinlan et al.: Inductive Knowledge Acquisition: a Case Study. A.a.O. S. 162ff.

27 Siehe N.R. Jennings, E.H. Mamdani: Using Joint Responsibility to Coordinate Collaborative Problem Solving in Dynamic Environments. In: AAAI-92.