Как построить лучшую модель
Специалисты по обработке данных тренируют модели, используя алгоритмы обучения. Есть много разных способов построить модель линейной регрессии или модель дерева решений. Кроме того, каждый обучающий алгоритм (тренер) имеет несколько настраиваемых параметров, значения которых можно изменить до начала обучения. Каждое значение может повлиять на конечный результат (то есть на обученную модель).
Что произойдет, если мы попытаемся найти лучшие значения настраиваемых параметров и повторно использовать их для обучения лучшей модели?
Прежде чем мы начнем, нам нужно ответить на несколько вопросов:
- Как определить, что данный набор настраиваемых параметров является лучшим?
- Где границы того, что можно настраивать, а что нет?
- Как найти лучшие значения для настраиваемых параметров?
- Как мы можем гарантировать, что наш поиск лучших значений для настраиваемых параметров совместим с современной практикой обучения моделей?
Не будем забывать, что в машинном обучении такие настройки известны как «гиперпараметры», а задача поиска значений оптимальных гиперпараметров известна как «HPO» (задача оптимизации гиперпараметров).
Гиперпараметры и параметры модели
Начнем с основного определения: что является гиперпараметром, а что нет?
Новичков в ML часто путают параметры модели и гиперпараметры алгоритмов обучения.
Параметры модели изучаются во время обучения, а гиперпараметры, наоборот, должны быть установлены специалистом по анализу данных или AutoML перед обучением.
Хороший пример параметров модели - наклон и пересечение в линейной регрессии или тензор веса в сверточном слое - мы пытаемся найти лучшие параметры во время одного обучения. С другой стороны, начальная скорость обучения в алгоритме оптимизации SGD или количество деревьев в случайном лесу должны быть определены перед обучением и могут отличаться в разных запусках обучения.
Основная идея HPO - найти гиперпараметры данного алгоритма машинного обучения или конвейера, который возвращает наилучшее значение метрики, измеренное на проверочном наборе.
Да, мы могли бы рассматривать лучшие гиперпараметры как параметры, полученные из набора данных проверки, а не непосредственно из алгоритмов машинного обучения. И я полагаю, что с наступлением эры AutoML (в ближайшем будущем) разница между параметрами модели и гиперпараметрами исчезнет.
Математическое описание HPO (проблема оптимизации гиперпараметров)
Оптимизацию гиперпараметров можно сформулировать как двухуровневую (двухуровневую) задачу оптимизации, где оптимальные параметры обучающего набора зависят от гиперпараметров.
Пусть w обозначает параметры (например, веса и смещения), а λ обозначает гиперпараметры (например, вероятность отсева). Пусть L_t и L_v - функции, отображающие параметры и гиперпараметры на потери при обучении и проверке соответственно. Мы стремимся решить
подлежит:
куда:
От 1"]
Задача двухуровневой оптимизации состоит из двух подзадач, называемых проблемами верхнего уровня и нижнего уровня, где проблема верхнего уровня должна быть решена с учетом оптимальности проблема нижнего уровня. Минимаксные задачи являются примером двухуровневых программ, в которых цель верхнего уровня равна отрицательной цели нижнего уровня.
Двухуровневые программы впервые были изучены в экономике для моделирования динамики фирмы лидер / последователь (Von Stackelberg, 2010) и с тех пор нашли применение в различных областях (обзор см. В Colson et al. (2007)). В машинном обучении многие проблемы могут быть сформулированы как двухуровневые программы, включая оптимизацию гиперпараметров, обучение GAN (Goodfellow et al., 2014), метаобучение и поиск нейронной архитектуры (Zoph & Le, 2016).
Даже если все цели и ограничения линейны, двухуровневые задачи сильно NP-трудны (Hansen et al., 1992; Vicente et al., 1994). NP-трудная сложность задачи HPO - причина, по которой мы должны избегать прямых методов или техники грубой силы и отдавать предпочтение эвристическим алгоритмам с полиномиальной сложностью (даже если эти эвристики не имеют доказанных верхних оценок полиномиальной сложности, но наблюдаются только как таковые) .
Алгоритмы машинного обучения, поддерживаемые фреймворком Apache Ignite ML.
Перечислим все доступные в настоящее время алгоритмы обучения Ignite ML и настраиваемые гиперпараметры этих алгоритмов.
Я начну с алгоритмов, основанных на разных версиях SGD (стохастический градиентный спуск).
- maxIterations - максимальное количество итераций перед остановкой обучения.
- batchSize - размер пакета для алгоритма обновления на основе SGD.
- locIterations - максимальное количество локальных итераций перед синхронизацией.
- seed - просто семя
- updatesStgy - аналог оптимизатора в фреймворках DL.
- maxIterations - максимальное количество итераций перед остановкой обучения.
- batchSize - размер пакета для алгоритма обновления на основе SGD.
- locIterations - максимальное количество локальных итераций перед синхронизацией.
- seed - просто семя
- updatesStgy - аналог оптимизатора в фреймворках DL.
SVMLinearClassificationTrainer
- amountOfIterations - количество итераций внешнего алгоритма SDCA.
- amountOfLocIterations - количество итераций локального алгоритма SDCA.
- лямбда - параметр регуляризации
- seed - просто семя
- arch - архитектура нейронной сети, определяющая слои и функции активации.
- потеря - функция потерь, которая должна быть минимизирована во время тренировки.
- maxIterations - максимальное количество итераций перед остановкой обучения.
- batchSize - размер пакета для алгоритма обновления на основе SGD.
- locIterations - максимальное количество локальных итераций перед синхронизацией.
- семя - просто семя
- updatesStgy - аналог оптимизатора в фреймворках DL.
Наборы гиперпараметров для четырех алгоритмов аналогичны, потому что все алгоритмы внутренне используют алгоритм итеративной оптимизации. Количество итераций и тип оптимизатора играют важную роль. Даже незначительные изменения гиперпараметров могут привести к значительным различиям в предсказательных способностях полученных моделей.
Теперь перейдем к широко используемому семейству алгоритмов метрической кластеризации и классификации.
- k - количество обнаруживаемых кластеров
- maxIterations - количество итераций
- epsilon - числовое значение, которое используется для проверки сходимости на каждой итерации.
- расстояние - мера расстояния в рамках ML, например Евклидова, Хэмминга или Манхэттена.
- maxCountOfClusters - количество возможных кластеров
- maxCountOfIterations - количество итераций, критерий остановки (другой критерий остановки - эпсилон)
- epsilon - разница между значениями старого и нового центроидов
- countOfComponents - количество компонентов
- maxLikelihoodDivergence - максимальное расхождение между максимумом вероятности каждого из двух векторов в наборах данных для идентификации аномалий;
- minElementsForNewCluster - минимальное количество требуемых аномалий с точки зрения maxLikelihoodDivergence для создания кластера.
- minClusterProbability - минимальная вероятность кластера
KNNClassificationTrainer и KNNRegressionTrainer
- k - количество ближайших соседей
- DistanceMeasure - метрика расстояния фреймворка ML, например Евклидова, Хэмминга или Манхэттена.
- isWeighted - по умолчанию false; если true, этот гиперпараметр включает взвешенный алгоритм KNN.)
- dataCache - держатель для набора обучающих объектов, для которого известен класс.
- indexType - распределенный пространственный индекс, имеющий три значения: ARRAY, KD_TREE и BALL_TREE.
- k - количество точек-кандидатов для фазы прогнозирования поиска ближайших соседей
- maxIterations - количество итераций
- epsilon - числовое значение, которое используется для проверки сходимости на каждой итерации.
- расстояние - мера расстояния фреймворка машинного обучения, например Евклидова, Хэмминга или Манхэттена.
Перейдем к выращиванию деревьев и лесных зарослей. Садоводство имеет специфику, которая связана с количеством информации и энтропией.
DecisionTreeClassificationTrainer и DecisionTreeRegressionTrainer
- maxDeep - максимальная глубина дерева
- minImpurityDecrease - минимальное уменьшение примесей
- usingIdx - параметр, позволяющий использовать структуру индекса вместо сортировки при обучении.
- featuresCountSelectionStgery - стратегия, определяющая количество случайных функций для изучения одного дерева.
- maxDepth - максимальная глубина дерева
- minImpurityDelta - узел в дереве решений разделяется на два узла, если разница между значениями примесей на двух узлах меньше значения minImpurityDecrease незапятненного узла.
- subSampleSize - значение, которое лежит в [0; MAX_DOUBLE] интервал; параметр, определяющий количество повторений выборки при равномерной выборке с заменой
- seed - начальное значение, которое используется в генераторах случайных чисел.
GDBBinaryClassifierOnTreesTrainer и GDBRegressionOnTreesTrainer
- maxDeep - максимальная глубина дерева
- minImpurityDecrease - минимальное уменьшение примесей
- usingIdx - параметр, позволяющий использовать структуру индекса вместо сортировки при обучении;
- gradStepSize - постоянный вес каждой модели в композиции.
- cntOfIterations - максимальное количество итераций
- checkConvergenceFactory - фабрика для построения проверки сходимости, которая используется для предотвращения переобучения и изучения бесполезных моделей во время обучения.
Рассмотрим последний представитель ансамблевых алгоритмов - бэггинг, в котором использовались разные обучающие алгоритмы (не только деревья).
- ensembleSize - количество обученных моделей в ансамбле.
- subsampleRatio - соотношение подвыборки набора данных.
- агрегатор - тип агрегирования прогнозов ансамблевой модели.
- featureVectorSize - размерность вектора признаков.
- featuresSubspaceDim - размерность подпространства объекта.
Следующие алгоритмы обучения не имеют гиперпараметров:
Нет необходимости запоминать все параметры, но я надеюсь, что вы впечатлены количеством настраиваемых параметров в инфраструктуре Apache Ignite ML.
Препроцессоры
Тренировочный процесс в Ignite ML не ограничивается только тренировками. Различные препроцессоры могут помочь нормализовать числа или преобразовать строки в числа.
Ignite ML теперь поддерживает настройку гиперпараметров инструкторов препроцессора. Например, в NormalizationTrainer пользователь может настроить гиперпараметр p (параметр, отвечающий за нормализацию в пространстве L ^ p), а в ImputerTrainer пользователь может ввести стратегию.
ПРИМЕЧАНИЕ. Правильный выбор масштабатора столбцов - это хорошо известная проблема настройки гиперпараметров. В настоящее время Ignite ML предлагает несколько скейлеров: MinMax Scaler, MaxAbsScaler и StandardScaler. К сожалению, возможность настройки масштабатора столбцов в качестве гиперпараметра пока не поддерживается.
Когда элементы AutoML будут добавлены в структуру машинного обучения, проблема выбора средства масштабирования столбцов будет решена.
Оценка модели
Apache Ignite ML предоставляет набор показателей классификации и регрессии для оценки точности прогнозирования моделей машинного обучения.
Есть много алгоритмов классификации. Однако модели классификации оцениваются аналогичным образом. Для каждой точки данных в задаче контролируемой классификации есть два выхода: истинный выход и предсказанный выход, созданный на основе модели. Следовательно, результаты для каждой точки данных можно отнести к одной из четырех категорий:
- Истинно положительный (TP) - метка положительная, и прогноз также положительный.
- True Negative (TN) - метка отрицательная, и прогноз также отрицательный.
- Ложно-положительный результат (FP): метка отрицательная, но прогноз положительный.
- Ложноотрицательный (FN): ярлык положительный, но прогноз отрицательный.
Ниже приведен список метрик двоичной классификации, поддерживаемых в Apache Ignite ML:
- Точность
- Сбалансированная точность
- F-мера
- Выпадать
- FN
- FP
- FDR
- MissRate
- ЧПС
- Точность
- Отзывать
- Специфичность
- TN
- TP
Пояснения и формулы для этих показателей можно найти здесь.
ПРИМЕЧАНИЕ. В Apache Ignite ML оценка мультиклассовой классификации пока не поддерживается.
Когда непрерывная выходная переменная прогнозируется на основе нескольких независимых переменных, используется регрессионный анализ.
Ниже приведен список показателей регрессии, которые поддерживаются в Apache Ignite ML:
- MAE
- R2
- RMSE
- RSS
- MSE
ПРИМЕЧАНИЕ. Расчет показателей выполняется распределенно, без сбора всех прогнозируемых или фактических (достоверных) меток на одном клиентском узле.
Разделение тестового поезда
Не рекомендуется изучать и проверять параметры модели на одних и тех же данных. Эта практика приводит к переобучению. Одно из наиболее эффективных решений - сохранить и использовать часть обучающих данных в качестве тестового набора.
Термин разделения тестового поезда в Apache Ignite ML означает фильтрацию данных, хранящихся в кэше, на две части (обучающая часть, используемая для обучения модели, и тестовая часть, используемая для оценки качества модели). Фильтрация выполняется по определенным условиям. На самом деле никакой передачи данных или перетасовки сети.
Все методы fit () имеют параметр, который передает условие фильтрации в каждый кеш.
ПРИМЕЧАНИЕ. Из-за распределенного и ленивого характера операций с наборами данных разделение набора данных является ленивой операцией. Операция может быть определена как условие фильтрации, которое применяется к начальному кэшу для формирования как обучающего, так и тестового наборов данных.
В следующем примере модель обучается только на 75% начального набора данных. Значение параметра фильтра является результатом функции split.getTrainFilter (), которая может продолжить или отклонить строку из исходного набора данных.
Типы перекрестной проверки
Хорошо, разделение тестового поезда помогает избежать переобучения. Однако, разбивая доступные данные и исключая одно или несколько подмножеств данных из обучающего набора, мы значительно сокращаем количество выборок, которые используются для изучения параметров модели. Результаты зависят от конкретного случайного выбора пары подмножеств обучения и проверки.
Подход перекрестной проверки решает эту проблему. Apache Ignite ML реализует кросс-валидацию в K-кратном порядке:
- Обучающий набор разделен на несколько поднаборов данных. Параметр k определяет количество поднаборов данных.
- Ignite ML использует k-1 складок (подмножеств) в качестве обучающих данных и обучает модель.
- Полученная модель проверяется на данных, которые не использовались для обучения.
Apache Ignite предоставляет функциональные возможности перекрестной проверки, позволяющие параметризовать проверяемый тренажер, метрики, которые должны быть рассчитаны для модели, и количество складок, на которые должны быть разделены обучающие данные.
Более подробную информацию о параметрах перекрестной проверки вы можете найти в документации.
Пользователь также может передать split.getTrainFilter () объекту CrossValidation для выполнения перекрестной проверки только данных обучения.
Процесс настройки гиперпараметров
Во многих случаях ручная настройка невозможна, потому что нам нужно настроить несколько параметров. Конечно, мы могли бы написать несколько циклов друг в друге, чтобы перебирать все возможные комбинации параметров, как в следующем примере:
И, конечно же, первая идея каждого инженера-программиста - автоматизировать процесс генерации и внедрения набора параметров в обучающие алгоритмы и препроцессоры.
Но я рад сообщить, что, начиная с версии 2.8 Ignite ML framework, доступна функция автоматической настройки гиперпараметров. Теперь Ignite ML включает встроенную библиотеку для последовательной и параллельной оптимизации неудобных дискретных пространств поиска.
Кроме того, в дорожной карте запланирована функция поддержки пространств поиска с действительными, дискретными и условными измерениями. Скорее всего, Apache Ignite 3.0 будет поставляться с этой функцией на борту.
ParamGrid
Первичным объектом, который хранит все возможные значения гиперпараметров, является объект ParamGrid.
Существует несколько подходов к поиску оптимального набора гиперпараметров:
- Грубая сила (поиск по сетке). Традиционным способом оптимизации гиперпараметров является поиск по сетке (поиск по параметрам). Поиск по сетке - это исчерпывающий поиск по заданному вручную подмножеству пространства гиперпараметров алгоритма обучения.
- Случайный поиск. Случайный поиск заменяет исчерпывающий перечень всех комбинаций случайным их выбором.
- Эволюционная оптимизация. Эволюционная оптимизация - это методика глобальной оптимизации шумных функций черного ящика. В оптимизации гиперпараметров эволюционная оптимизация использует эволюционные алгоритмы для поиска в пространстве гиперпараметров для данного алгоритма.
Объект ParamGrid поддерживает некоторые методы-сеттеры, которые задают параметры поисковой стратегии.
После создания объекта ParamGrid его можно передать объекту CrossValidation с помощью метода withParamGrid ().
Во-первых, мы рассмотрим базовую технику HPO, Grid Search (или Brute Force).
Основная идея этого подхода - запустить ML Pipeline со всеми возможными комбинациями параметров для получения окончательных показателей. Когда у нас есть заполненная таблица из двух столбцов со следующими столбцами: «Имена и значения параметров» и «Значение показателя», легко найти лучшую комбинацию гиперпараметров для повторного использования в обучении с нуля.
Следует иметь в виду комбинаторный взрыв количества комбинаций параметров по мере роста количества гиперпараметров и их вариантов значений.
Например, если у нас есть два гиперпараметра с десятью вариантами, будет выполнено 10 * 10 = 100 обучающих прогонов. Если увеличить количество гиперпараметров с 2 до 5, сохраняя по десять вариантов для каждого, то 10 * 10 * 10 * 10 * 10 = 100 000 прогонов тренировок будут выполнены. И, полагаю, никто не станет долго ждать завершения 100 000 тренировочных заездов.
Вы можете найти полный пример здесь.
Параллельное исполнение
Когда я запускал настройку гиперпараметров для моделей scikit-learn, для случаев случайного поиска и грубой силы, я часто писал распараллеливание вручную, чтобы запустить часть обучения с распараллеливанием.
Меня смутило, что такая библиотека, как Hyperopt, использует Apache Spark или MongoDB для параллельного обучения и не имеет встроенного распараллеливания. Запуск внешних исполнителей JVM для запуска параллельного выполнения для меня слишком сложен.
Конечно, когда ParamGrid был реализован в Apache Ignite ML, следующей остановкой для поезда наших разработчиков стало ускорение поиска грубой силой. Если у вас достаточно свободной памяти и низкая загрузка ЦП, рекомендуется начать новую тренировку, не дожидаясь завершения последней тренировки.
Перебор всех возможных комбинаций, при котором каждое обучение выполняется независимо, можно легко распараллелить без барьеров синхронизации.
Чтобы запустить параллельную версию перекрестной проверки, вам необходимо изменить ParallelismStrategy с NO_PARALLELISM на ON_DEFAULT_POOL в LearningEnvironmentBuilder (параметр CrossValidation), как в следующем примере:
Представьте, что у нас есть набор данных в кеше Ignite, и нам нужно выполнять десятки тренировок одновременно.
После вызова метода tuneHyperParameters () для поиска методом перебора выполняются следующие шаги:
- Объект CrossValidation генерирует все возможные комбинации параметров.
- Объект CrossValidation создает последовательность задач (по одной задаче на каждую комбинацию параметров).
- Задачи отправляются в ThreadPool (по умолчанию с одним основным потоком).
- Каждая задача выполняется независимо, и каждый результат отправляется в общий потокобезопасный объект CrossValidationResult.
- Внутри каждой задачи все параметры вводятся в соответствующие места конвейера машинного обучения.
Каждая задача создает новый экземпляр набора данных на основе кеша, и каждый раздел набора данных распространяется по кластеру Ignite.
Вы можете найти полный пример здесь.
Как сократить количество тренировок на данных (альтернативные подходы)
В [2] Бенжио пишет, что ручной поиск и поиск по сетке преобладают в качестве современного уровня техники, несмотря на десятилетия исследований глобальной оптимизации и публикацию нескольких алгоритмов оптимизации гиперпараметров; Bengio подробно описывает причины этой аномалии:
- Нет никаких технических накладных расходов или препятствий для ручной оптимизации.
- Поиск по сетке прост в реализации, а распараллеливание - тривиально.
- Как правило, Grid Search (с доступом к вычислительному кластеру) находит лучшее λ, чем результаты чисто ручной последовательной оптимизации (за то же время).
- Поиск по сетке надежен в пространствах с низкой размерностью (например, 1-d, 2-d).
Я могу добавить, что производительность поиска по сетке быстро снижается, когда он выполняет поиск лучших значений гиперпараметров в пространстве размерности больше трех.
Задача метаоптимизации
Пространство параметров часто имеет высокий ранг, а исследуемая поверхность выглядит как стопка грязной одежды в корзине для белья. В результате стандартные методы выпуклой и невыпуклой оптимизации неприменимы при поиске глобального или локального оптимума.
Случайный поиск
Поиск по сетке и ручной поиск - наиболее широко используемые стратегии для оптимизации гиперпараметров. В статье [2] эмпирически и теоретически показано, что случайно выбранные испытания более эффективны для оптимизации гиперпараметров, чем испытания на сетке. Когда мы сравниваем алгоритмы машинного обучения, сконфигурированные с помощью чистого поиска по сетке, с алгоритмами машинного обучения, которые настроены с помощью случайного поиска, мы обнаруживаем, что случайный поиск в том же домене может найти такие же или лучшие модели и использует небольшую часть времени вычислений. и кластерные ресурсы, необходимые для поиска в сетке.
Реализация Apache Ignite ML пока не поддерживает генерацию случайных параметров из диапазона и в соответствии с заданным распределением, как в статье [2], но реализация делает случайные переходы и испытания на дискретной сетке, чтобы гарантировать не более заданное количество попыток. Расчетное значение метрики за один тренировочный прогон не влияет на выбор набора гиперпараметров.
В следующем примере показано, как выполнить десять тренировок, чтобы найти достаточно хороших гиперпараметров.
Также Ignite ML включает параллельную версию оптимизации случайного поиска. Пользователь Ignite может включить его, изменив ParallelismStrategy с NO_PARALLELISM на ON_DEFAULT_POOL в LearningEnvironmentBuilder.
Генетические алгоритмы (эволюционная оптимизация)
Генетические алгоритмы, также известные как эволюционная оптимизация, применяют механизмы естественного отбора для решения задачи оптимизации (например, найти минимум функции).
Надеюсь, вы знакомы с основными принципами генетических алгоритмов, такими как популяция, особи, функция приспособленности, отбор, кроссовер (кроссинговер) и мутация. Если нет, то рекомендую следующую статью или Википедию.
Вкратце, внедрение генетического алгоритма для решения проблемы HPO включает следующие шаги:
- Генетический алгоритм (GA) генерирует начальную популяцию (фиксированные наборы гиперпараметров, причем каждый набор гиперпараметров представляет отдельного человека в популяции).
- После этого GA оценивает исходную популяцию (запускает тренировочные прогоны и получает значение функции приспособленности; например, значение показателя или оценки по складкам для каждого набора гиперпараметров).
- С помощью SelectionStrategy (например, Выбор колеса рулетки) генетический алгоритм выбирает лучших особей из исходной популяции, которые станут родителями нового поколения.
- GA создает популяцию следующего поколения с операторами кроссовера и мутации.
- Кроссовер действует следующим образом: для создания нового члена популяции он случайным образом выбирает двух родителей из предыдущего поколения и комбинирует их гены в соответствии с выбранной стратегией кроссовера. В Ignite ML реализованы одноточечный кроссовер, двухточечный кроссовер, k-точечный кроссовер и равномерный кроссовер.
- С помощью определяемой пользователем функции mutationProbability оператор мутации случайным образом изменяет несколько хромосом каждого вновь созданного потомка. Оператор мутации изменяет хромосомы на допустимые значения из области поиска.
- Генетический алгоритм оценивает новое поколение, в которое входят только что сгенерированные дети.
- Шаги с 2 по 6 повторяются до тех пор, пока не будет достигнуто максимальное количество поколений или пока не будет достигнуто какое-либо другое условие остановки или сходимости (например, недостаточное улучшение функции приспособленности).
Также стратегия Ignite ML Evolutional поддерживает элитарность. Элитизм - это практический вариант общего процесса конструирования нового населения. Элитарность позволяет лучшим организмам нынешнего поколения без изменений передаваться следующему поколению.
Эта стратегия известна как «элитарный отбор». Стратегия гарантирует, что качество решения GA не снижается от поколения к поколению. Вы можете настроить количество элитных хромосом в ParamGrid.
Также Ignite ML включает параллельную версию оптимизации случайного поиска. Когда вы работаете в Ignite, вы можете включить распараллеливание, изменив ParallelismStrategy с NO_PARALLELISM на ON_DEFAULT_POOL в LearningEnvironmentBuilder.
Внутри параллельная версия GA реализована как параллельный расчет функций приспособленности для всех людей в популяции. (одна фитнес-функция в одном потоке). Вычисление фитнес-функции эквивалентно тренировочному запуску с фиксированным набором гиперпараметров, представленным индивидуально. Окончание оценки новых людей - естественный барьер синхронизации.
Ниже приводится практический пример создания объекта ParamGrid:
В этом примере с тремя гиперпараметрами каждый человек в популяции будет иметь три хромосомы (гена): p, maxDeep и minImpurityDecrease. Значения из массивов будут переданы в ParamGrid.
Давайте подробнее рассмотрим пару особей в исходной популяции.
Предположим, что оператор выбора выбирает (1.0; 1.0; 0.0) и (5.0; 2.0; 0.8) в качестве родителей и что родители производят двух детей посредством одноточечного кроссовера: (1.0; 2.0; 0.8) и (5.0; 1.0; 0.0 ).
После этого оператор мутации изменяет ген у первого человека с 0,8 на 0,9. В результате к популяции нового поколения добавляются двое детей (1,0; 2,0; 0,9) и (5,0; 1,0; 0,0).
Надеюсь, я объяснил некоторые хитрости использования генетических алгоритмов для поиска лучших гиперпараметров.
В заключение
Я надеюсь, дорогой читатель, что теперь вы имеете представление о том, как работает оптимизация гиперпараметров в Ignite ML.
В этой статье мы пошагово прошли оптимизацию гиперпараметров в Apache Ignite ML.
Автоматическая настройка гиперпараметров моделей машинного обучения может быть выполнена с помощью реализации HPO Ignite ML. В отличие от случайного поиска, эволюционная оптимизация выбирает гиперпараметры, применяя механизмы естественного отбора и, таким образом, тратя больше времени на оценку многообещающих значений. Результатом может быть меньшее количество оценок функции пригодности и лучшая производительность обобщения на тестовом наборе по сравнению со случайным поиском и поиском по сетке.
Конечно, здесь есть много работы для участников Ignite ML: добавление методов оптимизации, таких как байесовская оптимизация или оптимизация на основе градиента, и такие улучшения, как логика EarlyStopping, которая основана на условиях, которые реализуются через обратные вызовы.
Но существующие методы могут значительно уменьшить количество запусков обучения, а также количество затрачиваемого времени ЦП и размер занимаемой памяти.
