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

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

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

Производительность модели, среди прочего, напрямую связана с ее обучением, этапом машинного обучения, на котором стремятся узнать лучшие параметры модели. Однако перед тренировочным процессом необходимо установить некоторые параметры. Эти параметры известны как гиперпараметры и часто определяются специалистами по данным на основе их практического опыта. Например, в случае известного алгоритма обучения Gradient Boosting некоторые из гиперпараметров, которые должны быть определены перед его запуском, — это скорость обучения и количество оценок.

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

Претворение идеи в жизнь

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

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

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

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

Рис. 1. Элементы для обучения многих моделей в Azure ML.

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

Чтобы проводить обучение параллельно, мы будем использовать тип компонента, доступный в Azure ML, ParallelRunStep. Это позволяет выполнять задачу параллельно; в нашем случае каждый параллельный прогон соответствует обучению одной из множества моделей и является дочерним заданием ParallelRunStep. Рисунок 2 в целом показывает, как работает выполнение конвейера с помощью ParallelRunStep. Azure ML распределяет выполнение дочерних заданий (многие модели обучают задание) в ядрах компьютерного кластера. В этом примере кластер состоит из двух узлов с четырьмя ядрами в каждом.

Рисунок 2. Параллельное обучение многих моделей.

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

Hyperdrive также выполняет параллельную обработку, поэтому пробные версии распределяются по разным ядрам вычислительного кластера. Рисунок 3 иллюстрирует тот же вид, представленный ранее, но с наличием HyperDrive. Каждая задача ParallelRunStep отвечает за обучение одной из множества моделей и запускает HyperDrive для оптимизации гиперпараметров соответствующей модели. Каждая пробная версия, запускаемая Hyperdrive, представляет задание в AzureML.

Рисунок 3. Параллельное обучение многих моделей с помощью HPO.

Распределение заданий в узлах, показанное на Рис. 3, является просто иллюстрацией, чтобы дать вам представление о распределении. В реальном мире планировщик AzureML — это процесс, который определяет это распределение заданий.

Ускорение решений для многих моделей с помощью HyperDrive

Хорошей новостью для вас является то, что команда Microsoft Early Access Engineering уже разработала общедоступный актив под названием Many Models Solution Accelerator. Этот актив выполняет большую часть работы, необходимой для обучения многих моделей. Он основан на прогнозировании количества продуктов, продаваемых в продуктовых магазинах. Каждая модель в примере соответствует паре магазина и товара.

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

Я разветвил репозиторий акселератора решений и внес некоторые дополнения, чтобы помочь с обучением многих моделей с помощью обучения HPO. Я объясню, как это сделать с самого начала. Вам нужен доступ к подписке Azure и опыт работы с блокнотами Jupyter в Python.

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

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

Рисунок 4. Заполнение формы шаблона для создания ресурсов.

После создания ресурса необходимо выполнить четыре основных шага для обучения множества моделей с помощью HPO. Первый — создание среды разработки по инструкции в EnvironmentSetup.md. После выполнения этого шага вы создадите вычислительный экземпляр для запуска записных книжек в рабочей области машинного обучения Azure и клонируете код ускорителя решений в этот экземпляр. Раздел Записные книжки вашего рабочего пространства должен выглядеть так, как показано на рис. 5.

Рис. 5. Рабочая область Azure ML.

Второй шаг — создание и настройка рабочей области машинного обучения Azure при развертывании вычислительного кластера для обучения. Вы делаете это, выполняя шаги в записной книжке 00_Setup_AML_Workspace.ipynb. При создании кластера вы можете выбрать наиболее удобный размер ВМ для вашего проекта.

На третьем этапе вы подготавливаете данные для обучения и проверки моделей. Для этого выполните шаги в записной книжке 01_Data_Preparation.ipynb, где вы загружаете данные, а затем регистрируете их как актив данных в рабочей области.

После завершения настройки среды и подготовки данных вы готовы к обучению моделей. На этом этапе вы можете использовать подход AutoML или собственный сценарий обучения. Последний будет нашим выбором, поэтому мы можем выбрать наш алгоритм обучения и использовать HyperDrive. Для этого мы будем использовать блокнот 02_CustomScript_HPO_Training_Pipeline.ipynb, адаптированную версию блокнота 02_CustomScript_Training_Pipeline.ipynb из оригинального репозитория Github. Новый поставляется со всеми инструкциями и комментариями, необходимыми для обучения с использованием HyperDrive.

Запустив конвейер, вы можете наблюдать за выполнением своих заданий, щелкнув пункт меню Azure ML Jobs. Когда вы это сделаете, вы сможете увидеть экран, подобный показанному на Рис. 6.

