1. была ставка, что нужно увеличить обзы. Ставка не сработала - заметка #136.
2. дальше было подозрение, что новый VisionHead из 18d_world_model_09:183 какой-то бракованный. Однако, связка вижн хед VisionHead:183 + frostbite_07_old дала результаты. Выходит, что дело было не в VisionHead, а в батч-нормализация внутри вижн хеда
3. наличие батч нормализации внутри вижн хеда вместе с неявным багом в использовании этого вижн хеда на оптимизации даёт положительный результат - на 3-ем шаге рождаются носители полезного навыка “умеют проходить 5-ый уровень. Выходит, что на роллауте агент играет с одними статистиками, близкими к тем, которые были на обучении WorldModel (уровни вплоть до 10-го), а на оптимизации использует статистика батча. И вот это расхождение вносит какую-то регуляризационную составляющую, которая приводит к рождению агентов носителей
4. захотелось избавиться от этого бага, т.к. это а) неконтролируемая хрень б) не позволяет масштабировать длину входной цепочки.
5. почему-то подумалось, что дело в забывчивостм агента. Это частично подтердилось тем, что через 18n_explore_03 стало ясно, что агент на третьем шаге разучился играть на 5-ом азбучном уровне.
6. сделал эксперимент с постепенным расширением адресного пространства FFN (MLP) в трансформере политики. Типа на первом шаге доступно 1/6 адресов для записи и чтения. На втором шаге доступно следующая 1/6 адресов для записи и 2/6 для чтения и т.д. Идея была в сохранении накопленного опыта. Но идея проавалилась, т.к. FFN (MLP) не живёт изолированно, а зависит от того, что в том числе проиходит в Attention слоях. Т.к. слои внимания мутируют, то ключи в FFN слое теряют синхронизацию с выходами слоёв внимания и модель разваливается.
7. поэтому сделал шаг в сторону LoRA архитектуры (frostbite_11). Это когда модель морозится но на MHA и FFN слои сверху нашлёпываются низкоранговые прослойки, которые впитывают новый опыт. Но в запуск это дело не пошло, т.к. стало понятно, что пока получение носителей на третьем шаге решено не будет LoRA будет преждевременным
8. поэтому натренил новый вижн хед без батч-норма (VisionHead:294). Вместо батч-норма взял PixelNorm. 45-ая линейка исследований показала, что туго, но носители рождаются и можно дальше тренить
9. потом подумалось, что можно взять под контроль батч-норм, если перенести его напрямую в энкодер. Идея сначала обломалась (46-линейка), так как была неправильная реализация энкодера (флаг is_ob_features_batch_norm не пробрасывался). Со второго раза получили новый энкодер (18d_world_model_10:29). Но выяснилось, что и для него нужен хак в виде постоянного передёргивания на параметры того, какой был в WorldModel - флаг is_world_model_ob_features_batch_norm.
10. к 26 октября пришли с пониманием, что надо просто брать вижн хед без батч-норма, энкодер без батч-норма, убирать все эти долбанные хаки и просто за счёт чуть большего кол-ва ранов на 3-ем шаге получать носителей. Также на 5+ шагах даёт эффект расширения окна обзов (sequence_ages)
11. ещё стало понятно после прочтения [DohareContLearn], что есть серьёзная проблематика с continual learning. На каждом шаге модель забывает старый опыт, и при этом плохо впитывает новый опыт. Именно поэтому азбука 5-го уровня на 3-ем шаге выветривается. Единственное, что спасает - это nine_lives в диете. Этот патч обеспечивает наличие в батчах оптимизации траекторий из всего спектра уровней. Поэтому агент как-бы умудряется сохранять опыть через этот костыль.

Идеи, куда двигаться дальше зависят от целей. А цели, напоминаю, следующие:

1. убер-цель: разработать агента, который может уметь играть в широкий спектр игр
2. под-цель: отточить необходимы для убер-цели механизмы на базе Frostbite. А для этого заставить его пройти дальше 10+ уровней.
3. что это за механизмы: а) сохранение старого опыта (политика работы с памятью), б) пластичность и адаптивность к новому, в) иерархическое мышление агента (от целей высшего порядка, к моторике)

Идеи, куда двигаться дальше:

