#featureselection #hpo #hpt #global #optimization #mbho
Недавно я начал тестирование библиотек глобальной оптимизации для одномерной задачи отбора признаков.
Сформировал датасет, проверил самые известные в ds тусовке optuna, skopt, hyperopt (см. по тэгу #featureselection).
Ну и, наконец, представляю своей алгоритм. Назван он Model-based heuristic optimization (MBHO), и по сути похож на байесовскую оптимизацию гауссовым процессом.
Только гауссов процесс я заменил на более универсальный бустинг (опционально с квантилями), а поиск кандидатов ведётся вместо Expected Improvement, Probability of improvement, Upper Confidence Bound такими достаточно простыми эвристиками:
1) на каждом шаге с опр. вероятностью выбирается режим, exploration или exploitation
2) в exploration мы рекомендуем проверить самые неисследованные точки - лежащие дальше всего от уже проверенных, + имеющие самую высокую неопределённость в случае использования квантилей
3) в exploitation режиме мы строим для всей области поиска прогноз, и исследуем точку с самым высоким прогнозом. если такая уже проверена, дополнительно учитываем расстояния от уже проверенных точек и неопределённости.
4) есть ещё несколько мелких опций
Почему гауссов процесс меня не устроил? Да он тупо зачастую плохо приближает данные, и качество решения, как следствие, отвратительное (пример будет в комментах). + долго работает.
Какие есть ещё фишки:
1) закодил 4 метода определения "затравочных" кандидатов, Random, Equidistant, Fibonacci, ReversedFibonacci. В какой-то мере это аналоги soblo/lhe и прочего из skopt.
2) есть возможность строить визуализацию поиска. видно, какие точки уже проверены, как к ним фиттится модель и какие даёт прогнозы, как рассчиталась перспективность каждого кандидата в зависимости от настроек, и какой кандидат в итоге выбран.
К результатам. В бенче я в основном смотрел на процент случаев, когда оптимизатор нашёл истинный максимум.
Для 20 итераций лидером была - optuna/tpe с 69%, для 50 - hyperopt/atpe с 81%. skopt этих показателей не смог превысить.
Показатели моего MBHO: 20 итераций - 70%, 50 итераций - 100%. По времени медленнее оптуны, но быстрее hyperopt/skopt. То есть моё решение победило 3 известные либы оптимизации в одномерном случае.
Да, можно возразить, что я заточил алгоритм под свои конкретные задачи, или вообще старался выставить оппонентов в невыгодном свете, но
1) старался возможности конкурентов исследовать по-полной
2) у них же тоже было тестирование на профильных задачах, им никто не мешал тоже тестироваться на одномерном случае
3) у моего алгоритма достаточно много параметров, и он как раз-таки остаётся недоисследованным. все вычисления я провёл навскидку с просто "разумными" значениями, наверняка можно натюнить лучшее время работы и точность.
Ну и моя основная мотивация, зачем я всё это начинал: в предварительном тестировании встроенные важности признаков бустингов себя хорошо показали, FS по таким важностям разумно делать только с RFECV, но в sklearn RFECV делает полный перебор (да и не работает с категориями), а на практике у меня десятки тысяч признаков и большие датасеты.
Получается, благодаря новому MBHO оптимизатору я смогу просчитывать лишь небольшой % от признаков и при этом находить глобально оптимальные сочетания.
В комментах картинки. Лучшим методом инициализации оказался эквидистантный (что в принципе логично, позволяет получить максимум информации). И что особенно интересно, наличие оценки неопределённости с помощью квантильной регрессии не супер важно - да, улучшает результат, но эвристика с расстояниями работает и сама по себе хорошо.
Реализация MBHO заняла ~700 строк кода, поддерживается максимизация и минимизация (в отличие от hyperopt, где надо извращаться с негацией функции). Правда, нет асинхронности и многопоточности.
Недавно я начал тестирование библиотек глобальной оптимизации для одномерной задачи отбора признаков.
Сформировал датасет, проверил самые известные в ds тусовке optuna, skopt, hyperopt (см. по тэгу #featureselection).
Ну и, наконец, представляю своей алгоритм. Назван он Model-based heuristic optimization (MBHO), и по сути похож на байесовскую оптимизацию гауссовым процессом.
Только гауссов процесс я заменил на более универсальный бустинг (опционально с квантилями), а поиск кандидатов ведётся вместо Expected Improvement, Probability of improvement, Upper Confidence Bound такими достаточно простыми эвристиками:
1) на каждом шаге с опр. вероятностью выбирается режим, exploration или exploitation
2) в exploration мы рекомендуем проверить самые неисследованные точки - лежащие дальше всего от уже проверенных, + имеющие самую высокую неопределённость в случае использования квантилей
3) в exploitation режиме мы строим для всей области поиска прогноз, и исследуем точку с самым высоким прогнозом. если такая уже проверена, дополнительно учитываем расстояния от уже проверенных точек и неопределённости.
4) есть ещё несколько мелких опций
Почему гауссов процесс меня не устроил? Да он тупо зачастую плохо приближает данные, и качество решения, как следствие, отвратительное (пример будет в комментах). + долго работает.
Какие есть ещё фишки:
1) закодил 4 метода определения "затравочных" кандидатов, Random, Equidistant, Fibonacci, ReversedFibonacci. В какой-то мере это аналоги soblo/lhe и прочего из skopt.
2) есть возможность строить визуализацию поиска. видно, какие точки уже проверены, как к ним фиттится модель и какие даёт прогнозы, как рассчиталась перспективность каждого кандидата в зависимости от настроек, и какой кандидат в итоге выбран.
К результатам. В бенче я в основном смотрел на процент случаев, когда оптимизатор нашёл истинный максимум.
Для 20 итераций лидером была - optuna/tpe с 69%, для 50 - hyperopt/atpe с 81%. skopt этих показателей не смог превысить.
Показатели моего MBHO: 20 итераций - 70%, 50 итераций - 100%. По времени медленнее оптуны, но быстрее hyperopt/skopt. То есть моё решение победило 3 известные либы оптимизации в одномерном случае.
Да, можно возразить, что я заточил алгоритм под свои конкретные задачи, или вообще старался выставить оппонентов в невыгодном свете, но
1) старался возможности конкурентов исследовать по-полной
2) у них же тоже было тестирование на профильных задачах, им никто не мешал тоже тестироваться на одномерном случае
3) у моего алгоритма достаточно много параметров, и он как раз-таки остаётся недоисследованным. все вычисления я провёл навскидку с просто "разумными" значениями, наверняка можно натюнить лучшее время работы и точность.
Ну и моя основная мотивация, зачем я всё это начинал: в предварительном тестировании встроенные важности признаков бустингов себя хорошо показали, FS по таким важностям разумно делать только с RFECV, но в sklearn RFECV делает полный перебор (да и не работает с категориями), а на практике у меня десятки тысяч признаков и большие датасеты.
Получается, благодаря новому MBHO оптимизатору я смогу просчитывать лишь небольшой % от признаков и при этом находить глобально оптимальные сочетания.
В комментах картинки. Лучшим методом инициализации оказался эквидистантный (что в принципе логично, позволяет получить максимум информации). И что особенно интересно, наличие оценки неопределённости с помощью квантильной регрессии не супер важно - да, улучшает результат, но эвристика с расстояниями работает и сама по себе хорошо.
Реализация MBHO заняла ~700 строк кода, поддерживается максимизация и минимизация (в отличие от hyperopt, где надо извращаться с негацией функции). Правда, нет асинхронности и многопоточности.
#featureselection #selectfrommodel #rfe #rfecv #diogenes
Ч. 2
RFECV кажется самым продвинутым и эффективным алгоритмом отбора признаков в sklearn, что же мне в нём могло не понравиться?
1) итоговые best_n_features выбираются по всем данным и по итогам только 1 обучения модели (а именно, предыдущего с best_n_features+1 фичами).
а если я обучу модель ещё раз, точно будут отобраны те же фичи, или нет? подозреваю, что этот способ неустойчив.
2) информация о важности признаков от обученных моделек с уровней от best_n_features+1 может использоваться только косвенно, а с уровней ниже best_n_features-1 вообще никак.
А что, если бы мы могли все эти важности как-то комбинировать, ну хотя бы голосованием? (привет #votenrank)
3) все обучения моделей внутри RFE/RFECV не поддерживают раннюю остановку. все решения вы будете принимать по оверфитнутым моделям.
4) для задачи с 10_000 фичами всё ещё надо обучить 10_000 моделек. Допустим, у нас терабайтный датасет, и даже на мощном сервере обучение идёт несколько часов. Да, можно задать шаг в 200, и обучить 50 моделек за пару суток, но и придётся пожертвовать точностью в +- 200 полезных признаков. Как там говорит Хеттингер, THERE MUST BE A BETTER WAY! А нельзя ли, попробовав несколько вариантов n_features и глядя на получающийся график скоров, определять следующих кандидатов для проверки более интеллектуально? Это же задача одномерной глобальной оптимизации! см #MBHO
5) даже в случае допустимости по ресурсам шага=1 и полного перебора, признаки имеют свою стоимость: приобретения, создания, хранения в featurestore. + из-за случайностей в разбиении конкретных данных Вы на протяжении десятков и сотен избыточных (и даже совершенно нерелевантных) признаков будете видеть на графике неубывающую полезность, из которой RFECV возьмёт абсолютный максимум, тем самым завысив реально полезное число признаков. Хотелось бы ввести понятие средней стоимости 1 признака, и от непосредственного ML функционала отнимать (шкалированную) стоимость получившегося набора данных. Это создаст адекватный и чёткий глобальный экстремум полезности.
6) некоторые признаки реально могут быть крайне дорогими сами по себе, если их приходится приобретать. в этом случае нужно пытаться их заменить на более дешёвые, и сравнивать каждый раз выгоду от увеличения точности модели с затратами на приобретение признаков.
7) по ходу отбора признаков обучается много моделей, по идее, это даёт вал ценной информации, значительная часть которой (по старой традиции кудесников дата сайенс из sklearn) потом просто выбрасывается, несмотря на потраченные часы вычислений. Давайте не забывать, после FS мы наверняка захотим ещё затюнить гиперпараметры нашей основной модельки, и будем перебирать/переобучать ещё сотни комбинаций (причём на тех же данных, что были использованы для FS), что будет стоить нам дополнительных часов. Так а кто нам мешает задавать моделькам с шага FS разные значения гиперпараметров и тем самым выучить оптимальные ещё до этапа HPO/HPT?!
8) глупое техническое ограничение. sklearn вам не позволит использовать датасет с категориальными признаками (даже если модель их поддерживает).
Решение этих проблем и является моей мотивацией при создании модуля wrappers библиотеки отбора признаков Diogenes.
Есть у меня подозрение, что самым эффективным в итоге окажется гибрид MRMR и RFECV (+возможно, Branch & Bound), но это уже тема другого разговора.
Ч. 2
RFECV кажется самым продвинутым и эффективным алгоритмом отбора признаков в sklearn, что же мне в нём могло не понравиться?
1) итоговые best_n_features выбираются по всем данным и по итогам только 1 обучения модели (а именно, предыдущего с best_n_features+1 фичами).
а если я обучу модель ещё раз, точно будут отобраны те же фичи, или нет? подозреваю, что этот способ неустойчив.
2) информация о важности признаков от обученных моделек с уровней от best_n_features+1 может использоваться только косвенно, а с уровней ниже best_n_features-1 вообще никак.
А что, если бы мы могли все эти важности как-то комбинировать, ну хотя бы голосованием? (привет #votenrank)
3) все обучения моделей внутри RFE/RFECV не поддерживают раннюю остановку. все решения вы будете принимать по оверфитнутым моделям.
4) для задачи с 10_000 фичами всё ещё надо обучить 10_000 моделек. Допустим, у нас терабайтный датасет, и даже на мощном сервере обучение идёт несколько часов. Да, можно задать шаг в 200, и обучить 50 моделек за пару суток, но и придётся пожертвовать точностью в +- 200 полезных признаков. Как там говорит Хеттингер, THERE MUST BE A BETTER WAY! А нельзя ли, попробовав несколько вариантов n_features и глядя на получающийся график скоров, определять следующих кандидатов для проверки более интеллектуально? Это же задача одномерной глобальной оптимизации! см #MBHO
5) даже в случае допустимости по ресурсам шага=1 и полного перебора, признаки имеют свою стоимость: приобретения, создания, хранения в featurestore. + из-за случайностей в разбиении конкретных данных Вы на протяжении десятков и сотен избыточных (и даже совершенно нерелевантных) признаков будете видеть на графике неубывающую полезность, из которой RFECV возьмёт абсолютный максимум, тем самым завысив реально полезное число признаков. Хотелось бы ввести понятие средней стоимости 1 признака, и от непосредственного ML функционала отнимать (шкалированную) стоимость получившегося набора данных. Это создаст адекватный и чёткий глобальный экстремум полезности.
6) некоторые признаки реально могут быть крайне дорогими сами по себе, если их приходится приобретать. в этом случае нужно пытаться их заменить на более дешёвые, и сравнивать каждый раз выгоду от увеличения точности модели с затратами на приобретение признаков.
7) по ходу отбора признаков обучается много моделей, по идее, это даёт вал ценной информации, значительная часть которой (по старой традиции кудесников дата сайенс из sklearn) потом просто выбрасывается, несмотря на потраченные часы вычислений. Давайте не забывать, после FS мы наверняка захотим ещё затюнить гиперпараметры нашей основной модельки, и будем перебирать/переобучать ещё сотни комбинаций (причём на тех же данных, что были использованы для FS), что будет стоить нам дополнительных часов. Так а кто нам мешает задавать моделькам с шага FS разные значения гиперпараметров и тем самым выучить оптимальные ещё до этапа HPO/HPT?!
8) глупое техническое ограничение. sklearn вам не позволит использовать датасет с категориальными признаками (даже если модель их поддерживает).
Решение этих проблем и является моей мотивацией при создании модуля wrappers библиотеки отбора признаков Diogenes.
Есть у меня подозрение, что самым эффективным в итоге окажется гибрид MRMR и RFECV (+возможно, Branch & Bound), но это уже тема другого разговора.
#news #hpt #hpo #mbho #transferlearning #pmbho
Начинаю работу над одним из самых амбициозных своих ML проектов - оптимизатором гиперпараметров, основанном на моделях (PMBHO, Persistent Model Based Heuristic Optimizer).
Это следующий шаг в цепочке GridSearch->RandomSearch->HalvingRandomSearch->BayesianSearch.
BayesianSearch используется в оптимизаторах вроде optuna и hyperopt, которые вроде как считаются сейчас state of the art. На самом деле от Байесовского подхода там немного, по сути это скорее оптимизация "одноруких бандитов" поверх простенькой суррогатной модели, как правило, ГП - гауссова процесса (т.к. он позволяет учитывать неопределённость).
Недостатки BayesianSearch:
1) ГП откровенно слабоват как модель, часто бывает трудно подобрать подходящее ядро
2) не всё гладко с категорийками
3) никак не учитывается природа и структура данных - признаков и таргета
4) никак не учитываются знания, полученные при работе с другими датасетами
5) это уже недостаток конкретных реализаций - современные библиотеки подбора гиперпараметров обычно ни хрена не знают, какие собственно гиперпараметры есть у каких классов моделей. обычно юзеры сами задают поисковые пространства для 5-10 HP (при том что у современных бустингов их десятки)
6) библиотеки никак не отрабатывают конфликты гиперпараметров - юзерам предлагается разруливать всё вручную, из-за чего все и забивают на большинство HP и ограничиваются 5-6 самыми неконфликтными.
7) почти все известные мне оптимизаторы за оптимальный набор HP считают ту единственную точку в пространстве поиска, что достигает экстремума по нужной ML-метрике на CV. При этом никак не учитывается устойчивость в близких областях, что приводит к катастрофам на OOS (Out-of-Sample).
В результате десятки тысяч дата-сайентистов по всему миру для каждого нового проекта молотят сотни тысяч комбинаций гиперпараметров "каждый раз как в первый раз". There... There must be a better way! )
Гипотеза: есть мнение, что по некоторым базовым статистикам признаков и таргета (и их связей) уже можно определить перспективные наборы гиперпараметров.
А обучив несколько неглубоких моделек с фиксированными HP (назовём их "золотой стандарт") и изучив производные от их атрибутов (важностей признаков, кривых обучения и валидации по набору ML метрик), можно существенно повысить точность рекомендаций практически в реальном времени.
Решение: свой оптимизатор, основанный на принципе exploration-exploitation и на ранжировании кандидатов с помощью мета-модели, натренированной на разных датасетах и богатом наборе мета-данных. Периодически по мере проверки кандидатов на конкретной задаче можно основную модель подстраивать/файнтюнить (брать основной датасет с обычными весами+подмешивать актуальный датасет с большими весами). Оптимизатор интеллектуальный и будет учитывать значения и гладкость МЛ-метрик в ближайших окрестностях точек-кандидатов, знать, какие гиперпараметры есть у конкретного класса моделей и иметь таблицы конфликтов (например, будет знать, какие гиперпараметры недоступны на GPU).
В теории такой оптимизатор может быть эффективнее решений типа оптуны в разы. А может и не быть. При этом подход требует проведения огромного количества вычислений и экспериментов при подготовке мета-датасета, не говоря уже о программерской работе. Но, считаю, цель стоит усилий и риска.
Напомню, что у меня уже есть одномерный MBHO оптимизатор (сделанный для задачи #featureselection), и по результатам тестов мне удалось побить и оптуну, и гиперотпт, и эскаопт.
На самом деле, моя цель еще более амбициозная - в идеале я бы хотел для заданного датасета (сырые признаки+таргет+МЛ задача) быстро определять не только оптимальные классы МЛ моделей и их гиперпараметры, но и оптимальный препроцессинг (нейлинейные преобразования, PolynomialFeatures, сплайны, обработка категориальных входов, ядра, шкалирование, понижение размерности ) и трансформацию таргета (для задач регрессии). Пока неясно, можно ли эти 2 задачи эффективно увязать вместе.
Временные ряды в этой постановке - отдельная боль.
Как всегда, буду рад советам и конструктивной критике.
Начинаю работу над одним из самых амбициозных своих ML проектов - оптимизатором гиперпараметров, основанном на моделях (PMBHO, Persistent Model Based Heuristic Optimizer).
Это следующий шаг в цепочке GridSearch->RandomSearch->HalvingRandomSearch->BayesianSearch.
BayesianSearch используется в оптимизаторах вроде optuna и hyperopt, которые вроде как считаются сейчас state of the art. На самом деле от Байесовского подхода там немного, по сути это скорее оптимизация "одноруких бандитов" поверх простенькой суррогатной модели, как правило, ГП - гауссова процесса (т.к. он позволяет учитывать неопределённость).
Недостатки BayesianSearch:
1) ГП откровенно слабоват как модель, часто бывает трудно подобрать подходящее ядро
2) не всё гладко с категорийками
3) никак не учитывается природа и структура данных - признаков и таргета
4) никак не учитываются знания, полученные при работе с другими датасетами
5) это уже недостаток конкретных реализаций - современные библиотеки подбора гиперпараметров обычно ни хрена не знают, какие собственно гиперпараметры есть у каких классов моделей. обычно юзеры сами задают поисковые пространства для 5-10 HP (при том что у современных бустингов их десятки)
6) библиотеки никак не отрабатывают конфликты гиперпараметров - юзерам предлагается разруливать всё вручную, из-за чего все и забивают на большинство HP и ограничиваются 5-6 самыми неконфликтными.
7) почти все известные мне оптимизаторы за оптимальный набор HP считают ту единственную точку в пространстве поиска, что достигает экстремума по нужной ML-метрике на CV. При этом никак не учитывается устойчивость в близких областях, что приводит к катастрофам на OOS (Out-of-Sample).
В результате десятки тысяч дата-сайентистов по всему миру для каждого нового проекта молотят сотни тысяч комбинаций гиперпараметров "каждый раз как в первый раз". There... There must be a better way! )
Гипотеза: есть мнение, что по некоторым базовым статистикам признаков и таргета (и их связей) уже можно определить перспективные наборы гиперпараметров.
А обучив несколько неглубоких моделек с фиксированными HP (назовём их "золотой стандарт") и изучив производные от их атрибутов (важностей признаков, кривых обучения и валидации по набору ML метрик), можно существенно повысить точность рекомендаций практически в реальном времени.
Решение: свой оптимизатор, основанный на принципе exploration-exploitation и на ранжировании кандидатов с помощью мета-модели, натренированной на разных датасетах и богатом наборе мета-данных. Периодически по мере проверки кандидатов на конкретной задаче можно основную модель подстраивать/файнтюнить (брать основной датасет с обычными весами+подмешивать актуальный датасет с большими весами). Оптимизатор интеллектуальный и будет учитывать значения и гладкость МЛ-метрик в ближайших окрестностях точек-кандидатов, знать, какие гиперпараметры есть у конкретного класса моделей и иметь таблицы конфликтов (например, будет знать, какие гиперпараметры недоступны на GPU).
В теории такой оптимизатор может быть эффективнее решений типа оптуны в разы. А может и не быть. При этом подход требует проведения огромного количества вычислений и экспериментов при подготовке мета-датасета, не говоря уже о программерской работе. Но, считаю, цель стоит усилий и риска.
Напомню, что у меня уже есть одномерный MBHO оптимизатор (сделанный для задачи #featureselection), и по результатам тестов мне удалось побить и оптуну, и гиперотпт, и эскаопт.
На самом деле, моя цель еще более амбициозная - в идеале я бы хотел для заданного датасета (сырые признаки+таргет+МЛ задача) быстро определять не только оптимальные классы МЛ моделей и их гиперпараметры, но и оптимальный препроцессинг (нейлинейные преобразования, PolynomialFeatures, сплайны, обработка категориальных входов, ядра, шкалирование, понижение размерности ) и трансформацию таргета (для задач регрессии). Пока неясно, можно ли эти 2 задачи эффективно увязать вместе.
Временные ряды в этой постановке - отдельная боль.
Как всегда, буду рад советам и конструктивной критике.