Занимался ли выкатыванием в продакшн в проекте
Что проверяют
Доводили ли вы модель или пайплайн до состояния, когда им пользуются, а не только до хорошей метрики в ноутбуке. Следом спрашивают, как вы поняли, что после релиза всё работает, и как бы откатились.
Как отвечать
Ответ строится на вашем проекте, поэтому нужны свои примеры и свои цифры. Удобный каркас:
- что выкатывали: модель как онлайн-сервис, батч-скоринг по расписанию, DAG в Airflow, модели dbt, новый источник в хранилище;
- как упаковали: Docker-образ, версия модели в реестре (MLflow Model Registry или аналог), зафиксированные версии библиотек, одинаковая подготовка признаков в обучении и в сервинге;
- как выкатывали: CI/CD с тестами (юнит-тесты на преобразования, проверка схемы данных, прогон на эталонном наборе), затем shadow-режим, канарейка или A/B-тест. Для батчей запуск на части данных и сверка с прежним результатом;
- как следили: задержка и ошибки сервиса в Prometheus и Grafana, распределение признаков и предсказаний, дрейф данных (например, Evidently), для пайплайнов свежесть и объём данных, алерты на падение DAG;
- как откатывались: возврат предыдущей версии модели из реестра, перезапуск DAG за нужные даты.
Роль назовите честно: сами писали деплой или отдавали артефакт MLOps-инженеру и отвечали за валидацию. Оба варианта нормальны.
Если в прод вы не выкатывали, не придумывайте. Скажите, до какой стадии доводили работу, и покажите понимание процесса на пет-проекте: модель за FastAPI в Docker, расписание в Airflow, простой мониторинг. Добавьте, что хотите освоить на новом месте.
Где спотыкаются
Называют эффект вроде «точность выросла на 15%, конверсия на 10%» без базы сравнения. Интервьюер спросит, офлайн это или A/B-тест и что было контролем.
Рассказывают только про обучение, а выкатку описывают фразой «передали модель бэкенду в pickle». Без версий и воспроизводимости это ещё не продакшн.
Забывают про жизнь после релиза: дрейф, расхождение признаков между обучением и сервингом, мониторинг. Именно там модели чаще всего ломаются тихо.