Forwarded from commit history
Написал статью на основе заметок по собеседованиям отсюда. В качестве доп материалов добавил:
+ скрин литкода
+ фото заката с Бали
+ фото домашнего рабочего места в Москве
+ общие советы для прохождения собеседований
https://habr.com/ru/post/704128/
+ скрин литкода
+ фото заката с Бали
+ фото домашнего рабочего места в Москве
+ общие советы для прохождения собеседований
https://habr.com/ru/post/704128/
Хабр
Как устроен процесс найма и собеседований на позицию Machine Learning Engineer
Это статья с 21-ой ссылкой о подготовке к собеседованиям на позиции Machine Learning Engineer. Статью собрал на основе заметок из своего канала в тг . Контекст Cейчас я отвечаю за ML в...
Forwarded from cydoroga
Всем привет!
Не очень в тему, но думаю, многим может быть интересно.
Ребята, в том числе ШАДовцы, сделали штуку, которая позволяет инферить и файнтюнить BLOOM-176B из Колаба.
Если вам интересно работать с 175B+ языковыми моделями без необходимости иметь несколько мощных GPU — можете глянуть ссылку и написать, что вы про это думаете!
https://colab.research.google.com/drive/1Ervk6HPNS6AYVr3xVdQnY5a-TjjmLCdQ?usp=sharing
Не очень в тему, но думаю, многим может быть интересно.
Ребята, в том числе ШАДовцы, сделали штуку, которая позволяет инферить и файнтюнить BLOOM-176B из Колаба.
Если вам интересно работать с 175B+ языковыми моделями без необходимости иметь несколько мощных GPU — можете глянуть ссылку и написать, что вы про это думаете!
https://colab.research.google.com/drive/1Ervk6HPNS6AYVr3xVdQnY5a-TjjmLCdQ?usp=sharing
Google
Petals - Getting started with BLOOM-176B (GPU Colab)
Colaboratory notebook
Forwarded from Love. Death. Transformers.
Самое полезное что есть у трансформера как у архитектры - устойчивость, оч сложно сделать так чтобы градиенты взорвались или на инференсе он разошёлся, поэтому 8бит обучение и инференс, вполне себе рабочая схема(скоро выйдет 4бит инференс, но его пока карты не поддерживают)
Ноутбук сборник всяких хаков
Автор: @kaggling
Ноутбук сборник всяких хаков
Автор: @kaggling
Kaggle
Optimization approaches for Transformers [Part 2]
Explore and run machine learning code with Kaggle Notebooks | Using data from multiple data sources
Forwarded from Dan Okhlopkov - канал (Dan)
📹 В какой-то момент я офигел, что умеет ffmpeg.
Как-то на физтехе мы делали phystech.tv: 24/7 стрим из видосов, которые были сняты в МФТИ. А это бесконечные "посвятские видосы первокурсников”, Тьмовости и треш-контент от Бужанского. И это все работало 1 строчкой в терминале.
Недавно на hackernews нашел волшебный гайд по ffmpeg. Если вам нужно сделать что-нибудь с видео или аудио - я уверен, что для этого уже есть ffmpeg filter.
🔗 https://img.ly/blog/ultimate-guide-to-ffmpeg/
Как-то на физтехе мы делали phystech.tv: 24/7 стрим из видосов, которые были сняты в МФТИ. А это бесконечные "посвятские видосы первокурсников”, Тьмовости и треш-контент от Бужанского. И это все работало 1 строчкой в терминале.
Недавно на hackernews нашел волшебный гайд по ffmpeg. Если вам нужно сделать что-нибудь с видео или аудио - я уверен, что для этого уже есть ffmpeg filter.
🔗 https://img.ly/blog/ultimate-guide-to-ffmpeg/
IMG.LY: Blog
FFmpeg - Ultimate Guide | IMG.LY Blog
This guide covers the ins and outs of FFmpeg starting with fundamental concepts and moving to media transcoding and video and audio processing providing practical examples along the way.
Forwarded from Тимлид Очевидность | Евгений Антонов
Играющий тренер
Прошлый пост вызвал активный отклик. Я почувствовал, что сегодня надо зайти с другой стороны. В тимлидском комьюнити эта боль очень даже существует.
Кто это
Довольно распространенная вакансия, где руководителя разработки хотят с глубокими экспертными знаниями. Ну, кажется, что всё нормально, и ничего сильно подозрительного нет.
А потом читаешь текст вакансии и там говорится, что подобный тимлид должен:
⁃ проектировать и реализовывать сложные архитектурные решения;
⁃ заниматься наймом команды;
⁃ заниматься людьми, их обучением, ростом, мотивацией;
⁃ заниматься рабочими процессами;
⁃ заниматься проектным менеджментом.
Ну то есть примерно быть разработчиком, тестировщиком, админом/девопсом, эйчаром и ПМом в одном лице.
Это то, что прямо сразу в голову приходит. Напишите в комментариях, чем еще «должен» заниматься играющий тренер.
80 на 80
Отсюда появляется золотое правило для тимлидов подобного рода. В вакансии пишут, что они 80% времени должны писать код, но мы-то понимаем, что менеджерских активностей тут еще на 80%. А уж как вы эти 160% уложите в рабочие дни, да так, чтобы качество у каждого вида деятельности не страдало – это ваши заботы.
Зато вам будут платить аж на 20-25% больше, чем какому-нибудь сеньору, который только задачи из to do забирает в in progress, пишет код и в done их двигает. При этом не теряя своих хард скиллов, свободно конвертируемых в деньги на рынке труда любой страны и любой компании.
Здоровый тимлид
В реальности я не спорю, что лучше тимлиду иметь хорошие хард скиллы, чем не иметь. Но на всех стульях сразу не посидишь. Поэтому стул надо выбирать исходя из ситуации.
Если у вас большая команда, расхлябанные рабочие процессы и проблемы с коммуникациями между смежными отделами, ну и нанимайте такого тимлида, который это пофиксит, а не будет сидеть 80% времени просто код педалить.
Если у вас 1-2-3 землекопа и всё уже отлажено в целом, то пусть приходит и правда какую-то серьезную часть времени код пилит, попутно подтюнивая эволюционирующие рабочие процессы, направляя команду и проект к светлому будущему.
Сознательный тимлид
А еще хочется затронуть тему сознательности у тимлидов. У каждого своя мотивация и у каждого свой интерес. Кому-то ближе работа с людьми, кому-то с процессами, а кто-то не хочет совсем уж отпускать код. И вот каждый должен хорошенько подумать о том, что он хочет, что ему предлагает его текущая или потенциальная позиция, сделать соответствующие выводы, насколько ему это подходит.
В этом плане мне очень нравится пример Антона Околелова из подкаста Цинковый прод. Он как-то писал, что ему не хочется расставаться с кодом, но и тимлидить нравится. Поэтому он сознательно идет тимлидом в небольшие команды (2-3 человека), чтобы в комфортном для себя режиме на двух стульях усиживать без вреда для дела.
Итог
Думайте что вам ближе, ищите что по душе.
Предлагают вакансию играющего тренера – хорошенько анализируйте, насколько она адекватна, прежде чем соглашаться.
Прошлый пост вызвал активный отклик. Я почувствовал, что сегодня надо зайти с другой стороны. В тимлидском комьюнити эта боль очень даже существует.
Кто это
Довольно распространенная вакансия, где руководителя разработки хотят с глубокими экспертными знаниями. Ну, кажется, что всё нормально, и ничего сильно подозрительного нет.
А потом читаешь текст вакансии и там говорится, что подобный тимлид должен:
⁃ проектировать и реализовывать сложные архитектурные решения;
⁃ заниматься наймом команды;
⁃ заниматься людьми, их обучением, ростом, мотивацией;
⁃ заниматься рабочими процессами;
⁃ заниматься проектным менеджментом.
Ну то есть примерно быть разработчиком, тестировщиком, админом/девопсом, эйчаром и ПМом в одном лице.
Это то, что прямо сразу в голову приходит. Напишите в комментариях, чем еще «должен» заниматься играющий тренер.
80 на 80
Отсюда появляется золотое правило для тимлидов подобного рода. В вакансии пишут, что они 80% времени должны писать код, но мы-то понимаем, что менеджерских активностей тут еще на 80%. А уж как вы эти 160% уложите в рабочие дни, да так, чтобы качество у каждого вида деятельности не страдало – это ваши заботы.
Зато вам будут платить аж на 20-25% больше, чем какому-нибудь сеньору, который только задачи из to do забирает в in progress, пишет код и в done их двигает. При этом не теряя своих хард скиллов, свободно конвертируемых в деньги на рынке труда любой страны и любой компании.
Здоровый тимлид
В реальности я не спорю, что лучше тимлиду иметь хорошие хард скиллы, чем не иметь. Но на всех стульях сразу не посидишь. Поэтому стул надо выбирать исходя из ситуации.
Если у вас большая команда, расхлябанные рабочие процессы и проблемы с коммуникациями между смежными отделами, ну и нанимайте такого тимлида, который это пофиксит, а не будет сидеть 80% времени просто код педалить.
Если у вас 1-2-3 землекопа и всё уже отлажено в целом, то пусть приходит и правда какую-то серьезную часть времени код пилит, попутно подтюнивая эволюционирующие рабочие процессы, направляя команду и проект к светлому будущему.
Сознательный тимлид
А еще хочется затронуть тему сознательности у тимлидов. У каждого своя мотивация и у каждого свой интерес. Кому-то ближе работа с людьми, кому-то с процессами, а кто-то не хочет совсем уж отпускать код. И вот каждый должен хорошенько подумать о том, что он хочет, что ему предлагает его текущая или потенциальная позиция, сделать соответствующие выводы, насколько ему это подходит.
В этом плане мне очень нравится пример Антона Околелова из подкаста Цинковый прод. Он как-то писал, что ему не хочется расставаться с кодом, но и тимлидить нравится. Поэтому он сознательно идет тимлидом в небольшие команды (2-3 человека), чтобы в комфортном для себя режиме на двух стульях усиживать без вреда для дела.
Итог
Думайте что вам ближе, ищите что по душе.
Предлагают вакансию играющего тренера – хорошенько анализируйте, насколько она адекватна, прежде чем соглашаться.
Forwarded from Data Science Private Sharing
Написал небольшой эпос о библиотеке transformers.
И хотя текста много это все равно только лишь введение. Функционала в библиотеке слишком много.
https://habr.com/ru/post/704592/
Для тех кто не в курсе: библиотека Transformers предоставляет доступ к куче современных предобученных DL-моделей.
И на текущий момент является чуть ли не аналогом скалерна в мире Deep Learning.
И хотя текста много это все равно только лишь введение. Функционала в библиотеке слишком много.
https://habr.com/ru/post/704592/
Для тех кто не в курсе: библиотека Transformers предоставляет доступ к куче современных предобученных DL-моделей.
И на текущий момент является чуть ли не аналогом скалерна в мире Deep Learning.
Forwarded from Artificial stupidity
#statistics
Поговорим о causal trees.
Ранее мы говорили об uplift trees. Causal trees - некоторое обобщение для построения деревьев в causal inference.
Что же там происходит?
Как я ранее говорил, в обычных uplift trees используются некоторые эвристики, которые позволяют посчитать приближение при разбиении и учесть его при построении дерева.
Но что, если мы сделаем иную (и более честную) функцию для того, чтобы разделять дерево на ветви? Про это как раз и следующая работа (Athey, Susan, and Guido Imbens. "Recursive partitioning for heterogeneous causal effects." Proceedings of the National Academy of Sciences 113.27 (2016): 7353-7360).
Почему нам важно иметь иную функцию для разбиения? Все потому, что у нас стоит принципиально иная задача. Это не обычная классификация или регрессия, а оценка причинности влияния и размера эффекта. Соответственно, обычные методы будут привносить смещение (bias). И оценки наши, увы, будут несостоятельны.
Соответственно, наш критерий для сплита должен учитывать (см. пример хорошего и плохого разбиения в изображении к посту):
- Баланс между попавшими в ветвь дерева объектами из target и control;
- Ожидаемую точность оценки CATE (conditional average treatment effect). Если разбиение разбивает на группы неточно, то мы получаем искажение в нашей оценке
Потому, давайте введем новую функцию для получения оптимального разбиения - EMSE (expected mean squared error for treatment effects). Если коротко, то это просто MSE с поправкой и учетом разделения на тест и обучение. Выглядит формула примерно так
То есть, мы обучаем наше разделение на одном множестве, а потом подставляем в другое. На коем и вычисляем MSE с поправкой на константу. Ну а expected здесь - это мат. ожидание от нашего MSE. При этом, test и estimation у нас независимы.
Доказано, что такая функция позволяет нам иметь нужные статистические свойства.
Итог:
Кажется весьма интересным такой способ оценки. Да и весьма в стиле ML решений с разделением на train/test части. Подробнее можно почитать в статьях + в этом блог-посте. А реализацию на python можно найти в пакете econml.
Поговорим о causal trees.
Ранее мы говорили об uplift trees. Causal trees - некоторое обобщение для построения деревьев в causal inference.
Что же там происходит?
Как я ранее говорил, в обычных uplift trees используются некоторые эвристики, которые позволяют посчитать приближение при разбиении и учесть его при построении дерева.
Но что, если мы сделаем иную (и более честную) функцию для того, чтобы разделять дерево на ветви? Про это как раз и следующая работа (Athey, Susan, and Guido Imbens. "Recursive partitioning for heterogeneous causal effects." Proceedings of the National Academy of Sciences 113.27 (2016): 7353-7360).
Почему нам важно иметь иную функцию для разбиения? Все потому, что у нас стоит принципиально иная задача. Это не обычная классификация или регрессия, а оценка причинности влияния и размера эффекта. Соответственно, обычные методы будут привносить смещение (bias). И оценки наши, увы, будут несостоятельны.
Соответственно, наш критерий для сплита должен учитывать (см. пример хорошего и плохого разбиения в изображении к посту):
- Баланс между попавшими в ветвь дерева объектами из target и control;
- Ожидаемую точность оценки CATE (conditional average treatment effect). Если разбиение разбивает на группы неточно, то мы получаем искажение в нашей оценке
Потому, давайте введем новую функцию для получения оптимального разбиения - EMSE (expected mean squared error for treatment effects). Если коротко, то это просто MSE с поправкой и учетом разделения на тест и обучение. Выглядит формула примерно так
1 / N_test * sum_N_test( (Y_i - tau_est)**2 - Y_i**2)То есть, мы обучаем наше разделение на одном множестве, а потом подставляем в другое. На коем и вычисляем MSE с поправкой на константу. Ну а expected здесь - это мат. ожидание от нашего MSE. При этом, test и estimation у нас независимы.
Доказано, что такая функция позволяет нам иметь нужные статистические свойства.
Итог:
Кажется весьма интересным такой способ оценки. Да и весьма в стиле ML решений с разделением на train/test части. Подробнее можно почитать в статьях + в этом блог-посте. А реализацию на python можно найти в пакете econml.
Forwarded from DevFM
Зачем нужен code review
Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. В дополнение к статическому анализу в настроенном pre-commit и тестам
— выявить проблемы в архитектуре
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных
В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
— дают приток новых идей для улучшений в процессах, подходах и автоматизации
— увеличивают децентрализацию знаний и bus factor
В статье из заголовка даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.
#skills
Выстроенный code review позволяет:
— найти баги и не пропустить их в прод. В дополнение к статическому анализу в настроенном pre-commit и тестам
— выявить проблемы в архитектуре
— сделать код единообразным. Спорный тезис, за единообразие должны отвечать линтеры и автоформатирование. Но code review помогает наладить те вещи, которые автоформатирование не тянут, например, именование переменных
В долгосрочной перспективе постоянные code review:
— налаживают обратную связь между участниками
— бустят уровень разработчиков, позволяя учиться на своих и чужих ошибках и давая обширную практику чтения чужого кода
— помогают делиться знаниями о технологиях, вариантах решения проблем, возможных проблемах и самом проекте в команде
— дают приток новых идей для улучшений в процессах, подходах и автоматизации
— увеличивают децентрализацию знаний и bus factor
В статье из заголовка даны примеры хорошего и плохого code review, способы прокачки и вообще много разных нюансов.
#skills
tlroadmap.io
Teamlead Roadmap: Code review
Code review – это проверка исходного кода на ошибки, проблемы архитектуры.
Forwarded from Кодим на Коленке | Уроки по программированию
Курс: Основы Python с примерами и заданиями
Курс рассчитан на новичков. Очень удобен тем, что все находится в виде маленьких уроков по каждой из тем. Помимо этого в курсе присутствует практика, которая позволит закрепить свои знания.
Подобнее:👉тут
Курс рассчитан на новичков. Очень удобен тем, что все находится в виде маленьких уроков по каждой из тем. Помимо этого в курсе присутствует практика, которая позволит закрепить свои знания.
Подобнее:👉тут
Forwarded from настенька и графики
Решила собрать разные челленджы и проекты, где можно попрактиковать Tableau. На самом деле, никто не мешает брать эти данные и делать визы где угодно.
В челленджах участвовать прикольно потому что есть еще множество людей, которые тоже в нем участвуют помимо вас, и делятся своими решениями. Какие-то из них стартуют время от времени, так что лучше следить на их лендингами отдельно.
Челленджи:
• #B2VB Back 2 Viz Basics – новые задачки каждую неделю, идут от простых к сложным обычно. Прямо что-то конкретное, сделать такой-то график.
• #WorkoutWednesday – повторить визуализацию из примера.
• #MakeoverMonday – новые данные каждую неделю по созданию своих визуализаций.
• #IronQuest – практика создания визов и подготовка к Iron Viz (крупному датавиз конкурсу).
• #RWFD The Real World Fake Data – создание дэшбордов на настоящий и не очень данных
• #GamesNightViz – челлендж с данными про игры
• #SportsVizSunday – челлендж со спортивными данными
Проекты:
• #EduVizzers – визуализация данных про образование.
• #ProjectHealthViz – визуализация данных по теме здравоохранения
• #PublicPolicyViz – датавиз про политику
• #VizForSocialGood – датавиз про социальные данные и НКО
ps по их хэштегам можно в твиттере найти работы участников
В челленджах участвовать прикольно потому что есть еще множество людей, которые тоже в нем участвуют помимо вас, и делятся своими решениями. Какие-то из них стартуют время от времени, так что лучше следить на их лендингами отдельно.
Челленджи:
• #B2VB Back 2 Viz Basics – новые задачки каждую неделю, идут от простых к сложным обычно. Прямо что-то конкретное, сделать такой-то график.
• #WorkoutWednesday – повторить визуализацию из примера.
• #MakeoverMonday – новые данные каждую неделю по созданию своих визуализаций.
• #IronQuest – практика создания визов и подготовка к Iron Viz (крупному датавиз конкурсу).
• #RWFD The Real World Fake Data – создание дэшбордов на настоящий и не очень данных
• #GamesNightViz – челлендж с данными про игры
• #SportsVizSunday – челлендж со спортивными данными
Проекты:
• #EduVizzers – визуализация данных про образование.
• #ProjectHealthViz – визуализация данных по теме здравоохранения
• #PublicPolicyViz – датавиз про политику
• #VizForSocialGood – датавиз про социальные данные и НКО
ps по их хэштегам можно в твиттере найти работы участников