#featureselection

В дополнение к посту. Потестировал много вариантов улучшения исходной идеи:

1) усреднение значений Шэпли нескольких типов (с разными feature_perturbation)
2) усреднение значений Шэпли нескольких разных моделей
3) использование парных интеракций (shap_interaction_values)
4) мета-модель ML: зная индексы выбранных в комбинацию признаков и оставшихся признаков, а также честные предсказания моделек, давайте попробуем создать как мета-признаки ряд простых числовых агрегатов от шепли-значений (суммы, средние, отклонения, мин/макс и тп). ну и уже от этого мета-модель, вдруг она будет точнее чем исходная простая идея просуммировать значения Шепли выбранных в комбинацию признаков?

Находки/открытия:

1) не существует работающей реализации Shap на GPU (GPUTreeExplainer из пакета shap нерабочий, и всем похер. По идее он должен ставиться с xgboost (без shap), но он всё равно не юзает gpu, я проверял.)
2) KernelExplainer непроходимо медленен, забудьте про его использование. Речь о сотнях часов даже на небольшом датасете.
3) некоторые модели (lightgbm) считают интеракции в один поток и очень медленно (~40 минут на 100k x 20 датасете)
4) некоторые бустинги (Catboost) раздувают expected_value так, что они не просто не сходятся точно к среднему прогнозу, а превышают его вдвое. При этом внутренняя проверка shap на аддитивность проходит! ХЗ как это возможно. У других бустингов тоже такое наблюдалось, но хотя бы с гораздо меньшей амплитудой. В режиме feature_perturbation="tree_path_dependent" такого никогда не наблюдал.
5) Режим feature_perturbation="interventional" требует теневого датасета и считает значения Шэпли на порядки дольше, но ничего не даёт к точности.
6) xgboost (и только он) поддерживает доп параметр approximate=True, который отрабатывает быстрее, но реально роняет качество. его использовать не надо.
7) документация shap по-прежнему дырявая (параметры объясняльщика, которые ничего не делают, например), а на гитхабе никто по-прежнему не отвечает и не отрабатывает сигналы и проблемы юзеров. не понимаю, как они при этом релизят новые версии, скорее всего, это в основном переписывания исходного говнокода Скотта Ландберга.

Ну и самое главное, по поводу аппроксимации честных прогнозов шэпли-значениями.

1) все виды бустингов и все виды объясняльщиков для нашей задачи имеют примерно одинаковое качество (если не использовалось approximate=True)
2) усреднения ничего особо не меняют.
3) метамодель существенно улучшает линейную (да и другие) корреляцию, но особо не меняет метрики ранжирования комбинаций (которые и так на удивление хороши).
4) при небольшой по размеру группе кандидатов на удивление ранжирующие свойства сильно не падают.

#featureselection

Вот внесэмпловые метрики XGBRegressor feature_perturbation=tree_path_dependent, approximate=False из предыдущего поста.

meta=мета-моделька, naive это просто сумма шэпли-значений как у автора идеи, adjusted это naive минус сумма шэпли-значений признаков не вошедших в комбинацию.

Считалось на датасете poker (10 исходных признаков + 5 фейковых случайных + 5 коррелированных с исходными). Помимо 2 видов ndgc (rel/abs), грубыми, но выразительными метриками были top_recall@k. Например, чтобы посчитать recall@10, брались 10 лучших (согласно честными прогнозам) на test комбинаций, и проверялось, сколько из них оказались в 10 лучших по версии того или иного метода.

В целом, для данной задачи нет смысла морочиться с мета-моделью, надо просто брать наивный оригинальный метод автора, и feature_perturbation="tree_path_dependent".

#featureselection #shap

Ну и теперь к практической реализации отборщика признаков на основе этой прекрасной идеи. Как это вообще сделать?

Обучать одну большую модель на всех признаках надо обязательно. Это, по счастливому совпадению, 1-й шаг всех RFE-* методов.
Далее получаем "простые" кэфы Шэпли самым быстрым (но не приближённым) методом. По желанию усредняем на CV.

И тут открывается простор для фантазии:

Полный брутфорс:

Генерим все 2^n_features сочетаний признаков, сортируем индексы признаков в сочетаниях.
суммируем шэпли-значения 1й комбинации. далее удаляем суммы убывших, прибавляем суммы прибывших в комбинацию признаков. раз в N итераций ресет суммы, чтобы сбросить накопленную ошибку суммирования.

Генетик:

Вектор 1/0 длины n_features генов - это особь популяции, её фитнесс оценивать мы умеем (суммируя его шэпли-значения и считая от них и ground truth нашу ml-метрику).
применяем направленный поиск путём скрещивания, мутаций, и прочего элитизма. Запускаем эволюцию, играем в Создателя, смеёмся страшным голосом mwa-ha-ha.

Любая другая эвристика, типа имитации отжига:

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

Градиентный поиск:

