Apprentissage par renforcement profond - Q moyen comme métrique d'évaluation

Question

Je suis en train de mettre au point un modèle d'apprentissage en profondeur pour un apprenant du jeu Space Invaders (image ci-dessous). L'état est défini comme la distance euclédienne relative entre le joueur et les ennemis + la distance relative entre le joueur et les 6 lasers ennemis les plus proches normalisés par la hauteur de la fenêtre (si la position du joueur est$(x_p,y_p)$ et la position d'un ennemi est $(x_e,y_e)$, la distance euclidienne relative est $\frac{\sqrt{(x_p-x_e)^2+(y_p-y_e)^2}}{HEIGHT}$et HEIGHT est la hauteur de la fenêtre). Par conséquent, la dimension de l'espace d'observation est (10 + 6), ce qui entraîne une entrée de mon réseau neuronal profond de 16 unités.

Mon agent ne semble pas apprendre (la fonction de récompense n'augmente pas) et j'ai pensé vérifier les valeurs Q moyennes, qui sont la sortie de mon principal réseau de neurones profonds, et, au lieu d'augmenter, j'ai remarqué que les valeurs Q moyennes se stabilisent (comme dans la figure ci-dessous) au lieu d'augmenter. J'ai modifié de nombreux paramètres de réglage (taille du lot, architecture du réseau neuronal et paramètres ...) mais j'ai toujours le même problème. Une idée de la raison pour laquelle les valeurs Q moyennes n'augmenteraient pas?

Voici quelques résultats sur l'apprenant:

Answer 1

Je pense que votre problème principal est l'utilisation de la distance relative comme caractéristique principale. Il présente deux faiblesses majeures:

• La distance à un objet ne donne pas la direction à l'objet. Les meilleurs choix d'action dépendent tous de manière critique de la direction. Par exemple, un boulon laser ennemi de 0,1 unité directement au-dessus du joueur est un danger immédiat nécessitant une action évasive, tandis qu'une unité de 0,1 unité à gauche ou à droite n'est pas un danger et est sur le point de quitter la fenêtre de jeu. Votre caractéristique de distance relative ne fait pas la distinction entre ces scénarios, mais c'est une différence critique.

• Un peu moins important, mais la distance brute ne capte aucune sensation de mouvement. Si les ennemis se déplacent constamment tour par tour, mais pas toujours exactement dans la même direction ou à la même vitesse, alors leurs vitesses devraient également faire partie de l'état.

Une façon d'améliorer les fonctionnalités est d'ajouter une composante de vélocité pour chaque élément, indiquant à quelle vitesse il s'approche ou s'éloigne du lecteur. Cela peut aider un peu, mais je pense que vous avez besoin de plus de données que de distance et de vitesse.

Je pense que vous devriez utiliser normalisé $x, y$position en tant qu'entités pour chaque élément suivi, plus vitesse normalisée$dx, dy$ pour tout type d'objet qui peut changer de direction (si les lasers ennemis tombent toujours droit, vous n'aurez peut-être besoin de rien pour ceux-ci).

En plus:

• Si les bords de la fenêtre sont importants, vous devez inclure au moins le $x$de l'un d'entre eux, de sorte que l'agent connaisse sa position absolue à l'écran et l'espace dont il dispose pour manœuvrer. Cela est vrai que le joueur ne puisse pas se déplacer plus à gauche ou à droite, ou que le joueur «s'enroule» de l'autre côté de l'écran. Les deux types d'effets affecteront considérablement la façon dont le jeu se déroule près du bord de l'écran.

• Afin de suivre la valeur prévue, vous devez suivre l'emplacement des missiles des joueurs. Il ne suffit pas de laisser simplement l'agent prédire quand il est préférable de tirer - pour suivre avec précision une fonction de valeur, il a besoin de "voir" si le missile qu'il a tiré il y a quelques pas de temps est susceptible de toucher ou de rater une cible.

• Pour les lasers ennemis et les missiles des joueurs, il est possible de filtrer et de trier les données en fonction de certains critères (tels que la distance au joueur). Tant que cela est cohérent, il peut même être très utile d'avoir un tel prétraitement.