Машинное обучение в облаке становится новым черным — привлекательной, но тенденцией, требующей серьезных размышлений и исследований. ML PaaS — одна из самых желанных и быстрорастущих тенденций в публичном облачном пространстве. Почти каждый поставщик облачных услуг постоянно пытается улучшить свою платформу машинного обучения, предлагая более комплексное решение для разработчиков, специалистов по данным и инженеров DevOps. Но большая проблема с машинным обучением в облаке заключается в том, насколько сложными и дорогостоящими могут стать эти решения по мере роста компании. Однако Microsoft создала очень надежную систему ML PaaS. AzureML предлагает простое комплексное решение для разработки и развертывания приложений машинного обучения для различных бизнес-потребностей.

Все, что вам действительно нужно для начала работы с AzureML, — это учетная запись Azure (… и достаточно надежное подключение к Интернету), и вы можете начать создавать решения машинного обучения корпоративного уровня, даже используя свой компьютер с Windows XP! AzureML управляет всем, начиная от подготовки кластеров, выполнения учебных заданий, создания и эксплуатации моделей машинного обучения и заканчивая развертыванием масштабируемых решений машинного обучения, при очень низких затратах. Еще одна действительно крутая вещь — AzureML легко связывает DevOps и науку о данных. Довольно здорово!

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

Войдите на портал Azure

Если у вас уже есть учетная запись Azure и личная или корпоративная подписка (это то, что Azure использует для отслеживания вашего использования, разрешений и расходов), войдите в свою учетную запись Azure и посетите Портал Azure. Портал Azure подобен торговому центру: он содержит все (и даже больше), необходимое для разработки, совместной работы и развертывания в Azure. Вы можете добавить в свою подписку различные облачные сервисы (вычисления, хранилище, искусственный интеллект, аналитику, Интернет вещей и т. д.) прямо с портала. Кроме того, вы также можете использовать Azure CLI для управления (создания, обновления, удаления) своими ресурсами.

Создание нового ресурса AML

Теперь, когда вы находитесь на портале, давайте создадим новый ресурс, щелкнув Создать ресурс в списке служб Azure, и найдите Машинное обучение в Marketplace. Здесь мы предоставим Машинное обучение Azure (также известное как AzureML и AML). Чтобы создать ресурс AML, вам потребуется указать подписку и группу ресурсов. Группа ресурсов объединит все похожие ресурсы вместе, что позволит вам управлять всем набором ресурсов вместе. Далее мы настроим нашу рабочую область ML. (DW! Мы рассмотрим, что такое рабочая область, после того, как мы закончим создание нашего ресурса AML). Для создания рабочей области нам понадобится:

  • имя для рабочей области.
  • Регион. Когда мы определяем регион, мы должны помнить о том, какие вычислительные ресурсы нам нужны для этой рабочей нагрузки. Наша цель вычислений (вычислительный ресурс, который будет выполнять наши задания) будет настроена в том же регионе, что и регион рабочей области. Так что, если нашему решению нужна машина, оптимизированная для GPU, мы должны убедиться, что эти машины доступны в регионе, который мы выбрали для нашей рабочей области. Примечание. Ресурсы в группе ресурсов не зависят от местоположения, поэтому вы можете иметь ресурсы из двух разных мест в одной группе ресурсов.
  • Учетная запись хранения. Хранилище Azure — это облачная служба Azure, предоставляющая высокодоступное, безопасное, надежное, масштабируемое и избыточное хранилище. Вы можете хранить изображения, видео, журналы, данные датчиков и многое другое в службе хранилища Azure. А учетная запись хранения Azure предоставляет доступ к хранилищу Azure и управляет конфигурациями, такими как избыточность. Вы можете использовать учетную запись хранения по умолчанию ИЛИ создать новую учетную запись, чтобы настроить уровень избыточности. По умолчанию используется локально избыточный (избыточный в том же центре обработки данных в указанном вами регионе).
  • Key Vault. В Key Vault вы можете хранить информацию, которую хотите сохранить в тайне. Чтобы получить доступ к этой информации в своих сценариях, вы можете использовать пакет AzureML SDK. Как и в случае с учетной записью хранения, вы можете использовать конкретное хранилище ключей, которое вы определили ранее.
  • Application Insights — AzureML использует App Insights для сбора данных из моделей, развернутых как веб-службы. Вы можете собирать информацию о запросах, ответах, выходных данных и т. д. из развернутого приложения машинного обучения.
  • Реестр контейнеров. AzureML использует реестр контейнеров для хранения образов, используемых при выполнении конвейера. По умолчанию реестр контейнеров не создается при первом создании рабочей области ML, чтобы пользователь не платил без необходимости. По мере прохождения этапов конвейера и создания образов Docker для этих шагов Azure создаст и настроит новый реестр контейнеров и сохранит там образы. При последующих запусках конвейера AzureML сам извлекает образы из этого репозитория, тем самым значительно экономя время.

