Если не нужна: деревья (xgboost, lightgbm, catboost, sklearn randomforest/gbtree, spark randomforest/gbtree)
State-of-the-art точность на структурированных данных, нет необходимости стандартизировать данные и (в некоторых имплементациях) заполнять missing values , быстрое обучение (параллельное для RF), куча имплементаций и.т.д. и.т.п. К тому же у нас нет видеокарт, без которых обучение сеток (единственный конкурентный метод на данный момент) крайне затруднительно.
Если задача решается локально, то лучше использовать lightgbm/catboost/xgboost, т.к. они самые точные. Xgboost является самым старым и у него лучше всего документация/примеры , но он не умеет работать с категориальными фичами в отличие от двух альтернатив. В целом из этих трёх можно выбирать тот, который больше нравится
SKlearn Random Forest может быть полезен если нужна максимально быстрая и грубая модель (или например вы хотите быстро глянуть feature importance), плюс он ближе к интерпретируемости и линейности чем бустинг
SKlearn Gbtree мало смысла использовать т.к. одна из вышеперечисленных альтернатив лучше для любой задачи, но никакого преступления в этом нет
Если задача решается на кластере Hadoop, то использовать местный randomforest/gbtree. Есть слабая рекомендация использовать forest, т.к. параллельная обучаемость, но в целом это решение up to you
- Vowpal Wabbit и похожие являются правильным методом если данные никак не пролезают в оперативную память и нет возможность построить нормальную модель на части данных , на момент написания таких задач в теле2 нет
- Нейросети для всех задач с неструктурированными данными (опять же, нет видеокарт, задачи с такими данными потенциально могут быть, но на момент написания их также нет в теле2)
- Naive Bayes никогда, отвратительная точность
- SVM никогда, немного проигрывает по точности и сильно по производительности, нет причин использовать когда есть деревья
- KNeighbours никогда
- Прочие редкие методы примерно никогда
- Ансамбли моделей в продакше используем примерно никогда, инкрементальное повышение точности не стоит страданий, к которым это приведёт
Старайтесь избегать таких задач т.к. реальность никогда не совпадёт полностью с фантазией заказчика. Конкретный метод не так важен, возьмите какую-нибудь кластеризацию
Данные представляют собой выборку, обычно из абонентов и дат, к которой мы по дате/абоненту привязываем объясняющие переменные, которые мы получаем из одной из наших витрин, про витрины в отдельном гайде. Выборку мы обычно получаем из внешнего источника, после чего в терадате или хадупе собираем для неё объясняющие переменные
Идеального метода нет, пример приемлимого решения: Берём все фичи что есть, закидываем в xgboost, смотрим feature importance. Проверяем, что модель даёт хоть какую-то точность и что в топе относительно логичные фичи. Берём топ-50 из прошлого пункта, выкидываем вручную все фичи, которые точно являются плохими для модели (про это в отдельном гайде), все оставшиеся проверяем на валидации (по очереди добавляем или убираем), не забываем правильно валидироваться
Для валидации мы хотим максимально приблизиться к той ситуации, для которой модель будет использоваться в дальнейшем. Пример: для банковского скоринга заказчик будет смотреть на точность на всей выборке, но мы хотим чтобы модель хорошо работала в продакшне, что хронологически будет после времени, за которое собрана выборка. Поэтому в такой ситуации правильно валидироваться на последнем хронологическом куске (обычно можно просто взять последний месяц, но вообще это просто последние 10-20% наблюдений по времени)
Эти вещи могут сильно отличаться для вашей задачи, здесь приведены разумные рекомендации для общего случая В полезных материалах есть ссылка на расширенный гайд по гиперпаметрам для XGboost
- Количество деревьев: 100-300
- Learning rate/ETA: 0.01 - 0.1 (можно юзать высокий рейт на стадии выбора фичей и гиперпараметров для ускорения процесса)
- Max depth: 3-6, эта штука очень быстро приводит к оверфиту и с ней надо быть аккуратным
- Subsampling rate: 0.5 - 1 (что-нибудь вроде 0.7 по дефолту) - для колонок и рядов
- Scale_pos_weight: sum(negative cases) / sum(positive cases) или не трогаем
- Регуляризация (gamma, lambda, min_child_weight etc): чем выше сложность модели (напр. max_depth) тем больше
Неплохой идеей для тюнинга параметров является сначала построить модель, которая оверфитит чтобы понимать пределы точности, а потом постепенно приблизить точность на валидации к тому что на трейне
Если конечной целью является правильное ранжирование (и решается задача классификации), то ROC AUC (на правильно заданной валидации) является вполне достаточной метрикой точности. В папке "General Knowledge" есть ноутбук, который питоновским кодом объясняет что из себя представляет ROC AUC Если стоит задача предсказывать не только ранжирование, но и правильный исход (0 или 1), то необходимо также смотреть на Precision-Recall AUC Никогда не будет лишним посмотреть и на Accuracy
"Хороший" результат крайне сильно зависит от задачи, и не существует отсечки после которой модель универсально хорошая 0.65+ AUC является приемлимой точностью для внешних задач (таких как банковский скоринг), однако для конкретной выборки вполне возможно что мы можем достичь значительно более высокой точности , так что нужно хорошо изучить достижимые пределы и примерно прикинуть (или спросить у коллег) какая примерно должна быть точность у такой задачи Если задача плохо сформулирована, или у нас нет и не может быть хороших данных, то иногда и результат в 0.6 является прекрасным - это могут быть 0.6 которых нет у заказчика Для внутренних задач встречаются и более высокие точности в 0.85-0.9, однако в целом при слишком высокой точности стоит искать ошибку/протечку в данных
Для любой модели, которая должна будет работать продолжительное время необходимо удостовериться в том, что она является достаточно стабильной во времени. Для этой цели можно взять несколько случайных выборок из разных месяцев (если есть возможность посмотреть на "будущее" относительно трейн выборки то это хорошо) и визуально посмотреть на распределение скоров Банки зачастую для определения стабильности используют метрику PSI - Population Stability Index, и в некоторых случаях эта стабильность является более приоритетной задачей, чем повышение точности модели , поэтому очень важно уделить внимание этому моменту Другой важный момент для внешних скорингов: точность на трейне и тесте не должна сильно различаться, т.к. они будут строить свою модель поверх нашей и им нужна стабильность в этом плане тоже
Все решения об используемых переменных и гиперпараметрах нужно принимать локально (если не пролезает, то на куске данных) - на спарке это сделать технически возможно, но крайне долго и неубедительно
У нас нет задачи построить модель, которая даст максимальную точность на валидации или даже тесте, т.к. это будет во многом оверфит к конкретной выборке. Задача во многом состоит в том, чтобы построить достаточно точную модель, которая будет удовлетворять всем дополнительным требованиям (стабильность, производительность и.т.д.)