DeepSchool

Продолжаем определять качество фото лица В первой части мы узнали, что такое задача определения качества фото лиц, зачем она нужна и какие у нее метрики. А сегодня разберемся с тем, как эту задачу можно решить. В новой статье мы расскажем: - как определить качество фото с помощью сравнения лиц разных людей - какие есть проблемы в предложенных решениях - и как решить задачу без разметки Читайте статью по ссылке: https://deepschool-pro.notion.site/Face-Image-Quality-Assessment-Part-2-8df5ffb339bd4bf9a74b863006e8867a?pvs=4

🎞Своя Игра от DeepSchool Всех с тыквенным спасом!🎃 В праздничных декорациях сыграли в “Свою Игру” с вопросами на ML/DL-темы и добавили несколько "tricks" в вопросы 👀🎁 В этот раз все игроки — спикеры нашего курса 3DCV: - Игорь Ильин, 3DCV Research Engineer at Kudan - Ренат Баширов, Leading Research Engineer at Samsung - Дима Чудаков, aka Вассерман, CV Researcher Expasoft И наш волшебный ведущий Давид Свитов — хэдлайнер курса 3DCV, PhD, ex Samsung, а сейчас снова PhD студент в Istituto Italiano di Tecnologia 🤌 Ребята отвечали на вопросы по темам: ① Матан за первый курс ② Ребус из эмодзи ③ Аватары ④ Калибровка ⑤ NeRF Проверьте себя, смогли бы вы ответить на все вопросы? :) Смотрите новый выпуск по ссылке: https://youtu.be/EahROocO3dw P.S. Спасибо за обратную связь к первой серии! Cподвигли нас поскорее снять второй выпуск 🙏

Few-shot learning Во время работы часто не хватает данных для обучения модели. А бывают ситуации, когда размеченных примеров совсем мало, например, менее 10 штук. Чтобы решить эту проблему и учить модели на нескольких примерах, придумали целый класс методов: few-shot learning. В новой статье вы познакомитесь с этим подходом, а также узнаете: - чем отличаются meta-learning, metric-learning и non-episode learning - как устроены эти методы - и как представить имеющиеся данные во время обучения Читайте статью по ссылке: https://deepschool-pro.notion.site/Few-shot-learning-0235073c4fef402daca77513232d058a?pvs=4

​​Шамиль Мамедов Ранее мы рассказывали, как создаем наши посты: - над материалами работает целая команда инженеров и ресерчеров - мы ревьюим посты друг друга - а в конце редактор правит текст, чтобы его было легче читать Также мы познакомили вас с частью нашей команды: Ксюша, Саша, Марк и Илья. А в этот раз о себе расскажет Шамиль: "Я делал магистерскую по Automation and Control Engineering. Control Engineering — это что-то типа Reinforcement Learning, но работает 😅 Кроме шуток, так я познакомился с робототехникой и захотел заниматься исследованиями в данной области. В России это можно делать в Университете Иннополис. Там я и занимался ресерчем, а еще вел занятия по робототехнике для студентов. Мы работали с шагающими роботами и роборуками. Мои друзья в Иннополисе занимались DL и CV, и я тоже начал интересоваться этой движухой. После трех лет работы в университете я выбирал между PhD и началом новой карьеры в ML. В итоге выбрал PhD. Cначала получил несколько отказов, а потом пришел хороший оффер из Бельгии. Я решил поехать посмотреть, как там пытаются двигать робототехнику вперед. Параллельно с PhD я решил углубить свои знания по ML, взял курсы на Coursera по ML и DL от Andrew Ng и прошел ML от Тинькофф. После этого решил внедрять больше ML в свою работу. Моя научная работа связана с обучением роботов манипулировать деформируемыми объектами (например, складывать рубашку или сгибать кабель в нужную форму). Методы, с помощью которых я пытаюсь решить эту задачу, схожи с model-based RL. Для моделирования деформируемых объектов я использую комбинацию машинного обучения и механики. Применение только машинного обучения требует много данных, а собирать реальные данные очень затратно. Комбинация ML и физики делает модели более sample efficient, так как законы физики служат в качестве inductive bias. Еще одно требование к моделям — время инференса, ведь мы хотим очень быстрые модели для их использования внутри оптимизаторов. Почти все статьи, которые я написал в DeepSchool, так или иначе связаны с моим исследованием. В свободное время я занимаюсь спортом (недавно решил пробежать марафон и уже пару месяцев готовлюсь к нему), готовлю и иногда путешествую по Европе." У Шамиля есть свой блог: там можно больше узнать о Шамиле и посмотреть его публикации 🔥 В комментариях можно пообщаться с Шамилем и задать интересующие вопросы 🙂 Посты, над которыми Шамиль работал в нашем канале: - Нейронные дифференциальные уравнения - Базовые методы аугментации временных рядов - Как решать графовые задачи с помощью нейросетей - Гессиан - Иммитационное обучение - Обучение скрытых динамических моделей по частичным наблюдениям

