продуктовый computer vision со стороны: нужно читать свежие статьи c CVPR и ICCV и имплементировать моднейшие архитектуры
продуктовый computer vision изнутри: бля, опять инстаграм забанил все скраперы
продуктовый computer vision изнутри: бля, опять инстаграм забанил все скраперы
Видел недавно образец карго-культа с привкусом ООП.
Дано: старый плохой код, состоящий из двух функций
Задача: отрефакторить, в первую очередь сделать модульно и тестируемо.
Результат выглядел примерно так:
Дано: старый плохой код, состоящий из двух функций
process и upload_to_s3, примерно 500 строк в сумме. Задача: отрефакторить, в первую очередь сделать модульно и тестируемо.
Результат выглядел примерно так:
class AbstractProcessor:Monkey see, monkey do.
def __init__():
pass
@abc.abstractmethod
def process():
pass
@abc.abstractmethod
def upload_to_s3():
pass
class Processor:
def __init__():
super().__init__()
def process():
# 300 строк старого говна
def upload_to_s3():
# 200 строк старого говна
👍3
#мысли_из_душа
Придумал бесполезную метрику: соотношение yaml-кода (или где вы там храните свои конфигурации) к python-коду для одного ML эксперимента.
Если для каждого нового эксперимента нужно писать много кода и мало конфигурации, представляются такие варианты:
- эксперименты исключительно передовые (или новая задача в рамках проекта, или кардинально новый подход к ее решению);
- инфраструктура находится где-то между "оставляет желать лучшего" и "ебаный колхоз".
Такая двойственность делает метрику абсолютно бесполезной. А раз так, то это и не метрика, а просто херня какая-то.
Придумал бесполезную метрику: соотношение yaml-кода (или где вы там храните свои конфигурации) к python-коду для одного ML эксперимента.
Если для каждого нового эксперимента нужно писать много кода и мало конфигурации, представляются такие варианты:
- эксперименты исключительно передовые (или новая задача в рамках проекта, или кардинально новый подход к ее решению);
- инфраструктура находится где-то между "оставляет желать лучшего" и "ебаный колхоз".
Такая двойственность делает метрику абсолютно бесполезной. А раз так, то это и не метрика, а просто херня какая-то.
Если бы я стремился прославиться в computer vision тусовке, я бы начал с написания human-friendly обертки вокруг python-обертки вокруг OpenCV.
Понятно, что хардкорные плюсовики привыкли к нечитаемым ошибкам, но нам, нежным хипстерам, очень грустно от этих всяких
Понятно, что хардкорные плюсовики привыкли к нечитаемым ошибкам, но нам, нежным хипстерам, очень грустно от этих всяких
*** SystemError: <built-in function> returned NULL without setting an error😁1
Я сейчас на той стадии технической (не)зрелости, что довольно много думаю об абстракциях. Точнее, о нужном и допустимом уровне абстракции для разных задач.
Если спуститься слишком низко, то для любой фигни нужно будет изобретать свой велосипед, а для него - свои колеса. В силу ограниченности наших умов, эти колеса иногда будут квадратными. Ну и количество времени, необходимое для любой задачи, ожидаемо устремится в бесконечность.
Если подняться слишком высоко, то программирование превращается в шаманство. Трижды стукни в бубен в полнолуние, переодевшись в петуха, и тогда твои тесты позеленеют, а логистическая регрессия покажет точность 146%.
Хороший пример: https://habr.com/ru/post/471282/#comment_20748088. Статья уже слегка отредактирована, потому перескажу вкратце историю (можно частично восстановить из комментариев): чувак вооружился сверхвысокоуровневой абстракцией fastai, забил на train/val/test разбиение (библиотека все сделает за него), получил близкие к идеальным результаты и начал хвастаться, как легко превзойти предыдущий state of the art.
Кажется, что опыт именно тем и полезен: со временем инженер примерно чувствует нужный уровень абстракции для задачи. Настоящие сеньоры - те, чьи абстракции протекают не сразу.
Если вы знаете, что почитать на эту тему - напишите мне (@arsenyinfo) и посоветуйте!
Если спуститься слишком низко, то для любой фигни нужно будет изобретать свой велосипед, а для него - свои колеса. В силу ограниченности наших умов, эти колеса иногда будут квадратными. Ну и количество времени, необходимое для любой задачи, ожидаемо устремится в бесконечность.
Если подняться слишком высоко, то программирование превращается в шаманство. Трижды стукни в бубен в полнолуние, переодевшись в петуха, и тогда твои тесты позеленеют, а логистическая регрессия покажет точность 146%.
Хороший пример: https://habr.com/ru/post/471282/#comment_20748088. Статья уже слегка отредактирована, потому перескажу вкратце историю (можно частично восстановить из комментариев): чувак вооружился сверхвысокоуровневой абстракцией fastai, забил на train/val/test разбиение (библиотека все сделает за него), получил близкие к идеальным результаты и начал хвастаться, как легко превзойти предыдущий state of the art.
Кажется, что опыт именно тем и полезен: со временем инженер примерно чувствует нужный уровень абстракции для задачи. Настоящие сеньоры - те, чьи абстракции протекают не сразу.
Если вы знаете, что почитать на эту тему - напишите мне (@arsenyinfo) и посоветуйте!
Классический шаблон вопроса на собеседовании: "у тебя есть неатомарный кусочек софта [примерное описание этого софта], и он работает плохо [сырое описание проблемы]. как исправить?". Например, в случае deep learning собеседования вопрос может быть сформулирован так: "у тебя есть пайплайн обучения сети, но она обучается слишком медленно. как ускорить?"
Если собеседуемый претендует на не совсем junior роль, от него ожидаются встречные вопросы. Например: что такое медленно? как это определили? почему это плохо и важно? В случае с обучением модели кто-то может иметь в виду просто некую неэффективность пайплайна в вакууме, а кто-то - несоответствие конкретным хотелкам (нужно обновлять модель ежедневно, а она тренируется три дня).
И уже после этого нужно отвечать. Слабые инженеры сразу говорят, что можно улучшить ("а давайте поменяем модель на более легкую!"), а сильные - набрасывают план, как находить слабые места и как их ранжировать ("определим, где у нас затык - для начала посмотрим утилизацию процессора, GPU и диска"). Это не всегда значит, что слабых нельзя нанимать, но наверняка какое-то время их придется кормить с ложечки и детально расписывать задачи.
Если собеседуемый претендует на не совсем junior роль, от него ожидаются встречные вопросы. Например: что такое медленно? как это определили? почему это плохо и важно? В случае с обучением модели кто-то может иметь в виду просто некую неэффективность пайплайна в вакууме, а кто-то - несоответствие конкретным хотелкам (нужно обновлять модель ежедневно, а она тренируется три дня).
И уже после этого нужно отвечать. Слабые инженеры сразу говорят, что можно улучшить ("а давайте поменяем модель на более легкую!"), а сильные - набрасывают план, как находить слабые места и как их ранжировать ("определим, где у нас затык - для начала посмотрим утилизацию процессора, GPU и диска"). Это не всегда значит, что слабых нельзя нанимать, но наверняка какое-то время их придется кормить с ложечки и детально расписывать задачи.
Хрестоматийный пример того, что иногда случается, если один человек делает машинлернинг, потом не глядя перекидывает результаты работы через стенку, чтобы кто-то другой вкрутил это в продакшен.
Дано: модель для сегментации, на выходе логиты. Человек, который должен прикрутить ее к продакшен приложению, слышал, что выход сегментации должен быть
После расследования обнаружилось, что постпроцессинг делался примерно так:
Дано: модель для сегментации, на выходе логиты. Человек, который должен прикрутить ее к продакшен приложению, слышал, что выход сегментации должен быть
[0..1], а значит, он должен добавить какой-то постпроцессинг.После расследования обнаружилось, что постпроцессинг делался примерно так:
std::clamp(x, 0, 1).Два дня боролся с утечкой памяти в доставшемся по наследству deep learning пайплайне. Оказалось, что на самом деле их две, а ведь в языках с автоматической очисткой памяти это довольно редкий зверь.
Первый лик нашелся относительно легко при помощи pympler. Дальше началось странное, потому что pympler не видел новые объекты, а память потихоньку утекала - медленно, но верно.
Для победы пришлось отбросить ковбойский подход "ща я тут дебаггером влезу, на код гляну и все быстро пойму" и перейти к divide and conquer:
- беру кусок пайплайна;
- вместо настоящего выполнения кэширую;
- смотрю, течет или нет.
После N итераций в подозреваемых остался один большой и запутанный модуль - все еще много. Смотреть глазами на графики потребления памяти стало сложно, глаз замылился. На картинке один из таких графиков, в качестве такого себе доказательства.
Пришлось добавить статистики и вместо графиков смотреть на p-value, что проще и не требует умственных усилий. Так удалось локализовать проблему до одной функции, изолировать ее и найти проблему: подвыборка из тензора по индексам оставляла неявный референс.
Мораль такая: даже если ты не разбираешься в проблеме, декомпозиция и базовая автоматизация (инструменты, склеенные скотчем) помогут.
Первый лик нашелся относительно легко при помощи pympler. Дальше началось странное, потому что pympler не видел новые объекты, а память потихоньку утекала - медленно, но верно.
Для победы пришлось отбросить ковбойский подход "ща я тут дебаггером влезу, на код гляну и все быстро пойму" и перейти к divide and conquer:
- беру кусок пайплайна;
- вместо настоящего выполнения кэширую;
- смотрю, течет или нет.
После N итераций в подозреваемых остался один большой и запутанный модуль - все еще много. Смотреть глазами на графики потребления памяти стало сложно, глаз замылился. На картинке один из таких графиков, в качестве такого себе доказательства.
Пришлось добавить статистики и вместо графиков смотреть на p-value, что проще и не требует умственных усилий. Так удалось локализовать проблему до одной функции, изолировать ее и найти проблему: подвыборка из тензора по индексам оставляла неявный референс.
Мораль такая: даже если ты не разбираешься в проблеме, декомпозиция и базовая автоматизация (инструменты, склеенные скотчем) помогут.
Полгода назад я выступал на Bulbacon и, отвечая на вопросы, сказал что-то вроде: "Через год называть себя дата сайнтистом станет зашкваром", подразумевая дурную славу некачественного кода в духе "я тут чего-то нафигачил в jupyter notebook" и намекая, что всем машинлернерам стоит учиться писать более или менее чистый код.
Тем временем в Python developers survey 2019 появился провокационный вопрос.
Тем временем в Python developers survey 2019 появился провокационный вопрос.
👍2
Обнаружил сервис для не самых умных, но не безответственных unix-пользователей.
Например, гуглите какой-то свой вопрос, видите волшебную shell команду на StackOverflow с кучей непонятных флажков. Есть соблазн просто вбить в терминал, но голос разума говорит, что надо бы хотя бы поверхностно разобраться, что это за магия.
Собственно, для этого и нужен explain shell. Пример с классическим sudo rm -rf.
Например, гуглите какой-то свой вопрос, видите волшебную shell команду на StackOverflow с кучей непонятных флажков. Есть соблазн просто вбить в терминал, но голос разума говорит, что надо бы хотя бы поверхностно разобраться, что это за магия.
Собственно, для этого и нужен explain shell. Пример с классическим sudo rm -rf.
У меня может быть confirmation bias, но кажется, что deep learning для компьютерного зрения в 3d вылазит из пещер и потихоньку идет в массы.
На Kaggle запустились два конкурса (1, 2) про 3d картинки (что характерно, оба про беспилотные тачки).
На глаза стали попадаться всякие pytorch библиотеки для работы с 3d объектами: kaolin, torch3d, kornia. Две первые - совсем свежие, последняя зародилась с год назад; примерно тогда же нам в WANNABY пришлось написать что-то такое самостоятельно, подглядывая в учебники и исходный код OpenCV (где большая часть примитивов давно есть, но не для модных DL-пацанчиков).
Наконец, на arxiv по запросу "3d deep learning" тоже явный рост: 170 работ в 2017, 255 работ в 2018, 282 - в незакончившемся 2019. Хотя тут нужно бы отнормировать на общее количество статей: DL хайп еще не закончился, экстенсивное развитие продолжается.
На Kaggle запустились два конкурса (1, 2) про 3d картинки (что характерно, оба про беспилотные тачки).
На глаза стали попадаться всякие pytorch библиотеки для работы с 3d объектами: kaolin, torch3d, kornia. Две первые - совсем свежие, последняя зародилась с год назад; примерно тогда же нам в WANNABY пришлось написать что-то такое самостоятельно, подглядывая в учебники и исходный код OpenCV (где большая часть примитивов давно есть, но не для модных DL-пацанчиков).
Наконец, на arxiv по запросу "3d deep learning" тоже явный рост: 170 работ в 2017, 255 работ в 2018, 282 - в незакончившемся 2019. Хотя тут нужно бы отнормировать на общее количество статей: DL хайп еще не закончился, экстенсивное развитие продолжается.
Спонсор картинки для канала - tensorboard, в котором я только что увидел такой семпл
Из вчерашней беседы с Алексеем (@simplestupid):
«если в случайном предложении заменить data scientist на "астролог" или "гомеопат", связность текста обычно не страдает».
«если в случайном предложении заменить data scientist на "астролог" или "гомеопат", связность текста обычно не страдает».
Одна из самых важных вещей в профессиональном развитии - поработать с фанатиками. Правильный фанатик должен (1) обладать достаточно глубокими знаниями в некоторой нише, (2) быть нетерпимым к посредственной, по его меркам, работе.
Такой фанатик может быть неприятным человеком, а его критерии абсолютно неадекватны в текущем контексте. Зато через его придирки можно очень быстро научиться хотя бы базовым приемам (80 на 20, как обычно) и составить свое представление о том, что такое хорошо и что такое плохо. Необязательно делать быстродействие вашего кода религией, но поработать с человеком, который стремится любой ценой оптимизировать все сколько-нибудь заметные в профайлере функции - очень полезно.
Так что если у вас есть коллега, который придирается к каждой строчке в код ревью, хуесосит тех, кто не понимает физический смысл Гессиана, возмущается несоблюдением канонов скрама или упорно критикует то, что вы считаете продуктовой стратегией - радуйтесь и извлекайте из этого выгоду.
А вот если ваши коллеги - скучные посредственности, неготовые выставить планку повыше хоть в чем-нибудь, постарайтесь не задерживаться в такой команде. Деградация - бессердечная сука.
Такой фанатик может быть неприятным человеком, а его критерии абсолютно неадекватны в текущем контексте. Зато через его придирки можно очень быстро научиться хотя бы базовым приемам (80 на 20, как обычно) и составить свое представление о том, что такое хорошо и что такое плохо. Необязательно делать быстродействие вашего кода религией, но поработать с человеком, который стремится любой ценой оптимизировать все сколько-нибудь заметные в профайлере функции - очень полезно.
Так что если у вас есть коллега, который придирается к каждой строчке в код ревью, хуесосит тех, кто не понимает физический смысл Гессиана, возмущается несоблюдением канонов скрама или упорно критикует то, что вы считаете продуктовой стратегией - радуйтесь и извлекайте из этого выгоду.
А вот если ваши коллеги - скучные посредственности, неготовые выставить планку повыше хоть в чем-нибудь, постарайтесь не задерживаться в такой команде. Деградация - бессердечная сука.
👍3🔥1
Если вы жалуетесь на высокое и постоянно растущее количество сущностей (будь то новые фреймворки на гитхабе или deep learning статьи на arxiv.org) в нашей условно интеллектуальной профессии, знайте, что вы серьезно опоздали с этими жалобами.
“Уже в 1600 г. Уильям Гильберт жаловался, что интеллектуалы должны ориентироваться в «столь обширном океане книг, которые смущают и утомляют умы занимающихся наукой»” - Дэвид Вуттон, “Изобретение науки. Новая история научной революции”
“Уже в 1600 г. Уильям Гильберт жаловался, что интеллектуалы должны ориентироваться в «столь обширном океане книг, которые смущают и утомляют умы занимающихся наукой»” - Дэвид Вуттон, “Изобретение науки. Новая история научной революции”
Большинство статей "топ 10 технологий 2010-ых" или "что нас ждет в 2020-ых" - неинтересный кликбейт, да еще и отражающий значительный bias автора.
В противоположность, статья https://habr.com/ru/post/481844/ выглядит максимально объективной и здравой, без перегибов типа "Мы на пороге сильного ИИ" и "AI winter is coming".
В противоположность, статья https://habr.com/ru/post/481844/ выглядит максимально объективной и здравой, без перегибов типа "Мы на пороге сильного ИИ" и "AI winter is coming".
Хабр
7 лет хайпа нейросетей в графиках и вдохновляющие перспективы Deep Learning 2020-х
Новый год все ближе, скоро закончатся 2010-е годы, подарившие миру нашумевший ренессанс нейросетей. Мне не давала покоя и лишала сна простая мысль: «Как можно...