Что я бы хотел знать про ML System Design раньше20.11.2022 19:31

b1555534d12fc6d6a240f4f8768c8259.jpg

Около года назад я начал проходить собеседования в разные компании на позицию Machine Learning Engineer. Одним из этапов в каждой компании было проектирование ML системы. В данной статье я делюсь опытом и ресурсами, которые помогли мне пройти собеседования. В том числе в команду MLE Ленты, в которой сейчас тружусь.

Что именно хотят услышать от кандидата?

  1. Понимание всех этапов проектирования системы и соблюдение очередности.

  2. Правильные вопросы про бизнес требования.

  3. Аргументация выбора определенного метода или технологии, обсуждение плюсов и минусов предложенных подходов.

  4. Методы борьбы с проблемами, которые обычно бывают в ML задачах. Например, сезонность, cold start, дисбаланс классов, выбросы.

Из каких этапов состоит проектирование системы?

Задача обычно ставилась довольно широко, больше с точки зрения бизнеса. Например, нужно сделать поиск или рекомендации по товарам в е-коммерсе.

Уточнение задачи

Не нужно сразу бросаться решать задачу, а лучше задать как можно больше правильных уточняющих вопросов. В зависимости от интервьюера, можно получить чуть больше информации сразу, но обычно стоит задать несколько вопросов:

  1. Какую бизнес метрику оптимизируем? Чего в принципе хотят добиться этой системой?

  2. Функциональные требования. Что именно должен уметь твой сервис с точки зрения пользователей?

  3. Какие есть ограничения на время ответа? С какой нагрузкой (RPS) будем работать? Какие ограничения на ресурсы (CPU/RAM)?

Будет плюсом, если вместо вопросов вы сможете выдвинуть предположения по каждому пункту, а затем спросить насколько в правильную сторону мыслите. Таким образом покажете, что у вас широкий опыт как с технической точки зрения, так и с продуктовой.

Постановка ML задачи

Прежде чем вдаваться в подробности нужно сразу определиться:

  1. Что будет фичами (признаками)?

  2. Что будет таргетом (лейблами)?

  3. Какой тип обучения будем использовать (классификация, регрессия и т.д)?

Детальная проработка системы

Данные

Данные влияют на решение всей задачи, поэтому им стоит уделить достаточно времени.

  1. Какие есть данные на текущий момент? Скорее всего разработчики настроили хоть какое-то логирование, из которого можно собрать датасет.

  2. Как собирать данные? Это может быть ручная разметка, парсинг логов системы и т.п

  3. Как разбивать данные? Стоит учесть природу данных при ответе на этот вопрос. Не стоит разбивать рандомно, если у вас данные имеют зависимость от времени.

  4. Какие особенности еще стоит учесть в фичах и таргете? Самые популярные: сезонность, cold start, выбросы.

Обучение модели

  1. Как представить фичи для модели, т.е как именно будем энкодить разные типы фичей? Стоит узнать стандартные подходы для каждого типа данных. Это может быть One-Hot Encoding, эмбеддинги и т.д

  2. Как представить таргет для модели? Как его нужно преобразовать, чтобы модели было легче обучаться?

  3. Какую модель использовать как бейзлайн?

  4. Как бороться с дисбалансом, если он предполагается? Можно упомянуть различные методы оверсемплинга и аугментации (SMOTE, ADASYN), взвешивание классов или использование специальных лоссов.

  5. Как бороться с выбросами и некачественной разметкой? Стоит использовать алгоритмы поиска аномалий и здравый смысл.

  6. Как бороться с изменением распределения из-за сезонности, мировых событий, праздников?

  7. Как можно улучшить бейзлайн? Можно придумать более хитрый лосс, другую архитектуру модели и т.д.

Инференс модели

  1. Как будет происходить инференс? Если у нас офлайн система, то процессить будем батчами. При онлайне — поэлементно, но в реальности скорее всего микс обоих подходов.

  2. Какую информацию стоит держать предпосчитанной и подтягивать при инференсе? Например, при персонализированном поиске для инференса необходимо подтягивать вектора пользователей.

  3. Какие проблемы могут быть при инференсе? Можно упомянуть извечную проблему training-serving skew (расхождение между тренировкой и инференсом модели) и как ее можно решить с помощью фича сторов.

Подсчет офлайн метрик

  1. Какую офлайн метрику выбрать, чтобы она максимально коррелировала с потребностями бизнеса? Можно предложить несколько метрик, которые будут показать качество модели с разных сторон.

  2. Как учесть дисбаланс классов в метриках и не дать им помешать сделать правильные выводы?

  3. Как определить guard метрики, которые не должны быть сломаны ни при каком случае?

