Было так же, решал свопом большим

Простой пример это timestamp, из него можно получить день недели и час дня, когда фичи разделяются на сплиты маловероятно что получится выделить воскресение в отдельный сплит. Если и получится случайно то какие то конкретные воскресения. А что если воскресение вечер окажется важной фичей.

Другой пример из sna конкурса. Есть количество просмотров объекта и количество лайков объекта, фажным признаком будет likesCount/showsCount, то есть для дерева не понятно 10 лайков это хорошо или плохо, оно должно создать сразу ещё один лист который определит а сколько просмотров (точнее больше чем сколько).

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

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

В версии 0.13.1 на CPU не поддерживается queryCrossEntropy так как не поддерживается leaf_estimation_method=Newton https://github.com/catboost/catboost/blob/master/catboost/libs/options/catboost_options.cpp#L90 а queryCrossEntropy хочет Newton

leaf_estimation_method=Newton на цпу поддерживается, а вот лосса QueryCrossEntropy нет

QueryCrossEntropy+CPU ошибка выдается this leaf_estimation_method is not supported. Хотя да, для других лосов Newton работает

Сделай, пожалуйста, issue, что текст ошибки неправильный.

ок

Судя по логам ошибок и комментариям в коде у меня создается впечатление что для querywise лоссов нужен какой то свой Newton который на CPU не реализован.
тогда может этот лог ошибки "This leaf estimation method is not supported for querywise error for CPU learning" верный, но всё равно не дает предствавления пользователю что с этим делать

ну тикет я создал

А ещё кстати QueryCrossEntropy после окончания обучения начинает считать feature importance (неотключаемо) в один поток CPU и занимает это больше времени чем само обучение. Это ожидаемое поведение или тоже баг?

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

А где нибудь можно почитать что делает has time = true.
На сколько я понимаю target encoding для кат фичей считается только в одной исходной соротировке, а значит не нужно теперь строить 3 модели с разными сортировками. Соответственно можно ожидать прироста скорости, но этого не заметно

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

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

Привет. Помогите, пожалуйста, разобраться с идеей категориальных фич. Вот у меня есть тестовый датасет, с колонками a, b, c. Всего мне известно, что в каждой из колонок может быть до 50 уникальных значений, но в тренировочном датасете у меня в колонках a, b, c по 50, 35, 48 значений соответственно. А после в датасете, для которого результат нужно предсказать в этих a, b, c по 30, 50, 50 уникальных значений.

Вопрос, нормально ли будет работать модель или лучше самому завести колонки под каждое уникальное значение вроде a_0, a_1, a_2, …, a_50 со значениями 0 или 1 - присутствует ли значение в колонке a. И так для остальных.

по дефолту заработает таргет энкодинг, то есть для каждой строки в a,b,c будет считаться среднее по таргету объектов выше этого в какйо то рандомной сортировке.
Можно увеличить параметр что то тима max_one_hot до 50 и тогда они будут работать как one hot, то есть то что ты руками предлагаешь сделать, только быстрее и вероятно немного лучше

в inference режиме категории которая встречалась тесте будет присвоено значение среднее по таргету на трейне, которая не встречалась получит значение 0,05

но это не точно, я могу ошибаться

Мне стоило бы указать, что в колонках a, b, c объекты одного множества. То есть все значения a = всем значениям b = всем значениям c. То есть можно ли сказать one-hot, чтобы создал колонки для всех значений. Или все же сделать ручками?