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