#hpt #optuna #codegems

Добавляю в сравнение по текущей задаче FS современные библиотеки оптимизации, в частности, очень популярная ныне (как б даже не лидер?) Optuna. Дабы освежить память, заглянул в доку. Привлёк внимание рецепт от создателей Оптуны, как бороться с дублированными кандидатами, которых иногда выдаёт Оптуна же. Ну это просто жопа, господа.

#optuna #hpt

Но зато у них есть ржачное классное промо )

https://youtu.be/-UeC4MR3PHM

#optuna #dask #optimization #global

Разные способы заюзать Даск из Оптуны.

https://www.youtube.com/watch?v=euT6_h7iIBA

#skopt #optuna #global #optimization

Неожиданно срезонировала библиотечка skopt. Я уже начал писать свой интерфейс оптимизитора, и сразу добавил туда вещи, которых мне очень не хватало в Оптуне: возможность указать "затравочные" входы, ответы на которые надо вычислить обязательно, разные виды начального сэмплирования (не только случайное, а ещё и фибо, обратное фибо для одномерого случая). Всё это кажется таким естественным, но я уже привык, что программисты по всему миру всегда думают иначе, чем я. И тут с большим удивлением увидел, что авторы skopt рассуждали в точности в том же направлении:

The total number of evaluations, n_calls, are performed like the following. If x0 is provided but not y0, then the elements of x0 are first evaluated, followed by n_initial_points evaluations. Finally, n_calls - len(x0) - n_initial_points evaluations are made guided by the surrogate model. If x0 and y0 are both provided then n_initial_points evaluations are first made then n_calls - n_initial_points subsequent evaluations are made guided by the surrogate model.

initial_point_generatorstr, InitialPointGenerator instance, default: ‘random’
Sets a initial points generator. Can be either

"random" for uniform random numbers,
"sobol" for a Sobol sequence,
"halton" for a Halton sequence,
"hammersly" for a Hammersly sequence,
"lhs" for a latin hypercube sequence

Интересно будет увидеть её в сравнении. Ещё из интересных находок авторов: по умолчанию у них acquisition function не просто одна из известных EI, PI UCB/LCB, а т.н. gp_hedge, которая на каждом шаге сэмплит одну из указанных, по идее предлагая лучшее из 3 миров )

#featureselection #hpo #hpt #global #optimization #optuna #scipy

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

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

Общий сетап: есть 8 кривых зависимости CV метрики качества от nfeatures: выдуманные, синтетические по связям, синтетические по данным и связям, с шумом (как есть) и сглаженные. Количество фичей там посчитано от 150 до 570.

Замеряю вкупе по всем 8 задачам (в среднем):
1) найденный максимум на истинный максимум
2) среднее по верхнему 25% перцентилю найденных значений на истинный максимум
3) факт нахождения истинного максимум
4) итерацию нахождения истинного максимум к общему числу попыток
5) время поиска

С Оптуной уже есть интересные результаты. Почти всё богатство настроек там в т.н. сэмплерах, я насчитал 7, от случайного до генетиков и парценовского. У некоторых настроек просто тонна. Так как большинство сэмплеров в сравнении будут model-based (smbo), у них (в Оптуне) есть параметр n_startup_trials, т.е., сколько брать случайных точек для инициализации модели. Тут интуитивно не хочется отдавать случаю слишком много ценных попыток, кажется, пусть уж лучше ищет с умом.

Для 100 повторов с n_trials 50 (n_trials - это разрешённое число оценок целевой функции) выяснилось, к примеру, что уменьшение n_startup_trials с 10 до 5 увеличивает долю нахождения истинного максимума с 66.7% до 68%. А вот дальнейшее снижение до n_startup_trials=2 уже снижает долю до 66.87%. А ведь у оптуны этот параметр по дефолту 10! Так что не полагайтесь на дефолты, тестируйте.

Ясно, что 100 повторов для каждого конфига мало, надо тысяч 10 минимум, а лучше 100. Но даже для 1 парценовского сэмплера кол-во комбинаций конфигов под сотню. Придётся, видно, писать распредёлённый бенч под Dask (

А, и уже видно, что TPE сэмплер заруливает случайный: доля найденных истинных максимумов составляет 68% против 18%. Цена принятия решения вполне оправдана: вместо 0.01 секунды тратится 0.28, что несущественно по сравнению с переобучением даже одной терабайтной модели.

UPD. С дефолтными параметрами все сэмплеры Оптуны, кроме TPE, на моем тесте не могут обогнать RandomSampler, поэтому их тонкие настройки тестить даже не буду.

#featureselection #hpo #hpt #global #optimization #optuna

Ну вот, уже не зря делал исследование. Не все настройки парценовского сэмплера Оптуны одинаково полезны. Выходит, в задаче FS хитрейт можно легко поднять с 68% до 76%!

#hpt #hpo #optuna

Было смешно. Чувак применил HPT и получил на OOS хуже )

