Model registry: как управлять версиями моделей в продакшене

Прямой ответ

Model registry — каталог моделей с версиями и стадиями жизненного цикла. Он отвечает на три вопроса: какая модель сейчас в продакшене, какая была до неё и как быстро вернуться назад. Без реестра выкатка модели превращается в копирование файлов с именами вроде model_final_v3_new.pkl.

Ключевые понятия:

• Registered model — логическая сущность, например churn_model.
• Version — конкретная версия модели с номером и ссылкой на артефакт.
• Alias / stage — указатель, например production, staging, champion. Сервис загружает модель по алиасу, а не по номеру версии, поэтому переключение не требует изменения кода.
• Связь с экспериментом. Версия реестра ссылается на run в трекинге, откуда видно параметры, метрики и данные обучения — см. MLflow Tracking.

Типовой жизненный цикл:

1. Обучение и регистрация версии из удачного прогона.
2. Автоматическая проверка: качество на тестовом наборе, валидность схемы признаков, размер и скорость инференса.
3. Перевод в staging, прогон на теневом трафике или A/B.
4. Перевод в production и наблюдение за метриками.
5. При деградации — откат алиаса на предыдущую версию.

Практические требования к процессу:

• Выкатка модели — это деплой. Она проходит ревью, тесты и фиксируется в системе контроля версий так же, как изменение кода.
• Откат должен занимать минуты. Если откат требует переобучения, процесс построен неверно.
• Загрузка по алиасу. Сервис не должен содержать «зашитых» номеров версий.

Практика: регистрация и переключение

Регистрация модели из прогона:

import mlflow

model_uri = f"runs:/{run_id}/model"
mv = mlflow.register_model(model_uri, "churn_model")
print(mv.name, mv.version)

mlflow.models.set_alias(f"models:/{mv.name}/{mv.version}", "staging")

Переключение продакшена после проверки:

# проверка качества перед переводом
metrics = evaluate_on_holdout(model_version=mv.version)
assert metrics["roc_auc"] >= 0.88, "качество ниже порога"

mlflow.models.set_alias(f"models:/churn_model/{mv.version}", "production")

Загрузка в сервисе:

import mlflow.pyfunc

model = mlflow.pyfunc.load_model("models:/churn_model@production")

Рекомендации:

1. Храните метаданные вместе с версией. Схема признаков, версия датасета, порог классификации, ожидаемое время ответа. Без них откат может сломать сервис: новая версия ожидает другие признаки.
2. Фиксируйте порог принятия решения. Смена порога меняет поведение так же сильно, как смена модели, поэтому он должен быть частью версии, а не настройкой в коде.
3. Автоматизируйте проверки перед переводом. Прогон тестового набора, проверка схемы и нагрузочный тест — часть пайплайна, а не ручная операция. Как это встроить — в статье про MLOps-пайплайн.
4. Ведите журнал переходов. Кто и когда перевёл версию, на основании каких метрик. Это нужно при разборе инцидентов и при аудите.

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

Практический сценарий: новая модель упала в продакшене

Контекст: перевели версию 7 в production; через час доля предсказаний «отток» выросла с 6 % до 21 %.

1. Диагностика. Метрики на тестовом наборе у версии 7 были лучше, но в проде качество упало. В логах видно: часть запросов приходит без признака tenure_months, модель подставляет пропуск и смещает предсказания.
2. Причина. Витрина признаков была изменена накануне, и новый признак перестал заполняться для старых клиентов. Тестовый набор был собран до изменения, поэтому проблему не поймал.
3. Действия. Откатываем алиас production на версию 6 — сервис восстанавливается за две минуты. Затем чиним заполнение признака и пересобираем тестовый набор на актуальной схеме.
4. Проверка. Версия 7 проходит повторную оценку на свежем срезе; качество подтверждается, переводим снова.
5. Профилактика. Добавляем обязательную проверку схемы входа при регистрации и алерт на изменение распределения предсказаний — подходы описаны в статье про мониторинг моделей.

Вывод: реестр ценен не каталогом версий, а возможностью мгновенного отката и обязательными проверками перед переводом в продакшен.

Соглашения об именовании и нумерации. Номер версии присваивается реестром автоматически, поэтому смысл вкладывают в алиасы и описания. Полезная практика: алиас production указывает на рабочую версию, challenger — на кандидата под наблюдением, а в описании версии фиксируют короткую строку «на каких данных обучена, какая метрика, какое изменение относительно предыдущей». Этого достаточно, чтобы через месяц понять, чем версии отличаются, не запуская сравнение метрик вручную.

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

FAQ

Можно ли обойтись без реестра, храня модели в Git или S3? Технически да, если версионирование и процедура переключения дисциплинированны. Реестр добавляет стандартизацию: стадии, алиасы, историю переходов и связь с экспериментом. На нескольких моделях и нескольких командах без него быстро возникает путаница.

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

Что делать с несколькими моделями в продакшене одновременно? Используйте отдельные алиасы (champion, challenger) и направляйте часть трафика на кандидата. Сравнение результатов на реальном трафике даёт больше информации, чем офлайн-метрики.

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

Источники: MLflow docs (model registry, deployment), scikit-learn model persistence — ссылки в шапке.