Вы когда-нибудь путались в функциях потерь для классификации? BCE, log-loss, Cross Entropy, Focal Loss — одно является частным случаем другого, третье выражается через четвертое, еще и в разных статьях свапают названия между собой)

Если хотите вспомнить кто есть кто, то мы подготовили для вас статью Функции потерь для классификации.

В ней мы также напомним:
- кто такой Brier Score;
- когда в задаче классификации может сработать MSE;
- что можно сделать с функцией потерь при дисбалансе классов;
- да, в прошлом пункте нет интриги, можно взвесить классы — но что если в минорном классе есть простые примеры, которые сеть учит легко и быстро, а в мажорном сложные? В чем тут может быть проблема и как ее решить?

В общем, есть что вспомнить, давайте закрепим знания вместе: https://telegra.ph/Funkcii-poter-dlya-klassifikacii-10-12

​​Рубрика «Вопрос с собеседования»💼

У вас есть сетка, которая умеет на спутниковом снимке находить маски домиков. Затем эти маски нужно превратить в полигоны домиков.

Вряд ли ваша сетка умеет сегментировать pixel-perfect. Поэтому получится полигон как на картинке (b). У этого полигона слишком много вершин и такой рваный домик на карту не поставишь. Поэтому будем постпроцессить такой полигон. Нам нужно, чтобы было поменьше вершин и побольше прямых углов и параллельных сторон. Получим приятный полигон как на картинке (c).

На одной картинке могут быть сотни таких полигонов. Поэтому постпроцессинг может стать боттлнеком вашей системы.

Вопрос

Пусть в среднем нейросеть предсказывает маску за 100мс, а постпроцессинг в среднем занимает 2с. Вам нужно ускорить работу системы. Считаем, что сам код оптимизирован идеально. Поэтому для ускорения остается только заваливать задачу железом (масштабироваться). Ваши действия?

​​Ответ на вопрос с собеседования💼

Будем считать, что у нас есть условный k8s и нам не нужно греть голову над балансировкой запросов между репликами, оно как-то само заработает 🙂. И пусть картинки к нам приходят по HTTP.

Нашу систему можно упрощенно нарисовать как на рис. 1 (a). Есть сетка на GPU и выход из нее мы передаем в постпроцессинг, который молотит полигоны на CPU.

Первый вариант, который может прийти в голову: а давайте просто горизонтально масштабировать всю систему целиком (рис. 1(b)). Так делать плохо. По условию наша сетка работает в 20 раз быстрее, чем постпроцессинг. Т.е. почти всё время наши дорогущие GPU-мощности простаивают. Получается, при таком масштабировании мы вместо одной дорогущей простаивающей видеокарты получаем много дорогущих простаивающих видеокарт. Не дела.

​​Давайте масштабировать только CPU-часть. Для этого вынесем ее в отдельный HTTP-сервис и сделаем столько реплик сервиса постпроцессинга, сколько нужно, чтобы CUDA-часть не простаивала (рис. 2 (а)). При таком подходе у нас не простаивает GPU и мы масштабируемся за счет относительно дешевых CPU (дешевых относительно видеокарт).

Можно посылать все полигоны (по условию их сотни) с картинки в сервис постпроцессинга. Но лучше разбивать полигоны на батчи и уже батчи асинхронно слать в сервис постпроцессинга (рис. 2 (б)). Такой подход позволит нам лучше утилизировать CPU-часть и лучше масштабироваться.
Это легко понять на простом примере: пусть к нам пришла только одна картинка и на ней 100 полигонов. Если мы пошлем все полигоны одним запросом, то будем ждать, пока один из зеленых сервисов их прожует. То есть мы вообще ничего не получили от масштабирования CPU-части. Но если мы разбили на пять батчей и каждый послали отдельным запросом, то над ними будут трудиться уже пять зеленых сервисов и мы ускоримся в пять раз.

Далее, когда докидывание CPU-сервисов перестает давать прирост к производительности, мы начнем докидывать еще и GPU-сервисы (рис. 2 (c)).

Можно заметить, что у нас появились накладные расходы на сеть, но будем считать, что они малы по сравнению с временем работы постпроцессинга.

Скорее всего, нагрузка на такой сервис не будет равномерной. Это значит, например, что в одно время суток нам нужно будет сто зеленых сервисов, а в другое время мы обошлись бы и десятью. Здесь, например, нас может выручить HPA. Он позволит нам автоматически разворачивать новые зеленые сервисы, например, тогда, когда утилизация CPU становится больше некоторого порога.

