#featureengineering #supervisedlearning #standardpractice

Недавно был материал о стандартном подходе к решению ML-задач с разметкой (не хочется использовать термин "с учителем", нет там учителя/супервизора), хотелось бы подробнее остановиться на создании признаков.
Часто бывает, что в модельной задаче есть целые группы признаков, которые относятся к определённой сущности: пользователю, компании, активностям, внешней среде, локациям. Часть из них текстовые, часть графовые. Это всё ещё часто осложняется временной структурой, и надо думать об агрегатах этих всех признаков по некоторым скользящим окнам. Если всё это богатство слепить в одну таблицу, начинают буксовать любые алгоритмы, не говоря уже про требования к железу. Как не сойти с ума во время такой инженерии и добиться осмысленных результатов в рамках бюджета?
Пока я остановился на таком подходе.
1) определяем Cross-Validation schema и метрики
2) настраиваем библу для трекинга, типа neptune или mlflow
3) начинаем с DummyClassifier/Regressor (DummyLags, если у вас timeseries-задача) со всеми доступными strategy. Лучший по метрикам становится baseline-ом.
4) работаем индивидуально по группам, относящимся к отдельным классам сущностей (юзеры, компании, и т.п.), начиная с самых простых
5) также можно работать по признакам, объединённым типом данных, например, все текстовые. это позволит ещё и логично считать межпризнаковые связи, например, расстояния в разных пространствах.
6) на данной группе построенных признаков обучаемся, фиксируем CV метрики, делаем анализ важности признаков, фиксируем барчарт важностей и список как артефакт модели и фичерсета. важность признаков в группе позволяет понять, куда копать дальше, в какие дебри углубляться
7) если это временной ряд, надо строить окна. строим коррелограмму, ориентируемся на пики графика, начинаем с небольших окон.
8) когда все группы пройдены, анализируем важности признаков и принимаем решение о том, в какую сторону углубляться, повторяем цикл с более "тонкими" признаками
9) теперь объединяем группы, пробуем обучаться на всех сразу, и используя Feature Selector (по-прежнему на CV).
10) если остаётся время, пробуем отношения фичей из разных групп, их добавляем к основному датасету и прогоняем тоже через пункт 9

Теперь смотрим в свой трекинг, выбираем лучший вариант по соотношению сложность/качество. Страдает ли этот метод от подгонки? Конечно, ведь мы, принимая решения о новых фичах, заглядываем в метрики. Можно ли этого избежать? Не знаю. Но можно зарезервировать часть данных под OOS, и финальное решение принимать только по этому набору, это уменьшит смещение.

#featureengineering #hamilton

Новая библа для вдумчивого, покрытого тестами создания признаков. Каждый признак - функция. Драйвер выполняет функции в том числе на системах оркестрации типа prefect, airflow. Есть удобные декораторы метаданных, валидации. Наверное, это хорошо для энтерпрайза, где командная работа, и важно понимание, как что считается и кто за что в ответе. Также обещают масштабируемость (Ray, Dask, Spark).


https://www.youtube.com/watch?v=oQLEkjUNq0U&ab_channel=PyData

#statistics #informationtheory #entropy #python #featureselection #featureengineering

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

https://medium.com/@fingoldo/15819b261de0

#ml #featureselection #featureengineering #mrmr #sulov

Наткнулся на новую библиотечку по созданию и отбору признаков. Гордятся реализацией MRMR (Minimum Redundancy Maximum Relevance) и SULOV (Searching for Uncorrelated List of Variables).

https://github.com/AutoViML/featurewiz

#ml #masters #ensembling #featureengineering #entropy

Продолжаем.

"A common procedure is to train several competing models on the same training set and then choose the best performer for deployment. However, it is usually advantageous to use all of the competing models and intelligently combine their predictions or class decisions to produce a consensus opinion."

"It is not widely known that the entropy of a predictor variable can have a profound impact on the ability of many models to make effective use of the variable. Responsible researchers will compute the entropy of every predictor and take remedial action if any predictor has low entropy."

Первая идея не нова, в соревах все стэкают модели. Но опять-таки, это до сих пор не стандарт в МЛ, и тот же sklearn просто отбрасывает все модели за исключением "лучшей", там даже опции нет сохранить остальные, или, упаси Боже, совместно их использовать.

А вот энтропийный подход к выбору и предобработке предикторов оригинален, такой идеи я нигде не встречал больше. Что нам предлагает классика? Генерить побольше потенциальных признаков произвольной природы, пока Ваша модель не захлебнётся по ресурсам. Но ведь можно действовать умнее. Эту идею можно использовать при комбинации нескольких признаков: к примеру, оставлять только те комбинации, чья энтропия превышает энтропии родителей.

