Model versioning на собеседовании Data Scientist

Почему model versioning спрашивают

Model versioning — это MLOps-тема, которая отделяет data scientist, обучающего модели в ноутбуке, от того, кто выводит их в продакшен и потом за них отвечает. На собесе её спрашивают, чтобы понять: осознаёте ли вы, что модель в бою живёт не одна и не вечно, и умеете ли управлять её версиями так, чтобы в любой момент откатиться и объяснить, что именно сейчас крутится на проде.

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

Эта статья закрывает базу: зачем версионировать модели, что такое model registry, как их именуют, какие есть стадии и как устроен откат.

Зачем версионировать модели

В продакшене редко живёт ровно одна модель. Обычно параллельно существует несколько версий на разных этапах:

• Production v1 — текущая, обслуживает реальный трафик.
• Staging v2 — кандидат на замену, проходит валидацию.
• Experiments v3, v4 — исследовательские, в стадии R&D.

Всем этим версиям нужна чёткая идентификация, иначе начинается хаос: непонятно, какая модель сейчас на проде, на чём она обучена и к какой откатываться при сбое. Версионирование решает три задачи. Воспроизводимость — восстановить любую версию по коду, данным и параметрам. Прослеживаемость — знать, кто, когда и что выкатил. Управляемый откат — быстро вернуться к рабочей версии, когда новая деградировала.

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

Model Registry

Model registry — это хранилище моделей вместе с их метаданными и историей версий. Это не просто папка с файлами, а сервис, который знает про каждую версию: кто обучил, на чём, с какими метриками и в какой она стадии.

Самый распространённый инструмент — MLflow Model Registry:

# зарегистрировать модель из конкретного запуска обучения
mlflow.register_model("runs:/<run_id>/model", "fraud_detector")

# перевести версию 3 в стадию Production
client.transition_model_version_stage(
    name="fraud_detector", version=3, stage="Production"
)

Помимо MLflow, ту же роль играют Weights & Biases, Vertex AI Model Registry (Google Cloud) и SageMaker Model Registry (AWS). Все они решают одну задачу: дать единую точку правды о том, какие версии модели существуют, какая где развёрнута и как её воспроизвести.

Схема именования версий

Версии именуют по одной из двух логик. Первая — семантическая (semver-подобная), где номер несёт смысл:

fraud_detector v2.1.0
  major (2): несовместимое изменение — например, поменялся формат входных признаков
  minor (1): новая функциональность — recall вырос на 5%, добавили фичу
  patch (0): исправления и стабильность без изменения поведения

Вторая — на основе времени и хэша коммита: fraud_detector_2026-05-07_abc123. Такой формат удобен, когда модели переобучаются по расписанию и человекочитаемый semver для них избыточен.

Что бы вы ни выбрали, каждая версия должна тянуть за собой полный контекст:

• Хэш коммита кода — на каком именно коде обучена модель.
• Версия обучающих данных — на каком срезе данных, чтобы результат можно было воспроизвести.
• Метрики на бенчмарках — как эта версия себя показала на контрольной выборке.
• Автор и апруверы — кто обучил и кто согласовал вывод в прод.

Стадии жизненного цикла модели

Модель движется по стадиям, и переход между ними — контролируемое событие, а не просто копирование файла:

None (только зарегистрирована) → Staging (валидация) → Production (боевой трафик) → Archived (выведена из эксплуатации)

Каждый переход фиксируется, образуя журнал аудита (audit trail): видно, кто и когда перевёл версию в прод и что было до неё. В строго регулируемых доменах — финансы, медицина, антифрод — перевод в Production требует ручного согласования: модель нельзя выкатить автоматически, её должен апрувнуть ответственный. Это ровно тот случай, когда версионирование из удобства превращается в требование комплаенса.

Rollback

Когда новая версия деградировала — метрики поехали, растёт число ошибок, посыпались жалобы — нужен быстрый откат к предыдущей рабочей версии. Механизмы отката:

