Seminarausarbeitung Kooridnation und Teambildung in
Transcrição
Seminarausarbeitung Kooridnation und Teambildung in
Universität Paderborn Fakultät für Elektrotechnik, Mathematik und Informatik Seminarausarbeitung Kooridnation und Teambildung in Multiagentensystemen Bartlomiej Gloger vorgelegt bei Prof. Dr. Hans Kleine Büning Inhaltsverzeichnis 1 Einführung 2 2 Koordination 2.1 Exkurs: Kommunikation . . . . . . . . . . 2.2 Überblick über Koordinationstechniken . . 2.2.1 Organisierte Strukturen . . . . . . 2.2.2 Ausschreibung . . . . . . . . . . . . 2.2.3 Planung . . . . . . . . . . . . . . . 2.2.3.1 Zentrale Planung . . . . . 2.2.3.2 Verteilte Planung . . . . . 2.2.3.3 Vorteile und Nachteile von 2.3 Verhandlung . . . . . . . . . . . . . . . . . 2.3.1 Spieltheorie . . . . . . . . . . . . . 2.3.2 Planbasierte Verhandlung . . . . . 2.3.3 Menschenorientierte Verhandlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Planung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 6 6 8 9 10 10 10 10 11 12 12 3 Teambildung 14 4 Fazit 15 1 1 Einführung Koordination ist ein zentrales Thema in vielen Bereichen der Informatik wie Multiagentensysteme oder verteilte künstliche Intelligenz. Es wurde aber auch in anderen Disziplinen erforscht wie der Politologie, Sozialpsychologie oder in der Soziologie. Die Wirtschaftswissenschaften haben ein starkes Interesse an Koordination wie die Erforschung von Märkten mit einzelnen gewinnmaximierenden Firmen zeigt [Mal87]. Selbst biologische Systeme scheinen koordiniert zu sein, obwohl einzelne Zellen oder Agenten unabhängig agieren. Koordination ist ein Prozess in dem Agenten agieren, um sicherzustellen, dass eine Gruppe von Agenten sich in einer kohärenten Weise verhält. In dieser Ausarbeitung werden die Themen Koordination und Teambildung behandelt. Ein kleiner einleitender Exkurs in die Kommunikation zwischen Agenten soll zeigen wie die Nachrichten, die in der Koordination verwendet werden, umgesetzt werden. Das Kapitel 2 beschreibt verschiedene Koordinationsstrategien und deren Eigenschaften. Die Notwendigkeit von Koordination in Multiagentensystemen wird aufgezeigt. Im folgenden Kapitel 3 wird auf den nächsten Bereich der Koordination, nämlich Kooperation durch Teambildung, eingegangen. Weiterführende und auf Koordination aufbauende Aspekte wie Teamwork würden den Rahmen dieser Ausarbeitung sprengen, so dass abschliessend in Kapitel 4 ein Fazit gezogen wird. 2 2 Koordination Nach der einleitenden Definition von Koordination in der Einführung, wird diese näher erläutert. Koordination ist ein Prozess, in dem Agenten handeln, um zu gewährleisten, dass eine Gemeinschaft von Agenten sich in einer kohärenten Weise verhält. Kohärenz bedeutet, dass die Aktionen, die die Agenten ausführen, gelingen und nicht untereinander in Konflikt geraten. Mit anderen Worten kann man Kohärenz als Wirkung der Agenten als Einheit bezeichnen [Syc89]. Koordination bedeutet die gegenseitige (ggf. zeitliche) Abstimmung von Tätigkeiten. Dazu gehört auch das Verhindern von Livelock 1 und Deadlock 2 , sowie eine sinnvolle Ressourcenverwaltung. Man spricht von Kooperation, wenn Agenten ein gemeinsames Ziel verfolgen oder vereinbaren. Um erfolgreich kooperieren zu können besteht die Möglichkeit, Agenten ein Bild über die Fähigkeiten der anderen Agenten und ein Modell über die zukünftigen Schritte der Zusammenarbeit zu geben. In [NLJ94] werden verschiedene Gründe für die Koordination geliefert: Vermeiden von Chaos Da viele Multiagentensysteme dezentral angelegt sind und das Wissen über die einzelnen Agenten verteilt ist, besitzt jeder Agent nur eine eingeschränkte Sicht auf seine Umgebung und kann nicht die Aktionen aller anderen Agenten mitverfolgen. Das Wissen und die Ziele eines Agenten können leicht in Konflikt geraten mit anderen Agenten, die eventuell nicht in der Wahrnehmung des Agenten sind. Unter solchen Umständen können Nebeneffekte entstehen, das gewünschte einheitliche Verhalten des Gesamtsystems ist nicht mehr gewährleistet. Erfüllen von globalen Nebenbedingungen Agenten arbeiten immer in einer bestimmten Umgebung, sei es eine Softwareumgebung oder (ein Ausschnitt) der realen Welt, die sie durch Sensoren wahrnehmen. In dieser Umgebung existieren gewöhnlich Beschränkungen oder Regeln, die eingehalten werden müssen, damit das System erfolgreich arbeiten kann. Etwa müssen in Echtzeitumgebungen Zeitschranken eingehalten werden, Einkauf-Agenten dürfen ein bestimmtes Budget nicht überschreiten oder der Zugriff auf eine gemeinsame Ressource (Festplatte, Drucker, ...) ist nur exklusiv möglich. Effizienz Obwohl einige Agenten alleine arbeiten können, kann Koordination sinnvoll sein. Wird einem Agenten ein Problem gestellt, das bereits ein anderer 1 Als Livelock bezeichnet man den Zustand eines Agentensystems, das zwar aktiv ist und handlungsfähig, aber jede Handlung der Agenten keine Änderung an dem Zustand bewirkt. 2 Deadlock bezieht sich auf einen Zustand in dem weitere Aktionen von Agenten unmöglich sind. 3 2 Koordination Agent (zum Teil) gelöst hat, kann das Wissen des anderen Agenten die eigene Problemlösung stark beschleunigen. Kann das Problem vielleicht in kleinere Teilprobleme aufgeteilt werden, kann das Erreichen der Lösung durch Delegation beschleunigt werden. Verteiltes Wissen oder Ressourcen Agenten können verschiedenes Wissen haben. Beispielsweise ein Agent, der für einen Chirurg steht und ein anderer der einen Anästhetist vertritt. Der Chirurg kann die Operation nicht ausführen, ohne dass der Patient in Narkose ist. Die Agenten eines Systems haben oftmals unterschiedliche Fähigkeiten und Beschränkungen, Aktionen durchzuführen oder Ressourcen zu nutzen. Auch die Kenntnisse und Informationsquellen verschiedener Agenten können stark voneinander abweichen. Abhängigkeiten zwischen Aktionen Der Chirurg aus dem obigen Beispiel muss warten bis der Patient in Narkose ist damit er mit der Operation anfangen kann. Oft hängt die Lösung der Aufgaben und Erfüllung der Ziele von Agenten von einander ab: Ein Agent muss auf das Ende der Tätigkeit eines anderen Agenten warten, bevor er selbst aktiv werden kann. Koordination kann Kooperation erfordern, aber es ist wichtig zu betonen, dass Kooperation nicht unbedingt in kohärentem Verhalten resultiert. Es kann passieren, dass Agenten verschiedene Modelle von den Annahmen der anderen Agenten haben, so dass zukünftige Handlungen in Konflikten resultieren. Andererseits ist Wettbewerb eine Form von Koordination, in der Agenten mit verschiedenen Zielen sich ohne Kooperation absprechen. Um Koordination zu erreichen, kann es notwendig werden, dass Agenten miteinander kommunizieren. Wie in [HS94] zu lesen ist, kann Koordination aber auch ohne Kommunikation erreicht werden, indem die Agenten Verhaltensmodelle von anderen Agenten nutzen. In diesem Fall wird Koordination hauptsächlich durch Organisation des Wissens erreicht. In den Fällen, wo Kommunikation möglich ist, ist es von Vorteil, dass die Agenten sich gegenseitig ihre Ziele, Intentionen, Ergebnisse und Zustände mitteilen. Das Ergebnis eines Koordinationsvorgangs ist ein kohärenter initialer Zustand der Agenten, in dem Deadlocks und Livelocks vermieden werden. Weiterhin minimiert dieser Zustand Konflikte zwischen Agenten und maximiert die Ausnutzung derer Fähigkeiten. 4 2 Koordination 2.1 Exkurs: Kommunikation Die Koordination erfordert zumeist Kommunikation. Dieser Einschub soll ein wenig die in der Koordination benutzten Kommunikationsmechanismen aufzeigen. Eine wichtige Sprache für die Agentenkommunikation ist KQML (Knowledge Query and Manipulation Language). Diese basiert auf der Sprechakttheorie, die die grundlegende Annahme hat, dass jede Kommunikation eine Aktion darstellt. Ursprünglich war das das Erklärungsmodell für die menschliche Sprache. Jede Nachricht hat drei Aspekte: Einmal die Lokution, also wie die Nachricht formuliert ist (z.B.: ’Es ist heiss hier.’ oder ’Mach die Heizung aus.’). Dann die Illokution, wie die Nachricht vom Sender gemeint ist und wie vom Empfänger verstanden (z.B. als Bitte die Heizung auszumachen, als Feststellung). Und als letztes die Perlokution, wie die Nachricht das Verhalten des Empfängers beeinflusst (z.B. Heizung ausmachen, Fenster öffnen, Kopf nicken oder nichts tun). Weiterhin gibt es drei Ebenen der Beschreibung des Nachrichteninhalts. Die Syntax repräsentiert Informationen und Anfragen in Form einer gemeinsamen Sprache (Grammatik). Die Semantik ist ein strukturiertes Vokabular (Begriffswelt) und eine gemeinsam bekannte Bedeutung der Entitäten in der Begriffswelt und möglicher Beziehungen zwischen ihnen. Und die Pragmatik beschäftigt sich damit herauszufinden, mit wem man kommuniziert, wie Kommunikation initiiert oder aufrechterhalten werden kann und welche Effekte Kommunikation auf den Kommunikationspartner hat. Die Knowledge Query and Manipulation Language (KQML) ist eine Abstrahierung der menschlichen Sprache. Sie wird als Kommunikationssprache eingesetzt, um Interaktionen zwischen Agenten auszulösen. Der semantische Inhalt der in KQML verfassten Nachricht kann z.B im Knowledge Interface Format (KIF) übermittelt werden. KIF erlaubt die Definition von Objekten und kann Funktionen und Relationen abbilden, wie es von objektorientierten Sprachen bekannt ist. KQML beschreibt also das Format der Nachricht, während die Information in KIF ausgedrückt wird. Bei einem Austausch von Information zwischen unterschiedlichen Quellen ist es wichtig, dass die gesamte Information, die notwendig ist, um den Inhalt der Nachricht zu verstehen, Bestandteil der Nachricht ist. Die Eigenschaften einer Sprache für die Kommunikation zwischen Agenten, die Vorteile erreichen: Form Die Form sollte selbsterklärend und verständlich sein. Das heisst syntaktisch einfach und für einen menschlichen Leser einsichtig. Inhalt Erkennbarer Unterschied zwischen Kommunikationssprache und Inhaltssprache, das heisst der Teil, der sich um das Protokoll kümmert, soll unterscheidbar sein von dem, der sich um den transportierten Inhalt kümmert. Semantik Sollte fundiert in der Theorie sein und auf keinen Fall mehrdeutig. Implementierung Sollte effizient sein. 5 2 Koordination Netzwerk Sollte Möglichkeiten für alle grundlegenden Verbindungen liefern und eine ausreichende Menge von Primitiven bereitstellen, so dass Protokolle auf höheren Ebenen erstellbar sind. Umgebung Die Sprache sollte fähig sein mit heterogenen und dynamischen Umgebungen umzugehen und interoperabel mit anderen Sprachen sein. Verlässlichkeit Sollte verlässlich und sicher sein. 2.2 Überblick über Koordinationstechniken Es gibt viele Ansätze um Koordination in Multiagentensystem zu erreichen. Die in dieser Ausarbeitung verwendete und weit verbreitete findet man in [Wei00]: • Organisierte Struktur • Ausschreibung (Kontraktnetz) • Planung • Verhandlung 2.2.1 Organisierte Strukturen Dieses Szenario ist das einfachste, denn es existieren Strukturen, die Verantwortlichkeiten, Fähigkeiten, den Zusammenhang und den Kontrollfluss definieren. Hier werden die Agenten in einer festen hierarchischen Struktur angeordnet, und damit auch die Verbindungen zwischen den einzelnen Agenten von vornherein festgelegt. Der Entwickler bestimmt also bei der Erstellung des Multiagentensystems für jeden Agenten dessen Tätigkeits- und Verantwortlichkeitsbereich und gibt auch die Kommunikationswege (entlang der Hierarchie), welche Agenten untereinander kommunizieren sollen, vor. Aus den Hierarchien ergibt sich die Client/Server (Master/Slave) Architektur, die typischerweise genutzt wird um Ressourcen oder Aufgaben zu verteilen. Der Master-Agent an der Spitze der Hierarchie nimmt eine Aufgabe entgegen, teilt sie gegebenenfalls in Teilaufgaben auf und reicht sie an spezielle Slave-Agenten eine Stufe tiefer weiter. Die Slave-Agenten bearbeiten die Aufgabe und teilen das Ergebnis ihrem Master-Agenten mit. Dabei können die Slaves unter Umständen miteinander kommunizieren oder auch (falls dies im Design vorgesehen ist) das Problem weiter unterteilen und weiteren Slave-Agenten übergeben. Damit hat der Master-Agent gegenüber seinen Slaves volle Eigenständigkeit und Autorität, während ein SlaveAgent seinem Master gegenüber nur eingeschränkt autonom handeln kann. Eine andere Möglichkeit der Umsetzung dieser Koordinationsform ist die Benutzung der Blackboardarchitektur [HR85]. In diesem Schema werden die Wissensquellen durch Agenten ersetzt, die auf das Blackboard schreibend oder lesend zugreifen. 6 2 Koordination Der Master-Agent regelt die Zugriffe auf das Blackboard. Diese Form kann verwendet werden, wenn das Problem verteilt ist, es einen zentralen Master-Agenten gibt oder wenn die Aufgaben von zu Anfang der Bearbeitung verteilt wurden. Weitere organisierte Strukturen sind zum Beispiel (de-)zentralisierte Marktstrukturen. Die zentralisierte Marktstruktur kann die Master/Slave Konfiguration verwenden, während die dezentralisierte, die im Kapitel 2.2.2 beschriebene Ausschreibung benutzen kann. Für das Master-Slave-Protokoll spricht die starke Kontrolle über die Arbeit der Agenten und den Problemlösungsprozess im Allgemeinen. Der Designer kann zu jeder Zeit nachvollziehen, in welcher Weise sein System eine Aufgabe erledigen wird. Arbeitet das System nicht erwartungsgemäss, stellt es kein Problem dar, herauszufinden an welcher Stelle in der Hierarchie das Problem liegt und welcher Agent nicht wie erwünscht arbeitet. Demgegenüber stehen eine Reihe von Nachteilen. Mit diesem Ansatz werden diverse sich bisher als vorteilhaft erwiesene Prinzipien von Multiagentensystemen nicht beachtet. Eine dezentrale Struktur existiert nicht. An deren Stelle steht die Agenten-Hierarchie, deren Master-Agent an der Spitze einen Überblick über das gesamte darunter liegende System haben muss, um die Aufgabe sinnvoll aufteilen und delegieren zu können. Auch das Prinzip des offenen Systems geht durch die feste Hierarchie verloren, denn das Hinzufügen oder Entfernen einzelner Agenten gestaltet sich durch die damit verbundene Notwendigkeit der Anpassung der hierarchischen Struktur aufwendig. Bei einer Änderung eines Agenten muss immer auch das Gesamtsystem mitverändert werden, was die Master-Slave-Technik unflexibel macht. Auch erweist sich das System als wenig Robust bei Ausfällen. Wird ein Agent funktionsuntüchtig, wird damit auch die gesamte über ihn laufende Kommunikation unterbrochen. Damit sind in der Regel auch weitere in der Hierarchie unter dem ausgefallenen Agenten liegende Agenten nicht mehr nutzbar. Bei der Benutzung von Blackboards stellt das Blackboard an sich einen Flaschenhals dar, wenn viele Agenten im System vorhanden sind. Ähnlich wie beim Kontrakt-Netz-Protokoll (siehe nächstes Kapitel) sind die Wissensquellen im Blackboardsystem einfach auszutauschen, hinzuzufügen oder zu entfernen. Einzige Voraussetzung für die Teilnahme am Problemlösungsprozess ist die Unterstützung der Schnittstelle des Blackboardsystems und das Verständnis der genutzten Sprache. Die gemeinsam genutzte Sprache ist auch gleichzeitig das größte Problem bei Blackboardsystemen. Die Wissensquellen müssen in der Lage sein, die Blackboardinhalte korrekt zu interpretieren. Dies wird durch die universelle Anwendbarkeit des Blackboards erschwert. Agenten, die sehr unterschiedliche Fähigkeiten haben, werden kaum die Informationen des anderen verstehen können. Zumindest sollte ein Teil einer Nachricht (etwa der Problembereich) von allen Agenten verstanden werden, um falsche Interpretationen zu verhindern. 7 2 Koordination 2.2.2 Ausschreibung In der Mitte im Einfluss zwischen Aufgabensteller und Problemlöser auf den Problemlösungsprozess steht das Kontrakt-Netz-Protokoll [DS83][Smi80], das die Form der Ausschreibung implementiert. Die Umgebung ist die eines dezentralen Marktes. Auf den ersten Blick ähnelt es der Master/Slave Architektur, bietet aber eine wesentlich höhere Flexibilität. Zunächst sind, wie schon bei der Master/Slave Architektur, die Agenten in zwei Gruppen eingeteilt. Es existieren Manager (entsprechend den Mastern), die eine Aufgabe in Teilaufgaben aufspalten und nach Agenten suchen, die für sie die Teilaufgaben erledigen. Schließlich verarbeitet der Manager auch die Ergebnisse, die er von den Dienstanbietern zurückerhält. Der Anbieter (entsprechen den Slaves) übernimmt Teilaufgaben vom Manager und führt sie durch. Dabei kann er selbst auch zum Manager werden und seine Aufgabe weiter zerlegen, um sie an andere Agenten zu delegieren. Die Besonderheit gegenüber der organisierten Struktur besteht darin, dass keine zentrale Kontrolle über die Aufgabenausführung existiert und die Verbindungen zwischen Manager und Anbieter nicht vom System fest vorgegeben sind. Vielmehr kann je nach Aufgabe jeder Agent zum Manager werden und in Verbindung mit beliebigen anderen Agenten treten, die dann spontan die Rolle des Anbieters übernehmen. Auch hat der Manager die Möglichkeit, nach einem weiteren Anbieter zu suchen, falls ein Anbieter nicht in der Lage ist, eine zufriedenstellende Lösung zu liefern. Dieses Protokoll (Contract Net Protocol,CNP) ist ein weit verbreitetes Interaktionsprotokoll zur kooperativen Problemlösung in Multiagentensystemen. Eine Ausschreibung enthält: • Adressaten • Eignungsspezifikation • abstrakte Aufgabenbeschreibung • Angebotsspezifikation • Gültigkeitsdauer Ein Gebot besteht aus einer kurzen Spezifikation der Fähigkeiten des bietenden Agenten, die relevant für die Aufgabenausführung sind. In der Regel spezifiziert das Gebot auch die Kosten oder den Preis, den der Bieter für die Ausführung der Aufgabe verlangt. Das Ausbleiben von Angeboten kann verschiedene Gründe haben, es könnten alle potentiellen Auftragnehmer ausgelastet sein, die aktuelle Ausschreibung wird mit geringer Priorität versehen oder es verfügt keiner der potentiellen Auftragnehmer über die notwendigen Fähigkeiten oder Ressourcen, um die Anforderung unverzüglich zu beantworten. Ein Vertrag besteht aus einer Aufgabenbeschreibung, die die vom Bieter zu erbringende Aufgabe vollständig beschreibt und einer beiderseitige Einwilligungserklärung 8 2 Koordination mit Spezifikation der Randbedingungen wie beispielsweise mögliche Konventionalstrafen im Falle einer Nichterfüllung des Vertrags. Das CNP ist dann geeignet, wenn: • Die Applikation durch eine wohldefinierte Hierarchie von Aufgaben beschrieben werden kann • Die Applikation relativ grobkörnig in Teilprobleme zergliedert werden kann • Die einzelnen Teilaufgaben weitgehend losgelöst voneinander sind, d.h. keine Abhängigkeiten bestehen Der entscheidende Vorteil des Kontrakt-Netz-Protokolls ist, dass es dezentral aufgebaut und selbstorganisierend ist. Damit werden praktisch alle Nachteile der Master/Slave Architektur ausgeräumt. Es kann im Prinzip jeder beliebige Agent im System mit einer Aufgabe betraut werden, die er notfalls unverändert an einen passenden Agenten weiterreicht. Des weiteren sind Agenten bequem ohne Änderung am Aufbau des Gesamtsystems hinzufügbar und entfernbar. Sofern sie das KontraktNetz-Protokoll unterstützen, müssen sie lediglich in die Liste der vorhandenen Agenten eingetragen werden, und können sofort Aufgaben übernehmen, indem sie auf Ausschreibungen reagieren oder selbst Aufgaben zur Bearbeitung ausschreiben. Die fehlende Notwendigkeit, auf Ausschreibungen zu reagieren, hat aber auch u.A. folgenden Nachteil. Existieren zwei mögliche Anbieter zum Bearbeiten einer Aufgabe, die aber unterschiedlich gut dafür geeignet sind, kann es leicht sein, dass die Aufgabe dem schlechteren Agenten zugeordnet wird, wenn der bessere Agent zum Zeitpunkt der Ausschreibung beschäftigt war. Dies erweist sich dann als nachteilig, wenn der bessere Agent unmittelbar nach der Zuteilung wieder verfügbar ist, und die Aufgabe somit in insgesamt kürzerer Zeit hätte erledigt werden können. Der große Aufwand bei der Suche nach passenden Agenten bringt einen hohen Nachrichtenverkehr mit sich, den das System bewältigen muss. Wenn die Zuständigkeiten der einzelnen Agenten klar sind und keine großen Änderungen am System zu erwarten sind, ist es daher wohl sinnvoller, auf eine organisierte Struktur zurückzugreifen. Das Kontrakt-Netz-Protokoll wird sinnvoll, wenn die Agenten vielseitig in ihren Fähigkeiten sind und nicht mehr von vornherein klar ist, welcher Agent eine Aufgabe zu bearbeiten hat. Außerdem sollte die Aufgabe leicht unterteilbar sein, die Teilaufgaben aber noch groß genug, damit sich der Kommunikationsaufwand lohnt. Die Annahmen, die das Kontrakt-Netz-Protokoll macht, sind zum Teil unrealistisch. Die Agenten sind nicht immer passiv und wohlwollend. Das antagonistische Verhalten von Agenten wird eher von der Koordinationstechnik der Verhandlung (Kapitel 2.3) berücksichtigt. 2.2.3 Planung Ein weiterer Ansatz zur Koordination in Multiagentensystemen ist die Agenten Pläne erstellen zu lassen. Um Inkonsistenzen oder Konflikte zu vermeiden, bauen 9 2 Koordination die Agenten Pläne, die alle ihre zukünftigen Aktionen auflisten, die sie ausführen wollen, um ihre Ziele zu erreichen. Die Ausführung ihrer Aktionen verzahnen sie mit weiterer Planung und Anpassung der Pläne. Grundsätzlich gibt es zwei Arten von Planung, die zentrale und die verteilte Planung. 2.2.3.1 Zentrale Planung Es gibt hierbei normalerweise einen koordinierenden Agenten, der, nachdem er alle lokalen Pläne von allen Agenten erhalten hat, diese analysiert, um Inkonsistenzen und Konflikte (z.B. gleichzeitiger Zugriff auf eine Ressource) zu identifizieren. Er versucht, diese Teilpläne so zu modifizieren, dass der daraus resultierende Gesamtplan keine Konflikte und Inkonsistenzen mehr hat. In [CMS83] wird ein Beispiel einer Konfliktsituation beschrieben, in dem sich Flugzeuge auf Kollisionskurs befinden und durch gemeinsame Planung eine Kollision vermeiden. Der koordinierende Agent wird dabei zur Laufzeit bestimmt. 2.2.3.2 Verteilte Planung In der verteilten Planung ist die Idee, jedem Agenten ein Modell über die Pläne anderer Agenten zu geben [Cor79]. Agenten kommunizieren dann, um ihre eigenen Pläne aufzubauen und zu aktualisieren. Die Modelle der Pläne werden entsprechend angepasst bis keine Konflikte mehr vorhanden sind. Ein Beispiel für verteilte Planung ist in [DL87]. Die Agenten tauschen ihre Pläne aus, die ständig aktualisiert werden anhand eines globalen Teilplanes, der wiederum aus den lokalen Plänen gebaut ist. Deswegen sind die Agenten immer auf der Suche nach möglichen Verbesserungen der Gruppenkoordination. 2.2.3.3 Vorteile und Nachteile von Planung Generell verlangt die Planung sehr hohen Kommunikationsaufwand, da die Agenten grosse Mengen an Informationen austauschen müssen. Die zentralisierte Planung teilt viele Nachteile mit der Master/Slave Architektur. In der verteilten Planung kann es allerdings sein, dass kein Agent eine globale Sicht auf das verteilte System hat. 2.3 Verhandlung Es gibt sehr viele Definitionen für den Begriff Verhandlung, eine einfache ist die von [BM92]: ’Verhandlung ist der Kommunikationsprozess einer Gruppe von Agenten, um eine einvernehmliche Vereinbarung über eine Sache zu erzielen.’ Weiterhin ist Sycara [Syc89] der Ansicht, dass Agenten, um effektiv verhandeln zu können, über die BDIs (Belief Desire Intention) der anderen Agenten nachdenken können müssen. Das hat die Entwicklung von Modellen über Annahmen (belief) in Agenten, von Folgerungen über die Modelle über Annahmen anderer Agenten und 10 2 Koordination schliesslich von Methoden, wie man diese Annahmen anderer Agenten, beeinflusst. Es gibt sehr viele verschiedene Ansätze zur Verhandlung. Auf die folgenden geht dieses Kapitel ein: • Spieltheorie • Planbasiert • Mensch als Vorbild 2.3.1 Spieltheorie Mit Hilfe der Werkzeuge der Spieltheorie erstellt [RZ94] ein Koordinationsschema, das ohne einen Koordinationsmechanismus, der in die Agenten von vorne herein eingebaut wäre, funktioniert. Es geht also nicht von der Annahme aus, das die Agenten wohlwollend sind. Die wichtigsten Konzepte in diesem Ansatz sind die Nutzenfunktion, der Deal, das Verhandlungsprotokoll und die Verhandlungsstrategie. Der Nutzen ist definiert als die Differenz zwischen dem Wert des Erreichens eines Zieles und den Kosten für das Erreichen dieses Zieles. Ein Deal ist jede Aktion mit einem Nutzen. Das Verhandlungsprotokoll definiert die Regeln, die die Verhandlung leiten, zum Beispiel die Frage, wie und wann die Verhandlung beendet wird (mit einer Vereinbarung oder nicht). Die tatsächliche Verhandlung findet wie folgt statt. Die Nutzenwerte für jedes mögliche Ergebnis einer Interaktion werden für jeden Agenten in eine Matrix eingetragen, die den Agenten bekannt ist. Die Verhandlung ist eine Abfolge von Angeboten und Gegenangeboten in denen jeder Agent seinen erwarteten Nutzenwert maximiert. Eine implizite Annahme über die Agenten wird gemacht, dass jeder Agent seinen eigenen Nutzenwert auch tatsächlich maximieren will, was in einem Team zum Beispiel nicht der Fall sein muss. In jedem Schritt der Verhandlung wird dann jedes mal ein neues Angebot gemacht, in Bezug nehmend auf die Verhandlungsstrategie. Rosenschein und Zlotkin [ZR90] haben gezeigt, dass Agenten, die nicht wahrheitsgemäss die Matrix ausfüllen, zum Teil bessere Deals abschliessen. Der spieltheoretische Verhandlungsansatz ist teilweise nicht realistisch. Zusätzlich zu der erwähnten Annahme über die Agenten als Nutzenwertmaximierer, ist auch nicht immer die vollständige Matrix bekannt. Zudem kann die Matrix für sehr viele Agenten und viele mögliche Ausgänge einer Verhandlung sehr gross und nicht mehr praktikabel werden. Die Agenten haben auch kein Gedächtnis, sie nehmen immer nur die aktuelle Matrix als Grundlage. Die bisherigen Ergebnisse in der Spieltheorie haben nur zwei Agenten als Verhandlungspartner betrachtet, eine Ausnahme ist in [ZR93] zu finden. Zusammenfassend kann man sagen, dass der spieltheoretische Ansatz zu viele Nachteile hat, um eingesetzt zu werden. 11 2 Koordination 2.3.2 Planbasierte Verhandlung Alder et al. untersuchten verhandelte Übereinkünfte und diskutieren Methoden der Konfliktaufdeckung und Konfliktlösung im Bereich des Telofonnetzwerkverkehrs [ADWF89]. Sie versehen ihre Agenten mit Wissen über Planung, da sie die Meinung vertreten, dass Verhandlung und Planung sehr eng miteinander verflochten sind, dadurch dass Agenten Information von anderen Agenten brauchen um effektiv und effizient zu arbeiten. Kreifelt und von Martial schlagen eine Verhandlungsstrategie für autonome Agenten vor [KvM91]; sie betrachten Verhandlung als 2 Phasen Prozess: als erstes planen die Agenten ihre Aktionen separat, um sie dann zu koordinieren. Die Koordination aller Agenten geschieht durch einen Koordinationsagenten. Sie präsentieren dann ein Verhandlungsprotokoll, das aber nicht vollständig definiert ist. Die Methode hat auch die gleichen Nachteile wie die zentrale Planung. 2.3.3 Menschenorientierte Verhandlung Es scheint, dass fast jede Form von menschlicher Interaktion zu einem bestimmten Grad explicite oder implizite Verhandlung beinhaltet. Daher ist es nicht überraschend, dass viele Verhandlungsstrategien auf menschlichen Vorgehensweisen basieren. Bussmann und Mullers [BM92] entwickeln ein zyklisches Verhandlungsmodell indem sie sich an soziopsychologischen Verhandlungstheorien orientieren. Sie versuchen die Einschränkungen anderer Verhandlungsstrategien anzugehen. Das Problem der Konfliktauflösung wird durch die zyklische Eigenschaft des Modells behandelt. Die Strategie ist, dass die Verhandlung damit beginnt, dass jeder Agent ein oder mehr Angebote macht. Die Agenten bewerten und vergleichen die Angebote mit ihren eigenen Präferenzen und kritisieren sie, indem sie die verletzen Präferenzen auflisten. Jeder Agent aktualisiert sein Wissen mit den Präferenzen der anderen Agenten und darauf basierend werden neue Angebote gemacht. Die Arbeit von Sycara [Syc89] nutzt CBR (case-based reasoning). Sie begründet das damit, dass menschliche Verhandlungsführer ihre weiteren Entscheidungen auf bisher gemachten Erfahrungen in Verhandlungen basieren. Weiterhin sollen Agenten andere Agenten überzeugen können, indem sie deren Annahmen (belief), Verhalten (behaviour) und Vorhaben (intention) modifizieren. Ihrer Meinung nach ist diese Fähigkeit notwendig um kooperative Interaktion zu schaffen. Werkman schlägt ein Modell [Wer90] vor, das die Verhalten von kooperierenden oder konkurrierenden Experten simulieren soll, die einen gemeinsamen Wissenshintergrund besitzen. Es nutzt die Blackboardarchitektur auf der Vorschläge gesammelt werden, die angefordert, abgelehnt oder angenommen wurden. Weiterhin ist wird im Blackboard das gemeinsame Wissen und die Kommunikation verwaltet. Das ermöglicht den Agenten dieses Wissen zu nutzen und es in ihre Entscheidungen einfliessen zu lassen. Werkman teilt die Verhandlung in drei Phasen auf. In Phase eins wird das 12 2 Koordination Angebot gemacht. Phase zwei enthält die Gegenangebote oder ggf. die Annahme des in Phase eins gemachten Angebots. In Phase drei wird ein Review von anderen Agenten gemacht. Entsteht ein Deadlock kommt ein Arbitrator Agent dazu, der die endgültige Entscheidung fällt. 13 3 Teambildung Ein Team1 von Agenten hat den Vorteil des Teamworks. In einem Team können Agenten zusammen Ziele verfolgen, sich aufeinander verlassen und besser interagieren. Ein Wolfsrudel ist ein Beispiel für Teamwork in der Natur, Schwärme von Zugvögeln ein anderes. In beiden Fällen profitieren die Agenten davon, einem Team anzugehören. Doch wie entstehen Teams in Multiagentensystemen? Es wird in den einzelnen Methoden davon ausgegangen, dass es Ziel gibt, an dessen Erreichung die einzelnen Agenten interessiert sind. In [HG00] wird vorgeschlagen eine kombinatorische Auktion als Selektor für Teammitglieder zu benutzen. Jeder Agent gibt anhand der Kosten für die Teilnahme im Team ein Gebot ab. Diese Kosten setzen sich zusammen aus den einzelnen Kosten der fraglichen Aufgabe, aus der Bewertung des Nutzens der Zeit, das heisst, es wird die Frage gestellt, ob andere Aufgaben in der Zeit zu lösen wären. Weiterhin muss der Agent feststellen, ob die Aufgabe für ihn erfüllbar ist (zeitliche Bedingungen). Eine zentrale Instanz entscheidet dann, welche Gebote genommen werden, indem sie die beste Kombination der Gebote berechnet. Von da an gehören die ausgewählten Agenten einem Team an. Tidhar et al. [TRLK92] verfolgen einen anderen Ansatz. Sie nutzen einen Teamplan, der das Ergebnis der Überschneidung aller Pläne aller teilnehmenden Agenten ist. Jeder Agent besitzt demnach eine Menge von Skills, das sind atomare Aktionen, die der Agent ausführen kann. Der Teamleader besitzt das ganze Wissen über alle Pläne der Agenten und erstellt daraus den Teamplan. Mittels eines Broadcasts fragt der Teamleader alle Agenten, ob sie die Skills zusichern oder ob sie anderweitig beschäftigt sind. Sobald der Teamleader alle notwendigen Skills für den Teamplan zusammen gesammelt hat, sind alle Agenten, die eine Zusicherung gemacht haben, in einem Team. Eine andere Betrachtung der Teams definiert Levesque et al. [LCN90] Agenten sind nicht in Teams, wie definiert, sondern in Gruppen (auch lose Teams genannt) organisiert. Die Agenten sind BDI (Belief Desire Intention) Agenten. Die Gruppen finden sich über gemeinsame Interessen oder Vorhaben (joint intentions). Eine Gruppe entsteht zwischen Agenten, sobald Agenten das Bedürfnis (desire) haben, eigene Ziele (intentions) anderen Agenten mitzuteilen. Dieser Ansatz hat den Vorteil, dass es keine zentrale Instanz geben muss, die die Teambildung beaufsichtigt, Gruppen entstehen von sich aus. 1 Eine Gruppe von Agenten nennt man Team, wenn es keine Interessenkonflikte zwischen den Agenten gibt (z.B. was das allgemeine Ziel angeht) 14 4 Fazit Diese Ausarbeitung hat eine Übersicht über verschiedene Koordinationstechniken und Möglichkeiten der Teambildung in Multiagentensystemen gezeigt. Erfolgreiche Koordination ist ein wichtiges Designziel für Entwickler von Multiagentensystemen. Ohne gute Koordinationsmechanismen und Teambildung werden viele Vorteile von MAS nicht ausgenutzt. Viele der betrachteten Vorgehensweisen waren in einmaligen Projekten umgesetzt worden, so dass keine soliden Folgerungen getroffen werden können. Die Implementationen sparen sich auch darüber aus, welche Strategien nun tatsächlich verwendet wurden. Die Ausschreibung und die Master/Slave Architektur sind die am meisten verbreiteten Strategien, da sie einfach zu realisieren sind. Viele der vorgestellten Techniken machen starke Annahmen über die Agenten, so dass sie nur begrenzt einsetzbar sind. Die meisten Koordinationstechniken lassen Domänenwissen ausser Acht, wie zum Beispiel die Zeit und die Veränderung der BDIs der Agenten über die Zeit. Wie diskutiert worden ist, haben die verschiedenen Ansätze Vorteile und Nachteile je nach Einsatzgebiet. Zu diesem Zeitpunkt existiert noch keine universell einsetzbare Methode, die auf alle Fälle beste Ergebnisse liefern würde. Die theoretischen Herangehensweisen funktionieren gut für eingeschränkten Umgebungen aber viele dieser Einschränkungen lassen sich nicht auf die reale Welt übertragen. Sehr anwendungsbezogenen Arbeiten fehlt es andererseits an theoretischen Grundlagen und Auswertungen. Nach [NLJ94] gibt es vier essentielle Komponenten, die jede Koordinationstechnik umsetzen muss. Erstens muss es Strukturen geben, die es den Agenten ermöglichen in einer voraussagbaren Weise zu interagieren. Weiterhin muss es die Flexibilität geben, so dass Agenten in dynamischen Umgebungen handeln können und mit der ihnen inhärenten unpräzisen Sicht auf die Welt umgehen können. Drittens muss es soziale Strukturen geben, die beschreiben, wie sich Agenten zueinander verhalten sollten, wenn sie sich in einem Koordinationsprozess befinden. Schliesslich müssen die Agenten genug Wissen und die Fähigkeit zu Schlussfolgerungen haben, um die zur Verfügung stehenden Strukturen, sowohl individuelle als auch soziale, und diese Flexibilität zu nutzen. In Zukunft sollten nach [NLJ94] mehr theoretische Arbeiten gemacht werden, die diese vier Komponenten erforschen, um universellere Koordinationstechniken zu schaffen. Aus den hier vorgestellten Techniken für Koordination ist für unsere Projektgruppe die verteilte Koordination sehr geeignet. Es gibt keine zentrale Instanz, bzw. diese müsste in der Engine selbst enthalten sein, was unser System sehr an sie bin- 15 4 Fazit den würde. Die Techniken der Teambildung sind für unser Projekt ein zu grosser Aufwand, da einerseits in der Modifikation Bauen eine Rollenverteilung wie bei der Ausschreibung einfacher ist und andererseits in der Modifikation des CTF Spiels die Teams vorgegeben sind. 16 Literaturverzeichnis [ADWF89] M.R. Alder, A.B. Davis, R. Weihmayer, and R.W. Forest. Conflictresolution strategies for non-hierarchical distributed agents. Morgan Kaufmann, 1989. [BM92] S. Bussmann and J. Muller. A negotiation framework for cooperating agents. In S. M. Deen, editor, Proc. CKBS-SIG, pages 1–17. University of Keele, 1992. [CMS83] S. Cammarata, D. McArthur, and R. Steeb. Strategies of cooperation in distributed problem solving. Proc. of the Eighth Int. Joint Conf. on Artificial Intell., pages 767–770, 1983. [Cor79] D.D. Corkill. Hierarchical planning in a distributed environment. Proc. 6th Int. Joint Conf. Artificial Intell., pages 168–179, August 1979. [DL87] E.H. Durfee and V.R. Lesser. Using partial global plans to coordinate distributed problem solvers. Proc. of the 1987 Int. Joint Conf. on Artificial Intell., pages 875–883, 1987. [DS83] R. Davis and R. G. Smith. Negotiation as a metaphor for distributed problem solving. Artificial Intelligence 20, pages 63–109, 1983. [HG00] L. Hunsberger and B. Grosz. A combinatorial auction for collaborative planning. In Proc. of ICMAS-2000, 2000. [HR85] B. Hayes-Roth. A blackboard architecture for control. Artificial Intelligence 26, pages 251–321, 1985. [HS94] M. Huhns and M. P. Singh. Ckbs-94 tutorial: Distributed artificial intelligence for information systems. Master’s thesis, University of Keele, England., 1994. [KvM91] T. Kreifelt and F. von Martial. A negotiation framework for autonomous agents. In Y. Demazeau and J. P. Muller, editors, Decentralized A. I. 2. Elsevier Science, 1991. [LCN90] H.J. Levesque, P.R. Cohen, and J.H.T. Nunes. On acting together. In Proc. of the Eighth National Conference on Artificial Intelligence (AAAI-90), pages 94–99, 1990. 17 Literaturverzeichnis [Mal87] T.W. Malone. Modeling coordination in organizations and markets. Management Science, 33(10), pages 1317–1332, 1987. [NLJ94] H. Nwana, L. Lee, and N. Jennings. Coordination in software agent systems. Part of Fellowship at BT Labs., 1994. [RZ94] J.S. Rosenschein and G. Zlotkin. Rules of Encounter: Designing Conventions for Automated Negotiation among Computers. MIT Press, 1994. [Smi80] R. G. Smith. The contract net protocol: High-level communication and control in a distributed problem solver. IEEE Trans. on Comput. 29(12), December 1980. [Syc89] K. Sycara. Multi-agent compromise via negotiation. In Distributed Artificial Intelligence 2. Morgan Kaufmann, 1989. [TRLK92] G. Tidhar, A. Rao, M. Ljungberg, and D. Kinny. Skills and capabilities in realtime team formation. Technical report, Australian A.I. Institute, 1992. [Wei00] G. Weiss. Multiagent Systems: A Modern Approach to Distributed Artificial Intelligence. MIT Press, 2000. [Wer90] K.J. Werkman. Knowledge-based model of negotiation using shareable perspectives. In Proc. of the 10th Int. Workshop on DAI, 1990. [ZR90] G. Zlotkin and J.S. Rosenschein. Blocks, lies, and postal freight: The nature of deception in behaviour. Proc. of the 10th Int. Workshop of DAI, October 1990. [ZR93] G. Zlotkin and J.S. Rosenschein. One, two, many: Coalitions in multiagent systems. Proc. of the 5th European Workshop on Modelling Autonomous Agents in Multi-Agent World, August 1993. 18