Здорово! После того, как мы все определили, мы можем продолжить и нажать Review+Create. Сначала будет проверен наш ресурс, а после проверки разрешений и настроек мы сможем нажать Создать. Это запустит развертывание нашего ресурса машинного обучения. Определенно можно попить кофе, пока ресурс разворачивается!

Итак, если вы здесь, значит, либо вы не пьете кофе, либо вам любопытно узнать больше об AzureML… либо вы попадаете в сумасшедшее пересечение двух диаграмм Венна! Давайте углубимся в AzureML и поговорим о компонентах, которые делают AzureML таким замечательным.

Компоненты AzureML:

  1. Рабочее пространство машинного обучения. Рабочее пространство — это зонтик, который содержит все необходимое для разработки и развертывания вашего решения машинного обучения. Компоненты, необходимые для разработки и развертывания решений машинного обучения, такие как данные, вычислительные объекты и среды, записные книжки, модели, — все они присутствуют в рабочей области. Рабочая область AzureML предоставляет нам способ отслеживать и версии каждого из этих компонентов, чтобы команды могли вернуться в историю и легко отслеживать изменения, которые они вносили с течением времени.
  2. Среда. Среда определяет время выполнения различных этапов конвейера. Мы можем определить различные зависимости, env-переменные, версию нашего языка выполнения для использования здесь и многое другое.
  3. Конвейер. Думайте об этом как о дорожной карте, но для компьютера. Мы определяем набор шагов, которые должны выполняться последовательно, и это создает конвейер. Например, сначала мы определяем шаг для получения данных, затем обрабатываем данные и, наконец, обучаем данные. Конвейер — это способ определить, что необходимо сделать в виде последовательных шагов. Чтобы определить конвейер, мы должны сначала настроить шаги, а затем указать порядок выполнения этих шагов. Эти шаги могут включать в себя подготовку наших данных, обучение гиперпараметров или развертывание наших моделей, передачу данных между различными источниками и многое другое. AzureML Pipelines дает нам свободу определять различные требования к оборудованию для разных этапов. Если шаг требует больших вычислительных ресурсов, у нас есть возможность использовать аппаратное обеспечение с интенсивными вычислениями для этого шага и универсальное оборудование для других. Примечание. Необязательно выполнять шаги последовательно. В зависимости от потребностей вашего бизнеса вы также можете выполнять шаги параллельно.
  4. Выполнить. Хорошо, теперь у нас есть определенный конвейер, который представляет собой не что иное, как определение шагов, которые выполняются последовательно. Выполнение в AzureML — это выполнение этих шагов в конвейере. Запуск берет наш определенный конвейер и запускает его на определенных вычислительных целях (мы определяем вычислительные цели в шагах нашего конвейера).
  5. Эксперимент – это набор запусков. Мы определяем эксперимент и запускаем эксперимент. Так, например, запуск AzureML запускает конвейер AzureML. Теперь, если мы настроим гиперпараметр шага, мы отправим этот запуск, который запустит конвейер и даст другой результат. Если мы отправим этот запуск в один и тот же эксперимент, мы сможем эффективно отслеживать производительность между двумя запусками в этом эксперименте.