• Feature flag (флаг функциональности). Переключатель между версиями: меняем значение флага, и трафик идёт на старую модель. Самый быстрый способ.
• Маршрутизация трафика (routing). Перенаправляем запросы на предыдущую версию на уровне балансировщика или роутера моделей, не трогая деплой.
• Повторный деплой старого образа. Разворачиваем предыдущий контейнер с проверенной версией.

Ключевая метрика отката — скорость: цель обычно менее 5 минут, и процесс должен быть автоматизирован, а не выполняться руками по инструкции в панике. Отдельная тонкость — изменения схемы: если новая версия ждёт другой набор признаков или другую структуру данных, откат усложняется. Поэтому изменения схемы стараются делать обратно совместимыми, чтобы старая и новая версии могли работать на одних и тех же данных.

Частые ошибки

• Версионировать только веса модели. Без версии кода, данных и гиперпараметров модель невоспроизводима. Через полгода вы не восстановите, как её получили.
• Путать model registry с хранилищем файлов. Папка с pickle-файлами по датам — не registry. Registry знает про стадии, метрики и историю переходов, а не просто хранит бинарники.
• Не продумать откат заранее. Если стратегия отката не готова до релиза, в момент инцидента вы теряете драгоценные минуты. Откат проектируют вместе с деплоем.
• Игнорировать совместимость схемы. Новая версия, требующая других признаков, ломает возможность быстрого отката. Изменения входов держат обратно совместимыми.
• Автоматический вывод в прод там, где нужен апрув. В регулируемых доменах перевод в Production без ручного согласования — нарушение процесса, а не «ускорение».

Связанные темы

• MLflow и DVC для DS
• Canary и shadow deployment ML для DS
• MLOps мониторинг для DS
• Feature Store для DS
• Подготовка к собесу Data Scientist

FAQ

Что именно нужно версионировать — только модель?

Не только веса. Для воспроизводимости версионируют весь контекст: код (хэш коммита), обучающие данные (их версию или снапшот) и гиперпараметры. Одинаковый код на разных данных даёт разные модели, поэтому версия данных так же обязательна, как версия кода. Иначе через полгода восстановить конкретную версию будет невозможно.

Semver или timestamp — что выбрать для именования?

Зависит от того, кто и как переобучает модель. Semver (v2.1.0) хорош, когда релизы редкие и осмысленные, а номер должен нести смысл (major — несовместимое изменение, minor — новая фича, patch — фикс). Timestamp с хэшем (model_2026-05-07_abc123) удобнее для автоматического переобучения по расписанию, где человекочитаемая нумерация избыточна. Часто их комбинируют.

Чем model registry отличается от обычного хранилища?

Registry хранит не только файлы моделей, но и их метаданные: версии, стадии (Staging/Production/Archived), метрики, авторов и историю переходов. Он даёт единую точку правды — какая версия сейчас на проде и как её воспроизвести. Обычная папка с файлами всего этого не знает и не помогает при откате или аудите.

Как быстро откатить модель в проде?

Через feature flag, переключение маршрутизации трафика или повторный деплой предыдущего образа. Цель — обычно менее 5 минут, и процесс должен быть автоматизирован. Главное, чтобы предыдущая рабочая версия оставалась доступной в registry, а изменения схемы входных данных были обратно совместимы — иначе откат усложняется.

Как versioning связан с A/B-тестами моделей?

Напрямую: чтобы сравнить две версии на реальном трафике, обе должны быть чётко идентифицированы и одновременно развёрнуты. Registry хранит их как отдельные версии в разных стадиях, а маршрутизация делит трафик между ними. По итогам эксперимента победившую версию переводят в Production, проигравшую — в Archived, и всё это фиксируется в журнале переходов.

Это официальная информация?

Нет. Статья основана на индустриальных практиках MLOps и документации MLflow. Конкретные инструменты и процессы зависят от компании, стека и уровня позиции.

Тренируйте Data Science — откройте тренажёр с 1500+ вопросами для собесов.