Вопросы по MLOps на собеседовании

MLOps-вопросы начинаются там, где заканчивается ноутбук. Проверяют, понимаете ли вы, что происходит с моделью после обучения: как её выкатывают, как замечают деградацию и как откатывают.

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• CI/CD и оркестрация14
• Выкат и мониторинг14
• Упаковка и сервинг14
• Трекинг и реестр моделей12

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• CI/CD и оркестрация14 вопросов
• MLOps: выкат и мониторинг14 вопросов
• MLOps: трекинг и реестр моделей12 вопросов
• MLOps: упаковка и сервинг14 вопросов

Примеры вопросов с разбором

1. #cicd_orchestration1 / 9
   Что означает CI/CD применительно к ML-модели?

   A)Автопрогон тестов и валидации с последующим выкатом пайплайна при изменении кода или данных

   B)Ручной запуск обучения модели по звонку от менеджера в конце каждого рабочего спринта команды разработки

   C)Специальный алгоритм автоматического подбора архитектуры нейросети под конкретную бизнес-задачу заказчика

   D)Формат сериализации весов обученной модели для их последующей передачи между разными сервисами по сети

   показать ответ и разбор

   +A)Автопрогон тестов и валидации с последующим выкатом пайплайна при изменении кода или данных

   // разбор: CI/CD переносит практику разработки на ML: на каждое изменение кода или данных автоматически прогоняются тесты, собирается и валидируется пайплайн, а затем модель/пайплайн выкатываются без ручных шагов. Это про автоматизацию сборки-проверки-выката, а не про подбор архитектуры или формат весов.

2. #deploy_monitoring2 / 9
   Что такое canary-деплой модели?

   A)Одномоментное переключение всего боевого трафика на новую версию модели сразу и вообще без наблюдения

   B)Выкат новой версии на малую долю трафика с наблюдением за метриками перед раскаткой на 100%

   C)Обязательный запуск новой модели в отдельном тестовом контуре, без живого трафика

   D)Хранение сразу всех прошлых версий модели в реестре на случай необходимости будущего отката на них назад

   показать ответ и разбор

   +B)Выкат новой версии на малую долю трафика с наблюдением за метриками перед раскаткой на 100%

   // разбор: Canary — новую версию сначала показывают маленькой доле реального трафика (1–5%) и следят за метриками (латентность, ошибки, качество). Если всё ок — долю плавно поднимают до 100%, если нет — откатывают, задев минимум пользователей. Это способ безопасно катить на живом трафике, в отличие от разового переключения всех сразу.

3. #experiment_registry3 / 9
   Зачем нужен трекинг экспериментов (например, MLflow), если метрики можно записать в блокнот?

   A)Трекер экспериментов самостоятельно подбирает оптимальные гиперпараметры модели вместо самого инженера

   B)Связывает параметры, метрики, артефакты и версию кода каждого прогона — он воспроизводим и сравним

   C)Заменяет собой систему контроля версий кода вроде git во всём ML-проекте

   D)Автоматически выкатывает лучшую по метрике модель прямо в прод вообще без всякого ревью и проверок

   показать ответ и разбор

   +B)Связывает параметры, метрики, артефакты и версию кода каждого прогона — он воспроизводим и сравним

   // разбор: Через сотню прогонов «в блокноте» невозможно понять, какие гиперпараметры и данные дали лучшую метрику. Трекер (MLflow и пр.) фиксирует на каждый run параметры, метрики, артефакты и версию кода — прогоны сравнимы и воспроизводимы. Он не подбирает гиперпараметры сам, не заменяет git и точно не катит модель в прод без ревью.

4. #packaging_serving4 / 9
   Зачем упаковывать обученную модель в Docker-образ, а не просто скопировать файл весов на сервер?

   A)Образ фиксирует окружение целиком — версии Python, библиотек и системных зависимостей

   B)Docker самостоятельно ускоряет инференс модели на GPU в несколько раз без каких-либо изменений кода

   C)Контейнер автоматически шифрует веса модели, защищая их от копирования конкурентами

   D)Упаковка в образ незаметно дообучает модель на данных сервера прямо во время каждого запуска

   показать ответ и разбор

   +A)Образ фиксирует окружение целиком — версии Python, библиотек и системных зависимостей

   // разбор: Модель тащит за собой окружение: ту же версию torch/numpy, тот же питон, те же системные либы. Голый .pkl на сервере ломается на несовпадении версий («работает у меня»). Docker-образ фиксирует окружение целиком, поэтому контейнер одинаково поднимется на CI, стейдже и проде. Веса он не шифрует и инференс сам по себе не ускоряет.

