Wissensbasis

Die Wisssensbasis ist als einfache Prolog-Datenbasis organisiert, in die beliebiges Faktenwissen eingetragen werden kann. Stärker strukturierte Repräsentationsfor-men, wie sie in kognitiven Architekturen zum Einsatz komRepräsentationsfor-men, werden nicht un-terstützt.

6.5.1 Sammlung von Erfahrungswissen

In die Architektur wurde ein einfaches Lernkonzept integriert. Es findet eine Auf-zeichnung von Leistungsdaten statt, die den Zweck hat, Handlungsentscheidungen eines Agenten mit der Zeit zu verbessern. Dabei wird die Kontrolle des Skriptma-nagers über die verarbeiteten Handlungsskripte genutzt, um statistische Werte zu er-heben. Durch die Reduktion auf einfache quantitative Aussagen gehen jedoch De-tailinformationen verloren. So werden die unterschiedlichen Variationen eines

Skriptaus-wahl

Skript anhand aktueller Task-Parameter und aktueller nor-mativer Ziele selektieren und Interpreter übergeben;

Wenn kein Skript auswählbar, Kooperation starten oder Fehlermeldung

empfange-ner Sprechakt

Empfangsprozedur ausführen, falls vorhanden, Fehlermel-dung, falls Sprechakt oder Inhalt unbekannt;

eventuelles Ergebnis in Form instantiierter Variablen zurück an Interpreter geben

Zugehörige Task deaktivieren und Taskbeendigung nach oben durch das Intentionalitätsnetz propagieren

Skript ab-gebrochen

lokale Fehlermaßnahmen einleiten (anderes Skript auswäh-len), andernfalls Fehlerbehandlung auf Task- und Zielebene durchführen

Scheduler Task-Prio-rität

Priorität einer aktiven Task aufgrund der Anzahl der Be-gründungen (Aktivierungen) berechnen

TABELLE 7. verarbeitbare Nachrichten des Intentionalitätsmoduls Ursprung Inhalt Verarbeitung

Skripts, wie sie durch das Auftreten von Tasks oder Kooperationsformen im Skript-rumpf auftreten können, nicht unterschieden. Insbesondere in Kooperationsproto-kollen hängen Ergebnisse und Performance von der Anzahl und Qualität der betei-ligten Agenten ab - mithin Parmetern, die weder statisch noch a priori bekannt sind.

Aus diesen Gründen werden jeweils zwei statistische Werte ermittelt: der Mittel-wert als Durchschnittsgröße und die Standardabweichung (Varianz) als Aussage zur Schwankungsbreite.

• Zeit: Der Skriptmanager mißt für jedes Skript die verbrauchte Zeit. Im Falle ei-ner Suspendierung der Ausführung wird die Zeitnahme entsprechend unterbro-chen. Nur für erfolgreich abgearbeitete Skripte werden durch die Zeitmessung der Durchschnittswert und die Standardabweichung ermittelt. Diese Werte fin-den bei der Skriptauswahl im Falle eines aktiven normativen Ziels „Zeitmini-mierung“ Berücksichtigung. Standardmäßig findet die Effizienzberechnung ohne Berücksichtigung der aktuellen Parameter statt. Alternativn kann im Skripteditor veranlaßt werden, daß die Verarbeitungsdauern auch einzeln für je-de Parameterbelegung durchgeführt werje-den. Diese Maßnahme kann sinnvoll sein, wenn ein Skript nur wenige Aufrufvarianten besitzt.

• Kosten: Auch der generische Kostenparameter wird zur Informationssammlung genutzt. Kosten sind für alle elementaren Skriptelemente definiert und summie-ren sich im Zuge der Verarbeitung. Sie kommen bei der Skriptauswahl zum Tra-gen, wenn das vordefinierte normative Ziel „Kostenminimierung“ aktiv ist.

• Ergebnisse: Skriptresultate können wahlweise gespeichert werden - dies ist über ein Flag im Skripteditor einstellbar. Nutzen bringt dieses Caching wenn ein Skript komplexe Berechnungen durchführt, weil dann im Wiederholungsfall auf das bereits vorhandene Ergebnis zurückgegriffen werden kann. Entsprechend findet das Speichern für jede Parameterkombination statt. Defaultmäßig ist die-se Funktionalität nicht aktiviert, weil nicht a priori ausgeschlosdie-sen werden kann, daß Skripte Seiteneffekte haben (z.B. beim Speichern einer Datei) und der Nut-zen der Ergebnisspeicherung vom der Wahrscheinlichkeit der Wiederverwend-barkeit abhängt und somit anwendungsabhängig ist.

