System design#
System design это разновидность технического собеседования, когда вам предлагается порассуждать о решении кейса. На этом этапе проверяются ваш подход к решению задачи, профессиональная эрудиция и знание подходов в индустрии, опыт в разработке продакшн систем, умение рассуждать.
Note
Приведу пример кейса. Вы работаете в маркетплейсе, где поставщики могут размещать свои товары. Вам необходимо сделать блок рекомендованных товаров на главной странице. Как вы подойдете к этой проблеме?
Главная ошибка: сразу броситься описывать какие вы знаете ML алгоритмы, применимые к задаче. К сожалению, это в корне неверный подход. Не стоит путать system design с обычным техническим интервью, где вам задают вопросы, а вы отвечаете.
System design интервью это имитация реального процесса работы, когда к вам приходят с проблемой, а не с техническим вопросом, и вам необходимо придумать решение. Важно: от вас не ожидают, что вы знаете всё о предметной области и расскажете всё по памяти. Часто system design кейсы будут не по вашей специальности. Интервьюеры смотрят на то, как вы подходите к решению, как вы добываете нужную информацию, какие вопросы задаете, какие делаете выводы на основе имеющихся ограничений.
Структура#
Решение system design кейсов это в первую очередь совместное рассуждение вместе с интервьюером. Оно должно следовать определенной структуре. Во-первых, она поможет вам не запутаться. Во-вторых, она позволит интервьюеру понять, как вы подходите к решению проблемы.
Приведу пример структуры, которой я следую сам. Она не является единственно верной, но она работает для меня.
Задавать вопросы и выяснить все доступные нам предположения.
Всегда стоит начинать с вопросов. Пропустив этот этап, вы рискуете неверно понять задачу, предложить неподходящее решение или запутаться.
Например, для кейса выше я бы задал следующие вопросы:
Какая цель блока рекомендованных товаров? Какую бизнес метрику мы максимизируем?
Какое у нас количество товаров? Как часто они обновляются? Какое количество пользователей?
Какие есть ограничения на скорость работы системы?
Оффлайн и онлайн метрики, методы сравнения решений.
Стоит сразу определить, как мы будем оценивать качество нашего решения.
Онлайн метрики мы можем наблюдать только после запуска в продакшн. Примерм онлайн метрик могут быть CTR (click-through rate), средний чек, конверсия в покупку. Внедрив блок рекомендаций, мы сможем оценить, улучшает он целевые метрики или нет.
Стоит обозначить, как именно мы будем сравнивать решения по онлайн метрикам. В данном случае очевидный выбор это A/B тестирование. Следует сразу упомянуть, как именно мы будем разделять пользователей на группы.
Оффлайн метрики — это то, что мы можем посчитать на исторических данных. Мы используем их, чтобы сравнивать ML модели. Для системы рекомендаций подойдут метрики ранжирования, например normalized discounted cumulative gain или mean average precision. Здесь стоит упомянуть, как вы будете делать кросс-валидацию моделей. В случае с рекомендательным блоком нужно учесть фактор, что данные одного пользователя не должны попасть одновременно в обучающую и тестовую выборки, а также временную компоненту.
Сбор данных.
Следующим шагом обозначим, откуда мы будем брать данные для обучения моделей. В нашем случае данных по ранжированию нет, но мы можем использовать историю покупок пользователей чтобы получить данные вида (признаки товара, признаки пользователя, купил пользователь товар или нет). С этим уже можно работать.
Бейзлайн решение.
Следующим шагом я предлагаю сделать бейзлайн решение. Это простое решение, вероятно без всякого машинного обучения, которое мы можем сделать быстро и использовать для проверки гипотезы о том, что рекомендательный блок улучшит метрики, и для обкатки процесса деплоя в продакшн.
Например, мы можем показывать самые популярные товары или товары, которые пользователь недавно просматривал. В случае данного кейса, как часто бывает, бейзлайн можно использовать для сбора данных: мы узнаем, на какие товары в блоке пользователи кликали, а на какие нет.
Простое ML решение.
Наконец, мы переходим к машинному обучению. Стоит предложить наиболее простое решение. Например, мы можем обучить логистическую регрессию на истории покупок пользователей, которая будет предсказывать вероятность покупки. Вероятности можно использовать для реранкинга выдачи, то есть для выбора топ-N товаров из бейзлайн решения, которые мы будем показывать в блоке рекомендаций.
Деплой в продакшн.
Описываем важные детали того, как простое решение будет развернуто в продакшн среде. Например, мы можем использовать сервисы AWS.
Сложное ML решение и дальнейшие итерации.
На этом этапе мы можем предложить более сложное решение, а также предположения о том, как можно улучшать систему дальше.
Например, для рекомендательного блока можно построить двухэтапную систему рекомендаций. Первый этап генерирует кандидатов более сложным методом, чем бейзлайн. Например, мы можем спроецировать эмбеддинги пользователей и товаров в одно пространство с помощью нейронной сети, обучая её по методу contrastive learning. Второй этап это реранкинг кандидатов, который можно делать с помощью градиентного бустинга.
🤗 Если этот материал был для вас полезен есть два способа отблагодарить меня:
Прислать ссылку на методичку своему другу.
Подписаться на мой телеграм канал.