1. подправить селектор decisive_metric. Сейчас он слеп к тем, кто на роллауте показывает большой потенциал. В итоге потомки рождаются не от тех, кто на 3-ем шаге научился проходить 5 уровней, а тот кто играет ровно, но имеет потолок. Короче, ведёт к стагнации. Надо, чтобы можно было явно выбирать более потециальных агентов
2. в том или ином виде реализация идей из [DohareContLearn]. Например, частичная реинициализация сети (через расчёт полезности нейронов), чтобы сделать её восприимчивой для нового опыта.
3. LoRA - это реальный способ адаптации большой сетки к новому опыту. Тоже со счетов не сбрасываем.
4. Hierarchical Reinforcement Learning, HRL. Хотя этим идеям уже лет 30 (Dayan & Hinton 1993, Feudal Reinforcement Learning), но всё равно можно каким-то наработками вдохновиться.

Первые 11 дней показали, что хитрость нужна не зря. Но и её мало.

> между делом: те же 11 дней агент-ассистент получил больше памяти и разобрался с долговременным хранением. Забавно ставить задачи памяти модели мира ровно тогда, когда чинишь память у собственного цифрового коллеги.

Что сделали с окном

Собрал 18n_ppo_tr_frostbite_08: длина истории теперь задаётся через sequence_ages, а временная разметка — синусоидальная, как в ванильном трансформере (Васвани и соавт., «Attention Is All You Need»). Уже это ставило вопрос: то же это самое «окно пошире» или другое качество.

Первый прогон — 18n_study_36.1 — был ещё на старой схеме. Новую temporal_encoding там не реализовали: работали старые learned-параметры, sequence_ages не использовался. То есть все 16 обзов каждый раз грузились агенту на ленту целиком. Честное «окно 16 против 4», без хитростей.

Результат неутешительный. Окно 16 значимо хуже: средняя 0.5561 против 0.6272 у бейзлайна с окном 4 (18n_study_31.1). Лучший агент с окном 16 (25) — 0.7594, лучший бейзлайн (521, 528) — 0.7969.

Вывод: окно само по себе не лекарство. И дело, скорее всего, не в самой памяти как таковой, а во времени — чтобы научиться пользоваться более длинной историей, агенту, видимо, нужно заметно больше обучения. Пока окно 16 — это не «умнее», а «дороже».

Модель мира: проблема была в данных

Долго бились с системной проблемой recon/0.1+recon/3.0 — модель неверно восстанавливала нижний ряд льдин.

Пробовали ёмкость VisionHead (24.1, 25.1), ёмкость и число слоёв RenderHead (26.1, 27.1), ширину d_model (28.1). Всё давало копейки и проблему не решало.

Разгадка пришла в 18d_study_30.1: дело было не в модели, а в данных. Объединили текущие 16 датасетов с 12 из 18d_world_model_09:40 — итого 28 — и получили ssim 0.9905. Месяцы тюнинга архитектуры против правильно собранного датасета: датасет выиграл.

Дотренировали чемпионов (18d_study_30.2) — взяли VisionHead версии 183 (ssim 0.9936). На нём теперь строится вся 18n-линейка.

Потолок третьего уровня

