Поделиться через


Операции машинного обучения

В этой статье описывается три архитектуры Azure для операций машинного обучения с сквозной интеграцией и конвейерами непрерывной доставки (CI/CD) и переобучение конвейеров. Архитектуры предназначены для этих приложений ИИ:

  • Классическое машинное обучение
  • Компьютерное зрение (CV)
  • Обработка естественного языка

Эти архитектуры являются продуктом проекта MLOps версии 2. Они включают рекомендации, которые архитекторы решений, определенные в процессе разработки различных решений машинного обучения. Результат — это развертываемые, повторяемые и обслуживаемые шаблоны. Все три архитектуры используют службу Машинное обучение Azure.

Сведения о реализации с примерами шаблонов развертывания для MLOps версии 2 см . в акселераторе решения Azure MLOps версии 2.

Потенциальные варианты использования

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

    • Классификация двоичных и многометок.

    • Линейная, полиномиальная, гребня, лассо, квантильная и байесская регрессия.

    • ARIMA, autoregressive, SARIMA, VAR, SES, LSTM.

  • CV: Платформа MLOps в этой статье посвящена главным образом вариантам использования CV сегментации и классификации изображений.

  • Обработка естественного языка: эту платформу MLOps можно использовать для реализации:

    • Распознавание именованных сущностей:

    • Классификация текстов

    • Создание текста

    • Анализ тональности

    • Перевод текста

    • Ответы на вопросы

    • Сводка

    • Обнаружение предложений

    • Распознавание языка

    • Лексико-грамматический анализ

Имитации ИИ, глубокое обучение с подкреплением и другие формы ИИ не описаны в этой статье.

Архитектура

Шаблон архитектуры MLOps версии 2 состоит из четырех основных модульных компонентов или этапов жизненного цикла MLOps:

  • Пространство данных
  • Администрирование и настройка
  • Разработка моделей или внутренний этап цикла
  • Развертывание модели или этап внешнего цикла

Предыдущие компоненты, соединения между ними и типичные лица являются стандартными для всех архитектур сценариев MLOps версии 2. Варианты детализации каждого компонента зависят от сценария.

Базовая архитектура MLOps версии 2 для Машинное обучение — это классический сценарий машинного обучения для табличных данных. Архитектуры CV и NLP создаются и изменяют эту базовую архитектуру.

MLOps версии 2 охватывает следующие архитектуры, описанные в этой статье:

Классическая архитектура машинного обучения

Схема, на котором показана классическая архитектура машинного обучения.

Скачайте файл Visio для этой архитектуры.

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

  1. Пространство данных

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

  2. Администрирование и настройка

    Этот компонент является первым шагом в развертывании акселератора MLOps версии 2. Она состоит из всех задач, связанных с созданием и управлением ресурсами и ролями, связанными с проектом. Например, команда инфраструктуры может:

    1. Создайте репозитории исходного кода проекта.
    2. Используйте Bicep или Terraform для создания рабочих областей Машинное обучение.
    3. Создание или изменение наборов данных и вычислительных ресурсов для разработки и развертывания моделей.
    4. Определите пользователей группы проектов, их роли и элементы управления доступом к другим ресурсам.
    5. Создание конвейеров CI/CD.
    6. Создайте компоненты мониторинга для сбора и создания оповещений для метрик модели и инфраструктуры.

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

  3. Разработка моделей (внутренний этап цикла)

    Этап внутреннего цикла состоит из итеративного рабочего процесса обработки и анализа данных, который действует в выделенной и безопасной рабочей области Машинное обучение. На предыдущей схеме показан типичный рабочий процесс. Процесс начинается с приема данных, перемещается через аналитический анализ данных, экспериментацию, разработку и оценку моделей, а затем регистрирует модель для использования в рабочей среде. Этот модульный компонент, реализованный в акселераторе MLOps версии 2, не зависит от процесса, который команда обработки и анализа данных использует для разработки моделей.

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

  4. реестры Машинное обучение

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

    Лица, связанные с этим этапом, обычно являются инженерами машинного обучения.

  5. Развертывание модели (этап внешнего цикла)

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

    Лица, связанные с этим этапом, являются главным образом инженерами машинного обучения.

  6. Промежуточное и тестирование

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

  7. Развертывание в производстве

    После прохождения промежуточного и тестового этапа модель инженеры машинного обучения могут использовать утверждение, созданное человеком в цикле, для повышения его уровня в рабочей среде. Варианты развертывания модели включают управляемую конечную точку пакетной службы для сценариев пакетной службы или управляемой сетевой конечной точки или развертывания Kubernetes, которая использует Azure Arc для онлайн-сценариев практически в режиме реального времени. Как правило, производство выполняется в одной или нескольких выделенных и безопасных рабочих областях Машинное обучение.

  8. Наблюдение

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

  9. Мониторинг данных и моделей: события и действия

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

  10. Мониторинг инфраструктуры: события и действия

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