Довольно подробное обсуждение конвейеров AzureML. Должны ли мы теперь вернуться к нашему ресурсу AzureML?! Как только ваш ресурс будет развернут, позвольте нам открыть наш новый ресурс, нажав «Перейти к ресурсу», и вы попадете в интерфейс рабочей области AzureML. Довольно элегантный пользовательский интерфейс с информацией, но более изящным является AzureML Studio. Нажмите «Запустить студию», чтобы запустить классный интерфейс AzureML.

Теперь мы внутри AzureML Studio. Здесь вы сможете увидеть данные, с которыми вы работаете, красивый вид нашего конвейера в процессе его работы, информацию о ваших зарегистрированных моделях (модели, которые вы зарегистрировали для использования в своем бизнесе). Когда мы создадим наш пайплайн и запустим его, мы увидим здесь больше активности, обещаю!

Построение нашего трубопровода

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

Мы будем работать с набором данных Pima Indian Diabetes для разработки конвейера двоичной классификации с использованием AzureML.

Для разработки конвейера машинного обучения мы будем использовать AzureML SDK для Python. Установите зависимость, используя:

pip install azureml-sdk

Структура каталогов кажется интуитивно понятной, не так ли? В папке данных мы будем хранить CSV-файл, содержащий данные. Затем мы будем использовать хранилище Azure для хранения этих данных и сделать их доступными для целевого объекта вычислений, на котором запущен наш конвейер, используя класс DataStore из пакета SDK для AzureML, который мы определили ранее. Мы также можем написать скрипт для загрузки этого CSV-файла и передачи его в качестве шага в наш конвейер. Выходные данные (загруженный CSV-файл) будут отслеживаться и сохраняться нашим конвейером.

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

  • На этапе подготовки должна быть предусмотрена возможность извлечения необработанного CSV-файла, поэтому ему нужны входные данные, которые представляют собой необработанный CSV-файл.
  • Шаг подготовки имеет промежуточный вывод данных, то есть вывод этого этапа будет использоваться этапом обучения.
  • На этапе обучения будет обучаться модель, и мы также хотим сохранить модель в виде сериализованного файла таким образом, чтобы его можно было напрямую передать в производство в Azure.

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

Сценарий подготовительного этапа

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

Некоторые интересные вещи о сценарии prep.py:

  1. Использование azureml.core…? Это основная библиотека, которая дает нам доступ ко всем основным функциям AzureML, таким как доступ к наборам данных, конвейерам и запуску (которые мы используем в этом сценарии).
  2. Run.get_context() — как мы говорили ранее, запуск в конвейере AzureML — это один запуск конвейера, который содержит журналы. метрики и т. д. об этом конкретном запуске / испытании. Здесь мы получаем конфигурацию этого запуска конвейера.
  3. Мы используем анализатор аргументов. Что именно он здесь делает? Отличная мысль! Парсер аргументов — это то, что мы используем для передачи данных в виде параметров, которые используются при запуске скрипта. Мы не хотим жестко задавать параметры, которые нужны этому сценарию, потому что это не очень хорошая практика проектирования. Что мы скорее хотим сделать, так это передать эти параметры динамически. Поэтому, если мы хотим изменить начальное число для случайного разделения, мы передадим это значение в качестве параметра этому сценарию с нашего шага. Это также отличный способ отправки параметров между двумя этапами конвейера. Подумайте об этом с такой точки зрения: цель вычислений, на которой работает конвейер, не имеет такой же структуры каталогов, как в нашей локальной системе. По мере выполнения каждого шага создается образ этого скрипта в докере. Должен быть способ определить входные данные для этого скрипта, работающего в изолированной среде. В этом случае очень помогает передача аргументов через Argument Parser. Когда мы напишем наш код конфигурации конвейера, мы рассмотрим его более внимательно.

Сценарий Train-Step

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