Дальше — самое неприятное. На 183 собрали новый бейзлайн (18n_study_31.1), но чемпионы 18n_study_32 оказались сплошной посредственностью: все упёрлись в levels_passed=3. В сентябре мы брали 5 уровней (см. #133). Новый бейзлайн не дотягивает до старого — это и есть «хтонь» 34-й линейки, которую 34.3b–34.5 пытались продавить количеством прогонов. Не продавили.

Сквозной прогон 18n_study_35 вернул логику работы от обзов на оптимизации, как в старом frostbite_07_old. Дались жидкие прострелы (18n_study_35.4 — 3.75), но не прорыв. Финальная попытка 18n_study_35.3d — тот же третий шаг, но на старом коде — 3.0.

Вывод трезвый, без посыпания головы пеплом: низковисячие фрукты съедены. Простые рычаги — количество прогонов, анниллинг, логика обзов — дали своё, и дальше ими не выехать. Остаётся либо случайность, либо сам VisionHead. Значит, пора изобретать новые подходы, а не перебирать старое.

Где угнетается исследование (спойлер: не сильно)

Отдельная ветка — расследование 18n_study_23.3b–23.3n вокруг AMP. Тут пришлось городить новый гипер is_obs_usage_enforced, чтобы воспроизвести логику старого 18n_ppo_tr_frostbite_07: на роллауте без AMP, на оптимизации — с AMP, но с полной цепочкой obs → VisionHead → Encoder → ob_latents.

is_obs_usage_enforced оказался очень коварным. Из-за него можно было неявно менять VisionHead, даже когда его обучение выключено. Дело в используемых внутри него BatchNorm2d. По-дефолту модель стоит в train режиме, и поэтому при прогоне батчей на оптимизации у неё меняются running_mean, running_var. А в прологе к оптимизации стояла строка:

if RT.vision_head.is_trainable: RT.vision_head.train()

Т.е. получается, что без явного вызова RT.vision_head.eval() на оптимизации мы начинали менять VisionHead неявным образом!

Правильный код:

RT.vision_head.train(RT.vision_head.is_trainable)

По-честному, выхлоп небольшой. И с prediction_loss не сказать, что эффект прямо такой уж сильный: убрали — хуже, вернули — лучше, но всё на грани шума. Скорее всего, дело опять-таки в самом VisionHead и в случайности.

Разное

Победили недетерминизм PPO: torch.use_deterministic_algorithms(True) + cudnn.deterministic=True + cudnn.benchmark=False, плюс дефолты по дропауту и шуму. Теперь запуски с одним random_seed сходятся до копейки — с этим проще сравнивать эксперименты.

Что дальше

1. Сфокусироваться на 8-обзовом варианте, где работают два timescale. Понять, помогает ли такая схема растить выдающихся чемпионов.
2. Если не поможет — возвращаться к VisionHead версии 40 и заниматься регрессионной охотой.
3. prediction_loss оставить как есть: убедительных доказательств, что он что-то сильно портит, нет.

В рамках 18n_study_26.6 и 18n_study_27.6 объявился феномен “горбатости”. Сначала агент преуспевает на поздних уровнях, а потом медленно деградирует. Связываю это с разучиваением. Типа если он проводит больше времени на поздних уровнях, то начинает забывать начальные. Эффект не катастрофический, т.к. мы заставляем его постоянно проходить начальные уровни и тем самым не даём политике развалится, но всё равно неприятный.

Ещё также обнаружился феномен двух фракций: одни агенты очень стабильно проходит первые уровни практически без потерь, но не так феерично играют на поздних уровнях, а другие наоборот - играют небрежно, могут сдохнуть где-нибудь на 3 или 4-ом уровне, но зато легче доходят до 8-го.

Чем можно победить разучивание? Кажется, что только памятью. Сейчас у агента что есть: 1) коротенькая tape-like память на 4 слота - текущие наблюдения, 2) память в MLP слоях трансфомера. Видимо в таком сетапе агенту некуда просто выгрузить нерелевантную для данного уровня информацию и наоборот, подгрузить, нужную. На ум приходят архитектуры, где есть какая-нибудь матричная память, DND, LSTM или GRU. Но какой-то цельной картины, как это встроить непонятно.

Что стало более понятно, так это то, что можно пока поработать с tape-like памятью - трансформенным окном. Сейчас это 4 наблюдения. Я считал, что т.к. игра fully-observable, то этого хватает. Джемини мне подпевал только. А теперь я понимаю следующее. Да, во Frostbite нет такого понятия, как неразведанная территория или fog of war, как в StarCraft. Но это не означает, что 4-х наблюдений хватит для построения оптимальной политики. Возьмем, например, гусей. Вот они улетели с одной стороны и что-то должно появиться с другой стороны: может рыбка, может крабы, может гуси. Если у агента только 4 наблюдения, то для него просто существует миг. Появление врагов с другой стороны будет для него сюрпризом. А вот если бы у агенты была хотя бы память на несколько секунд, то он мог бы это предвидеть и действовать более оптимально. То же самое и со льдинам.

Другая аналогия. Если у агента есть только 4 наблюдения, и агент бы обитался в нашем мире, то он никогда бы не смог понять смену дня и ночи, времён года да и вообще чего-бы то ни было, что не укладывается в этот промежуток времени. Т.к. каждый эпизод для него - это всего лишь 4 наблюдения. Для него день и ночь - это как будто всегда существующее состояние. Перехода между ними просто нет. И он действует как будто всегда ночь или всегда день. И только наличие памяти позволит зацепить эти переходы и понять, что есть более низкочастотные явления, чем передвижения льдинок или гусей на пару пикселей. А раз так, то и действия его могут быть более хитрыми.