Подсчет онлайн метрики

Прежде чем выкатить новую модель на всех пользователей, необходимо сделать A/B тесты. Для этого стоит ответить на несколько вопросов:

  1. Какую метрику считать (CR, CTR, revenue и т.д)?

  2. Какие статистические критерии использовать (t-test, Манна-Уитни и т.д)?

  3. Как разбивать пользователей на тестовую и контрольную выборки?

  4. Как долго проводить тест?

Деплой модели

  1. Как сервить модель? Для того чтобы обернуть модель в сервис в большинстве случаев работает следующая связка — конвертация модели в ONNX, сервинг через Flask/FastAPI, подготовки образа с помощью Docker и деплой на Kubernetes/Heroku/AWS.

  2. Какие еще компоненты нужны для работы модели? Зачастую добавляются сторонние источники данных (Redis, Postgres, S3), необходимые для инициализации модели и ее инференса.

  3. Как проверить работоспособность сервиса перед деплоем? Рассказать, какие тесты стоит написать (юнит, интеграционные, системные тесты).

  4. Как не вызвать просадки в работоспособности системы при деплое? Есть разные сценарии деплоя (canary/rolling), при котором сервис с моделью обновляется постепенно и не вызывает даунтайм.

  5. Как скалировать, чтобы выдерживать высокую нагрузку? Например, поднять несколько инстансов и распределять нагрузку через балансировщик или очередь.

  6. Как собирать логи из сервиса? Стоит знать базовый ELK стек и его альтернативы.

  7. Как мониторить данные? Хорошо бы знать такие термины, как Data drift, Concept drift, Target Drift. Почему они могут вызвать проблемы с системой? Какими фреймворками их считать?

Мониторинг сервиса

Кроме чтения логов стоит проверять, что:

  1. Доля неуспешных запросов не превышает заранее установленное значение.

  2. Каждый запрос не превышает заранее установленное время ответа.

  3. Используется разумное количество ресурсов (CPU, GPU, memory).

  4. Проходит хелфчеки.

Обычно на это не остается время, но можно упомянуть

  1. Как организовать хранение моделей и данных?

  2. Как организовать пайплайн переобучения?

  3. Как мониторить деградацию модели? Можно пересчитывать офлайн метрики на новых данных или считать онлайн метрики, базируясь на логах взаимодействия пользователя с системой.

Что лучше прочитать/пройти перед интервью

  1. Если есть пару выходных, то можно пройти небольшой курс от Educative https://www.educative.io/courses/grokking-the-machine-learning-interview

  2. Если хочется подготовиться основательно, то стоит прочесть «Designing Machine Learning System» by Chip Huyen

  3. Если не сталкивались с рекомендашками, то можно посмотреть курсы от MTS

    1. Базовый курс, объясняющий больше про модели и метрики — https://ods.ai/tracks/mts-recsys-df2020

    2. Продолжение курса, но уже больше про реальный мир — https://ods.ai/tracks/recsys-course2021

  4. Достаточно подробно про каждую компоненту ML системы — https://madewithml.com/#mlops

  5. Хорошо бы знать, что такое фича сторы и когда они становятся нужны — https://www.tecton.ai/blog/what-is-a-feature-store/

  6. Про мониторинг

    1. https://www.evidentlyai.com/blog/ml-monitoring-metrics

    2. https://neptune.ai/blog/how-to-monitor-your-models-in-production-guide

  7. Про А/Б тесты есть замечательные статьи от Авито

    1. https://habr.com/ru/company/avito/blog/571094/

    2. https://habr.com/ru/company/avito/blog/571096/

    3. https://habr.com/ru/company/avito/blog/590105/

  8. Лучшие практики машинного обучения от гугла — https://developers.google.com/machine-learning/guides/rules-of-ml

  9. Огромная подборка статей по разным темам — 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 дизайн собеседованиях?

  1. Структуры и фреймворка. Бросался от модели к данным, от данных к деплою и забывал спросить про потребности бизнеса.

  2. Насмотренности. Как делаются системы в других доменах (рекомендашках, поиске и т.д).

  3. Нервов. Я очень сильно переживал на своих первых собеседованиях. Это можно побороть периодическими мок интервью. Эффективнее всего заниматься с опытным ментором раз в неделю. Искать можно на специализированных площадках (Solvery, GetMentor и т.д) или стучаться людям в Linkedin. Также можно использовать платформу для прохождения интервью Prump и его аналоги.

Заключение

Данный фреймворк не является серебряной пулей и прочувствовать его можно только на реальных собесах, поэтому рекомендую как можно раньше пробовать свои силы в бою.

© Habrahabr.ru