архитектура Машинное обучение CV

Схема, показывющая архитектуру компьютерного зрения.

Скачайте файл Visio для этой архитектуры.

Рабочий процесс для архитектуры CV

Архитектура Машинное обучение CV основана на классической архитектуре машинного обучения, но она имеет изменения, относящиеся к защищенным сценариям CV.

  1. Пространство данных

    Этот компонент демонстрирует хранилище данных организации и потенциальные источники данных и целевые объекты для проекта обработки и анализа данных. Инженеры данных являются основными владельцами этого компонента в жизненном цикле MLOps версии 2. Платформы данных Azure на этой схеме не являются исчерпывающими или предписательными. Изображения для сценариев CV могут поступать из различных источников данных. Для повышения эффективности при разработке и развертывании моделей CV с Машинное обучение рекомендуется Хранилище BLOB-объектов Azure и Azure Data Lake Storage.

  2. Администрирование и настройка

    Этот компонент является первым шагом в развертывании акселератора MLOps версии 2. Она состоит из всех задач, связанных с созданием и управлением ресурсами и ролями, связанными с проектом. Для сценариев CV администрирование и настройка среды MLOps версии 2 в значительной степени совпадает с классическим машинным обучением, но включает дополнительный шаг. Команда инфраструктуры использует функцию маркировки Машинное обучение или другого средства для создания проектов маркировки изображений и заметок.

  3. Разработка моделей (внутренний этап цикла)

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

  4. реестры Машинное обучение

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

  5. Развертывание модели (этап внешнего цикла)

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

  6. Промежуточное и тестирование

    Этап промежуточного и тестового тестирования зависит от методик клиента. Этот этап обычно включает такие операции, как тестовые развертывания для производительности конечных точек, проверки качества данных, модульного тестирования и ответственные проверки ИИ на наличие предвзятости моделей и данных. Для сценариев CV инженеры машинного обучения не должны переобучивать кандидат модели на рабочие данные из-за ограничений ресурсов и времени. Вместо этого команда обработки и анализа данных может использовать рабочие данные для разработки моделей. Кандидатная модель, зарегистрированная в цикле разработки, оценивается для рабочей среды. Этот этап выполняется в одной или нескольких выделенных и безопасных рабочих областях Машинное обучение.

  7. Развертывание в производстве

    После прохождения промежуточного и тестового этапа модель инженеры машинного обучения могут использовать утверждение, созданное человеком в цикле, для повышения его уровня в рабочей среде. Варианты развертывания модели включают управляемую конечную точку пакетной службы для сценариев пакетной службы или управляемой сетевой конечной точки или развертывания Kubernetes, которая использует Azure Arc для онлайн-сценариев практически в режиме реального времени. Как правило, производство выполняется в одной или нескольких выделенных и безопасных рабочих областях Машинное обучение.

  8. Наблюдение

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

  9. Мониторинг данных и моделей: события и действия

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

  10. Мониторинг инфраструктуры: события и действия

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

