AB
Ответил на запрос, в конце написано что ‘доступ запрещён’
+1. Обидно, отвечал вдумчиво, а все зря
Size: a a a
2019 March 21
AT
Там следующая страница с результатами опроса, наверное. Её могут видеть не все
Аa
какой же это "другой"?
ip, os, разрешение экрана, версия браузера, куча всего. Но уже этого, да факта интереса к DS достаточно, чтобы меня идентифицировать.
AD
+1. Обидно, отвечал вдумчиво, а все зря
Смотрим. Пожалуйста, сохрани пока куда-нибудь свои ответы, нам очень важен ваш фидбек!
KM
Есть какая-то возможность посмотреть на дерево решений и понять почему дерево дало такой ответ?
AD
json только
AD
есть туториал, в котором описано, как по json-у понять, что в деревьях
KM
Спасибо. Смотрю ваши доклады, все очень круто и интересно)
Аa
Датасет 30000*25. В нём события, которые возникали в разные моменты времени в меняющемся мире. Первые 60% - train, следующие 20% - для валидации при обучении, последние 20% - отложенная выборка для валидации после обучения.
Если выкрутить
Если выкрутить
lr=0.15, l2_leaf_reg=770, Max_depth: 4. RSM: 0.84, то лучшей итерацией оказывается буквально 15я. Ошибки на выборках такие: RMSE. Train: 1446.01. Validation: 481.14. Holdout: 503.06
Как правильно такую ситуацию толковать? Большая разница между обучающей и валидационными выборками? Насколько такое решение стабильно?AB
Приветы! Активно используем CatBoost в продакшене: прогнозируем качество RTB трафика до его покупки. Абсолютно нет вопросов к качеству обучения, однако, присутствуют некоторые неприятные моменты в эксплуатации:
1. На наборе из 7-10КК объектов, состоящих из ~40 категориальных фич (файл .csv на 4ГБ) может получиться бинарный классификатор весом в 13ГБ (300+ деревьев): приходится ограничивать количество деревьев 50-60ю. При этом модель умещается в 4ГБ, но граница порога принятися решения перестает быть такой четкой, как в полностью обученной модели в 13Г+.
Насколько я понимаю, дело во встроенной методике преобразования категориальных фич в числовые, так как подобного эффекта нет при работе с числовыми фичами.
Снизить размер моделей (примерно в 10 раз) помогает параметр model_size_reg, но он недоступен при обучении на GPU, также модели, обученные с ним, теряют в скорости применения примерно в 2-3 раза. Хотя, возможно, на скорость влияет увеличенное количество деревьев - не могу точно сказать.
Вопросы:
- Есть ли какие-либо способы существенно уменьшить модели при обучении на GPU без сокращения числа деревьев?
- В данный момент размер модели резко увеличивается с каждым новым деревом, что может говорить о том, что каждое дерево тащит за собой огромную таблицу преобразований. Возможно, имеет смысл вынести работу с категориальными фичами за скобки и проделывать один раз? Возможно, я тут глупость говорю, так как не в полной мере владею внутренным устройством инструмента. Поправьте)
2. Наш микросервис на Go, выполняющий роль аппликатора, обращается к вашей динамическую библиотеке libcatboostmodel.so для работы с моделями. Периодически модели необходимо обновлять. Тут возникает следующая проблема:
- вызов функций ModelCalcerDelete не приводит к полному освобождению памяти от старой модели (остается от 20% до половины),
- затем после вызова ModelCalcerCreate и LoadFullModelFromFile микросервис уже занимает памяти больше, чем мог бы при рестарте
- справедливости ради нужно отметить, что ингода при вызове ModelCalcerCreate и LoadFullModelFromFile часть неудаленной (от старой модели) памяти все таки освобождается (не вся)
- но в долгосрочном периоде работы (месяц, например) микросервис с катбустом может захватить все пространство сервера
Сталкивались ли вы с чем-то подобным при перезагрузке моделей без перезагрузки сервиса? Возможно, у вас все хорошо, и как-то влияет взимодействие с Go?
1. На наборе из 7-10КК объектов, состоящих из ~40 категориальных фич (файл .csv на 4ГБ) может получиться бинарный классификатор весом в 13ГБ (300+ деревьев): приходится ограничивать количество деревьев 50-60ю. При этом модель умещается в 4ГБ, но граница порога принятися решения перестает быть такой четкой, как в полностью обученной модели в 13Г+.
Насколько я понимаю, дело во встроенной методике преобразования категориальных фич в числовые, так как подобного эффекта нет при работе с числовыми фичами.
Снизить размер моделей (примерно в 10 раз) помогает параметр model_size_reg, но он недоступен при обучении на GPU, также модели, обученные с ним, теряют в скорости применения примерно в 2-3 раза. Хотя, возможно, на скорость влияет увеличенное количество деревьев - не могу точно сказать.
Вопросы:
- Есть ли какие-либо способы существенно уменьшить модели при обучении на GPU без сокращения числа деревьев?
- В данный момент размер модели резко увеличивается с каждым новым деревом, что может говорить о том, что каждое дерево тащит за собой огромную таблицу преобразований. Возможно, имеет смысл вынести работу с категориальными фичами за скобки и проделывать один раз? Возможно, я тут глупость говорю, так как не в полной мере владею внутренным устройством инструмента. Поправьте)
2. Наш микросервис на Go, выполняющий роль аппликатора, обращается к вашей динамическую библиотеке libcatboostmodel.so для работы с моделями. Периодически модели необходимо обновлять. Тут возникает следующая проблема:
- вызов функций ModelCalcerDelete не приводит к полному освобождению памяти от старой модели (остается от 20% до половины),
- затем после вызова ModelCalcerCreate и LoadFullModelFromFile микросервис уже занимает памяти больше, чем мог бы при рестарте
- справедливости ради нужно отметить, что ингода при вызове ModelCalcerCreate и LoadFullModelFromFile часть неудаленной (от старой модели) памяти все таки освобождается (не вся)
- но в долгосрочном периоде работы (месяц, например) микросервис с катбустом может захватить все пространство сервера
Сталкивались ли вы с чем-то подобным при перезагрузке моделей без перезагрузки сервиса? Возможно, у вас все хорошо, и как-то влияет взимодействие с Go?
AD
Приветы! Активно используем CatBoost в продакшене: прогнозируем качество RTB трафика до его покупки. Абсолютно нет вопросов к качеству обучения, однако, присутствуют некоторые неприятные моменты в эксплуатации:
1. На наборе из 7-10КК объектов, состоящих из ~40 категориальных фич (файл .csv на 4ГБ) может получиться бинарный классификатор весом в 13ГБ (300+ деревьев): приходится ограничивать количество деревьев 50-60ю. При этом модель умещается в 4ГБ, но граница порога принятися решения перестает быть такой четкой, как в полностью обученной модели в 13Г+.
Насколько я понимаю, дело во встроенной методике преобразования категориальных фич в числовые, так как подобного эффекта нет при работе с числовыми фичами.
Снизить размер моделей (примерно в 10 раз) помогает параметр model_size_reg, но он недоступен при обучении на GPU, также модели, обученные с ним, теряют в скорости применения примерно в 2-3 раза. Хотя, возможно, на скорость влияет увеличенное количество деревьев - не могу точно сказать.
Вопросы:
- Есть ли какие-либо способы существенно уменьшить модели при обучении на GPU без сокращения числа деревьев?
- В данный момент размер модели резко увеличивается с каждым новым деревом, что может говорить о том, что каждое дерево тащит за собой огромную таблицу преобразований. Возможно, имеет смысл вынести работу с категориальными фичами за скобки и проделывать один раз? Возможно, я тут глупость говорю, так как не в полной мере владею внутренным устройством инструмента. Поправьте)
2. Наш микросервис на Go, выполняющий роль аппликатора, обращается к вашей динамическую библиотеке libcatboostmodel.so для работы с моделями. Периодически модели необходимо обновлять. Тут возникает следующая проблема:
- вызов функций ModelCalcerDelete не приводит к полному освобождению памяти от старой модели (остается от 20% до половины),
- затем после вызова ModelCalcerCreate и LoadFullModelFromFile микросервис уже занимает памяти больше, чем мог бы при рестарте
- справедливости ради нужно отметить, что ингода при вызове ModelCalcerCreate и LoadFullModelFromFile часть неудаленной (от старой модели) памяти все таки освобождается (не вся)
- но в долгосрочном периоде работы (месяц, например) микросервис с катбустом может захватить все пространство сервера
Сталкивались ли вы с чем-то подобным при перезагрузке моделей без перезагрузки сервиса? Возможно, у вас все хорошо, и как-то влияет взимодействие с Go?
1. На наборе из 7-10КК объектов, состоящих из ~40 категориальных фич (файл .csv на 4ГБ) может получиться бинарный классификатор весом в 13ГБ (300+ деревьев): приходится ограничивать количество деревьев 50-60ю. При этом модель умещается в 4ГБ, но граница порога принятися решения перестает быть такой четкой, как в полностью обученной модели в 13Г+.
Насколько я понимаю, дело во встроенной методике преобразования категориальных фич в числовые, так как подобного эффекта нет при работе с числовыми фичами.
Снизить размер моделей (примерно в 10 раз) помогает параметр model_size_reg, но он недоступен при обучении на GPU, также модели, обученные с ним, теряют в скорости применения примерно в 2-3 раза. Хотя, возможно, на скорость влияет увеличенное количество деревьев - не могу точно сказать.
Вопросы:
- Есть ли какие-либо способы существенно уменьшить модели при обучении на GPU без сокращения числа деревьев?
- В данный момент размер модели резко увеличивается с каждым новым деревом, что может говорить о том, что каждое дерево тащит за собой огромную таблицу преобразований. Возможно, имеет смысл вынести работу с категориальными фичами за скобки и проделывать один раз? Возможно, я тут глупость говорю, так как не в полной мере владею внутренным устройством инструмента. Поправьте)
2. Наш микросервис на Go, выполняющий роль аппликатора, обращается к вашей динамическую библиотеке libcatboostmodel.so для работы с моделями. Периодически модели необходимо обновлять. Тут возникает следующая проблема:
- вызов функций ModelCalcerDelete не приводит к полному освобождению памяти от старой модели (остается от 20% до половины),
- затем после вызова ModelCalcerCreate и LoadFullModelFromFile микросервис уже занимает памяти больше, чем мог бы при рестарте
- справедливости ради нужно отметить, что ингода при вызове ModelCalcerCreate и LoadFullModelFromFile часть неудаленной (от старой модели) памяти все таки освобождается (не вся)
- но в долгосрочном периоде работы (месяц, например) микросервис с катбустом может захватить все пространство сервера
Сталкивались ли вы с чем-то подобным при перезагрузке моделей без перезагрузки сервиса? Возможно, у вас все хорошо, и как-то влияет взимодействие с Go?
попробуй max_ctr_complexity=1 или 2
AD
будет модель поменьше
AD
model_size_reg на гпу добавим, вроде был issue по этому поводу
AB
Спасибо! Посмотрите, пожалуйста, момент с утечками – крайне неожиданное поведение, и ничего не сделаешь, так как внешняя либа. Ну, и в виду размера моделей cbm – единственный вариант
SK
Спасибо! Посмотрите, пожалуйста, момент с утечками – крайне неожиданное поведение, и ничего не сделаешь, так как внешняя либа. Ну, и в виду размера моделей cbm – единственный вариант
Это скорее всего кэш аллокатора
SK
Надо сделать очистку его на выгрузку модели, да
SK
Сколько у вас гигов памяти на сервере?
AB
Возможно есть какие-то функции для запуска GC или сброса кэша, которые отстутствуют в заголовке?
AB
32 - 64, несколько серверов
SK
Они приватные просто