Как быстро проверить? Решил, что пока не хочется ломать архитектуру сильно и превносить какие-то другие конструкции (LSTM, GRU). Думаю просто увеличить контекстное окно до 32. Это где-то около 5 секунда времени. Но если увеличить в лоб, то сразу агент начнёт жрать кучу памяти и обучение будет длиться вечность. Поэтому идём на хитрость. Делаем окно 32, но на роллауте собираем только 4 обза. Обучаем агента, боль-мень играть. Потом морозим энкодер (а это работает - см. 18n_study_26.6), и открываем окно на полную. Т.е. в начале агент смотрит только на 4 обза (высокочастотное обучение), а потом получает доступ к более богатой истории. И по идее он должен стать более умным.

Архитектура

На нижнем уровне CNN сетка. Далее идут два стэкированных трансформера: энкодер и полиси. Можно и без энкодера, но тогда в полиси сразу уедут 4 * 42 латента (квадратичная сложность), что сделает его очень медленным и очень требовательным к памяти. Поэтому промежуточный энкодер необходим. Полиси трансформер анализирует динамику и вычисляет латенты для будущего плана действий, предсказательный латент. Преобразованный латент последнего обза (lat4') используется для оценки состояния через ValueHead (Linear). Следующее действие вычисляет ActorHead (Linear). Предсказанием будущего занимается PredictorHead (MLP).

Общее кол-во параметров: 5_081_479

Кол-во оптимизируемых параметров: 4_930_439

Всё произошло в рамках 18n_study_18.5e. Было три акта прохождения:

• 18n_ppo_tr_frostbite_06:355
• 18n_ppo_tr_frostbite_06:359
• 18n_ppo_tr_frostbite_06:369

Обидно только, что это случилось в самом начале или в середине, а ближе к концу агенты даже немного деградировали. Но сам факт, что агент смог пройти 5 уровней - это то, над чем я бился несколько месяцев. Значит, ёмкость архитектуры позволяет агенту одолевать 5 уровней. Осталось только оптимизировать путь обучения и саму архитектуру, чтобы результат был стабильным.

Успех закреплён в 18n_study_19.6e, тут уже побогаче:

• 18n_ppo_tr_frostbite_06:610 (два раза финальных)
• 18n_ppo_tr_frostbite_06:607 (два раза)
• 18n_ppo_tr_frostbite_06:609 (два раза)
• 18n_ppo_tr_frostbite_06:613 (один раз)

Рефлексия по пройдённому пути с Atari Frostbite, что сработало:

1. трансформер прекрасно заменяет stacked frames. Трансформе по сути - это работа с памятью.
2. там, где можно сломать joint, надо ломать. Например, spatial encoding - лучше сделать два отдельных экондинга по X,Y (separate), чем один объединённый (joint). Так модели нужно меньше учиться и это усиливает обобщающую способность
3. как можно быстрее переходить на работу с латентами (что-то типа идей JEPA). Граундиться на обзервейшны (RenderHead), особенно для предсказания - это дохлый номер.
4. стохастичность. На первых уровнях можно искусственно увеличивать стохастичность, чтобы способоствовать лучшему изучению пространства состояний. На более поздних уровнях искусственная стохастичность может мешать, т.к. а) стохастичнотсть уже и так встроена и б) сами по себе поздние уровние (например, 5-ый) уже и так достаточно сложные. Получается, что можно создать трейн РАМ-ы, которые очень сложны в прохождении. Из-за чего агент может даже деградировать, т.к. начнёт терять путевондуню нить - поток награды
5. прохождение пятого уровня на видео захвате не гарантирует, что агент научился его проходить уверенно. Многое зависит от random_seed. Например, для random_seed=64 агент будет проходить 5-ый уровень с 20% вероятность, а с random_seed=61 - уже только с 5% вероятностью. Поэтому чтобы агент уверенно проходил 5-ый уровень, надо чтобы при обучении он проходил 6-ой уровень. Это типа как с тренировками: если пробегаешь полумарафон, то пробежать 10км - вообще ни о чём.
6. полноцветный материал лучше серого: (3, 84, 84) » (1, 84, 84). Обучаемость на полном цвете идёт явно бодрее
7. очень помогла декомпозиция CNN + Transformer на CNN (VisionHead) + Encoder (Transformer) + Policy (Transformer). В первом случае вся тяжесть по кодированию обзов влетает в CNN, из-за чего его колбасит и агент забывает прошлый опыт при значительном переключении палитры (см. проблему дневной/ночной уровень). Во втором случае мы морозим VisionHead и заставляем тем самым перераспределить тяжесть логики вычисления латентного представления состояния на трансформеры.
8. одного или двух запусков не хватает. Нужно минимум 10, а лучше больше, чтобы получить адекватное представление о распределении кривых эффективности агента. Есть является “зацепляемости” (traction) - взрывной роста эффективности агента случается при наступлении комбинации событий. А чтобы эту комбинацию поймать, нужно несколько запусков с разным рандом сид
9. естественный отбор. Прошлый пункт сам собой предлагает путь, когда для обучения на следующем этапе отбираются самые эффективные агенты. Иначе так можно впустую жечь ресурсы. Да, всегда есть вероятность с водой выплеснуть и ребёнка (оставить не выбранным более агента, который бы себя позднее проявил), но это нерабочая схема из-за дороговизны ресурсов. Если бы ресурсов было бесконечно много, то можно было бы всех проверять, но это невозможно.

