Реестр моделей (Model Registry)

Где живёт «текущая прод-модель» и как безопасно её менять — отвечает реестр моделей.

Реестр моделей (model registry) — централизованное хранилище зарегистрированных моделей с версиями, стадиями жизненного цикла и метаданными, единый источник правды о том, какая модель сейчас в продакшне.

Зачем нужен реестр

Без реестра «текущая модель» — это файл model_final_v2_real.pkl на чьём-то ноутбуке. Никто не знает, чем она отличается от предыдущей, кто и когда её одобрил, на каких данных обучена. Реестр превращает хаос файлов в управляемый каталог: у каждой модели есть имя, нумерованные версии, текущая стадия и история переходов.

Версии и стадии

Зарегистрированная модель (например, fraud-detector) имеет растущий список версий: v1, v2, v3… Каждой версии назначается стадия:

Переход Staging → Production — это контролируемое событие с историей: кто, когда, какую версию повысил. Сервинг всегда спрашивает реестр «дай мне Production-версию модели fraud-detector» и не зависит от имён файлов.

  Обучение -> register(v3) -> stage: Staging -> проверки -> promote -> Production
                                                                |
                       прежний Production (v2) -> Archived <----+

Метаданные и происхождение

Каждая версия в реестре связана со своим экспериментом: гиперпараметры, метрики, ссылка на версию данных (DVC-хеш), git-коммит кода. Так из прод-модели можно одним кликом дойти до того, как именно её получили — это и есть lineage.

На практике эта связь экономит часы при разборе инцидентов. Представьте: в проде резко выросла доля ложных срабатываний антифрода. Без реестра вы начнёте с вопроса «а какая вообще модель сейчас работает?» и потратите день на археологию. С реестром вы открываете запись Production-версии, видите, что три дня назад v7 сменила v6, сравниваете их метрики на одном валидационном наборе, смотрите, на каких данных и с какими параметрами обучалась v7, — и либо находите регрессию, либо откатываетесь на v6 за секунды. Реестр превращает расследование из гадания в навигацию по фактам.

Кроме того, реестр — точка интеграции для всей команды и автоматики. CI/CD-пайплайн регистрирует кандидата и ставит ему стадию Staging; система мониторинга читает, какая версия в Production, чтобы привязать метрики; сервис деплоя подписывается на события смены стадии и сам перевыкатывается. Так реестр становится «диспетчерской» жизненного цикла модели, а не просто складом файлов.

Пример (MLflow Model Registry)

import mlflow

# регистрируем модель из конкретного run
result = mlflow.register_model(
    model_uri="runs:/<run_id>/model",
    name="fraud-detector",
)

client = mlflow.MlflowClient()
# переводим версию в Production
client.transition_model_version_stage(
    name="fraud-detector",
    version=result.version,
    stage="Production",
    archive_existing_versions=True,  # старую Production -> Archived
)

Как работает под капотом

Реестр — это база данных метаданных плюс ссылки на хранилище артефактов. Сама модель (веса) лежит в объектном хранилище; реестр держит запись: имя, версия, стадия, путь к артефакту, метрики, теги, история переходов. Сервис при старте обращается к API реестра, получает URI Production-версии и подгружает артефакт. Смена прод-модели — это атомарная смена указателя стадии, а не перезапись файлов.

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

• Хранить модели файлами без реестра. Теряется история, одобрения и связь с данными.
• Повышать в Production без проверок. Стадия Staging существует, чтобы прогнать валидацию до боевого трафика.
• Хардкодить путь к модели в сервисе. Сервис должен спрашивать реестр, а не знать имя файла, иначе откат и обновление превращаются в ручную работу.

Итог

• Реестр моделей — единый источник правды: какая версия модели сейчас в проде и как она туда попала.
• Версии и стадии (Staging/Production/Archived) делают продвижение и откат контролируемыми событиями.
• Сервинг обращается к реестру за Production-версией, что развязывает деплой и имена файлов.