Forwarded from DevFM
Справляемся с рисками
Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.
В первой даётся определение риска – это сочетание возможности получить выгоду и вероятности потерь. Мы принимаем риск не ради него самого, а ради целей, которые хотим достичь.
Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?
Для оценки риска предлагается использовать матрицы риска, которые делят вероятность и последствия на категории: низкие, средние, высокие. Таким образом можно наглядно увидеть, какие стечения обстоятельств действительно рисковые.
На самом деле важно понимать структуру риска и инструменты для его анализа. Вместо расплывчатого "это слишком рискованно" можно попробовать выдать что-то осмысленное: "Вероятность низкая, но последствия критические, значит, это требует дополнительной подготовки".
Вторая статья посвящена управлению рисками – действиям, направленным на снижение риска.
По сути мы возвращаемся к составляющим риска:
– Снижение вероятности. Мы пытаемся сделать так, чтобы рискованное событие с меньшей вероятностью происходило.
– Снижение последствий. Мы уменьшаем ущерб, если событие всё же произойдёт.
Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:
Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода
Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления
#teamwork
Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.
В первой даётся определение риска – это сочетание возможности получить выгоду и вероятности потерь. Мы принимаем риск не ради него самого, а ради целей, которые хотим достичь.
Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?
Для оценки риска предлагается использовать матрицы риска, которые делят вероятность и последствия на категории: низкие, средние, высокие. Таким образом можно наглядно увидеть, какие стечения обстоятельств действительно рисковые.
На самом деле важно понимать структуру риска и инструменты для его анализа. Вместо расплывчатого "это слишком рискованно" можно попробовать выдать что-то осмысленное: "Вероятность низкая, но последствия критические, значит, это требует дополнительной подготовки".
Вторая статья посвящена управлению рисками – действиям, направленным на снижение риска.
По сути мы возвращаемся к составляющим риска:
– Снижение вероятности. Мы пытаемся сделать так, чтобы рискованное событие с меньшей вероятностью происходило.
– Снижение последствий. Мы уменьшаем ущерб, если событие всё же произойдёт.
Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:
Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода
Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления
#teamwork
jacobian.org
Mitigation - Jacob Kaplan-Moss
So you’ve identified a risk — now what do you do about it? Here’s a simple framework to help frame discussions about risk mitigation. It’s intentionally very simple, a basic starting point. I’ll present a more complex framework later in this series, but I…
Forwarded from Тимлид Очевидность | Евгений Антонов
Пятый месяц. Развитие ключевых людей
Прошел пятый месяц курса Стратоплана «Руководитель отдела». Перевалил за серединку уже 🙂
Контент первого, второго, третьего и четвертого месяцев я описывал ранее.
В отличие от прошлого месяца в этот раз удалось присоединиться к групповым практикам, и я в очередной раз убедился, что это ОГРОМНАЯ разница, конечно.
В этот раз часть контента была мне знакома не только потому, что я где-то что-то читал и изучал, а еще и потому, что похожие упражнения по работе с ключевыми людьми мы делали на работе. Тем не менее для меня традиционно нашлось и что-то новенькое.
Старенькое
- Ситуационное руководство. Как с кем работать при разных уровнях мотивации и компетентности. Это классика, и это надо уметь, если хочешь взращивать самостоятельные и профессиональные команды.
- Как с человеком поговорить о его желании и потенциальных направлениях к дальнейшему развитию. Тут, как всегда, я сторонник того, что не надо на каждого наседать, что развиваться – это ОБЯЗАТЕЛЬНО. Тем не менее это важная часть нашей работы. Где-то сами люди хотят профессионально и карьерно расти, но не знают как, и им надо помочь. А где-то некоторым людям надо расти, чтобы продолжать быть на хорошем уровне в команде, перед которой встают новые вызовы, и надо правильно это донести.
- HiPo и HiPro анализ своей команды (именно такое упражнение я как-то и делал на работе). С одной стороны, мне кажется, у опытного руководителя, погруженного в команду, это должно уже быть где-то в подсознании всегда сгенерено, а с другой стороны, для менее опытных ребят это хороший подход к рефлексии на тему своих соколиков.
- SWOT-анализ и модель GROW. Коротко говоря, это фреймворки на подумать о себе, о своих целях и о том, как и за счет чего ты их будешь достигать.
Новенькое
Тут растекусь мыслью только про одну тему. Но это мне прям ярко впечаталось, и хочется с вами поделиться.
У нас была тема про менторинг vs коучинг. Где менторинг — это про то, что очень опытный и компетентный в конкретном вопросе человек учит другого (ну, например, кузнец учит подмастерье ковать какие-нибудь загогулины), а коучинг — грубо говоря, не обязательно столько компетентный в этом деле человек задает тебе вопросы, и ты сам во всём разбираешься.
Вот мне всегда менторинг был ближе и понятнее. Как будто это профессионально, а коучинг — странное инфоцыганство из серии: «Так, ты пришел ко мне с проблемой. А сам что думаешь? А как будешь решать? Разобрался? С вас пятьтыщ».
Послушал я теоретическую часть и немного скептически двинулся к групповой практике, где мы реальные рабочие вопросы разбирали, чередуя то менторинговый подход, то коучинговый.
И оказалось, что коучинговый подход в некоторых вопросах отработал внезапно очень круто. Человек, ранее зафреймировавший себя на определенные мысли и поведение, столкнулся с проясняющими вопросами и, пока на них отвечал, сам всё понял и пришел к решению, которое ему подходит и нравится.
Короче говоря, если применять менторинг туда, где человек мало компетентен, то можно его научить. А если коучинг добавить туда, где он уже понимает, а просто застрял в силу разных обстоятельств, то есть шанс, что он сам разберется и примет подходящие для себя решения.
Прошел пятый месяц курса Стратоплана «Руководитель отдела». Перевалил за серединку уже 🙂
Контент первого, второго, третьего и четвертого месяцев я описывал ранее.
В отличие от прошлого месяца в этот раз удалось присоединиться к групповым практикам, и я в очередной раз убедился, что это ОГРОМНАЯ разница, конечно.
В этот раз часть контента была мне знакома не только потому, что я где-то что-то читал и изучал, а еще и потому, что похожие упражнения по работе с ключевыми людьми мы делали на работе. Тем не менее для меня традиционно нашлось и что-то новенькое.
Старенькое
- Ситуационное руководство. Как с кем работать при разных уровнях мотивации и компетентности. Это классика, и это надо уметь, если хочешь взращивать самостоятельные и профессиональные команды.
- Как с человеком поговорить о его желании и потенциальных направлениях к дальнейшему развитию. Тут, как всегда, я сторонник того, что не надо на каждого наседать, что развиваться – это ОБЯЗАТЕЛЬНО. Тем не менее это важная часть нашей работы. Где-то сами люди хотят профессионально и карьерно расти, но не знают как, и им надо помочь. А где-то некоторым людям надо расти, чтобы продолжать быть на хорошем уровне в команде, перед которой встают новые вызовы, и надо правильно это донести.
- HiPo и HiPro анализ своей команды (именно такое упражнение я как-то и делал на работе). С одной стороны, мне кажется, у опытного руководителя, погруженного в команду, это должно уже быть где-то в подсознании всегда сгенерено, а с другой стороны, для менее опытных ребят это хороший подход к рефлексии на тему своих соколиков.
- SWOT-анализ и модель GROW. Коротко говоря, это фреймворки на подумать о себе, о своих целях и о том, как и за счет чего ты их будешь достигать.
Новенькое
Тут растекусь мыслью только про одну тему. Но это мне прям ярко впечаталось, и хочется с вами поделиться.
У нас была тема про менторинг vs коучинг. Где менторинг — это про то, что очень опытный и компетентный в конкретном вопросе человек учит другого (ну, например, кузнец учит подмастерье ковать какие-нибудь загогулины), а коучинг — грубо говоря, не обязательно столько компетентный в этом деле человек задает тебе вопросы, и ты сам во всём разбираешься.
Вот мне всегда менторинг был ближе и понятнее. Как будто это профессионально, а коучинг — странное инфоцыганство из серии: «Так, ты пришел ко мне с проблемой. А сам что думаешь? А как будешь решать? Разобрался? С вас пятьтыщ».
Послушал я теоретическую часть и немного скептически двинулся к групповой практике, где мы реальные рабочие вопросы разбирали, чередуя то менторинговый подход, то коучинговый.
И оказалось, что коучинговый подход в некоторых вопросах отработал внезапно очень круто. Человек, ранее зафреймировавший себя на определенные мысли и поведение, столкнулся с проясняющими вопросами и, пока на них отвечал, сам всё понял и пришел к решению, которое ему подходит и нравится.
Короче говоря, если применять менторинг туда, где человек мало компетентен, то можно его научить. А если коучинг добавить туда, где он уже понимает, а просто застрял в силу разных обстоятельств, то есть шанс, что он сам разберется и примет подходящие для себя решения.
Forwarded from Аналитика данных / Data Study
Analysis.pdf
2 MB
Нашёл у себя в сундуке полезных материалов презентацию с 39 видами различных видов бизнес/системного/дата/продуктового анализа, а также инструменты проектного управления, которые полезно применять в разных задачах.
В файле описаны ключевые аспекты каждой методологии, если захотите применять что-то на практике, то лучше изучить дополнительные материалы.
Хотите описать сильные и слабые стороны продукта, берите SWOT (слайд 2).
Есть потребность оценки рисков и проектных зависимостей, рассмотрите RAID Log (слайд 20).
Хотите зафиксировать список стейкхолдеров проекта и понять кому и по каким вопросам обращаться, с кем согласовывать, а кому просто прийти с готовым результатом - посмотрите на Stakeholder Analysis (слайд 17)
Только запускаете проект и думаете какую информацию для старта важно собрать - воспользуйтесь Project Charter (слайд 26)
Когда-то много из этих видов анализа использовал в работе, потом настал период когда зарылся в данные и технику. Сейчас похоже начинается цикл, когда часть этих инструментов опять войдут в мою повседневную работу
В файле описаны ключевые аспекты каждой методологии, если захотите применять что-то на практике, то лучше изучить дополнительные материалы.
Хотите описать сильные и слабые стороны продукта, берите SWOT (слайд 2).
Есть потребность оценки рисков и проектных зависимостей, рассмотрите RAID Log (слайд 20).
Хотите зафиксировать список стейкхолдеров проекта и понять кому и по каким вопросам обращаться, с кем согласовывать, а кому просто прийти с готовым результатом - посмотрите на Stakeholder Analysis (слайд 17)
Только запускаете проект и думаете какую информацию для старта важно собрать - воспользуйтесь Project Charter (слайд 26)
Когда-то много из этих видов анализа использовал в работе, потом настал период когда зарылся в данные и технику. Сейчас похоже начинается цикл, когда часть этих инструментов опять войдут в мою повседневную работу
Forwarded from sahil
Summary : Собеседование в майкрософт
1) Системный дизайн : задача спроектировать википедию.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Вроде как прошел, не знал про эластик для поиска, но обсудил различные стратегии скэйлинга. Обсудил все требования + back to envelop
2) OOP Дизайн : задача спроектировать систему букинга билетов для самолетов.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Решение понравилось собеседующему, вроде как обсудили различные моменты с API
НО, я не закодил полностью решение. Т.е только базовый API и то не 100% верный с точки зрения всех моментов
3) Бихейв : обсуждение опыта и мое поведение в различных ситуациях.
Весь собес просто обсуждение моего опыта, поведения и все. Т.е ничего особого не было
Мнение : Прошел, вроде есть матч
4) Алгоритмы : задача написать алгоритм для определения того, что одно домино упадет на другое и расстояние между ними 1 метр. Усложнили на последние пару минут требования. Все равно закодил. Задача уровня easy
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Wrap up :
Мне кажется, что я прошел собеседование, но тут уже им решать. Было классно сходить на такое собеседование. Все ребята были очень позитивные и классно общались. Вот бы такое во всех компаниях.
1) Системный дизайн : задача спроектировать википедию.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Вроде как прошел, не знал про эластик для поиска, но обсудил различные стратегии скэйлинга. Обсудил все требования + back to envelop
2) OOP Дизайн : задача спроектировать систему букинга билетов для самолетов.
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Мнение : Решение понравилось собеседующему, вроде как обсудили различные моменты с API
НО, я не закодил полностью решение. Т.е только базовый API и то не 100% верный с точки зрения всех моментов
3) Бихейв : обсуждение опыта и мое поведение в различных ситуациях.
Весь собес просто обсуждение моего опыта, поведения и все. Т.е ничего особого не было
Мнение : Прошел, вроде есть матч
4) Алгоритмы : задача написать алгоритм для определения того, что одно домино упадет на другое и расстояние между ними 1 метр. Усложнили на последние пару минут требования. Все равно закодил. Задача уровня easy
Первые 20 минут собеса общение. За последние 20 минут обсудить дизайн, компоненты и что необходимо + 5 минут для моих вопросов.
Wrap up :
Мне кажется, что я прошел собеседование, но тут уже им решать. Было классно сходить на такое собеседование. Все ребята были очень позитивные и классно общались. Вот бы такое во всех компаниях.
Forwarded from Aspiring Data Science (Anatoly Alekseev)
#python #debugging #ic #icecream
https://medium.com/pythoneers/debugging-in-python-replace-print-with-ic-and-do-it-like-a-pro-18f330c863cb
from icecream import ic
# Using ic() to debug
ic(add(10, 20))
ic(add(30, 40))
ic| add(10, 20): 30
ic| add(30, 40): 70
ic.disable() # Disables ic()
ic(multiply(3, 3)) # Prints nothing
ic.enable() # Re-enables ic()
ic(multiply(3, 3)) # Output: ic| multiply(3, 3): 9
def log_to_file(text):
with open("debug.log", "a") as f:
f.write(text + "\n")
ic.configureOutput(prefix="DEBUG| ", outputFunction=log_to_file)
ic(multiply(7, 7))
https://medium.com/pythoneers/debugging-in-python-replace-print-with-ic-and-do-it-like-a-pro-18f330c863cb
Medium
Debugging in Python: Replace print() with ic() and Do It Like a Pro
Introduction:
Forwarded from От идеи до продукта B2B & B2C | Виктор Чертков (Viktor Chertkov)
Нет не реклама, просто сам активно стал использовать и открыл для себя много новых моделей. Еще и большинство бесплатных
Недавно нашел ресурс — Artificial Analysis. Это библиотека актуальных AI-моделей, где можно не просто смотреть, но и выбирать те, которые реально подходят под конкретные задачи.
Что круто:
Я уже добавил в свою работу несколько инструментов, которые сильно ускорили процессы анализа и проверки гипотез. За счет этого:
Если вы работаете с данными, гипотезами или просто ищете способы прокачать свою продуктивность — загляните. Инструменты ИИ должны работать на вас, а не наоборот.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Глеб Михайлов
Что бы я делал по-другому, работая в IT?
1. Больше бы общался с людьми.
Когда я только начал работать, я вел себя на работе очень замкнуто. Ни с кем не сближался. А это одна из главных фич работы (и жизни)!
Это как еще одни одноклассники и одногруппники! И среди них можно найти друзей, мужа/жену, будущих бизнес-партнеров, менторов.
И просто это фан. Насколько приятнее мне стало ходить на работу, когда я начал больше общаться с людьми. И насколько быстрее стали пролетать "тяжелые" будни.
***
2. Чаще бы менял работу, чтобы получать больше денег.
Всю карьеру я считал, что надо хотя бы год работать на одном месте, чтобы потом не было проблем с поиском работы.
По факту, на 3 из 6 моих офисных работ я работал меньше года, и с моей карьерой ничего страшного не случилось. Только рост в зарплате и в скилах).
***
3. Больше бы отказывался от задач и встреч.
В корпоративной жизни очень большое количество задач и встреч абсолютно бесполезны. Как минимум, они не так важны и срочны, как их преподносят.
И если спорить с начальником – это обычно непродуктивно, то предложить более легкую альтернативу или более комфортный срок – это всегда уместно.
Со встречами еще легче: можно просто не принимать их. И если никто не напишет, значит, я там особо не нужен.
Ну и, конечно, ставить заглушки на обед и на время после 18:00. Заглушки лучше всего делать с небольшим буфером 15-30 минут в обе стороны, чтобы встречи впритык к обеду не ставили – это неудобно, т.к. обед превращается в суету.
Отстаивать свои личные границы не просто, и это не раз приводило меня к конфликтам и увольнениям. Но это того стоило).
***
4. Более открыто бы занимался обучением на работе.
Я всегда боялся читать книги, проходить курсы и делать свои проекты на работе. Ведь на работе надо работать!
Но рабочий день слишком длинный, столько задач нет. Если всё делать эффективно, то рабочие задачи можно раскидать за 2-3 часа в день, а остальное время заниматься своим развитием.
И если кто-то задает вопросы, можно ответить, что ты повышаешь свою квалификацию, и это полезно для компании.
И еще неочевидный факт: когда ты сидишь и учишься, то со стороны это ничем не отличается от того, что ты сидишь и работаешь))).
***
5. Больше бы вкладывался в маркетинг и продажи.
Профессиональные скиллы – это круто. Но успех в карьере зависит не от них!
Профессиональные скиллы – это, по сути, тривиально. Они просто должны быть на приличном уровне.
Поэтому при наличии минимальных профессиональных скиллов, достаточных для работы, гораздо выгоднее вкладываться в маркетинг и продажи.
Маркетинг: резюме, портфолио, личный бренд.
Продажи: умение продавать себя, умение проходить технические интервью, умение договариваться.
Если ты выгодно продаешь свои скиллы, то получаешь лучшее финансирование своего развития и жизни, больше времени на своё развитие, заряженных людей вокруг и вообще более интересный опыт.
А ещё ты не боишься, что тебя уволят или сократят и чувствуешь себя уверенно: ну уволят и хорошо – я умею продавать себя и быстро найду себе работу еще лучше!
***
Кстати, если хочешь прокачать центровой навык продаж в мире IT – умение проходить технические и алгоритмические интервью, то сейчас полным ходом идет набор в 8-й поток моего курса по алгоритмам и структурам данных (старт потока 3 февраля).
Этот курс выбрало уже 189 человек, а студенты и выпускники моего курса проходят интервью в топовые компании. Это значит, что мой курс уже стал проверенным временем и реальным миром продуктом, который сможет довести тебя до результата.
Хочешь выгодно продать свои скиллы? Переходи в бот и узнай, как научиться писать эффективный код, проходить алгоритмические интервью и стать высокооплачиваемым профессионалом без мучений и выгорания, даже если сейчас ты еле-еле кодишь!
1. Больше бы общался с людьми.
Когда я только начал работать, я вел себя на работе очень замкнуто. Ни с кем не сближался. А это одна из главных фич работы (и жизни)!
Это как еще одни одноклассники и одногруппники! И среди них можно найти друзей, мужа/жену, будущих бизнес-партнеров, менторов.
И просто это фан. Насколько приятнее мне стало ходить на работу, когда я начал больше общаться с людьми. И насколько быстрее стали пролетать "тяжелые" будни.
***
2. Чаще бы менял работу, чтобы получать больше денег.
Всю карьеру я считал, что надо хотя бы год работать на одном месте, чтобы потом не было проблем с поиском работы.
По факту, на 3 из 6 моих офисных работ я работал меньше года, и с моей карьерой ничего страшного не случилось. Только рост в зарплате и в скилах).
***
3. Больше бы отказывался от задач и встреч.
В корпоративной жизни очень большое количество задач и встреч абсолютно бесполезны. Как минимум, они не так важны и срочны, как их преподносят.
И если спорить с начальником – это обычно непродуктивно, то предложить более легкую альтернативу или более комфортный срок – это всегда уместно.
Со встречами еще легче: можно просто не принимать их. И если никто не напишет, значит, я там особо не нужен.
Ну и, конечно, ставить заглушки на обед и на время после 18:00. Заглушки лучше всего делать с небольшим буфером 15-30 минут в обе стороны, чтобы встречи впритык к обеду не ставили – это неудобно, т.к. обед превращается в суету.
Отстаивать свои личные границы не просто, и это не раз приводило меня к конфликтам и увольнениям. Но это того стоило).
***
4. Более открыто бы занимался обучением на работе.
Я всегда боялся читать книги, проходить курсы и делать свои проекты на работе. Ведь на работе надо работать!
Но рабочий день слишком длинный, столько задач нет. Если всё делать эффективно, то рабочие задачи можно раскидать за 2-3 часа в день, а остальное время заниматься своим развитием.
И если кто-то задает вопросы, можно ответить, что ты повышаешь свою квалификацию, и это полезно для компании.
И еще неочевидный факт: когда ты сидишь и учишься, то со стороны это ничем не отличается от того, что ты сидишь и работаешь))).
***
5. Больше бы вкладывался в маркетинг и продажи.
Профессиональные скиллы – это круто. Но успех в карьере зависит не от них!
Профессиональные скиллы – это, по сути, тривиально. Они просто должны быть на приличном уровне.
Поэтому при наличии минимальных профессиональных скиллов, достаточных для работы, гораздо выгоднее вкладываться в маркетинг и продажи.
Маркетинг: резюме, портфолио, личный бренд.
Продажи: умение продавать себя, умение проходить технические интервью, умение договариваться.
Если ты выгодно продаешь свои скиллы, то получаешь лучшее финансирование своего развития и жизни, больше времени на своё развитие, заряженных людей вокруг и вообще более интересный опыт.
А ещё ты не боишься, что тебя уволят или сократят и чувствуешь себя уверенно: ну уволят и хорошо – я умею продавать себя и быстро найду себе работу еще лучше!
***
Кстати, если хочешь прокачать центровой навык продаж в мире IT – умение проходить технические и алгоритмические интервью, то сейчас полным ходом идет набор в 8-й поток моего курса по алгоритмам и структурам данных (старт потока 3 февраля).
Этот курс выбрало уже 189 человек, а студенты и выпускники моего курса проходят интервью в топовые компании. Это значит, что мой курс уже стал проверенным временем и реальным миром продуктом, который сможет довести тебя до результата.
Хочешь выгодно продать свои скиллы? Переходи в бот и узнай, как научиться писать эффективный код, проходить алгоритмические интервью и стать высокооплачиваемым профессионалом без мучений и выгорания, даже если сейчас ты еле-еле кодишь!
Forwarded from Vikhr models
This media is not supported in your browser
VIEW IN TELEGRAM
Salt
Мы начали собирать эту модель в августе, в конце августа получили первый прототип, а потом стало выходить миллион вариантов вида: а давайте whisper для речи+GAN для генерации аудио, а потом вышел FishAudio который лучше работает, да и в целом хорошая модель.
Мы шли с другого конца, собрали решение поверх lm с расширенным токенайзером, использовали WavTokenizer для токенизации аудио.
Учили около 150 а100 часов для финального экспа, но количество экспов и денег сожженых в этот проект переваливает за то сколько я потратил на оригинальные Вихри.
По итогу получился не трансформер который понимает речь и генерирует речь, а Dalle1 like tts на основе llama3 3b.
Сейчас идут работы по дообучению на музыку/аудио, вероятно проект получит папир и обновление.
Сейчас модель неплохо работает на английском, на русский мы доучиваем модель.
huggingface
collab
А еще мы учимся на ошибках и в этот раз выкладываем весь код для обучения и aulate для подсчета аудио метрик
В релизе участвовали: Ksenya (основной контрибьютор), Костя, а я ходил пинал чтобы оно все не развалилось и доехало до какого то состояния.
Мы начали собирать эту модель в августе, в конце августа получили первый прототип, а потом стало выходить миллион вариантов вида: а давайте whisper для речи+GAN для генерации аудио, а потом вышел FishAudio который лучше работает, да и в целом хорошая модель.
Мы шли с другого конца, собрали решение поверх lm с расширенным токенайзером, использовали WavTokenizer для токенизации аудио.
Учили около 150 а100 часов для финального экспа, но количество экспов и денег сожженых в этот проект переваливает за то сколько я потратил на оригинальные Вихри.
По итогу получился не трансформер который понимает речь и генерирует речь, а Dalle1 like tts на основе llama3 3b.
Сейчас идут работы по дообучению на музыку/аудио, вероятно проект получит папир и обновление.
Сейчас модель неплохо работает на английском, на русский мы доучиваем модель.
huggingface
collab
А еще мы учимся на ошибках и в этот раз выкладываем весь код для обучения и aulate для подсчета аудио метрик
В релизе участвовали: Ksenya (основной контрибьютор), Костя, а я ходил пинал чтобы оно все не развалилось и доехало до какого то состояния.
Forwarded from MISTER SOSISTER ~ CHINESE TIME OF MY LIFE
Про лидерство в Dise
Как вы знаете, у Dise еще нет CTO. В октябре мы наняли троих очень талантливых и очень амбициозных разрабов, надеясь этот вопрос решить, но что то пошло не так...
Об этом в конце, что важнее, это заставило нас много думать и говорить о лидерстве, и вывести формулу, по которой мы теперь лидерские качества меряем.
Лидер—это тот, кому больше всех надо.
Оказалось это не вопрос экспертности или даже опыта, это вопрос инициативности, заряженности, и желания брать на себя ответственность, как бы это банально не звучало.
Когда лидер берет на себя ответственность он становится тем с кого в конце спрашивают, и это дает ему власть спрашивать с других, потому что все понимают, что он забирает на себя риск и пострадает если что он, а оне они. Он закрывает других своей спиной, и из за этого другие его слушают и помогают.
На бытовом уровне, овнерщип означает:
1️⃣ Одержимость результатом. Если что то критическое не работает, этот человек не заснет пока решение не будет найдено. Если оно не может быть найдено, он предложит альтернативные пути обхода, потому что он видит общую картину, и понимает что варианта не решить у него нет. В лидерских ролях не существует отмазок.
2️⃣ Перфекционизм. Если что то не идеально, он не успокоится пока не будет сделано как надо. Он переживает про каждую деталь, потому что если верхушка принимает тяп-ляп, то ни у кого ниже нет инцентива делать лучше. Я слышал, как люди жалуются на ios 18 и говорят "это было бы невозможно при Стиве Джобсе", потому что он дрючил всех, и не допускал низкого качества, что в итоге определяло планку продуктов эпл. Я сам, каждый наш релиз, отправляю фронтендеру фиксы по отступам, цветам иконок, и обводкам, потому что после меня уже никто об этом не скажет.
3️⃣ Инициативность. И главное, он проактивно ищет новые возможности, и предлагает новые идеи, как улучшить общий результат, а не сидит в комфорте минимума своих прямых обязанностей, потому что упряжка не может бежать быстрее первой лошади. Он должен на своей энергии и одержимости общим успехом тащить всю упряжку и мотивировать других бежать быстрее.
За все это он получает контроль и другие плюшки.
Это точно не привилегия, это просто другая функция, с более широким диапазоном ups and downs. Расположенность к ней определяется исключительно настроем и личной мотивацией (ну и способностью это экзекьютить), и многим это просто не нужно чтобы достичь своих целей.
____
Мы поняли свои проблемы, когда раз за разом, когда у нас падал продукт, или банили домен, ни у кого не горела жопа так, чтобы поднять всех на уши, порисерчить, сделать самому, но решить. Мне приходилось говорить "алё, у нас вообще то прод лежит" или звать Диму. Дошло до того, что я начал проводить дейли синки и спрашивать всех по прогрессу и проверять все ли занимаются самыми приоритетными задачами.
Вышло это так, потому что я верю что можно иметь это лидерство, и этот овнерщип в каждом члене команды, хотя бы на уровне своей зоны ответственности, и мы наверно ожидали увидеть троих СТО, которые втроем будут не спать и переживать о продукте, но из за того что мы не наделили никого конкретно властью, это погубило личную инициативу брать ответственность за весь продукт, так как все стеснялись спрашивать с других. Но мы меняемся.
____
Напоследок, все что я сказал применимо в ровной степени к нашемудизайнеру СЕО. Сейчас, человек "которому больше всех надо"—это я. Но как только появится кто то, кто будет больше переживать про продукт и рост бизнеса, быстрее решать проблемы, и сильнее толкать компанию вперед своими идеями, то он/она станет помощником СЕО .
Как вы знаете, у Dise еще нет CTO. В октябре мы наняли троих очень талантливых и очень амбициозных разрабов, надеясь этот вопрос решить, но что то пошло не так...
Об этом в конце, что важнее, это заставило нас много думать и говорить о лидерстве, и вывести формулу, по которой мы теперь лидерские качества меряем.
Лидер—это тот, кому больше всех надо.
Оказалось это не вопрос экспертности или даже опыта, это вопрос инициативности, заряженности, и желания брать на себя ответственность, как бы это банально не звучало.
Leadership = Ownership + Control Когда лидер берет на себя ответственность он становится тем с кого в конце спрашивают, и это дает ему власть спрашивать с других, потому что все понимают, что он забирает на себя риск и пострадает если что он, а оне они. Он закрывает других своей спиной, и из за этого другие его слушают и помогают.
Не может быть ответственности без власти, и не может быть власти без ответственности
На бытовом уровне, овнерщип означает:
Можно зафейлить задачу, но нельзя зафейлить миссию
За все это он получает контроль и другие плюшки.
Это точно не привилегия, это просто другая функция, с более широким диапазоном ups and downs. Расположенность к ней определяется исключительно настроем и личной мотивацией (ну и способностью это экзекьютить), и многим это просто не нужно чтобы достичь своих целей.
____
Мы поняли свои проблемы, когда раз за разом, когда у нас падал продукт, или банили домен, ни у кого не горела жопа так, чтобы поднять всех на уши, порисерчить, сделать самому, но решить. Мне приходилось говорить "алё, у нас вообще то прод лежит" или звать Диму. Дошло до того, что я начал проводить дейли синки и спрашивать всех по прогрессу и проверять все ли занимаются самыми приоритетными задачами.
Вышло это так, потому что я верю что можно иметь это лидерство, и этот овнерщип в каждом члене команды, хотя бы на уровне своей зоны ответственности, и мы наверно ожидали увидеть троих СТО, которые втроем будут не спать и переживать о продукте, но из за того что мы не наделили никого конкретно властью, это погубило личную инициативу брать ответственность за весь продукт, так как все стеснялись спрашивать с других. Но мы меняемся.
____
Напоследок, все что я сказал применимо в ровной степени к нашему
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Записки MLEшника
TLDR доклада "Как в яндексе делают ранжирование нейросетками в RecSys?"
1. Категориальные фичи кодируют эмбедингами
2. Вещественные фичи нормализуют / делают улучшенную бинаризацию (называют кусочно-линейным кодированием)
3. Используют один слой DCN, чтобы моделировать комбинации признаков
4. Затем 5 MLP слоев и дропаут
5. Добавляют на вход фичи с других моделей по пользователю (например, у них есть трансформер, который делает вектор пользователя по его истории)
6. Делаю несколько голов на несколько действий пользователя (клик, просмотр и тд.)
7. Кормят много данных с большим бачсайзом
8. Лосс на попарное ранжирование (сигмоида от разности логитов двух айтемов)
1. Категориальные фичи кодируют эмбедингами
2. Вещественные фичи нормализуют / делают улучшенную бинаризацию (называют кусочно-линейным кодированием)
3. Используют один слой DCN, чтобы моделировать комбинации признаков
4. Затем 5 MLP слоев и дропаут
5. Добавляют на вход фичи с других моделей по пользователю (например, у них есть трансформер, который делает вектор пользователя по его истории)
6. Делаю несколько голов на несколько действий пользователя (клик, просмотр и тд.)
7. Кормят много данных с большим бачсайзом
8. Лосс на попарное ранжирование (сигмоида от разности логитов двух айтемов)