#ml #featureengineering #geofeatures #advicewanted

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

Пока что нашел вот такую прекрасную серию статей

https://towardsdatascience.com/graph-machine-learning-with-python-pt-1-basics-metrics-and-algorithms-cc40972de113

https://towardsdatascience.com/graph-machine-learning-with-python-part-3-unsupervised-learning-aa2854fe0ff2

https://towardsdatascience.com/graph-machine-learning-with-python-part-4-supervised-semi-supervised-learning-d66878161b79

#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:
- http://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

Google Machine Learning Education

Learn to build ML products with Google's Machine Learning Courses.

Foundational courses
The foundational courses cover machine learning fundamentals and core concepts. They recommend taking them in the order below.

1. Introduction to Machine Learning
A brief introduction to machine learning.
2. Machine Learning Crash Course
A hands-on course to explore the critical basics of machine learning.
3. Problem Framing
A course to help you map real-world problems to machine learning solutions.
4. Data Preparation and Feature Engineering
An introduction to preparing your data for ML workflows.
5. Testing and Debugging
Strategies for testing and debugging machine learning models and pipelines.

Advanced Courses
The advanced courses teach tools and techniques for solving a variety of machine learning problems. The courses are structured independently. Take them based on interest or problem domain.

- Decision Forests
Decision forests are an alternative to neural networks.
- Recommendation Systems
Recommendation systems generate personalized suggestions.
- Clustering
Clustering is a key unsupervised machine learning strategy to associate related items.
- Generative Adversarial Networks
GANs create new data instances that resemble your training data.
- Image Classification
Is that a picture of a cat or is it a dog?
- Fairness in Perspective API
Hands-on practice debugging fairness issues.

Guides
Their guides offer simple step-by-step walkthroughs for solving common machine learning problems using best practices.

- Rules of ML
Become a better machine learning engineer by following these machine learning best practices used at Google.
- People + AI Guidebook
This guide assists UXers, PMs, and developers in collaboratively working through AI design topics and questions.
- Text Classification
This comprehensive guide provides a walkthrough to solving text classification problems using machine learning.
- Good Data Analysis
This guide describes the tricks that an expert data analyst uses to evaluate huge data sets in machine learning problems.
- Deep Learning Tuning Playbook
This guide explains a scientific way to optimize the training of deep learning models.

Link: https://developers.google.com/machine-learning?hl=en

Navigational hashtags: #armknowledgesharing #armcourses
General hashtags: #machinelearning #ml #google #course #courses #featureengineering #recsys #clustering #gan

@data_science_weekly

#teasers #featureengineering

И ещё новости. Пока не получается опубликовать детали, но я работаю над новым крутым методом feature engineering, который ещё нигде не применяется. О нём узнают (практически) только подписчики канала.

Без смс и регистрации ) Так что stay tuned!

#featureengineering #featureselection #diogenes

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

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 метриках, или же ведут к оверфиту.