Введение

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

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

Есть много шагов и процессов, которые мы должны выполнить, прежде чем работать, и разделение среды является одним из них.

Разные роли, разные миры

Специалисты по обработке данных и инженеры машинного обучения следуют очень итеративному процессу для создания точных и надежных алгоритмов и моделей. По мере прохождения жизненного цикла машинного обучения они обнаруживают, что повторяют раздел, пока не достигнут удовлетворительного уровня производительности, а затем переходят к следующей задаче (которая может возвращаться к еще более раннему этапу). Более того, проект не завершен после того, как вы отправили первую версию; вы получаете обратную связь от реальных взаимодействий и переопределяете цели для следующей итерации развертывания. [цитата из Организация проектов машинного обучения: рекомендации по управлению проектами]

В то же время SDE, SA и DevOps придерживаются другой практики. Сначала они собирают требования от клиентов, затем разрабатывают функции в локальной среде разработки и разработки, запускают интеграционные тесты в средах NonProd или SIT (тестирование системной интеграции), а затем развертывают рабочую нагрузку в производственной среде. Могут быть задействованы и другие среды, например среда тестирования производительности, среда оценки стоимости, промежуточная среда, альфа-среда и т. Д.

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

Почему разделение среды для ML особенное?

  1. Данные участвуют в жизненном цикле. На этапе построения модели DS / MLE должен иметь доступ к «реальным» данным, среда может быть исследовательской средой, но данные обычно являются производственными данными. Для среды разработки / тестирования / альфа нам нужны данные для выполнения интеграционных тестов или тестов производительности, но данные могут быть синтетическими, потому что нам может потребоваться большой объем или мы хотим охватить определенные тестовые случаи. Это не то же самое, что и обычный программный продукт. Для разработки программного обеспечения имитируемые данные и службы-заглушки могут быть достаточно хорошими для проверки системы.
  2. Безопасность. Было бы здорово, если бы у DS / MLE был постоянный доступ к производственным данным. Это позволяет им выполнять мониторинг модели и онлайн-отладку. Исключительно сложно полагаться только на ведение журнала и отслеживание ошибок для продуктов ML для устранения проблем, потому что тихий сбой (0 предупреждение 0 ошибок) является наиболее распространенным типом ошибок для проектов ML. Однако наши данные всегда имеют конфиденциальные и конфиденциальные атрибуты, поэтому мы должны действовать с минимальными привилегиями, если это возможно. Разрешения должны отличаться от одной среды к другой.
  3. Среда автоматизации машинного обучения. В некоторых практиках разработки программного обеспечения у нас есть отдельный CI & CD для выполнения процесса CI & CD и хранения артефактов для развертывания. В этой среде будет автоматизированный процесс развертывания артефактов в других средах (dev / test / staging / prod / etc). В мире машинного обучения модели машинного обучения будут одним из типов этих артефактов. Более того, мы рассчитываем на автоматизированные конвейеры машинного обучения для обучения моделей и хранения метаданных для будущего анализа.

Возможное решение для разделения сред

  • Среда исследования: используется для EDA и развертывания кода. Ему необходимо читать производственные данные из исторического хранилища и отправлять изменения кода в репозиторий.
  • Среда CICD: используется для автоматизации и создания артефактов (библиотеки PyPI, образы докеров и т. д.).
  • Среда ML CICD: используется для обучения модели всего набора данных (долгое обучение модели), запланированного повторного обучения модели и сохранения артефактов машинного обучения (модели, поиск кодировки, статистика обучающих данных и т. д.). Он может содержать службу для управления метаданными машинного обучения (например, MLflow, Metaflow, хранилище метаданных).
  • Среды выполнения. Эти среды должны иметь ту же настройку, что и ваша команда разработчиков программного обеспечения. Таким образом, на уровне сети или IAM среды могут работать попарно. Например, ml-dev может взаимодействовать только с окружением swe-dev.

В средах разработки / подготовки и других непроизводственных средах мы можем использовать фиктивные данные для проверки системы. Таким образом, этим средам не нужен доступ к производственным данным.

Вывод

Независимо от того, как вы справляетесь с разделением среды в своих собственных проектах машинного обучения, ключевыми показателями эффективности являются рентабельность, удобный для разработчиков процесс разработки и достаточный контроль доступа. Некоторые проекты решают объединить исследование и ML CICD в единую среду, чтобы уменьшить объем DevOps, но это повысит вероятность того, что разработчики случайно внесут ошибки в хранилище артефактов ML. В этой теме нет серебряной пули, учет команды, инженерных практик и времени может помочь вам найти наиболее подходящий способ для вашей команды. Увидимся в прод.

Ссылка: