Forwarded from Start Career in DS
Пожалуй, самая подробная статья про градиентные бустинги (да и в целом про деревья решений и всё что с ними связано) на русском языке:
https://habr.com/ru/company/ods/blog/645887/
Тут есть ответы на очень большое количество вопросов, но статью за один присест вряд ли прочитаешь. Когда-то я начал делать цикл роликов по ключевым моментам алгоритмов (линейная регрессия часть 1 и часть 2). Тыкайте 👍 если стоит сделать такие же ролики и по деревьям/бустингам 🙂
https://habr.com/ru/company/ods/blog/645887/
Тут есть ответы на очень большое количество вопросов, но статью за один присест вряд ли прочитаешь. Когда-то я начал делать цикл роликов по ключевым моментам алгоритмов (линейная регрессия часть 1 и часть 2). Тыкайте 👍 если стоит сделать такие же ролики и по деревьям/бустингам 🙂
Хабр
CatBoost, XGBoost и выразительная способность решающих деревьев
Сейчас существенная часть машинного обучения основана на решающих деревьях и их ансамблях, таких как CatBoost и XGBoost, но при этом не все имеют представление о том, как устроены эти алгоритмы...
#quantitative #learn #quant
Какая математика требуется для квантов?
Тервер, матстат, непараметрический матстат, слупы, эконометрика, теория мартингалов, теория больших уклонений, стохастические дифференциальные уравнения, байесовские методы так же не лишними будут, а так же много и много другого в удивительном мире математики
Какая математика требуется для квантов?
Тервер, матстат, непараметрический матстат, слупы, эконометрика, теория мартингалов, теория больших уклонений, стохастические дифференциальные уравнения, байесовские методы так же не лишними будут, а так же много и много другого в удивительном мире математики
#cv #resume #ds #career
Темплейт для резюме
https://ru.overleaf.com/latex/templates/data-science-tech-resume-template/zcdmpfxrzjhv
Темплейт для резюме
https://ru.overleaf.com/latex/templates/data-science-tech-resume-template/zcdmpfxrzjhv
Overleaf
data-science-tech-resume-template
Простой в использовании онлайн редактор LaTeX. Не требует установки, поддерживает совместную работу в реальном времени, контроль версий, сотни шаблонов LaTeX и многое другое.
Forwarded from ML for Value / Ваня Максимов
В канале уже почти месяц не было постов: это потому что я готовил нечто интересное для вас всех) Но обо всем по порядку: на этой неделе небольшие вводные истории, а все лакомое буду писать уже с понедельника
Итак, примерно полгода назад я выступал и рассказывал о способах ускорить А/В тесты. Даже тогда я много времени уделял процессам или "культуре экспериментов"
Можно бесконечно применять CUPED, CUPAC и другие методы, но что делать если:
- Менеджер говорит: "Фича супер важна, нужно выкатить ее еще вчера"?
- Ключевая метрика не красится и предлагается посчитать еще десяток других, которых не было в изначальном дизайне?
- Хотим запустить сразу 20 маркетинговых баннеров в тест?
- Аналитик дизайнит тест аж целый спринт?
Имхо, успешность фичей определяется ответами именно на эти вопросы в вашей "культуре экспериментов". Верхнеуровнево все довольно просто:
1. Появилась идея + ее побрейнштормили внутри команды = конкретное описание фичи
2. Посчитан ожидаемый импакт от фичи в конкретных 1-3 метриках
3. Оцениваем адекватность фичи на пользователях через UX
4. Делаем фичу и проверяем, что она технически работает
5. Смотрим на нескольких боевых пользователях и тестируем edge кейсы
6. Дизайним А/В = приемочные, барьерные и контрольные метрики, сроки и % пользователей
7. Запускаем тест
8. Принимаем решение в соответствии с дизайном
Звучит легко, но в реальности gap между аналитиком, продактом и разработчиком сильно усложняет процесс)
Забыли прокинуть событие в аналитику, не учли важную метрику соседней команды, покатили фичу в пятницу вечером - Узнаете ли свой опыт?)
Серия постов на этой неделе будет посвящена "культуре экспериментов" или "как избежать таких сложностей"
Итак, примерно полгода назад я выступал и рассказывал о способах ускорить А/В тесты. Даже тогда я много времени уделял процессам или "культуре экспериментов"
Можно бесконечно применять CUPED, CUPAC и другие методы, но что делать если:
- Менеджер говорит: "Фича супер важна, нужно выкатить ее еще вчера"?
- Ключевая метрика не красится и предлагается посчитать еще десяток других, которых не было в изначальном дизайне?
- Хотим запустить сразу 20 маркетинговых баннеров в тест?
- Аналитик дизайнит тест аж целый спринт?
Имхо, успешность фичей определяется ответами именно на эти вопросы в вашей "культуре экспериментов". Верхнеуровнево все довольно просто:
1. Появилась идея + ее побрейнштормили внутри команды = конкретное описание фичи
2. Посчитан ожидаемый импакт от фичи в конкретных 1-3 метриках
3. Оцениваем адекватность фичи на пользователях через UX
4. Делаем фичу и проверяем, что она технически работает
5. Смотрим на нескольких боевых пользователях и тестируем edge кейсы
6. Дизайним А/В = приемочные, барьерные и контрольные метрики, сроки и % пользователей
7. Запускаем тест
8. Принимаем решение в соответствии с дизайном
Звучит легко, но в реальности gap между аналитиком, продактом и разработчиком сильно усложняет процесс)
Забыли прокинуть событие в аналитику, не учли важную метрику соседней команды, покатили фичу в пятницу вечером - Узнаете ли свой опыт?)
Серия постов на этой неделе будет посвящена "культуре экспериментов" или "как избежать таких сложностей"
YouTube
Иван Максимов | 13 способов ускорить А/В тест, или "Не CUPED-ом единым"
ML in Marketing hub: https://ods.ai/hubs/ml-in-marketing
Телеграм-канал https://news.1rj.ru/str/mlinmarketing
Спикер: Иван Максимов, Data Science Team Lead at Delivery Club
Многие аналитики для ускорения А/В тестов в первую очередь используют достаточно сложные статистические…
Телеграм-канал https://news.1rj.ru/str/mlinmarketing
Спикер: Иван Максимов, Data Science Team Lead at Delivery Club
Многие аналитики для ускорения А/В тестов в первую очередь используют достаточно сложные статистические…
Forwarded from MISTER SOSISTER ~ CHINESE TIME OF MY LIFE
Как устроен AI в нашем “AI-стартапе”, или что нового я понял перейдя из рисерча в топ-лабах о решении реальных проблем. Рассказываю инженерам.
Это майндсет бизнес-овнера, чем раньше вы его усвоите, тем быстрее вы вылезете из своей песочницы с формулами и начнете делать импакт, а с ним и расти в лид-позиции.
1. Всем поебать что вы там используете, на сколько большие у вас сетки, на сколько инновационный подход, доказана ли у вас полнота пространства, и какой сплит кросс валидации. По большому счету все, за что у вас в академии откусят жёпу, юзеру не интересно, и не влияет на ваш бизнес. Влияет только одно: работает или нет. “Это реально сделать?”, “Много менять придется?”, “Петрович, готов уже МЛ или остужать контейнеры?” – это вопросы которые определяют развитие продукта и ценность МЛ для него. Следовательно.
2. Работать сделать проще всего то, что ты понимаешь и можешь запустить малой кровью. Поэтому самые полезные в реальном применение вещи это эвристики или коробочные решения с простым интерфейсом. Если что-то нужно дописывать, настраивать, подстраивать, контролировать – для этого нужна отдельная команда, и в стартапе на это времени нет. Pro tip: очень хорошо работают комбинации сложных черных ящиков (например трансформеров), которые дают примитивы (например векторы фичей), и простая логика для обработки этих примитивов поверх.
3. Дебажить проще всего то, что ты понимаешь. Никому не нужны сюрпризы в проде. Даже если модель фейлит в 2% случаев, но фейлит конкретно – ее уже нельзя использовать. Поэтому, или такие случаи нужно очень хорошо знать, и подкреплять их эвристикой, или использовать эвристику и простые правила с самого начала.
4. Реальный мир непредсказуем, никаких контролируемых условий нет, все должно быть универсально и пуленепробиваемо. То-есть, никаких 5 гиперпараметров, которые нужно подкручивать для разных knowledge domains, и никакие приближения, типо ограничимся товарами с заказами или магазинами одежды, не проканают. Я вам скажу больше, мы очень старались над тем, чтобы полностью уйти от абсолютных значений, и перевести все в относительную форму. Практически все можно нормализовать, отсортировать и отсечь через статистику (топ-5, нижний квартиль, и тд). Константы вызывают рак.
5. Вы должны хорошо понимать проблему которую юзер решает, и быть способным описать идеальное решение из первых принципов. Жирным, потому что самое важное. Не 1., потому что проебался. Но. Вы не должны оперировать “какими-то” коэффициентами. Вы упростите себе жизнь когда станете понимать, что каждый коэффициент значит, и выбросите все то, что не понимаете. Меньше иногда больше. Таким образом вы сами сможете приходить к известным решениям, но уже с пониманием как они работают, и как они относятся к другим вариантам решения. И я не говорю знать все формулы или доказывать теоремы, я говорю понимать, что вы делаете, и главное почему так, а не иначе. Мы так сами вывели много формул, без сложной теории, а чисто из логики и базовой статистики, и смогли улучшить для нашего конкретного случая то, что другие берут не думая. Например, мы понимаем общий принцип для которого коллаборативная фильтрация является частным случаем, знаем как там информация движется, и можем ее улучшить. Из знания матричной факторизации, что является просто имплементацией, к этому не прийти, вы сможете улучшить только имплементацию. Это как понимать реализацию формулы в коде против понимания того как формула работает. Проверки понимания – вы должны мочь объяснить принцип работы пошагово на пальцах, можно с абстракциями, но без формул.
6. У всего есть цена. Рисерчить новый алгоритм ради рисерча не получится. R&D стоит денег и времени, и в стартапе еще неизвестно что из этого дороже. Как правило, последние 10% результата будут занимать 90% времени, поэтому однозначно надо ориентироваться на первые 10% усилий, и на соотношение impact/effort, а не на accuracy или AUC. (Это как elbow метод, нужно найти момент когда прирост падает я и ваши усилия выходят на асимптоту).
Это майндсет бизнес-овнера, чем раньше вы его усвоите, тем быстрее вы вылезете из своей песочницы с формулами и начнете делать импакт, а с ним и расти в лид-позиции.
1. Всем поебать что вы там используете, на сколько большие у вас сетки, на сколько инновационный подход, доказана ли у вас полнота пространства, и какой сплит кросс валидации. По большому счету все, за что у вас в академии откусят жёпу, юзеру не интересно, и не влияет на ваш бизнес. Влияет только одно: работает или нет. “Это реально сделать?”, “Много менять придется?”, “Петрович, готов уже МЛ или остужать контейнеры?” – это вопросы которые определяют развитие продукта и ценность МЛ для него. Следовательно.
2. Работать сделать проще всего то, что ты понимаешь и можешь запустить малой кровью. Поэтому самые полезные в реальном применение вещи это эвристики или коробочные решения с простым интерфейсом. Если что-то нужно дописывать, настраивать, подстраивать, контролировать – для этого нужна отдельная команда, и в стартапе на это времени нет. Pro tip: очень хорошо работают комбинации сложных черных ящиков (например трансформеров), которые дают примитивы (например векторы фичей), и простая логика для обработки этих примитивов поверх.
3. Дебажить проще всего то, что ты понимаешь. Никому не нужны сюрпризы в проде. Даже если модель фейлит в 2% случаев, но фейлит конкретно – ее уже нельзя использовать. Поэтому, или такие случаи нужно очень хорошо знать, и подкреплять их эвристикой, или использовать эвристику и простые правила с самого начала.
4. Реальный мир непредсказуем, никаких контролируемых условий нет, все должно быть универсально и пуленепробиваемо. То-есть, никаких 5 гиперпараметров, которые нужно подкручивать для разных knowledge domains, и никакие приближения, типо ограничимся товарами с заказами или магазинами одежды, не проканают. Я вам скажу больше, мы очень старались над тем, чтобы полностью уйти от абсолютных значений, и перевести все в относительную форму. Практически все можно нормализовать, отсортировать и отсечь через статистику (топ-5, нижний квартиль, и тд). Константы вызывают рак.
5. Вы должны хорошо понимать проблему которую юзер решает, и быть способным описать идеальное решение из первых принципов. Жирным, потому что самое важное. Не 1., потому что проебался. Но. Вы не должны оперировать “какими-то” коэффициентами. Вы упростите себе жизнь когда станете понимать, что каждый коэффициент значит, и выбросите все то, что не понимаете. Меньше иногда больше. Таким образом вы сами сможете приходить к известным решениям, но уже с пониманием как они работают, и как они относятся к другим вариантам решения. И я не говорю знать все формулы или доказывать теоремы, я говорю понимать, что вы делаете, и главное почему так, а не иначе. Мы так сами вывели много формул, без сложной теории, а чисто из логики и базовой статистики, и смогли улучшить для нашего конкретного случая то, что другие берут не думая. Например, мы понимаем общий принцип для которого коллаборативная фильтрация является частным случаем, знаем как там информация движется, и можем ее улучшить. Из знания матричной факторизации, что является просто имплементацией, к этому не прийти, вы сможете улучшить только имплементацию. Это как понимать реализацию формулы в коде против понимания того как формула работает. Проверки понимания – вы должны мочь объяснить принцип работы пошагово на пальцах, можно с абстракциями, но без формул.
6. У всего есть цена. Рисерчить новый алгоритм ради рисерча не получится. R&D стоит денег и времени, и в стартапе еще неизвестно что из этого дороже. Как правило, последние 10% результата будут занимать 90% времени, поэтому однозначно надо ориентироваться на первые 10% усилий, и на соотношение impact/effort, а не на accuracy или AUC. (Это как elbow метод, нужно найти момент когда прирост падает я и ваши усилия выходят на асимптоту).