Еще можно сказать, что подход с HTTP-запросами и сервисами может быть заменен на подход с промежуточной очередью и воркерами. Он будет спасать нас, например, от резких всплесков нагрузки. Но в условиях несложной задачки будем считать этот пункт не очень важным 😉

Как понять где ваш код тормозит
⠀
Недавно мы рассказали про два простых метода ускорения сетей: фьюзинг и дистилляция. Но не архитектурными трюками едины! Эффективно написанный код может также бустануть ваш инференс или тренировку.

Но как понять что код эффективен? Использовать профилировщики! В новой статье мы рассказали про вариант, который хорошо подойдет под специфику DL: Профилировщик torch.profiler — читайте и пишите эффективный код✌️

Вебинар по введению в разработку

В посте про распределение нагрузки между GPU и CPU мы упомянули k8s. Еще тогда подумали рассказать что такое кубер в одном из постов, но тогда надо бы и докер упомянуть, да и CI/CD можно.. Плюс есть люди, которые вообще никогда не занимались разработкой. Поэтому мы решили провести вводную онлайн-лекцию, на которой расскажем как создают и поддерживают сервисы.

Вебинар рассчитан на новичков, которые не сталкивались с разработкой. На нем мы обзорно рассмотрим что такое сервис, докер, кубер, мониторинг, ci/cd и другие базззворды🐝 За пару часов вебинара стать профи в этих темах нельзя, но понять, за что каждая из них отвечает — вполне :)

Чтобы материал был еще полезнее, создали для вас короткую гугл-форму, через которую вы можете повлиять на содержание лекции и задать интересующие вас вопросы — на них мы ответим на вебинаре.

Время вебинара сообщим на этой неделе! Кстати, в гугл-форме можно повлиять и на него :)

Продолжаем ликбез по архитектурам

В прошлый раз мы рассказывали про VGG, теперь вспоминаем как зародилось семейство ResNet.

В отличии от VGG, ResNet не стыдно использовать в привычных CV задачах даже в 2022 году. Надо лишь знать как ее учить — об мы, кстати, рассказывали в серии предыдущих постов.

В новой же статье отдаем дань старичку и вспоминаем:
- изначальную идею,
- пользу ботлнек блоков
- и основной вклад identity веток в deep learning

​​Вебинар по введению в разработку

Недавно мы анонсировали вебинар и попросили вас заполнить гугл-форму. Спасибо всем за ваши ответы! Благодаря им мы уже скорректировали план лекции и выбрали оптимальное время. Решили не тянуть с обещанием и провести вебинар уже в этот вторник 1 ноября в 18:00 Мск🔥

Напомним, что вебинар расчитан на новичков, которые еще не знакомы с разработкой. На нем вы узнаете:
- как обученную модель доставляют до клиентов,
- как разворачивают приложение на сервере,
- как автоматизируют доставку,
- и как следят за ошибками и метриками.

Чтобы зарегистрироваться, просто начните диалог с нашим ботом: @deepschool_webbot. До встречи на вебинаре!🚀

Провели наш первый вебинар! Спасибо всем кто заполнял формы, оставлял вопросы, участвовал в вебинаре и предлагал новые темы❤️

Получили несколько сообщений с просьбой повторить вебинар, поэтому хотим оценить количество желающих. Поставьте, пожалуйста, китенка в реакцию, если хотите повтор🐳 Наберем 30 китов — повторим!

Однако, не ожидали, что за 30 минут наберем 30 китов😅
Повтору — быть!

Анонсируем дату позднее в этом канале

Виды сверток

Собрали в одну статью различные виды сверток!
Напомнили зачем существуют свертки 1х1, что такое Depthwise Separable Convolution, Spatialy Separable и другие. Не забыли и про нотку экзотики в виде Shuffled Grouped и Deformable.

Читайте статью, чтобы вспомнить какие бывают свертки и чем они отличаются: https://telegra.ph/Vidy-2D-svertok-11-03

Последний шанс записаться в осенний поток

Помимо постов в этом канале, наша команда также создает курс по Computer Vision для практиков. Этот курс — повышение квалификации для Junior специалистов и возможность закрыть дыры в знаниях для Middle инженеров компьютерного зрения.

На курсе Ракета в Computer Vision вы научитесь решать различные CV задачи, делать это в команде и проходить весь путь разработки полноценного сервиса: от сбора данных до автоматизации деплоя на сервер.

Курс проходит в живом формате в виде zoom-вебинаров. На них спикеры
- рассказывают лекции,
- отвечают на вопросы,
- проводят работу в группах
- и обмениваются опытом со студентами.
Последний пункт — отдельная ценность нашего курса, ведь большая часть студентов — практики с опытом в разных областях и направлениях. На 4 месяца они станут вашими коллегами вместе с кураторами курса.

