Оптимизацията на проксималната политика (PPO) е техника за градиент на политика, която е сравнително лесна за прилагане и може да разработи политики за максимизиране на възнаграждението за широк клас проблеми [1].

Подобно на други методи за градиент на политики, PPO може да оптимизира повтарящи се политики на невронни мрежи. Това може да бъде много полезно, тъй като в много среди наблюденията не представят пълното състояние на системата, но повтарящият се модел може да разбере какви са състоянията от поредица от наблюденият.е. Частично наблюдаваните процеси на вземане на решение по Марков (POMDP) ​​могат да бъдат решени, сякаш са процеси на вземане на решение по Марков (MDP). Този подход беше използван от OpenAI Five, за да победи световните шампиони в Dota [2].

В много по-малък мащаб полезността на този подход е демонстрирана в частично наблюдаваната среда [3] по-долу:

HardcoreBipedalWalker-v2

За да квалифицира допълнително подхода, той тества някои по-измислени примери. Много от средите на Gym предоставят наблюдения със скоростни условия, така че те са напълно видими и могат да бъдат решени с помощта на наблюденията като състояния. За да тествам способността на LSTMs да научават състоянието, маскирах термините за скорост и резултатите могат да се видят по-долу:

CartPole-v2 (Маскирани условия за скорост в наблюдения)

Pendulum-v0 (Маскирани термини за скорост в наблюдения)

LunarLander-v2 (Маскирани термини за скорост в наблюдения)

LunarLanderContinuous-v2 (Маскирани термини за скорост в наблюдения)

BipedalWalker-v2 (Термините за скорост не са маскирани)

Допълнителна обосновка

Надяваме се, че горните примери са показали, че повтарящите се модели могат да помогнат в среди, където частичната наблюдаемост е проблем. Въпреки това бих отишъл по-далеч и смятам, че има основателни причини да го използвам като общ метод по подразбиране за решаване на среди:

  1. Моделът може да изчисли състоянието от наблюденията вместо нас

Много среди се състоят от или включват динамична механична система. За да бъде MDP, средата трябва да включва както позицията, така и скоростта, което е точно това, което правят Gym среди като CartPole, Pendulum и LunarLander. Без повтарящ се модел и използване на наблюденията директно като състояние могат да бъдат постигнати само ниски резултати, тъй като политиката не може да знае дали да спира или да ускорява за дадена позиция. За този прост случай знаем отговора, но с нарастването на сложността на наблюденията ще става все по-трудно да проектираме подходящо състояние и по-лесно да позволим на модела да го изчисли вместо нас. Пример за това е BipedalWalkerHardcore, където [2] обяснява, че ходещият трябва да запомни, че може да е видял в предишните кадри, за да избегне попадането в тях.

2. Понякога наблюденията се контролират от самия агент

Докато агентът се движи в частично видим свят, може да се наложи да научи къде търсим, за да можем да получим наблюденията, необходими за оптимални действия.

3. Моделът може да ни предпази от непознаването на проблема

Дори ако смятаме, че сме проектирали състояние въз основа на наблюденията, за да намалим сложността на проблема до MDP, можем да направим грешки, напр. Може би ни липсват съответните познания за домейна, има грешка или сложността на състоянието е извън нашето разбиране. За мен това е едновременно смущаващо и вълнуващо, защото повтарящият се модел може автоматично да се научи да се справя с това вместо нас.

Забележителни подробности за внедряването

Повечето от съответните подробности за алгоритъма могат да бъдат получени от [1], така че ще се съсредоточа върху някои от инженерните подробности тук:

1. Изпълнение на Gym Vector

Стандартната среда за фитнес работи с една среда наведнъж. Други RL реализации, които съм виждал, работят около това, като изпълняват отделни процеси паралелно. Това работи, но консумира много ресурси, особено когато се правят изводи върху множество отделни модели. Gym сега разполага с хубаво решение на този проблем чрез обвиване на средата, така че множество екземпляри на една и съща среда да могат да работят заедно или синхронно в един и същ процес, или асинхронно, използвайки множество процеси. Увеличаването на размера на пакета за политиката и критика от 1 (единична среда) до 32 паралелни среди е много много по-бързо от 32 модела, работещи паралелно, правейки изводи върху един пакет.

2. Google Colab

