#featureselection #diogenes #rfecv

Вот так, кстати, выглядит зависимость ML-метрики от числа признаков в Diogenes. Это пример с реальными данными, но синтетическими зависимостями. Пока кандидаты для проверки генерятся полным случайным перебором, подключаю более интеллектуальные методы.

#featureselection #rfecv

Некоторые мысли по поводу процесса отбора признаков в RFECV

1) Количество проверяемых признаков имеет свою стоимость. Проверить nfeatures=10 стоит гораздо дешевле, чем проверить nfeatures=1000 (скажем, на терабайтном датасете). С другой стороны, проверка 1000 фичей даст больше информации об их рейтинге, что будет полезно при выборе следующих кандидатов. Но опять же, за время проверки 1000 можно проверить сразу несколько более мелких комбинаций... Надо как-то учитывать этот баланс.
Пока ограничусь проверкой начальных сэмплированных значений (для обучения базы) в порядке возрастания, чтобы при срабатывании лимита времени успеть проверить больше комбинаций.

2) Можно ли совмещать FS с HPT прямо в процессе FS? Скажем, пока мы с помощью интеллектуального алгоритма из 1000 признаков проверяем 50 комбинаций nfeatures, можем ли мы одновременно варьировать гиперпараметры базового оценщика, чтобы собрать дополнительную ценную информацию? С точки зрения выбора следующего кандидата варьирование HPT обычно ничего не изменит (за исключением случаев когда HPT совсем уж явно изменит лидеров), т.к. всё равно будут использоваться ранги. А вот для последующего обучения на финальном наборе это может дать очень ценную информацию бесплатно, особенно если базовый оценщик тоже будет использоваться на финальной стадии конвейера. Плюс это повысит вариативность, и, соответственно, реалистичность оценок CV.

Проще говоря, если собирать инфу о рейтингах признаков неизбежно надо, причём обучая модельки, так давайте заодно менять при каждом обучении HP и дополнительно собирать данные о чувствительности итоговых метрик к гиперпараметрам?
Планирую сэмплить HP из допустимого множества для заданной базовой модели. Возможно, придётся вести список "опасных" значений HP, которые сильно увеличат время расчётов. Итоговые кортежи (hp,feature_stats,train_time,ml_perf) сохранять в отборщике признаков для посл старта в HPT.

3) А можно ли как-то ещё заюзать эти десятки и сотни промежуточных моделек из фазы FS? Понятно, они все обучены на разных количествах признаков, да ещё и лишь на CV частях train set. Но всё-таки даже на них будут затрачены большие ресурсы, и они представляют собой ценный актив. Ну хотя бы с точки зрения последующего ансамблирования, или точечной оценки уверенности в прогнозах (когда модельки расходятся во мнениях)?
Думаю опционально сохранять их в памяти и/или на диске, с указанием входных признаков.

4) Есть ли смысл в RFECV использовать сразу несколько базовых алгоритмов? Скажем, и catboost, и lgbm.

5) Как выяснилось недавно, у lgbm есть режим, когда листья дерева заменяются наклонными линиями регрессии. По идее, это позволит лучше моделировать связи, особенно на небольшом числе точек. Стоит ли попробовать такой сплайновый режим?

#milestones #plans #2023

Итоги моего 2023-го года.

Бизнес-проекты

К сожалению, у меня трудности с доведением замыслов до готового продукта, даже если технически всё реализовать я могу - теряется как-то быстро интерес, что ли. В 2023-м я "технически сделал" 1 такой продукт/сервис для поиска подходящих облачных серверов, #opticloud, но никуда в паблик пока не вывел. Также за этот год появились идеи как минимум 6 интересных стартапов (от знакомств и обучения языкам до оптимизации СУБД), над некоторыми я даже неплохо поработал и добился начального прогресса. Благодаря неожиданно вышедшему на связь старому товарищу поработал над ML в оценке недвижимости. В планах на 2024-й продолжить работу над этими проектами, и, самое важное, зарелизить как минимум 1 общедоступный цифровой продукт.

Совместная работа

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

ML

За год удалось вернуться к многим своим старым идеям о взаимной информации и отборе признаков, переписать свою старую библиотечку с visual basic на python с многопроцессорностью и gpu, сформулировать идеи экспериментов и сравнений, которые надо провести. Начал писать свою FS-либу #diogenes, сейчас она включает в себя на 95% готовые модули filters и wrappers с кастомной реализацией SelectBest и #RFECV и превосходит по функциональности и качеству всё то, что я знаю из общедоступных решений. В планах на 2024-й её доведение до ума и интеграция со своей библиотекой оптимизации гиперпараметров.

Обучение

В основном я прокачивал знания в ML, просматривая/прослушивая ютуб-ролики, на эту тему (эффективного усваивания подобного материала) появились идеи ещё нескольких стартапов )

Соревнования

В очередной раз подтвердилось моё понимание, что ML-соревы - это бесполезная трата времени. Насколько я был воодушевлён, решив поучаствовать в #watersupply, настолько же оказался разочарован, увидев, какие тупые искусственные ограничения туда добавили организаторы. Ещё более меня разочаровали 350+ дата сайентистов, которые слова не сказали против таких правил, позволяющих пилить оверфитнутые решения, бессмысленные с точки зрения практики. В итоге, после препирания (моего и ещё 1 неравнодушного участника) с админами площадки, незадолго от дедлайна пришло уведомление, что идиотские ограничения убраны, что ещё более усилило, как это модно говорить, чувство кринжа.

Правда, в начале года я выиграл мини-сореву по предсказанию цен на электричество #electricity, но там каждому участнику была гарантирована компенсация в $2k независимо от места, и я ничего не терял. С тех пор, кстати, я сильно прокачал модуль генерации признаков для временных рядов, использованный в сореве.

Публицистика

Написал несколько статей на medium. Площадка - говно, но и хабр не лучше, а куда-то писать надо было.

Трейдинг

Это одна из тем, к которой я регулярно возвращаюсь со времён университета, и отступаю из-за нехватки знаний. В этот раз уже знаний, кажется, хватает, но завяз в тонкостях реализации. Проделана большая работа в нескольких поднаправлениях, в частности, сделано хорошее логирование экспериментов в MFlow, с ансамблями и стекнгом. Ожидается существенный прогресс от интеграции с Диогеном. Надо, как всегда, побыстрее делать простое работающее решение, и постепенно улучшать. В этом плане я решил попробвать сначала поработать с трейдером, предоставив ему информационную поддержку в виде веб-панельки с прогнозами, какие активы имеют высокую вероятность роста/падения в ближайшее время, посмотрим, будет ли она полезной. В планах на 2024-й, безусловно, полностью автоматизированная торговля на основе ML моделей.

#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) уже на полном входном датасете.

#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), но это уже тема другого разговора.

#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 на финансовом проекте, очень интересно смотреть в реальном времени, что он находит.

#featureselection #diogenes #rfecv

Вот так работает обратное удаление признаков в Диогене, кстати, в реальном проекте уже.