В исследовании 18n_study_17.1 энкодер был разморожен и обучаемость агента стала явно веселее - близко к той, что была в 17-ых агентах. Это заставляет думать, что энкодер, обученный для целей реконструкции / предсказания, не достаточен. Чего-то мозгу агента не хватает для выработки оптимальной стратегии поведения. Но вместе с тем, тренить сразу и мозг и энкодер - это ОЧЕНЬ долго и жрёт много памяти.

Получается такая ситуция:

Выводы:

1. уверенное продвижение вперёд пока может обеспечить только вариант, когда энкодер (какой-был он ни был: встроенный или факторизованный), обучается вместе с политкой (мозгами).
2. 17-ые агенты были покинуты из-за проблемы замещения опыта. Проблему замещения опыта хотелось решить факторизацией энкодера с его заморозкой
3. значит, надо решить проблему замещения как-то иначе нежели простой заморозкой

• Encoder - переводит обз. (178,152) в латентный вектор (256). Использует внутри VisionHead, который CNN 6x6
• Predictor - потребляет цепочку латентов от энкодера и на их основе предсказывает латент следующего обза.
• RenderHead - принимает на вход латенты и по ним возвращает обз. (178,152).

Цель была в том, чтобы легко унести Encoder в 18n_ppo_tr_frostbite и там использовать сравнение латентов, вместо рендеринга. Это откроет возможности для использования более длинных цепочек и тем самым решить проблемы тупизны агента, когда он не может разобраться с тем, он сдох или это очистка уровня идёт.

Как ни странно, для сравнения латентов подходит обычный MSE. Ещё пробовал InfoNCE. Штука красивая, но требует ещё доп. прожектор и по ssim, ниже чем MSE. См. исследования 18d_study_14.1, 18d_study_15.1, 18d_study_15a.1, 18d_study_16.1, 18d_study_17.1.

Из важного:

1. для обучения энкодера оказалось достаточно последнего обза из секва. До этого прогонял все обзы, но это просто увеличивалос время тренинга, НЕ добавляя в качестве. По факту я просто брал датасет, умножал каждый элемент на 4, и прогонял этот датасет. Понятно, что на распределение это никак не влияет, а только влияет на время и потребление памяти. Короче, как только перешёл на использование только последнего обза из секва, сразу скорость в небеса.
2. сравнение латентов VS сравнение через рендеринг. По скорости - небо и земля. Однозначно надо держаться за сравнение латентов, правда тут возникает вопрос - а вот где та граница, когда два латента достаточно хороши? Короче проблема граундинга, надо как-то цепочку до реальности простраивать, иначе можно (особенно при иерархической конструкции) фантазировать латентами, которые ничего общего с реальностью не имеют.
3. фокусность. Возможно проблема граундинга можно решить не тем, чтобы с пиксель-перфект качеством рендерить обзы, а с тем, чтобы уметь рендерить небольшой кусочек обза. Это схоже с тем, как мы думаем о будущем. Мы не можем думать о всём сразу, мы можем думать и воображать о чём-то одном. И потом из этих частей можно сложить уже полную картинку. А вот сразу всё - это не охватывается.
4. горизонт воображения. С предсказанием следующего обза есть проблема слишком короткого горизонта - порядка 0,13сек. За это время редко когда меняется позиция игрока, врагов. Чаще они просто меняет своё состояние: кралья вверх или вниз, ножки подогнуты или вытянуты. А если позиция и меняется, то незначительно. Поэтому модель может просто это обойти тем, чтобы рисовать что-то размыленное в пределах ожидамой границы перемещения. Поэтому интересно посмотреть, как будет на более длинном горизонте предсказание работать. Например, предсказывать, что будет через +1 сек.
5. возникла мысль, что можно стэкировать предсказатели. И их отдельно обучать. И что каждый предсказатель потребялет латенты нижележащего.

