Forwarded from я так понимаю, Роман Васильев
💼 Делегировать — сложно, но эффективно! Памятка юного руководителя.
Когда ты джун или мидл, всё просто: тебе дают задачки, ты их делаешь и закрываешь. Со стороны работа руководителя иногда кажется очень простой: сидишь, раздаешь задачки, чилишь, периодически пишешь «ну чё как там?». Однако всё совсем не так просто.
Один из самых важных навыков руководителя — умение делегировать.
В этом посте поделюсь с вами тем, как я это вижу и как можно развивать этот навык (на своём примере)
Чтобы грамотно делегировать, нужно:
1. Понять, какой формат взаимодействия с конкретным человеком будет наиболее эффективен. К примеру, если сотрудник опытный - с ним можно работать на уровне проблем ("у нас падают показатели - разберись, пожалуйста"), а если сотрудник впервые стакливается с проектом/задачей - нужно явно проговорить план решения задачи и контрольные точки
2. Довериться другому человеку. Сделать с ним план решения задачи такой, чтобы ему было комфортно (не уходить в гиперконтроль, но и не оставлять человека один на один с непонятной задачей)
3. Уметь максимально ясно и подробно объяснить, что от человека нужно и для чего это нужно сделать. На языке, который этот человек поймет!
4. Понять, что возможно, всё не получится с первой попытки. Заложить это в сроки проекта и воспринимать спокойно
5. В противовес пункту 3 – четко определить, какое качество и скорость работы приемлемы в этой ситуации, и явно донести это до человека. Иногда — весьма строго. Если сотрудник стабильно не справляется, четко ему об этом сказать
6. Давать возможность человеку ошибаться. Гиперконтроль над сотрудником не позволяет ему учиться на своих ошибках
Как лично я стараюсь развивать эти навыки (помимо основной работы):
1. Общаюсь с руководителями, на которых хочется равняться, и перенимаю лучшие практики от них
2. У меня есть команда, которая занимается проектом Start Career in DS. Стараюсь выстроить процессы в своих проектах максимально эффективно, чтобы ребята могли готовить хорошие посты, сами проверять метрики, делать контент-планы и т. д. Получается весьма хорошо!
3. Периодически беру дополнительные активности, которые позволяют поработать с новой командой. Например, в этом году мы делали Яндекс Кап, в котором пришлось собрать совершенно новую команду (которая не работала вместе ранее)
4. Преподаю. Преподавание позволяет развивать навык объяснения информации таким образом, чтобы люди могли быстро воспринимать абсолютный новый для них материал
5. Учусь. Курсы по управлению иногда кажутся набором максимально очевидных фактов, но среди них можно найти весьма полезные!
К слову, недавно я прошёл очень клёвый курс по менеджменту.
Оставляйте 🔥 если тема для вас интересна и стоит поделиться инсайтами из него 🙂
Когда ты джун или мидл, всё просто: тебе дают задачки, ты их делаешь и закрываешь. Со стороны работа руководителя иногда кажется очень простой: сидишь, раздаешь задачки, чилишь, периодически пишешь «ну чё как там?». Однако всё совсем не так просто.
Один из самых важных навыков руководителя — умение делегировать.
В этом посте поделюсь с вами тем, как я это вижу и как можно развивать этот навык (на своём примере)
Чтобы грамотно делегировать, нужно:
1. Понять, какой формат взаимодействия с конкретным человеком будет наиболее эффективен. К примеру, если сотрудник опытный - с ним можно работать на уровне проблем ("у нас падают показатели - разберись, пожалуйста"), а если сотрудник впервые стакливается с проектом/задачей - нужно явно проговорить план решения задачи и контрольные точки
2. Довериться другому человеку. Сделать с ним план решения задачи такой, чтобы ему было комфортно (не уходить в гиперконтроль, но и не оставлять человека один на один с непонятной задачей)
3. Уметь максимально ясно и подробно объяснить, что от человека нужно и для чего это нужно сделать. На языке, который этот человек поймет!
4. Понять, что возможно, всё не получится с первой попытки. Заложить это в сроки проекта и воспринимать спокойно
5. В противовес пункту 3 – четко определить, какое качество и скорость работы приемлемы в этой ситуации, и явно донести это до человека. Иногда — весьма строго. Если сотрудник стабильно не справляется, четко ему об этом сказать
6. Давать возможность человеку ошибаться. Гиперконтроль над сотрудником не позволяет ему учиться на своих ошибках
Как лично я стараюсь развивать эти навыки (помимо основной работы):
1. Общаюсь с руководителями, на которых хочется равняться, и перенимаю лучшие практики от них
2. У меня есть команда, которая занимается проектом Start Career in DS. Стараюсь выстроить процессы в своих проектах максимально эффективно, чтобы ребята могли готовить хорошие посты, сами проверять метрики, делать контент-планы и т. д. Получается весьма хорошо!
3. Периодически беру дополнительные активности, которые позволяют поработать с новой командой. Например, в этом году мы делали Яндекс Кап, в котором пришлось собрать совершенно новую команду (которая не работала вместе ранее)
4. Преподаю. Преподавание позволяет развивать навык объяснения информации таким образом, чтобы люди могли быстро воспринимать абсолютный новый для них материал
5. Учусь. Курсы по управлению иногда кажутся набором максимально очевидных фактов, но среди них можно найти весьма полезные!
К слову, недавно я прошёл очень клёвый курс по менеджменту.
Оставляйте 🔥 если тема для вас интересна и стоит поделиться инсайтами из него 🙂
Forwarded from ML for Value / Ваня Максимов
Ну ладно, начну первый ☝️
Еще до полноценной работы выше я стажировался на Мосбирже в отделе рисков. То, что мне потом нельзя было около года торговать акциями из-за возможной инсайдерской инфы - это отдельная история))
Зато я узнал, что можно строить линейные регрессии (и любые мл-модели) с заковыристым таргетом:
- q95% доходности (=CVaR, Conditional value at risk)
- Интеграл от q95 до +Inf доходности (=eCVaR, expected CVAR - сколько мы потеряем в среднем в 5% самых плохих сценариев)
Ну и в целом узнал на практике, что в мире рисков применения мат статистики и матана не меньше, чем в современном DL
Еще до полноценной работы выше я стажировался на Мосбирже в отделе рисков. То, что мне потом нельзя было около года торговать акциями из-за возможной инсайдерской инфы - это отдельная история))
Зато я узнал, что можно строить линейные регрессии (и любые мл-модели) с заковыристым таргетом:
- q95% доходности (=CVaR, Conditional value at risk)
- Интеграл от q95 до +Inf доходности (=eCVaR, expected CVAR - сколько мы потеряем в среднем в 5% самых плохих сценариев)
Ну и в целом узнал на практике, что в мире рисков применения мат статистики и матана не меньше, чем в современном DL
Forwarded from Data Secrets
У Google вышла крутая статья про новую архитектуру Titan, которая может победить проблему забывания в трансформерах
Традиционные трансформеры очень прожорливы. Архитектура масштабируется квадратично по мере увеличения длины последовательности. Это приводит к проблеме невозможности увеличения контекстного окна и так называемому забыванию, потому что трансформеры также часто склонны аллоцировать внимание на нерелевантный контекст и, чем он больше, тем больше такая накапливаемая ошибка и степень забывчивости модели.
В Titan же подход к памяти немного иной: помимо краткосрочной памяти attention исследователи добавили в архитектуру долгосрочную память (тут вы, возможно, поймали флешбек на LSTM, и не зря). То есть у нас есть некоторый core – стандартное внимание с ограниченным окном, и модуль, который хранит важную информацию из "далекого прошлого". Чтобы решать, какую информацию запоминать, в нем используется метрика сюрприза (чем "неожиданнее" новые данные для модели, тем важнее их запомнить) + есть коэффициент затухания. Все эффективно параллелится.
При этом в статье показали аж три варианта соединить текущее внимание с долгосрочной памятью:
➖ Memory as Context: долгосрочная память используется как контекст для текущего внимания.
➖ Memory as Gating: здесь прямо максимальный мэтч с LSTM, тот же механизм гейтов
➖ Memory as Layer: самый простой вариант, вся память соединена как слой в сетке
MAC оказался лучше всего по перплексии, а MAL чуть быстрее, но теряет в эффективности. В целом такая архитектура может легким движением руки масштабироваться до контекста в 2+ миллиона токенов, сохраняя стабильную точность (трансформеры начинают обычно фейлить уже после отметки 4096). Очень крутая работа получилась у Google, в общем.
Полный текст статьи здесь
P.S. Очень подробный и понятный разбор архитектуры LSTM от нас можно почитать здесь, а вот тут лежит наша большая статья про другие архитектуры-альтернативы трансформеру
Традиционные трансформеры очень прожорливы. Архитектура масштабируется квадратично по мере увеличения длины последовательности. Это приводит к проблеме невозможности увеличения контекстного окна и так называемому забыванию, потому что трансформеры также часто склонны аллоцировать внимание на нерелевантный контекст и, чем он больше, тем больше такая накапливаемая ошибка и степень забывчивости модели.
В Titan же подход к памяти немного иной: помимо краткосрочной памяти attention исследователи добавили в архитектуру долгосрочную память (тут вы, возможно, поймали флешбек на LSTM, и не зря). То есть у нас есть некоторый core – стандартное внимание с ограниченным окном, и модуль, который хранит важную информацию из "далекого прошлого". Чтобы решать, какую информацию запоминать, в нем используется метрика сюрприза (чем "неожиданнее" новые данные для модели, тем важнее их запомнить) + есть коэффициент затухания. Все эффективно параллелится.
При этом в статье показали аж три варианта соединить текущее внимание с долгосрочной памятью:
MAC оказался лучше всего по перплексии, а MAL чуть быстрее, но теряет в эффективности. В целом такая архитектура может легким движением руки масштабироваться до контекста в 2+ миллиона токенов, сохраняя стабильную точность (трансформеры начинают обычно фейлить уже после отметки 4096). Очень крутая работа получилась у Google, в общем.
Полный текст статьи здесь
P.S. Очень подробный и понятный разбор архитектуры LSTM от нас можно почитать здесь, а вот тут лежит наша большая статья про другие архитектуры-альтернативы трансформеру
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from КПД
Inference-Time Scaling for Diffusion Models beyond Scaling Denoising Steps
[Статья][DeepMind не часто публикует код]
Введение
Данная статья уже появлялась на Love. Death. Transformers и была разобрана у Сиолошной . Тем не менее, выскажу свое скромное мнение 😉.
Inference-time scaling уже продемонстрировал впечатляющие результаты в контексте языковых моделей, где длинные цепочки рассуждений позволяют значительно улучшать качество на сложных задачах.
У диффузионных моделей механизм улучшения качества генераций за счет большего объема вычислений есть “из 📦” - выбор количества шагов сэмплирования. С ростом количества шагов расшумления качество полученных генераций и их соответствие запросу 🔼, но начиная с какого-то момента происходит насыщение, и дальнейшее повышение не приводит к значимым улучшениям, а иногда даже наоборот.
Поэтому в данной статье предлагают улучшать генерации за счет сэмплирования разных случайных шумов, начальных точек в процессе генерации, и выборе лучшего случайного зерна 🌱.
[Статья][DeepMind не часто публикует код]
Введение
Данная статья уже появлялась на Love. Death. Transformers и была разобрана у Сиолошной . Тем не менее, выскажу свое скромное мнение 😉.
Inference-time scaling уже продемонстрировал впечатляющие результаты в контексте языковых моделей, где длинные цепочки рассуждений позволяют значительно улучшать качество на сложных задачах.
У диффузионных моделей механизм улучшения качества генераций за счет большего объема вычислений есть “из 📦” - выбор количества шагов сэмплирования. С ростом количества шагов расшумления качество полученных генераций и их соответствие запросу 🔼, но начиная с какого-то момента происходит насыщение, и дальнейшее повышение не приводит к значимым улучшениям, а иногда даже наоборот.
Поэтому в данной статье предлагают улучшать генерации за счет сэмплирования разных случайных шумов, начальных точек в процессе генерации, и выборе лучшего случайного зерна 🌱.
Forwarded from Aspiring Data Science (Anatoly Alekseev)
#hpt #hpo #critics
Суммаризировал свои претензии к современным подборщикам гиперпараметров.
1) Не надо говорить, что тюнинг моделей - это black box optimization. Никакая это не новая уникальная задача, где неизвестно, что происходит под капотом, мы одну и ту же задачу решаем день за днём, день за днём, даже данные зачастую похожи. Можно, конечно, притворяться, что для нас каждый раз как первый раз, но имхо это тупо.
2) Вот хочу я затюнить градиентный бустинг над деревьями с помощью Optuna или Hyperopt. Почему я должен каждый раз указывать, какие гиперпараметры я хочу оптимизировать? Они что, часто меняются у xgboost-а? В современных моделях их несколько десятков. Я не хочу их все помнить. Я не знаю, какие из них важны. Я не хочу каждый раз разбираться, какие комбинации совместимы, а какие нет. Ваша библиотека мне жизнь упрощать собирается или нет?
3) Хоть как-то учитываются значения целевой функции в ближайших окрестностях найденных оптимальных параметров? Да конечно, нет, всем начхать на это, тебе находят точечное "лучшее" решение, которое потом на поверку оказывается крайне нестабильным.
4) Байесовская оптимизация с помощью гауссовых процессов - ну это не круто, слишком слабая модель. Вы хоть раз слышали, чтобы сореву на каггле выиграли гауссовым процессом?
5) мне не нравится, что всё CPU/GPU время, которое я палю при HPT некоторой задачи, служит лишь какой-то временной цели, никак не обобщается, и никак не поможет мне (или другим людям) при решении подобных задач в будущем.
6) Ни в одной доке библиотек HPO/HPT я не видел оценок, каких же преимуществ, в терминах ML метрик, можно ждать от тюнинга. Казалось бы, авторы проводят много тестов, в т.ч. автоматизированных, им и карты в руки, ну поделитесь вы статистикой? но нет.
7) а хоть одна из библиотек байесовской оптимизации, предлагая очередных кандидатов, вообще оценивает время обучения модели при таких параметрах?
8) вопрос к алгоритмам HalvingSearch/Hyperband, а насколько надёжно по ранним итерациям можно судить о том, какая метрика будет достигнута к концу обучения? А как же нелинейности кривой обучения? А мы точно так не откинем хорошие решения, которые наибольший "импульс" получают к концу обучения?
9) а хоть одна библа вообще смотрит на декоррелированность прогнозов модели с прогнозами других моделей? это же такая естественная мысль. моделька же не в вакууме будет жить, а, скорей всего, в ансамбле.
THERE SHOULD BE A BETTER WAY!!
Суммаризировал свои претензии к современным подборщикам гиперпараметров.
1) Не надо говорить, что тюнинг моделей - это black box optimization. Никакая это не новая уникальная задача, где неизвестно, что происходит под капотом, мы одну и ту же задачу решаем день за днём, день за днём, даже данные зачастую похожи. Можно, конечно, притворяться, что для нас каждый раз как первый раз, но имхо это тупо.
2) Вот хочу я затюнить градиентный бустинг над деревьями с помощью Optuna или Hyperopt. Почему я должен каждый раз указывать, какие гиперпараметры я хочу оптимизировать? Они что, часто меняются у xgboost-а? В современных моделях их несколько десятков. Я не хочу их все помнить. Я не знаю, какие из них важны. Я не хочу каждый раз разбираться, какие комбинации совместимы, а какие нет. Ваша библиотека мне жизнь упрощать собирается или нет?
3) Хоть как-то учитываются значения целевой функции в ближайших окрестностях найденных оптимальных параметров? Да конечно, нет, всем начхать на это, тебе находят точечное "лучшее" решение, которое потом на поверку оказывается крайне нестабильным.
4) Байесовская оптимизация с помощью гауссовых процессов - ну это не круто, слишком слабая модель. Вы хоть раз слышали, чтобы сореву на каггле выиграли гауссовым процессом?
5) мне не нравится, что всё CPU/GPU время, которое я палю при HPT некоторой задачи, служит лишь какой-то временной цели, никак не обобщается, и никак не поможет мне (или другим людям) при решении подобных задач в будущем.
6) Ни в одной доке библиотек HPO/HPT я не видел оценок, каких же преимуществ, в терминах ML метрик, можно ждать от тюнинга. Казалось бы, авторы проводят много тестов, в т.ч. автоматизированных, им и карты в руки, ну поделитесь вы статистикой? но нет.
7) а хоть одна из библиотек байесовской оптимизации, предлагая очередных кандидатов, вообще оценивает время обучения модели при таких параметрах?
8) вопрос к алгоритмам HalvingSearch/Hyperband, а насколько надёжно по ранним итерациям можно судить о том, какая метрика будет достигнута к концу обучения? А как же нелинейности кривой обучения? А мы точно так не откинем хорошие решения, которые наибольший "импульс" получают к концу обучения?
9) а хоть одна библа вообще смотрит на декоррелированность прогнозов модели с прогнозами других моделей? это же такая естественная мысль. моделька же не в вакууме будет жить, а, скорей всего, в ансамбле.
THERE SHOULD BE A BETTER WAY!!
Forwarded from Дратути Антон
Учиться быть руководителем
Тема весьма избитая, скорее всего, кто-то вам может тут вам выпулить супер курс с кучей ресурсов. Здесь лишь про моё мнение!
Я искренне убеждён, что нужно учиться быть руководителем🌿 . Нет такого, что у кого-то от природы дар вести проекты, строить процессы, развивать сотрудников и т.д.
Аналогия из разработки очень простая: ты можешь учиться пользоваться инструментом, а можешь методом тыка и интуиции попробовать им воспользоваться. И то, и друго работает, но есть нюанс😀 . Одно дело пользоваться браузером, а другое — ПО для управления атомным реактором. Вот управление для меня — это сродни второму примеру, где важен каждый компонент, где неверное решение может с одной стороны невелироваться сложностью системы, а с другой стороны запустить медленный процесс с большими последствиями 🤯 .
Учиться можно по разному. Например, я выделяю для себя следующие ресурсы в порядке приоритетов:
— Мой руководитель и лиды в моей службе. Это самые ближайшие люди, которые имеют прямо здесь и сейчас очень богатый опыт и готовы им поделиться, нужно лишь только придти. Ребят, если читаете — спасибо вам, что помогаете мне😍 ;
— Youtube. Я часто смотрю выступления со конференций, по типу Teamlead Conf, а также смотрю подкасты с разными руководителями, чтобы подчерпнуть их опыт, понять их образ мышления;
— Книги. У меня не получается много читать, но тем не менее, иногда получается подчерпнуть важную информацию. Особенно полезно возвращаться, когда хочешь проработать конкретный кейс.
Из того, что я не делаю, но пора бы начать🔼 :
— Нетворк. Слушать руководителей в команде хорошо, слушать умных людей в ютубе тоже хорошо. Но еще хорошо иметь товарищей не из моего отдела, не из компании, чтобы взаимоопыляться. Тут хорошо бы найти способы нетворкаться, если знаете — пишите в комментарии;
— Курсы. Хорошие курсы — это в первую очередь пришедшие туда люди и экспертиза наставников с большим стажем;
— Конференции. Одна из баз для нетворка и иногда нетривиальных выводов.
Какие навыки развивать? Оооооо, ну тут всё очень сложно. Нужно справедливо себе отвечать на вопрос — "а что проседает сейчас?". Это нормально, если всё пока около нуля (хотя скорее всего, вы себя недооцениваете). Как вариант придти к своему руководителю и попробовать вместе с ним выстроить приоритеты.
Какие навыки бывают? Разные. Я как-то смотрел на карту тимлида (https://tlroadmap.io/), общался с руководителем, и среди всех мнений выписал, а на что нужно фокусироваться.
Сколько времени надо? Много. Некоторые вещи и за год сложно сформировать (например, стратегическое мышление, как мне кажется), а что-то приходит в сознание относительно быстро (например, какие практики имеет смысл использовать в команде). К сожалению, руководителем нельзя стать за 21 день (тут я больше верю в обучении C++).
Какой бы я себе дал совет 5 лет назад (именно тогда я начал задумываться про руководство)? Начинай учиться. Удивительно, но когда начинаешь понимать образ мыслей руководителей, начинаешь понимать, чо они от тебя все хотят. Ретроспективно я проследил за собой, чего от меня хотели руководители в тех или иных ситуациях, когда я был разработчиком.
Ставьте 🔥, если хотите побольше такого материала. Пишите комменты, что думаете про эту тему сами.
Вы всегда можете побустить мой канал: https://t.me/blog_toxa?boost
Тема весьма избитая, скорее всего, кто-то вам может тут вам выпулить супер курс с кучей ресурсов. Здесь лишь про моё мнение!
Я искренне убеждён, что нужно учиться быть руководителем
Аналогия из разработки очень простая: ты можешь учиться пользоваться инструментом, а можешь методом тыка и интуиции попробовать им воспользоваться. И то, и друго работает, но есть нюанс
Учиться можно по разному. Например, я выделяю для себя следующие ресурсы в порядке приоритетов:
— Мой руководитель и лиды в моей службе. Это самые ближайшие люди, которые имеют прямо здесь и сейчас очень богатый опыт и готовы им поделиться, нужно лишь только придти. Ребят, если читаете — спасибо вам, что помогаете мне
— Youtube. Я часто смотрю выступления со конференций, по типу Teamlead Conf, а также смотрю подкасты с разными руководителями, чтобы подчерпнуть их опыт, понять их образ мышления;
— Книги. У меня не получается много читать, но тем не менее, иногда получается подчерпнуть важную информацию. Особенно полезно возвращаться, когда хочешь проработать конкретный кейс.
Из того, что я не делаю, но пора бы начать
— Нетворк. Слушать руководителей в команде хорошо, слушать умных людей в ютубе тоже хорошо. Но еще хорошо иметь товарищей не из моего отдела, не из компании, чтобы взаимоопыляться. Тут хорошо бы найти способы нетворкаться, если знаете — пишите в комментарии;
— Курсы. Хорошие курсы — это в первую очередь пришедшие туда люди и экспертиза наставников с большим стажем;
— Конференции. Одна из баз для нетворка и иногда нетривиальных выводов.
Какие навыки развивать? Оооооо, ну тут всё очень сложно. Нужно справедливо себе отвечать на вопрос — "а что проседает сейчас?". Это нормально, если всё пока около нуля (хотя скорее всего, вы себя недооцениваете). Как вариант придти к своему руководителю и попробовать вместе с ним выстроить приоритеты.
Какие навыки бывают? Разные. Я как-то смотрел на карту тимлида (https://tlroadmap.io/), общался с руководителем, и среди всех мнений выписал, а на что нужно фокусироваться.
Сколько времени надо? Много. Некоторые вещи и за год сложно сформировать (например, стратегическое мышление, как мне кажется), а что-то приходит в сознание относительно быстро (например, какие практики имеет смысл использовать в команде). К сожалению, руководителем нельзя стать за 21 день (тут я больше верю в обучении C++).
Какой бы я себе дал совет 5 лет назад (именно тогда я начал задумываться про руководство)? Начинай учиться. Удивительно, но когда начинаешь понимать образ мыслей руководителей, начинаешь понимать, чо они от тебя все хотят. Ретроспективно я проследил за собой, чего от меня хотели руководители в тех или иных ситуациях, когда я был разработчиком.
Ставьте 🔥, если хотите побольше такого материала. Пишите комменты, что думаете про эту тему сами.
Вы всегда можете побустить мой канал: https://t.me/blog_toxa?boost
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Дратути Антон
Визибилити
На выходных просмотрел роликов несколько роликов с канала: https://www.youtube.com/@tobecto. Мне, конечно, рано быть😀 , но всегда интересно послушать людей, которые думают на больших масштабах. Я кайфанул с многих роликов, но по вайбу заполнился Эмиль Абдулнасыров, CTO Ламоды. Ролик про человека, который явно что-то понял в этой жизни 🔼 !
Но среди всего есть еще и видео про визибилити: https://www.youtube.com/watch?v=A8OK2mvH17Y. Он выбивается из формата, о чём ребята сразу же и говорят. Мне бы этот ролик, да года 4 назад🥺 .
Весь подкаст ребята пытаются построить определение, что же такое "визибилити". Это может быть прозрачность действий, это может быть личная видимость на разных уровнях. В общем, термин многогранен.
Для себя я подчерпнул следующее:
1. Модель для донесения информации о том, чем ты сейчас занимаешься, может быть следующей: продукт, технологии, люди.
2. Нужно понимать, на каком уровне мыслит руководитель и поставлять в понятном для него виде информацию. Ну, например, странно будет придти СТО и рассказывать 10 минут о том, как вы чинили какой-то мелкий баг👨🦳 ;
3. Информация должна быть записана и доступна. У руководителя всегда должен быть доступ к информации о текущем статусе проекта.
4. Визибилити иногда решает, кому доверить проект. В ролике была озвучена аналогия с ремонтной бригадой: когда люди обычно выбирают, с кем делать ремонт, в первую очередь они спрашивают у знакомых, редко оперируя терминами, подходящими под KPI. Типа: "Ну норм ребятам сделали, да были пару косяков, но в целом хорошо".
Также было и правда много интересных мыслей между делом. Записал себе на проработку, через пару месяцев вернусь, гляну — ок не ок😍 .
Это, кстати, один из тех роликов про образ мышления людей старше. Рекомендую смотреть всем🌿
На выходных просмотрел роликов несколько роликов с канала: https://www.youtube.com/@tobecto. Мне, конечно, рано быть
Но среди всего есть еще и видео про визибилити: https://www.youtube.com/watch?v=A8OK2mvH17Y. Он выбивается из формата, о чём ребята сразу же и говорят. Мне бы этот ролик, да года 4 назад
Весь подкаст ребята пытаются построить определение, что же такое "визибилити". Это может быть прозрачность действий, это может быть личная видимость на разных уровнях. В общем, термин многогранен.
Для себя я подчерпнул следующее:
1. Модель для донесения информации о том, чем ты сейчас занимаешься, может быть следующей: продукт, технологии, люди.
2. Нужно понимать, на каком уровне мыслит руководитель и поставлять в понятном для него виде информацию. Ну, например, странно будет придти СТО и рассказывать 10 минут о том, как вы чинили какой-то мелкий баг
3. Информация должна быть записана и доступна. У руководителя всегда должен быть доступ к информации о текущем статусе проекта.
4. Визибилити иногда решает, кому доверить проект. В ролике была озвучена аналогия с ремонтной бригадой: когда люди обычно выбирают, с кем делать ремонт, в первую очередь они спрашивают у знакомых, редко оперируя терминами, подходящими под KPI. Типа: "Ну норм ребятам сделали, да были пару косяков, но в целом хорошо".
Также было и правда много интересных мыслей между делом. Записал себе на проработку, через пару месяцев вернусь, гляну — ок не ок
Это, кстати, один из тех роликов про образ мышления людей старше. Рекомендую смотреть всем
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Quant Valerian
Нельзя слепо брать лучшие практики от успешных компаний
Я взял себя в руки и продолжил, наконец, читать Thinking Fast and Slow. И был вознаграждён! Там есть про менеджмент 😁
В главе о ретроспективном искажении обсуждается, что на результаты работы компании, без сомнений, влияет навык менеджера и удача. Так же, как, например, на успехи спортсмена влияет талант, навык и удача.
И так же, как у Талеба в Dynamic Hedging на успех трейдера влияет навык и удача.
Это вообще говоря нетривиальная мысль! Хотя там в следующей главе написано, что как только ты узнал что-то, то часто начинаешь думать, что знал всегда. Мне вас не убедить, я в книжке читал!
Так вот. Утверждается, что есть некие исследования, согласно которым, по самой оптимистичной оценке, корреляция успеха компании с навыками менеджмента составляет всего 0,3. У меня есть очевидные вопросы к тому, как это считали, но как-будто звучит вполне реалистично.
Это в свою очередь означает что-то типа, что у нас 70% случайного шума и 30% навыков и 10% в мощности колёс (играет трек Fort Minor).
Это нам говорит о том, что в целом бесполезно наблюдать за успешными компаниями и копировать их фишки. Ещё это нам напоминает, что книга Цель — художественный вымысел и таких результатов достичь одними процессами нельзя.
Что нам остаётся тогда, чтобы принимать управленческие решения, выбирать подходы и методы? Получается, что только логика и прикладной опыт (чтобы сделать поправки в своих предпосылках и с новыми вводными применять логику).
А че там Талеб предлагал, чтобы найти реально грамотного трейдера? Вообще он предлагал почитать исследовательские статьи (там типа параметрические тесты есть с учетом перфоманса рынка), но по существу нужно смотреть на частоту сделок и риск, который берёт трейдер.
Перекладывая его совет на управление, делаю вывод: если мы считаем, что у нас есть какой-то навык (edge, что мы лучше рандома), то нужно принимать низкорисковые решения и делать это почаще. Тогда мы будем быстрее сходиться к тренду за счёт своего навыка.
Картинки дальше 👇👇👇👇👇
Я взял себя в руки и продолжил, наконец, читать Thinking Fast and Slow. И был вознаграждён! Там есть про менеджмент 😁
В главе о ретроспективном искажении обсуждается, что на результаты работы компании, без сомнений, влияет навык менеджера и удача. Так же, как, например, на успехи спортсмена влияет талант, навык и удача.
И так же, как у Талеба в Dynamic Hedging на успех трейдера влияет навык и удача.
Это вообще говоря нетривиальная мысль! Хотя там в следующей главе написано, что как только ты узнал что-то, то часто начинаешь думать, что знал всегда. Мне вас не убедить, я в книжке читал!
Так вот. Утверждается, что есть некие исследования, согласно которым, по самой оптимистичной оценке, корреляция успеха компании с навыками менеджмента составляет всего 0,3. У меня есть очевидные вопросы к тому, как это считали, но как-будто звучит вполне реалистично.
Это в свою очередь означает что-то типа, что у нас 70% случайного шума и 30% навыков и 10% в мощности колёс (играет трек Fort Minor).
Это нам говорит о том, что в целом бесполезно наблюдать за успешными компаниями и копировать их фишки. Ещё это нам напоминает, что книга Цель — художественный вымысел и таких результатов достичь одними процессами нельзя.
Что нам остаётся тогда, чтобы принимать управленческие решения, выбирать подходы и методы? Получается, что только логика и прикладной опыт (чтобы сделать поправки в своих предпосылках и с новыми вводными применять логику).
А че там Талеб предлагал, чтобы найти реально грамотного трейдера? Вообще он предлагал почитать исследовательские статьи (там типа параметрические тесты есть с учетом перфоманса рынка), но по существу нужно смотреть на частоту сделок и риск, который берёт трейдер.
Перекладывая его совет на управление, делаю вывод: если мы считаем, что у нас есть какой-то навык (edge, что мы лучше рандома), то нужно принимать низкорисковые решения и делать это почаще. Тогда мы будем быстрее сходиться к тренду за счёт своего навыка.
Картинки дальше 👇👇👇👇👇
Forwarded from Сиолошная
This media is not supported in your browser
VIEW IN TELEGRAM
Всё никак не дойдут руки нормально написать про R1 и DeepSeek (ждите на неделе), а умельцы из Unsloth взяли этого гиганта весом более чем в 700 гигабайт и пожали в ~150-180 (влезет в 3 карты по 80GB).
Да так пожали, что модель всё ещё выдаёт что-то адекватное — смотрите на гифке генерации аналога игры FlappyBird. Авторы делали 3 генерации и оценивали их по 10-бальной шкале по нескольким критериям, и пожатая модель выбивала 9+)
Секрет в том, что отбирают примерно ~12% самых важных весов (первые слои + shared-эксперты + SuperWeights) и оставляют их почти не сжатыми, а остальные (в основном веса экспертов) квантизируются по методу 1.58 bit от Microsoft (помните была такая статья хайповая?).
Больше деталей в блогпосте, но я удивлён, что прям ТАК жмётся. Интересно дождаться замеров нормальных метрик, насколько сильно проседает по широкому набору бенчмарков, включая знания (не только рассуждения).
UPD: написали, что версия, которая влазит в 2 GPU (она пожата чуть больше -> качество хуже) выдаёт 140 токенов в секунду (что больше чем у любых провайдеров и у o1 — в несколько раз).
Да так пожали, что модель всё ещё выдаёт что-то адекватное — смотрите на гифке генерации аналога игры FlappyBird. Авторы делали 3 генерации и оценивали их по 10-бальной шкале по нескольким критериям, и пожатая модель выбивала 9+)
Секрет в том, что отбирают примерно ~12% самых важных весов (первые слои + shared-эксперты + SuperWeights) и оставляют их почти не сжатыми, а остальные (в основном веса экспертов) квантизируются по методу 1.58 bit от Microsoft (помните была такая статья хайповая?).
Больше деталей в блогпосте, но я удивлён, что прям ТАК жмётся. Интересно дождаться замеров нормальных метрик, насколько сильно проседает по широкому набору бенчмарков, включая знания (не только рассуждения).
UPD: написали, что версия, которая влазит в 2 GPU (она пожата чуть больше -> качество хуже) выдаёт 140 токенов в секунду (что больше чем у любых провайдеров и у o1 — в несколько раз).
Forwarded from Quant Researcher
Зачем учить базу в финансах?
Чтобы не переизобретать велосипед, как сделали авторы одной статьи. Они обучили сложную нейронку, докрутили RL и для весов выбрали функцию, которая очень напоминает классическое Sharpe Ratio.
Весь этот сложный алгоритм можно заменить на простой портфель Марковица с Efficient Frontier или в лоб Mean-Variance Optimization.
Это самая типичная ошибка, которую совершают Data-Scientists в финансах. Сразу пытаются зарядить супер-сложный алгоритм или нейронку. В итоге выходит не лучше любого базового алгоритма. По этой же причине более 99% статей по ML в финансах никогда не показывают положительный PnL на проде.
Чтобы не совершать таких ошибок, надо учить базу. Можно начать с книги Де Прадо:
1. *Advances in Financial Machine Learning* – ссылка
2. *Machine Learning for Asset Managers* – ссылка
А вся база выложена здесь: 20 обязательных книг для кванта
Quant Researcher
Чтобы не переизобретать велосипед, как сделали авторы одной статьи. Они обучили сложную нейронку, докрутили RL и для весов выбрали функцию, которая очень напоминает классическое Sharpe Ratio.
Весь этот сложный алгоритм можно заменить на простой портфель Марковица с Efficient Frontier или в лоб Mean-Variance Optimization.
Это самая типичная ошибка, которую совершают Data-Scientists в финансах. Сразу пытаются зарядить супер-сложный алгоритм или нейронку. В итоге выходит не лучше любого базового алгоритма. По этой же причине более 99% статей по ML в финансах никогда не показывают положительный PnL на проде.
Чтобы не совершать таких ошибок, надо учить базу. Можно начать с книги Де Прадо:
1. *Advances in Financial Machine Learning* – ссылка
2. *Machine Learning for Asset Managers* – ссылка
А вся база выложена здесь: 20 обязательных книг для кванта
Quant Researcher
Forwarded from Душный NLP
Интересные решения из технического отчёта DeepSeek-V3 — часть I
В конце прошлого года вышел технический отчёт модели DeepSeek-V3. У неё 671 миллиардов параметров, из которых активные — 37 миллиардов (то есть меньше 1/16). Обучение длилось два месяца на 2 тысячах GPU H800. Впервые в истории LLM обучали на FP8 и с высокой степенью разреженности (sparsity). Полученная модель вошла в топ-10 на Chatbot Arena. Кроме того, DeepSeek-V3 хорошо показывала себя в бенчмарках.
Изучили технический отчёт и рассказываем, какие необычные и даже новаторские решения в нём есть. Обзор получился объёмным, поэтому мы поделили его на два поста.
MLA
Метод, который называется Multi-head Latent Attention (MLA), используют как альтернативу Grouped Query Attention (GQA) для снижения объёма KV-кэша. Этот подход апробировали ещё в июне 2024 года в DeepSeek-V2. Как утверждают разработчики, по качеству MLA превосходит GQA и Multi-Query Attention и сопоставим с Multi-Head Attention.
Суть MLA заключается в сжатии скрытого представления в латентные вектора и хранении их на продакшене вместо Key Value. Во время генерации токенов KV восстанавливается из латентных векторов, что требует отдельных, но не слишком затратных вычислений.
Такой подход позволяет здорово экономить память, однако лишает возможности применять Rotary Position Embedding (RoPE) — способ несовместим с низкоранговым сжатием KV. Чтобы обойти проблему, в DeepSeek прибегли к методу Decoupled Rotary Position Embedding. Он предполагает добавление к каждой голове вектора с RoPE.
В результате не происходит деградации качества из-за того, что для большей части каждой головы позиционные эмбеддинги не обрабатываются. При этом модель сохраняет способность учитывать очень длинные контексты, так как её производительность не ухудшается даже при значительном удалении токенов от начальной позиции.
После претрейна разработчики расширили контекст, используя YaRN-подход (Yet another RoPE extension) — c 4 тысяч токенов до 128 тысяч. В тесте Needle In A Haystack, по условиям которого нужно найти ответ на вопрос в контексте на 128 тысяч токенов, DeepSeek-V3 в 100% случаев справлялась с задачей. Сама по себе она несложная, но демонстрирует умение модели работать с большими контекстами.
MoE
По сравнению с DeepSeek-V2 изменился подход к Mixture-of-Experts. Здесь есть общие эксперты (Shared experts), которые применяются ко всем входным токенам, и маршрутизируемые эксперты (Routed experts), среди которых выбираются лучшие для решения конкретной задачи.
Специальный лосс для контроля загруженности экспертов не используется. Вместо этого для каждого эксперта вводится определённый bias, через который и осуществляется балансировка. Если эксперт вызывается слишком часто, то bias уменьшается, слишком редко — увеличивается. Благодаря этому обучение получается более стабильным, чем при использовании лоссов.
Однако разработчикам всё-таки пришлось ввести балансировочный лосс. Описанный выше способ приводит к тому, что эксперты становятся домен-специфичными. Дополнительный лосс позволяет избежать этого, создавая разнообразие в выдаче. Благодаря хорошей балансировке нагрузки в процессе обучения DeepSeek-V3 не отбрасывает ни одного токена.
Для снижения затрат на коммуникации использовали метод Node-Limited Routing. Он вводит ограничение на число хостов, куда может быть направлен токен. Сперва выбираются хосты, которые содержат необходимых экспертов, а затем среди них с помощью алгоритма top-K routing выбираются лучшие для конкретного токена.
Во второй части расскажем о FP8-квантизации, результатах на бенчмарках и не только. Не переключайтесь!
Разбор подготовил❣ Михаил Хрущев
Душный NLP
В конце прошлого года вышел технический отчёт модели DeepSeek-V3. У неё 671 миллиардов параметров, из которых активные — 37 миллиардов (то есть меньше 1/16). Обучение длилось два месяца на 2 тысячах GPU H800. Впервые в истории LLM обучали на FP8 и с высокой степенью разреженности (sparsity). Полученная модель вошла в топ-10 на Chatbot Arena. Кроме того, DeepSeek-V3 хорошо показывала себя в бенчмарках.
Изучили технический отчёт и рассказываем, какие необычные и даже новаторские решения в нём есть. Обзор получился объёмным, поэтому мы поделили его на два поста.
MLA
Метод, который называется Multi-head Latent Attention (MLA), используют как альтернативу Grouped Query Attention (GQA) для снижения объёма KV-кэша. Этот подход апробировали ещё в июне 2024 года в DeepSeek-V2. Как утверждают разработчики, по качеству MLA превосходит GQA и Multi-Query Attention и сопоставим с Multi-Head Attention.
Суть MLA заключается в сжатии скрытого представления в латентные вектора и хранении их на продакшене вместо Key Value. Во время генерации токенов KV восстанавливается из латентных векторов, что требует отдельных, но не слишком затратных вычислений.
Такой подход позволяет здорово экономить память, однако лишает возможности применять Rotary Position Embedding (RoPE) — способ несовместим с низкоранговым сжатием KV. Чтобы обойти проблему, в DeepSeek прибегли к методу Decoupled Rotary Position Embedding. Он предполагает добавление к каждой голове вектора с RoPE.
В результате не происходит деградации качества из-за того, что для большей части каждой головы позиционные эмбеддинги не обрабатываются. При этом модель сохраняет способность учитывать очень длинные контексты, так как её производительность не ухудшается даже при значительном удалении токенов от начальной позиции.
После претрейна разработчики расширили контекст, используя YaRN-подход (Yet another RoPE extension) — c 4 тысяч токенов до 128 тысяч. В тесте Needle In A Haystack, по условиям которого нужно найти ответ на вопрос в контексте на 128 тысяч токенов, DeepSeek-V3 в 100% случаев справлялась с задачей. Сама по себе она несложная, но демонстрирует умение модели работать с большими контекстами.
MoE
По сравнению с DeepSeek-V2 изменился подход к Mixture-of-Experts. Здесь есть общие эксперты (Shared experts), которые применяются ко всем входным токенам, и маршрутизируемые эксперты (Routed experts), среди которых выбираются лучшие для решения конкретной задачи.
Специальный лосс для контроля загруженности экспертов не используется. Вместо этого для каждого эксперта вводится определённый bias, через который и осуществляется балансировка. Если эксперт вызывается слишком часто, то bias уменьшается, слишком редко — увеличивается. Благодаря этому обучение получается более стабильным, чем при использовании лоссов.
Однако разработчикам всё-таки пришлось ввести балансировочный лосс. Описанный выше способ приводит к тому, что эксперты становятся домен-специфичными. Дополнительный лосс позволяет избежать этого, создавая разнообразие в выдаче. Благодаря хорошей балансировке нагрузки в процессе обучения DeepSeek-V3 не отбрасывает ни одного токена.
Для снижения затрат на коммуникации использовали метод Node-Limited Routing. Он вводит ограничение на число хостов, куда может быть направлен токен. Сперва выбираются хосты, которые содержат необходимых экспертов, а затем среди них с помощью алгоритма top-K routing выбираются лучшие для конкретного токена.
Во второй части расскажем о FP8-квантизации, результатах на бенчмарках и не только. Не переключайтесь!
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM