ReMoE: Fully Differentiable Mixture-of-Experts with ReLU Routing
китайцы сделали интересное нововведение для МоЕ, которую мы не так уж и часто упоминали (и еще чуть-чуть здесь)
обычно используется как классика ТопК над софтмаксом (который в последнее время используется и в разреженных автоэнкодерах), и вот в этом как раз заключается загвоздка по заверениям авторов, ибо топ-к сильно так ограничивает по бекворду обновление сетки и количество активированных экспертов всегда одинаково
потому авторы решили заменить это на релу → получаем (почти) дифференцируемый оператор выбора экспертов, да и к тому же при каждом форварде это количество экспертов нефиксировано
но релу сама по себе не обеспечивает разреженности, потому на обучении пришлось добавить л1 регуляризацию + коэффициент к ней адаптивный и высчитывается в соответствии с понятиями average sparsity & target sparsity
- average sparsity высчитывается на каждом степе (ну или раз в N степов) и определяется просто через количество нулевых релу активаций
- а target sparsity задается через гиперпараметры. да, количество экспертов при каждом запуске модели правда динамичное, но мы все равно должны задавать сколько примерно экспертов должно быть активировано, иначе ниче не получится (можеть быть и момент в котором статья не является breathtaking)
- так же они еще добавили эксперименты о том как в эту регуляризацию добавили Load Balancing, чтобы инпуты равномерно разделялись между экспертами, через аналогичное высчитывание средней активации по отношению к целевой. но на экспах (и оч небольшом скейле) load balancing может появляться и без этого
по экспам трудно что-то сказать, ибо все до 1б параметров, но хотя бы тут выигрывает. в принципе пейпер отличителен всякими прикольными замечаниями, которые подтверждают интуитивное понимание аллоцирования динамического количества экспертов во время форварда - естественным образом во время обучения сначала все эксперты активируются, потом разреженность повышается и достигает таргета в конечном счет + так же естественно количество активирующихся экспертов повышается со снижением частоты токена (авторы проводят аналогию с деревом Хаффмана, где нужна меньшая длина для кодировки более частого объекта)
👀LINK
китайцы сделали интересное нововведение для МоЕ, которую мы не так уж и часто упоминали (и еще чуть-чуть здесь)
обычно используется как классика ТопК над софтмаксом (который в последнее время используется и в разреженных автоэнкодерах), и вот в этом как раз заключается загвоздка по заверениям авторов, ибо топ-к сильно так ограничивает по бекворду обновление сетки и количество активированных экспертов всегда одинаково
потому авторы решили заменить это на релу → получаем (почти) дифференцируемый оператор выбора экспертов, да и к тому же при каждом форварде это количество экспертов нефиксировано
но релу сама по себе не обеспечивает разреженности, потому на обучении пришлось добавить л1 регуляризацию + коэффициент к ней адаптивный и высчитывается в соответствии с понятиями average sparsity & target sparsity
- average sparsity высчитывается на каждом степе (ну или раз в N степов) и определяется просто через количество нулевых релу активаций
- а target sparsity задается через гиперпараметры. да, количество экспертов при каждом запуске модели правда динамичное, но мы все равно должны задавать сколько примерно экспертов должно быть активировано, иначе ниче не получится (можеть быть и момент в котором статья не является breathtaking)
- так же они еще добавили эксперименты о том как в эту регуляризацию добавили Load Balancing, чтобы инпуты равномерно разделялись между экспертами, через аналогичное высчитывание средней активации по отношению к целевой. но на экспах (и оч небольшом скейле) load balancing может появляться и без этого
по экспам трудно что-то сказать, ибо все до 1б параметров, но хотя бы тут выигрывает. в принципе пейпер отличителен всякими прикольными замечаниями, которые подтверждают интуитивное понимание аллоцирования динамического количества экспертов во время форварда - естественным образом во время обучения сначала все эксперты активируются, потом разреженность повышается и достигает таргета в конечном счет + так же естественно количество активирующихся экспертов повышается со снижением частоты токена (авторы проводят аналогию с деревом Хаффмана, где нужна меньшая длина для кодировки более частого объекта)
👀LINK
Lightning Attention-2: A Free Lunch for Handling Unlimited Sequence Lengths in Large Language Models
помимо дипсика и квена, недавно успели еще китайцы выкатить очередную ллм - минимакс, уже по традиции которая является МоЕ + вводит гибрид софтмакс и линейного аттеншнов (кстати о махинациях с аттеншном мы уже ни раз писали)
при том второй аттеншн не абы какой, а лайтнинг (не тот слава Богу). в минимаксе используется первая версия, а почти одновременно с этой моделькой успела выйти и вторая версия
в чем вообще суть - вот у нас есть
softmax(Q @ K^T) @ V, где иннер продукт между запросами и ключами выдает матрицу seq_len x seq_len, что довольно много
→ приходит в голову идея линеаризовать аттеншн, то есть делаем просто из softmax(Q @ K^T) ~= phi(Q) @ phi(K^T) ⇒ [phi(Q) @ phi(K^T)] @ V, что можно переписать как из left product в right product
phi(Q) @ [ phi(K^T) @ V ], где не будем напрямую высчитывать seq_len x seq_len матрицу, а будет только hidden_dim x hidden_dim. profit?
не совсем, когда в дело приходит понятие каузальности, ибо тогда формула становится (phi убрал для удобства) снова left product
[Q @ K^T * causal_mask] @ V
снова получаем seq_len x seq_len момент, это дело можно исправить алгоритмом Linear Attention Right Product (на предпоследней фотке), но тогда встревает кумулятивная сумма, которую не распараллелить
ну и авторы довольно красивое решение предлагают в виде того, что как раз и называется Lightning Attention
- во-первых, го вычислять аттеншн по блокам, по которым и будет идти цикл как обычно
- а в каждом блоке будем одновременно вычислять аттеншны и первым, и вторым способом: через left product с каузальной маской будет вычисляться intra block (как я понял потому что он находится рядом с диагональными элементами как раз, где и нужна каузальная маска), а через right product inter block (который/которые не соприкасаются с диагональю и можно без каузальной маски их использовать, да еще и этот блок вычислить можно через накопленную кумулятивную сумму KV), а в конце просто просуммируем, не забыв обновить KV
- тут получаем трейдофф между лево- и правоматричным умножениями, который еще и к тому же нетяжело под хардвейр оптимизировать - перетаскивать поочередно блоки между High Bandwidth Memory & SRAM (последняя картинка для иллюстрации отсюда, по всем правилам - чем больше по памяти вмещается, тем медленее работает)
вторая же версия отличается тем, что в каузальную маску добавляется гипер, контролирующий меру затухания информации между токенами (похожее делали в ретнете и второй мамбе), по формулам конечно присутствует не только в маске для сохранения контистенси в реккурентных выражениях (хоть этот вариант алгоритма был и в первой версии в аппендиксе)
реализовано все на тритоне, метод в принципе применим не только к их ТрансНормеру
👀 link, code
помимо дипсика и квена, недавно успели еще китайцы выкатить очередную ллм - минимакс, уже по традиции которая является МоЕ + вводит гибрид софтмакс и линейного аттеншнов (кстати о махинациях с аттеншном мы уже ни раз писали)
при том второй аттеншн не абы какой, а лайтнинг (не тот слава Богу). в минимаксе используется первая версия, а почти одновременно с этой моделькой успела выйти и вторая версия
в чем вообще суть - вот у нас есть
softmax(Q @ K^T) @ V, где иннер продукт между запросами и ключами выдает матрицу seq_len x seq_len, что довольно много
→ приходит в голову идея линеаризовать аттеншн, то есть делаем просто из softmax(Q @ K^T) ~= phi(Q) @ phi(K^T) ⇒ [phi(Q) @ phi(K^T)] @ V, что можно переписать как из left product в right product
phi(Q) @ [ phi(K^T) @ V ], где не будем напрямую высчитывать seq_len x seq_len матрицу, а будет только hidden_dim x hidden_dim. profit?
не совсем, когда в дело приходит понятие каузальности, ибо тогда формула становится (phi убрал для удобства) снова left product
[Q @ K^T * causal_mask] @ V
снова получаем seq_len x seq_len момент, это дело можно исправить алгоритмом Linear Attention Right Product (на предпоследней фотке), но тогда встревает кумулятивная сумма, которую не распараллелить
ну и авторы довольно красивое решение предлагают в виде того, что как раз и называется Lightning Attention
- во-первых, го вычислять аттеншн по блокам, по которым и будет идти цикл как обычно
- а в каждом блоке будем одновременно вычислять аттеншны и первым, и вторым способом: через left product с каузальной маской будет вычисляться intra block (как я понял потому что он находится рядом с диагональными элементами как раз, где и нужна каузальная маска), а через right product inter block (который/которые не соприкасаются с диагональю и можно без каузальной маски их использовать, да еще и этот блок вычислить можно через накопленную кумулятивную сумму KV), а в конце просто просуммируем, не забыв обновить KV
- тут получаем трейдофф между лево- и правоматричным умножениями, который еще и к тому же нетяжело под хардвейр оптимизировать - перетаскивать поочередно блоки между High Bandwidth Memory & SRAM (последняя картинка для иллюстрации отсюда, по всем правилам - чем больше по памяти вмещается, тем медленее работает)
вторая же версия отличается тем, что в каузальную маску добавляется гипер, контролирующий меру затухания информации между токенами (похожее делали в ретнете и второй мамбе), по формулам конечно присутствует не только в маске для сохранения контистенси в реккурентных выражениях (хоть этот вариант алгоритма был и в первой версии в аппендиксе)
реализовано все на тритоне, метод в принципе применим не только к их ТрансНормеру
👀 link, code
Forwarded from NLP Wanderer
О неочевидном поведении DPO и улучшениях SMPO в новой SLM от VIkhrModels
Недавно вышедшая QVikhr-2.5-1.5B-Instruct-SMPO, отличается не только лучшим качеством среди наших небольших тюнов, сопоставимым местами с 7B моделями, но и улучшениями в нашем методе алайнмента SMPO.
В ходе большого количества экспериментов я заметил, что офлайновая DPO-like (любая, в том числе и SMPO, ORPO, SimPO и тд) тренировка, часто при обучении может приводить к вырожденным решениям, например, таким, где модель теряет EOS токен при генерации и уходит в повторения или просто в генерацию сломанных токенов.
После небольшого расследования выяснилось, что частично такое поведение объяснимо поведением логарифма при вычислении логпробов токенов (картинка 1), которые в свою очередь участвуют в вычислении ревордов, разница между которыми и оптимизируется в DPO. Вычисляя логарифм чисел в районе 0, вы легко можете получить неограниченное падение логпроба в минус бесконечность. В случае DPO вы эти логпробы потом складываете, в случае SMPO они усредяются по всему комплишену. И в том и в другом случае, вы не спасаетесь от возможных значений-выбросов на конкретных токенах.
Если говорить более простыми словами - если ваш rejected содержит какието очевидные закономерности в токенах, которые его отличают от chosen, то модель через DPO может научится занижать логпробы именно этих токенов в минус бесконечность (т.е. обнулять вероятность) и выигрывать тем самым objective DPO, при этом для более "умных" последовательностей токенов, которые вы хотели бы тоже выучить, оптимизация может вобще не произойти, приводя к довольно тупым результатам, частое из которых это занизить логпроб EOS токена на всех rejected, тем самым почти уничтожив вероятность его генерации на OOD примерах - получаем проблему бесконечных повторений.
Конечно, такое поведение связано с плохой регуляризацией в RL. Выбор меньшего lr, уменьшение гипермараметра beta (в dpo), использование KL (как в DPO) или rejected и chosen SFT амортизации (как в SMPO), лучший выбор модели (какие-то меньше подвержены), использование model merging между SFT и PO стадиями тренировки, в целом обучение не до конца, частично помогает бороться с таким хаком обжектива. При тренировке Vikhr-Nemo было проведено немало экспериментов с гиперпараметрами, но проблема не была полностью вылечена.
В итоге, для тренировки наших следующих моделей мы теперь используем модифицированную версию SMPO (картинка 2), в которой было решено ввести штраф на занижение EOS токена для rejected комплишенов, а также сделать винзоризацию и клиппинг экстремальных значений логпробов, что позволило частично решить проблему нежелательного переобучения.
Модифицированный SMPO и конфиги обучения уже доступны в нашей библиотеке Effective LLM Alignment
Недавно вышедшая QVikhr-2.5-1.5B-Instruct-SMPO, отличается не только лучшим качеством среди наших небольших тюнов, сопоставимым местами с 7B моделями, но и улучшениями в нашем методе алайнмента SMPO.
В ходе большого количества экспериментов я заметил, что офлайновая DPO-like (любая, в том числе и SMPO, ORPO, SimPO и тд) тренировка, часто при обучении может приводить к вырожденным решениям, например, таким, где модель теряет EOS токен при генерации и уходит в повторения или просто в генерацию сломанных токенов.
После небольшого расследования выяснилось, что частично такое поведение объяснимо поведением логарифма при вычислении логпробов токенов (картинка 1), которые в свою очередь участвуют в вычислении ревордов, разница между которыми и оптимизируется в DPO. Вычисляя логарифм чисел в районе 0, вы легко можете получить неограниченное падение логпроба в минус бесконечность. В случае DPO вы эти логпробы потом складываете, в случае SMPO они усредяются по всему комплишену. И в том и в другом случае, вы не спасаетесь от возможных значений-выбросов на конкретных токенах.
Если говорить более простыми словами - если ваш rejected содержит какието очевидные закономерности в токенах, которые его отличают от chosen, то модель через DPO может научится занижать логпробы именно этих токенов в минус бесконечность (т.е. обнулять вероятность) и выигрывать тем самым objective DPO, при этом для более "умных" последовательностей токенов, которые вы хотели бы тоже выучить, оптимизация может вобще не произойти, приводя к довольно тупым результатам, частое из которых это занизить логпроб EOS токена на всех rejected, тем самым почти уничтожив вероятность его генерации на OOD примерах - получаем проблему бесконечных повторений.
Конечно, такое поведение связано с плохой регуляризацией в RL. Выбор меньшего lr, уменьшение гипермараметра beta (в dpo), использование KL (как в DPO) или rejected и chosen SFT амортизации (как в SMPO), лучший выбор модели (какие-то меньше подвержены), использование model merging между SFT и PO стадиями тренировки, в целом обучение не до конца, частично помогает бороться с таким хаком обжектива. При тренировке Vikhr-Nemo было проведено немало экспериментов с гиперпараметрами, но проблема не была полностью вылечена.
В итоге, для тренировки наших следующих моделей мы теперь используем модифицированную версию SMPO (картинка 2), в которой было решено ввести штраф на занижение EOS токена для rejected комплишенов, а также сделать винзоризацию и клиппинг экстремальных значений логпробов, что позволило частично решить проблему нежелательного переобучения.
Модифицированный SMPO и конфиги обучения уже доступны в нашей библиотеке Effective LLM Alignment
🔥6
Vintix: Action Model via In-Context Reinforcement Learning
не дипсиком единым жив рл, а всем исходящем из дуно живет отечественный In-Context RL
и авторы на сей раз решили сделать генералист агента как раз под ин-контекст рл. при том это актуально не только с точки зрения генералист агентов, ибо они по перформансу пока довольно далеки от чего-то разрывного, но и для ин-контекст рл, поскольку такая область пока ограничивается довольно игрушечными примерами в основном и одним доменом, внутри которого и происходит вариация в тасках
и из этого и рождается винтикс на основе ДимДимычей в виде AD, TinyLLaMa (откуда много из архитектуры бралось) и частично JAT (стоит упомянуть, что основной автор этого агента сейчас в основном занимается в хф трл и опен-р1)
в общей сумме тренились на 87 тасках в симуляторах (что очень мало для ин-контекст рл, где это количество от сотен до тысяч)
- двуручном роботе
- муджоко
- мета-ворлд
- индустриальном бенчмарке, где задачи по типу контроля промышленных турбин
поскольку акншы и обсервейшны в этих симуляторах разные, то для каждого использовались отдельные энкодеры/декодеры, чтобы подгонять под нужную размерность для трансформера + насколько я понял, каждый батч - семплы из одной среды (как это было сделано и в JAT)
данные собирали при помощи расшумления траекторий от политик ппо или взятых с JAT + обобщили эту идею на непрерывные действия
- посколькуо в изначальной папире этот метод предлагался в дискретном пространстве → реализовывался epsilon-greedy алгоритм, где действия политики сразу были оптимальны (был взят оракул)
- то здесь пришлось линейно интерполировать каждый раз между действием полиси и рандомным вектором. но при том сам коэффициент влияния шума пришлось подбирать нелинейным способом, чтобы уже в таких более-менее сложных задачах траектории обучения как датасет был “гладким”
тренировали каузальный трансформер в 300М параметров на 8 картах, что для рл сейчас более-менее. по итогу что-то да получилось - на трейн тасках есть прогресс получше JAT (где это уместно сравнивать) + если варьировать в трейн тасках конфигурацию среды (например в муджоко потыкать гравитацию или уровень вязкости), то агент может адаптироваться к таким изменениям, что довольно круто (авторы назвали это self-correction, в последнее время это слово часто всплывает)
когда речь доходит до тестовых тасок, которые вообще агент никак видеть не мог, то здесь становится погрустнее история. авторы связывают это с недостаточным скейлом (а ведь в первую очередь из-за него и появляются фаундейшн модели), который на самом деле и не настолько мал, но все равно видимо оказывается недостаточен (что коррелирует с фаундейшн в роботике)
👀 link, code coming soon (датасет тоже планируют релизить)
не дипсиком единым жив рл, а всем исходящем из дуно живет отечественный In-Context RL
и авторы на сей раз решили сделать генералист агента как раз под ин-контекст рл. при том это актуально не только с точки зрения генералист агентов, ибо они по перформансу пока довольно далеки от чего-то разрывного, но и для ин-контекст рл, поскольку такая область пока ограничивается довольно игрушечными примерами в основном и одним доменом, внутри которого и происходит вариация в тасках
и из этого и рождается винтикс на основе ДимДимычей в виде AD, TinyLLaMa (откуда много из архитектуры бралось) и частично JAT (стоит упомянуть, что основной автор этого агента сейчас в основном занимается в хф трл и опен-р1)
в общей сумме тренились на 87 тасках в симуляторах (что очень мало для ин-контекст рл, где это количество от сотен до тысяч)
- двуручном роботе
- муджоко
- мета-ворлд
- индустриальном бенчмарке, где задачи по типу контроля промышленных турбин
поскольку акншы и обсервейшны в этих симуляторах разные, то для каждого использовались отдельные энкодеры/декодеры, чтобы подгонять под нужную размерность для трансформера + насколько я понял, каждый батч - семплы из одной среды (как это было сделано и в JAT)
данные собирали при помощи расшумления траекторий от политик ппо или взятых с JAT + обобщили эту идею на непрерывные действия
- посколькуо в изначальной папире этот метод предлагался в дискретном пространстве → реализовывался epsilon-greedy алгоритм, где действия политики сразу были оптимальны (был взят оракул)
- то здесь пришлось линейно интерполировать каждый раз между действием полиси и рандомным вектором. но при том сам коэффициент влияния шума пришлось подбирать нелинейным способом, чтобы уже в таких более-менее сложных задачах траектории обучения как датасет был “гладким”
тренировали каузальный трансформер в 300М параметров на 8 картах, что для рл сейчас более-менее. по итогу что-то да получилось - на трейн тасках есть прогресс получше JAT (где это уместно сравнивать) + если варьировать в трейн тасках конфигурацию среды (например в муджоко потыкать гравитацию или уровень вязкости), то агент может адаптироваться к таким изменениям, что довольно круто (авторы назвали это self-correction, в последнее время это слово часто всплывает)
когда речь доходит до тестовых тасок, которые вообще агент никак видеть не мог, то здесь становится погрустнее история. авторы связывают это с недостаточным скейлом (а ведь в первую очередь из-за него и появляются фаундейшн модели), который на самом деле и не настолько мал, но все равно видимо оказывается недостаточен (что коррелирует с фаундейшн в роботике)
👀 link, code coming soon (датасет тоже планируют релизить)
❤6
FAST: Efficient Action Tokenization for Vision-Language-Action Models
зачем-то physical intelligence, которые делали pi0, себе второй домен забабахали pi.website, на котором запостили как они сделали токенизатор для робо действий
зачем? в принципе трансформер и оперирует в каждом своем слое над дискретными элементами (каждая голова каждого слоя интуитивно проталкивает только определенные токены дальше по сетке), а в роботике часто надо выпуливать многомерные непрерывные действия, так еще часто и с высокой частотой, а если еще пытаться решить достаточно сложную таску, то такую особенность становится невозможно игнорировать
ну и физикал интеллиженс пытался это решить как раз через флоу матчинг в прошлый раз, что более-менее и получилось (с нюансами), но они проработали и альтернативу в виде FAST
при том идея хороша тем, что построена она из привычных рабочих техник
- надо бы как-то эффективно сжимать временные ряды действий. можно бинаризовать - ок, но в случае высокой герцовки робота получается все больше бинов за все меньшее количество времени → медленный инференс. но можно вспомнить (или просто почитать предположение авторов), что траектории действий во времени являются все-таки гладкими, а значит и это можно использовать для компрессии
- lets go to the Discrete Cosine Transform! да, вот такой переход потому что это уже своего рода классика: будем получать наибольшее количество информации в низких частотах, а значит и можно будет сжимать очень многие высокие частоты)
- получим матрицу для каждого action chunk (о важности чего мы упоминали здесь), которую нам неплохо было бы представить в виде последовательности, чтобы потом использовать БПЕ (потому что скорее всего это тоже привычно и довольно удобно) → давайте флаттенить, да при том чтобы низкие частоты были в начале последовательности, а высокие (незначительные) в конце + допом сделаем scale-and-round операцию чтобы округлить до нулей все незначимое
- тогда и можно запускать бпе бррррр
примечательно еще то, что как будто такая идея может и расширяться за пределы обработки действий (а в принципе многомерных временных рядов)
по результатам он даже обгоняет первую версию их pi-модели с флоу матчингом. то есть (имхо) авторы пытаются дать эвиденс о том, что стоит по максимуму токенизировать все что только можно при работе с трансформерами прежде чем приступать к флоу матчингу (даже с трюками авторов по типу бета распределения версия с токенизатором обгоняет по результату, подтвердили на экспах где обучали оба метода до сходимости и где уравнивали бюджет компьюта)
при том это настолько хорошо вкладывается в пайплайн физикал интеллиженса, что они утверждают о возможности зеро-шота на DROID + там где происходит фейл на эпизоде, полиси делает не вообще полностью что-то рандомное
теперь к вопросам, которые появились
- перед DCT происходит нормализация в рейндж от - 1 до 1 на основе статистик датасета по первой и 99 квантили. FAST+, который они выпустили в опенсурс построен аналогичным путем и заявляет о своей универсальности. звучит немного странно с учетом такой нормализации. да, их датасет основан на многих роботах + 1млн траекторий
- но это все равно как будто слишком уникальное дело по поводу токенизации акншнов для робота + так же в экспериментах они говорят об низкой чувствительности к scale параметру перед округлением и вокаб сайзом для БПЕ → выбирают 10 и 1024. как будто второе число довольно-таки мало (особенно сравнивая с вокаб сайзом для лмок что не очень честно но хоть что-то), чтобы с удобоваримым пресижном сжимать действия,
но может я чего-то не понимаю в этой жизни и это довольно-таки интересный инсайт о природе рободействий в нашей реальности
👀 link, демки, code вроде выложили но там нету самой процедуры обучения токенизатора
зачем-то physical intelligence, которые делали pi0, себе второй домен забабахали pi.website, на котором запостили как они сделали токенизатор для робо действий
зачем? в принципе трансформер и оперирует в каждом своем слое над дискретными элементами (каждая голова каждого слоя интуитивно проталкивает только определенные токены дальше по сетке), а в роботике часто надо выпуливать многомерные непрерывные действия, так еще часто и с высокой частотой, а если еще пытаться решить достаточно сложную таску, то такую особенность становится невозможно игнорировать
ну и физикал интеллиженс пытался это решить как раз через флоу матчинг в прошлый раз, что более-менее и получилось (с нюансами), но они проработали и альтернативу в виде FAST
при том идея хороша тем, что построена она из привычных рабочих техник
- надо бы как-то эффективно сжимать временные ряды действий. можно бинаризовать - ок, но в случае высокой герцовки робота получается все больше бинов за все меньшее количество времени → медленный инференс. но можно вспомнить (или просто почитать предположение авторов), что траектории действий во времени являются все-таки гладкими, а значит и это можно использовать для компрессии
- lets go to the Discrete Cosine Transform! да, вот такой переход потому что это уже своего рода классика: будем получать наибольшее количество информации в низких частотах, а значит и можно будет сжимать очень многие высокие частоты)
- получим матрицу для каждого action chunk (о важности чего мы упоминали здесь), которую нам неплохо было бы представить в виде последовательности, чтобы потом использовать БПЕ (потому что скорее всего это тоже привычно и довольно удобно) → давайте флаттенить, да при том чтобы низкие частоты были в начале последовательности, а высокие (незначительные) в конце + допом сделаем scale-and-round операцию чтобы округлить до нулей все незначимое
- тогда и можно запускать бпе бррррр
примечательно еще то, что как будто такая идея может и расширяться за пределы обработки действий (а в принципе многомерных временных рядов)
по результатам он даже обгоняет первую версию их pi-модели с флоу матчингом. то есть (имхо) авторы пытаются дать эвиденс о том, что стоит по максимуму токенизировать все что только можно при работе с трансформерами прежде чем приступать к флоу матчингу (даже с трюками авторов по типу бета распределения версия с токенизатором обгоняет по результату, подтвердили на экспах где обучали оба метода до сходимости и где уравнивали бюджет компьюта)
при том это настолько хорошо вкладывается в пайплайн физикал интеллиженса, что они утверждают о возможности зеро-шота на DROID + там где происходит фейл на эпизоде, полиси делает не вообще полностью что-то рандомное
теперь к вопросам, которые появились
- перед DCT происходит нормализация в рейндж от - 1 до 1 на основе статистик датасета по первой и 99 квантили. FAST+, который они выпустили в опенсурс построен аналогичным путем и заявляет о своей универсальности. звучит немного странно с учетом такой нормализации. да, их датасет основан на многих роботах + 1млн траекторий
- но это все равно как будто слишком уникальное дело по поводу токенизации акншнов для робота + так же в экспериментах они говорят об низкой чувствительности к scale параметру перед округлением и вокаб сайзом для БПЕ → выбирают 10 и 1024. как будто второе число довольно-таки мало (особенно сравнивая с вокаб сайзом для лмок что не очень честно но хоть что-то), чтобы с удобоваримым пресижном сжимать действия,
но может я чего-то не понимаю в этой жизни и это довольно-таки интересный инсайт о природе рободействий в нашей реальности
👀 link, демки, code вроде выложили но там нету самой процедуры обучения токенизатора