https://www.youtube.com/watch?v=t-INgABWULw

#hpt #hpo #optuna

Но, кстати, ситуация жизненная. Что делать-то, если test set недоступен, и возможностей проверить train/test skew нет, к примеру, это соревнование? Потратил такой кучу ресурсов, заоптимизировался на train/public. Вроде приложил усилия, сделал HPT, и на тебе, сюрприз. Хочу на этом тестовом примере изучить, что было бы, если за лучший сет брать не просто аргмакс от сырой метрики, а аргмакс от метрики, усреднённой по n ближайшим соседям.

#optuna

Глубоко в недрах доки Оптуны, и почти случайно, я обнаружил, что у неё всё-такие есть нормальный интерфейс и можно у неё попросить все параметры сразу. Называется это define-and-run. Также, оказывается, не обязательно заворачивать всё в objective, можно использовать ask/tell чтобы гибко интегрировать её в существующие системы.

https://optuna.readthedocs.io/en/stable/tutorial/20_recipes/009_ask_and_tell.html#ask-and-tell

#hpt #hpo #optuna

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

Кстати, удивляет, что если в документации используется небрежный или неэффективный код, всё равно при демонстрациях, да и в практическом использовании подобную ересь все как попки копируют. В случае оптуны подобным кодом является загрузка и сплит датасета внутри objective. На кой эти дорогие задачи делать снова и снова на КАЖДОЙ итерации? И главное, человек при этом замеряет время исполнения... И нигде у него не ёкает.

Хах, а как он тестирует прунинг? Походу, совершенно не понимает, что это и как оно работает, там же должен быть partial_fit. И опять же, время выполнения у него с "прунингом" такое же, как и без, почему, вопросов у него не возникает даже. Доклад сделал, нормалёк, чё вам ещё надо?

https://www.youtube.com/watch?v=hboCNMhUb4g

#hpt #optuna #pytorch #nas

https://youtu.be/P6NwZVl8ttc?si=cvBi9mA-EnNPyG5n

#news #automl #plans

ML/DS-планы на 2024-й.

Как-то незаметно прошло уже почти полгода! Поймал себя на том, что двигаюсь к своей мини-automl системе. Скажете, почему не возьмёшь готовую? Ответ обычный, хочешь чтоб было сделано хорошо - сделай сам (если у тебя есть экспертиза и классные идеи).

В рамках этой automl системы будут:

1) 2 отборщика признаков из Diogenes, MRMR и RFECV.
MRMR уже получил навык создания комбинаций признаков (feature engineering), его надо ускорить (запараллелить) и лучше потестировать подмодуль с ортогональными полиномами (там будет полезен хороший оптимизатор, сейчас стоит оптуна и работает через пень-колоду)

2) мой будущий классный MBHO оптимизатор HPT. мне уже удалось побить оптуну, гиперопт, скопт в задачах одномерной оптимизации (для решения проблемы feature selection, см бенчи по тегам #featureselection #hpt #optuna #hyperopt #skopt), пора его расширить на многомерный случай

3) модуль ансамблирования ENS. будет простое усреднение (много оттенков) и стэкинг. из ноу-хау тут будут instance-based confidence, numaggs over level 0 predictions, identity level 1 baseline, аугментация табличных данных. Для расширения ENS планируется написать универсальную обёртку для ранней остановки. С этой идеей ношусь уже несколько лет, да никак не сделаю. Смысл обёртки в том, чтобы дать функционал early stopping/overfitting detection тем моделькам, которые сами нативно его не поддерживают - путём partial_fit или дихотомического поиска по n_iterations.

Отборщики признаков получат апгрейд и во время своей работы будут собирать ценную информацию для модулей HPT (MRMR считает базовые статистики признаков, силу связей с таргетами и между собой; RFECV создаёт пары гиперпараметры-ml метрики для последующего обучения MBHO) и ENS (будут замерять, насколько прогнозы моделек с определёнными признаками и гиперпараметрами декоррелированы и спосбны помочь ансамблю).

Также планируется большое обновление Diogenes, после которого избыточные признаки опционально будут не удаляться из набора, а сливаться в единый "кластер" c primary (если это будет повышать стабильность). Идея взята из лекций Эрни Чана. Это может быть полезно, когда 1 скрытый драйвер влияет на множество факторов в датасете. Текущая реализация MRMR выбирает 1 фактор с самой сильной MI на таргет, остальные выкидывает, что приводит к потере информации если влияние драйвера на факторы неоднородно по инстансам или времени.

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

Хочу также изучить гибриды между MRMR и RFECV (например, все признаки отброшенные MRMR прогонять через RFECV).