Обучението и тестването на модела бяха проведени в Colab на Google. Основната причина за това е, че средата щедро предлага безплатен GPU. Това обаче не е без ограничения и според моя опит няма да позволи непрекъснато използване на GPU повече от около 12 часа. Има и други проблеми, като например прекъсвания на връзката. Това означава, че за работни места за обучение, отнемащи няколко дни като BipedalWalkerHardcore-v2, трябваше да се добави възможността за запазване и възобновяване от контролни точки, записани в Google Drive.

3. Инициализация на състоянието

При заснемане на траектория за обучение на модел е лесно скритото състояние на LSTM и състоянието на клетката да се инициализира до нула. След това преминете през пълен епизод, позволявайки на LSTM да актуализира собственото си състояние за всяка стъпка. По време на обучението разделяме епизода на части с дължина обикновено около 8 стъпки. По време на обучението можем също да инициализираме скритото състояние и състоянието на клетката до нула, но при тези условия съотношението pi / pi_old може да бъде доста различно дори при същите параметри на политиката. Този проблем става по-добър, колкото по-голям е с по-дълги дължини на тренировъчни последователности като 16 или 32, тъй като началното състояние има по-малко влияние върху крайното състояние, но обратното също е вярно и става по-лошо за по-къси дължини на последователности. За да смекчим този проблем, можем да запазим състоянията на LSTM по време на внедряване и да ги използваме за инициализация по време на обучение. За първата итерация на обучение във всяка итерация на PPO, тези запазени скрити и клетъчни състояния са точни, но с промяната на параметрите те стават по-малко точни. Въпреки това, това все още е много по-точна инициализация от нулата и като такава произвежда по-точни градиенти за обучение, което позволява използването на много кратки дължини на последователност.

4. Оформяне на възнаграждението

Получените награди могат да имат голямо влияние върху това как PPO решава проблем. В средите BipedalWalker и BipedalWalkerHardcore се дава награда за движение напред, прилага се наказание за въртящ момент и голяма отрицателна награда (-100) за падане. Използвах същия подход като в [4], за да огранича наградата до минимум -1 за средите на ходещите. Разликата в поведението е доста драматична:

Неоформена награда:

  1. Уокър се научава да приема много стабилна стойка и остава там до края на епизода.
  2. Уокър бавно се научава да се тътри напред.
  3. Походката на Уокър бавно става по-малко консервативна и по-бърза.

Оформена награда:

  1. Уокър бързо се научава да пада напред.
  2. Падането на Walkers става все по-дълго и по-дълго, докато се учи да се „хваща“ с краката си.
  3. Уокър вече не пада и е намерил високоскоростна походка.

Докато PPO може да реши и двата проблема, неоформеното възнаграждение отнема много повече време за решаване на проблема и походката е по-малко удовлетворяваща, защото е толкова консервативна.

Връзки за внедряване и настройка

Изпълнението се състои от две тетрадки. Един за обучение на политика в избрана среда: recurrent_ppo.ipynb

и един за генериране на тестово видео: test_recurrent_ppo.ipynb

Преносимите компютри очакват следните директории в Google Drive:

/работно пространство/контролни точки

/работни пространства/дневници

/работно пространство/видеоклипове

Директорията с контролни точки се използва за запазване на модела и параметрите на оптимизатора, така че моделът да може да бъде възобновен или тестван. Директорията logs се използва за запазване на регистрационните файлове на Tensorboard, а директорията videos се използва за запазване на видео изхода от тестовия бележник.

Запазените контролни точки, използвани за генериране на резултатите, са включени тук: контролни точки, те могат да бъдат добавени към облака на Google, за да възобновите от, да тествате или дори да прехвърлите обучението.

15 минути трениран Bipedal WalkerHardcore-v2

Това видео се състои от около 70 епизода. Забележете, че все още се проваля доста често. Средната награда беше около 160, когато загубих търпение да го тренирам.

Заключение

PPO алгоритъмът заедно с повтарящ се модел е наистина мощна комбинация. Способен да произвежда добри резултати при широк кръг от проблеми, решавайки както MDP, така и POMDP в непрекъснати и дискретни пространства за действие.

Препратки

[1] Алгоритми за оптимизиране на проксималната политика https://arxiv.org/pdf/1707.06347.pdf

[2] Dota 2 с голям мащаб Deep Reinforcement Learning https://arxiv.org/pdf/1912.06680.pdf

[3] Повтарящ се детерминистичен градиентен метод на политиката за двукрако придвижване по неравен терен, предизвикателство https://arxiv.org/pdf/1710.02896.pdf

[4] PPO с LSTM и паралелна обработка https://github.com/jet-black/ppo-lstm-parallel