архитектура обработки естественного языка Машинное обучение

Схема архитектуры обработки естественного языка.

Скачайте файл Visio для этой архитектуры.

Рабочий процесс для архитектуры обработки естественного языка

Архитектура обработки естественного языка Машинное обучение основана на классической архитектуре машинного обучения, но имеет некоторые изменения, относящиеся к сценариям NLP.

  1. Пространство данных

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

  2. Администрирование и настройка

    Этот компонент является первым шагом в развертывании акселератора MLOps версии 2. Она состоит из всех задач, связанных с созданием и управлением ресурсами и ролями, связанными с проектом. Для сценариев обработки естественного языка администрирование и настройка среды MLOps версии 2 в значительной степени совпадают с классическим машинным обучением, но с дополнительным шагом: создание проектов меток и заметок с помощью функции маркировки Машинное обучение или другого средства.

  3. Разработка моделей (внутренний этап цикла)

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

  4. реестры Машинное обучение

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

  5. Развертывание модели (этап внешнего цикла)

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

  6. Промежуточное и тестирование

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

  7. Развертывание в производстве

    После прохождения промежуточного и тестового этапа модель инженеры машинного обучения могут использовать утверждение, созданное человеком в цикле, для повышения его уровня в рабочей среде. Варианты развертывания модели включают управляемую конечную точку пакетной службы для сценариев пакетной службы или управляемой сетевой конечной точки или развертывания Kubernetes, которая использует Azure Arc для онлайн-сценариев практически в режиме реального времени. Как правило, производство выполняется в одной или нескольких выделенных и безопасных рабочих областях Машинное обучение.

  8. Наблюдение

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

  9. Мониторинг данных и моделей: события и действия

    Как и в архитектуре CV, данные и модели мониторинга и этапы событий и действий MLOps для обработки естественного языка являются ключевыми отличиями от классического машинного обучения. Автоматическая переобучение обычно не выполняется в сценариях обработки естественного языка при обнаружении снижения производительности модели на новом тексте. В этом случае процесс "человек в цикле" необходим для проверки и анимации новых текстовых данных для модели, которая выполняется плохо. Часто следующее действие — вернуться к циклу разработки модели, чтобы обновить модель с новыми текстовыми данными.

  10. Мониторинг инфраструктуры: события и действия

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

Компоненты

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

  • Azure Pipelines — это система сборки и тестирования, основанная на Azure DevOps и используемая для конвейеров сборки и выпуска. Azure Pipelines разделяет эти конвейеры на логические шаги, называемые задачами.

  • GitHub — это платформа размещения кода для рабочих процессов управления версиями, совместной работы и CI/CD.

  • Azure Arc — это платформа, которая использует Azure Resource Manager для управления ресурсами Azure и локальными ресурсами. Ресурсы могут включать виртуальные машины, кластеры Kubernetes и базы данных.

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

  • Azure Data Lake Storage — это файловая система, совместимая с Hadoop. Он имеет интегрированное иерархическое пространство имен и масштабируемую и экономию хранилища BLOB-объектов.

  • Azure Synapse Analytics — это безграничная служба аналитики, которая объединяет интеграцию данных, хранение корпоративных данных и аналитику больших данных.

  • Центры событий Azure — это служба, которая использует потоки данных, создаваемые клиентскими приложениями. Затем он получает и сохраняет потоковые данные, которые сохраняют последовательность полученных событий. Клиенты могут подключаться к конечным точкам концентратора для получения сообщений для обработки. Эта архитектура использует интеграцию Data Lake Storage.

Другие вопросы

Предыдущий шаблон архитектуры MLOps версии 2 имеет несколько критически важных компонентов, включая управление доступом на основе ролей (RBAC), которое соответствует заинтересованным лицам бизнеса, эффективному управлению пакетами и надежным механизмам мониторинга. Эти компоненты совместно способствуют успешной реализации и управлению рабочими процессами машинного обучения.