#featureengineering #dyakonov #pzad

Понравилось:

монотонное преобразование для порядковых признаков (напр, возведение в квадрат);

совет пересоздать признаки, даже если они уже посчитаны в оригинальных данных, сверить во избежание сюрпризов;

трюк с обратными признаками для линейных (только ли?) моделей;

Ordinal/LabelEncoding с индуцированным порядком (лексикографическим, по мере появления категории в датасете, по длине токена и пр);

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

кодирование мелких категорий в одну (сразу мысль, а нельзя ли это как-то улучшить с помощью теории информации? Что, если в категориальном признаке только некоторые уровни несут информацию о таргете, нельзя ли все остальные сплавить в "общую категорию бесполезных"?);

"Applied machine learning is basically feature engineering."
Andrew Ng

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

#featureengineering #dyakonov #pzad

Понравилось:

Count Encoding+шум;

Киллер фича кодирования категориальных признаков другими категориальными, через crosstab+SVD;

Target Encoding как форма стекинга;

Target Encoding+мультипликативный шум;

"Экспертное кодирование";

Category Embeddings;

Расстояние (ядро) до какого-то "идеального"/"нормального" объекта как новая фича;

Линейная модель на признаках нелинейной модели (например, сплитах дерева, random forest-based feature induction);

Кодирование M циклических признаков (вместо последовательных возрастающих целочисленных номеров) в 2 новых вектора x,y как t=np.linspace(0,2*np.pi, M+1), x=np.sin(t), y=np.cos(t); -надо бы замутить какой-то CyclicEncoder, кстати.

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

#kaggle #tricks #ml #titericz #featureengineering

Before FE, calculate corr coeff of raw features & the target; наверное, лучше всё-таки брать половину сета, чтобы не оверфитить совсем уж. С оценкой корреляций (нелинейных) и "интеракций", кстати, очень может помочь Диоген.

Combine numerical features: log(A)*log(B), A*exp(B), Rank(A)+Rank(B), sin(A)+cos(B) etc;

Use binary flag for NAs;

Do N-way nested OOF Target Encoding;

Try aggregations of one feature by another;

Try extensive target transformations (TT), as y^1/2, y^1/4,log(10+y), 10/y etc;

Try several clustering algos to create new categorical or numerical features based on cluster IDs or distances;

Trees leaves indices as weak features to the linear models (incl. factorization machines);

LOFO feature selection;

Adversarial Validation to tell train apart from test;


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

Feature Engineering and Selection: A Practical Approach for Predictive Models by Max Kuhn and Kjell Johnson

The process of developing predictive models includes many stages. Most resources focus on the modelling algorithms, but neglect other critical aspects of the modelling process. This book describes techniques for finding the best representations of predictors for modelling and for finding the best subset of predictors for improving model performance. A variety of example data sets are used to illustrate the techniques, along with R programs for reproducing the results.

Table of Contents:
1. Introduction
2. Illustrative Example: Predicting Risk of Ischemic Stroke
3. A Review of the Predictive Modeling Process
4. Exploratory Visualizations
5. Encoding Categorical Predictors
6. Engineering Numeric Predictors
7. Detecting Interaction Effects
8. Handling Missing Data
9. Working with Profile Data
10. Feature Selection Overview
11. Greedy Search Methods
12. Global Search Methods

Links:
- https://www.feat.engineering/
- https://www.routledge.com/Feature-Engineering-and-Selection-A-Practical-Approach-for-Predictive-Models/Kuhn-Johnson/p/book/9781138079229
- https://www.routledge.com/Feature-Engineering-and-Selection-A-Practical-Approach-for-Predictive-Models/Kuhn-Johnson/p/book/9781138079229

Navigational hashtags: #armknowledgesharing #armbooks
General hashtags: #machinelearning #ml #featureengineering #featureselection #missingdata #categoricalvariables

@accelerated_learning

#featureengineering #python #architecture

Возникла архитектурная задача. Мне нужно рассчитывать признаки на большом количестве дней. Сырые данные по дню лежат в 3 отдельных файлах. Что делается сейчас в цикле по дням:

