Базовые траты в Нидерландах
#life #career #netherlands

Посчитаем грошики-шекелёчки, поноем, это все любят. Есть, конечно, Numbeo, но лишний датапойнт про цену жизни в Нидерландах, возможно, вам не помешает. Как рассказать о своей зарплате, не называю цифру? Легко. Я вам примерно распишу расходы на жизнь в Нидерландах и скажу, что у меня все впритык, от зп к зп (ага, с финансовой грамотностью пока так себе выходит). По крайне мере, когда я в 2018 услышал, сколько мне предлагают в Нидерландах, мне казалось, буду в золоте купаться. На деле все оказалось не так радужно. Так что возможно, пост поможет тем, кто приценивается к жизни в NL.

Допустим, в семье работает один человек и получает 5к евро/месяц чистыми (что примерно соответствует гроссу в 75к с рулингом или 100к - без него. Рулинг - это налоговая поблажка на первые 5 лет, когда 30% дохода не облагается налогом). Более точно можно прикинуть на thetax.nl. Не совсем моя ситуация, но пойдет для бейзлайна. Оговорок много (что если оба работают, есть дети или нет, свое жилье или аренда) – это можно в коменты перенести.

Обязательные расходы (т.е. исключая еду/кафе/etc) у меня ~2500. Каждый грош считать не хочется, но основное, из того что больше 100 евро/месяц:

- 1300 – ипотека
- 400 – медстраховка на двоих
- 200 – транспорт на двоих
- 140 – коммунальные налоги
- 120 – электричество/газ
- ~350 – остальное (связь, инет, прочие страховки, и т.д.)

Немного прокомментировать все же надо, хотя главный вывод – в конце поста.

- Ипотека за 1300 это прям дико удачно, успел ухватить ставку 1.8%, сейчас она ближе к 4.5% и соотв-но, ежемесячный платеж легко может быть и 2к и 3к, ажиотаж с жильем бешеный, особенно в Амстере
- медстраховка дорогая, и тут сэкономить особо не выйдет, помимо ~150/чел в месяц еще 360/год – собственный риск, то есть 360 платишь сам, а что свыше – уже покрывается. Плюс зубы отдельно, легко выходит 200 евро в месяц на человека. К слову, голландские врачи настолько дорогие, что на оплату их труда уходит ~30% подоходных налогов, помимо отчислений на медстраховку
- транспорт дорогой, к примеру, поезда катаются на чистом электричестве от ветрогенераторов. Где-то видел статью, что в NL самый дорогой транспорт с нормировкой на уровень доходов – похоже на правду
- коммуналка – это налог собственника жилья (неактуально, если снимаете), а также на мусор, канализацию и проч
- электричество/газ – ну тут, понятное дело, отказ от fcukn russian gas сильно все цены повысил

И вот, допустим, остается еще 2500/мес на еду, кафе, шмотки, путешествия и прочую жизнь. Хм… 80 евро в день? Вы уже видите, что так недолго превратиться в бомжа, живущего в красивой обстановке. Ну и начать жить по-голландски, то есть экономить – ходить в Lidl и jumbo, а не Albert Heijn, нагибаться рачком за более дешевыми товарами на нижних полках, ходить в кафе раз в месяц, не есть рыбу/мясо. В-общем, это все не про меня. К слову, наиболее характерное голландское слово, передающее менталитет – goedkoop (дешевый) - только дословно это не “дешевый” или ”cheap” (негативный посыл), а “выгодно купленный” (явно позитивный посыл). Про это еще разверну мысль #todo

В итоге если в семье работает один, то рассматривать что-то меньшее 75к/год (с учетом рулинга) я бы не советовал. Когда рулинга уже нет – это вообще другая история, требующая кардинально новых решений, о которых, надеюсь, получится вскоре рассказать.

А если хочется путешествовать и вообще-то думать про старость и откладывать – то и подавно надо сразу смотреть на 100к+. Либо, конечно, вдвоем работать.

#ensembling #featureselection #papers #todo

Ensemble Selection from Libraries of Models
Rich Caruana, Alexandru Niculescu-Mizil, Geoff Crew, Alex Ksikes

