Model Registry

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

Как работает реестр моделей#

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

• Артефакт модели: Сериализованные веса, логику предобработки, конфигурационные файлы или ссылку на место их хранения.
• Версия: Неизменяемый идентификатор, который отличает одного кандидата от другого.
• Метрики и параметры: Точность на валидации, precision, recall, задержку (latency), данные о датасете, гиперпараметры и другие измерения.
• Происхождение (линейность): Связи между моделью, ее исходным кодом, запуском обучения и данными.
• Статус: Метки, такие как кандидат, одобрено, отклонено, чемпион или в архиве.
• Информация о развертывании: Среды и эндпоинты, которые в данный момент используют эту версию.

Платформы реализуют эти идеи по-разному. Рабочий процесс реестра моделей MLflow использует зарегистрированные модели, версии, псевдонимы и теги, в то время как реестр моделей Amazon SageMaker поддерживает группы моделей, состояния одобрения, происхождение и автоматизацию развертывания. Некоторые системы также записывают сигнатуру модели: ожидаемую схему ввода и вывода, описанную в документации по сигнатурам моделей Snowflake.

Псевдонимы, такие как champion или production, предоставляют стабильные имена, которые могут переключаться между неизменяемыми версиями. Как объясняется в руководстве по псевдонимам моделей Vertex AI, приложение может запросить псевдоним без жесткого кодирования номера версии.

Реестр моделей против связанных концепций#

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

• Отслеживание экспериментов записывает запуски обучения, включая параметры, метрики и промежуточные артефакты. Реестр получает выбранные выходные данные из этих экспериментов и управляет ими как кандидатами на релиз.
• Хранилище артефактов содержит большие файлы. Реестр может хранить эти файлы напрямую, но он также может функционировать как индекс метаданных, указывающий на внешнее объектное хранилище. Архитектура реестра моделей Kubeflow иллюстрирует этот ориентированный на метаданные дизайн.
• Контроль версий исходного кода управляет версиями кода, в то время как реестр моделей управляет версиями обученных артефактов и их специфических для машинного обучения метаданных. Реестр моделей GitLab может связывать версии моделей с заданиями CI/CD, логами, метриками и параметрами.
• Развертывание модели делает выбранную модель доступной для инференса. Реестр определяет одобренный артефакт, а система развертывания запускает его.
• Мониторинг моделей наблюдает за поведением в продакшене после выпуска. Результаты мониторинга могут инициировать оценку, дообучение, регистрацию и продвижение замещающей версии.

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

Реальные приложения#

В системе контроля качества на производстве инженеры могут дообучать детектор дефектов всякий раз, когда меняются камеры, материалы или конструкция изделий. Реестр может сохранять ссылку на датасет каждой модели, среднюю точность (mAP), задержку инференса и поддерживаемый аппаратный формат. После того как тесты подтвердят, что версия 12 улучшает обнаружение царапин без увеличения количества ложных срабатываний, ответственное лицо может повысить ее статус, сохранив версию 11 для немедленного отката.

В анализе медицинских изображений несколько команд могут оценивать кандидатов на обнаружение опухолей. Регистрация сохраняет результаты валидации, конфигурацию обучения, ответственного владельца и историю утверждения для каждой версии. Продакшн-приложения могут быть ограничены проверенными моделями, в то время как старые версии остаются доступными для аудитов и воспроизводимости. Средства контроля на основе ролей, подобные тем, что описаны для управления реестром моделей Snowflake, помогают предотвратить несанкционированную замену или проверку конфиденциальных артефактов.

Регистрация моделей в рабочих процессах Ultralytics#

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

Следующий документированный рабочий процесс обучает Ultralytics YOLO26 локально, одновременно отправляя полученную модель, конфигурацию, метрики и логи в именованный проект Платформы:

import os

from ultralytics import YOLO

# Authenticate remote training with Ultralytics Platform
os.environ["ULTRALYTICS_API_KEY"] = "YOUR_API_KEY"

model = YOLO("yolo26n.pt")

model.train(
    data="coco8.yaml",
    epochs=3,
    project="username/model-registry-demo",
    name="candidate-001",
)

Название проекта и запуска делает кандидата доступным для поиска наряду с похожими моделями. Команды могут оценить его, использовать интеграцию Ultralytics с MLflow для дополнительного логирования экспериментов или применить экспорт моделей YOLO, когда зарегистрированная модель должна запускаться на определенном облачном или периферийном оборудовании.

Практические рекомендации по использованию реестра#

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

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