1) файлы дня последовательно открываются как фреймы пандас, делается фильтрация и простой общий препроцессинг. работает 1 ядро. занимает 30 секунд.
2) обработанные файлы направляются в joblib.Parallel уже на все ядра с указанием, какой кусок данных просчитывать конкретному воркеру (ядру). работают все ядра, фаза занимает на текущем железе 10 минут. как происходит направление файлов: 2 передаются просто как параметры, их numpy прозрачно memmap-ит (в течение нескольких секунд). третий содержит столбец массивов (dtype=object), не родной тип numpy, поэтому memmap не происходит. приходится обработанный файл сохранять как временный(в паркет, это оказалось быстрее всего), и уже изнутри каждого рабочего потока открывать по ссылке. как и при сериализации, здесь дублируется RAM, но работает быстрее.

Неизбежно какие-то ядра заканчивают работу быстрее остальных, и в итоге утилизация процессора на какое-то время падает со 100% до, скажем, 30%. Ну и пока файлы готовятся, утилизация составляет жалкие проценты. Рабочие потоки, кстати, возвращают результаты как фреймы панадас, которые потом сливаются в 1 фрейм в главном потоке (2сек) и дампятся в файл (15сек). Итого выходит, что до 10% времени железо простаивает.

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

Пока думаю в отдельном потоке готовить файлы и складывать в очередь, если её длина меньше 3. иначе спать минуту. А уже в основном потоке брать из очереди и засылать на параллельное выполнение. Да, вспомогательный поток уменьшит на 1 число рабочих потоков, но так кодить будет проще, утилизация повысится с 90% до 99%. Также надо подумать об асинхронном мёрдже и сохранении результатов. Может, как раз в тот же вспомогательный поток результаты засылать? Пока остальные молотят расчёты, этот пусть будет завхозом, который файлы открывает, готовит, результаты собирает и сохраняет...

#featureengineering #gruzdev #pygeohash

Также порекламирую следующие мини-лекции по созданию признаков. Я потратил несколько долларов, чего и вам советую сделать )

Про геохэши вообще раньше не знал. Также ценным показался авторский опыт про манхэттенское расстояние в задачах оценки недвижимости, важность разнообразия MCC кодов и структуры deposits/withdrawals в задаче оттока. Ещё из необычного понравились:
- идея с округлением вещественных значений;
- идея с промежуточной моделью и формированием новых признаков - отношений между топовыми фичами (по важности) промежуточной модели (odd-even). Вообще данный подход кажется интересным для исследования на стадии feature improvement (название только что придумал). У меня по этому направлению будет отдельная работа, завязанная на теорию информации.

Интересно было отступление о методе EFB в lightgbm и связи с задачей раскраски карты.

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

https://boosty.to/gewissta/posts/46a20bb7-3a49-43d3-b63c-1610c608e7fa

#featureengineering

Поговорим о конструировании признаков. В теории мы знаем, что, если есть много времени и вычислительных ресурсов, неплохо бы попробовать забросить в модель не просто сырые фичи, а

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

В реальных проектах у меня до этого ни разу не дошли руки, отчасти ещё и потому, что я сомневался: а как такие сконструированные признаки подавать, отдельно или вместе, это ж как раздует объёмы данных и время расчётов, а как потом понять, какие нерелевантны...

Но после экспериментов с отборщиком признаков MRMR кажется весьма очевидным общий подход, позволяющий найти оптимальные преобразования и основанный на теории информации:

просто для каждого сырого признака на train, прошедшего отбор MRMR,

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

2) попарно, для всех сочетаний признаков из шага 1), проверяем, какое преобразование f(A,B) из списка стандартных максимизирует MI этой пары с таргетом (только на train!). если такая максимальная MI выше условной MI(A,Y;B), пара добавляется в пул улучшений с указанием ожидаемого "улучшения" информации. После проверки всех сочетаний, пары из пула сортируются по ожидаемому улучшению и начинают формироваться. Если переменная оказывается уже задействована в другой паре, можно допускать не более N повторных использований. Оригинальные задействованные переменные из датасета удаляются.

Как думаете, стоящая идея?

UPD. могу подтвердить, что в части 2 идея работает!!! это просто фантастика. Правда, в части 1 пока облом.

#featureengineering #autofeat

Вспомнил, что конструктор фичей уже реализован в библиотеке autofeat.

Давайте разбираться.

"Linear models+ non-linear features=LOVE"
"There is always enough RAM somewhere" ))

"Most existing feature construction frameworks follow the second, iterative feature engineering approach: The FICUS algorithm uses a beam search to expand the feature space based on a simple heuristic, while the FEADIS algorithm and Cognito use more complex selection strategies. A more recent trend is to use meta-learning, i.e., algorithms trained on other datasets, to decide whether to apply specific transformation to the features or not. While theoretically promising, we could not find an easy to use open source library for any of these approaches."

https://arxiv.org/pdf/1901.07329.pdf

https://www.youtube.com/watch?v=4-4pKPv9lJ4