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

Наша эпистемологическая ограниченность и иллюзия знания

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

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

Сигнализируют ли эти множественные локальные минимумы о каком-либо значении риска?
Если есть, то какие?

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

A. Обзор настройки гиперпараметров

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

а) Гиперпараметры

Я использовал родной XGBoost API для Python.

Среди многих гиперпараметров, встроенных в собственный API XGBoost, этот анализ фокусируется на следующих 8 гиперпараметрах из-за ограниченной доступности вычислительных ресурсов.

Для определения этих гиперпараметров обратитесь к документации родного XGBoost API.

Помимо этих 8 гиперпараметров, я настроил количество итераций, num_boost_round, используя early_stopping_round в процессе настройки.

Подробнее о гиперпараметрах XGBoost можно прочитать в хорошем резюме, написанном Джейсоном Браунли: A Gentle Introduction to the Gradient Boosting Algorithm for Machine Learning.

b) Метод настройки

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

Чтобы сэкономить вычислительные затраты на анализ, я сделал 4 пары параметров из 8: а именно

(макс_глубина, эта)
(подвыборка, colsample_bytree)
(min_child_weight, гамма) и
(reg_alpha, reg_lambda) .

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

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

Что касается методологии настройки, здесь я хотел бы выделить несколько важных сносок.

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

c) Первый результат настройки

Здесь у нас есть 3D-визуализация результатов четырех парных настроек гиперпараметров. Каждая диаграмма отражает производительность каждой настройки парного гиперпараметра.

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

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

for reg_alpha in [0, 1e-2, 0.1, 1, 2, 3, 4, 8, 10, 12, 14] 
for reg_lambda in [0, 1e-2, 0.1, 1, 2, 3, 4, 8, 10, 12, 14] ]

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

В таблице ниже представлены 10 лучших показателей производительности в поисковой сетке.

Таблица определяет наилучшую производительность в точке данных поисковой сетки (reg_alpha = 0,1, reg_lambda = 8,0); и второе место (reg_alpha = 3.0, reg_lambda = 0.1).

Чтобы поближе взглянуть на сложный ландшафт производительности пары гиперпараметров (reg_alpha и reg_lambda), я нарезал ландшафт производительности вдоль reg_alpha по его значениям двух верхних точек данных, а именно при reg_alpha = 0,1 и 3,0.

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

Кривая производительности, срезанная вдоль reg_alpha=0,1 выше, подтверждает 3 локальных минимума при (reg_lambda = 0,01, 1,00 и 8,00). Между 0 и 2 есть заметные провалы и подъемы. В некотором смысле локальный минимум при reg_lambda = 0,01 и эти провалы и подъемы не были бы зафиксированы, если бы у нас не было детальной настройки локальной сетки поиска между 0 и 1.

Теперь давайте посмотрим на другую кривую производительности, срезанную вдоль reg_alpha = 3.0, и ее 10 лучших точек данных поисковой сетки производительности.

Второй срез ландшафта производительности вдоль (reg_alpha = 3.0) определяет острую пропасть, образовавшуюся между (reg_lambda = 0,01) и (reg_lambda = 1,0). Интенсивная неровность в форме пропасти — (вдоль reg_lambda = 0,01, 0,1 и 1,00) — была зафиксирована настройкой локальной сетки поиска, которая была намного мельче, чем любая другая часть сетки поиска. Другими словами, если бы мы пропустили единственную точку данных (reg_lambda = 0,1) в нашей поисковой сетке, мы бы не смогли зафиксировать наличие локального минимума между (reg_lambda = 0,01) и (reg_lambda = 1,0).

d) Слепая зона поиска по сетке и визуализации

Эти 2 среза кривых производительности выявили общую ловушку поиска по сетке: то, что было зафиксировано в ландшафте производительности, — это только результаты производительности, спроецированные на выбранную сетку поиска. Назовите их производительность в поисковой сетке; и у нас нет никакой информации о производительности какой-либо точки данных вне сетки поиска. Назовите это внесистемной производительностью.

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

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

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

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

e) Второй этап настройки reg_alpha и reg_lambda.

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

for reg_alpha in [0, 1e-2, 2e-2, 3e-2, 0.1, 0.5, 1, 1.5, 1.8, 1.9, 2, 2.1, 2.2, 2.5, 3, 3.5, 4]
for reg_lambda in [0, 1e-2, 2e-2, 3e-2, 0.1, 0.5, 1, 1.5, 1.8, 1.9, 2, 2.1, 2.2, 2.5, 3, 4, 5, 6, 7, 7.5, 8, 8.5, 9, 9.5, 10, 10.5, 11, 11.5, 12, 12.5, 13, 13.5, 14, 14.5, 15, 15.5]

А вот и 3D визуализация результата тюнинга 2-го тура.