Старт ближайшего потока во вторник, 8 ноября. А следующего — в марте. Мы уже набрали полноценную группу, но осталось 4 места до лимита в 20 человек. Успейте записаться на консультацию, чтобы задать вопросы, познакомиться с одним из кураторов и принять решение об участии. Скажите на встрече, что вы наш подписчик, чтобы получить скидку :)

С началом нового потока курса пришлось отвлечься от написания статей в телеграм) Но теперь мы снова встали на рельсы и уже подготовили несколько интересных постов для вас! Начнем с одной довольно популярной задачки…

​​Задачка на подумать:

Пусть вам нужно дедуплицировать фотографии. Причем дедупликация должна быть умной. Если есть фотка и такая же фотка, но сдвинутая/повернутая/засвеченная, то нужно считать их дублями.

Для этой задачки вы решили использовать сетку. Выцепляете эмбеддинги картинок и если расстояние между эмбеддингами меньше порога, то считаете картинки дублями.

В итоге может получиться такой словарик (рис. 1):

{
'img1': {'img2', 'img10', 'img15'},
'img2': {'img1', 'img10', 'img15', 'img20'},
...
}

Где ключ - это картинка, а значение - это множество картинок, которые мы посчитали дублями по расстоянию между эмбеддингами.

В таком подходе возникнет следующая проблема: получившееся отношение дублируемости не транзитивно. Это значит, что по расстоянию между эмбеддингами может получиться что-то такое (рис. 2):

{
'img1': {'img2', 'img3'},
'img2': {'img1'},
'img3': {'img1'},
}

т.е. img2 и img3 дублируют img1, но не дублируют друг друга. Кажется, в такой ситуации мы хотим сказать, что все картинки (img1, img2, img3) являются дубликатами друг друга. Ситуацию, при которой из-за такого подхода мы начнем даже очень непохожие картинки называть дублями, мы не рассматриваем, она малореалистична.

Как этого достичь?

Ответ опубликуем завтра

​​Решение

Первое решение, которое может прийти в голову: для каждой картинки в словаре пройдемся по ее дубликатам. И объединим множество дубликатов картинки с множествами дубликатов для каждого дубликата этой картинки. Но такое решение будет работать долго и неправильно. Долго потому что операция объединения множеств имеет линейную сложность, т.е. мы получим итоговую квадратичную сложность. А неправильно потому что может быть такая ситуация (рис. 1):

# input
{
'img2': {'img1'},
'img3': {'img1', 'img4'},
'img1': {'img2', 'img3'},

}

# output
{
'img2': {'img1', 'img3'},
'img3': {'img1', 'img4', 'img2'},
'img1': {'img2', 'img3', 'img4'},

}

Т.е. для картинки img2 нужно было не просто объединить ее множество с множеством картинки img1, а еще и провалиться в множество картинки img1 и взять оттуда все множества дубликатов. Думаю, вы поняли, что здесь запахло рекурсией… поэтому забудем про это решение.

Корректное и быстрое решение можно сделать при помощи структуры данных система непересекающихся множеств (Disjoint-set). Библиотечка для python. Но там буквально несколько строк, можно и самим написать.

В этой структуре данных все объекты хранятся в непересекающихся множествах.

У нее есть две операции:

- get(x) — возвращает некоторого представителя из множества, которому принадлежит объект x
- union(x, y) — объединяет два множества, в которых лежат объекты x и y

Разберем на примере. Пусть была такая система множеств:

{img1, img2, img3}, {img4, img5}, {img6, img7}

get(img1) вернет нам одно из значений из множества {img1, img2, img3}. Т.е. некоторого представителя этого множества
union(img2, img4) преобразует систему множеств к такому виду:

{img1, img2, img3, img4, img5}, {img6, img7}

Обе операции работают почти за О(1). В сложности фигурирует обратная функция Аккермана, но ее можно принять за небольшую константу в реальных задачах. Вообще, есть даже работы, которые утверждают, что нашли ошибку в выводе классической оценки и она может быть улучшена.

Приспособить эту структуру данных под нашу задачу можно следующим образом (рис. 2).
Вот и все. В итоге у нас получится система множеств картинок-дубликатов, которую мы хотели получить изначально.

MobileNet v1-v3

Разобрали для вас сразу три статьи в одной! В ней мы рассказали про революционное семейство архитектур MobileNet и выписали все трюки, которые использовали авторы в каждой из версий архитектуры.

Как можно догадаться из названия, MobileNet — отличная архитектура для инференса на мобильных устройствах. Статьи о ней принесли в мир CV несколько ключевых идей по ускорению и облегчению сетей. Многие из этих идей используются до сих пор и наследуются в других работах (в той же EfficientNet). Поэтому очень сложно переоценить важность этих архитектур.