Простой метод ансамблирования 20-летней давности, возможно, незаслуженно обделённый вниманием. (Именно его авторы auto-sklearn отмаечают как превосходящий по качеству стэкинг.)

"We present a method for constructing ensembles from libraries of thousands of models. Model libraries are generated using different learning algorithms and parameter settings.

Forward stepwise selection is used to add to the ensemble the models that maximize its performance.

Ensemble selection allows ensembles to be optimized to performance metric such as accuracy, cross entropy, mean precision, or ROC Area. Experiments with seven test problems and ten metrics demonstrate the benefit of ensemble selection."

Что удивительно, есть прямая параллель между выбором "артистов" в ансамбль и ... просто выбором признаков в одиночную модель. Только, в отличие от последнего, качество ансамбля подсчитать можно очень быстро (это же усреднение предсказаний), не надо (пере)обучать потенциально медленную модель.

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

Находкой авторов, видимо, стоит считать выбор кандидатов с возвращением, когда вхождение модели в ансамбль может рассматриваться неоднократно, причём на разных этапах (эквивалент веса):

"Selection with replacement flattens the curve so much that a test set is not needed to determine when to stop adding models to the ensemble. The hillclimbing set can be used to stop hillclimbing. This means ensemble selection does not need more test sets than the base-level models would have used to select model parameters. Ensemble selection uses the validation set to do both parameter and model selection."

Что ещё очень интересно, для борьбы с оверфитом валидационного множества они вводят 50%-ный бэггинг моделей, но повторяют всю процедуру построения ансамбля 20 раз, так что итоговое решение - это среднее 20 ансамблей 🤪

Глядя на таблицу результатов, кажется, что стэкинг они реализовали неправильно, ну не может он быть таким плохим. Вот как они это объясняют:
"Stacking (Wolpert, 1992) with logistic regression performs poorly because regression overfits dramatically when there are 2000 highly correlated input models and only 1k points in the validation set."
Видимо, отсюда и проблемы, ведь стэкинг лучше делать на CV, а не на одном множестве.

