Изучение архитектуры решения
Давайте изменим архитектуру операций машинного обучения (MLOps), чтобы понять, чего и зачем мы пытаемся достичь.
Представьте, что вместе с командой специалистов, ответственных за обработку и анализ данных, и разработчиков программного обеспечения вы согласовали следующую архитектуру для обучения, тестирования и развертывания модели классификации диабета:
Примечание.
На схеме демонстрируется упрощенное представление архитектуры MLOps. Чтобы просмотреть архитектуру более подробно, изучите различные варианты использования в акселераторе решений MLOps (версии 2).
Компоненты архитектуры:
- Настройка: создание всех необходимых ресурсов Azure для решения.
- Разработка моделей (внутренний цикл): изучение и обработка данных для обучения и оценки модели.
- Непрерывная интеграция: упаковка и регистрация модели.
- Развертывание модели (внешний цикл): развертывание модели.
- Непрерывное развертывание: тестирование модели и перенос в рабочую среду.
- Мониторинг: мониторинг производительности модели и конечной точки.
Команда специалистов по обработке и анализу данных отвечает за разработку модели. Команда разработчиков программного обеспечения отвечает за интеграцию развернутой модели с веб-приложением, которое используется врачами, чтобы понять, есть ли у пациента диабет. Вы отвечаете за переход от разработки к развертыванию модели.
Вы ожидаете, что команда специалистов по обработке и анализу данных будет постоянно предлагать изменения в скриптах, используемых для обучения модели. При каждом изменении сценария обучения требуется переобучение модели и ее повторное развертывание в существующую конечную точку.
Вы хотите разрешить команде по обработке и анализу данных экспериментировать, не затрагивая код, подготовленный к запуску в рабочей среде. Вы также хотите убедиться, что для всего нового или обновленного кода автоматически выполняются согласованные проверки качества. После проверки кода для обучения модели вы будете использовать обновленный скрипт обучения для обучения новой модели и ее развертывания.
Чтобы отслеживать изменения и проверять код перед обновлением рабочего кода, необходимо поработать с ветвями. Вы договорились со специалистами по обработке и анализу данных о том, что каждый раз, когда им требуется внести изменения, они будут создавать ветвь возможности для создания копии кода и внесения изменений в эту копию.
Любой специалист по обработке и анализу данных может создать ветвь возможности и работать в ней. Если после обновления кода необходимо, чтобы этот код стал новым кодом рабочей среды, придется создать запрос на вытягивание. В запросе на вытягивание другие пользователи будут видеть, что представляют собой предложенные изменения, предоставляя остальным возможность просматривать и обсуждать их.
При каждом создании запроса на вытягивание необходимо автоматически проверить, работает ли код, а также убедиться в том, что качество кода соответствует стандартам вашей организации. После того как код пройдет проверку качества, ведущий специалист по обработке и анализу данных должен проверить изменения и утвердить обновления, прежде чем можно будет объединить запрос на вытягивание. Код в главной ветви можно обновить соответствующим образом.
Внимание
Никому никогда нельзя разрешать передавать изменения в главную ветвь. Чтобы защитить код, особенно код рабочей среды, необходимо применить принудительное обновление основной ветви только с помощью запросов на вытягивание, которые требуется утвердить.