Несколько интересных фактов о скрипте train.py:

  1. Этот сценарий получает параметры с помощью синтаксического анализатора аргументов. args.train и args.test ссылаются на то, где хранятся данные обучения и тестирования. В то время как args.model указывает, где должна быть сохранена окончательная модель.
  2. Мы используем run.log(), что это может быть? Как упоминалось ранее, Run.get_context() в конвейере AzureML предоставляет информацию об этом конкретном запуске конвейера. Здесь мы извлекаем время начала и окончания обучения, чтобы отслеживать, сколько времени занимает процесс, и записываем его в этот запуск конвейера. В идеале мы хотели бы сохранить это время довольно низким, чтобы наши пользователи были довольны. Если мы настроим наши гиперпараметры или сам алгоритм и снова отправим прогон в тот же эксперимент, мы сможем посмотреть общее время, прошедшее между прогонами; отличный способ принимать важные решения с точки зрения UX.

Конфигурация конвейера

ЛАДНО ЛАДНО! Супер крутая часть сейчас: на самом деле проектирование и запуск конвейера. Здесь я использую блокнот Jupyter, у вас есть полная свобода использовать все, что работает.

Итак, здесь мы пытаемся получить доступ и настроить рабочее пространство AML из нашей локальной системы. AzureML SDK позволяет нам сделать именно это. Все, что нам нужно, это вернуться в рабочую область AML и загрузить файл config.json, который содержит информацию о нашей рабочей области, включая имя и группу ресурсов, внутри которой находится наша рабочая область. Нам нужно скачать этот файл и сохранить его в корне каталога, с которым мы работали.

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

import os
# azureml.core for importing core components like Experiment, Workspace
from azureml.core import Workspace, Experiment, Datastore, Dataset, Environment
#To track and log run-details as the experiment runs
from azureml.widgets import RunDetails
  
from azureml.pipeline.core import Pipeline, PipelineData, PipelineRun, StepRun, PortDataReference 
from azureml.pipeline.steps import PythonScriptStep
 
from azureml.core.compute import ComputeTarget, AmlCompute
from azureml.core.compute_target import ComputeTargetException
 
from azureml.core.runconfig import RunConfiguration
from azureml.core.conda_dependencies import CondaDependencies
 
from azureml.core.model import Model

Мы уже говорили о azureml.core. Двигаясь вперед, мы экспортируем RunDetails для печати журналов в записной книжке, когда мы отправляем запуск в эксперимент. PipelineData — это данные, которые используются в качестве входных или выходных данных в одном или нескольких шагах. PipelineRun предоставляет информацию о состоянии работающего конвейера. StepRun — это запуск определенного шага в конвейере, и его полезно использовать для загрузки выходных данных определенного шага из запуска вместе с PortDataReference. В конвейере AzureML есть несколько типов шагов; PythonScript — это один из шагов, который запускает скрипт Python. Другие можно проверить здесь: Этапы конвейера AzureML. ComputeTarget и AMLCompute позволяют выполнять CRUD для вычислительных ресурсов. CondaDependecies предоставляет отличный способ настройки зависимостей среды. У Microsoft действительно отличная документация по каждому из этих модулей и классов. Рекомендую посмотреть. Возможно, вы найдете действительно крутые вещи.

Хорошо, когда это будет сделано, я перейду к получению доступа к своему рабочему пространству и начну работать с ним!

#Configure the Workspace from config.json
ws = Workspace.from_config()

Теперь настраиваем наши данные. AzureML Pipelines использует хранилища данных для получения доступа к данным, хранящимся в различных службах хранения в Azure. Наборы данных прикрепляются к рабочей области, и к ним можно обращаться по имени. Есть поддержка объектного хранилища, SQL DB и многого другого. И данные в хранилищах данных, которые можно рассматривать как версионированные объекты данных, используемые в конвейере в качестве входных данных для шага, называются набором данных. Существует 2 разных типа наборов данных: набор файловых данных и набор табличных данных. Табличный набор данных дает специалистам по данным возможность преобразовывать данные в Pandas ИЛИ Spark Dataframe.

def_blob_store = ws.get_default_datastore()
def_blob_store.upload_files(["./data/diabetes.csv"], target_path="data", overwrite=True)

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

