Как проходить ML system design.

Если литкод собеседование устроено по очень строгим и понятным правилам, то system design сложнее. Здесь главное показать, что вы можете разложить проблему на составляющие и наметить решение.

Как правило вам задают открытый вопрос вида: "Как бы вы сделали систему прогнозирования спроса в супермаркете?" От вас не ждут, что вы эксперт в прогнозировании спроса, хотя если у вас есть релевантные знания это плюс. Просто представьте, что вы уже на работе и вам задают такой вопрос.

Главная ошибка, которую здесь совершают: пытаются натянуть свой прошлый опыт на проблему и закапываются в детали. Надо спрогнозировать спрос, а человек начинает рассказывать, как он бы тюнил градиентный бустинг. Это собеседование не про ваш опыт, а про совместное решение кейса.

Моя личная структура решения таких кейсов:
* В-о-п-р-о-с-ы. Первым делом надо было задавать как можно больше вопросов. Какие есть данные? Сколько данных? Какое качество модели нас устроит? Какое время на предсказания? Какие ошибки для нас страшнее: false positive или false negative?
* Обозначить план работ. Не надо сразу закапываться в какие-то детали. Как правило порядок примерно такой: изучение проблемы -> сбор данных -> бейзлайн -> деплой -> A/B тест -> следующая итерация с более умным решением.
* Придумываем откуда взять данные. Например, если мы в кейсе делаем блок рекомендаций на сайте, то запускаем блок со случайными рекомендациями, смотрим на что кликают и получаем шумные лейблы. Потом делаем умнее: показываем в блоке половину популярных товаров и половину случайных.
* Изучаем данные. Обозначаем интервьюеру, что мы ищем. На этом этапе интервьюер даст еще дополнительных вводных, связанных с доменной информацией. Например, насколько в спросе на типичные товары много сезонности? Можем ли мы отделить покупки товаров со скидками от покупок товаров без скидок, чтобы это не вносило шум в датасет?
* Делаем глупое бейзлайн решение. Помню байку, что Avito нужно было сделать алгоритм, который выберет лучшее фото для объявления. Никто не смог побить бейзлайн "выбрать самое квадратное фото."
* Деплоим глупое решение, запускаем A/B тест, придумываем, как оценивать было улучшение или нет. На этом этапе мы отрабатываем весь пайплайн, чтобы потом встраивать в него более хорошие решения. Здесь можно уже говорить про архитектуру: будем делать предсказания в батч режиме (периодической крон джобой) или онлайн?
* Переходим к ML. Здесь надо первым делом сформулировать задачу в терминах оптимизации. Что на входе, что на выходе. Это классификация, регрессия, ранжирование или что-то еще? Что мы будем минимизировать/максимизировать?
* Выбираем оффлайн метрики для оценки моделей. Например, задачу ранжирования можно свести к классификации. Но выбирать F1 score не стоит, потому что эта метрика не учитывает положение примера в выдаче. Метрика должна быть тем больше, чем выше релевантный элемент и ниже нерелевантный. Например MAP@R. Но знать ее не обязательно, важнее обозначить ее необходимость интервьюеру.
* Описываем как будем принимать решение, достаточно ли новая модель хороша, чтобы ее деплоить. Здесь чаще всего разговор про кросс-валидацию и про то, как связаны наши ML метрики с бизнесовыми.
* Делаем первую простейшую ML модель. Не сложнее логистической регрессии. Деплоим.
* Делаем модель посложнее и итерируемся.
(UPD: как сказали в комментариях, очень хорошая идея поговорить про мониторинг, дообучение и в целом поддержку решения)

Не претендую на универсальность этого подхода, но я пока не получил ни одного отказа после System Design собеседования, так что такая структура явно лучше, чем ничего.