Ко всей методологии сравнения у меня есть 1 большая претензия: похоже, что все тестовые множества были сгенерированы 1 раз. Ну не серьёзно. Я понимаю, что и так объём вычислений был большой, но... (

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

Я постараюсь повторить это исследование в рамках создания своего тюнера Diogenes, с бОльшим количеством HP-шек на модель, более современными моделями, метриками включающими и "резкость" и калибрацию, бОльшим количеством альтернативных методов ансамблирования.

Интересно, а если полностью затюнить ансамбль сначала на одну, потом на другую метрику, получится ли улучшить обе, как обсуждалось ранее?

Попросил "размышляющие" версии AI проанализировать интересные аспекты и слабости статьи. Deepseek R1 справилась куда лучше OpenAI O3-mini. Gemini 2.0 жёстко галлюцинировала.

https://www.cs.cornell.edu/~alexn/papers/shotgun.icml04.revised.rev2.pdf

#books #kagglebook #interviews #todo

Jean-François Puget

I like competitions with a scientific background, or a background I can relate to. I dislike anonymous data and synthetic data, unless the data is generated via a very precise physics simulation. More generally, I like Kaggle competitions on domains I don’t know much about, as this is where I will learn the most. It is not the most effective way to get ranking points, but it is the one I entertain most.

What I often do is plot samples using two features or derived features on the x and y axis, and a third feature for color coding samples. One of the three features can be the target. I use lots of visualization, as I believe that human vision is the best data analysis tool there is.

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

Hyperparameter tuning is one of the best ways to overfit, and I fear overfitting a lot.

Kazuki Onodera

-In your experience, what do inexperienced Kagglers often overlook?
-Target analysis.

-What mistakes have you made in competitions in the past?
-Target analysis. Top teams always analyze the target better than others.

Xavier Conort

-Tell us about a particularly challenging competition you entered, and what insights you used to tackle the task.

-My favorite competition is GE Flight Quest, a competition organised by GE where competitors had to predict arrival time of domestic flights in the US.

I was very careful to exclude the name of the airport from my primary feature lists. Indeed, some airports hadn’t experienced bad weather conditions during the few months of history. So, I was very concerned that my favorite ML algorithm, GBM, would use the name of the airport as a proxy for good weather and then fail to predict well for those airports in the private leaderboard. To capture the fact that some airports are better managed than others and improve my leaderboard score slightly, I eventually did use the name of the airport, but as a residual effect only. It was a feature of my second layer of models that used as an offset the predictions of my first layer of models. This approach can be considered a two-step boosting, where you censor some information during the first step. I learnt it from actuaries applying this approach in insurance to capture geospatial residual effects.

I would advise inexperienced Kagglers not to look at the solutions posted during the competition but to try to find good solutions on their own. I am happy that competitors didn’t share code during the early days of Kaggle. It forced me to learn the hard way.

-What mistakes have you made in competitions in the past?
-One mistake is to keep on competing in competitions that are badly designed with leaks. It is just a waste of time. You don’t learn much from those competitions.

-What’s the most important thing someone should keep in mind or do when they’re entering a competition?
-Compete to learn. Compete to connect with other passionate data scientists. Don’t compete only to win.

Chris Deotte

I enjoy competitions with fascinating data and competitions that require building creative novel models.
My specialty is analyzing trained models to determine their strengths and weaknesses. Feature engineering and quick experimentation are important when optimizing tabular data models. In order to accelerate the cycle of experimentation and validation, using NVIDIA RAPIDS cuDF and cuML on GPU are essential.

Laura Fink

My favorite competitions are those that want to yield something good to humanity. I especially like all
healthcare-related challenges.

#books #kagglebook #todo

Теперь пройдёмся по основному контенту и поглядим, чего там было интересного.

Custom losses in boosting

If you need to create a custom loss in LightGBM, XGBoost, or CatBoost, as indicated in their respective documentation, you have to code a function that takes as inputs the prediction and the ground truth, and that returns as outputs the gradient and the hessian. Подумал, что хорошо бы учесть разные лоссы при написании свего тюнера гиперпараметров.

From a code implementation perspective, all you have to do is to create a function, using closures
if you need to pass more parameters beyond just the vector of predicted labels and true labels.

Here is a simple example of a focal loss (a loss that aims to heavily weight the minority class in
the loss computations as described in Lin, T-Y. et al. Focal loss for dense object detection: https://
arxiv.org/abs/1708.02002) function that you can use as a model for your own custom functions:

from scipy.misc import derivative
import xgboost as xgb

def focal_loss(alpha, gamma):
    def loss_func(y_pred, y_true):
        a, g = alpha, gamma

        def get_loss(y_pred, y_true):
            p = 1 / (1 + np.exp(-y_pred))
            loss = (
                -(a * y_true + (1 - a) * (1 - y_true))
                * ((1 - (y_true * p + (1 - y_true) * (1 - p))) ** g)
                * (y_true * np.log(p) + (1 - y_true) * np.log(1 - p))
            )
            return loss

        partial_focal = lambda y_pred: get_loss(y_pred, y_true)
        grad = derivative(partial_focal, y_pred, n=1, dx=1e-6)
        hess = derivative(partial_focal, y_pred, n=2, dx=1e-6)
        return grad, hess

    return loss_func


xgb = xgb.XGBClassifier(objective=focal_loss(alpha=0.25, gamma=1))

In the above code snippet, we have defined a new cost function, focal_loss, which is then fed into an XGBoost instance’s object parameters. The example is worth showing because the focal loss requires the specification of some parameters in order to work properly on your problem (alpha and gamma). The more simplistic solution of having their values directly coded into the function is not ideal, since you may have to change them systematically as you are tuning your model. Instead, in the proposed function, when you input the parameters into the focal_loss function, they reside in memory and they are referenced by the loss_func function that is returned to XGBoost. The returned cost function, therefore, will work, referring to the alpha and gamma values that you have initially instantiated.

Another interesting aspect of the example is that it really makes it easy to compute the gradient and the hessian of the cost function by means of the derivative function from SciPy. If your cost function is differentiable, you don’t have to worry about doing any calculations by hand. However, creating a custom objective function requires some mathematical knowledge and quite a lot of effort to make sure it works properly for your purposes. You can read about the difficulties that Max Halford experienced while implementing a focal loss for the LightGBM algorithm, and how he overcame them, here: https://maxhalford.github.io/blog/lightgbm-focal-loss/. Despite the difficulty, being able to conjure up a custom loss can really determine your success in a Kaggle competition where you have to extract the maximum possible result from your model.

#books #kagglebook #todo

Metrics

what you care the most about when using RMSLE is the scale of your predictions with respect
to the scale of the ground truth.

By far, at the moment, RMSLE is the most used evaluation metric for regression in Kaggle competitions.


In terms of downside, using MAE as an objective function results in much slower convergence, since you are actually optimizing for predicting the median of the target (also called the L1 norm),
instead of the mean (also called the L2 norm), as occurs by MSE minimization. This results in more complex computations for the optimizer, so the training time can even grow exponentially
based on your number of training cases (see, for instance, this Stack Overflow question: https://stackoverflow.com/questions/57243267/why-is-training-a-random-forest-regressorwith-mae-criterion-so-slow-compared-to).

Dimensionality reduction

t-SNE and UMAP are two techniques, often used by data scientists, that allow you to project multivariate data into lower dimensions. They are often used to represent complex sets of data in two dimensions. 2-D UMAP and t-SNE plots can reveal the presence of outliers and relevant clusters for your data problem.

In fact, if you can plot the scatter graph of the resulting 2-D projection and color it by target value, the plot may give you hints about possible strategies for dealing with subgroups. You can find a useful example of applying both UMAP and t-SNE with a RAPIDS implementation and a GPU for data exploration purposes.

t-SNE/UMAP надо тоже использовать (как препроцессоры) при написании "умного" оптимизатора гиперпараметров

Pseudo-labeling

In competitions where the number of examples used for training can make a difference, pseudo-labeling can boost your scores by providing further examples taken from the test set. The idea is to add examples from the test set whose predictions you are confident about to your training set.

Unfortunately, you cannot know for sure beforehand whether or not pseudo-labeling will work in a competition (you have to test it empirically), though plotting learning curves may provide you with a hint as to whether having more data could be useful.

#books #kagglebook #noise #augmentaion #todo

Denoising with autoencoders

In his famous post (https://www.kaggle.com/c/porto-seguro-safe-driver-prediction/ discussion/44629), Michael Jahrer describes how a DAE can not only remove noise but also automatically create new features, so the representation of the features is learned in a similar way to what happens in image competitions. In the post, he mentions the secret sauce for the DAE recipe, which is not simply the layers, but the noise you put into the data in order to augment it. He also made clear that the technique requires stacking together training and test data, implying that the technique would not have applications beyond winning a Kaggle competition.

In order to help train any kind of DAE, you need to inject noise that helps to augment the training data and avoid the overparameterized neural network just memorizing inputs (in other words, overfitting). In the Porto Seguro competition, Michael Jahrer added noise by using a technique called swap noise, which he described as follows: Here I sample from the feature itself with a certain probability “inputSwapNoise” in the table above. 0.15 means 15% of features replaced by values from another row.

What is described is basically an augmentation technique called mixup (which is also used in image augmentation: https://arxiv.org/abs/1710.09412). In mixup for tabular data, you decide a probability for mixing up. Based on that probability, you change some of the original values in a sample, replacing them with values from a more or less similar sample from the same training data.

Большой вопрос, на который нет ответа - почему аугментации всегда используются в задачах машинного зрения, и никогда - в табличных данных? А ведь это отличный метод создания diversity. Нужно исследование.

Neural networks for tabular competitions

Use activations such as GeLU, SeLU, or Mish instead of ReLU; they are quoted in quite a few papers as being more suitable for modeling tabular data and our own experience confirms that they tend to perform better.

Use augmentation with mixup (discussed in the section on autoencoders).
Use quantile transformation on numeric features and force, as a result, uniform or Gaussian distributions.

Leverage embedding layers, but also remember that embeddings do not model everything. In fact, they miss interactions between the embedded feature and all the others (so you have to force these interactions into the network with direct feature engineering).

Remember that embedding layers are reusable. In fact, they consist only of a matrix multiplication that reduces the input (a sparse one-hot encoding of the high cardinality variable) to a dense one of lower dimensionality. By recording and storing away the embedding of a trained neural network, you can transform the same feature and use the resulting embeddings in many other different algorithms, from gradient boosting to linear models.

#hpo #hpt #ensembling #diogenes #todo #metalearning

Работаю над планом создания своего тюнера гипер-параметров для библиотеки Diogenes, в том числе, формализацией процесса сбора мета-признаков.

Цели тюнера

1) простая. для конкретного датасета/таргета и ML-алгоритма, порекомендовать гиперпараметры, которые дадут лучшие (и стабильные) метрики на CV

2) посложнее. для конкретного датасета/таргета порекомендовать ML-алгоритмы с гиперпараметрами, которые дадут лучшие результаты в ансамбле

3) сложная. для конкретного датасета/таргета порекомендовать лучшие пре-, пост-процессинг (и признаков, и таргета), фиче инжиниринг, и ML-алгоритмы с гиперпараметрами для последующего ансамблирования.

Предпосылка в том, что для данного датасета (признаков) и таргета, задачи и ML алгоритма, зависимость достигнутых ML метрик от гиперпараметров алгоритма не случайна и может быть выучена/смоделирована с помощью мета-обучения. Она подтверждается моим feasibility study на базе датасета openml, да и работой авторов TabPFN.

Простой пример, чего я хочу достигнуть в задаче 1:

LTV regression where target is bimodally distributed. Tuner should recommend using Lgbm with a Tweedie loss.
https://youtu.be/qGsHlvE8KZM?t=1139

Подход, соответственно, заключается в сборе мета-датасета, когда на множестве задач обучается большое число кандидатов с разными HP, и в процессе работы с новым датасетом интеллектуальная мета-модель рекомендует "хороших" кандидатов, что должно повышать качество решения при сокращении затрат времени.

Наверное, разумно начать решение с задачи 2 (автоматически решая задачу 1). Задачу 3 можно попытаться решать позже модификацией задачи 2, когда случайным образом добавляется определённый препроцессинг, и старый алгоритм сбора мета-признаков отрабатывает уже по изменённым данным.

Неизвестно, можно ли вообще будет предсказывать хороший препроцессинг, вполне может быть, что общим решением задачи 3 будет просто случайная генерация препроцессингов и уже направленное обучение ансамблей тюнером из задачи 2. Но в этом случае надо хотя бы сформировать мета-признаки для задачи 2 с помощью разных препроцессингов хотя бы для некоторых датасетов, что само по себе крайне ресурсоёмкая задача.

Крутые "фишки" тюнера, которых ни у кого (вроде) пока нет, а у меня будут:

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

2) гибкая мультикритериальность - можно будет не просто получить Парето-фронт по, скажем, ROC AUC и затем F-score, но и указать, какой % от первичной метрики мы готовы променять на какой % от вторичной (и т.д.). К примеру, мы предпочитаем 3% роста F-меры (вторичной метрики) 1% роста ROC AUC (первичной метрики). Хотя, может, проще будет просто дать возможность задать веса метрик в абсолютной или нормализированной шкалах, и потом просто оптимизировать линейную комбинацию (скаляр).