#creating a tabular dataset. 
diabetes_data = Dataset.Tabular.from_delimited_files(def_blob_store.path('./data/diabetes.csv'))
#registered the created dataset in the workspace with the name diabetes_data
diabetes_data = diabetes_data.register(ws, 'diabetes_data')

Супер, теперь у нас есть набор данных, который зарегистрирован в нашей рабочей области. Его можно легко передать в качестве входных данных для сценария внутри шага конвейера и загрузить в Python DF. Сделав это, мы настроим нашу цель вычислений, которая будет выполнять все эти здоровенные задачи ниже. Сначала мы проверим, существует ли уже кластер, и создадим новый только в том случае, если кластер отсутствует; в противном случае используйте уже существующий. Мы используем стандартную виртуальную машину серии D общего назначения. Вы можете выбирать между очень огромным списком размеров виртуальных машин в зависимости от вашего варианта использования. Так удивительно! Проверьте размеры ВМ здесь!

aml_compute_target = "ml-cluster"
#Search for existing CLuster, create one in the ML Workspace if cluster not found
try:
    aml_compute = AmlCompute(ws, aml_compute_target)
    print("Compute Target exists already, using that")
except ComputeTargetException:
    print("Creating a new Compute Target")
    
    provisioning_config = AmlCompute.provisioning_configuration(vm_size = "STANDARD_D2_V2",
                                                                min_nodes = 1, 
                                                                max_nodes = 2)    
    aml_compute = ComputeTarget.create(ws, aml_compute_target, provisioning_config)
    aml_compute.wait_for_completion(show_output=True, min_node_count=None, timeout_in_minutes=20)
    
print("Azure Machine Learning Compute attached")

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

aml_run_config = RunConfiguration()
 
aml_run_config.target = aml_compute
aml_run_config.environment.docker.enabled = True
aml_run_config.environment.docker.base_image = "mcr.microsoft.com/azureml/base:latest"
 
aml_run_config.environment.python.user_managed_dependencies = False
 
aml_run_config.environment.python.conda_dependencies = CondaDependencies.create(
    conda_packages=['pandas','scikit-learn','numpy'], 
    pip_packages=['joblib','azureml-sdk','fusepy'], 
    pin_sdk_version=True)

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

#passing the dataset as_named_input to retrieve in the script later, like a parameter for function
raw_data = diabetes_data.as_named_input('raw_data')
train_data = PipelineData("train_data", datastore=def_blob_store).as_dataset()
test_data = PipelineData("test_data", datastore=def_blob_store).as_dataset()
scaler_file = PipelineData("scaler_file", datastore=def_blob_store)
model_file = PipelineData("model_file", datastore=def_blob_store)

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

source_directory="./prep"
prep_step = PythonScriptStep(name="prep_step",
                         script_name="./prep.py", 
                         arguments=["--train", train_data,"--test", test_data,"--scaler",scaler_file, "--test_size",0.3, "--seed", 42],
                         inputs=[raw_data],
                         outputs=[train_data,test_data,scaler_file],                         
                         compute_target=aml_compute,
                         runconfig=aml_run_config,
                         source_directory=source_directory,
                         allow_reuse=True)

Глядя на блок кода выше, мы сначала определили исходный_каталог, в котором находится скрипт. Затем мы используем PythonScriptStep, что означает, что на этом шаге выполняется сценарий Python: это всего лишь один из многих различных шагов AzureML Pipeline, доступных нам из Azure. Затем мы определяем набор аргументов. Все эти аргументы используются в сценарии prep.py, который мы видели ранее. Вот как мы динамически передаем аргументы сценарию. Мы также видели, как мы использовали ввод с этого шага в нашем файле prep.py:

dataframe=run.input_datasets[“raw_data”].to_pandas_dataframe()

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

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

source_directory="./train"
train_step = PythonScriptStep(name="train_step",
                         script_name="./train.py", 
                         arguments=["--train", train_data,"--test", test_data,"--model",model_file],
                         inputs=[train_data,test_data],
                         outputs=[model_file],                         
                         compute_target=aml_compute, 
                         runconfig=aml_run_config,
                         source_directory=source_directory,
                         allow_reuse=True)