RBAC на основе persona

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

Примеры personas

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

Специалист по обработке и анализу данных и инженер машинного обучения

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

Тип: Person
Конкретный проект: Да

Аналитик данных

Аналитики данных предоставляют необходимые входные данные для действий по обработке и анализу данных, например выполнение запросов SQL для бизнес-аналитики. Обязанности этой роли включают работу с данными, выполнение анализа данных и поддержку разработки моделей и развертывания моделей.

Тип: Person
Конкретный проект: Да

Средство тестирования моделей

Тестировщики моделей проводят тесты в средах тестирования и промежуточных сред. Эта роль обеспечивает функциональное разделение от процессов CI/CD.

Тип: Person
Конкретный проект: Да

Заинтересованные лица бизнеса

Бизнес-заинтересованные лица связаны с проектом, например менеджером по маркетингу.

Тип: Person
Конкретный проект: Да

Руководитель проекта или руководитель по обработке и анализу данных

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

Тип: Person
Конкретный проект: Да

Владелец проекта или продукта (владелец бизнеса)

Бизнес-заинтересованные лица отвечают за Машинное обучение рабочую область в соответствии с владением данными.

Тип: Person
Конкретный проект: Да

Техническая поддержка платформы

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

Тип: Person
Конкретный проект: нет

Конечный пользователь модели

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

Тип: Person или Process
Конкретный проект: Да

Процессы CI/CD

Ci/CD обрабатывает выпуск или откат изменений в средах платформы.

Тип: Процесс
Конкретный проект: нет

Рабочая область машинного обучения

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

Тип: Процесс
Конкретный проект: нет

Процессы мониторинга

Процессы мониторинга — это вычислительные процессы, которые отслеживают и оповещают на основе действий платформы.

Тип: Процесс
Конкретный проект: нет

Процессы управления данными

Процессы управления данными сканируют проект машинного обучения и хранилища данных для управления данными.

Тип: Процесс
Конкретный проект: нет

Членство в группе Microsoft Entra

При реализации RBAC группы Microsoft Entra предоставляют гибкий и масштабируемый способ управления разрешениями доступа для разных пользователей. Группы Microsoft Entra можно использовать для управления пользователями, которым требуются те же разрешения и доступ к ресурсам, например потенциально ограниченные приложения и службы. Вместо добавления специальных разрешений отдельным пользователям будет создана группа, которая применяет специальные разрешения ко всем членам этой группы.

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

Удостоверение RBAC

Рассмотрим, как использовать следующие встроенные роли Azure RBAC для применения RBAC к рабочим и предварительным средам. Для архитектуры в этой статье рабочие среды включают промежуточные, тесты и рабочие среды. Предварительные среды включают среды разработки. Следующие роли RBAC основаны на лицах, описанных ранее в этой статье.

Стандартные роли

Определенные роли компонентов

Эти сокращения ролей RBAC Azure соответствуют следующим таблицам.

Рабочая среда
Пользователь Рабочая область машинного обучения Azure Key Vault Реестр контейнеров Учетная запись хранения Azure Azure DevOps Azure Artifacts Рабочая область Log Analytics Azure Monitor
Специалист по обработке и анализу данных R LAR МИ
Аналитик данных
Средство тестирования моделей
Заинтересованные лица бизнеса МИ
Руководитель проекта (ведущий по обработке и анализу данных) R R, KVR R LAR МИ
Владелец проекта или продукта МИ
Техническая поддержка платформы O O, KVA DOPCA O O O
Конечный пользователь модели
Процессы CI/CD O O, KVA AcrPush DOPCA O O O
Рабочая область машинного обучения R C C
Процессы мониторинга R LAR МИ
Процессы управления данными R R R R R
Предварительная среда
Пользователь Рабочая область машинного обучения Key Vault Реестр контейнеров Storage account Azure DevOps Azure Artifacts Рабочая область Log Analytics Azure Monitor
Специалист по обработке и анализу данных ADS R, KVA C C C C LAC MC
Аналитик данных R C LAR MC
Средство тестирования моделей R R, KVR R R R R LAR МИ
Заинтересованные лица бизнеса R R R R R
Руководитель проекта (ведущий по обработке и анализу данных) C C, KVA C C C C LAC MC
Владелец проекта или продукта R R МИ
Техническая поддержка платформы O O, KVA O O DOPCA O O O
Конечный пользователь модели
Процессы CI/CD O O, KVA AcrPush O DOPCA O O O
Рабочая область машинного обучения R, KVR C C
Процессы мониторинга R R R R R R LAC
Процессы управления данными R R R