Проблемы:

• жрётся ощутимо больше памяти, чем 17-е агенты. Ну это и понятно - 17-ый агент оперировал цепочкой из 4-х токенов, а здесь сразу в 36 раз больше
• как следствие время роллаута и оптимизации тоже выросли. 6 млн шагов 2,5 часа требует =(

В ходе запусков выяснились интересные подробности:

1. в ale был баг в логике Frostbite, который приводил к тому, что игра переходила в режим скринсейвера. В итоге агент видел разворачивающееся действие, но нажатие кнопнок не давало никакого эффекта (). Агент познаёт безнадёгу, т.к. понимает, что от него ничего не зависит. Воспроизведение элементарное - надо, чтобы агент замёрз на последней жизни. Пофикшено в ale_py=0.12.0+neurolab3
2. после фикса бага вылез другой баг. Теперь если агент заходит в иглу на последней жизни, то ошибочно вздёргивался флаг terminated. Это всё из-зи того, что есть промежуточное состояние игры, в котором начисляются очки (levels clearance). А они начисляются с обратным отсчётом температуры. А в ale_py=0.12.0+neurolab3 я незамысловато поставил, что если жизнь последняя и температура упала до 0, то вздёрнуть флаг terminated. Короче, оба бага пофикшены в ale_py=0.12.0+neurolab4
3. prediction_coef=0.1, который хорошо работал для 17-ых агентов, стал приводить к вырожденному поведению в 18-ых агентах. Оказалось, что это слишком высокое значение, из-за которого агент предпочитает абсолютную предсказуемость. А она достигается, если просто стоять или делать простые механические движения. Почему значение коэффициента работало в 17-ых, и сломалось в 18-ых? Потому что в 17-х мы предсказывали эмбеддинг вектор (latent space), а 18-ых мы предсказываем пиксели. В итоге коэффициент по разному влияет на градиенты.
4. градиенты. Добавил выгрузку в тензорборд влияния того или иного лосса на градиент. Выяснилось, что, действительно, снижение prediction_coef с 0.1 до 0.02 снижает влияние лосса по предсказанию на несколько порядков. Т.е. связь нелинейная.
5. после получения вклада каждого лосса в градиенты выяснилось, что доминирующее значение вносит велью-лосс. Стал разбираться почему. Выяснилось, что есть агента колбасит туда-сюда, когда он утонет или пройдёт уровень. В обоих случая во входящей цепочке из 4-х картинок он видит статичную сцены, где ничего не двигается. И в итоге не может понять: это идёт начисление очков или это он утонул. И вот видно, чтоб если он думает, что идёт начисление очков и агент предполагает, что сейчас он нахоботит 40 очков, а по факту 2. И лосс просто громадные получается. Система такая: так, тащим влево. А потом следующий пример из батча: когда агент думает, что он сейчас нахоботит 20, а получает 30. И система такая: так, тащим вправо. Короче, великий тяни-толкай из-за того, что агент лишён возможности комплексно оценить обстановку. Я изначально думал, что 4-х кадров хватит. Да, этого хватит для активных игровых действий, но тут есть вот эти промежуточные состояния (начисление очков, анимация утопленности), которые на коротких цепочках сложно (если не невозможно) выявить.

Мораль-то какая.

1. Без чистого сигнала агенту очень туго приходится. Выясняется, что всё это время я тренировал агента на грязных сигналах.
2. Цепочка из 4-х наблюдений - этого недостаточно для Frostbite. Нужно 8-м. Либо нужно решать задачу по типу Transformer-XL, где мы анализируем эмбеддинг вектора.
3. Нужно внимательно смотреть на градиенты, чтобы правильно выставить веса потерь.
4. Если лосс колбасит, то это верный признак, что что-то идёт не так и надо с этим разбираться.

Теперь, если потребуется при разработке агента потребуется поиграться с поиском оптимальных вариантов организации зрения, то можно использовать 18d_world_model.

Из главного:

1. модель, когда одновременно и восстановление, и предсказание, показывает более высокий SSIM. Т.е. оба процесса дополняют друг друга.
2. увеличение длины цепочки с 4 до 5 или даже до 7 не даёт ожидаемого улучшения SSIM (16, 17, 18, 19, 20, 21). Даже наоборот, имеем более низкие значения SSIM.
3. увеличение сложности модели через heads_count и layers_count также не даёт улучшения по SSIM
4. сетка 6x6 даёт хорошние результаты по SSIM (18d_world_model_01/13 + 18d_world_model_01/14)

Самое большое удивление вызывает 2. Я думал, что чем длиннее цепочка, тем эффективнее будет модель. Интересно разобраться в причинах этого явления, но пока оставим, т.к. надо скорее девелопировать новый агент.

Короче, берём наработки из 18d и девелопируем новый агент.

So I came to idea that I need a more complex pipeline:

foveal point selector. This is a rough CNN (e.g. 4x4 grid) coupled with simple transformer. Goal: given observation produce number of foveal points (configurable parameter) in terms of x,y,std(x),std(y). I.e. produce parameters of Gaussian distribution from one could sample.

spatial feature extractor. Given sampled foveal points for each observation extract features with different resolution. I think I just need two resolutions: fine-grained (e.g. 5x5) and middle-grained (e.g. 4.4) with extended area. Observation space is not so large (it’s not a Starcraft observations) to use 3 or more resolution grades. so I end up with a bunch of feature tokens for each observation which I label with temporal label and spatial labels. The remaining part of model is unchanged for now.

Хотелось научиться работать многофокальными данными, когда есть несколько точек зрения на один кадр и потом через трансформер всё это изучается в целостности.

Провеёл несколько экспериментов для сетапа, когда есть 1 обзервейшн и нет pov_vision_head. Т.е. чисто за счёт ob_vision_head. Эксперименты:

Я думал, что чем больше грид и чем больше фичей, тем лучше. Но нет - как ни сранно 6х6 делает и 7х7 и 9х9 по крайней мере на первых 100 эпохах.

Дальше 4 обзервейшна, 2 пова, ob_vision_head выключен. База - это 'pov_vision_head': {'grid': (5, 5), 'features_counts': (16, 32, 64)} Эксперименты: |эксперимент|особенность|ssim| |—|—|—| |18c_world_model_02/15|-|0.8936| |18c_world_model_02/16|’parent’: ‘18c_world_model_02:15’, ‘learn_rate’: ‘const(0.0001)’|0.9037| |18c_world_model_02/17|’parent’: ‘18c_world_model_02:15’, ‘learn_rate’: ‘const(0.00025)’|0.8989| |18c_world_model_02/18|’parent’: ‘18c_world_model_02:15’, ‘learn_rate’: ‘const(0.00005)’|0.8994| |18c_world_model_02/19|’pov_coords_encoding’: {‘frequencies_count’: 16, ‘inner_d_model’: 64}|0.8855| |18c_world_model_02/20|’pov_coords_encoding’: {‘frequencies_count’: 6, ‘inner_d_model’: 128}|0.8775| |18c_world_model_02/21|’pov_coord_lists’: ‘pov_coord_lists:1:cls=2,0_526,49753,0_2’}|0.9026| |18c_world_model_02/22|’pov_coord_lists’: ‘pov_coord_lists:1:cls=2,0_526,49753,0_2’}, ‘pov_coords_encoding’: {‘frequencies_count’: 6, ‘inner_d_model’: 64, ‘is_combined’: False}|0.9053| |18c_world_model_02/23|’pov_coord_lists’: ‘pov_coord_lists:1:cls=2,0_526,49742’}, ‘pov_coords_encoding’: {‘frequencies_count’: 6, ‘inner_d_model’: 64, ‘is_combined’: False}|0.8806| |18c_world_model_02/24|’pov_vision_head’: {‘grid’: (5, 5), ‘features_counts’: (32, 64, 128)}, ‘pov_coord_lists’: ‘pov_coord_lists:1:cls=2,0_526,49742’}, ‘pov_coords_encoding’: {‘frequencies_count’: 6, ‘inner_d_model’: 64, ‘is_combined’: True}|0.8711| |18c_world_model_02/25|’comment’: ‘removed BatchNorm2d in pov_vision_head’, ‘pov_vision_head’: {‘grid’: (5, 5), ‘features_counts’: (32, 64, 128)}, ‘pov_coord_lists’: ‘pov_coord_lists:1:cls=2,0_526,49742’}, ‘pov_coords_encoding’: {‘frequencies_count’: 6, ‘inner_d_model’: 64, ‘is_combined’: True}|0.8924|