3) заточенность под будущее ансамблирование, в плане стремления к разнообразности предсказаний (diversity)

4) детальное планирование затрат времени и загруженности железа, составление оптимального плана эксперимента с учётом ограничений

5) глубокое знание ВСЕХ гиперпараметров каждого алгоритма. Нет универсальности, да глубокой компетенции.

#hpo #hpt #ensembling #diogenes #todo #metalearning

Требования к тюнеру:

В реальных задачах есть конкретное железо и бюджет времени на обучение. Соответственно, планировщик должен понимать, какое время займёт обучение каждого кандидата и сколько потребует ресурсов (RAM, VRAM, диска для хранения модели). В идеале, если пользователь задал совсем жёсткое ограничение, планировщик должен рассчитать сэмплирование и обучить одну "предполагаемую лучшую" модель на этом сэмпле, использовав (почти) всё отведённое время.

То есть, от кандидатов надо собирать не только достигнутые на CV разнообразные ML-метрики, но и затраченные ресурсы CPU, GPU, памяти, диска. (add resulting model size as a factor. in xgboost, max_cat_threshold must be varied btw 0 and max cat features cardinality! # affects model size heavily when high cardinality cat features r present! ADD HIGH CARD dataset to the testing suite!)

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

Значит, мета-модель должна прогнозировать среднюю "непохожесть" ответов кандидата на ответы всех остальных кандидатов (хотя бы внутри группы данного алгоритма).
Тут есть тонкий момент, навеянный идеями ensemble selection: возможно, ещё надо пытаться прогнозировать, сможет ли данный кандидат составить "лучшее в группе простое усреднение" с каким-то другим кандидатом. Типа, можно быть довольно похожим на остальных, но вот прям засиять с кем-то в паре.

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

Учёт multi-fidelity. Если данные представлены таблицей с миллионами строк, конечно, нет смысла тестировать всех кандидатов на полном датасете. В идеале "пристрелку" хорошо бы вести на более разумном сэмпле, скажем, 10k, ну или хотя бы 100k строк. Но тогда надо понимать, а как для одних и тех же HP соотносятся результаты на полной и уменьшенных версиях датасета, и можно ли последние использовать для оценки первых (непосредственно в виде рангов, или через отдельную ML-модель).

Значит, при сборе мета-признаков надо их собирать как для полного датасета, так и для его "уменьшенных копий", при точно тех же HP (сэмплирование надо фиксировать для воспроизводимости).

#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, на каких-то разумных настройках глубины/сложности/времени. И датасетах с в т.ч. большим количеством фичей.

#timeseries #ensembling #todo #hetboost

Что мне тут нравится, ансамблируются не просто МЛ-модельки, а еще и статмодельки.

И вот здесь автора доклада рассматривает идею, которая и меня с недавних пор преследует: гетерогенный бустинг.

У меня планируется исследование/сравнение продвинутых методов ансамблирования, и даже есть идея своего метода.
Это будет микс гетерогенного бустинга, ансамблевого отбора и стэкинга.

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

#timeseries #ensembling #hetboost #pmdarima #todo

Вот попался классный пример, где идея "гетерогенного бустинга" отлично отрабатывает.

Лектор на синтетике сравнивает ариму и ансамбль линрег+дерево.

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

В то же время, сейчас самыми распространёнными методами ансамблирования являются стэкинг (когда для моделей последующего уровня меняется признаковое пространство) и гомогенный бустинг (например, градиентный над деревьями в catboost/xgboost/lightgbm), а вот идею бустинга гетерогенного как будто никто и не рассматривает, и как будто бы нет опенсорсных реализаций.

Истоки такого предубеждения, похоже, растут из ранних статей о бустинговом подходе над "слабыми моделями" (weak learners). Выбор именно слабых моделей аргументировался контролем переобучения, равномерностью шагов процесса обучения, фокусом на сложных для предсказания примерах (которые более сильная модель могла бы просто запомнить).

Мне кажется, "слабость" и одинаковость участников ансамбля не всегда благо, и на практике есть смысл в каждой конкретной задаче проверять (на CV) наиболее выгодный подход к ансамблированию, от простого усреднения моделей и ensemble selection (который мы недавно рассматривали) до стэкинга и двух видов бустинга, одно- и разнородного.

На этот год планирую сравнительное исследование )

Видимо, относительно небольшая статья о том, как стать лучше в DS, которую я подготовил, столкнувшись с неспособностью современных библиотек градиентного бустинга хорошо смоделировать простую зависимость Y=X, вырастет в большое сравнение алгоритмов ансамблирования.

Постараюсь захватить Ensemble Selection (1, 2, 3), опции ансамблирования рассмотренные в #kagglebook (1, 2, 3), и Cascade Generalization/Cascading/Delegating (or Selective Routing)/Arbitrating.