5. #cicd_orchestration5 / 9
   Зачем оркестровать обучение в Airflow, а не запускать скрипты вручную по cron?

   A)Airflow сам по себе значительно повышает итоговое качество обученной модели без изменения данных и кода

   B)Cron не способен запускать python-скрипты по расписанию на сервере без сторонних костылей

   C)Зависимости шагов, ретраи, наблюдаемость и бэкфилл — граф задач вместо разрозненных скриптов

   D)Ради того, чтобы убрать из проекта необходимость хранить код в системе git

   показать ответ и разбор

   +C)Зависимости шагов, ретраи, наблюдаемость и бэкфилл — граф задач вместо разрозненных скриптов

   // разбор: Пайплайн — это граф зависимых шагов (выгрузка → фичи → обучение → валидация → регистрация). Airflow задаёт зависимости, ретраит упавший шаг, показывает статус и историю прогонов, умеет бэкфилл за прошлые даты. Cron просто дёргает скрипт по времени, не зная ни зависимостей, ни того, упал ли предыдущий шаг. Качество модели оркестратор не повышает.

6. #deploy_monitoring6 / 9
   Что такое shadow-деплой (теневой запуск) модели?

   A)Полностью скрытая от команды разработки версия модели, которую катит в прод в одиночку только один инженер

   B)Выкат модели строго в ночное время суток, когда боевого пользовательского трафика на сервисе почти нет

   C)Новая модель считает на боевом трафике, но её ответы не влияют на пользователя — только сравнение с текущей

   D)Резервная копия модели, которая автоматически включается лишь при полном отказе основного сервиса инференса

   показать ответ и разбор

   +C)Новая модель считает на боевом трафике, но её ответы не влияют на пользователя — только сравнение с текущей

   // разбор: При shadow-запуске новая модель получает тот же боевой трафик, что и текущая, её предсказания логируются, но пользователю не показываются — на решения по-прежнему влияет старая модель. Так безопасно сравнивают модели на реальных данных и проверяют латентность/стабильность под нагрузкой без риска для UX. Ответы новой модели «в тени», отсюда название.

7. #experiment_registry7 / 9
   Что такое model registry?

   A)Хранилище сырых обучающих данных со всеми их историческими версиями и полной родословной строк

   B)Сервис, который в реальном времени считает признаки для модели по запросу из продакшена онлайн

   C)Каталог версий модели со стадиями (staging/production) и управляемыми переходами между ними

   D)Инструмент для ручной разметки и валидации предсказаний модели силами команды внешних асессоров

   показать ответ и разбор

   +C)Каталог версий модели со стадиями (staging/production) и управляемыми переходами между ними

   // разбор: Model registry — каталог обученных моделей: версии, стадии жизненного цикла (staging/production/archived), кто и когда перевёл, привязка к прогону-родителю. Он отвечает на вопрос «какая версия сейчас в проде и как откатиться». Это не хранилище данных (это data versioning/DVC) и не сервис фичей (feature store).

8. #packaging_serving8 / 9
   Что такое ONNX в контексте вывода модели в прод?

   A)Облачный сервис, который сам обучает и хостит нейросети без написания какого-либо кода пользователем

   B)Открытый формат представления модели для обмена между фреймворками и рантаймами инференса

   C)Библиотека для разметки обучающих данных силами асессоров прямо внутри обучающего пайплайна проекта

   D)Протокол шифрованной передачи признаков между сервисом фичей и моделью по сети в реальном времени

   показать ответ и разбор

   +B)Открытый формат представления модели для обмена между фреймворками и рантаймами инференса

   // разбор: ONNX (Open Neural Network Exchange) — открытый формат, в который экспортируют обученную модель, чтобы оторвать её от питон-фреймворка обучения. Модель из PyTorch/TF конвертируют в ONNX и гоняют в оптимизированном рантайме (ONNX Runtime, TensorRT, Triton) — часто быстрее и без тяжёлого фреймворка на проде. Это формат обмена, а не сервис и не библиотека разметки.

9. #cicd_orchestration9 / 9
   Что должен проверять CI для ML-пайплайна помимо юнит-тестов кода?

   A)Ничего сверх юнит-тестов кода — для машинного обучения этого достаточно на практике

   B)Схему и качество входных данных плюс метрику модели на holdout — нет ли деградации против текущей

   C)Скорость обучения модели в секундах, поскольку она важнее всех прочих характеристик

   D)Орфографию комментариев и стиль форматирования кода по принятому код-стайлу

   показать ответ и разбор

   +B)Схему и качество входных данных плюс метрику модели на holdout — нет ли деградации против текущей

   // разбор: У ML две оси регресса: код и модель. Помимо юнит-тестов кода CI должен валидировать данные (схема, диапазоны, доля пропусков) и качество модели — посчитать метрику на фиксированном holdout и сравнить с текущим прод-порогом, чтобы не выкатить модель хуже. Линт и скорость полезны, но деградацию качества ловит именно gate на метрику.

Частые вопросы

• Как замечают, что модель испортилась?

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

• Что спрашивают про деплой моделей?

  Онлайн-инференс против батчевого, требования по задержке, версионирование и воспроизводимость, откат на предыдущую версию и как устроен реестр моделей.