Сначала меня смутил низкий ssim, особенно на фоне предыдущих экспериментов. Даже после дообучения лучший был 0.9037. Возникла мысля, что это из-за хитроумного PovCoordsEncoding, который сразу и X, и Y смешивает в один эмбеддинг. Попробовал несколько эксперментов, где использовались различные эмбеддинги для X и Y (is_combined=False), также пробовал с гранулярными pov_coords (гранулярность 0.2, гранулярность исключает непрерывность, что делает изучение X,Y проще). Стало чуть получше, но не убедительно. После визуального просмотра обратил внимание на то, что модель плодит сразу несколько врагов в ряду. Т.е. как будто для неё выгодно в случае отсутствия информации нарисовать хоть что-то, т.к. это видимо просто снижает ошибку. Поэтому возникла мысль, что видимо в таком сетапе (рандомные pov_coords, нет общего контектса) м.б. лучше и не получить.

Ок. А что если совместить ob_vision_head и pov_vision_head, как собственно и задумывалось изначально? Это был эксп 18c_world_model_02/26, ssim=0.979.

Не сказать, чтобы был какой-то прорыв. Конечно, за счёт грамотной раскладки POV должно быть возможным вырасти ssim. Но это надо девелопировать foveal point selector либо хардкодтить. Стоит ли оно того?