​​Имитационное обучение Чтобы обучить роботов выполнять полезные задачи, нужна целая команда робототехников, которая их запрограммирует. Чем сложнее задача, тем больше времени необходимо на ее реализацию. Для упрощения работы мы можем вместо ручного программирования просто показывать роботу новый навык, которому он обучится с помощью имитации. Это называется имитационным обучением. В новой статье мы поговорим об имитационном обучении, а также узнаем: - как передать навыки людей роботам - чем отличается имитационное обучение от обучения с учителем - подходы к имитационному обучению и как они работают Читайте нашу новую статью по ссылке: https://deepschool-pro.notion.site/6ad66bb2ef494cafab421409dbc2b91c?pvs=4

🎞Своя Игра от DeepSchool Мы повеселились и поиграли в “Свою Игру” с вопросами на ML/DL-темы! Гости первой игры — спикеры наших курсов 3DCV и CVRocket: - Андрей Шадриков, Head of R&D Verigram - Оля Гребенькова, PhD student LMU of Munich, ex Samsung - Дима Чудаков, CV Researcher Expasoft И наш прекрасный ведущий Давид Свитов — хэдлайнер курса 3DCV, PhD, исследователь в Samsung AI Center Ребята отвечали на вопросы по темам: ① Детекторы ② Классический ML ③ Глаз, мозг, зрение ④ Личности ⑤ 3D Computer Vision Проверьте себя, смогли бы вы ответить на все вопросы? :) Смотрите первый выпуск по ссылке: https://youtu.be/Bc80mQMRULc! Это пилотный выпуск шоу, поэтому будем очень рады обратной связи в виде реакций и комментариев! 🔥

Ответ на вопрос с собеседования 💼 ❶ 17 строка: не поставили параметр shuffle в True. Train loader нужно шафлить ❷ 14 и 20: использовали Softmax + CrossEntropyLoss. Так делать не нужно, ведь CrossEntropyLoss уже содержит в себе Softmax. Поэтому мы убираем Softmax из сетки. Можно почитать наш пост про лоссы, чтобы точно со всем разобраться 🙂 ❸ 32-35: не использовали torch.no_grad, а значит, отслеживали градиенты, что нам нужно только при обучении ❹ 32-35: не перевели модель в eval() режим при подсчете метрик, поэтому неправильно посчитался BatchNorm1d. Кстати, у нас есть об этом пост, а еще большой пост про виды нормализаций ❺ 15 и 25-30: модель лежит на gpu, а датасет на cpu. Лучше всегда выносить параметр device, чтобы модель и данные всегда лежали на одном устройстве ❻ 35 строчка: забыли сделать detach().cpu(). Из-за этого потечет память Также в комментариях заметили, что переменные epoch и features не определены, а epoch затирает себя в цикле — это было не по плану, но вы молодцы 🙂 Никто не написал ответ, который содержит в себе все наши пункты, поэтому первый победитель был выбран по меньшему числу упущенных пунктов. А также мы не смогли выбрать одного призера зрительских симпатий внутри команды, поэтому дарим 3️⃣ пиццы! Итак, наши победители, к которым отправляются пиццы: 🍕@KalabiYauu — первый ответ со всего одним упущенным пунктом 🍕@zen0no — приз зрительских симпатий, который совпал с нашим мнением и мнением подписчиков (судя по количеству реакций) 🍕@Xallt — приз зрительских симпатий от нашей команды

Рубрика «Вопрос с собеседования»💼 На собеседованиях часто просят найти ошибки в коде обучения нейросети. Давайте потренируемся. На картинке кусок кода, в котором есть несколько ошибок. Посмотреть в тексте можно тут. Пишите найденные ошибки и идеи, как можно улучшить код в комментариях 👇 🍕 За правильные ответы отправим авторам большие пиццы 😄 - одну за первый ответ, который соберет все спрятанные нами ошибки - вторую за самый полный ответ, который выберет наша команда (доставка по РФ :) Завтра в 16:00 по мск подведем итоги и выложим правильные ответы 🙂

​​История YOLO. Часть 3 Недавно мы рассмотрели первую и вторую версии YOLO, популярной архитектуры для детекции. Сегодня мы продолжим знакомство с историей этого семейства и поговорим о YOLOv3. Эта модель долгое время применялась на практике и успела породить множество ответвлений, которыми пользуются до сих пор. В статье мы расскажем: - как изменилась архитектура в сравнении с предыдущими версиями - какие результаты показала модель в сравнении с другими архитектурами - как авторы решили проблему с пропуском маленьких объектов - и какие трюки позволили поднять качество Читайте новую статью по ссылке: https://deepschool-pro.notion.site/YOLO-history-Part-3-4a17c56760a34067ae52fa42a8b5a489?pvs=4