Примечание.

Каждый пользователь сохраняет доступ к длительности проекта, кроме технической поддержки платформы, которая имеет временный или JIT-доступ Microsoft Entra управление привилегированными пользователями (PIM).

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

Управление пакетами

Зависимости от различных пакетов, библиотек и двоичных файлов распространены во время жизненного цикла MLOps. Эти зависимости, часто разработанные сообществом и быстро развивающиеся, требуют знаний экспертов по предмету для правильного использования и понимания. Необходимо убедиться, что соответствующие пользователи имеют безопасный доступ к различным ресурсам, таким как пакеты и библиотеки, но также необходимо предотвратить уязвимости. Специалисты по обработке и анализу данных сталкиваются с этой проблемой при сборке специализированных стандартных блоков для решений машинного обучения. Традиционные подходы к управлению программным обеспечением являются дорогостоящими и неэффективными. Другие подходы обеспечивают больше значения.

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

Этот подход включает в себя безопасный список трех стандартных репозиториев пакетов машинного обучения в отрасли: Реестр артефактов Microsoft, индекс пакета Python (PyPI) и Conda. Безопасное перечисление позволяет самостоятельно обслуживать отдельные Машинное обучение рабочих областей. Затем используйте автоматизированный процесс тестирования во время развертывания для сканирования полученных контейнеров решений. Сбои элегантно завершают процесс развертывания и удаляют контейнер. На следующей схеме и потоке процессов демонстрируется этот процесс:

Схема, показывающая подход к безопасному Машинное обучение пакету.

Последовательность операций процесса

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

  2. Машинное обучение предоставляет решения машинного обучения как контейнеры Docker. По мере разработки этих решений они отправляются в реестр контейнеров. Microsoft Defender для контейнеров создает оценки уязвимостей для образа контейнера.

  3. Развертывание решения происходит через процесс CI/CD. Microsoft Defender для DevOps используется в стеке для обеспечения управления безопасностью и защиты от угроз.

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

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

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

Наблюдение

В MLOps мониторинг имеет решающее значение для поддержания работоспособности и производительности систем машинного обучения и обеспечения того, чтобы модели оставались эффективными и согласованными с бизнес-целями. Мониторинг поддерживает управление, безопасность и управление затратами во время внутреннего цикла. Она обеспечивает наблюдаемость производительности, ухудшения модели и использования при развертывании решений на этапе внешнего цикла. Действия по мониторингу относятся к таким лицам, как Специалист по обработке и анализу данных, бизнес-заинтересованные лица, руководители проектов, владельцы проектов, техническая поддержка платформы, процессы CI/CD и процессы мониторинга.

Выберите платформу мониторинга и проверки в зависимости от настройки Машинное обучение рабочей области, например проекта, команды или отдела.

Эффективность модели

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

Смещение данных

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

Среда: рабочая среда
Упрощение функций Azure: Машинное обучение — мониторинг моделей

Смещение прогнозирования

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

Среда: рабочая среда
Упрощение функций Azure: Машинное обучение — мониторинг моделей

Ресурс

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

Среда: все
Упрощение azure. Мониторинг метрик конечных точек в Сети

