Группа исследований и разработок Domino предоставляет открытый исходный код Bridge, инструмента, который превращает реестр вашей модели в декларативный источник достоверной информации для развертывания и хостинга вашей модели.

С мостом:

  • Специалисты по обработке данных управляют жизненным циклом своих моделей исключительно через специальный API-интерфейс и пользовательский интерфейс своего реестра моделей.
  • Группы инженеров DevOps и машинного обучения используют Bridge для автоматизации зачастую сложного и утомительного управления ресурсами хостинга моделей.

Ниже мы делимся результатами исследований, которые привели нас к декларативному «RegistryOps» как правильному способу структурирования пути от разработки модели до производства.

(Tl; dr? Посмотрите эту 7-минутную демонстрацию ткацкого станка Bridge в действии)

Сотни интервью, два наблюдения

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

Реестры (а не репо) являются источником правды

Большинство развернутых программных систем используют репозиторий кода (обычно репозиторий git) в качестве источника достоверной информации. Если ваша обслуживающая инфраструктура была полностью разрушена, вы все равно сможете восстановить и повторно развернуть свое приложение, используя только исходный код в репозитории. Системы CI / CD - золотой стандарт для безопасного масштабируемого развертывания программного обеспечения - глубоко внедряют это в свой дизайн - при отправке в репозиторий артефакты перестраиваются, а затем эти артефакты развертываются для хостинга.

Код-репо-как-источник-истины не работает при разработке модели по трем причинам:

  1. Разработка модели является творческой / специальной: создание и улучшение модели требует экспериментов с различными функциями, архитектурами, значениями гиперпараметров и т. д. мерзавец. Даже если экспериментальный код имеет версии git, один набор кода может генерировать несколько версий модели-кандидата. Эти версии определяются артефактами, показателями и параметрами, которые сложно организовать и сохранить в виде обычного текста для управления версиями git. В отличие от обычного разработчика программного обеспечения, самая последняя версия очень редко бывает лучшей.
  2. Данные так же важны, как и код, и часто меняются: один и тот же код моделирования дает разные результаты при запуске с использованием разных данных. Данные часто меняются с течением времени, поэтому, даже если код остается нетронутым, модель со временем будет развиваться так, что это не будет отражено в репозитории git.
  3. Вычисления важны и стохастичны: для обычного программного обеспечения вычисления, необходимые для создания артефактов, являются вторичными, поскольку они относительно малы / дешевы и в основном детерминированы. При разработке модели вычисления являются дорогостоящими, и одни и те же входные данные могут давать разные результаты из-за стохастической оптимизации. Это означает, что крайне важно сохранять результаты каждого запуска вычислений, а не рассматривать их как одноразовые.

Реестры моделей решают эти проблемы, сохраняя «версии моделей», которые фиксируют входные данные (код, параметры, данные) и выходы (артефакты, метрики) вычислений независимо от того, где это происходит. Если ваша производственная инфраструктура была разрушена, содержимое вашего реестра (ваша лучшая версия модели), а не содержимое репозитория git, будет тем, что вам нужно для повторного развертывания вашей модели.

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

Жизненные циклы модели должны быть отделены от жизненных циклов приложения.

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

Независимо от того, как происходит потребление, важно отделить жизненный цикл приложения-потребителя от самой модели, потому что они меняются в разных временных масштабах и с разными требованиями. В подавляющем большинстве команд логика времени выполнения приложения и использования результатов относительно стабильна, но модель должна часто обновляться в результате дрейфа данных и появления новых, улучшенных версий модели. Это верно даже без учета более сложных шаблонов, таких как теневое тестирование и A / B-тестирование, которые требуют внесения изменений в модель, работающую в том же контексте.

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

Проблема для команд моделирования

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

  • Группа моделирования поддерживает отдельную инфраструктуру хостинга и времени выполнения для моделей, как правило, API-интерфейсы, подобные микросервисам, или пакетные задания. Это обеспечивает независимость модели от приложения, но создает нагрузку на управление инфраструктурой, которая отвлекает от разработки модели. Опытные группы могут запускать эти обновления на основе веб-хуков из своего реестра моделей, но для этого требуется конфигурация DevOps, которая требует наличия хотя бы одного, если не более штатных инженеров.
  • Команда моделирования не поддерживает отдельную инфраструктуру. Модели объединяются в приложение-потребитель с использованием обычного процесса сборки. Это делается путем выборки правильной модели из реестра во время сборки и развертывания приложения. В этом шаблоне сложно обновить модель независимо от приложения-потребителя. Если приложение не настроено для истинного непрерывного развертывания, группа моделирования полагается на поддержку общей группы DevOps для получения обновлений модели в производственной среде.

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

Представляем Bridge

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

При таком подходе «RegistryOps»:

  • Специалисты по обработке данных управляют жизненным циклом своих моделей исключительно через специальный API-интерфейс и пользовательский интерфейс своего реестра моделей. Метки этапов (dev / staging / prod / etc) в реестре становятся декларативной спецификацией того, какие модели должны быть развернуты и в какой среде они должны быть развернуты.
  • Группы инженеров DevOps и машинного обучения используют Bridge для автоматизации зачастую сложного и утомительного управления ресурсами хостинга. Вы управляете Bridge, Bridge пасет инфраструктурных кошек и управляет повторяющимся кодом оболочки.
  • Обе команды могут быть уверены, что модели, отмеченные в реестре, являются обслуживаемыми, без необходимости копаться в журналах git и CI или беспокоиться о том, чтобы обновлять данные вручную.

Попробуйте быстрый старт - вы начнете развертывание из существующего реестра менее чем за 10 минут. Если вы хотите настроить MLflow для тестирования Bridge, ознакомьтесь с нашим 5-минутным руководством по настройке MLflow

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

Если у вас возникла идея или возникла проблема, откройте вопрос. Мы с нетерпением ждем вашего ответа!