Ну да, это ж бинарный вектор, нет непрерывности, как по нему дифференцировать? Есть идея применить "признаки Шрёдингера"! ))
А именно, размазать их бинарность с помощью весового коэффициента. Они могут как бы входить, а как бы и нет в комбинацию с определённым весом. А чтобы вес в итоге ограничивался промежутком [0,1], к нему можно применить сигмоиду. Тем самым autograd-оптимизатор по идее сможет найти экстремумы ML-метрики, плавно включив/исключив признаки из комбинации.

А если итоговая ML-метрика недифференцируема (типа ROC, PR AUC)? Ну тогда ведь можно взять Brier score или какую-то подходящую прокси.
Уже есть набросок кода для pytorch, попробую затестить.

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

В любом случае, надо дать методу оптимизации поработать (в рамках бюджета времени), и получить от него топ-N лучших кандидатов. А их уже "честно" проверить (в оставшееся время) на insample CV и вернуть самую лучшую/устойчивую комбинацию признаков.

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

#databases #cache #redis


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

#fun

Вот как надо перемещаться по элеваторам )

https://www.youtube.com/shorts/eDkScjKYotI

#python #cleancode #codegems

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

Annotated это вообще перебор, мне кажется. А вот с возвратом понятно именованной переменной - совет хороший.

Про сложность Halstead не слышал.

Про Legacy раздел не согласен. Меня вот тошнит от Pathlib, и я предпочитаю os.path. Какого хрена всякие индюки объявляют прекрасно работающий пакет legacy? Да ещё и в линтеры типа ruff добавляют избавление от "легаси" как правила.

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

Вопрос из зала про быстрый MVP и целесообразность чистого кода в нём хорош!

https://www.youtube.com/watch?v=2m8u_QwTaQQ

#boostings #mlgems

В процессе сравнения методов FS я словил когнитивный диссонанс. Уже энное количество лет я думал, что градиентные бустинги над деревьями - это прямо панацея для табличных данных, и всегда по дефолту использовал их.

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

Только недавно я стал исследовать возможность и эффекты добавления альтернативных классов моделей в ансамбль.

Плюс, в моих DS проектах обычно не хватало времени и/или бюджета на тюнинг гиперпараметров, и я так с потолка оценивал эффект от HPT в +- 10% - nice to have, но не критично.

Всем, кто в опросе выше выбрал 1-й вариант, я советую запустить вот такой простой пример:

import numpy as np, pandas as pd
from lightgbm import LGBMRegressor
from catboost import CatBoostRegressor
from sklearn.metrics import root_mean_squared_error


X=np.random.normal(0,9,size=(10_000,3)) # generate 3 random features with normal distribution
X[:,0]=X[:,0]*1000 # make one feature of a bigger magnitude

y=X.sum(axis=1) # target is just an exact sum of our 3 features


model=CatBoostRegressor(verbose=0,eval_fraction=0.1)
model.fit(X,y,plot=True)


print(f"train RMSE={root_mean_squared_error(y,model.predict(X))}")

train RMSE=311.7677815427915

и попытаться понять, что происходит.

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

Мне подсказали увеличить катбустовый (гипер)параметр border_count, но даже с максимальным значением RMSE всё равно высока. Ну хотя бы снижается втрое.

Какие выводы можно сделать из данного примера:

1) всегда проверяйте несколько альтернативных классов моделей, обязательно включая линейные
2) в некоторых случаях HPT даёт прирост не в 10-15, а в 300-500% (также справедливо для категориек в xgboost. ну плохо он умеет с ними обращаться, плохо). делайте HPT.
3) lightgbm с линейной регрессией в листьях (вместо константы) решает задачу LGBMRegressor (linear_tree=True)
4) в общем случае бустинги требуют в качестве препроцессора не только PolynomialFeatures для моделирования произведений, но и, похоже, "AdditiveFeatures", дающего суммы/линейные комбинации сырых признаков.
5) плохонький и простенький посчитанный численный эксперимент лучше любого предвзятого убеждения.
6) декомпозиция рулит

#games #returntomoria

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

#fun #music #rammstein #programming

Что общего у Тилля с программированием?

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

Дождались

Наконец-то выложили видео с моим выступлением на датафесте!

Все прошло очень круто, тем более в этот день конференция проходила в гостях у Яндекса и по классике все было очень приятно.

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

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

Кстати, вот ссылка на видео: https://www.youtube.com/watch?v=lL9Dimm5UuE

#life #ml #timeseries

#law #google

"В центре скандала оказалось действующее с 2002 года эксклюзивное соглашение между Apple и Google, в рамках которого поисковая система Google Search является на всех устройствах Apple для пользователей по всему миру поисковиком по умолчанию, что приносило и той и другой компании доходы, исчисляемые миллиардами долларов. Google выплачивала Apple как партнёру часть дохода от своей поисковой рекламы. Только за 2022 год Google выплатила Apple 20 млрд долларов, сообщает Financial Times, ссылаясь на приведённые факты в судебном решении.

Окружной судья Амит Мехта (Amit Mehta) признал Google виновной в нарушении антимонопольного законодательства, что ставит под вопрос партнёрское соглашение об установлении Google на устройствах Apple в качестве основного поисковика.

