Настройка Model Registry для управления версиями моделей

Почему без Model Registry версии моделей расходятся с продом

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

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

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

Разбираем, как такой реестр выстраивается в вашем контуре: от соглашения об именовании до автоматического перевода стадий.

Что даёт управляемый реестр моделей: измеримый эффект

Реестр моделей — это не каталог файлов, а контракт между теми, кто обучает модели, и теми, кто выводит их в продукт. Пока версии живут в личных каталогах и переписке, команда тратит часы на выяснение, какой артефакт работает в рабочем контуре и чем он отличается от того, что получился в эксперименте.

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

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

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

Итог — реестр превращает работу с моделями из набора личных практик в повторяемый процесс с измеримыми показателями.

Варианты Model Registry: облако, свой контур, гибрид

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

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

Как выбрать

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

Внедрение реестра моделей: от аудита до передачи

Реестр моделей (model registry) не разворачивают «на пустом месте»: сначала нужно понять, что уже работает в проде и что вообще существует внутри команды. Ниже — инженерный путь от инвентаризации до передачи, по которому проходит внедрение.

1. Аудит моделей. Собираем перечень: какие модели обслуживают продукт, кто владелец, из какого артефакта идёт развёртывание. Отдельно помечаем дубли и «сирот» — их судьбу решаем до настройки реестра.
2. Схема реестра. Определяем иерархию «проект → модель → версия → этап», правила именования и обязательные метаданные: данные обучения, метрики, автор. От этого зависит воспроизводимость и возможность отката.
3. Настройка прав. Роли разграничиваем по действиям: публикация версии, перевод в прод, только чтение. Реестр связываем с контуром развёртывания, чтобы прод не забирал модель из экспериментальной ветки.
4. Тестовый контур. Прогоняем сквозной сценарий на копии: публикация, перевод между этапами, откат на предыдущую версию. Проверяем, что права действительно отсекают лишнее, а метрики воспроизводимы.
5. Передача знаний. Переносим рабочие версии с историей и фиксируем, что осталось вне реестра. Отдаём команде регламент публикации, инструкции по типовым операциям и порядок разбора инцидентов.

Что остаётся в вашем контуре: артефакты и регламенты

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

• Схема метаданных — обязательные поля карточки модели: набор данных, метрика качества, владелец, стадия, дата обучения.
• Конфигурации реестра и хранилища — разделение контуров разработки, приёмки и эксплуатации, настройки резервного копирования артефактов.
• Политики доступа и роли — кто публикует версию, кто переводит её в эксплуатацию, у кого только чтение. Роли связываются с вашим каталогом пользователей.
• Регламент выпуска — порядок перевода версии между стадиями, обязательные проверки перед выкладкой и условия отката на прошлый выпуск.
• Правила хранения и очистки — сколько версий держим на тег, что уходит в архив, как при этом сохраняется возможность отката.
• Шаблоны автоматизации — заготовки типового пути от обучения до выдачи в эксплуатацию, чтобы новая модель подключалась по готовому маршруту.
• Документация и чек-лист приёмки — схема контура, инструкции для инженеров и аналитиков, порядок действий при инциденте.
• Передача команде — разбор контура с вашими специалистами и согласованный порядок сопровождения после запуска.

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

Кейс: навели порядок в версиях моделей на проде

Что было до

На проде работало 38 моделей, 14 из них жили вне реестра: веса лежали в каталогах на учебных серверах, а версия определялась по имени файла и дате изменения. Инвентаризация занимала неделю и всё равно давала расхождения — спорные версии приходилось подтверждать у авторов вручную. Откат после неудачного выпуска шёл без регламента: инженер искал предыдущий артефакт, подменял файл и перезапускал сервис, надеясь, что подменяет именно то, что работало. В среднем 3–4 часа ночью, дважды за квартал — с полной остановкой сервиса оценки.

Что изменили

Сначала провели инвентаризацию: сверили веса, метрики качества и даты выпуска, отметили мёртвые версии и вывели их из оборота. Затем завели единый model registry на базе MLflow — у каждой модели появились владелец, обучающий набор, метрики и стадия. Выпуск идёт только через реестр: сборка сама регистрирует артефакт и переводит стадию, ручная загрузка файлов на прод закрыта.

Что стало

Через квартал под управлением реестра — 100% моделей, выпуск версии сократился с 4 часов до 40 минут, откат — с 3–4 часов до 8 минут, днём и без остановки сервиса. Повторяющиеся инциденты вида «на прод вернулась устаревшая модель» прекратились. Инвентаризация теперь занимает минуты: список версий, стадий и владельцев выгружается из реестра одним запросом.

Чем реестр моделей отличается от хранилища артефактов?

Хранилище артефактов отвечает на вопрос «где лежит файл», реестр моделей — на вопрос «что это за модель и можно ли её выкатывать». Первое оперирует путями, размерами и контрольными суммами: объектное хранилище надёжно сохранит веса, но не знает, на каких данных они получены и какой артефакт был предыдущим.

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

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

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

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

Технические сомнения: разбираем частые вопросы

Реестр моделей почти никогда не разворачивают с нуля: его встраивают в существующий контур — хранилище артефактов, систему обучения, конвейер выкладки. Ниже — четыре вопроса, которые чаще всего задают до старта работ.

Как разграничить доступ между командами и средами?

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

Унаследованные модели без метаданных придётся пересобирать?

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

Сколько места займут все версии моделей?

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

Обсудим задачу и вернёмся с оценкой и планом работ

Чтобы оценка по model registry опиралась на ваш контур, а не на средние допущения, первый разговор строим как разбор вводных. Нам нужны факты о том, как модели живут сейчас, — тогда трудоёмкость считаем по этапам, а не одной усреднённой цифрой.

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

Возвращаемся с планом работ: последовательность этапов, состав команды с зонами ответственности, сроки и критерии приёмки по каждому шагу. Если на разборе видим риск — называем его сразу, а не в середине проекта.