Рисунок 6. Мониторинг выполнения заданий.

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

Рис. 7. Параметр "Включить дочерние задания".

На рис. 6 показано несколько типов заданий. Конвейерный тип — это родительское задание, с которого начинается весь процесс обучения. Шаг конвейера — это этап ParallelRunStep в конвейере. На этом шаге параллельно инициируется несколько обучающих задач, каждая из которых соответствует заданию типа azureml.ManyModelsCustomTrain. Каждое из этих заданий обучает одну из многих моделей и запускает процесс Hyperdrive HPO, задание командного типа. Наконец, каждый пробный запуск процесса HPO соответствует заданию очистки.

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

Обсуждение и дальнейшие действия

Блокнот, с которого вы начинаете процесс обучения, хорошо задокументирован, объясняя все этапы обучения. Программы на Python также говорят сами за себя. Поэтому, чтобы не повторяться, я прокомментирую лишь несколько фрагментов кода, чтобы помочь вам лучше понять, как работает конфигурация параллелизма процесса. В следующем фрагменте из записной книжки 02_CustomScript_HPO_Training_Pipeline.ipynb определяется конфигурация параллельного выполнения:

parallel_run_config = ParallelRunConfig(source_directory='./scripts',
                                        entry_script='train.py',
                                        mini_batch_size="1",
                                        run_invocation_timeout=timeout,
                                        error_threshold=-1,
                                        output_action="append_row",
                                        environment=train_env,
                                        process_count_per_node=2,
                                        compute_target=compute,
                                        node_count=2,
                                        run_max_try=3)

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

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

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

hyperdrive = HyperDriveConfig(run_config=script_config, 
                              hyperparameter_sampling=params, 
                              policy=None, 
                              primary_metric_name='mae', 
                              primary_metric_goal=PrimaryMetricGoal.MINIMIZE, 
                              max_total_runs=6, 
                              max_duration_minutes=10, 
                              max_concurrent_runs=2)

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

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

Рис. 8. Анализ испытаний.

Мы применили этот подход в базовом примере, чтобы показать, как проводить обучение многим моделям с помощью HPO в Azure ML. Этот метод может помочь вам повысить производительность прогнозирования по сравнению со сценарием, в котором вы вручную определяете гиперпараметры модели. Этот метод связан с дополнительными затратами на проведение испытаний и должен использоваться с умом, чтобы сбалансировать затраты и производительность при применении метода к вашему проекту. Если вы хотите двигаться дальше, я предлагаю вам рассмотреть некоторые улучшения метода, показанного здесь. Одним из них является тестирование других алгоритмов обучения, таких как Extreme Gradient Boosting или XGBoost, для повышения производительности прогнозирования. Еще одна вещь, которую следует учитывать, — это использование подхода проверки модели, основанного на k-кратной перекрестной проверке, для оценки производительности модели без переобучения.

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

Еще один важный момент, о котором следует упомянуть, заключается в том, что шаги, предпринятые в этой статье, касаются только обучения. Чтобы сделать вывод, вам нужно посмотреть блокнот 03_CustomScript_Forecasting_Pipeline.ipynb, который также доступен в репозитории Solution Accelerator.

Спасибо за чтение и удачи в ваших проектах по машинному обучению.

Пауло Ласерда (Paulo Lacerda) — архитектор облачных решений с искусственным интеллектом в Microsoft, специализирующийся на предоставлении технических знаний по ключевым задачам и внедрении ускорителей решений, чтобы помочь клиентам использовать Azure AI Services.

До прихода в Microsoft он работал архитектором ИИ-решений в Global Hitss в Бразилии. Кроме того, он много лет проработал в IBM на различных должностях, таких как разработчик, архитектор программного обеспечения и специалист по техническим продажам.

Пауло имеет степень магистра и в настоящее время работает над докторской диссертацией в области искусственного интеллекта, применяемого для анализа медицинских изображений. Его основные интересы: Computer Vision, MLOps и NLP.

Первоначально опубликовано на OpenDataScience.com

Читайте другие статьи по науке о данных на OpenDataScience.com, включая учебные пособия и руководства от начального до продвинутого уровня! Подпишитесь на нашу еженедельную рассылку здесь и получайте последние новости каждый четверг. Вы также можете пройти обучение по науке о данных по запросу, где бы вы ни находились, с нашей платформой Ai+ Training. Подпишитесь также на нашу быстрорастущую публикацию на Medium, ODSC Journal, и узнайте, как стать писателем.