Google намерена обжаловать решение суда, хотя аналитики считают, что шансы на положительный пересмотр малы. В зависимости от окончательного вердикта, касающегося нарушения антимонопольного законодательства Google, Apple может быть «вынуждена согласиться на гораздо менее выгодное соглашение с Microsoft [поисковая система Bing] или может быть вообще лишена возможности устанавливать поисковые системы по умолчанию», — считает независимый аналитик Эрик Сеуферт (Eric Seufert)."

https://3dnews.ru/1109138/v-apple-zayavili-chto-alternativi-poisku-google-net

#gpt #openai

"До вычета сборов магазинов приложений Apple App Store и Google Play, приложение ChatGPT заработало 28,9 млн долларов в мае, 34 млн долларов в июне и 39,9 млн долларов в июле. Интересно, что 83 % выручки приложения пришлось на App Store от Apple, что на 20 % больше по сравнению с июнем.

По информации Appfigures, спрос на новую технологию способствовал росту выручки приложения на 40 % в мае, и хотя темпы роста немного замедлились, доходы продолжают расти стабильно. В результате, в июле ChatGPT удалось привлечь 2 миллиона новых платных подписчиков, что стало очередным рекордом для мобильного приложения.

В OpenAI ожидают, что с внедрением нового расширенного голосового режима, который сможет обеспечить реалистичное взаимодействие практически в реальном времени, интерес к GPT-4o будет только увеличиваться, соответственно рост доходов продолжится в ближайшие месяцы."

https://3dnews.ru/1109146/mobilnoe-prilogenie-chatgpt-blagodarya-versii-omni-zafiksirovalo-rekordnuyu-viruchku

#sklearn #dataframes

Оказывается, есть инициатива унификации библиотек работы с датафреймами. И её поддерживают в sklearn.

"Enhancement All estimators now recognizes the column names from any dataframe that adopts the DataFrame Interchange Protocol. Dataframes that return a correct representation through np.asarray(df) is expected to work with our estimators and functions."

"Python users today have a number of great choices for dataframe libraries. From Pandas and cuDF to Vaex, Koalas, Modin, Ibis, and more. Combining multiple types of dataframes in a larger application or analysis workflow, or developing a library which uses dataframes as a data structure, presents a challenge though. Those libraries all have different APIs, and there is no standard way of converting one type of dataframe into another."

Похожая идея с использованием массивов Array API:

"Python users have a wealth of choice for libraries and frameworks for numerical computing, data science, machine learning, and deep learning. New frameworks pushing forward the state of the art in these fields are appearing every year. One unintended consequence of all this activity and creativity has been fragmentation in multidimensional array (a.k.a. tensor) libraries - which are the fundamental data structure for these fields. Choices include NumPy, Tensorflow, PyTorch, Dask, JAX, CuPy, MXNet, Xarray, and others.

The APIs of each of these libraries are largely similar, but with enough differences that it’s quite difficult to write code that works with multiple (or all) of these libraries. This array API standard aims to address that issue, by specifying an API for the most common ways arrays are constructed and used.

Why not simply pick an existing API and bless that as the standard?"

#sklearn #cupy

Вот пример выполнения LDA на GPU с применением этого экспериментального Array API.

from sklearn.datasets import make_classification
from sklearn import config_context
from sklearn.discriminant_analysis import LinearDiscriminantAnalysis
import cupy

X_np, y_np = make_classification(random_state=0)
X_cu = cupy.asarray(X_np)
y_cu = cupy.asarray(y_np)
X_cu.device

with config_context(array_api_dispatch=True):
    lda = LinearDiscriminantAnalysis()
    X_trans = lda.fit_transform(X_cu, y_cu)
X_trans.device

А еще теперь можно напрямую работать с тензорами Pytorch:

import torch
X_torch = torch.asarray(X_np, device="cuda", dtype=torch.float32)
y_torch = torch.asarray(y_np, device="cuda", dtype=torch.float32)

with config_context(array_api_dispatch=True):
    lda = LinearDiscriminantAnalysis()
    X_trans = lda.fit_transform(X_torch, y_torch)
type(X_trans)
X_trans.device.type

Пока далеко не все модули это поддерживают, но сама идея чудесная.

https://scikit-learn.org/stable/modules/array_api.html#array-api

#astronomy #geology

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

#boostings #mlgems

Подумал, жаль, что даже в лучших в современных библиотеках машинного обучения нет параметра timeout. В xgboost, catboost, lightgbm есть максимальное количество деревьев n_estimators, но вряд ли кому есть дело до точного количества деревьев в решении. Что на самом деле важно, так это максимальное время обучения модели, правда? Так почему бы не дать возможность его непосредственно задать параметром timeout?

Запостил feature requests. Мне, правда, указывают, что можно для этих целей приспособить коллбэк и отлавливать исключение, но в xgboost неясно, сохранится ли лучшая модель, если используется защита от оверфита. Да и гораздо удобнее, если такой простой параметр будет во всех либах без необходимости конструировать и тестировать свои коллбэки.

Если кто согласен с полезностью такой фичи, буду рад поддержке в гитхабовских ветках.