Метрики использования

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

Клиентские запросы

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

Среда: рабочая среда
Упрощение работы Azure: Мониторинг метрик конечных точек в Сети, таких как RequestsPerMinute. Примечания:

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

Задержки регулирования — это замедление запроса и реагирования на передачу данных. Регулирование происходит на уровне Resource Manager и уровне обслуживания. Отслеживайте метрики на обоих уровнях.

Среда: рабочая среда
Упрощение функций Azure:

  • Monitor — Resource Manager, сумма requestThrottlingDelayMs, ResponseThrottlingDelayMs.
  • Машинное обучение. Чтобы проверить сведения о запросах конечных точек, можно включить журналы трафика в сети. Для обработки журналов можно использовать рабочую область Log Analytics.

Примечание. Выравнивание допустимых пороговых значений для целей уровня обслуживания рабочей нагрузки (SLOS) или соглашений об уровне обслуживания (SLA) и нефункциональных требований решения (NFR).

Ошибки, созданные

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

Среда: рабочая среда
Упрощение функций Azure: Машинное обучение. Включение журналов трафика конечной точки в Интернете для проверки сведений о запросе. Например, можно проверить количество XRequestId с помощью ModelStatusCode или ModelStatusReason. Для обработки журналов можно использовать рабочую область Log Analytics.
Примечания:

  • Все коды ответов HTTP в диапазоне 400 и 500 классифицируются как ошибка.

Оптимизация затрат

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

Вычисления рабочей области

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

Среда: все
Упрощение процедур Azure: управление затратами Майкрософт — оповещения о бюджете
Примечания:

  • Задайте пороговые значения бюджета на основе первоначальных NFR и оценок затрат.
  • Используйте несколько пороговых уровней. Несколько пороговых уровней гарантируют, что заинтересованные лица получают соответствующее предупреждение до превышения бюджета. Эти заинтересованные лица могут включать бизнес-потенциальных клиентов, владельцев проектов или потенциальных клиентов в зависимости от организации или рабочей нагрузки.
  • Согласованные оповещения бюджета также могут быть триггером для рефакторинга для поддержки большего спроса.
Устаревшая рабочая область

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

Среда: предварительная подготовка
Упрощение функций Azure:

Примечания:

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

Безопасность

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

Среда: все
Упрощение функций Azure: Политика Azure для Машинное обучение

безопасность конечных точек.

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

Среда: рабочая среда
Упрощение azure. Microsoft Defender для API обеспечивает широкую защиту жизненного цикла, обнаружение и покрытие ответов для API. Примечание. Defender для API обеспечивает безопасность API, опубликованных в Azure Управление API. Вы можете подключить Defender для API на портале Microsoft Defender для облака или в экземпляре Управление API в портал Azure. Необходимо интегрировать Машинное обучение сетевые конечные точки с Управление API.

Мониторинг развертывания

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

Стандарты и управление

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

Среда: все
Упрощение функций Azure:

  • Назначение управляемой политики и жизненный цикл с помощью Azure Pipelines для обработки политики как кода.
  • PSRule для Azure предоставляет платформу тестирования для инфраструктуры Azure в качестве кода.
  • Политику Enterprise Azure можно использовать в качестве кода в политиках развертывания системы на основе CI/CD, наборах политик, назначениях, исключениях политик и назначениях ролей.

Примечание. Дополнительные сведения см. в руководстве Azure по Машинное обучение соответствию нормативным требованиям.

проверка безопасности;

Реализуйте автоматизированные проверки безопасности в рамках автоматизированных процессов интеграции и развертывания.

Среда: все
Упрощение функций Azure: Defender для DevOps
Примечание. Вы можете использовать приложения в Azure Marketplace для расширения этого процесса для модулей тестирования безопасности, отличных от Майкрософт.

Текущая служба

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

Среда: рабочая среда
Упрощение функций Azure:

Соавторы

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

Основные авторы:

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги