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

The Kaggle Book by Konrad Banachewicz and Luca Massaron

Millions of data enthusiasts from around the world compete on Kaggle, the most famous data science competition platform of them all. Participating in Kaggle competitions is a surefire way to improve your data analysis skills, network with an amazing community of data scientists, and gain valuable experience to help grow your career.

The first book of its kind, The Kaggle Book assembles in one place the techniques and skills you'll need for success in competitions, data science projects, and beyond. Two Kaggle Grandmasters walk you through modeling strategies you won't easily find elsewhere, and the knowledge they've accumulated along the way. As well as Kaggle-specific tips, you'll learn more general techniques for approaching tasks based on image, tabular, textual data, and reinforcement learning. You'll design better validation schemes and work more comfortably with different evaluation metrics.

Whether you want to climb the ranks of Kaggle, build some more data science skills, or improve the accuracy of your existing models, this book is for you.

Link: Book

Navigational hashtags: #armknowledgesharing #armbooks
General hashtags: #ml #machinelearning #featureengineering #kaggle #metrics #validation #hyperparameters #tabular #cv #nlp

@data_science_weekly

#gplearn #featureengineering #pysr #symbolicregression

Классная идея! Подбор формул позволяет (пере)открыть законы мироздания )

https://medium.com/data-science-collective/find-hidden-laws-within-your-data-with-symbolic-regression-ebe55c1a4922

#featureengineering #pysr #symbolicregression

На самом деле, подход символьной регрессии перекликается с моей идеей использования информационно-теоретических метрик.

Читаю сейчас статью pysr, у них интересный подход с генетиком над признаками, отобранными бустингом.

Очень хочу сравнить их результаты со своими на том же игрушечном примере.

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

Ps. ДА! pysr отлично справился с моим примером!

import numpy as np, pandas as pd

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 pysr import PySRRegressor

model = PySRRegressor(
    maxsize=20,
    niterations=40,  # < Increase me for better results
    binary_operators=["+", "*"],
    unary_operators=[
        "cos",
        "exp",
        "log",
        "sin",
        "inv(x) = 1/x",
        # ^ Custom operator (julia syntax)
    ],
    extra_sympy_mappings={"inv": lambda x: 1 / x},
    # ^ Define operator for SymPy as well
    elementwise_loss="loss(prediction, target) = (prediction - target)^2",
    # ^ Custom loss function (julia syntax)
)

model.fit(df, y)

model.get_best()

после ~6 минут работы

complexity 14
loss 0.003329
score 0.947915
sympy_format a**2/b + log(c)*sin(d) + 0.09998281

#featureengineering #pysr #symbolicregression #todo

Библиотека pysr заслуживает пристального внимания. Она настолько хорошо сделана, глубока и функциональна, что просто загляденье.

Полностью готова к внедрению в бой, поддерживает оптимизации, кластера, логгинг в тензорборд, пре-отбор признаков с помощью ML, сохранение прогресса в файл и тёплый старт.

Зацените функциональность и количество опций:

model = PySRRegressor(
    populations=8,
    # ^ Assuming we have 4 cores, this means 2 populations per core, so one is always running.
    population_size=50,
    # ^ Slightly larger populations, for greater diversity.
    ncycles_per_iteration=500,
    # ^ Generations between migrations.
    niterations=10000000,  # Run forever
    early_stop_condition=(
        "stop_if(loss, complexity) = loss < 1e-6 && complexity < 10"
        # Stop early if we find a good and simple equation
    ),
    timeout_in_seconds=60 * 60 * 24,
    # ^ Alternatively, stop after 24 hours have passed.
    maxsize=50,
    # ^ Allow greater complexity.
    maxdepth=10,
    # ^ But, avoid deep nesting.
    binary_operators=["*", "+", "-", "/"],
    unary_operators=["square", "cube", "exp", "cos2(x)=cos(x)^2"],
    constraints={
        "/": (-1, 9),
        "square": 9,
        "cube": 9,
        "exp": 9,
    },
    # ^ Limit the complexity within each argument.
    # "inv": (-1, 9) states that the numerator has no constraint,
    # but the denominator has a max complexity of 9.
    # "exp": 9 simply states that `exp` can only have
    # an expression of complexity 9 as input.
    nested_constraints={
        "square": {"square": 1, "cube": 1, "exp": 0},
        "cube": {"square": 1, "cube": 1, "exp": 0},
        "exp": {"square": 1, "cube": 1, "exp": 0},
    },
    # ^ Nesting constraints on operators. For example,
    # "square(exp(x))" is not allowed, since "square": {"exp": 0}.
    complexity_of_operators={"/": 2, "exp": 3},
    # ^ Custom complexity of particular operators.
    complexity_of_constants=2,
    # ^ Punish constants more than variables
    select_k_features=4,
    # ^ Train on only the 4 most important features
    progress=True,
    # ^ Can set to false if printing to a file.
    weight_randomize=0.1,
    # ^ Randomize the tree much more frequently
    cluster_manager=None,
    # ^ Can be set to, e.g., "slurm", to run a slurm
    # cluster. Just launch one script from the head node.
    precision=64,
    # ^ Higher precision calculations.
    warm_start=True,
    # ^ Start from where left off.
    turbo=True,
    # ^ Faster evaluation (experimental)
    extra_sympy_mappings={"cos2": lambda x: sympy.cos(x)**2},
    # extra_torch_mappings={sympy.cos: torch.cos},
    # ^ Not needed as cos already defined, but this
    # is how you define custom torch operators.
    # extra_jax_mappings={sympy.cos: "jnp.cos"},
    # ^ For JAX, one passes a string.
)

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

И хорошо бы её потестить для FE, на каких-то разумных настройках глубины/сложности/времени. И датасетах с в т.ч. большим количеством фичей.

#trading #chan #featureengineering

Понравилась идея превращения cs фичей в ts путём формирования синтетического портфеля из активов, отранжированных по cs признаку. Трейдерские метрики такого портфеля уже можно (путём взятия rolling stats) превратить во временнЫе (ts) признаки.

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

https://www.youtube.com/watch?v=6J9iaXNpCN8