Около года назад я начал проходить собеседования в разные компании на позицию Machine Learning Engineer. Одним из этапов в каждой компании было проектирование ML системы. В данной статье я делюсь опытом и ресурсами, которые помогли мне пройти собеседования. В том числе в команду MLE Ленты, в которой сейчас тружусь.
Что именно хотят услышать от кандидата?
-
Понимание всех этапов проектирования системы и соблюдение очередности.
-
Правильные вопросы про бизнес требования.
-
Аргументация выбора определенного метода или технологии, обсуждение плюсов и минусов предложенных подходов.
-
Методы борьбы с проблемами, которые обычно бывают в ML задачах. Например, сезонность, cold start, дисбаланс классов, выбросы.
Из каких этапов состоит проектирование системы?
Задача обычно ставилась довольно широко, больше с точки зрения бизнеса. Например, нужно сделать поиск или рекомендации по товарам в е-коммерсе.
Уточнение задачи
Не нужно сразу бросаться решать задачу, а лучше задать как можно больше правильных уточняющих вопросов. В зависимости от интервьюера, можно получить чуть больше информации сразу, но обычно стоит задать несколько вопросов:
-
Какую бизнес метрику оптимизируем? Чего в принципе хотят добиться этой системой?
-
Функциональные требования. Что именно должен уметь твой сервис с точки зрения пользователей?
-
Какие есть ограничения на время ответа? С какой нагрузкой (RPS) будем работать? Какие ограничения на ресурсы (CPU/RAM)?
Будет плюсом, если вместо вопросов вы сможете выдвинуть предположения по каждому пункту, а затем спросить насколько в правильную сторону мыслите. Таким образом покажете, что у вас широкий опыт как с технической точки зрения, так и с продуктовой.
Постановка ML задачи
Прежде чем вдаваться в подробности нужно сразу определиться:
-
Что будет фичами (признаками)?
-
Что будет таргетом (лейблами)?
-
Какой тип обучения будем использовать (классификация, регрессия и т.д)?
Детальная проработка системы
Данные
Данные влияют на решение всей задачи, поэтому им стоит уделить достаточно времени.
-
Какие есть данные на текущий момент? Скорее всего разработчики настроили хоть какое-то логирование, из которого можно собрать датасет.
-
Как собирать данные? Это может быть ручная разметка, парсинг логов системы и т.п
-
Как разбивать данные? Стоит учесть природу данных при ответе на этот вопрос. Не стоит разбивать рандомно, если у вас данные имеют зависимость от времени.
-
Какие особенности еще стоит учесть в фичах и таргете? Самые популярные: сезонность, cold start, выбросы.
Обучение модели
-
Как представить фичи для модели, т.е как именно будем энкодить разные типы фичей? Стоит узнать стандартные подходы для каждого типа данных. Это может быть One-Hot Encoding, эмбеддинги и т.д
-
Как представить таргет для модели? Как его нужно преобразовать, чтобы модели было легче обучаться?
-
Какую модель использовать как бейзлайн?
-
Как бороться с дисбалансом, если он предполагается? Можно упомянуть различные методы оверсемплинга и аугментации (SMOTE, ADASYN), взвешивание классов или использование специальных лоссов.
-
Как бороться с выбросами и некачественной разметкой? Стоит использовать алгоритмы поиска аномалий и здравый смысл.
-
Как бороться с изменением распределения из-за сезонности, мировых событий, праздников?
-
Как можно улучшить бейзлайн? Можно придумать более хитрый лосс, другую архитектуру модели и т.д.
Инференс модели
-
Как будет происходить инференс? Если у нас офлайн система, то процессить будем батчами. При онлайне — поэлементно, но в реальности скорее всего микс обоих подходов.
-
Какую информацию стоит держать предпосчитанной и подтягивать при инференсе? Например, при персонализированном поиске для инференса необходимо подтягивать вектора пользователей.
-
Какие проблемы могут быть при инференсе? Можно упомянуть извечную проблему training-serving skew (расхождение между тренировкой и инференсом модели) и как ее можно решить с помощью фича сторов.
Подсчет офлайн метрик
-
Какую офлайн метрику выбрать, чтобы она максимально коррелировала с потребностями бизнеса? Можно предложить несколько метрик, которые будут показать качество модели с разных сторон.
-
Как учесть дисбаланс классов в метриках и не дать им помешать сделать правильные выводы?
-
Как определить guard метрики, которые не должны быть сломаны ни при каком случае?
Подсчет онлайн метрики
Прежде чем выкатить новую модель на всех пользователей, необходимо сделать A/B тесты. Для этого стоит ответить на несколько вопросов:
-
Какую метрику считать (CR, CTR, revenue и т.д)?
-
Какие статистические критерии использовать (t-test, Манна-Уитни и т.д)?
-
Как разбивать пользователей на тестовую и контрольную выборки?
-
Как долго проводить тест?
Деплой модели
-
Как сервить модель? Для того чтобы обернуть модель в сервис в большинстве случаев работает следующая связка — конвертация модели в ONNX, сервинг через Flask/FastAPI, подготовки образа с помощью Docker и деплой на Kubernetes/Heroku/AWS.
-
Какие еще компоненты нужны для работы модели? Зачастую добавляются сторонние источники данных (Redis, Postgres, S3), необходимые для инициализации модели и ее инференса.
-
Как проверить работоспособность сервиса перед деплоем? Рассказать, какие тесты стоит написать (юнит, интеграционные, системные тесты).
-
Как не вызвать просадки в работоспособности системы при деплое? Есть разные сценарии деплоя (canary/rolling), при котором сервис с моделью обновляется постепенно и не вызывает даунтайм.
-
Как скалировать, чтобы выдерживать высокую нагрузку? Например, поднять несколько инстансов и распределять нагрузку через балансировщик или очередь.
-
Как собирать логи из сервиса? Стоит знать базовый ELK стек и его альтернативы.
-
Как мониторить данные? Хорошо бы знать такие термины, как Data drift, Concept drift, Target Drift. Почему они могут вызвать проблемы с системой? Какими фреймворками их считать?
Мониторинг сервиса
Кроме чтения логов стоит проверять, что:
-
Доля неуспешных запросов не превышает заранее установленное значение.
-
Каждый запрос не превышает заранее установленное время ответа.
-
Используется разумное количество ресурсов (CPU, GPU, memory).
-
Проходит хелфчеки.
Обычно на это не остается время, но можно упомянуть
-
Как организовать хранение моделей и данных?
-
Как организовать пайплайн переобучения?
-
Как мониторить деградацию модели? Можно пересчитывать офлайн метрики на новых данных или считать онлайн метрики, базируясь на логах взаимодействия пользователя с системой.
Что лучше прочитать/пройти перед интервью
-
Если есть пару выходных, то можно пройти небольшой курс от Educative https://www.educative.io/courses/grokking-the-machine-learning-interview
-
Если хочется подготовиться основательно, то стоит прочесть «Designing Machine Learning System» by Chip Huyen
-
Если не сталкивались с рекомендашками, то можно посмотреть курсы от MTS
-
Базовый курс, объясняющий больше про модели и метрики — https://ods.ai/tracks/mts-recsys-df2020
-
Продолжение курса, но уже больше про реальный мир — https://ods.ai/tracks/recsys-course2021
-
-
Достаточно подробно про каждую компоненту ML системы — https://madewithml.com/#mlops
-
Хорошо бы знать, что такое фича сторы и когда они становятся нужны — https://www.tecton.ai/blog/what-is-a-feature-store/
-
Про мониторинг
-
Про А/Б тесты есть замечательные статьи от Авито
-
Лучшие практики машинного обучения от гугла — https://developers.google.com/machine-learning/guides/rules-of-ml
-
Огромная подборка статей по разным темам — https://github.com/eugeneyan/applied-ml
Нужно ли знать про System Design?
ML системы не находятся в вакууме, а являются частью одной большой системы. Поэтому на позицию MLE зачастую ожидают кандидата, который разбирается в инженерке в целом.
Стоит хотя бы немного понимать про архитектуру систем, из каких компонент обычно состоят и как связаны компоненты.
Можно использовать бесплатные ресурсы (https://github.com/donnemartin/system-design-primer, Designing Data-Intensive Applications by Martin Kleppmann) или пройти платные курсы (https://karpov.courses/systemdesign и https://www.educative.io/courses/grokking-the-system-design-interview).
Чего мне не хватало на ML дизайн собеседованиях?
-
Структуры и фреймворка. Бросался от модели к данным, от данных к деплою и забывал спросить про потребности бизнеса.
-
Насмотренности. Как делаются системы в других доменах (рекомендашках, поиске и т.д).
-
Нервов. Я очень сильно переживал на своих первых собеседованиях. Это можно побороть периодическими мок интервью. Эффективнее всего заниматься с опытным ментором раз в неделю. Искать можно на специализированных площадках (Solvery, GetMentor и т.д) или стучаться людям в Linkedin. Также можно использовать платформу для прохождения интервью Prump и его аналоги.
Заключение
Данный фреймворк не является серебряной пулей и прочувствовать его можно только на реальных собесах, поэтому рекомендую как можно раньше пробовать свои силы в бою.
ссылка на оригинал статьи https://habr.com/ru/company/ods/blog/698698/
Добавить комментарий