Потом возникла мысль, а может быть и не нужны отдельные pov? Может просто хватит ob_vision_head на каждый из элементов сиквенса. Это, конечно, в каком-то роде декаденс, т.к. возвращает к тому сетапу, который был в №127. Правда там было 16х16х4=1024 токена, а здесь будет меньше. |эксперимент|сетка|токенов|ssim| |—|—|—|—| |18c_world_model_02/27|6x6|144|0.9757| |18c_world_model_02/29|7x7|196|0.9746| |18c_world_model_02/30|9x9|324|0.9814|

Потом следующая мысль! А может стерео зрение попробовать? Это когда один обзервейшн исследуется двумя CNN (2x178х178->6x6, 72 токена), но с разными смещениями по оси Х. Так же смотрим что лучше работает: когда одна CNN для лева и права (сильная регуляризация), или когда разные (выше гибкость). Был выточен 18c_study_01. Результаты: |эксперимент|offset|is_shared|ssim| |—|—|—|—| |18c_world_model_02/opt_01/60|1|F|0.9777| |18c_world_model_02/opt_01/56|2|F|0.9741| |18c_world_model_02/opt_01/57|3|F|0.9799| |18c_world_model_02/opt_01/52|4|F|0.9744| |18c_world_model_02/opt_01/54|5|F|0.9751| |18c_world_model_02/opt_01/59|1|T|0.9751| |18c_world_model_02/opt_01/55|2|T|0.9785| |18c_world_model_02/opt_01/51|3|T|0.9778| |18c_world_model_02/opt_01/58|4|T|0.9818| |18c_world_model_02/opt_01/62|5|T|0.9775|

Не, ну какое-то улучшение есть, по сравнению с тем, когда на один кадр одна CNN (один ob_vision_head). Вопрос только в цене: 32 токена против 72 (для 6х6).

Вообще упражняться тут долго можно:

1. ob_vision_head на последний кадр. На предыдущие кадры горизонтальные band-like CNN (9x1), чтобы точнее фиксировать горизонтальное движения
2. харкодное расположение pov_vision_head в заранее определённых местах
3. foveal point selector, как и задумывалось
4. и т.д.

Но, кажется, это немного отвлекает от главной задачи. А именно №126. Всё таки хочется научить агента проходить игру. Пока стало понятно, что надо заменять в агенте CNN, например, на 6х6. Короче, с новым опытом и наработками возвращаемся к агенту. Переделываем ему зрение, экспериментируем. Если будет не хватать, то можно вернуться к экспериментам world_model и найти ещё более оптимальную CNN. А если хватит и простой 6x6, то зачем усложнять?