прироста не будет же

только экономия памяти при использовании одной модели в разных процессах

если сделать формат заточенный под максимально линейное и последовательное обращение к памяти — то будет афигенный. Это как merge sort & quick sort — вроде оба N*log(N), но на современных процессорах merge может быть в несколько раз быстрее, ибо последовательное обращение к памяти.

ты наверно имеешь в виду экономию на TLB и HUGE PAGE

прям сейчас алгоритм и так бежит по векторам максимально линейно

формат применялки уже заточен под эфективное обращение к памяти

самая большая проблема - это фетч значений листьев, там идет gather по фиксированному смещению + номер листа документа

вызов функции get_object_importance съедает всю оперативку, больше 30 гигабайт и залезает в своп, дальше не стал проверять, так и должно быть? передаю pool=25k строк и train_pool=75k строк

Привет, маловероятно, но вдруг: возможно ли указать для регрессии что все тагеты больше нуля?

Не подойдёт ли под логарифм его загнать предварительно, а получив прогноз - прогноз под экспоненту? 🙃

Хотя это может быть не лучше чем просто "обнулять" отрицательные прогнозы, в зависимости от области определения таргета

@rubyr0id да, может быть не лучшим, но попробую. Спасибо

Всем привет! Меня зовут Дмитрий Барычев, руководитель сервиса Отследить-посылку.рф . Мы строим можель в катбусте по прогнозу, выкупит или нет человек следующую посылку, отправленную Почтой России наложенным платежом. У нас в базе 200 млн посылок и 1 млрд писем. Модель построили в катбусте, но пока результат не очень. Ищу специалиста, кто может выделять час времени в день, чтобы нам помогать или взять в работу весь проект. Отзовитесь, пожалуйста! Очень надо. Нам срочно. Отблагодарим щедро!)

Что значит "не очень"? Почему сразу катбуст, что с другими алгоритмами?

кликхаус

не очень - 79% точности

хочется 95

Уже почти все понятно. Какая доля посылок "выкупается"?

85 в среднем, но разброс от 55 до 95

Тогда точность 85 получается вообще без моделей