Раз уж меня не срослось с выступлением на на хайлоадовской AiConf поделюсь чуть-чуть прогрессом, потому как рассказать неймётся. :)
Тренеруюсь тут подбирать гиперпараметры, на всё том же трансформере с гроккингом, При соблюдении должной аккуратности его даже без перестроения коннектома на уровне слоёв можно пожать ещё в полтора раза сильнее, примерно до 6тысяч весов от начальных 422тысяч, это x73 и на последних этапах сжатия веса модели убавляются уже буквально по одному, то есть 30 штучек удаляется, и 29 штук перспективных кандидатов возвращается обратно.
Всё это прекрасно и весело, но естественно задать вопрос, а на сколько этот трансформер был перепараметризован изначально? Напомню, задача состоит из ~10 тысяч примеров, из которых ровно половина в валидейшене - таблица остатков от деления размером 98*97, трансформер с внутренним эмбедингом 128 из двух слоёв, в общей сложности 422 тыс. весов.
Чисто по формальному математическому критерию перепараметризация наступает когда количество эффективных весов больше, чем количество примеров в выборке, но такое определение хорошо подходит только для доказательства теорем. Поэтому перейдём сразу к практике и начнём запускать бейзлайн уменьшая размер модели. И... если мы уменьшим внутренний эмбединг до 96, то модель ещё справляется и с трейном и с валом через гроккинг, Это ~200тыс весов, а вот 64 уже не вытягивает. Глубину тоже можно уменьшить до одного слоя и при эмбединге 128 она справится с задачей, а на 96 уже нет. Тоесть, как бы и перепараметризованная задачи и одновременно не так, чтобы сильно. Пляшем так или иначе где-то вокруг 200тысяч, меньшего размера плотная модель уже не тянет. А жёмтся при этом до 6 тыс. Грубо говоря в 10 раз по скорости (потому что спарс-матрицы x3 медленнее) и в 15 раз по памяти и шине (потому что индексы для спарсов можно хранить половинного размера как минимум).
P.S. Необходимо буквально тантрическое терпение, чтобы изучать все вот такие свойства разреженного обучения вместо того чтобы сразу броситься писать финальную версию кода... Даже хорошо, что я пока независимый исследователь, потому что никакому начальнику терпения бы не хватило...
P.P.S. Обратите внимания на стратегию прунинга с отращивание новых весов. Мне даёт результаты кратно лучшие чем обычный прунинг.
Тренеруюсь тут подбирать гиперпараметры, на всё том же трансформере с гроккингом, При соблюдении должной аккуратности его даже без перестроения коннектома на уровне слоёв можно пожать ещё в полтора раза сильнее, примерно до 6тысяч весов от начальных 422тысяч, это x73 и на последних этапах сжатия веса модели убавляются уже буквально по одному, то есть 30 штучек удаляется, и 29 штук перспективных кандидатов возвращается обратно.
Всё это прекрасно и весело, но естественно задать вопрос, а на сколько этот трансформер был перепараметризован изначально? Напомню, задача состоит из ~10 тысяч примеров, из которых ровно половина в валидейшене - таблица остатков от деления размером 98*97, трансформер с внутренним эмбедингом 128 из двух слоёв, в общей сложности 422 тыс. весов.
Чисто по формальному математическому критерию перепараметризация наступает когда количество эффективных весов больше, чем количество примеров в выборке, но такое определение хорошо подходит только для доказательства теорем. Поэтому перейдём сразу к практике и начнём запускать бейзлайн уменьшая размер модели. И... если мы уменьшим внутренний эмбединг до 96, то модель ещё справляется и с трейном и с валом через гроккинг, Это ~200тыс весов, а вот 64 уже не вытягивает. Глубину тоже можно уменьшить до одного слоя и при эмбединге 128 она справится с задачей, а на 96 уже нет. Тоесть, как бы и перепараметризованная задачи и одновременно не так, чтобы сильно. Пляшем так или иначе где-то вокруг 200тысяч, меньшего размера плотная модель уже не тянет. А жёмтся при этом до 6 тыс. Грубо говоря в 10 раз по скорости (потому что спарс-матрицы x3 медленнее) и в 15 раз по памяти и шине (потому что индексы для спарсов можно хранить половинного размера как минимум).
P.S. Необходимо буквально тантрическое терпение, чтобы изучать все вот такие свойства разреженного обучения вместо того чтобы сразу броситься писать финальную версию кода... Даже хорошо, что я пока независимый исследователь, потому что никакому начальнику терпения бы не хватило...
P.P.S. Обратите внимания на стратегию прунинга с отращивание новых весов. Мне даёт результаты кратно лучшие чем обычный прунинг.
👍6
Всем привет, у меня вопрос!
За последние два дня два раза поднимался вопрос, а есть ли какая-нибудь не слишком устаревшая, но при этом широко известная задача маленького размера, на которой можно было побаловаться трансформерами и посравниваться себя с другими, которая бы обучалась, например, за сутки и влезала в бытовую карту? Может кто знает/слышал? Или может быть какая-нибудь задачка на каггле, например, за последнее время всплывала с подходящими параметрами, чтобы было с кем себя сравнить?
- У Сбера есть бенчмарк публичный, для экспериментов с разными идеями, но там задача рассчитана на, примерно 200М весов, чтобы готовым результатом померяться это норм, но для быстрых домашних экспериментов многовато.
- Есть тот трансформер с гроккингом, на котором я балуюсь, он хорош тем, что совсем микроскопический время разных экспериментов всего от 4 минут до часа, но эта задача совсем вырожденная, последовательность всего из двух токенов состоит, так что для многих экспериментов она просто непригодна.
За последние два дня два раза поднимался вопрос, а есть ли какая-нибудь не слишком устаревшая, но при этом широко известная задача маленького размера, на которой можно было побаловаться трансформерами и посравниваться себя с другими, которая бы обучалась, например, за сутки и влезала в бытовую карту? Может кто знает/слышал? Или может быть какая-нибудь задачка на каггле, например, за последнее время всплывала с подходящими параметрами, чтобы было с кем себя сравнить?
- У Сбера есть бенчмарк публичный, для экспериментов с разными идеями, но там задача рассчитана на, примерно 200М весов, чтобы готовым результатом померяться это норм, но для быстрых домашних экспериментов многовато.
- Есть тот трансформер с гроккингом, на котором я балуюсь, он хорош тем, что совсем микроскопический время разных экспериментов всего от 4 минут до часа, но эта задача совсем вырожденная, последовательность всего из двух токенов состоит, так что для многих экспериментов она просто непригодна.
👍2
Forwarded from Vlad Goloshchapov
Российские школьники выиграли олимпиаду по искусственному интеллекту. Россияне были единственными людьми, кто выступал без флага "дабы разумением своим не смущать начальства".
🤡2🤔1🤣1
Постоянные читатели канала увидят больше половины доклада ещё до того, как я его до Новосибирска довезу.
Это, собственно, задача, которую решает трансформер - таблица остатков от деления в виде картинки. Хорошо видно, что много где в данных прослеживается понятная логика, грокнуть их, тобышь получить 100% acc на валидейшене, составляющем случайную половину этой картинки на первый взгляд нетривиально.
На второй взгляд можно заметить, что картинка симметричная, так что многим точкам из валидейшена соответствуют точки из трейна отличающиеся примерно ничем. Так что реальный валидейшен там далеко далеко не половина. Осталось выяснить,
Как бы не пришлось читать оригинальную статью гугловцев, чтобы узнать, есть ли у них эта "незначительная утечка", или это только в публичном ноутбуке такая фигня получилась...
Впрочем, на сжатие трансформера это не влияет, и способность при гроккинге обобщить поняв, что многие токены будучи представленными в виде float-ов тоже не так чтобы тривиально.
Это, собственно, задача, которую решает трансформер - таблица остатков от деления в виде картинки. Хорошо видно, что много где в данных прослеживается понятная логика, грокнуть их, тобышь получить 100% acc на валидейшене, составляющем случайную половину этой картинки на первый взгляд нетривиально.
На второй взгляд можно заметить, что картинка симметричная, так что многим точкам из валидейшена соответствуют точки из трейна отличающиеся примерно ничем. Так что реальный валидейшен там далеко далеко не половина. Осталось выяснить,
Как бы не пришлось читать оригинальную статью гугловцев, чтобы узнать, есть ли у них эта "незначительная утечка", или это только в публичном ноутбуке такая фигня получилась...
Впрочем, на сжатие трансформера это не влияет, и способность при гроккинге обобщить поняв, что многие токены будучи представленными в виде float-ов тоже не так чтобы тривиально.
Forwarded from tsymba❤️
Всем привет! На волне хайпа и по горячим следам написал про первый межнар по ИИ, который прошел в Болгарии буквально позавчера. Мне посчастливилось принимать участие в подготовке и организации; мой основной вклад состоял в разработке трети задач из научного раунда.
Куча постов ниже, а лонгрид — вот тут.
Куча постов ниже, а лонгрид — вот тут.
Telegraph
IOAI: a side story
Всем привет! На волне хайпа и по горячим следам написал про первый межнар по ИИ, который прошел в Болгарии буквально позавчера. Мне посчастливилось принимать участие в подготовке и организации; мой основной вклад состоял в разработке трети задач из научного…
👍2
А помните я говорил, что заглянул в данные, и с удивлением обнаружил, что задачка то симметричная, так что стоит сети об этой симметрии догадаться и выяснится, что половина валидации в трейне присутствует.
И, конечно, стало мне интересно, а что там с этим хвалёным гроккингом будет, если эту "утечку" в трейне устранить.
На самом деле это, конечно, же это не утечка, а наоборот самая маковка обобщения - заметить, что в данных присутствует центральная симметрия, но согласитесь без это симметрии задачка выглядит сразу сильно более сложной и впечатляющей.
Так вот, выясняется, что если взять в рассмотрение только половину данных, оставив, доступными только сложные обобщения, гроккинг тоже вполне себе заводится, но не так бодро - в четыре раза больше времени у него уходит чтобы распутать эту математику.
И, конечно, стало мне интересно, а что там с этим хвалёным гроккингом будет, если эту "утечку" в трейне устранить.
На самом деле это, конечно, же это не утечка, а наоборот самая маковка обобщения - заметить, что в данных присутствует центральная симметрия, но согласитесь без это симметрии задачка выглядит сразу сильно более сложной и впечатляющей.
Так вот, выясняется, что если взять в рассмотрение только половину данных, оставив, доступными только сложные обобщения, гроккинг тоже вполне себе заводится, но не так бодро - в четыре раза больше времени у него уходит чтобы распутать эту математику.
👍4🔥4
В Эфире рубрика "очумелые ручки". :)
Если выкрутить weight_decay отрицательный -0.2 например, так чтобы он не уменьшал, а увеличивал веса, то придя домой с работы можно обнаружить, что при train accuracy ~94% loss уползает куда-то в окрестности 6e+7.
Ну то есть 6% неправильно классифицированных семплов убегают куда-то на бесконечность, не сдерживаемые ничем и оставляя своих более удачливых коллег работать в этих зверский условиях.
Если выкрутить weight_decay отрицательный -0.2 например, так чтобы он не уменьшал, а увеличивал веса, то придя домой с работы можно обнаружить, что при train accuracy ~94% loss уползает куда-то в окрестности 6e+7.
Ну то есть 6% неправильно классифицированных семплов убегают куда-то на бесконечность, не сдерживаемые ничем и оставляя своих более удачливых коллег работать в этих зверский условиях.
🔥7🤔1🥴1
Было-Стало
Для опенсорсной библиотечки, которую буду показывать в октябре на новосибирском датафесете обобщил и причесал двухсторонние логарифмические графики, которые вы могли часто видеть в разных формах в моих докладах.
Это когда вам нужно показать каку-то-величину которая может меняться на порядки, но при этом и положительные и отрицательные значения вам для понимания нужны и желательно на одном графике.
Например, вы смотрите как изменение loss-а за десяток батчей зависит от выбранной lr. При слишком большой lr будут экстримально большие значения, котоыре вам взорвут весь график, но вам нужны только отрицательные значения и тенденция, а lr тоже меняется в широчайших пределах.
В этом случае я как бы склеиваю два отдельных логарифмических графика в одинаковом масштабе, помещая между ними виртуальный 0. На самом деле и нулевое значение там тоже быть может, и будет нарисовано на этой линии и информативно.
Казалось бы мелочь, но очень важная для понимания в некоторых случаях.
Для опенсорсной библиотечки, которую буду показывать в октябре на новосибирском датафесете обобщил и причесал двухсторонние логарифмические графики, которые вы могли часто видеть в разных формах в моих докладах.
Это когда вам нужно показать каку-то-величину которая может меняться на порядки, но при этом и положительные и отрицательные значения вам для понимания нужны и желательно на одном графике.
Например, вы смотрите как изменение loss-а за десяток батчей зависит от выбранной lr. При слишком большой lr будут экстримально большие значения, котоыре вам взорвут весь график, но вам нужны только отрицательные значения и тенденция, а lr тоже меняется в широчайших пределах.
В этом случае я как бы склеиваю два отдельных логарифмических графика в одинаковом масштабе, помещая между ними виртуальный 0. На самом деле и нулевое значение там тоже быть может, и будет нарисовано на этой линии и информативно.
Казалось бы мелочь, но очень важная для понимания в некоторых случаях.
👍10
Запустил прунинг MobileNetV4, чтобы несколько освежить свои демослайды. И вот спустя несколько часов озаботился вопросом, что лучше:
Anonymous Poll
43%
Написать папиру "Любую нейросеть, обученную батчами можно подтянуть ещё на 0.5% accuracy"🙊
30%
Заколлабиться со всеми командами без разбору и выиграть все соревнования на Kaggle?🤣
27%
Просто посмотреть результаты, а ты слишком много о себе возомнил.
Я думал, что ошибка где-то у меня, но оказалось что PIL и декодер от nvidia, который декодирует JPEG прямо в видиопамяти, доступный через torchvision.io.decode_jpeg, дают чуть-чуть разную картинку. На одну-две единички на байт цвета, но воспроизводимость это руинит начисто.
Большинство дайтасайнтистов хорошего програмистского бэкграунда не имеет, и всякие такие мелочи успешно игнорирует в результате копятся не только такие разночтения, которые, в принципе, ожидаемы, но и буквально ошибки, на которые все могут забивать годами. Печалька...
Большинство дайтасайнтистов хорошего програмистского бэкграунда не имеет, и всякие такие мелочи успешно игнорирует в результате копятся не только такие разночтения, которые, в принципе, ожидаемы, но и буквально ошибки, на которые все могут забивать годами. Печалька...
🥴3👍2
accuracy: 0.7270, 0.7278, а должно быть 73.454, спрашивается, что ещё пошло не так...
image_2024-09-23_21-11-25.png
968.6 KB
Я сделал это! И результат расследования нифига не радует... tensor(0.7348) - Это уже в пределах особенностей декодера jpeg от желаемого 73.454
И теперь мне придётся пересчитывать все свои результаты ради того чтобы вернуть безупречность своим предыдущим данным и выводам.
Потому что чем для вас отличаются две вот эти картинки? На первый взгляд ничем, я, по крайней мере, на взгляд отличить не могу, даже с применением стереотехник, но они отличаются степенью сжатия jpeg-а, и MobileNetV4 классифицирует их по разному. И это всё, что нужно знать про устойчивость современных CV сетей...
P.S. Чуть не забыл у Телеграмма снять галочку "Сжать изображение", а то ещё и Телеграм бы досыпал своих артефактов в нашу и так безрадостную картину...
P.P.S. Справа: Линь - 0.8561, Осётр - 0.0645, Игуана - 0.0105, Слева: Осётр - 0.3995, Линь - 0.1318, Комодский варан - 0.1293
И теперь мне придётся пересчитывать все свои результаты ради того чтобы вернуть безупречность своим предыдущим данным и выводам.
Потому что чем для вас отличаются две вот эти картинки? На первый взгляд ничем, я, по крайней мере, на взгляд отличить не могу, даже с применением стереотехник, но они отличаются степенью сжатия jpeg-а, и MobileNetV4 классифицирует их по разному. И это всё, что нужно знать про устойчивость современных CV сетей...
P.S. Чуть не забыл у Телеграмма снять галочку "Сжать изображение", а то ещё и Телеграм бы досыпал своих артефактов в нашу и так безрадостную картину...
P.P.S. Справа: Линь - 0.8561, Осётр - 0.0645, Игуана - 0.0105, Слева: Осётр - 0.3995, Линь - 0.1318, Комодский варан - 0.1293
😱4👍2😢1
Подготовка данных как в лучших домах ландона и парижу...
Поскольку скомпрометирован оказался мой датасет, тащу себе домой официальнейший имиджнет скачаный отсюда: https://www.kaggle.com/c/imagenet-object-localization-challenge
Эпоха на четверть длиннее, но чем не пожертвуешь ради воспроизводимости. В какой-то момент пайплан ломается. Трачу пол дня чтобы понять в чём дело, оказывается, среди картинок присутствуют серые картинки с одним цветовым каналом. Прикиньте дебагать и исправлять ошибку когда каждый тестовый запуск занимает до часа времени. Ну ок, добавлю expand до трёх каналов. Запускаю, уезжаю. по делам. Возвращаюсь, опять всё лежит. На этот раз ломается NVIDIA-вский декодер JPEG-а в видеопамяти с невразумительной ошибкой. Опять обмазываюсь логами. Напоминаю, каждый тестовый запуск матожидание пол часа. Пофиг, втыкаю try и в случае exception-a гружу традиционным PIL-ом. Падает. Хотя не должно бы.Добавляем логов, выясняется, что у картинки 4 цветовых канала, "чё?" спрашивается в задачнике. Предположите в чём подвох прежде чем читать дальше.
.
.
.
.
.
Смотрим свойства, а там реально 4 канала. Расширение картинки JPEG, а внутри лежит PNG.
Вот, почему так ценятся хорошие бейзлайны, в которых уже всё худо-беджно работает. Если бы оно ещё не так медленно работало...
Поскольку скомпрометирован оказался мой датасет, тащу себе домой официальнейший имиджнет скачаный отсюда: https://www.kaggle.com/c/imagenet-object-localization-challenge
Эпоха на четверть длиннее, но чем не пожертвуешь ради воспроизводимости. В какой-то момент пайплан ломается. Трачу пол дня чтобы понять в чём дело, оказывается, среди картинок присутствуют серые картинки с одним цветовым каналом. Прикиньте дебагать и исправлять ошибку когда каждый тестовый запуск занимает до часа времени. Ну ок, добавлю expand до трёх каналов. Запускаю, уезжаю. по делам. Возвращаюсь, опять всё лежит. На этот раз ломается NVIDIA-вский декодер JPEG-а в видеопамяти с невразумительной ошибкой. Опять обмазываюсь логами. Напоминаю, каждый тестовый запуск матожидание пол часа. Пофиг, втыкаю try и в случае exception-a гружу традиционным PIL-ом. Падает. Хотя не должно бы.Добавляем логов, выясняется, что у картинки 4 цветовых канала, "чё?" спрашивается в задачнике. Предположите в чём подвох прежде чем читать дальше.
.
.
.
.
.
Смотрим свойства, а там реально 4 канала. Расширение картинки JPEG, а внутри лежит PNG.
Вот, почему так ценятся хорошие бейзлайны, в которых уже всё худо-беджно работает. Если бы оно ещё не так медленно работало...
😁4👍1
О пользе двухсторонних логарифмических графиков, которые входят в библиотечку и о которых я буду рассказывать на на датафесте в Н-ске через две недели.
Здесь по горизонтали скорость обучения - lr, а по вертикали - как изменится loss и accuracy на валидейшене после одного единственного шага градиентного спуска на основе градиентов, вычисленных на всём ImageNet. Сеть - уже обученная MobileNetV4. Невооружённым взглядом виден диапазон скоростей, в котором сеть можно эффективно доучивать, видно, что скорость больше определённой разваливает сеть в клочья, и ещё одно малоизвестное явление - скорость ниже определённой так же портит loss. Я прадполагаю это потому что из-за дискретности float32 слишком малое изменение весов и-за неизбежных округлений создаёт шума больше пользы.
Все оси логарифмические, но на график искусственно прилеплен 0 и удобно отображаются как положительные так и отрицательные значения в одинаковом масштабе.
Единственное что плохо - из-за того же логарифмического масштаба требуется задумываться чтобы понимать на сколько на самом деле одно значение хуже другого.
Отдельное интересное - то на сколько loss портят слишком маленькие значения скорости. Но при обучении батчами такое явление не на столько явно себя проявляет.
Готовьтесь качать библиотечку и напихивать двусторонние логарифмические графики всюду. :) Здесь в канале она будет выложена несколько раньше феста.
Здесь по горизонтали скорость обучения - lr, а по вертикали - как изменится loss и accuracy на валидейшене после одного единственного шага градиентного спуска на основе градиентов, вычисленных на всём ImageNet. Сеть - уже обученная MobileNetV4. Невооружённым взглядом виден диапазон скоростей, в котором сеть можно эффективно доучивать, видно, что скорость больше определённой разваливает сеть в клочья, и ещё одно малоизвестное явление - скорость ниже определённой так же портит loss. Я прадполагаю это потому что из-за дискретности float32 слишком малое изменение весов и-за неизбежных округлений создаёт шума больше пользы.
Все оси логарифмические, но на график искусственно прилеплен 0 и удобно отображаются как положительные так и отрицательные значения в одинаковом масштабе.
Единственное что плохо - из-за того же логарифмического масштаба требуется задумываться чтобы понимать на сколько на самом деле одно значение хуже другого.
Отдельное интересное - то на сколько loss портят слишком маленькие значения скорости. Но при обучении батчами такое явление не на столько явно себя проявляет.
Готовьтесь качать библиотечку и напихивать двусторонние логарифмические графики всюду. :) Здесь в канале она будет выложена несколько раньше феста.
🔥9👍1👀1