Autor: **** Yan Kexi, Jing Yuheng, Liu Zhihao, Feng Xiaokun, Lei Shiqi-** Institut für Automatisierung, Chinesische Akademie der Wissenschaften
Zusammenfassung
Für dieses Reinforcement-Learning-Experiment hat unser Team das Thema „Neue Umgebung/Neuer Algorithmus für MindSpore-Zugriff auf Reinforcement-Learning“ gewählt. Wir haben eine Spieltestumgebung für Multi-Agenten-Kooperationsszenarien – SISL (Stanford Intelligent Systems Laboratory) – mit der MindSpore-Plattform verbunden und den Leistungsbenchmarktest der QMIX- und MAPPO-Algorithmen in dieser experimentellen Umgebung implementiert. In diesem Austausch werden wir eine entsprechende Einführung und Analyse rund um die fünf Aspekte Themenauswahl, Umgebung, Algorithmus, experimentelle Ergebnisse und Schlussfolgerungen durchführen.
Die projektbezogenen Codes finden Sie im Anhang.
https://gitee.com/lemonifolds/reinforcement/tree/c03e5f8e6104b5880fdfa53d579332078c7dfb99
01
Themeneinführung
Reinforcement Learning ist eine Disziplin, die die Entscheidungsfindung in der Reihenfolge untersucht. Sie erlernt Optimierungsstrategien zur Maximierung der kumulativen Erträge durch die Analyse des Interaktionsprozesses zwischen einem Agenten und der Umgebung. Unter diesen ist die Umgebung ein wichtiges Element beim Verstärkungslernen. Sie bestimmt nicht nur direkt das Eingabedatenformat des Algorithmusmodells, sondern steht auch in engem Zusammenhang mit den Forschungsaufgaben des Verstärkungslernens. Einige klassische Reinforcement-Learning-Algorithmen werden oft von einigen klassischen Verifizierungsumgebungen begleitet. Für Einzelagenten-Wahrnehmungs- und Entscheidungsaufgaben wurde beispielsweise sein klassischer Algorithmus DQN (Deep Q-Learning) [1] im Atari-Spiel verifiziert, einer klassischen Umgebung für diese Aufgabe für vollständige Informations-Nullsummenspielaufgaben. und unvollständige Informationen Mehrspieleraufgaben Für gemischte Spielaufgaben benannten seine repräsentativen Werke AlphaGo[2][3] und AlphaStar[4] den Algorithmus sogar nach der entsprechenden Verifizierungsumgebung (Go, StarCraft). Dies zeigt die wichtige Rolle der Verifizierungsumgebung im Bereich des verstärkenden Lernens.
Es gibt viele Arten von Umgebungen, die beim Reinforcement Learning verwendet werden. Typische Umgebungen sind Gym[5], MuJoCo[6], MPE[7], Atari[1], PySC2[8], SMAC[9], TORCS, ISAAC usw. Derzeit ist die StarCraft MindSpore-Architektur mit zwei Umgebungen verbunden: Gym und SMAC (StarCraft Multi-Agent Challenge), die jeweils auf Szenarios für Single-Agent Reinforcement Learning und Multi-Agent Reinforcement Learning ausgerichtet sind. Für letztere ist es aufgrund des komplexen und hochdimensionalen Zustands-, Aktions- und Entscheidungsraums des StarCraft-Spiels zu einem wichtigen herausfordernden Maßstab für Multi-Agent-Lernalgorithmen zur Verstärkung geworden. Wenn wir jedoch in der tatsächlichen wissenschaftlichen Forschungspraxis einen neuen Algorithmus vorschlagen, überprüfen wir ihn häufig zuerst in einigen kleinen Umgebungen (z. B. der Atari-Spielumgebung in Gym). Auf dieser Grundlage wählte unser Team eine kleine Testumgebung für Multi-Agenten-Szenarien – SISL (Stanford Intelligent Systems Laboratory) – und verband sie mit der MindSpore-Plattform, um der Plattform eine vielfältigere Zertifizierungsumgebung für Multi-Intelligence-Erlebnisse bereitzustellen. Darüber hinaus haben wir zwei typische Multi-Agent-Lernalgorithmen zur Verstärkung, MAPPO [10] und QMIX [11], für die SISL-Umgebung implementiert und entsprechende Benchmark-Testergebnisse bereitgestellt.
Als nächstes gibt dieser Austausch zunächst eine vorläufige Einführung in die verbundene SISL-Umgebung (Kapitel 2) sowie die verwendeten QMIX- und MAPPO-Algorithmen (Kapitel 3) und dann den Implementierungsprozess für den Zugriff auf die Umgebung und die erhaltenen Benchmark-Testergebnisse und die im Experiment aufgetretenen Probleme werden dargestellt und analysiert (Kapitel 4). Basierend auf den experimentellen Ergebnissen ziehen wir schließlich entsprechende Schlussfolgerungen (Kapitel 5).
02
Einführung in die Umwelt
PettingZoo[12] ist eine Python-Bibliothek, die häufig in der Multiagenten-Lernforschung verwendet wird. SISL (Stanford Intelligent Systems Laboratory) ist eines der Umgebungspakete, einschließlich drei Unterumgebungen: Multiwalker, Pursuit und Waterworld.
Die grundlegende Verwendung von PettingZoo ähnelt der von Gym. Das Folgende ist ein Codebeispiel für den Aufbau eines zufällig agierenden Agenten in der Waterworld-Umgebung:
from pettingzoo.sisl import waterworld_v4
env = waterworld_v4.env(render_mode='human')
env.reset()
for agent in env.agent_iter():
observation, reward, termination, truncation, info = env.last()
if termination or truncation:
action = None
else:
action = env.action_space(agent).sample()
env.step(action)
env.close()
Im Folgenden finden Sie eine Einführung in die drei Unterumgebungen in SISL.
2.1Multiwalker
In der Multiwalker-Umgebung versuchen zweibeinige Roboter, ihre Last zu tragen und nach rechts zu gehen. Mehrere Roboter transportieren eine große Ladung und müssen zusammenarbeiten, wie im Bild unten gezeigt.
Multiwalker-Umgebungsdiagramm
Jeder Agent erhält die Rendite des „forward_reward“ multipliziert mit der Positionsänderung des Pakets im Vergleich zum vorherigen Zeitpunkt. Wenn mindestens eines der Pakete herunterfällt oder das Paket die linke Grenze des Geländes überschreitet, endet die Umgebung und jeder Agent erhält -100 Vorteile. Fällt das Paket vom rechten Rand des Geländes, endet auch die Umgebung mit einem Gewinn von 0.
Fällt ein Agent, erhält er zusätzlich einen Vorteil von -10. Wenn „terminate_on_fall“ = False ist, wird die Umgebung nicht beendet, wenn der Agent ausfällt. Andernfalls wird die Umgebung beendet, sobald der Agent ausfällt, und bringt einen Vorteil von -100. Wenn „remove_on_fall“ = „True“, wird der abgestürzte Agent aus der Umgebung entfernt. Jeder Agent erhält außerdem eine -5-fache Änderung des Kopfwinkels, um den Kopf gerade zu halten. Wenn shared_reward = True, wird die persönliche Belohnung jedes Agenten gemittelt und an jeden Agenten zurückgegeben.
Jeder Agent übt Kraft auf die beiden Gelenke seiner beiden Beine aus, sodass sein kontinuierlicher Aktionsraum ein vierdimensionaler Vektor ist. Der Beobachtungsraum jedes Agenten ist ein 31-dimensionaler Vektor, der verrauschte Radardaten über die Umgebung und die umgebenden Agenten, die Winkel und Geschwindigkeiten jedes Gelenks seines eigenen Körpers und andere Informationen enthält.
2.2 Verfolgung
In der Verfolgungsumgebung versuchen einige Verfolgungsagenten, die Flüchtenden zu verfolgen und zu umzingeln, wie in der Abbildung unten dargestellt (Rot ist der kontrollierte Verfolgungsagent, Blau ist die zufällige Bewegung der Flüchtlinge).
Diagramm der Verfolgungsumgebung
Standardmäßig gibt es 30 Flüchtige und 8 Verfolger in einem 16x16-Raster, und in der Mitte der Karte befindet sich ein Hindernis (weißer Teil). Wenn ein Agent einen Entkommenden vollständig umgibt, erhält jeder umgebende Agent einen Vorteil von 5 und der Entkommende wird aus der Umgebung entfernt. Jedes Mal, wenn der Agent einen Flüchtigen berührt, erhält er außerdem einen Vorteil von 0,01.
Jeder Agent verfügt über einen diskreten Aktionsbereich: hoch, runter, links, rechts, Stopp. Der Beobachtungsraum jedes Agenten ist ein 7x7-Gitter um ihn herum, das in der Abbildung durch Orange dargestellt wird.
2.3 Wasserwelt
Die Waterworld-Umgebung simuliert die Bedingungen, unter denen Archaeen versuchen, in der Umwelt zu überleben. Jeder Agent muss versuchen, Nahrung zu sich zu nehmen und Giftstoffe zu vermeiden, wie im Bild unten gezeigt.
Waterworld-Umgebungsdiagramm
Abhängig von den Eingabeparametern müssen die Agenten möglicherweise zusammenarbeiten, um Lebensmittel zu konsumieren, sodass das Modell gleichzeitig kooperativ und wettbewerbsfähig sein kann. Ebenso können die Vorteile für jeden Agenten unterschiedlich oder gemittelt sein. Die gesamte Umgebung ist ein kontinuierlicher zweidimensionaler Raum, und die Vorteile basieren auf der Einwirkung von Nahrungsmitteln und Giftstoffen.
Der Aktionsraum jedes Agenten ist ein zweidimensionaler Vektor, dh der Fortschritt (Beschleunigung) in horizontaler und vertikaler Richtung. Der Beobachtungsraum jedes Wirkstoffs besteht aus den von jedem Sensor empfangenen Informationen über den Abstand zu Nahrungsmitteln, Toxinen und anderen Wirkstoffen und darüber, ob er mit Nahrungsmitteln oder Toxinen kollidiert. Die Gesamtdimension beträgt oder
, abhängig von den Parametern.
03
Einführung in den Algorithmus
In diesem Abschnitt stellen wir den im Experiment verwendeten MAPPO[10]-Algorithmus und QMIX[11]-Algorithmus vor.
3.1 MAPPO-Algorithmus
Der vollständige Name von MAPPO lautet Multi-Agent Proximal Policy Optimization. Wie aus dem Namen hervorgeht, handelt es sich beim MAPPO-Algorithmus um einen klassischen Reinforcement-Learning-Algorithmus – den PPO-Algorithmus [13], der in einer Multi-Intelligence-Umgebung erweitert wird. Für Umgebungen mit mehreren Agenten werden sie oft mit < > Sieben-Tupeln beschrieben. Unter diesen stellt n die Anzahl der Agenten dar
; Die
vollständig beobachtbare Umgebung stellt dann
die
Wahrscheinlichkeit dar, bei einer gemeinsamen Aktion von s zu s zu wechseln.
Der MAPPO-Algorithmus verwendet die klassische Akteur-Kritiker-Struktur, die das Training zweier separater neuronaler Netze erfordert: das Richtliniennetzwerk und die Wertefunktion
(als Akteur bzw. Kritiker).
Für das Richtliniennetzwerk wird es verwendet, um eine Zuordnung von der Beobachtung o_i zur Aktionsverteilung a_i zu lernen, und das entsprechende Optimierungsziel lautet:
Unter diesen stellt B die Größe der Chargengröße dar, die mit der GAE-Methode [14] berechnet wird,
die Richtlinienentropie darstellt und
den Hyperparameter des Gewichtskoeffizienten darstellt.
Für die Wertfunktion , die zum Erlernen der Zuordnung vom Zustand S zur Belohnungsschätzung verwendet wird
, lautet das entsprechende Optimierungsziel:
wobei es sich um die berechnete diskontierte Rendite handelt. Da MAPPO eine zentralisierte Trainings- und verteilte Ausführungstrainingsmethode anwendet, kann die Wertfunktion den globalen Status direkt aufteilen , während die Richtlinienfunktion nur
die lokalen Beobachtungsinformationen jedes Agenten
verarbeiten kann.
Basierend auf der obigen Optimierungszielformel kann der Verarbeitungsprozess des zyklischen MAPPO-Algorithmus im Originalartikel [10] wie folgt organisiert werden:
3.1 MAPPO-Algorithmus
In diesem Abschnitt wird u zur Bezeichnung von Aktionen und u zur Bezeichnung des Aktions-/Beobachtungsverlaufs verwendet. Die Designidee des QMIX-Algorithmus ähnelt der von VDN. Es besteht die Hoffnung, dass
jeder einzelne durch Berechnung eines globalen Algorithmus erhalten werden kann
. muss nur
Damit wird die Anforderung erfüllt. Damit die obige Formel gilt, sollte Monotonie in Bezug auf Q_i vorliegen
Die neuronale Netzwerkstruktur von QMIX ist in der folgenden Abbildung dargestellt: QMIX-Framework-Diagramm
Für jeden Agenten i gibt es ein Agentennetzwerk, mit dem er berechnet wird , wie in Abbildung (c) dargestellt. Dieses Netzwerk ist ein DRQN-Netzwerk, das heißt, die vollständig verbundene Schicht in DQN wird durch GRU ersetzt, und die Eingabe ist die Beobachtung des Agenten zum Zeitpunkt t
und die Aktion zum Zeitpunkt t-1
.
Das Hybridnetzwerk ist ein vorwärtsgerichtetes neuronales Netzwerk, das n Ausgaben vom Agentennetzwerk empfängt und diese monoton mischt. Die Ausgabe ist das Ergebnis, wie in Abbildung (a) dargestellt. Die Gewichte des Hybridnetzwerks werden von einem separaten Supernetzwerk generiert. Das Supernetzwerk verwendet den globalen Zustand s_t als Eingabe und generiert die Gewichte einer Schicht des Hybridnetzwerks. Jedes Supernetzwerk besteht aus einer einzelnen linearen Schicht mit einer Absolutwert-Aktivierungsfunktion, um sicherzustellen, dass die Gewichte des Hybridnetzwerks nicht negativ sind.
Das QMIX-Netzwerk wird durchgängig trainiert, um die folgenden Verluste zu minimieren:
Darunter sind
die Parameter des Zielnetzwerks (ähnlich wie bei DQN).
04
Experimentelle Ergebnisse
In diesem Abschnitt werden spezifische experimentelle Analysen basierend auf der obigen Einführung in die SISL-Umgebung und die MAPPO- und QMIX-Algorithmen durchgeführt. Zuerst stellen wir den Zugriffsprozess der SISL-Umgebung vor (Abschnitt 4.1); dann versuchen wir, sie basierend auf den im ursprünglichen MindSporeRL-Warehouse bereitgestellten MAPPO- und QMIX-Algorithmen nach Modifikation und Anpassung in der neu aufgerufenen Umgebung anzuwenden Nachdem das Testexperiment (Abschnitte 4.2 und 4.3) in der SISL-Umgebung abgeschlossen ist, werden wir die entsprechenden technischen Verbesserungspunkte, experimentellen Ergebnisse und Gedanken vorstellen und vorstellen.
4.1 Zugriffsprozess auf die SISL-Umgebung
Wir verwenden den Befehl pip install pettingzoo[sisl], um die Basisumgebungsbibliothek von SISL zu installieren. Natürlich können Sie die Basisumgebung auch lokal über die folgende Methode installieren:
cd ~/reinforcement/mindspore_rl/environment
git clone https://github.com/Farama-Foundation/PettingZoo.git
cd PettingZoo
pip install -e .[sisl]
Auf der Grundlage dieser Basisumgebung kapseln wir SISL gemäß dem Kapselungsmodus der vorhandenen Umgebung von MindSpore Reinforcement. Informationen zur spezifischen Codeimplementierung finden Sie unter sisl_environment.py.
Die Wrapper-Klasse der SISL-Umgebung erbt hauptsächlich die folgenden Klassen:
from mindspore_rl.environment import Environment
Um mit MindSpore Reinforcement und dem Trainingsframework von MindSpore kompatibel zu sein, erben oder verwenden wir die folgende Datenstruktur in der Wrapper-Klasse der SISL-Umgebung:
import mindspore as ms
from mindspore.ops import operations as P
from mindspore_rl.environment.space import Space
Nachdem wir das Code-Framework von MindSpore Reinforcement beobachtet hatten, stellten wir fest, dass verschiedene Algorithmen nur an bestimmte Umgebungen angepasst sind und nicht alle Umgebungen und Algorithmen universell sind. Beispielsweise ist der MAPPO-Algorithmus nur an die MPE-Umgebung angepasst, sodass der Algorithmus nur den kontinuierlichen Vektorzustandsraum und den diskreten Aktionsraum unterstützt. Da die Implementierung der MPE-Umgebung außerdem mehrere Prozesse verwendet, wird der MAPPO-Algorithmus auch für mehrere Prozesse implementiert . Spezialisierte Anpassung. In einem anderen Beispiel ist der QMIX-Algorithmus nur an die SMAC-Umgebung angepasst, sodass der Algorithmus nur einen kontinuierlichen Vektorzustandsraum und einen diskreten Aktionsraum unterstützt. Die SMAC-Umgebung ist ein einzelner Prozess, sodass der QMIX-Algorithmus nur für einen einzelnen Prozess geeignet ist. Daher können die vorhandenen Algorithmen von MindSpore Reinforcement diskrete und kontinuierliche Zustands- oder Aktionsräume nicht universell unterstützen, und Zustandsräume sind im Allgemeinen nur für Vektorformen geeignet. Für andere Eingabeformen wie Bilder müssen zusätzliche Backbone-Netzwerke wie CNN implementiert werden. Darüber hinaus erfordert die Zugriffsumgebung auch eine spezifische Anpassung basierend auf der Einzelprozess- oder Mehrprozessimplementierung des Algorithmus.
Um uns an den QMIX-Algorithmus anzupassen, implementieren wir die Einzelprozessversion der SISL-Umgebungs-Wrapper-Klasse SISLEnvironment und kapseln alle APIs der Umgebung gemäß dem MindSpore Reinforcement-Kapselungsformat.
Zur Anpassung an den MAPPO-Algorithmus implementieren wir die Multiprozessversion der SISL-Umgebung, die Wrapper-Klasse SISLMultiEnvironment und die auf Python basierende Multiprocessing-Bibliothek, um die Multiprozess-Scheduling-Klasse EnvironmentProcessNew zu implementieren und alle APIs der Umgebung zu kapseln gemäß dem MindSpore Reinforcement-Kapselungsformat.
4.2 MAPPO-Algorithmus-Benchmark-Testexperiment
reinforcement_MAPPO
├─ example
│ ├─ make_plot.py
│ ├─ scripts
│ │ ├─ mappo_train_log.txt
│ │ └─ run_standalone_train.sh
│ └─ train_SISL.py
└─ mindspore_rl
├─ algorithm
│ ├─ config.py
│ ├─ config_SISL.py
│ ├─ mappo.py
│ ├─ mappo_replaybuffer.py
│ ├─ mappo_session.py
│ ├─ mappo_trainer.py
│ ├─ mappo_vmap.py
│ ├─ mappo_vmap_trainer.py
│ ├─ mpe
│ ├─ mpe_environment.patch
│ ├─ mpe_environment.py
│ ├─ on-policy
│ ├─ sisl_environment.py
│ └─ __init__.py
└─ environment
└─ sisl_environment.py
SISL-Umgebungscodebaum, implementiert durch den MAPPO-Algorithmus
Der MAPPO****-Algorithmus ist von der Umgebung entkoppelt
MAPPO in Shengsi Mindspore ist nativ mit der MPE-Umgebung verbunden und kann bei Versuchen von Teammitgliedern direkt in der MPE-Umgebung ausgeführt werden, wobei die Schritte der Interaktion mit der Umgebung, Training, Parameteraktualisierung usw. erfolgreich abgeschlossen werden, um die Korrektheit sicherzustellen des MAPPO-Algorithmuscodes. SISL verfügt über verschiedene Karten als experimentelle Umgebungen, darunter Multiwalker, Pursuit und Waterworld. Eine direkte Änderung der Datei config.py kann jedoch nicht erfolgreich in der SISL-Umgebung ausgeführt werden. Nach Recherchen und Diskussionen unter Teammitgliedern stellten sie fest, dass bei der MAPPO-Implementierung im MindSpore-Framework der MAPPO-Algorithmus stark mit der Umgebung gekoppelt ist. Beispielsweise werden in MAPPOSession.py alle umgebungsbezogenen Variablen wie die Anzahl der Agenten, die Beobachtungsdimension der Zustandsdimension und die Dimension der möglichen Aktion als spezifische Werte und nicht in Umgebungsvariablen implementiert Es werden explizit definierte Variablen wie die Anzahl der Agenten, die Konfigurationsparameter sein sollen, entfernt. Diese explizite Definition verhindert, dass Änderungen an der Datei config.py innerhalb des Algorithmus übergeben werden, was zu Laufzeitfehlern an der Schnittstelle des Feature-Eingabenetzwerks führt.
Wir haben den ursprünglichen Algorithmus verbessert und einen Entkopplungsteil von der Umgebung hinzugefügt, der es dem Framework ermöglicht, die entsprechenden Umgebungsinformationen korrekt aus der config.py-Datei zu lesen und die Umgebungsinformationen korrekt zu verwenden, um sie an den Algorithmus zu übergeben, wodurch die Entkopplung der Umgebung und der Umgebung wirklich realisiert wird MAPPO-Algorithmus.
MAPPO- Zugriff auf die SISL-Umgebung****
Nach Abschluss der oben genannten Arbeiten können wir sicherstellen, dass der MAPPO-Algorithmus korrekt ist und die Parameter der Konfigurationsdatei korrekt an den Algorithmus übergeben werden können. Anschließend begannen die Teammitglieder, sich mit der SISL-Umgebung zu verbinden. Im MindSpore-Framework entsprechen unterschiedliche Algorithmen unterschiedlichen Umgebungen und haben unterschiedliche Ausführungen. Während des Debugging-Prozesses haben wir festgestellt, dass für die Multithread-Version der SISL-Umgebung die Anzahl der Multithread-Threads und die Anzahl der in jedem Thread vorhandenen Umgebungen nicht direkt geändert werden können Umgebungen führen dazu, dass der Algorithmus an einem bestimmten Punkt hängen bleibt. Außerdem ist numpy.int32 während der Ausführung des Codes nicht mit int32 kompatibel, was zu Problemen mit der Umgebung führt Konvertierung; was von der Umgebung zurückgegeben wird, ist die One-Hot-Codierung der Aktion, die sie nicht direkt in das definierte Mappo-Netzwerk für Schulungen und andere Probleme eingeben kann.
Nachdem die Probleme des Datentyps und der Interaktion mit der Umgebung gelöst waren, trainierten die Teammitglieder MAPPO in der SISL-Umgebung. Gemäß dem Standard-Trainingscode meldete das Programm jedoch einen Fehler und wurde nach jedem Training von 19 Episoden beendet. Nach der Diskussion zwischen den Teammitgliedern und dem zeilenweisen Debuggen enthält der ursprüngliche Trainingscode nach jedem Training keine Aufforderungsinformationen zum Abschneiden, um die Episode zu beenden. Wenn also die nächste Trainingsrunde beginnt, wird die Umgebung aus der vorherigen übernommen Die Runde wird im Status fortgesetzt und die Anzahl der ausgeführten Schritte der vorherigen Runde der Umgebung wird nicht gelöscht. Da die Pursuit-Umgebung so eingestellt ist, dass sie eine maximale Anzahl von Ausführungsschritten aufweist, werden nach dem Ausführen der maximalen Anzahl von Ausführungen der Umgebung gemäß dem Umgebungsframework alle Belohnungen und Beobachtungen in der Ausführungsfunktion von sisl_environment.py ausgeführt Die letzte Schrittumgebung wird gelöscht und die Ausführungsfunktion wird nicht ausgeführt. Die gelöschten Variablen werden nicht verarbeitet, sodass das Programm während der Ausführung der Funktion immer dann abstürzt, wenn die in der Umgebung angegebene maximale Anzahl von Schritten erreicht ist. Dies ist auch der Grund Warum meldet das Programm nach jeweils 19 Trainingsepisoden einen Fehler? Daher haben die Teammitglieder einen Test hinzugefügt, um zu sehen, ob die festgelegte Höchstzahl erreicht ist. Wenn die Höchstzahl erreicht ist, sendet die Umgebung ein Kürzungssignal, beendet die Ausführungsfunktion und setzt die Umgebung zurück.
Nachdem die oben genannten Schwierigkeiten gelöst wurden, konnte der MAPPO-Algorithmus erfolgreich in der SISL-Umgebung ausgeführt werden. Legen Sie die für MAPPO erforderlichen Zustandsinformationen als Zusammenführung aller Agentenbeobachtungen fest und führen Sie maximal 500 Episoden durch. Führen Sie MAPPO-Experimente in der SISL-Umgebung durch und zeichnen Sie die Belohnungs- und Verlustkurven während des Trainings. Nach Abschluss des Trainings erhalten wir folgende Ergebnisse:
4.3 QMIX-Algorithmus-Benchmark-Testexperiment
reinforcement_QMIX
├─ example
│ ├─ qmix
│ │ ├─ eval.py
│ │ ├─ scripts
│ │ │ ├─ run_standalone_eval.sh
│ │ │ └─ run_standalone_train.sh
│ │ └─ train.py
│ └─ __init__.py
└─ mindspore_rl
├─ algorithm
│ ├─ qmix
│ │ ├─ config.py
│ │ ├─ qmix.py
│ │ ├─ qmix_session.py
│ │ ├─ qmix_trainer.py
│ │ ├─ _config.py
│ │ ├─ __init__.py
│ └─ __init__.py
└─ environment
├─ sc2_environment.py
└─ sisl_environment.py
SISL-Umgebungscodebaum, implementiert durch den QMIX-Algorithmus
Korrektur des QMIX-Algorithmus
Während unserer Implementierung stellten wir fest, dass im MindSpore-Framework der ursprüngliche QMIX-Algorithmus und seine entsprechende experimentelle Umgebung SMAC nicht ausgeführt werden konnten und die Routine eval.py ebenfalls einen Fehler meldete und nicht ausgeführt werden konnte. Um die Korrektheit des Algorithmus und die Machbarkeit der Umgebung zu testen, haben wir daher zunächst den QMIX-Algorithmus und die entsprechende im Framework implementierte Umgebung überarbeitet.
Da das MindSpore-Framework zum ersten Mal zum Einsatz kam, stellten die Teammitglieder fest, dass die Fehlermeldung des Frameworks während des Experiments nicht offensichtlich war. Nach Diskussion und Zusammenarbeit zwischen den Teammitgliedern wurde festgestellt, dass dies auf die wiederholte Verwendung von Vererbung und Überladung im Framework sowie auf die zugrunde liegende Computerlogik zurückzuführen ist, die die Python-Sprache zur Berechnung in das CPP-Berechnungsdiagramm übersetzt, was fast dazu führt Dieselben Fehlerberichte und der Debugger im Framework können nicht immer den entsprechenden Fehlerort zurückgeben.
Durch zeilenweises Debuggen haben wir festgestellt, dass in der implementierten QMIXTrainer-Klasse „save_reward“ hätte zurückgegeben werden sollen, in der SMAC-Umgebung jedoch fälschlicherweise „Step_info“ zurückgegeben wurde. Nach dem Debuggen kann der QMIX-Algorithmus in einer der SMAC-Umgebungen korrekt überprüft werden.
Entkopplung des QMIX-Algorithmus von der Umgebung
Basierend auf den bisherigen Erfahrungen der Teammitglieder verfügt SMAC über verschiedene Karten als experimentelle Umgebungen, wie zum Beispiel 2s3z, das in Shengsi MindSpore implementiert wurde, sowie 3m, 3s5z usw. Wenn wir jedoch die entsprechende config.py-Datei wie im Dokument beschrieben ändern, kann das ursprüngliche Programm nicht direkt ausgeführt werden. Nach Recherchen und Diskussionen unter den Teammitgliedern stellten sie fest, dass bei der QMIX-Implementierung im MindSpore-Framework der QMIX-Algorithmus stark mit der Umgebung gekoppelt ist. Beispielsweise werden in QMIXTrainer fast alle umgebungsbezogenen Variablen wie die Anzahl der Agenten, Agent_num, die Beobachtungsdimension obs_shape und die Dimension der möglichen Aktion als spezifische Werte und nicht als Umgebungsvariablen implementiert.
-
Die obige Funktion „evaluieren()“ wird in der Trainings- und Testphase wiederverwendet und es treten die oben genannten Probleme auf. Trennen Sie sie hier, um funktionale Verwirrung zu vermeiden.
-
Agent_num, obs_shape und andere Variablen beziehen sich auf die Umgebung und haben nichts mit dem Algorithmus zu tun. Lokale Variablen wurden hinzugefügt und der Code wurde gemäß der Dokumentation von MindSporeRL umgestaltet, um den Algorithmus von der Umgebung zu entkoppeln und den Framework-Spezifikationen zu entsprechen.
Zusammenfassend lässt sich sagen, dass wir durch Debuggen und Überarbeiten des Frameworks das Problem der übermäßigen Kopplung zwischen der Umgebung und dem Algorithmus gelöst und tatsächlich die Entkopplung des QMIX-Algorithmus und der SMAC-Umgebung erreicht haben. Wir haben auch eine Pull-Anfrage für diese Version des Codes im ursprünglichen Code-Repository eingereicht, um späteren Benutzern des Frameworks die Arbeit zu erleichtern.
Wenn wir in der 3s5z-Umgebung unseren Code zum Testen von QMIX verwenden, erhalten wir die folgenden Ergebnisse:
QMIX-Zugriff auf die SISL-Umgebung
Nach Abschluss der oben genannten Arbeiten können wir sicherstellen, dass der QMIX-Algorithmus korrekt ist, und entsprechende Ergebnisse in der entsprechenden SMAC-Umgebung erhalten. Anschließend begannen die Teammitglieder, sich mit der SISL-Umgebung zu verbinden. Wie bereits erwähnt, entsprechen im MindSpore-Framework unterschiedliche Algorithmen unterschiedlichen Umgebungen und haben unterschiedliche Ausführungen. Der QMIX-Algorithmus implementiert nur eine Single-Threaded-Version und ist daher nicht mit der oben genannten MAPPO-Umgebung interoperabel. Während des Debugging-Prozesses stellten wir fest, dass die Single-Thread-Version der SISL-Umgebung nie normal laufen konnte. Der Ort des Fehlers ist schwer zu finden. Sein Inhalt ist: Python-Instanz kann nicht in C++-Typ umgewandelt werden.
Die Teammitglieder diskutierten und debuggten Zeile für Zeile und stellten fest, dass das MindSpore-Framework die unterste Cpp-Ebene zum Kompilieren in ein Berechnungsdiagramm für beschleunigte Berechnungen verwendet. Daher gibt es einen Übersetzungsprozess von Python nach CPP, und dieser Prozess unterscheidet sich geringfügig von dem Traditioneller Python-Laufprozess. Das traditionelle Python-Programm ist eine interpretierte Sprache und das Programm wird fast zeilenweise ausgeführt, während cpp als kompilierte Sprache vollständig kompiliert und ausgeführt werden muss. Aus diesem Grund vermuteten die Teammitglieder, dass eine solche Vermischung zu dem oben erwähnten unklaren Problem bei der Fehlerberichterstattung führte. Gleichzeitig müssen Sie beim Schreiben eines Programms jederzeit den Datentyp jeder Variablen überprüfen. Im Gegensatz zu herkömmlichem Python ist numpy.int32 nicht mit int32 kompatibel, was einen hohen Zeitaufwand erfordert Überprüfen des Datentyps jedes Schritts von der Umgebung bis zum Algorithmus.
Angesichts der aufgetretenen Schwierigkeiten versuchten die Schüler der Gruppe, nacheinander die Datentypen der einzelnen Daten in der Umgebung und im Algorithmus zu überprüfen, waren jedoch immer noch nicht in der Lage, die spezifische Variable, bei der das Problem auftrat, und den Ort, an dem das Problem auftrat, zu lokalisieren. Darüber hinaus haben wir eine Multiprozessversion der SISL-Umgebung implementiert und führen den MAPPO-Code aus. Nach der Diskussion kamen die Teammitglieder zu dem Schluss, dass das Problem durch die Inkonsistenz zwischen dem Datentyp und dem zugrunde liegenden C++-Datentyp, den er aufruft, verursacht wurde. Es ist schwierig, das Problem durch Einzelpunkt-Debugging zu lokalisieren. Sie müssen es mit Kompilierung und Debuggen versuchen. Gleichzeitig hat dieses Problem wenig mit dem Inhalt des Reinforcement-Learning-Kurses zu tun, sodass wir keine Zeit damit verbracht haben, die Implementierung des QMIX-Algorithmus in einer Einzelprozess-SISL-Umgebung zu debuggen.
05
abschließend
In diesem Reinforcement-Learning-Experiment hat unser Team erfolgreich eine Spieltestumgebung für Multi-Agenten-Kooperationsszenarien – SISL (Stanford Intelligent Systems Laboratory) – mit der MindSpore-Plattform verbunden und versucht, hierfür QMIX- und MAPPO-Algorithmen zu verwenden experimentelle Umgebung. Nachdem wir die verschiedenen in der Aufgabe genannten Anforderungen erfüllt haben, verfügen wir auch über ein tieferes Verständnis der zugrunde liegenden Architektur von MindSpore, was uns helfen wird, die MindSporeRL-Bibliothek in Zukunft geschickter auf unsere wissenschaftlichen Forschungsaktivitäten anzuwenden.
Verweise
[1]. Mnih V, Kavukcuoglu K, Silver D, et al. Atari spielen mit tiefem Verstärkungslernen[J]. arXiv-Vorabdruck arXiv:1312.5602, 2013.
[2]. Silver D, Huang A, Maddison CJ, et al. Das Go-Spiel mit tiefen neuronalen Netzen und Baumsuche meistern[J]. Natur, 2016, 529(7587): 484-489.
[3]. Silver D, Schrittwieser J, Simonyan K, et al. Das Go-Spiel ohne menschliches Wissen meistern[J]. Natur, 2017, 550(7676): 354-359.
[4]. Vinyals O, Babuschkin I, Czarnecki WM, et al. Großmeister-Level in StarCraft II mit Multi-Agent-Verstärkungslernen[J]. Natur, 2019, 575(7782): 350-354.
[5]. Brockman G, Cheung V, Pettersson L, et al. Offenes Fitnessstudio[J]. arXiv-Vorabdruck arXiv:1606.01540, 2016.
[6]. Todorov E, Erez T, Tassa Y. Mujoco: Eine Physik-Engine für modellbasierte Steuerung[C]//2012 Internationale IEEE/RSJ-Konferenz über intelligente Roboter und Systeme. IEEE, 2012: 5026-5033.
[7]. Mordatch I, Abbeel P. Entstehung einer fundierten Kompositionssprache in Populationen mit mehreren Agenten[C]//Vorträge der AAAI-Konferenz über künstliche Intelligenz. 2018, 32(1).
[8]. Romo L, Jain M. PySC2 Reinforcement Learning[J].
[9]. Samvelyan M, Rashid T, De Witt CS, et al. Die Starcraft-Multiagenten-Herausforderung[J]. arXiv-Vorabdruck arXiv:1902.04043, 2019.
[10]. Yu C, Velu A, Vinitsky E, et al. Die überraschende Wirksamkeit von PPO in kooperativen Multiagentenspielen[J]. Fortschritte in neuronalen Informationsverarbeitungssystemen, 2022, 35: 24611-24624.
[11]. Rashid T., Samvelyan M., De Witt CS, et al. Faktorisierung monotoner Wertfunktionen für tiefes Lernen zur Verstärkung mehrerer Agenten[J]. The Journal of Machine Learning Research, 2020, 21(1): 7234-7284.
[12]. https://pettingzoo.farama.org/environments/sisl/
[13]. Schulman J, Wolski F, Dhariwal P, et al. Proximale Richtlinienoptimierungsalgorithmen[J]. arXiv-Vorabdruck arXiv:1707.06347, 2017.
[14]. John Schulman, Philipp Moritz, Sergey Levine, Michael Jordan und Pieter Abbeel. Hochdimensionale kontinuierliche Kontrolle mittels verallgemeinerter Vorteilsschätzung. In Proceedings of the International Conference on Learning Representations (ICLR), 2016.
Ein in den 1990er Jahren geborener Programmierer hat eine Videoportierungssoftware entwickelt und in weniger als einem Jahr über 7 Millionen verdient. Das Ende war sehr bestrafend! Google bestätigte Entlassungen, die den „35-jährigen Fluch“ chinesischer Programmierer in den Flutter-, Dart- und Teams- Python mit sich brachten stark und wird von GPT-4.5 vermutet; Tongyi Qianwen Open Source 8 Modelle Arc Browser für Windows 1.0 in 3 Monaten offiziell GA Windows 10 Marktanteil erreicht 70 %, Windows 11 GitHub veröffentlicht weiterhin KI-natives Entwicklungstool GitHub Copilot Workspace JAVA ist die einzige starke Abfrage, die OLTP+OLAP verarbeiten kann. Dies ist das beste ORM. Wir treffen uns zu spät.