Forwarded from ML for Value / Ваня Максимов
Оптимизация цен на товары: прогноз спроса
Фундаментальная задача везде, но вокруг неё так много мифов! Давайте начнём разбираться с базы
Q = Q(P) - спрос в штуках, зависит от цены
P - цена
C - издержки на 1 штуку товара
Базово задача - максимизировать прибыль:
Q(P) * (P - C) --> max
И самое сложное - смоделировать зависимость Q(P)
Экономисты предполагают, что спрос складывается из многих таких выборов между продавцами, товарами и тд. Поэтому
Важна не абсолютная цена (79 руб), а относительная (Р/ P_competitor = +2% к цене конкурента, P / P_analogue = -5% к цене товара-аналога, P/ P_yesterday = +3% к вчерашней цене этого же товара)
Поэтому функция спроса на товары
Q = f(P/ P_competitor, P / P_analogue, ...)
Вообще, теоретически, на этом можно остановиться и применять наш любимый ML для прогноза Q с фичами на относительные цены. Но в реальности все сложнее 😅
Об этом - в следующих постах
Фундаментальная задача везде, но вокруг неё так много мифов! Давайте начнём разбираться с базы
Q = Q(P) - спрос в штуках, зависит от цены
P - цена
C - издержки на 1 штуку товара
Базово задача - максимизировать прибыль:
Q(P) * (P - C) --> max
И самое сложное - смоделировать зависимость Q(P)
Экономисты предполагают, что спрос складывается из многих таких выборов между продавцами, товарами и тд. Поэтому
Важна не абсолютная цена (79 руб), а относительная (Р/ P_competitor = +2% к цене конкурента, P / P_analogue = -5% к цене товара-аналога, P/ P_yesterday = +3% к вчерашней цене этого же товара)
Поэтому функция спроса на товары
Q = f(P/ P_competitor, P / P_analogue, ...)
Вообще, теоретически, на этом можно остановиться и применять наш любимый ML для прогноза Q с фичами на относительные цены. Но в реальности все сложнее 😅
Об этом - в следующих постах
Forwarded from ИЦ "ГЕВИССТА"
Forwarded from ИЦ "ГЕВИССТА"
Таблица гиперпараметров CatBoost.pdf
226.9 KB
Таблица гиперпараметров CatBoost
Как уже писал, сейчас работаю над обновлением модуля по бустингу. Эта таблица из устаревшей версии, тем не менее большинство гиперпараметров актуально, пользуйтесь.
Как уже писал, сейчас работаю над обновлением модуля по бустингу. Эта таблица из устаревшей версии, тем не менее большинство гиперпараметров актуально, пользуйтесь.
Forwarded from ИЦ "ГЕВИССТА"
BoostARoota. Часть 1
Многие знают такой метод отбора признаков, как Boruta. Boruta показывает хорошие результаты в сочетании со случайным лесом, но имеет при этом недостаток – медленные вычисления, особенно на данных больших размеров. Вне зависимости от времени вычислений, Boruta плохо работает на других алгоритмах, таких как бустинг или нейронные сети, хоть и хорошо работает на случайных лесах. Аналогичные проблемы возникают с регуляризацией LASSO, эластичной сетью или гребневой регрессией – они хорошо работают на линейных регрессиях, но плохо на других современных алгоритмах.
В 2016 году Чейз Дэхан представил алгоритм отбора признаков BoostARoota, который похож на Boruta, но использует в качестве базовой модели не случайный лес, а XGBoost. Алгоритм требует гораздо меньших затрат времени на выполнение, в отличие от Boruta, и обладает сопоставимым с Boruta качеством на различных наборах данных. Хотя идея алгоритма идейно близка Boruta, BoostARoota использует немного другой подход для удаления признаков, который выполняется намного быстрее. Перед применением необходимо выполнить дамми-кодирование, поскольку базовая модель работает только с количественными признаками.
Подобно принципу работы Boruta, BoostARoota создает «теневые» признаки, но отличается модифицированным этапом удаления.
1. Удваивает ширину полученного набора, создавая копии всех признаков исходного набора.
2. Случайным образом перемешивает значения новых признаков. Эти дублированные и перемешанные признаки называются «теневыми».
3. Запускает десять раз XGBoost на всем наборе данных. Обучение алгоритма десять раз позволяет сгладить случайный шум, что дает более устойчивые оценки важностей. Количество повторов – это параметр, который можно изменить.
4. Получает значения важностей для каждого признака. Это простой показатель важности, который суммирует, сколько раз конкретный признак использовался в качестве предиктора разбиения в алгоритме XGBoost (тип важности weight).
5. Вычисляет «порог отсечения»: среднее значение важности для всех «теневых» признаков, поделенное на четыре. Деление значения «теневой» важности на четыре (параметр можно изменить) предназначено для регулирования агрессивности удаления переменных. При значении «порога отсечения» меньше 4 признаки удаляются слишком агрессивно.
6. Удаляет признаки, средняя важность которых по результатам десяти итераций меньше «порога отсечения», указанного на шаге 5.
7. Возвращается обратно в пункт (1), т.е. запускает новый раунд и так, пока количество удаленных признаков не станет меньше десяти процентов от их общего количества, или пока не будет выполнено заданное количество раундов.
8. По завершении метод возвращает оставшиеся признаки.
Установить BoostARoota можно с помощью команды
# импортируем класс BoostARoota
Многие знают такой метод отбора признаков, как Boruta. Boruta показывает хорошие результаты в сочетании со случайным лесом, но имеет при этом недостаток – медленные вычисления, особенно на данных больших размеров. Вне зависимости от времени вычислений, Boruta плохо работает на других алгоритмах, таких как бустинг или нейронные сети, хоть и хорошо работает на случайных лесах. Аналогичные проблемы возникают с регуляризацией LASSO, эластичной сетью или гребневой регрессией – они хорошо работают на линейных регрессиях, но плохо на других современных алгоритмах.
В 2016 году Чейз Дэхан представил алгоритм отбора признаков BoostARoota, который похож на Boruta, но использует в качестве базовой модели не случайный лес, а XGBoost. Алгоритм требует гораздо меньших затрат времени на выполнение, в отличие от Boruta, и обладает сопоставимым с Boruta качеством на различных наборах данных. Хотя идея алгоритма идейно близка Boruta, BoostARoota использует немного другой подход для удаления признаков, который выполняется намного быстрее. Перед применением необходимо выполнить дамми-кодирование, поскольку базовая модель работает только с количественными признаками.
Подобно принципу работы Boruta, BoostARoota создает «теневые» признаки, но отличается модифицированным этапом удаления.
1. Удваивает ширину полученного набора, создавая копии всех признаков исходного набора.
2. Случайным образом перемешивает значения новых признаков. Эти дублированные и перемешанные признаки называются «теневыми».
3. Запускает десять раз XGBoost на всем наборе данных. Обучение алгоритма десять раз позволяет сгладить случайный шум, что дает более устойчивые оценки важностей. Количество повторов – это параметр, который можно изменить.
4. Получает значения важностей для каждого признака. Это простой показатель важности, который суммирует, сколько раз конкретный признак использовался в качестве предиктора разбиения в алгоритме XGBoost (тип важности weight).
5. Вычисляет «порог отсечения»: среднее значение важности для всех «теневых» признаков, поделенное на четыре. Деление значения «теневой» важности на четыре (параметр можно изменить) предназначено для регулирования агрессивности удаления переменных. При значении «порога отсечения» меньше 4 признаки удаляются слишком агрессивно.
6. Удаляет признаки, средняя важность которых по результатам десяти итераций меньше «порога отсечения», указанного на шаге 5.
7. Возвращается обратно в пункт (1), т.е. запускает новый раунд и так, пока количество удаленных признаков не станет меньше десяти процентов от их общего количества, или пока не будет выполнено заданное количество раундов.
8. По завершении метод возвращает оставшиеся признаки.
Установить BoostARoota можно с помощью команды
pip install boostaroota. Затем импортируем класс BoostARoota и создаем экземпляр класса BoostARoota.# импортируем класс BoostARoota
from boost_preprocessing import BoostARoota
br = BoostARoota(clf=None,
cutoff=4,
iters=10,
max_rounds=100,
delta=0.1,
silent=False)Forwarded from Ilya Gusev
Курс Лены Войты: https://lena-voita.github.io/nlp_course.html
Stanford CS224N: https://www.youtube.com/playlist?list=PLoROMvodv4rOhcuXMZkNm7j3fVwBBY42z
Speech and Language Processing: https://web.stanford.edu/~jurafsky/slp3/
Прикладные курсы:
- https://github.com/yandexdataschool/nlp_course
- https://github.com/DanAnastasyev/DeepNLP-Course
Основные статьи:
- Word2Vec: Mikolov et al., Efficient Estimation of Word Representations in Vector Space https://arxiv.org/pdf/1301.3781.pdf
- FastText: Bojanowski et al., Enriching Word Vectors with Subword Information https://arxiv.org/pdf/1607.04606.pdf
- Attention: Bahdanau et al., Neural Machine Translation by Jointly Learning to Align and Translate: https://arxiv.org/abs/1409.0473
- Transformers: Vaswani et al., Attention Is All You Need https://arxiv.org/abs/1706.03762
- BERT: Devlin et al., BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding https://arxiv.org/abs/1810.0480
Stanford CS224N: https://www.youtube.com/playlist?list=PLoROMvodv4rOhcuXMZkNm7j3fVwBBY42z
Speech and Language Processing: https://web.stanford.edu/~jurafsky/slp3/
Прикладные курсы:
- https://github.com/yandexdataschool/nlp_course
- https://github.com/DanAnastasyev/DeepNLP-Course
Основные статьи:
- Word2Vec: Mikolov et al., Efficient Estimation of Word Representations in Vector Space https://arxiv.org/pdf/1301.3781.pdf
- FastText: Bojanowski et al., Enriching Word Vectors with Subword Information https://arxiv.org/pdf/1607.04606.pdf
- Attention: Bahdanau et al., Neural Machine Translation by Jointly Learning to Align and Translate: https://arxiv.org/abs/1409.0473
- Transformers: Vaswani et al., Attention Is All You Need https://arxiv.org/abs/1706.03762
- BERT: Devlin et al., BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding https://arxiv.org/abs/1810.0480
Forwarded from Nikita
просто свои 5 копеек вкину, вдруг кому интересно
есть прикольный чувак, у него есть плейлисты в частности как писать с помощью RL ботов
https://www.youtube.com/channel/UCfzlCWGWYyIQ0aLC5w48gBQ
для GTA и StarCraft (да и вообще канал клевый)
есть прикольный чувак, у него есть плейлисты в частности как писать с помощью RL ботов
https://www.youtube.com/channel/UCfzlCWGWYyIQ0aLC5w48gBQ
для GTA и StarCraft (да и вообще канал клевый)
Forwarded from тревожный эйчар
Media is too big
VIEW IN TELEGRAM
💌 Запись эфира «Как увлечь работой себя и свою команду»
Что успели обсудить за час:
— почему можно не искать work-life balance и все равно пребывать в гармонии;
— как позволить себе быть собой на работе и что это меняет в жизни;
— о чем важно не забывать в атмосфере кризиса, чтобы не угнетать себя;
— и многое другое.
Спасибо Александре и Максиму за насыщенный и яркий эфир 🤍
Пожалуйста, оставьте обратную связь про эфир под этим постом. Как вам разговор и о чем еще вы хотели бы послушать?
Что успели обсудить за час:
— почему можно не искать work-life balance и все равно пребывать в гармонии;
— как позволить себе быть собой на работе и что это меняет в жизни;
— о чем важно не забывать в атмосфере кризиса, чтобы не угнетать себя;
— и многое другое.
Спасибо Александре и Максиму за насыщенный и яркий эфир 🤍
Пожалуйста, оставьте обратную связь про эфир под этим постом. Как вам разговор и о чем еще вы хотели бы послушать?
Forwarded from Борис опять
Как проходить ML system design.
Если литкод собеседование устроено по очень строгим и понятным правилам, то system design сложнее. Здесь главное показать, что вы можете разложить проблему на составляющие и наметить решение.
Как правило вам задают открытый вопрос вида: "Как бы вы сделали систему прогнозирования спроса в супермаркете?" От вас не ждут, что вы эксперт в прогнозировании спроса, хотя если у вас есть релевантные знания это плюс. Просто представьте, что вы уже на работе и вам задают такой вопрос.
Главная ошибка, которую здесь совершают: пытаются натянуть свой прошлый опыт на проблему и закапываются в детали. Надо спрогнозировать спрос, а человек начинает рассказывать, как он бы тюнил градиентный бустинг. Это собеседование не про ваш опыт, а про совместное решение кейса.
Моя личная структура решения таких кейсов:
* В-о-п-р-о-с-ы. Первым делом надо было задавать как можно больше вопросов. Какие есть данные? Сколько данных? Какое качество модели нас устроит? Какое время на предсказания? Какие ошибки для нас страшнее: false positive или false negative?
* Обозначить план работ. Не надо сразу закапываться в какие-то детали. Как правило порядок примерно такой: изучение проблемы -> сбор данных -> бейзлайн -> деплой -> A/B тест -> следующая итерация с более умным решением.
* Придумываем откуда взять данные. Например, если мы в кейсе делаем блок рекомендаций на сайте, то запускаем блок со случайными рекомендациями, смотрим на что кликают и получаем шумные лейблы. Потом делаем умнее: показываем в блоке половину популярных товаров и половину случайных.
* Изучаем данные. Обозначаем интервьюеру, что мы ищем. На этом этапе интервьюер даст еще дополнительных вводных, связанных с доменной информацией. Например, насколько в спросе на типичные товары много сезонности? Можем ли мы отделить покупки товаров со скидками от покупок товаров без скидок, чтобы это не вносило шум в датасет?
* Делаем глупое бейзлайн решение. Помню байку, что Avito нужно было сделать алгоритм, который выберет лучшее фото для объявления. Никто не смог побить бейзлайн "выбрать самое квадратное фото."
* Деплоим глупое решение, запускаем A/B тест, придумываем, как оценивать было улучшение или нет. На этом этапе мы отрабатываем весь пайплайн, чтобы потом встраивать в него более хорошие решения. Здесь можно уже говорить про архитектуру: будем делать предсказания в батч режиме (периодической крон джобой) или онлайн?
* Переходим к ML. Здесь надо первым делом сформулировать задачу в терминах оптимизации. Что на входе, что на выходе. Это классификация, регрессия, ранжирование или что-то еще? Что мы будем минимизировать/максимизировать?
* Выбираем оффлайн метрики для оценки моделей. Например, задачу ранжирования можно свести к классификации. Но выбирать F1 score не стоит, потому что эта метрика не учитывает положение примера в выдаче. Метрика должна быть тем больше, чем выше релевантный элемент и ниже нерелевантный. Например MAP@R. Но знать ее не обязательно, важнее обозначить ее необходимость интервьюеру.
* Описываем как будем принимать решение, достаточно ли новая модель хороша, чтобы ее деплоить. Здесь чаще всего разговор про кросс-валидацию и про то, как связаны наши ML метрики с бизнесовыми.
* Делаем первую простейшую ML модель. Не сложнее логистической регрессии. Деплоим.
* Делаем модель посложнее и итерируемся.
(UPD: как сказали в комментариях, очень хорошая идея поговорить про мониторинг, дообучение и в целом поддержку решения)
Не претендую на универсальность этого подхода, но я пока не получил ни одного отказа после System Design собеседования, так что такая структура явно лучше, чем ничего.
Если литкод собеседование устроено по очень строгим и понятным правилам, то system design сложнее. Здесь главное показать, что вы можете разложить проблему на составляющие и наметить решение.
Как правило вам задают открытый вопрос вида: "Как бы вы сделали систему прогнозирования спроса в супермаркете?" От вас не ждут, что вы эксперт в прогнозировании спроса, хотя если у вас есть релевантные знания это плюс. Просто представьте, что вы уже на работе и вам задают такой вопрос.
Главная ошибка, которую здесь совершают: пытаются натянуть свой прошлый опыт на проблему и закапываются в детали. Надо спрогнозировать спрос, а человек начинает рассказывать, как он бы тюнил градиентный бустинг. Это собеседование не про ваш опыт, а про совместное решение кейса.
Моя личная структура решения таких кейсов:
* В-о-п-р-о-с-ы. Первым делом надо было задавать как можно больше вопросов. Какие есть данные? Сколько данных? Какое качество модели нас устроит? Какое время на предсказания? Какие ошибки для нас страшнее: false positive или false negative?
* Обозначить план работ. Не надо сразу закапываться в какие-то детали. Как правило порядок примерно такой: изучение проблемы -> сбор данных -> бейзлайн -> деплой -> A/B тест -> следующая итерация с более умным решением.
* Придумываем откуда взять данные. Например, если мы в кейсе делаем блок рекомендаций на сайте, то запускаем блок со случайными рекомендациями, смотрим на что кликают и получаем шумные лейблы. Потом делаем умнее: показываем в блоке половину популярных товаров и половину случайных.
* Изучаем данные. Обозначаем интервьюеру, что мы ищем. На этом этапе интервьюер даст еще дополнительных вводных, связанных с доменной информацией. Например, насколько в спросе на типичные товары много сезонности? Можем ли мы отделить покупки товаров со скидками от покупок товаров без скидок, чтобы это не вносило шум в датасет?
* Делаем глупое бейзлайн решение. Помню байку, что Avito нужно было сделать алгоритм, который выберет лучшее фото для объявления. Никто не смог побить бейзлайн "выбрать самое квадратное фото."
* Деплоим глупое решение, запускаем A/B тест, придумываем, как оценивать было улучшение или нет. На этом этапе мы отрабатываем весь пайплайн, чтобы потом встраивать в него более хорошие решения. Здесь можно уже говорить про архитектуру: будем делать предсказания в батч режиме (периодической крон джобой) или онлайн?
* Переходим к ML. Здесь надо первым делом сформулировать задачу в терминах оптимизации. Что на входе, что на выходе. Это классификация, регрессия, ранжирование или что-то еще? Что мы будем минимизировать/максимизировать?
* Выбираем оффлайн метрики для оценки моделей. Например, задачу ранжирования можно свести к классификации. Но выбирать F1 score не стоит, потому что эта метрика не учитывает положение примера в выдаче. Метрика должна быть тем больше, чем выше релевантный элемент и ниже нерелевантный. Например MAP@R. Но знать ее не обязательно, важнее обозначить ее необходимость интервьюеру.
* Описываем как будем принимать решение, достаточно ли новая модель хороша, чтобы ее деплоить. Здесь чаще всего разговор про кросс-валидацию и про то, как связаны наши ML метрики с бизнесовыми.
* Делаем первую простейшую ML модель. Не сложнее логистической регрессии. Деплоим.
* Делаем модель посложнее и итерируемся.
(UPD: как сказали в комментариях, очень хорошая идея поговорить про мониторинг, дообучение и в целом поддержку решения)
Не претендую на универсальность этого подхода, но я пока не получил ни одного отказа после System Design собеседования, так что такая структура явно лучше, чем ничего.
Forwarded from commit history
Этап собеседования Machine Learning System Design.
Этот этап попадался в 9 из 10 компаний. Задача - полностью спроектировать ML решение. От определения задачи и метрик, заканчивая деплоем и оптимизацией.
Здесь важный момент. Время собеседования ограничено. Поэтому с одной стороны важно не растекаться по дереву, с другой стороны важно покрыть все этапы решения ML задачи, а в некоторые даже погрузиться вглубь, чтобы показать что шарите.
В этом помогает четкая структура ответа:
1. Problem definition and requirement clarification. Определение задачи и оценка требований.
2. Data. Источники данных, какая разметка, как выглядит сэмпл.
3. Evaluation. Какие метрики, сравнение с бейзлайном.
4. Features and model. Препроцессинг, варианты моделей.
5. Online eval, deploy. Выкатка + АБ.
6. Further actions. Как дебажить/обновлять/улучшать/ускорять/итд модель.
Каждый из этапов более подробно разобран в репе ML design primer.
Порядок подготовки.
+ Посмотреть видео fb, яндекса, полистать гитхаб ml design primer.
+ Сделать себе пробный собес попробовать задизайнить систему из списка.
+ Почитать пару разборов из технических блогов компаний или инженеров. Например, тут или тут
+ Делать моки (mock-interview). Это когда вы созваниваетесь и устраиваете друг-другу пробный собес. Моки можно искать в этом чате.
+ Получаете фидбек с мока и идете качать слабые места, читаете еще статьи или главы из 329s.
Этот этап попадался в 9 из 10 компаний. Задача - полностью спроектировать ML решение. От определения задачи и метрик, заканчивая деплоем и оптимизацией.
Здесь важный момент. Время собеседования ограничено. Поэтому с одной стороны важно не растекаться по дереву, с другой стороны важно покрыть все этапы решения ML задачи, а в некоторые даже погрузиться вглубь, чтобы показать что шарите.
В этом помогает четкая структура ответа:
1. Problem definition and requirement clarification. Определение задачи и оценка требований.
2. Data. Источники данных, какая разметка, как выглядит сэмпл.
3. Evaluation. Какие метрики, сравнение с бейзлайном.
4. Features and model. Препроцессинг, варианты моделей.
5. Online eval, deploy. Выкатка + АБ.
6. Further actions. Как дебажить/обновлять/улучшать/ускорять/итд модель.
Каждый из этапов более подробно разобран в репе ML design primer.
Порядок подготовки.
+ Посмотреть видео fb, яндекса, полистать гитхаб ml design primer.
+ Сделать себе пробный собес попробовать задизайнить систему из списка.
+ Почитать пару разборов из технических блогов компаний или инженеров. Например, тут или тут
+ Делать моки (mock-interview). Это когда вы созваниваетесь и устраиваете друг-другу пробный собес. Моки можно искать в этом чате.
+ Получаете фидбек с мока и идете качать слабые места, читаете еще статьи или главы из 329s.
Forwarded from commit history
Как сформулировать ML задачу?
Каждый этап разбирать не буду, но о первым расскажу на примере. Допустим, дали задачу сделать фид для контента. Цель: хотим сделать рекомендации контента(текстовые посты, картинки, видео). Текущая лента обратная хронологическая, хочется сделать персонализированной.
Первый вопрос: зачем? Кажется, что с персональной лентой пользователи будут чаще заходить, залипать в ленте, шерить продукт друзьям. Но, это только предположение, которое нуждается в проверке. Поэтому на старте определимся, как будем оценивать успех или неуспех в количественных показателях.
Продуктовые метрики в рамках собеседования я для себя разделил на три уровня:
1. Деньги 💰– revenue, arpu, конверсии в покупку.
2. Счастье юзера 😍 – like/view rate, avg session time, views count, etc
3. Технические метрики 🎯– recall@k, diversity of items, etc. Соответственно цель наша больше денег, а гипотеза в том, что повысив технические метрики –> повысим счастье юзера –> заработаем больше деньги. В жизни, к сожалению, зависимость не всегда прямая. Но для задачи этот момент опустим.
В cs329s этот этап разбит на 4 шага.
1. Framing. Какая ML проблема? Регрессия, Классификация - multiclass, multilabel.
2. Objectives. На какие подзадачи можно разделить? Например, Прокачать engagement ленты, но при этом не уронить качество постов, не форсить спам и кликбейты.
3. Constraints. Ограничения ресурсов, приватность данных, требования регуляторов.
4. Phases. Как будете внедрять решение: эвристика -> простая модель -> оптимизация простой модели -> сложная модель.
По данному пункту советую полистать лекцию 2 в cs329s и если что-то непонятно посмотреть в Lecture Note.
Еще один важный момент: на этом этапе задавать уточняющие вопросы, чтобы понять контекст задачи: как решается задача сейчас, число пользователей, доступные ресурсы итп.
Каждый этап разбирать не буду, но о первым расскажу на примере. Допустим, дали задачу сделать фид для контента. Цель: хотим сделать рекомендации контента(текстовые посты, картинки, видео). Текущая лента обратная хронологическая, хочется сделать персонализированной.
Первый вопрос: зачем? Кажется, что с персональной лентой пользователи будут чаще заходить, залипать в ленте, шерить продукт друзьям. Но, это только предположение, которое нуждается в проверке. Поэтому на старте определимся, как будем оценивать успех или неуспех в количественных показателях.
Продуктовые метрики в рамках собеседования я для себя разделил на три уровня:
1. Деньги 💰– revenue, arpu, конверсии в покупку.
2. Счастье юзера 😍 – like/view rate, avg session time, views count, etc
3. Технические метрики 🎯– recall@k, diversity of items, etc. Соответственно цель наша больше денег, а гипотеза в том, что повысив технические метрики –> повысим счастье юзера –> заработаем больше деньги. В жизни, к сожалению, зависимость не всегда прямая. Но для задачи этот момент опустим.
В cs329s этот этап разбит на 4 шага.
1. Framing. Какая ML проблема? Регрессия, Классификация - multiclass, multilabel.
2. Objectives. На какие подзадачи можно разделить? Например, Прокачать engagement ленты, но при этом не уронить качество постов, не форсить спам и кликбейты.
3. Constraints. Ограничения ресурсов, приватность данных, требования регуляторов.
4. Phases. Как будете внедрять решение: эвристика -> простая модель -> оптимизация простой модели -> сложная модель.
По данному пункту советую полистать лекцию 2 в cs329s и если что-то непонятно посмотреть в Lecture Note.
Еще один важный момент: на этом этапе задавать уточняющие вопросы, чтобы понять контекст задачи: как решается задача сейчас, число пользователей, доступные ресурсы итп.
Google Docs
cs329s_2022_02_slides_mlsd
Machine Learning Systems Design Lecture 2: ML and Data Systems Fundamentals Reply in Zoom chat: What MLOps tools would you want tutorials on? CS 329S (Chip Huyen, 2022) | cs329s.stanford.edu
Forwarded from Anton Plaksin
Увы этого в курсе освещено не будет. Этот курс про самые основы. Чтобы иметь более широкое представление о том, что сейчас происходит в RL могу порекомендовать этот цикл докладов. Ну и конечно читать статьи https://www.youtube.com/playlist?list=PLt1IfGj6-_-eXjZDFBfnAhAJmCyX227ir
YouTube
Advanced Topics in Reinforcement Learning
The idea of this course is to concentrate on modern research in the RL and to analyze significant articles over the past few years. https://deeppavlov.ai/rl_...