Как и ожидалось, 2-й этап настройки пары гиперпараметров (reg_alpha и reg_lambda) показал гораздо более суровую производительность с большим количеством провалов и скачков, чем 1-й этап настройки.

Вот 10 лучших точек данных поисковой сетки производительности 2-го раунда настройки.

Итак, это подтверждает справедливость моего более раннего беспокойства.

Во-первых, грубая детализация 1-й сетки поиска недооценила фактическую чувствительность ландшафта производительности к небольшим изменениям значений пары гиперпараметров.
Таблица 10 лучших точек данных сетки поиска производительности показывает, что 2-й раунд настройки с более тонкой детализацией обнаружил наилучшую точку данных производительности в месте (reg_alpha = 0,5, reg_lambda = 13,5), которое полностью отличается от результата настройки 1-го раунда (reg_alpha = 0,1, reg_lambda = 13,5). reg_lambda = 8.0).

Б. Последствия риска использования нескольких локальных минимумов и используемых методологий

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

Вот краткий обзор этих ограничений.

Ограничение 1) Слепая зона поиска по сетке:

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

Ограничение 2) Иллюзорная визуализация

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

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

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

С. Смещение-Дисперсиякомпромисс при выборе модели

Теперь, на данном этапе, учитывая результаты этих двух раундов настройки, мы хотели бы принять предварительное решение по выбору модели, чтобы ответить на следующий вопрос. Какую настроенную модель выбрать: 1-й результат настройки или 2-й результат настройки?

Можем ли мы сказать, что 2-й раунд настройки представляет собой лучшее решение по сравнению с результатом 1-го раунда, потому что он дал лучшую производительность во время настройки (к-кратная перекрестная проверка)?

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

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

Вот таблица, в которой сравниваются характеристики между набором данных перекрестной проверки и тестовым набором данных — «Настройка (проверка MAE)» и «Тестовая производительность (MAE)» соответственно — для 3 этапов: этап предварительной настройки, после 1-й пары -мудрая настройка, а пост-2-я попарная настройка.

Из таблицы видно, что наилучшие результаты теста фактически были получены при настройке 1-го раунда, а не при настройке 2-го раунда. Это указывает на то, что лучший результат перекрестной проверки во время второго раунда настройки объясняется дисперсией или переобучением.

Чтобы найти компромисс между смещением и дисперсией, мы должны выбрать результат 1-го раунда и отклонить результат 2-го раунда для выбора модели.

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

Д. Обсуждение

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

Установим новую поисковую сетку, чтобы проверить это сомнение?

Это была бы бесконечная история.

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

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

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

Ограничение 3) Частичная попарная настройка

Единая совместная настройка всех гиперпараметров позволит лучше отразить фактическое взаимодействие производительности между всеми гиперпараметрами. И это может привести к совершенно другому выводу. В этом смысле глобальный минимум, зафиксированный парной настройкой, может быть неточным и отличаться от истинного глобального минимума.
Имея всего 4 попарных настройки, мы не покрываем все возможные пары комбинаций (28=8×7/2) для 8 гиперпараметров. Взаимодействия между этими отсутствующими комбинациями не фиксируются четырьмя парными настройками.

Парная настройка reg_alpha и reg_lambda собственного XGBoost API продемонстрировала высокую чувствительность модели к небольшим изменениям значений пары гиперпараметров и выявила эпистемологические ограничения поиска по сетке и интерполированной 3D-визуализации.

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

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

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

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

Имеет ли вообще значение глобальный минимум с точки зрения общей оптимизации настроенной модели?

Еще один момент: при анализе эпистемологическое ограничение не казалось проблематичным для 3 других ландшафтов производительности, а именно для следующих 3 пар: (max_depth, eta), (subsample, colsample_bytree), (min_child_weight, gamma) — потому что они были относительно последовательно. Очевидно, что эпистемологическое ограничение попало в поле зрения нашего радара только с высокочувствительным ландшафтом производительности reg_alpha и reg_lambda.

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

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

Будут ли множественные локальные минимумы указывать на нестабильность модели настроенной модели в области развертывания, где в модель могут быть введены новые типы наборов данных?

Что вы думаете?

Ни на один из этих вопросов, кажется, нет самоочевидного ответа.

Д. Заключение

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

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

Поиск по сетке определял производительность модели только в сетке поиска, оставляя неизвестными характеристики вне сетки поиска. Ситуацию усугубляло то, что 3D-визуализация отображала артефакт интерполяции триангуляции по точкам данных вне сетки поиска и создавала иллюзию знания.

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

Спасибо, что прочитали этот пост.

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

ПОДТВЕРЖДЕНИЕ

Я хотел бы выразить благодарность команде редакторов TDS, особенно Katherine Prairie, за их бесценные советы по редактированию на этапе редактирования.