Собрали все наши статьи на одной notion-странице В комментариях спросили, есть ли ссылка на все труды нашей команды — сделали! Пишите нам чаще свои предложения или вопросы — мы все читаем :)

​​Как работает камера. Калибровка В первой частистатьи мы рассказали, как 3D объекты проецируются на 2D плоскость фотографии. А также описали математическую модель камеры и ее параметры. Зная параметры камеры, можно восстановить 3D сцену или ее характеристики: высоту здания, расстояние до пешехода, загруженность самосвала. Но мы не рассказали, как определить параметры своей камеры. И мы рассматривали простую pinhole модель, а в реальной жизни у камер есть линзы, которые искажают изображения (вспомните fisheye эффект) — и их тоже надо как-то исправлять. О том как восстанавливать параметры камеры (калибровать ее) и нивелировать искажения (дисторсию), мы и рассказали в нашей новой статье. Из нее вы узнаете: - как выглядит математическая модель калибровки и дисторсии - советы по сбору датасета для калибровки - какие есть методы калибровки - и подробный разбор одного из методов Кажется, это самая длинная наша статья, сохраняйте ее, чтобы не потерять в тот момент, когда вы столкнетесь с этой задачей :) Читайте по ссылке: https://deepschool-pro.notion.site/e434d0f2fe144734a7577d5540debbd3?pvs=4

Еще 2 преимущества автотестов “Да ладно, в следующий раз напишу тесты, вроде все работает” — каждый ловил себя на такой мысли. Бывает, мы успокаиваем себя тем, что проект маленький, шанс его уронить невелик, и можно не переживать. Но такая вероятность есть всегда, и с ростом проекта она только увеличивается. В реальных проектах могут быть тысячи строк с десятками классов, которые взаимодействуют друг с другом. И представьте, что ваша текущая задача требует модифицировать всего пару строк в классе. Ноо… От этого класса зависят ещё три. А от этих трёх еще по три… И в итоге ваши 2 строчки могут уронить всю систему. Как избежать этого? Можно потратить пару дней на то, чтобы придумать и проверить все сценарии, при которых проект может упасть или отработать некорректно — но это точно будут не самые интересные пару дней. Скорее всего вы как разработчик предпочли бы писать код и катить новые фичи, а не изучать легаси-куски системы. ... вот опять бы была кнопка, на которую жмешь и проверяешь: все ли корректно работает. Автотесты — та самая кнопка. В одном посте тему автотестов не обхватить, но мы добавим аргументов "за" тесты, чтобы замотивировать вас в них разобраться. С очевидными плюсами тестов многие уже знакомы и согласны: тесты снижают вероятность появления нелепых багов (например, при рефакторинге) и экономят время на проверки. В этом же посте мы поделимся еще парой не самых очевидных преимуществ. Тесты — это документация Ведь на какие вопросы обычно отвечает документация: - как выглядят базовые сценарии работы приложения? - что делает функция? — в идеале с примерами - как собрать инстанс класса? - на какие куски кода я повлияю, если изменю вот этот метод? - хочу красивую страничку с поясняющими картинками и ссылками на ютуб, чтобы как для тупых Если ответственно подойти к процессу тестирования, то все пункты кроме последнего можно удовлетворить. Причем зачастую тесты в реальных проектах — единственная документация и в них полезно заглядывать, когда вы с знакомитесь с проектом. Тесты контролируют сложность кода С течением времени наш когда-то понятный прозрачный проект превращается в клубок грязи, который очень тяжело поддерживать. Почти всегда такой клубок просто невозможно тестировать — и это хорошая новость. Ведь если вы понимаете, что на какую-то логику очень сложно написать тест, значит с большой вероятностью вы написали плохоподдерживаемый код и его нужно рефакторить. P.S. не надо ждать момента, когда проект разросся и его стало тяжело править, пишите тесты со старта! Иначе рискуете уйти в крайность "уже слишком поздно, это невозможно тестировать...". Какие еще полезные последствия тесты принесли вам? Пишите в комментариях! А в следующих постах расскажем про типичные ошибки при написании тестов и о том, как их избежать. Если вы хотите научиться писать тесты, приходите на нашу программу CVRocket. На ней мы учим приводить в порядок эксперименты, ускорять модели, оборачивать их в веб-сервис, настраивать ci/cd — и все это при поддержке опытных инженеров. #заметки@deep_school