ניהול גרסאות למודלי ML: הקמת Model Registry כולל הכל

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

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

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

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

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

Model registry закрывает это как единая точка правды: версионирование ml-моделей, привязка к данным и параметрам запуска, воспроизводимость экспериментов и предсказуемый откат. Ниже разбираем, как именно это устроено.

Эффект от версионирования: воспроизводимость и откат модели

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

Повторное обучение на том же снимке даёт ту же метрику — расхождение видно на этапе проверки, а не через неделю в рабочем контуре.

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

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

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

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

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

Режимы хранения и раздачи моделей: сравнение вариантов

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

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

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

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

Этапы внедрения: от инвентаризации моделей до передачи

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

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

Конфигурации, политики доступа и регламент выпуска версий

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

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

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

Всё перечисленное ведётся в вашем репозитории и передаётся с историей изменений. Опишите задачу — вернёмся с оценкой и планом, в каком объёме этот комплект собирается под ваш контур.

Кейс: сократили долю сбоев после выпуска моделей

Кейс внедрения: у заказчика в боевом контуре жили 14 моделей, и каждая версия выходила через переписку.

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

Что изменили

Развернули MLflow Model Registry как единственный источник правды по версиям: у каждой записи — номер, привязка к датасету, коммиту и замерам качества, а стадии «обучение → проверка → боевой контур» проставляются автоматически.

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

Метрики до и после

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

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

Чем Model Registry отличается от версионирования кода?

Код и модель версионируются по-разному, потому что версия кода — это текст и конфигурация, а версия модели — совокупность весов, параметров обучения, версии набора данных и метрик качества.

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

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

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

Совместимость, хранение артефактов и права: частые вопросы

Реестр моделей (Model Registry) надстраивается над текущим стеком, а не заменяет его: обучение идёт в привычной среде, а версия, метрики и артефакт попадают в реестр автоматическим шагом сборочного контура или через программный интерфейс.

Уже обученные модели переносим импортом — веса, метаданные и владелец версии привязываются к записи, история экспериментов не теряется.

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

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

Совместим ли реестр с нашими инструментами обучения?

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

Что с объёмом артефактов?

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

Обсудим задачу: с чего начать версионирование моделей

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

• Какие модели работают в продакшене: типы задач, форматы артефактов, число активных версий на каждую.
• Как модели попадают из обучения в запуск: ручная выкладка, скрипты, конвейер сборки — и где этот путь чаще ломается.
• Где лежат артефакты и метаданные: файловое или объектное хранилище, реестр образов, таблицы с экспериментами.
• Инфраструктура запуска: Kubernetes или виртуальные машины, облако или собственные серверы, изолированные контуры.
• Что требуется для воспроизводимости и аудита: хранить ли датасет, хеш артефакта, метрики обучения и автора выпуска.
• Кто имеет право публиковать и отзывать версию: роли, внешние подрядчики, ограничения по доступам.
• Сроки вывода модели в продакшен и требования к откату на предыдущую версию.

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

Опишите задачу и пришлите вводные — хотя бы черновыми заметками: уточним детали и вернёмся с планом и сроками.