#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
Ч. 1
Как работают embedded, filters и wrappers подходы к отбору признаков, что лучше использовать в бою, и почему sklearn-овская реализация RFECV недостаточно хороша?
embedded (встроенные) делают отбор признаков частью процесса обучения модели (к примеру, используя специализированные функции потерь). К примеру, L-1 регуляризация в Lasso и ElasticNet регресиях способна занулять коэффициент при факторах и тем самым полностью исключать их из работы.
плюсы: удобство, не надо создавать отдельный FS компонент, органичная интеграция в основной алгоритм. минусы: мало моделей с поддержкой embedded.
wrappers (обёртки) для оценки подмножеств факторов применяет отдельную предсказательную модель и внешний критерий. Критерием могут быть как непосредственно ML метрики(обычно на отложенной выборке), так и относительные важности признаков.
плюсы: позволяет оценивать большие подмножества/группы факторов; универсальность, работает со всеми базовыми моделями. минусы: большое время работы, пропорциональное количеству факторов.
filters (фильтры) вместо дорогой в обучении предсказательной модели используют более простую вычислительно оценку наличия связи между фактором (или небольшой группой факторов) и таргетом. Это может быть коэффициент линейной корреляция или взаимной информации. Фильтры могут быть простейшие, независимые по 1 переменной, или более сложные, по нескольким и даже с учётом внутренней избыточности (см #MRMR). Иногда рассматривается просто информационное содержание (энтропия) фактора, без связи с таргетом.
плюсы: быстрый; универсальный. минусы: проблемы с одновременным учётом больше 2-3 факторов.
Для полноты картины, есть ещё полный перебор подмножеств признаков, но в современных реалиях это скорее академическое упражнение, разве что у Вас в какой-то специфической задаче датасет и правда содержит не больше 5-6 факторов.
На текущий момент, по моему скромному опыту, для задач с большим (сотни,тысячи, ++) кол-вом признаков предпочтительным решением кажутся обёрточные (wrappers) методы с привлечением информации о важности признаков. Последняя зачастую довольно точна и полезна, может учитывать нелинейности и внутренние связи (особенно в современных бустингах), и позволяет заменить крайне дорогостоящий полный перебор/дообучение простым ранжированием важностей.
Давайте рассмотрим (в порядке роста изощрённости) обёрточные алгоритмы FS, использующий важности признаков.
SelectFromModel(estimator,n_features_to_select) обучает модель лишь 1 раз, и за один шаг сразу отбрасывает все низкорейтинговые признаки, чтобы оставить только нужное пользователю число фичей.
RFE(estimator,n_features_to_select) (Recursive Feature Elimination) можно рассматривать как улучшение SelectFromModel: RFE сделает то же самое, но не за 1 ход, а постепенно, итеративно отбрасывая по N самых слабых признаков и переобучая модель, чтобы использовать дальше уже новые важности признаков. Идея в том, что удаление признаков может вести к тому, что относительные важности оставшихся достаточно сильно изменятся, и RFE как раз сможет эти перетасовки учесть.
У обоих алгоритмов есть недостаток: пользователю нужно знать заранее, какое число признаков оставить, а ему это знать обычно неоткуда.
RFECV (RFE with Cross-Validation) решает эту проблему: вместо строгого n_features_to_select, у него есть параметр min_features_to_select. Входные данные RFECV разбивает на несколько train/test фолдов, и для каждого train фолда в отдельности просто запускает старого добого RFE(n_features_to_select=min_features_to_select). RFE всё так же проходится по числу оставленных признаков сверху вниз, но теперь дополнительно каждый набор признаков скорится на тестовом фолде.
По итогу, best_n_features с лучшим средним скором по всем тестовым фолдам и возвращается как ответ, а конкретные признаки выбираются финальным запуском RFE(n_features_to_select=best_n_features) уже на полном входном датасете.
Ч. 1
Как работают embedded, filters и wrappers подходы к отбору признаков, что лучше использовать в бою, и почему sklearn-овская реализация RFECV недостаточно хороша?
embedded (встроенные) делают отбор признаков частью процесса обучения модели (к примеру, используя специализированные функции потерь). К примеру, L-1 регуляризация в Lasso и ElasticNet регресиях способна занулять коэффициент при факторах и тем самым полностью исключать их из работы.
плюсы: удобство, не надо создавать отдельный FS компонент, органичная интеграция в основной алгоритм. минусы: мало моделей с поддержкой embedded.
wrappers (обёртки) для оценки подмножеств факторов применяет отдельную предсказательную модель и внешний критерий. Критерием могут быть как непосредственно ML метрики(обычно на отложенной выборке), так и относительные важности признаков.
плюсы: позволяет оценивать большие подмножества/группы факторов; универсальность, работает со всеми базовыми моделями. минусы: большое время работы, пропорциональное количеству факторов.
filters (фильтры) вместо дорогой в обучении предсказательной модели используют более простую вычислительно оценку наличия связи между фактором (или небольшой группой факторов) и таргетом. Это может быть коэффициент линейной корреляция или взаимной информации. Фильтры могут быть простейшие, независимые по 1 переменной, или более сложные, по нескольким и даже с учётом внутренней избыточности (см #MRMR). Иногда рассматривается просто информационное содержание (энтропия) фактора, без связи с таргетом.
плюсы: быстрый; универсальный. минусы: проблемы с одновременным учётом больше 2-3 факторов.
Для полноты картины, есть ещё полный перебор подмножеств признаков, но в современных реалиях это скорее академическое упражнение, разве что у Вас в какой-то специфической задаче датасет и правда содержит не больше 5-6 факторов.
На текущий момент, по моему скромному опыту, для задач с большим (сотни,тысячи, ++) кол-вом признаков предпочтительным решением кажутся обёрточные (wrappers) методы с привлечением информации о важности признаков. Последняя зачастую довольно точна и полезна, может учитывать нелинейности и внутренние связи (особенно в современных бустингах), и позволяет заменить крайне дорогостоящий полный перебор/дообучение простым ранжированием важностей.
Давайте рассмотрим (в порядке роста изощрённости) обёрточные алгоритмы FS, использующий важности признаков.
SelectFromModel(estimator,n_features_to_select) обучает модель лишь 1 раз, и за один шаг сразу отбрасывает все низкорейтинговые признаки, чтобы оставить только нужное пользователю число фичей.
RFE(estimator,n_features_to_select) (Recursive Feature Elimination) можно рассматривать как улучшение SelectFromModel: RFE сделает то же самое, но не за 1 ход, а постепенно, итеративно отбрасывая по N самых слабых признаков и переобучая модель, чтобы использовать дальше уже новые важности признаков. Идея в том, что удаление признаков может вести к тому, что относительные важности оставшихся достаточно сильно изменятся, и RFE как раз сможет эти перетасовки учесть.
У обоих алгоритмов есть недостаток: пользователю нужно знать заранее, какое число признаков оставить, а ему это знать обычно неоткуда.
RFECV (RFE with Cross-Validation) решает эту проблему: вместо строгого n_features_to_select, у него есть параметр min_features_to_select. Входные данные RFECV разбивает на несколько train/test фолдов, и для каждого train фолда в отдельности просто запускает старого добого RFE(n_features_to_select=min_features_to_select). RFE всё так же проходится по числу оставленных признаков сверху вниз, но теперь дополнительно каждый набор признаков скорится на тестовом фолде.
По итогу, best_n_features с лучшим средним скором по всем тестовым фолдам и возвращается как ответ, а конкретные признаки выбираются финальным запуском RFE(n_features_to_select=best_n_features) уже на полном входном датасете.
#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), но это уже тема другого разговора.
#featureselection #diogenes
Тестирую сейчас Диогена в контролируемом эксперименте. Несмотря на ожидания, RFECV звёзд с неба не хватает: некоторые значимые группы факторов "уплывают" из зоны видимости, без шансов выйти в топ. Думаю про альтернативу, ну или как минимум предварительный шаг: просчитывать важности признаков на случайных подгруппах случайных размеров, а не просто на всех доступных одним разом.
UPD. Кстати, эксперименты на подгруппах открыли интересный факт: важности признаков катбуста могут совершенно не отражать реальный вклад факторов в результат. Пример в комментах.
Тестирую сейчас Диогена в контролируемом эксперименте. Несмотря на ожидания, RFECV звёзд с неба не хватает: некоторые значимые группы факторов "уплывают" из зоны видимости, без шансов выйти в топ. Думаю про альтернативу, ну или как минимум предварительный шаг: просчитывать важности признаков на случайных подгруппах случайных размеров, а не просто на всех доступных одним разом.
UPD. Кстати, эксперименты на подгруппах открыли интересный факт: важности признаков катбуста могут совершенно не отражать реальный вклад факторов в результат. Пример в комментах.
#featureselection
Недавно я проводил опрос, нужен ли вообще отбор признаков, если есть современные мощные бустинги. Большая часть аудитории сказала, что нет, и этим не занимается.
Вот вам пример: 246 фичей, из них на таргет влияют 11. Результаты (mean_cv_score, std_cv_score) MSE с 5-фолдовой кросс-валидацией для всех фичей и только для важных фичей показывают ОГРОМНУЮ разницу (0.0219 vs 0.0145, при dummy=0.0278). По сути, наличие/отсутствие FS может быть причиной успеха/провала проекта. Порядок разницы одинаковый для Catboost и Xgboost, кстати.
Недавно я проводил опрос, нужен ли вообще отбор признаков, если есть современные мощные бустинги. Большая часть аудитории сказала, что нет, и этим не занимается.
Вот вам пример: 246 фичей, из них на таргет влияют 11. Результаты (mean_cv_score, std_cv_score) MSE с 5-фолдовой кросс-валидацией для всех фичей и только для важных фичей показывают ОГРОМНУЮ разницу (0.0219 vs 0.0145, при dummy=0.0278). По сути, наличие/отсутствие FS может быть причиной успеха/провала проекта. Порядок разницы одинаковый для Catboost и Xgboost, кстати.
#diogenes #featureselection #rfecv #mrmr
Ну и немного новостей по проекту Диоген. Собрал и потестировал на синтетике 2 полноценных отборщика признаков, filter & wrapper. мой улучшенный RFECV отлично отработал на датасете с 250+ факторами, 11k записями: из 11 значимых факторов нашёл 9, причём и нелинейные, и 2-way XOR, и 3-way XOR. Не смог найти 2 фактора с частичной зависимостью (на 10% и 30% области определения). Ну я не сильно расстроился, найди он и это на 11k записей, это было бы чудом. При росте числа записей находит и их. Что выяснилось: промежуточные модельки надо фиттить прям до упора (насколько ES позволяет).
И, кажется, оправдалась моя идея, что важности признаков надо складировать со всех запусков, а не только с самого первого. Оптимизатор мой MBHO отлично отработал - сократил время поиска вдвое. В общем, не зря пилил этот проект полгода.
В то же время, MRMR находит только 6 важных признаков из 11. Но время работы, Карл! 2 часа RFECV против 2 минут MRMR.
Мне уже стало казаться, что в бою на больших данных RFECV ну просто будет неприменим по времени. Начал тестировать на реальном датасете с 500+ столбцов общим размером 50Гб. Подождал часов 6 на сервере с 16 ядрами, за это время не обучилась полностью даже 1я FS моделька, махнул рукой. Придётся переносить тесты RFECV на GPU сервер с приличным объёмом VRAM.
Перешёл к тестированию MRMR. Тут тоже в реальности не всё гладко оказалось, биннинг датасета, который на небольшой синтетике шёл 2 секунды на 1 ядре, в реальном проекте растянулся на полчаса. Пришлось переписывать под многопоток, заодно улучшил работу с пропусками и отловил пару багов. Биннинг стал отрабатывать за 2 минуты. И снова сюрприз, который отнял полдня. Оказалось, что np.random.shuffle в многопотоке ужасно тормозит, пришлось оборачивать его в njit.
В итоге тестирую MRMR с полной загрузкой CPU на финансовом проекте, очень интересно смотреть в реальном времени, что он находит.
Ну и немного новостей по проекту Диоген. Собрал и потестировал на синтетике 2 полноценных отборщика признаков, filter & wrapper. мой улучшенный RFECV отлично отработал на датасете с 250+ факторами, 11k записями: из 11 значимых факторов нашёл 9, причём и нелинейные, и 2-way XOR, и 3-way XOR. Не смог найти 2 фактора с частичной зависимостью (на 10% и 30% области определения). Ну я не сильно расстроился, найди он и это на 11k записей, это было бы чудом. При росте числа записей находит и их. Что выяснилось: промежуточные модельки надо фиттить прям до упора (насколько ES позволяет).
И, кажется, оправдалась моя идея, что важности признаков надо складировать со всех запусков, а не только с самого первого. Оптимизатор мой MBHO отлично отработал - сократил время поиска вдвое. В общем, не зря пилил этот проект полгода.
В то же время, MRMR находит только 6 важных признаков из 11. Но время работы, Карл! 2 часа RFECV против 2 минут MRMR.
Мне уже стало казаться, что в бою на больших данных RFECV ну просто будет неприменим по времени. Начал тестировать на реальном датасете с 500+ столбцов общим размером 50Гб. Подождал часов 6 на сервере с 16 ядрами, за это время не обучилась полностью даже 1я FS моделька, махнул рукой. Придётся переносить тесты RFECV на GPU сервер с приличным объёмом VRAM.
Перешёл к тестированию MRMR. Тут тоже в реальности не всё гладко оказалось, биннинг датасета, который на небольшой синтетике шёл 2 секунды на 1 ядре, в реальном проекте растянулся на полчаса. Пришлось переписывать под многопоток, заодно улучшил работу с пропусками и отловил пару багов. Биннинг стал отрабатывать за 2 минуты. И снова сюрприз, который отнял полдня. Оказалось, что np.random.shuffle в многопотоке ужасно тормозит, пришлось оборачивать его в njit.
В итоге тестирую MRMR с полной загрузкой CPU на финансовом проекте, очень интересно смотреть в реальном времени, что он находит.
#autofeat #featureselection #featureselection
Как работает autofeat:
1) берётся подвыборка train set, из сырых фичей генерируется много кандидатов (с помощью простых математических операций)
2) в пул "хороших" добавляются кандидаты с высокой корреляцией с необъяснённым таргетом
3) на всех "хороших" кандидатах обучается линейная модель с регуляризацией LassoLarsCV. Отбрасываются кандидаты с низкими весами в последней модели. Пересчитывается таргет, не объясняемый моделью.
4) повтор цикла до стабилизации множества хороших кандидатов
5) отсев шума. обучение на итоговом пуле+случайных признаках, отбрасываем всех кандидатов с весами, меньшими весов шумовых фичей
Как работает autofeat:
1) берётся подвыборка train set, из сырых фичей генерируется много кандидатов (с помощью простых математических операций)
2) в пул "хороших" добавляются кандидаты с высокой корреляцией с необъяснённым таргетом
3) на всех "хороших" кандидатах обучается линейная модель с регуляризацией LassoLarsCV. Отбрасываются кандидаты с низкими весами в последней модели. Пересчитывается таргет, не объясняемый моделью.
4) повтор цикла до стабилизации множества хороших кандидатов
5) отсев шума. обучение на итоговом пуле+случайных признаках, отбрасываем всех кандидатов с весами, меньшими весов шумовых фичей
#featureselection #diogenes
Задумался о модификации MRMR в свете коррелированных признаков.
Сейчас Диоген избыточные признаки просто отсеивает. Но представим себе такую ситуацию: истинный влияющий фактор вне выборки, до нас дошли только несколько его "отражений" A,B, C... каждое со своим случайным шумом. По факту, мы сейчас выбираем одно самое похожее отражение D, а остальные выкидываем. А это же нерационально. Не лучше ли брать вместо D, к примеру, mean(A,B,C,...)? Идея в том, что случайные шумы отменяют друг друга, а сигнал усиливается (как и обычно при ансамблировании).
О подходе к FS, когда несколько коррелированных факторов заменяются кластером, рассказывал Эрни Чан. Правда, почему-то этого не было в его статье.
В общем, буду делать. Как минимум будет нелишней такая опция.
Задумался о модификации MRMR в свете коррелированных признаков.
Сейчас Диоген избыточные признаки просто отсеивает. Но представим себе такую ситуацию: истинный влияющий фактор вне выборки, до нас дошли только несколько его "отражений" A,B, C... каждое со своим случайным шумом. По факту, мы сейчас выбираем одно самое похожее отражение D, а остальные выкидываем. А это же нерационально. Не лучше ли брать вместо D, к примеру, mean(A,B,C,...)? Идея в том, что случайные шумы отменяют друг друга, а сигнал усиливается (как и обычно при ансамблировании).
О подходе к FS, когда несколько коррелированных факторов заменяются кластером, рассказывал Эрни Чан. Правда, почему-то этого не было в его статье.
В общем, буду делать. Как минимум будет нелишней такая опция.
#featureselection #diogenes
в модуле filters Диогена уже 3k строчек кода. хотя вроде идеи основные такие простые и элегантные.
в модуле filters Диогена уже 3k строчек кода. хотя вроде идеи основные такие простые и элегантные.
#featureengineering #featureselection #diogenes
2024-03-02 05:39:17,484 - INFO - screen_predictors-line:1524 - Starting work with full_npermutations=10, min_nonzero_confidence=0.99000, max_failed=1
2024-03-02 05:39:49,214 - INFO - fit-line:2750 - MRMR selected 4 out of 5 features: [{'name': 'a', 'indices': (0,), 'gain': 0.33220730396336595, 'confidence': 1.0}, {'name': 'b', 'indices': (1,), 'gain': 0.5405325314273686, 'confidence': 1.0}, {'name': 'c', 'indices': (2,), 'gain': 0.20641517193369197, 'confidence': 1.0}, {'name': 'd', 'indices': (3,), 'gain': 0.07414164383695354, 'confidence': 1.0}]
2024-03-02 05:40:34,762 - INFO - fit-line:2983 - mul(log(c),sin(d)) is recommended to use as a new feature!
2024-03-02 05:42:12,619 - INFO - fit-line:2983 - mul(squared(a),reciproc(b)) is recommended to use as a new feature!
time: 3min 7s (started: 2024-03-02 05:39:05 +03:00)
Как тебе такое, Франциска Хорн? )
n =100_000
a = np.random.rand(n)
b = np.random.rand(n)
c = np.random.rand(n)
d = np.random.rand(n)
e = np.random.rand(n)
f = np.random.rand(n)
y=a**2/b+f/5+np.log(c)*np.sin(d)
df = pd.DataFrame(
{
"a": a,
"b": b,
"c": c,
"d": d,
"e": e,
}
)
from mlframe.feature_selection.filters import MRMR
fs=MRMR(full_npermutations=10,baseline_npermutations=20,verbose=1,n_workers=1,parallel_kwargs=dict(temp_folder=r"R:\Temp"),)
fs.fit(X=df,y=y)
2024-03-02 05:39:17,484 - INFO - screen_predictors-line:1524 - Starting work with full_npermutations=10, min_nonzero_confidence=0.99000, max_failed=1
2024-03-02 05:39:49,214 - INFO - fit-line:2750 - MRMR selected 4 out of 5 features: [{'name': 'a', 'indices': (0,), 'gain': 0.33220730396336595, 'confidence': 1.0}, {'name': 'b', 'indices': (1,), 'gain': 0.5405325314273686, 'confidence': 1.0}, {'name': 'c', 'indices': (2,), 'gain': 0.20641517193369197, 'confidence': 1.0}, {'name': 'd', 'indices': (3,), 'gain': 0.07414164383695354, 'confidence': 1.0}]
2024-03-02 05:40:34,762 - INFO - fit-line:2983 - mul(log(c),sin(d)) is recommended to use as a new feature!
2024-03-02 05:42:12,619 - INFO - fit-line:2983 - mul(squared(a),reciproc(b)) is recommended to use as a new feature!
time: 3min 7s (started: 2024-03-02 05:39:05 +03:00)
Как тебе такое, Франциска Хорн? )
#featureengineering #featureselection #autofeat
time: 5min 23s (started: 2024-03-02 06:07:07 +03:00)
Эмм.. А можно мне другой отборщик признаков? )
from autofeat import AutoFeatRegressor
model = AutoFeatRegressor(transformations = ('1/', 'exp', 'log', 'sin', 'sqrt', '^2', '^3'),featsel_runs=15)
new_df = model.fit_transform(df, y)
time: 5min 23s (started: 2024-03-02 06:07:07 +03:00)
Эмм.. А можно мне другой отборщик признаков? )
#featureengineering #featureselection #diogenes
Хорошие новости!
Как уже поняли читатели моего блога, в библиотеке отбора признаков Диоген появился также и модуль инженерии/конструирования новых признаков, но не бездумного, как в autofeat, а направленного, на основании теоретико-информационных метрик (в основном, взаимной информации MI комбинаций факторов с таргетом).
Основной мотивацией была попытка выделить рациональное зерно из набивших оскомину унылых рекомендаций и бубнежа вида "также иногда помогает логарифмирование, экспоненциирование, извлечение корней, попарное перемножение или деление исходных факторов". Эти рекомендации регулярно встречаются в курсах по FE и презентациях кэгглеров, но непонятно, как к этому вообще подступаться, кроме разве что каких-то случайных выпадов. Ну вот есть у меня 10k оригинальных признаков, мне взаимные отношения или произведения у каких именно из 50M пар проверять?
А так как метод MRMR в Диогене как раз и определяет достаточно хорошее в смысле предиктивности и уникальности подмножество признаков, некоторая проверка комбинаций становится уже реальной. Ещё больше пространство поиска сужает эвристика, что MI от "хорошей" на предмет тесной нелинейной связи пары признаков должна быть выше суммы индивидуальных MI факторов пары.
Это уже позволяет брать любые известные классы функций и для пары признаков a,b пытаться подбирать (в рамках бюджета) F3(F1(a),F2(b)) дающие максимальную MI с таргетом. В некоторых простых случаях этот метод срабатывает на ура, результаты я показывал выше. Но, если истинная зависимость сильно искажает вход ДО передачи в нелинейную функцию, метод становится практически бессилен и связь не обнаруживается.
Алексей @introspec предложил очень классную идею: почему бы не заменить подбор функций, сходимость которого дело скорее удачи, подбором коэффициентов ортогональных многочленов (например, Эрмитовых), теоретически умеющих аппроксимировать любую функциональную зависимость на отрезке? Взяв степень пониже, и коэффициенты поближе к 0, можно обеспечить своего рода регуляризацию.
Я попробовал пару дней тому заменить случайный поиск в пространстве функций на почти настолько же случайный поиск в пространстве коэффициентов Эрмитовых полиномов, но поставил вариацию на паузу из-за того, что не находились достаточно хорошие решения.
Теперь, собственно, к новостям )
Потестил свой модуль с разными исходными зависимостями, немного прояснил чувствительность и границы применимости метода. Пофиксил баги.
И... Заменил случайный перебор Эрмитовых полиномов на направленную оптимизацию с помощью Optuna )
Решения явно стали находиться получше за разумное время, иногда по качеству не уступают "нативным", когда зависимость известна. Нужно больше тестов. И, самое главное, предстоит выяснить, дают ли такие необычные преобразования реальные преимущества в ML метриках, или же ведут к оверфиту.
Хорошие новости!
Как уже поняли читатели моего блога, в библиотеке отбора признаков Диоген появился также и модуль инженерии/конструирования новых признаков, но не бездумного, как в autofeat, а направленного, на основании теоретико-информационных метрик (в основном, взаимной информации MI комбинаций факторов с таргетом).
Основной мотивацией была попытка выделить рациональное зерно из набивших оскомину унылых рекомендаций и бубнежа вида "также иногда помогает логарифмирование, экспоненциирование, извлечение корней, попарное перемножение или деление исходных факторов". Эти рекомендации регулярно встречаются в курсах по FE и презентациях кэгглеров, но непонятно, как к этому вообще подступаться, кроме разве что каких-то случайных выпадов. Ну вот есть у меня 10k оригинальных признаков, мне взаимные отношения или произведения у каких именно из 50M пар проверять?
А так как метод MRMR в Диогене как раз и определяет достаточно хорошее в смысле предиктивности и уникальности подмножество признаков, некоторая проверка комбинаций становится уже реальной. Ещё больше пространство поиска сужает эвристика, что MI от "хорошей" на предмет тесной нелинейной связи пары признаков должна быть выше суммы индивидуальных MI факторов пары.
Это уже позволяет брать любые известные классы функций и для пары признаков a,b пытаться подбирать (в рамках бюджета) F3(F1(a),F2(b)) дающие максимальную MI с таргетом. В некоторых простых случаях этот метод срабатывает на ура, результаты я показывал выше. Но, если истинная зависимость сильно искажает вход ДО передачи в нелинейную функцию, метод становится практически бессилен и связь не обнаруживается.
Алексей @introspec предложил очень классную идею: почему бы не заменить подбор функций, сходимость которого дело скорее удачи, подбором коэффициентов ортогональных многочленов (например, Эрмитовых), теоретически умеющих аппроксимировать любую функциональную зависимость на отрезке? Взяв степень пониже, и коэффициенты поближе к 0, можно обеспечить своего рода регуляризацию.
Я попробовал пару дней тому заменить случайный поиск в пространстве функций на почти настолько же случайный поиск в пространстве коэффициентов Эрмитовых полиномов, но поставил вариацию на паузу из-за того, что не находились достаточно хорошие решения.
Теперь, собственно, к новостям )
Потестил свой модуль с разными исходными зависимостями, немного прояснил чувствительность и границы применимости метода. Пофиксил баги.
И... Заменил случайный перебор Эрмитовых полиномов на направленную оптимизацию с помощью Optuna )
Решения явно стали находиться получше за разумное время, иногда по качеству не уступают "нативным", когда зависимость известна. Нужно больше тестов. И, самое главное, предстоит выяснить, дают ли такие необычные преобразования реальные преимущества в ML метриках, или же ведут к оверфиту.
#featureselection #diogenes #rfecv
Вот так работает обратное удаление признаков в Диогене, кстати, в реальном проекте уже.
Вот так работает обратное удаление признаков в Диогене, кстати, в реальном проекте уже.
#featureselection #kuhn
Читаю по рекомендации товарища книжку по ML. В главе по FS есть задание, мимо которого не смог пройти ) Надо будет потестить на нём Диогена. А возьмётся кто-то из читателей потестить на этом примере алгоритмы sklearn/mlxtend?
Читаю по рекомендации товарища книжку по ML. В главе по FS есть задание, мимо которого не смог пройти ) Надо будет потестить на нём Диогена. А возьмётся кто-то из читателей потестить на этом примере алгоритмы sklearn/mlxtend?
#news #automl
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).
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).
#featureselection
Классная идея применения коэффициентов Шэпли для отбора признаков!
Задача FS вообще NP-сложная и сводится к выбору оптимального значения бинарного вектора длины n_features (n_features это количество признаков-кандидатов в исходной выборке). Строго говоря, для её точного решения нужно оценить OOS-метрики моделей, обученных на всех возможных сочетаниях признаков от 1 до n_features (2^n_features комбинаций).
Автор же показывает, как, используя свойство аддитивности индивидуальных shap values признаков, можно заменить дорогое обучение модели и выдачу прогноза на комбинации признаков на... просто суммирование shap values этих признаков в большой модели (обученной один раз на всех признаках).
Понятно, что это будет лишь аппроксимацией прогнозов реальной модели, честно (и долго) обученной именно на нужной комбинации признаков, но автор на множестве датасетов оценил точность этой аппроксимации, и её ранжирующие свойства оказались высоки.
PS. Тут надо провести дописследование. Как бы не вытащить себя самих за волосы из болота, как известный барон )
А вообще, конечно, сразу приходят в голову возможные улучшения для этого подхода:
1) обучать вместо одной N больших моделей (с разными HPT и вообще разными алгоритмами
2) обучать вместо одной большой модели на всех признаках M моделей на случайной части 1/M от всех признаков. Потом при оценке комбинаций, полностью попадающих в бакет i=1..M, брать не общую модель, а более конкретную i (ну или взвешенное среднее).
3) комбинация 1 и 2
4) а точно ли не нужно никакое масштабирование частичных сумм значений Шэпли?
Если эта идея рабочая, она позволит расширить область применения полного перебора (а это самый точный метод FS) с 5 (32 честные комбинации) до примерно 40 факторов (1.1 трлн аппроксимированных комбинаций).
Ну и, практически говоря, это поможет и в частичном переборе. Например, получили мы какой-то перспективный список предикторов - от эксперта, RFECV, или как-то ещё. Ну и берём 20-30-40 лучших признаков из списка, насколько потянет железо, и применяем полный аппроксимированный перебор уже к этому сокращённому списку. Профит? Профит.
Посоветовался с чат гпт, после нескольких пинков она даже сама распознала, что
Using SHAP values to approximate the predictions of models trained on specific subsets of features is an innovative approach. The idea is to use the contributions of individual features (as captured by SHAP values) to estimate the predictions of a model that would have been trained on a subset of those features.
Предложила использовать среднее сумм shap values предикторов-кандидатов для коррекции base value, и Interaction-aware SHAP Values.
Через год что, эти чёртовы языковые модели нас полностью превзойдут уже и в научной креативности? )
https://towardsdatascience.com/approximate-predictions-make-feature-selection-radically-faster-0f9664877687
Классная идея применения коэффициентов Шэпли для отбора признаков!
Задача FS вообще NP-сложная и сводится к выбору оптимального значения бинарного вектора длины n_features (n_features это количество признаков-кандидатов в исходной выборке). Строго говоря, для её точного решения нужно оценить OOS-метрики моделей, обученных на всех возможных сочетаниях признаков от 1 до n_features (2^n_features комбинаций).
Автор же показывает, как, используя свойство аддитивности индивидуальных shap values признаков, можно заменить дорогое обучение модели и выдачу прогноза на комбинации признаков на... просто суммирование shap values этих признаков в большой модели (обученной один раз на всех признаках).
Понятно, что это будет лишь аппроксимацией прогнозов реальной модели, честно (и долго) обученной именно на нужной комбинации признаков, но автор на множестве датасетов оценил точность этой аппроксимации, и её ранжирующие свойства оказались высоки.
PS. Тут надо провести дописследование. Как бы не вытащить себя самих за волосы из болота, как известный барон )
А вообще, конечно, сразу приходят в голову возможные улучшения для этого подхода:
1) обучать вместо одной N больших моделей (с разными HPT и вообще разными алгоритмами
2) обучать вместо одной большой модели на всех признаках M моделей на случайной части 1/M от всех признаков. Потом при оценке комбинаций, полностью попадающих в бакет i=1..M, брать не общую модель, а более конкретную i (ну или взвешенное среднее).
3) комбинация 1 и 2
4) а точно ли не нужно никакое масштабирование частичных сумм значений Шэпли?
Если эта идея рабочая, она позволит расширить область применения полного перебора (а это самый точный метод FS) с 5 (32 честные комбинации) до примерно 40 факторов (1.1 трлн аппроксимированных комбинаций).
Ну и, практически говоря, это поможет и в частичном переборе. Например, получили мы какой-то перспективный список предикторов - от эксперта, RFECV, или как-то ещё. Ну и берём 20-30-40 лучших признаков из списка, насколько потянет железо, и применяем полный аппроксимированный перебор уже к этому сокращённому списку. Профит? Профит.
Посоветовался с чат гпт, после нескольких пинков она даже сама распознала, что
Using SHAP values to approximate the predictions of models trained on specific subsets of features is an innovative approach. The idea is to use the contributions of individual features (as captured by SHAP values) to estimate the predictions of a model that would have been trained on a subset of those features.
Предложила использовать среднее сумм shap values предикторов-кандидатов для коррекции base value, и Interaction-aware SHAP Values.
Через год что, эти чёртовы языковые модели нас полностью превзойдут уже и в научной креативности? )
https://towardsdatascience.com/approximate-predictions-make-feature-selection-radically-faster-0f9664877687
Medium
“Approximate-Predictions” Make Feature Selection Radically Faster
Feature selection is so slow because it requires the creation of many models. Find out how to make it blazingly faster thanks to…
#featureselection
Подобрался к более детальной проверке идеи из этого поста. Результаты поистине изумительные.
Как мы и знали раньше (из оригинального исследования автора, + моей проверки), корреляция "аппроксимированных предсказаний" и "честных предсказаний", хотя иногда и поднимается выше 90% (если количество признаков-кандидатов близко к полному количеству признаков), в среднем звёзд с неба не хватает.
Я взял датасет poker из pycaret, т.к. там достаточно наблюдений (100k), и дополнительно к к-ту корреляции посчитал RMSE честных и аппроксимированных предсказаний. Выяснился печальный факт, что RMSE просто среднего таргета по выборке (dummy) зачастую побеждает авторский способ оценки (naive).
Я расстроился, но, помня красивые графики автора, всё-таки посчитал реальные ошибки ground truth vs naive predictions, а уже от них NDCG в разрезе наборов признаков-кандидатов.
И был просто шокирован.
ndcg(naive_opt_fin_rmse)=0.99995 по 50 наборам признаков-кандидатов с числом признаков от 1 до 9 (всего в датасете их 10).
То есть, из Shap-значений нельзя вытащить прям точные аппроксимации честных прогнозов (слишком высокая RMSE). Но и не надо: даже эти аппроксимации позволяют с высокой точностью ранжировать наборы признаков-кандидатов (удивительно высокий NDCG).
Почему? Загадка. Видимо, движения "в нужном направлении" достаточно для точного ранжирования, и это важнее, чем абсолютная величина совпадения прогнозов. Здесь, похоже, действуют какие-то тонкие математические эффекты, которых я не понимаю. Но эта идея реально работает.
На датасете poker "честное переобучение" модельки занимает у меня 8 секунд, а оценка авторским методом 0,005 секунд. Ускорение в 1500+ раз при 0.99995 условной точности ранжирования.
"Условной", потому что на больших списках ndcg становится "логарифмически нечувствительным" к хорошему ранжированию. Например, случайное ранжирование в этой же задаче (с теми же релевантностями) на списке размером 50 выдаёт NDCG=0.987.
Если же отказаться от абсолютной шкалы целевой ML-метрики, и в качестве релевантностей использовать целые числа [1,2,..,N], NDCG случайного ранжирования становится в среднем 0,827, а NDCG авторского ранжирования 0,968. Ну то есть, это прекрасный значимый результат.
Подобрался к более детальной проверке идеи из этого поста. Результаты поистине изумительные.
Как мы и знали раньше (из оригинального исследования автора, + моей проверки), корреляция "аппроксимированных предсказаний" и "честных предсказаний", хотя иногда и поднимается выше 90% (если количество признаков-кандидатов близко к полному количеству признаков), в среднем звёзд с неба не хватает.
Я взял датасет poker из pycaret, т.к. там достаточно наблюдений (100k), и дополнительно к к-ту корреляции посчитал RMSE честных и аппроксимированных предсказаний. Выяснился печальный факт, что RMSE просто среднего таргета по выборке (dummy) зачастую побеждает авторский способ оценки (naive).
Я расстроился, но, помня красивые графики автора, всё-таки посчитал реальные ошибки ground truth vs naive predictions, а уже от них NDCG в разрезе наборов признаков-кандидатов.
И был просто шокирован.
ndcg(naive_opt_fin_rmse)=0.99995 по 50 наборам признаков-кандидатов с числом признаков от 1 до 9 (всего в датасете их 10).
То есть, из Shap-значений нельзя вытащить прям точные аппроксимации честных прогнозов (слишком высокая RMSE). Но и не надо: даже эти аппроксимации позволяют с высокой точностью ранжировать наборы признаков-кандидатов (удивительно высокий NDCG).
Почему? Загадка. Видимо, движения "в нужном направлении" достаточно для точного ранжирования, и это важнее, чем абсолютная величина совпадения прогнозов. Здесь, похоже, действуют какие-то тонкие математические эффекты, которых я не понимаю. Но эта идея реально работает.
На датасете poker "честное переобучение" модельки занимает у меня 8 секунд, а оценка авторским методом 0,005 секунд. Ускорение в 1500+ раз при 0.99995 условной точности ранжирования.
"Условной", потому что на больших списках ndcg становится "логарифмически нечувствительным" к хорошему ранжированию. Например, случайное ранжирование в этой же задаче (с теми же релевантностями) на списке размером 50 выдаёт NDCG=0.987.
Если же отказаться от абсолютной шкалы целевой ML-метрики, и в качестве релевантностей использовать целые числа [1,2,..,N], NDCG случайного ранжирования становится в среднем 0,827, а NDCG авторского ранжирования 0,968. Ну то есть, это прекрасный значимый результат.
Telegram
Aspiring Data Science
#featureselection
Классная идея применения коэффициентов Шэпли для отбора признаков!
Задача FS вообще NP-сложная и сводится к выбору оптимального значения бинарного вектора длины n_features (n_features это количество признаков-кандидатов в исходной выборке).…
Классная идея применения коэффициентов Шэпли для отбора признаков!
Задача FS вообще NP-сложная и сводится к выбору оптимального значения бинарного вектора длины n_features (n_features это количество признаков-кандидатов в исходной выборке).…
#featureselection
В дополнение к посту. Потестировал много вариантов улучшения исходной идеи:
1) усреднение значений Шэпли нескольких типов (с разными feature_perturbation)
2) усреднение значений Шэпли нескольких разных моделей
3) использование парных интеракций (shap_interaction_values)
4) мета-модель ML: зная индексы выбранных в комбинацию признаков и оставшихся признаков, а также честные предсказания моделек, давайте попробуем создать как мета-признаки ряд простых числовых агрегатов от шепли-значений (суммы, средние, отклонения, мин/макс и тп). ну и уже от этого мета-модель, вдруг она будет точнее чем исходная простая идея просуммировать значения Шепли выбранных в комбинацию признаков?
Находки/открытия:
1) не существует работающей реализации Shap на GPU (GPUTreeExplainer из пакета shap нерабочий, и всем похер. По идее он должен ставиться с xgboost (без shap), но он всё равно не юзает gpu, я проверял.)
2) KernelExplainer непроходимо медленен, забудьте про его использование. Речь о сотнях часов даже на небольшом датасете.
3) некоторые модели (lightgbm) считают интеракции в один поток и очень медленно (~40 минут на 100k x 20 датасете)
4) некоторые бустинги (Catboost) раздувают expected_value так, что они не просто не сходятся точно к среднему прогнозу, а превышают его вдвое. При этом внутренняя проверка shap на аддитивность проходит! ХЗ как это возможно. У других бустингов тоже такое наблюдалось, но хотя бы с гораздо меньшей амплитудой. В режиме feature_perturbation="tree_path_dependent" такого никогда не наблюдал.
5) Режим feature_perturbation="interventional" требует теневого датасета и считает значения Шэпли на порядки дольше, но ничего не даёт к точности.
6) xgboost (и только он) поддерживает доп параметр approximate=True, который отрабатывает быстрее, но реально роняет качество. его использовать не надо.
7) документация shap по-прежнему дырявая (параметры объясняльщика, которые ничего не делают, например), а на гитхабе никто по-прежнему не отвечает и не отрабатывает сигналы и проблемы юзеров. не понимаю, как они при этом релизят новые версии, скорее всего, это в основном переписывания исходного говнокода Скотта Ландберга.
Ну и самое главное, по поводу аппроксимации честных прогнозов шэпли-значениями.
1) все виды бустингов и все виды объясняльщиков для нашей задачи имеют примерно одинаковое качество (если не использовалось approximate=True)
2) усреднения ничего особо не меняют.
3) метамодель существенно улучшает линейную (да и другие) корреляцию, но особо не меняет метрики ранжирования комбинаций (которые и так на удивление хороши).
4) при небольшой по размеру группе кандидатов на удивление ранжирующие свойства сильно не падают.
В дополнение к посту. Потестировал много вариантов улучшения исходной идеи:
1) усреднение значений Шэпли нескольких типов (с разными feature_perturbation)
2) усреднение значений Шэпли нескольких разных моделей
3) использование парных интеракций (shap_interaction_values)
4) мета-модель ML: зная индексы выбранных в комбинацию признаков и оставшихся признаков, а также честные предсказания моделек, давайте попробуем создать как мета-признаки ряд простых числовых агрегатов от шепли-значений (суммы, средние, отклонения, мин/макс и тп). ну и уже от этого мета-модель, вдруг она будет точнее чем исходная простая идея просуммировать значения Шепли выбранных в комбинацию признаков?
Находки/открытия:
1) не существует работающей реализации Shap на GPU (GPUTreeExplainer из пакета shap нерабочий, и всем похер. По идее он должен ставиться с xgboost (без shap), но он всё равно не юзает gpu, я проверял.)
2) KernelExplainer непроходимо медленен, забудьте про его использование. Речь о сотнях часов даже на небольшом датасете.
3) некоторые модели (lightgbm) считают интеракции в один поток и очень медленно (~40 минут на 100k x 20 датасете)
4) некоторые бустинги (Catboost) раздувают expected_value так, что они не просто не сходятся точно к среднему прогнозу, а превышают его вдвое. При этом внутренняя проверка shap на аддитивность проходит! ХЗ как это возможно. У других бустингов тоже такое наблюдалось, но хотя бы с гораздо меньшей амплитудой. В режиме feature_perturbation="tree_path_dependent" такого никогда не наблюдал.
5) Режим feature_perturbation="interventional" требует теневого датасета и считает значения Шэпли на порядки дольше, но ничего не даёт к точности.
6) xgboost (и только он) поддерживает доп параметр approximate=True, который отрабатывает быстрее, но реально роняет качество. его использовать не надо.
7) документация shap по-прежнему дырявая (параметры объясняльщика, которые ничего не делают, например), а на гитхабе никто по-прежнему не отвечает и не отрабатывает сигналы и проблемы юзеров. не понимаю, как они при этом релизят новые версии, скорее всего, это в основном переписывания исходного говнокода Скотта Ландберга.
Ну и самое главное, по поводу аппроксимации честных прогнозов шэпли-значениями.
1) все виды бустингов и все виды объясняльщиков для нашей задачи имеют примерно одинаковое качество (если не использовалось approximate=True)
2) усреднения ничего особо не меняют.
3) метамодель существенно улучшает линейную (да и другие) корреляцию, но особо не меняет метрики ранжирования комбинаций (которые и так на удивление хороши).
4) при небольшой по размеру группе кандидатов на удивление ранжирующие свойства сильно не падают.
Telegram
Aspiring Data Science
#featureselection
Подобрался к более детальной проверке идеи из этого поста. Результаты поистине изумительные.
Как мы и знали раньше (из оригинального исследования автора, + моей проверки), корреляция "аппроксимированных предсказаний" и "честных предсказаний"…
Подобрался к более детальной проверке идеи из этого поста. Результаты поистине изумительные.
Как мы и знали раньше (из оригинального исследования автора, + моей проверки), корреляция "аппроксимированных предсказаний" и "честных предсказаний"…
#featureselection
Вот внесэмпловые метрики XGBRegressor feature_perturbation=tree_path_dependent, approximate=False из предыдущего поста.
meta=мета-моделька, naive это просто сумма шэпли-значений как у автора идеи, adjusted это naive минус сумма шэпли-значений признаков не вошедших в комбинацию.
Считалось на датасете poker (10 исходных признаков + 5 фейковых случайных + 5 коррелированных с исходными). Помимо 2 видов ndgc (rel/abs), грубыми, но выразительными метриками были top_recall@k. Например, чтобы посчитать recall@10, брались 10 лучших (согласно честными прогнозам) на test комбинаций, и проверялось, сколько из них оказались в 10 лучших по версии того или иного метода.
В целом, для данной задачи нет смысла морочиться с мета-моделью, надо просто брать наивный оригинальный метод автора, и feature_perturbation="tree_path_dependent".
Вот внесэмпловые метрики XGBRegressor feature_perturbation=tree_path_dependent, approximate=False из предыдущего поста.
meta=мета-моделька, naive это просто сумма шэпли-значений как у автора идеи, adjusted это naive минус сумма шэпли-значений признаков не вошедших в комбинацию.
Считалось на датасете poker (10 исходных признаков + 5 фейковых случайных + 5 коррелированных с исходными). Помимо 2 видов ndgc (rel/abs), грубыми, но выразительными метриками были top_recall@k. Например, чтобы посчитать recall@10, брались 10 лучших (согласно честными прогнозам) на test комбинаций, и проверялось, сколько из них оказались в 10 лучших по версии того или иного метода.
В целом, для данной задачи нет смысла морочиться с мета-моделью, надо просто брать наивный оригинальный метод автора, и feature_perturbation="tree_path_dependent".
#featureselection #shap
Ну и теперь к практической реализации отборщика признаков на основе этой прекрасной идеи. Как это вообще сделать?
Обучать одну большую модель на всех признаках надо обязательно. Это, по счастливому совпадению, 1-й шаг всех RFE-* методов.
Далее получаем "простые" кэфы Шэпли самым быстрым (но не приближённым) методом. По желанию усредняем на CV.
И тут открывается простор для фантазии:
Полный брутфорс:
Генерим все 2^n_features сочетаний признаков, сортируем индексы признаков в сочетаниях.
суммируем шэпли-значения 1й комбинации. далее удаляем суммы убывших, прибавляем суммы прибывших в комбинацию признаков. раз в N итераций ресет суммы, чтобы сбросить накопленную ошибку суммирования.
Генетик:
Вектор 1/0 длины n_features генов - это особь популяции, её фитнесс оценивать мы умеем (суммируя его шэпли-значения и считая от них и ground truth нашу ml-метрику).
применяем направленный поиск путём скрещивания, мутаций, и прочего элитизма. Запускаем эволюцию, играем в Создателя, смеёмся страшным голосом mwa-ha-ha.
Любая другая эвристика, типа имитации отжига:
Начинаем со случайного вектора, делаем небольшие изменения, продвигаемся с вероятностью пропорциональной улучшениям, порог принятия снижается со временем.
Мультистарт. А если начинать с кандидатов ранжированных по FI?
Градиентный поиск:
Ну да, это ж бинарный вектор, нет непрерывности, как по нему дифференцировать? Есть идея применить "признаки Шрёдингера"! ))
А именно, размазать их бинарность с помощью весового коэффициента. Они могут как бы входить, а как бы и нет в комбинацию с определённым весом. А чтобы вес в итоге ограничивался промежутком [0,1], к нему можно применить сигмоиду. Тем самым autograd-оптимизатор по идее сможет найти экстремумы ML-метрики, плавно включив/исключив признаки из комбинации.
А если итоговая ML-метрика недифференцируема (типа ROC, PR AUC)? Ну тогда ведь можно взять Brier score или какую-то подходящую прокси.
Уже есть набросок кода для pytorch, попробую затестить.
Не знаю, что сработает лучше, есть надежды на градик.
В любом случае, надо дать методу оптимизации поработать (в рамках бюджета времени), и получить от него топ-N лучших кандидатов. А их уже "честно" проверить (в оставшееся время) на insample CV и вернуть самую лучшую/устойчивую комбинацию признаков.
Надо ещё помнить, что точность метода может падать при уменьшении количества кандидатов в группе по сравнению с размерностью матрицы значений Шэпли, но это обсудим позже.
Ну и теперь к практической реализации отборщика признаков на основе этой прекрасной идеи. Как это вообще сделать?
Обучать одну большую модель на всех признаках надо обязательно. Это, по счастливому совпадению, 1-й шаг всех RFE-* методов.
Далее получаем "простые" кэфы Шэпли самым быстрым (но не приближённым) методом. По желанию усредняем на CV.
И тут открывается простор для фантазии:
Полный брутфорс:
Генерим все 2^n_features сочетаний признаков, сортируем индексы признаков в сочетаниях.
суммируем шэпли-значения 1й комбинации. далее удаляем суммы убывших, прибавляем суммы прибывших в комбинацию признаков. раз в N итераций ресет суммы, чтобы сбросить накопленную ошибку суммирования.
Генетик:
Вектор 1/0 длины n_features генов - это особь популяции, её фитнесс оценивать мы умеем (суммируя его шэпли-значения и считая от них и ground truth нашу ml-метрику).
применяем направленный поиск путём скрещивания, мутаций, и прочего элитизма. Запускаем эволюцию, играем в Создателя, смеёмся страшным голосом mwa-ha-ha.
Любая другая эвристика, типа имитации отжига:
Начинаем со случайного вектора, делаем небольшие изменения, продвигаемся с вероятностью пропорциональной улучшениям, порог принятия снижается со временем.
Мультистарт. А если начинать с кандидатов ранжированных по FI?
Градиентный поиск:
Ну да, это ж бинарный вектор, нет непрерывности, как по нему дифференцировать? Есть идея применить "признаки Шрёдингера"! ))
А именно, размазать их бинарность с помощью весового коэффициента. Они могут как бы входить, а как бы и нет в комбинацию с определённым весом. А чтобы вес в итоге ограничивался промежутком [0,1], к нему можно применить сигмоиду. Тем самым autograd-оптимизатор по идее сможет найти экстремумы ML-метрики, плавно включив/исключив признаки из комбинации.
А если итоговая ML-метрика недифференцируема (типа ROC, PR AUC)? Ну тогда ведь можно взять Brier score или какую-то подходящую прокси.
Уже есть набросок кода для pytorch, попробую затестить.
Не знаю, что сработает лучше, есть надежды на градик.
В любом случае, надо дать методу оптимизации поработать (в рамках бюджета времени), и получить от него топ-N лучших кандидатов. А их уже "честно" проверить (в оставшееся время) на insample CV и вернуть самую лучшую/устойчивую комбинацию признаков.
Надо ещё помнить, что точность метода может падать при уменьшении количества кандидатов в группе по сравнению с размерностью матрицы значений Шэпли, но это обсудим позже.