Очень рекомендуем к прочтению! Изложили все идеи простым языком и подчеркнули несколько интересных нюансов.

Например, вы знали, зачем в MobileNet v2 убрали нелинейность между некоторыми свертками? Или помните почему свертки 1х1 считаются быстрее других (даже с поправкой на кол-во параметров)? Если нет и хотите узнать или вспомнить, читайте нашу новую статью: https://telegra.ph/MobileNet-v1-v3-11-24 🔥

Вспоминаем статистику!

Начинаем серию постов про проверку статистических гипотез.

В новой статье рассказали о том, что такое статистические тесты и зачем они вообще нужны. Напомнили что значит «репрезентативная выборка», стат. критерий, стат. значимость, ошибки первого/второго рода и другое.
Читайте подробнее в статье: https://telegra.ph/Proverka-statisticheskih-gipotez-Vvedenie-12-05

Что такое attention?

Раньше CV инженерам можно было оправдаться, почему они не могут ответить на этот вопрос.
Но трансформеры все глубже проникают в компьютерное зрение и оправдания вроде “я же не нлп-шник!” уже точно не сработают :)

Чтобы напомнить вам какие бывают механизмы внимания в CV, мы готовим для вас отдельный материал. Но пока давайте вспомним/узнаем что же вообще такое attention!

Читайте нашу короткую, но очень полезную статью: https://telegra.ph/CHto-takoe-attention-12-09 — и больше не придется оправдываться)

Основные компоненты AWS

Давайте представим, что вам понадобилось обучиться на датасете размером в несколько ТБ. На вашей рабочей машинке всего RTX - 3070, а кластера у вас нет🙁 Или даже машинки нет.

Что делать? Надо переезжать в облако! Если вы планируете переезжать или просто хотите узнать как работают в облаке, то читайте нашу новую статью Основные компоненты AWS. В ней мы познакомим вас с основными терминами и дадим несколько советов.

https://telegra.ph/Osnovnye-komponenty-AWS-12-14

​​Прогресс развития механизма внимания в CV

Продолжаем про аттеншн в CV. Предыдущий пост.

Теперь у вас есть понимание, что по большому счету механизм внимания - это просто умный (обучаемый) способ что-то перевзвесить. Давайте рассмотрим классификацию механизмов внимания в компьютерном зрении, а также историю их развития. На рисунке представлена временная линия с метками, подчеркивающими знаковые статьи того времени.

Весь прогресс развития может быть грубо разделен на 4 периода:

1. Первый период начинается с архитектуры RAM. В ней авторы предложили комбинировать глубокие сети с механизмом внимания. Механизм внимания рекуррентно предсказывал “важные” участки изображений и обновлял веса сети с помощью обучения с подкреплением. Главной отличительной особенностью работ этого периода является то, что для реализации механизмов внимания всегда использовали RNN;

2. Второй период начался с архитектуры STN. В STN авторы использовали подсеть, которая предсказывает аффинные преобразования для локализации (за счет растяжения и обрезки) и трансформации (сдвиг, поворот) “важной” области изображения. Затем через сеть пропускается только преобразованная важная область входной картинки. Главной отличительной особенностью второго периода является то, что важные области входных данных предсказывались отдельной подсетью, которая училась вместе с классификатором.

3. Третий период начался с SENet, которая предложила поканальный вариант механизма внимания. В нем адаптивно (обучаемо) выделяются потенциально важные признаки. SE-блоки используются например в EffNet и MobileNet архитектурах.

4. Четвертый период начался с адаптации работы Attention is all you need к работе с изображениями, породив архитектуры под общим названием “visual transformers”.

​​Типы механизмов внимания

В целом механизмы внимания в компьютерном зрении можно разделить на следующие категории:

1. Поканальный механизм внимания (Channel attention - НА ЧТО обращать внимание);
2. Пространственный механизм внимания (Spatial attention - КУДА обращать внимание);
3. Временной (эволюционный) механизм внимания (Temporal Attention - КОГДА обращать внимание);
4. Блочный\веточный механизм внимания (Branch attention - ЧТО должно обратить внимание).

Также существуют архитектуры, которые являются представителями нескольких категорий механизмов внимания одновременно.
Рисунок 1 представляет диаграмму категоризации механизмов внимания в компьютерном зрении.

Формула 1 обобщает практически все существующие реализации механизмов внимания. Эту формулу стоит запомнить как для общего развития, так и для ответов на собеседованиях.

Формула 2 — известный вам из предыдущего поста self-attention .

Формула 3 — SE-блок.