Auteurs : **** Yan Kexi, Jing Yuheng, Liu Zhihao, Feng Xiaokun, Lei Shiqi-** Institut d'automatisation, Académie chinoise des sciences
Résumé
Pour cette expérience d'apprentissage par renforcement, le thème choisi par notre équipe est "Nouvel environnement/nouvel algorithme pour l'accès MindSpore à l'apprentissage par renforcement". Nous avons connecté un environnement de test de jeu pour des scénarios de coopération multi-agents - SISL (Stanford Intelligent Systems Laboratory) à la plateforme MindSpore, et implémenté le test de performance des algorithmes QMIX et MAPPO dans cet environnement expérimental. Dans ce partage, nous procéderons à une introduction et à une analyse correspondantes autour des cinq aspects de la sélection du sujet, de l'environnement, de l'algorithme, des résultats expérimentaux et des conclusions.
Veuillez consulter la pièce jointe pour les codes liés au projet.
https://gitee.com/lemonifolds/reinforcement/tree/c03e5f8e6104b5880fdfa53d579332078c7dfb99
01
Introduction au sujet
L'apprentissage par renforcement est une discipline qui étudie la prise de décision séquentielle. Il apprend des stratégies d'optimisation pour maximiser les rendements cumulés en analysant le processus d'interaction entre un agent et l'environnement. Parmi eux, l'environnement est un élément important dans l'apprentissage par renforcement. Il détermine non seulement directement le format des données d'entrée du modèle d'algorithme, mais est également étroitement lié aux tâches de recherche de l'apprentissage par renforcement. Certains algorithmes classiques d’apprentissage par renforcement sont souvent accompagnés de certains environnements de vérification classiques. Par exemple, pour les tâches de perception et de prise de décision mono-agent, son algorithme classique DQN (Deep Q-learning) [1] a été vérifié dans le jeu Atari, un environnement classique pour cette tâche pour les tâches de jeu à somme nulle avec informations complètes ; et informations incomplètes tâches multi-joueurs Pour les tâches de jeu mixtes, ses travaux représentatifs AlphaGo[2][3] et AlphaStar[4] ont même nommé l'algorithme en fonction de l'environnement de vérification correspondant (Go, StarCraft). Cela montre le rôle important de l’environnement de vérification dans le domaine de l’apprentissage par renforcement.
Il existe de nombreux types d'environnements utilisés dans l'apprentissage par renforcement. Les environnements typiques incluent Gym[5], MuJoCo[6], MPE[7], Atari[1], PySC2[8], SMAC[9], TORCS, ISAAC, etc. À l'heure actuelle, l'architecture StarCraft MindSpore est connectée à deux environnements : Gym et SMAC (StarCraft Multi-Agent Challenge), qui sont respectivement orientés vers des scénarios d'apprentissage par renforcement mono-agent et d'apprentissage par renforcement multi-agent. Pour ces derniers, en raison de l’espace d’état, d’action et de décision complexe et de grande dimension du jeu StarCraft, il est devenu une référence importante et stimulante pour les algorithmes d’apprentissage par renforcement multi-agents. Cependant, dans la pratique réelle de la recherche scientifique, lorsque nous proposons un nouvel algorithme, nous le vérifions souvent d'abord dans certains petits environnements (comme l'environnement de jeu Atari dans Gym). Sur cette base, notre équipe a choisi un petit environnement de test pour les scénarios multi-agents - SISL (Stanford Intelligent Systems Laboratory), et l'a connecté à la plateforme MindSpore pour fournir à la plateforme un environnement de certification d'expérience multi-intelligence plus diversifié. De plus, nous avons également implémenté deux algorithmes typiques d'apprentissage par renforcement multi-agents, MAPPO [10] et QMIX [11], pour l'environnement SISL, et fourni les résultats des tests de référence correspondants.
Ensuite, ce partage donnera dans un premier temps une introduction préliminaire à l'environnement SISL connecté (Chapitre 2), ainsi que les algorithmes QMIX et MAPPO utilisés (Chapitre 3) puis, le processus de mise en œuvre de l'accès à l'environnement, les expérimentations et les résultats des tests de benchmark obtenus ; et les problèmes rencontrés dans l'expérience sont affichés et analysés (Chapitre 4) enfin, sur la base des résultats expérimentaux, nous donnons les conclusions correspondantes (Chapitre 5) ;
02
Présentation de l'environnement
PettingZoo[12] est une bibliothèque Python couramment utilisée dans la recherche sur l'apprentissage par renforcement multi-agents. SISL (Stanford Intelligent Systems Laboratory) est l'un des packages d'environnement, comprenant trois sous-environnements : Multiwalker, Pursuit et Waterworld.
L'utilisation de base de PettingZoo est similaire à Gym. Voici un exemple de code pour créer un agent agissant de manière aléatoire dans l'environnement Waterworld :
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()
Ce qui suit est une introduction aux trois sous-environnements de SISL.
2.1Multimarcheur
Dans l'environnement Multiwalker, les robots bipèdes tentent de transporter leur charge et de marcher vers la droite. Plusieurs robots transportent une grosse cargaison et doivent travailler ensemble, comme le montre l'image ci-dessous.
Diagramme d'environnement multimarcheur
Chaque agent recevra le retour du forward_reward multiplié par le changement de position du colis par rapport au point temporel précédent. Si au moins un des colis tombe ou si le colis dépasse la limite gauche du terrain, l'environnement prend fin et chaque agent reçoit -100 bénéfices. Si le colis tombe du bord droit du terrain, l'environnement prendra également fin, avec un gain de 0.
Si un agent tombe, il reçoit un bénéfice supplémentaire de -10. Si terminate_on_fall = False, alors l'environnement ne se terminera pas lorsque l'agent tombe, sinon l'environnement se terminera une fois l'agent tombé et apportera un bénéfice de -100. Si remove_on_fall = True, alors l'agent tombé sera supprimé de l'environnement. Chaque agent reçoit également -5 fois le changement d'angle de tête pour maintenir la tête au niveau. Si shared_reward = True, alors la récompense personnelle de chaque agent est calculée en moyenne et restituée à chaque agent.
Chaque agent exerce une force sur les deux articulations de ses deux pattes, son espace d'action continu est donc un vecteur à 4 dimensions. L'espace d'observation de chaque agent est un vecteur à 31 dimensions contenant des données radar bruitées sur l'environnement et les agents environnants, les angles et les vitesses de chaque articulation de son propre corps, ainsi que d'autres informations.
2.2 Poursuite
Dans l'environnement Poursuite, certains agents de poursuite tentent de poursuivre et d'encercler les évadés, comme le montre la figure ci-dessous (le rouge est l'agent de poursuite contrôlé, le bleu est le mouvement aléatoire des évadés).
Diagramme de l'environnement de poursuite
Par défaut, il y a 30 fugitifs et 8 agents poursuivants dans une grille 16X16, et il y a un obstacle (partie blanche) au centre de la carte. Si un agent entoure complètement un évadé, chaque agent environnant reçoit un avantage de 5 et l'évadé est retiré de l'environnement. Chaque fois que l'agent touche un évadé, il recevra également un bénéfice de 0,01.
Chaque agent dispose d'un espace d'action discret : haut, bas, gauche, droite, stop. L’espace d’observation de chaque agent est une grille 7X7 autour de lui, représentée en orange sur la figure.
2.3 Monde aquatique
L'environnement Waterworld simule les conditions dans lesquelles les archées tentent de survivre dans l'environnement. Chaque agent doit essayer de consommer de la nourriture et d'éviter les toxines, comme le montre l'image ci-dessous.
Diagramme de l'environnement du monde aquatique
En fonction des paramètres d’entrée, les agents peuvent avoir besoin de coopérer pour consommer de la nourriture, de sorte que le modèle peut être à la fois coopératif et compétitif. De même, les bénéfices peuvent également être différents ou moyennés pour chaque agent. L’environnement dans son ensemble est un espace bidimensionnel continu et les bénéfices reposent sur l’exposition aux aliments et aux toxines.
L'espace d'action de chaque agent est un vecteur bidimensionnel, c'est-à-dire l'avancement (accélération) dans les directions horizontale et verticale. L'espace d'observation de chaque agent est l'information reçue par chaque capteur sur la distance par rapport aux aliments, aux toxines, à d'autres agents, et s'il entre en collision avec des aliments ou des toxines. La dimension totale est ou
, selon les paramètres.
03
Introduction à l'algorithme
Dans cette section, nous présenterons l'algorithme MAPPO[10] et l'algorithme QMIX[11] utilisés dans l'expérience.
3.1 Algorithme MAPPO
Le nom complet de MAPPO est Multi-Agent Proximal Policy Optimization. Comme son nom l'indique, l'algorithme MAPPO est un algorithme d'apprentissage par renforcement classique - l'algorithme PPO [13], qui est étendu dans un environnement multi-intelligence. Pour les environnements multi-agents, ils sont souvent décrits à l'aide de < > sept tuples. Parmi eux, n représente le nombre d'agents ; S représente l'espace d'état de l'environnement ;
c'est l'espace de comportement composé des actions de tous les agents ;
il représente l'observation locale obtenue par l'agent i à partir de l'état global s ; environnement complètement observable, alors
); représente la probabilité de passer de s à s' étant donné une action conjointe ; R
(s,A) représente la fonction de récompense partagée ;
L'algorithme MAPPO utilise la structure classique acteur-critique, qui nécessite la formation de deux réseaux neuronaux distincts : le réseau politique et la fonction valeur
(respectivement acteur et critique).
Pour le réseau de politiques , il est utilisé pour apprendre une cartographie de l'observation o_i à la distribution d'action a_i, et l'objectif d'optimisation correspondant est :
Parmi eux, B représente la taille du lot, qui est calculée à l'aide de la méthode GAE [14],
représente l'entropie politique et
représente l'hyperparamètre du coefficient de pondération.
Pour la fonction de valeur , qui est utilisée pour apprendre la cartographie de l'état S pour récompenser l'estimation
, l'objectif d'optimisation correspondant est :
où représente le rendement actualisé calculé. Puisque MAPPO adopte une méthode de formation centralisée et de formation à l'exécution distribuée, la fonction valeur peut directement diviser l'état global tandis que la fonction politique ne peut traiter que
les informations d'observation locales de chaque agent .
Sur la base de la formule d'objectif d'optimisation ci-dessus, le processus de fonctionnement de MAPPO peut être obtenu. Le processus de traitement de l'algorithme MAPPO cyclique fourni dans l'article original [10] est organisé comme suit :
3.1 Algorithme MAPPO
Dans cette section, u est utilisé pour désigner les actions et u est utilisé pour désigner l'historique des actions et des observations. L'idée de conception de l'algorithme QMIX est similaire à celle du VDN. On espère que
chacun pourra être obtenu en calculant un algorithme global
. juste besoin de
Cela satisfera à l’exigence. Pour que la formule ci-dessus soit valable, il doit y avoir une monotonie par rapport à Q_i, c'est-à-dire
La structure du réseau neuronal de QMIX est illustrée dans la figure ci-dessous : Diagramme du cadre QMIX
Pour chaque agent i, il existe un réseau d'agents utilisé pour le calculer , comme le montre la figure (c). Ce réseau est un réseau DRQN , c'est-à-dire que la couche entièrement connectée dans DQN est remplacée par GRU, et l'entrée est l'observation de l'agent au temps t
et l'action au temps t-1
.
Le réseau hybride est un réseau neuronal à action directe qui reçoit n sorties du réseau d'agents et les mélange de manière monotone, et la sortie est le résultat, comme le montre la figure (a). Les poids du réseau hybride sont générés par un super réseau distinct. Le super réseau prend l'état global s_t en entrée et génère les poids d'une couche de réseau hybride. Chaque super-réseau se compose d'une seule couche linéaire avec une fonction d'activation en valeur absolue pour garantir que les poids du réseau hybride ne sont pas négatifs.
Le réseau QMIX est formé de bout en bout pour minimiser les pertes suivantes :
Parmi eux, se
trouvent les paramètres du réseau cible (similaires à DQN).
04
Résultats expérimentaux
Cette section effectue une analyse expérimentale spécifique basée sur l'introduction ci-dessus de l'environnement SISL et des algorithmes MAPPO et QMIX. Tout d'abord, nous introduisons le processus d'accès à l'environnement SISL (Section 4.1) ; puis, sur la base des algorithmes MAPPO et QMIX fournis dans l'entrepôt MindSporeRL d'origine, après modification et ajustement, nous essayons de les appliquer dans l'environnement nouvellement accédé. l'expérience de test (sections 4.2 et 4.3) est réalisée dans l'environnement SISL ; nous afficherons et présenterons les points d'amélioration technique, les résultats expérimentaux et les réflexions correspondants.
4.1 Processus d'accès à l'environnement SISL
Nous utilisons la commande pip install pettingzoo[sisl] pour installer la bibliothèque d'environnement de base de SISL. Bien entendu, vous pouvez également installer l'environnement de base localement via la méthode suivante :
cd ~/reinforcement/mindspore_rl/environment
git clone https://github.com/Farama-Foundation/PettingZoo.git
cd PettingZoo
pip install -e .[sisl]
Sur la base de cet environnement de base, nous encapsulons SISL selon le mode d'encapsulation de MindSpore Reinforcement de son environnement existant. Pour une implémentation de code spécifique, voir sisl_environment.py.
La classe Wrapper de l'environnement SISL hérite principalement des classes suivantes :
from mindspore_rl.environment import Environment
Afin d'être compatible avec MindSpore Reinforcement et le framework de formation de MindSpore, nous héritons ou utilisons la structure de données suivante dans la classe Wrapper de l'environnement SISL :
import mindspore as ms
from mindspore.ops import operations as P
from mindspore_rl.environment.space import Space
Après avoir observé le cadre de code de MindSpore Reinforcement, nous avons constaté que les différents algorithmes ne sont adaptés qu'à des environnements spécifiques et que tous les environnements et algorithmes ne sont pas universels. Par exemple, l'algorithme MAPPO n'est adapté qu'à l'environnement MPE, donc l'algorithme ne prend en charge que l'espace d'état vectoriel continu et l'espace d'action discret. De plus, puisque l'implémentation de l'environnement MPE utilise plusieurs processus, l'algorithme MAPPO est également implémenté pour plusieurs processus. .Adaptation spécialisée. Pour un autre exemple, l'algorithme QMIX est uniquement adapté à l'environnement SMAC, donc l'algorithme ne prend en charge que l'espace d'état vectoriel continu et l'espace d'action discret. L'environnement SMAC est un processus unique, donc l'algorithme QMIX ne convient qu'à un seul processus. Par conséquent, les algorithmes existants de MindSpore Reinforcement ne peuvent pas prendre en charge universellement les espaces d’état ou d’action discrets et continus, et les espaces d’état ne conviennent généralement qu’aux formes vectorielles. Pour d’autres formes d’entrée telles que les images, des réseaux fédérateurs supplémentaires tels que CNN doivent être implémentés. De plus, l’environnement d’accès nécessite également une adaptation spécifique basée sur la mise en œuvre de l’algorithme en mono-processus ou multi-processus.
Afin de nous adapter à l'algorithme QMIX, nous implémentons la version mono-processus de la classe Wrapper de l'environnement SISL SISLEnvironment, et encapsulons toutes les API de l'environnement selon le format d'encapsulation MindSpore Reinforcement.
Afin de nous adapter à l'algorithme MAPPO, nous implémentons la version multi-processus de l'environnement SISL, la classe Wrapper SISLMultiEnvironment et la bibliothèque multitraitement basée sur Python pour implémenter la classe de planification multi-processus EnvironmentProcessNew, et encapsuler toutes les API de l'environnement. selon le format d'encapsulation MindSpore Reinforcement.
4.2 Expérience de test de référence de l'algorithme MAPPO
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
Arbre de code d'environnement SISL implémenté par l'algorithme MAPPO
L’algorithme MAPPO**** est découplé de l’environnement
MAPPO dans Shengsi Mindspore est connecté nativement à l'environnement MPE et, dans les tentatives des membres de l'équipe, il peut s'exécuter directement sur l'environnement MPE, complétant avec succès les étapes d'interaction avec l'environnement, de formation, de mise à jour des paramètres, etc., garantissant l'exactitude du code de l'algorithme MAPPO. SISL propose différentes cartes comme environnements expérimentaux, notamment Multiwalker, Pursuit et Waterworld. Cependant, la modification directe du fichier config.py ne peut pas s'exécuter correctement sur l'environnement SISL. Après des recherches et des discussions entre les membres de l'équipe, ils ont découvert que dans l'implémentation de MAPPO dans le framework MindSpore, l'algorithme MAPPO est fortement couplé à l'environnement. Par exemple, dans MAPPOSession.py, toutes les variables liées à l'environnement telles que le nombre d'agents, la dimension d'observation de la dimension d'état et la dimension d'action réalisable sont implémentées en tant que valeurs spécifiques plutôt que variables d'environnement de la même manière dans sisl_environment.py ; sont explicitement définies. Les variables telles que le nombre d'agents qui doivent être des paramètres de configuration sont supprimées. Cette définition explicite empêche les modifications apportées au fichier config.py d'être transmises à l'intérieur de l'algorithme, ce qui entraînerait des erreurs d'exécution à l'interface du réseau d'entrée des fonctionnalités.
Nous avons amélioré l'algorithme d'origine et ajouté une partie de découplage de l'environnement, qui permet au framework de lire correctement les informations d'environnement correspondantes du fichier config.py et d'utiliser correctement les informations d'environnement pour les transmettre à l'algorithme, réalisant ainsi véritablement le découplage de l'environnement et Algorithme MAPPO.
Accès MAPPO à l'environnement SISL****
Une fois le travail ci-dessus terminé, nous pouvons garantir que l'algorithme MAPPO est correct et que les paramètres du fichier de configuration peuvent être correctement transmis à l'algorithme. Par la suite, les membres de l’équipe ont commencé à se connecter à l’environnement SISL. Dans le framework MindSpore, différents algorithmes correspondent à différents environnements et ont des exécutions différentes. Au cours du processus de débogage, nous avons constaté que pour la version multithread de l'environnement SISL, le nombre de threads multithread et le nombre d'environnements existants dans chaque thread ne peuvent pas être modifiés directement en modifiant directement le nombre de processus ou le nombre de processus. les environnements entraîneront le blocage de l'algorithme à un certain moment; de plus, lors de l'exécution du code, en raison d'une incompatibilité de type de données, par exemple, numpy.int32 n'est pas compatible avec int32, ce qui entraîne des problèmes d'environnement. conversion ; ce qui est renvoyé par l'environnement est l'encodage à chaud de l'action, qui ne peut pas l'entrer directement dans le réseau mappo défini pour la formation et d'autres problèmes.
Après avoir résolu les problèmes de type de données et d'interaction avec l'environnement, les membres de l'équipe ont formé MAPPO sur l'environnement SISL. Cependant, selon le code de formation par défaut, le programme a signalé une erreur et s'est arrêté après chaque formation de 19 épisodes. Après discussion entre les membres de l'équipe et débogage ligne par ligne, selon le code de formation d'origine, après chaque formation, il ne contient pas les informations d'invite de troncature pour terminer l'épisode, donc lorsque le prochain cycle de formation commence, l'environnement du précédent Le tour continuera. L'exécution démarre dans l'état et le nombre d'étapes en cours du cycle d'environnement précédent ne sera pas effacé. Étant donné que l'environnement Pursuit est configuré pour avoir un nombre maximum d'étapes en cours d'exécution, après avoir exécuté le nombre maximum d'exécutions de l'environnement, selon le cadre d'environnement, toutes les récompenses et observations dans la fonction d'exécution de sisl_environment.py qui sont exécutées vers le L'environnement de l'étape finale sera effacé et la fonction d'exécution ne le sera pas. Les variables effacées ne sont pas traitées, donc pendant l'exécution de la fonction, chaque fois que le nombre maximum d'étapes spécifié par l'environnement est atteint, le programme plante. C'est aussi la raison. pourquoi le programme signale une erreur tous les 19 épisodes d'entraînement. Par conséquent, les membres de l'équipe ont ajouté un test pour voir si le nombre maximum défini est atteint. Si le nombre maximum est atteint, l'environnement envoie un signal de troncature, termine la fonction d'exécution et réinitialise l'environnement.
Après avoir résolu les difficultés ci-dessus, l’algorithme MAPPO a pu s’exécuter avec succès sur l’environnement SISL. Définissez les informations d'état requises pour que MAPPO soit l'épissage de toutes les observations d'agent et exécutez un maximum de 500 épisodes. Chaque épisode contient 500 pas de temps. Menez des expériences MAPPO sur l'environnement SISL et dessinez les courbes de récompense et de perte pendant la formation. Une fois la formation terminée, nous obtenons les résultats suivants :
4.3 Expérience de test de référence de l'algorithme QMIX
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
Arbre de code d'environnement SISL implémenté par l'algorithme QMIX
Correction de l'algorithme QMIX
Au cours de notre implémentation, nous avons constaté que dans le framework MindSpore, l'algorithme QMIX d'origine et son environnement expérimental correspondant SMAC ne pouvaient pas s'exécuter, et la routine eval.py a également signalé une erreur et n'a pas pu s'exécuter. Par conséquent, afin de tester l'exactitude de l'algorithme et la faisabilité de l'environnement, nous avons d'abord révisé l'algorithme QMIX et l'environnement correspondant implémenté dans le framework.
Comme c'était la première fois que nous utilisions le framework MindSpore, les membres de l'équipe ont constaté que le message d'erreur du framework n'était pas évident lors de l'expérience. Après discussion et coopération entre les membres de l'équipe, il a été constaté que cela était dû à l'utilisation répétée de l'héritage et de la surcharge dans le framework, ainsi qu'à la logique informatique sous-jacente pour traduire le langage python en graphe de calcul cpp pour le calcul, ce qui a entraîné presque le mêmes rapports d'erreurs, et le débogueur dans le framework n'est pas toujours capable de renvoyer l'emplacement d'erreur correspondant.
Grâce au débogage ligne par ligne, nous avons constaté que dans la classe QMIXTrainer implémentée, save_reward aurait dû être renvoyé, mais que Step_info dans l'environnement SMAC a été renvoyé de manière incorrecte. Après le débogage, l'algorithme QMIX peut être correctement vérifié dans l'un des environnements SMAC.
Découplage de l'algorithme QMIX de l'environnement
Sur la base de l'expérience antérieure des membres de l'équipe, SMAC dispose de différentes cartes comme environnements expérimentaux, telles que 2s3z qui a été implémentée dans Shengsi MindSpore, ainsi que 3m, 3s5z, etc. Cependant, lorsque nous modifions le fichier config.py correspondant comme décrit dans le document, le programme d'origine ne peut pas être exécuté directement. Après recherches et discussions entre les membres de l'équipe, ils ont découvert que dans l'implémentation de QMIX dans le framework MindSpore, l'algorithme QMIX est fortement couplé à l'environnement. Par exemple, dans QMIXTrainer, presque toutes les variables liées à l'environnement telles que le nombre d'agents Agent_num, la dimension d'observation obs_shape et la dimension d'action réalisable sont implémentées sous forme de valeurs spécifiques plutôt que de variables d'environnement.
-
La fonction évaluer() ci-dessus est réutilisée dans les phases de formation et de test, et les problèmes ci-dessus se produisent. Séparez-les ici pour éviter toute confusion fonctionnelle.
-
Agent_num, obs_shape et d'autres variables sont liées à l'environnement et n'ont rien à voir avec l'algorithme. Des variables locales ont été ajoutées et le code a été refactorisé selon la documentation de MindSporeRL pour découpler l'algorithme de l'environnement et se conformer aux spécifications du framework.
En résumé, grâce au débogage et à la révision du framework, nous avons résolu le problème du couplage excessif entre l'environnement et l'algorithme, et avons véritablement réalisé le découplage de l'algorithme QMIX et de l'environnement SMAC. Nous avons également soumis une pull request pour cette version du code dans le référentiel de code d'origine pour la commodité des utilisateurs ultérieurs du framework.
Dans l'environnement 3s5z, en utilisant notre code pour tester QMIX, nous obtenons les résultats suivants :
Accès QMIX à l'environnement SISL
Une fois le travail ci-dessus terminé, nous pouvons garantir que l'algorithme QMIX est correct et obtenir les résultats correspondants dans l'environnement SMAC correspondant. Par la suite, les membres de l’équipe ont commencé à se connecter à l’environnement SISL. Comme mentionné précédemment, dans le framework MindSpore, différents algorithmes correspondent à différents environnements et ont des exécutions différentes. L'algorithme QMIX n'implémente qu'une version monothread, il n'est donc pas interopérable avec l'environnement MAPPO susmentionné. Au cours du processus de débogage, nous avons constaté que la version monothread de l'environnement SISL ne pouvait jamais fonctionner normalement. L'emplacement de l'erreur est difficile à localiser. Son contenu est : Impossible de convertir l'instance Python en type C++.
Les membres de l'équipe ont discuté et débogué ligne par ligne et ont découvert que le framework MindSpore utilise la couche inférieure Cpp pour compiler dans un graphique de calcul pour des calculs accélérés, il existe donc un processus de traduction de python vers cpp, et ce processus est légèrement différent du processus d'exécution python traditionnel. Le programme Python traditionnel est un langage interprété, et le programme est presque exécuté ligne par ligne ; tandis que cpp, en tant que langage compilé, doit être entièrement compilé et exécuté. Pour cette raison, les membres de l’équipe ont émis l’hypothèse qu’un tel mélange conduisait au problème de rapport d’erreurs peu clair mentionné ci-dessus. Dans le même temps, vous devez vérifier le type de données de chaque variable à tout moment pendant le processus d'écriture d'un programme. Contrairement au Python traditionnel, numpy.int32 n'est pas compatible avec int32, ce qui nécessite beaucoup de temps. vérifier le type de données de chaque étape de l'environnement à l'algorithme.
Face aux difficultés rencontrées, les étudiants du groupe ont tenté de vérifier tour à tour les types de données de chaque donnée dans l'environnement et l'algorithme, mais ils n'ont toujours pas réussi à localiser la variable spécifique où le problème s'est produit et l'emplacement où le problème s'est produit. De plus, nous avons implémenté une version multi-processus de l'environnement SISL et exécuté le code MAPPO. Après discussion, les membres de l'équipe ont conclu que le problème était dû à l'incohérence entre le type de données et le type de données C++ sous-jacent qu'il appelle. Il est difficile de localiser le problème via le débogage en un seul point. Vous devez essayer la compilation et le débogage. Dans le même temps, ce problème n'a pas grand-chose à voir avec le contenu du cours d'apprentissage par renforcement, nous n'avons donc pas continué à consacrer du temps à déboguer l'implémentation de l'algorithme QMIX dans un environnement SISL à processus unique.
05
en conclusion
Dans cette expérience d'apprentissage par renforcement, notre équipe a réussi à connecter un environnement de test de jeu pour des scénarios de coopération multi-agents - SISL (Stanford Intelligent Systems Laboratory) à la plateforme MindSpore et a essayé d'utiliser les algorithmes QMIX et MAPPO pour ce faire. Des benchmarks de performances ont été réalisés dans le cadre de cette expérience. environnement expérimental. Après avoir rempli les différentes exigences indiquées dans la mission, nous avons également une compréhension plus approfondie de l'architecture sous-jacente de MindSpore, ce qui nous aidera à appliquer plus habilement la bibliothèque MindSporeRL à nos activités de recherche scientifique à l'avenir.
les références
[1]. Mnih V, Kavukcuoglu K, Silver D et al. Jouer à l'Atari avec un apprentissage par renforcement profond[J]. Préimpression arXiv arXiv : 1312.5602, 2013.
[2]. Silver D, Huang A, Maddison CJ et coll. Maîtriser le jeu de Go avec les réseaux de neurones profonds et la recherche arborescente[J]. nature, 2016, 529(7587): 484-489.
[3]. Silver D, Schrittwieser J, Simonyan K et al. Maîtriser le jeu de go sans connaissance humaine[J]. nature, 2017, 550(7676) : 354-359.
[4]. Vinyals O, Babuschkin I, Czarnecki WM et al. Niveau Grand Maître dans StarCraft II utilisant l'apprentissage par renforcement multi-agents[J]. Nature, 2019, 575(7782) : 350-354.
[5]. Brockman G, Cheung V, Pettersson L et al. Gymnase ouverte[J]. Préimpression arXiv arXiv : 1606.01540, 2016.
[6]. Todorov E, Erez T, Tassa Y. Mujoco : Un moteur physique pour le contrôle basé sur des modèles[C]//Conférence internationale IEEE/RSJ 2012 sur les robots et systèmes intelligents. IEEE, 2012 : 5026-5033.
[7]. Mordatch I, Abbeel P. Émergence d'un langage compositionnel ancré dans les populations multi-agents[C]//Actes de la conférence AAAI sur l'intelligence artificielle. 2018, 32(1).
[8]. Romo L, Jain M. Apprentissage par renforcement PySC2 [J].
[9]. Samvelyan M, Rashid T, De Witt CS et al. Le défi multi-agent Starcraft[J]. Préimpression arXiv arXiv : 1902.04043, 2019.
[dix]. Yu C, Velu A, Vinitsky E et al. L'efficacité surprenante du ppo dans les jeux coopératifs multi-agents[J]. Avancées dans les systèmes de traitement de l’information neuronale, 2022, 35 : 24611-24624.
[11]. Rashid T, Samvelyan M, De Witt CS et al. Factorisation de fonctions de valeur monotones pour un apprentissage par renforcement multi-agents approfondi [J]. Le Journal de recherche sur l'apprentissage automatique, 2020, 21(1) : 7234-7284.
[12]. https://pettingzoo.farama.org/environments/sisl/
[13]. Schulman J, Wolski F, Dhariwal P et al. Algorithmes d'optimisation de politique proximale [J]. Préimpression arXiv arXiv : 1707.06347, 2017.
[14]. John Schulman, Philipp Moritz, Sergey Levine, Michael Jordan et Pieter Abbeel. Contrôle continu de grande dimension utilisant l'estimation des avantages généralisés. Dans Actes de la Conférence internationale sur les représentations d'apprentissage (ICLR), 2016.
Un programmeur né dans les années 1990 a développé un logiciel de portage vidéo et en a réalisé plus de 7 millions en moins d'un an. La fin a été très éprouvante ! Google a confirmé les licenciements, impliquant la « malédiction des 35 ans » des codeurs chinois des équipes Flutter, Dart et . Python Arc Browser pour Windows 1.0 en 3 mois officiellement la part de marché de GA Windows 10 atteint 70 %, Windows 11 GitHub continue de décliner l'outil de développement natif d'IA GitHub Copilot Workspace JAVA. est la seule requête de type fort capable de gérer OLTP+OLAP. C'est le meilleur ORM. Nous nous rencontrons trop tard.