• Fehler: Treten Fehler bei der Skriptverarbeitung auf, werden diese protokol-liert. Als Fehlerquellen kommen Überschreitungen vorgegebener Zeit- oder Ko-stenlimits, nicht vorhandene Fähigkeiten und Fehler in der Kommunikation vor.

Die Ausfallwahrscheinlichkeiten und Fehlerursachen können für eine post-mor-tem-Analyse herangezogen werden und zu Aufschlüssen für besseres System-bzw. Agentendesign führen.

Auch die im Intentionalitätsmodul durchgeführten Berechnungen bieten sinnvolle Möglichkeiten zur Sammlung und Nutzung von Verarbeitungsdaten.

• Aktivierungen: Jede Skriptaktivierung wird mitgezählt. Das Wissen um die Häufigkeit ausgeführter Skripte wird bei der Skriptauswahl (Abschnitt 6.4.3) genutzt, um in der Lernphase auch für häufig vernachlässigte Skripte aussage-kräftige Laufzeitdaten zu erfassen⁸.

• Nichtberücksichtigung: Wenn ein Skript, das einer Task zugeordnet ist, nicht zur Ausführung kommt, wird auch dies protokolliert. Die Ursache liegt hierbei in den Filter- und Auswahlmechanismen der in Abschnitt 6.4.3 beschriebenen Skritpauswahl. Dieses Wissen kann jedoch nicht vom Agenten selbst verwendet werden, sondern dient der post-mortem-Analyse seitens des Agentenprogram-mierers.

Neben diesen Wissenserhebungen, die von Agenten selbständig durchgeführt wer-den, bietet die Architektur zahlreiche weitere Möglichkeiten zur Datensammlung.

Ermöglicht wird dies durch den Debug-Modus von Agenten, der im nachfolgenden Kapitel behandelt wird.

6.5.2 Persistente Datenhaltung

Zumeist ist es wünschenswert, den Zustand eines Agenten über dessen Lebenszeit hinaus zu speichern, damit bei einem Neustart auf dem Erfahrungswissen vor dem letzten Abbruch wieder aufgesetzt werden kann. Derartige Neustarts können beim Austausch eines Agenten durch eine neue Version oder auch nach einem Absturz notwendig werden.

Beim kontrollierten Herunterfahren eines Agenten werden die aktiven Tasks und Interaktionsprotokolle noch vollständig abgearbeitet, so daß sich der Agent am En-de im Ruhezustand befinEn-det. Der Agent läßt sich dann vollständig durch En-den Zu-stand der Wissensbasis beschreiben. Weil über die Wiederverwendungsmöglichkei-ten von Wissen generell keine zuverlässigen Aussagen getroffen werden können, speichern Agenten vor ihrem Ableben nur das im Rahmen der Leistungsdatenauf-zeichnungen erlernte Erfahrungswissen. Beim Neustart wird dann automatisch die-ses Wissen, zusammen mit dem initialen mentalen Zustand des Agenten, in das In-tentionalitätsmodul eingelesen. Für weitergehende persistente Datenhaltung ist der Programmierer verantwortlich. Die Architektur bietet hierfür Unterstützung in Form eines vordefinierten einstelligen persistent-Prädikats, mit dem Wissensmu-ster in Form von Prolog-Fakten für die spätere Speicherung spezifiziert werden können.

Der Persistenzmechanismus kann auch während der Laufzeit eines Agenten über die Benutzungsoberfläche angestoßen werden. Auf diese Weise lassen sich Backups ziehen, auf denen im Falle eines unkontrollierten Programmabbruchs wieder aufge-setzt werden kann. Ein Abspeichern des Zustands aktiver Skripte ist aufgrund der möglichen Seiteneffekte des von Hand programmierten Codes nicht möglich. In

8. Die „Lernphase“ erstreckt sich über den Zeitraum, in dem alle normativen Ziele, die die Skriptauswahl beeinflussen, inaktiv sind. Damit wird eine Lernstrategie wie beim reinforcement learning (Abschnitt 2.4.5 auf Seite 64) verfolgt, gemäß der auch schwach bewertete Aktionen zur Ausführung kommen soll-ten, weil die schlechte Bewertung auch auf mangelnde Datenerhebung zurückzuführen sein könnte.

den meisten Fällen abgebrochener Handlungen würden ohnehin Kommunikations-Timeouts auftreten⁹, so daß deren Fortsetzung oder Wiederausführung nicht mehr in Frage kommt. Außerdem erkennen die Kommunikationspartner eines Agenten dessen Nichterreichbarkeit und reagieren entsprechend durch Abbruch von Proto-kollen oder Suche nach anderen Informationsquellen.