#earlystopping #pipelines #boostings
При тестировании отборщиков признаков в конвейере (а это, по идее, лучшая практика) вдруг осознал, что из 3-х основных бустингов только катбуст может обучать финальную модель с ранней остановкой, и то, если нет категориальных признаков в датасете. Все остальные требуют явного указания валидационного множества в fit_params, т.е. создаёшь такой его до запуска конвейера из начальных признаков (а как ещё-то?), первым этапом конвейера запускается отборщик признаков, убирает у тебя, скажем, половину фич, передаёт самые важные на обучение финальной модели, а она валится с ошибкой, что в валидационном множестве найдены несовпадающие признаки. Вопрос: каким местом думают разработчики популярных бустингов, почему не сделали передачу индексов или вообще сплиттеров вместо полноценных данных?
Пока выход виден только один, отказаться от лучшей практики и фиттить отборщик признаков отдельно. Или есть ещё варианты?
Почему это вообще считалось лучшей практикой? Наверное, потому, что весь конвейер было легко сохранить в один файл и обучать на любых новых данных почти одной строкой. Почти потому, что надо ж ещё просплитить данные было на train и eval.
Пока что, если хочется следовать остальным лучшим практикам (Early Stopping etc), выходит что конвейер надо сохранять 2 частями: препроцессинг (с потенциальным созданием новых фичей)+FS, и финальная моделька (потенциально + обёртка в виде HPT).
Что-то не могу придумать красивого варианта (
При тестировании отборщиков признаков в конвейере (а это, по идее, лучшая практика) вдруг осознал, что из 3-х основных бустингов только катбуст может обучать финальную модель с ранней остановкой, и то, если нет категориальных признаков в датасете. Все остальные требуют явного указания валидационного множества в fit_params, т.е. создаёшь такой его до запуска конвейера из начальных признаков (а как ещё-то?), первым этапом конвейера запускается отборщик признаков, убирает у тебя, скажем, половину фич, передаёт самые важные на обучение финальной модели, а она валится с ошибкой, что в валидационном множестве найдены несовпадающие признаки. Вопрос: каким местом думают разработчики популярных бустингов, почему не сделали передачу индексов или вообще сплиттеров вместо полноценных данных?
Пока выход виден только один, отказаться от лучшей практики и фиттить отборщик признаков отдельно. Или есть ещё варианты?
Почему это вообще считалось лучшей практикой? Наверное, потому, что весь конвейер было легко сохранить в один файл и обучать на любых новых данных почти одной строкой. Почти потому, что надо ж ещё просплитить данные было на train и eval.
Пока что, если хочется следовать остальным лучшим практикам (Early Stopping etc), выходит что конвейер надо сохранять 2 частями: препроцессинг (с потенциальным созданием новых фичей)+FS, и финальная моделька (потенциально + обёртка в виде HPT).
Что-то не могу придумать красивого варианта (
Please open Telegram to view this post
VIEW IN TELEGRAM
#boostings #mlgems
Подумал, жаль, что даже в лучших в современных библиотеках машинного обучения нет параметра timeout. В xgboost, catboost, lightgbm есть максимальное количество деревьев n_estimators, но вряд ли кому есть дело до точного количества деревьев в решении. Что на самом деле важно, так это максимальное время обучения модели, правда? Так почему бы не дать возможность его непосредственно задать параметром timeout?
Запостил feature requests. Мне, правда, указывают, что можно для этих целей приспособить коллбэк и отлавливать исключение, но в xgboost неясно, сохранится ли лучшая модель, если используется защита от оверфита. Да и гораздо удобнее, если такой простой параметр будет во всех либах без необходимости конструировать и тестировать свои коллбэки.
Если кто согласен с полезностью такой фичи, буду рад поддержке в гитхабовских ветках.
Подумал, жаль, что даже в лучших в современных библиотеках машинного обучения нет параметра timeout. В xgboost, catboost, lightgbm есть максимальное количество деревьев n_estimators, но вряд ли кому есть дело до точного количества деревьев в решении. Что на самом деле важно, так это максимальное время обучения модели, правда? Так почему бы не дать возможность его непосредственно задать параметром timeout?
Запостил feature requests. Мне, правда, указывают, что можно для этих целей приспособить коллбэк и отлавливать исключение, но в xgboost неясно, сохранится ли лучшая модель, если используется защита от оверфита. Да и гораздо удобнее, если такой простой параметр будет во всех либах без необходимости конструировать и тестировать свои коллбэки.
Если кто согласен с полезностью такой фичи, буду рад поддержке в гитхабовских ветках.
GitHub
Feature Request: add timeout parameter to the .fit() method · Issue #10684 · dmlc/xgboost
Adding the timeout parameter to the .fit() method, that should force the library to return best known solution found so far as soon as provided number of seconds since the start of training are pas...
#boostings #regression #trees #compositeregressor
В свете недавних разочарований по поводу неспособности деревянных моделей к хорошему прогнозу линейных комбинаций признаков сделал свою реализацию CompositeRegressor (совместимую с scikit-learn), которая призвана решать эту проблему (и решает) композицией сначала линейной, а на её невязках уже нелинейной "деревянной" модели.
Причём линейная может строиться не на всех исходных признаках, а лишь на их "устойчивом" подмножестве (чтобы не лезла в нелинейную часть, которую лучше оставить модельке верхнего уровня).
Сейчас пишу сопроводительную статью и (вопреки своей лени и дремучести) покрываю модуль тестами, т.к. хочу показать читателям не только полезный с точки зрения ds приём, но и грамотную программерскую реализацию, готовую к боевому внедрению, в т.ч. корпоративного уровня.
В свете недавних разочарований по поводу неспособности деревянных моделей к хорошему прогнозу линейных комбинаций признаков сделал свою реализацию CompositeRegressor (совместимую с scikit-learn), которая призвана решать эту проблему (и решает) композицией сначала линейной, а на её невязках уже нелинейной "деревянной" модели.
Причём линейная может строиться не на всех исходных признаках, а лишь на их "устойчивом" подмножестве (чтобы не лезла в нелинейную часть, которую лучше оставить модельке верхнего уровня).
Сейчас пишу сопроводительную статью и (вопреки своей лени и дремучести) покрываю модуль тестами, т.к. хочу показать читателям не только полезный с точки зрения ds приём, но и грамотную программерскую реализацию, готовую к боевому внедрению, в т.ч. корпоративного уровня.