Конфигурация этого шага очень похожа на предыдущую. Несколько вещей:

  • У нас похожая среда и вычисления для обоих этих шагов. Однако можно совершенно свободно использовать другую среду и/или оборудование в зависимости от необходимости.
  • allow_reuse=True будет повторно использовать разрешение на повторное использование результатов предыдущего запуска, если содержимое шага (скрипты/зависимости), а также входные данные и параметры остаются неизменными. Примечание. Изменения данных, поступающие из хранилища данных, здесь не учитываются. Любое изменение таких данных не будет повторяться. Изменения коснутся только скриптов или зависимостей.

Фу! Мы достигли так далеко! Все, что нам нужно сделать сейчас, это объединить шаги для разработки нашего конвейера и запустить его. Кроме того, помните, о чем мы говорили ранее, здесь шаги выполняются последовательно, однако AzureML дает нам пространство для параллельного выполнения шагов в конвейере.

#Define the order of steps to run in a sequence
steps = [prep_step,train_step]
# Design the pipeline with the steps
pipeline1 = Pipeline(workspace=ws, steps=steps)

Отлично… всего один последний шаг, и наш пайплайн готов, настроено, вперед! В блоке кода ниже мы отправим запуск этого конвейера в наш эксперимент. Как только мы реализуем эту ячейку, запуск будет выполнен. Давайте запустим это и вернемся в AzureML Studio. Мы увидим, что новый эксперимент запущен и выполняется Run1. Следует отметить использование regenerate_outputs=False; устанавливая для regenerate_output значение False, мы настраиваем конвейер для повторного использования выходных данных предыдущих запусков. Таким образом, мы не будем генерировать новый вывод для каждого запуска, если конкретный шаг не изменился. Однако, если мы установим для этого параметра значение True, новый вывод будет генерироваться каждый раз, когда мы отправляем прогон в эксперимент.

pipeline_run = Experiment(ws, 'diabetes').submit(pipeline1, regenerate_outputs=False, show_output=True)

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

На консоли есть возможность проверить сам график; посмотрите на показатели либо всего запуска, либо отдельного шага. Вкладка «Эксперименты» предоставляет много обширной информации обо всем выполнении и выполнении отдельных шагов. Каждый раз, когда мы отправляем запуск для этого эксперимента, запуск будет указан как запуск № ‹number› в этом эксперименте. Здесь следует отметить, что при первом запуске конвейера (Run # 1) он занимает больше времени, чем при последующем запуске. Это связано с тем, что создание образа докера занимает больше времени при первом запуске каждого шага. В последующих запусках мы используем кешированную версию изображения. Как только образ будет создан, статус изменится с подготовка на выполняется. Однако, если процесс все еще очень медленный, вы всегда можете поиграться с аппаратной конфигурацией вычислений. Кроме того, вы всегда можете просмотреть журналы, чтобы увидеть, что происходит во время работы конвейера. В случае ошибки также перейдите к выходным данным и журналам этого конкретного этапа, чтобы получить более четкое представление о том, что пошло не так.

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

Возможности разработки и развертывания с помощью AzureML безграничны. Одна из причин, почему я люблю AzureML, заключается в том, насколько обширным, но простым в реализации является AML. Команды могут использовать отличные инструменты для ускорения внедрения машинного обучения в свой бизнес. Например, Azure SDK значительно упростил создание конвейеров машинного обучения. Изменив всего один параметр, команды смогут переключиться с учебного кластера на основе ЦП на мощный кластер графического процессора, выполняющий рабочие процессы с интенсивным использованием графического процессора. Точно так же AzureML Workspaces упростила отслеживание и управление версиями данных и ресурсов. Azure Pipelines позволили командам автоматизировать процесс создания и выпуска решений машинного обучения пошагово. Кроме того, цены удивительно гибкие, что дает командам возможность попробовать разные компоненты, не поджигая свои средства. И, конечно же, великолепная документация и постоянно растущее и постоянно поддерживающее сообщество разработчиков делают разработку с Azure намного увлекательнее!!!