Comments 9
Одна из проблем нынешнего дата саенса — доступ неокрепших умов к слишком большому количеству вспомогательных инструментов.
А еще — отсутствие зачастую элементарной статистической грамотности (это мой «закидон» на будущее — будем исправлять)
Из собственного опыта (в том числе слегка проверенного кагглом), что бы я попробовал в этом конкретном случае:
— не занимайтесь «кусочнечеством» — не восстанавливайте пропущенные данные — просто выбрасывайте их на первом проходе. На последующих — попробуйте то же самое, но с imputed пропущенными. Вы удивитесь, но по моему опыту просто выбросить — в 99% случаев — наилучшее решение
— пробуйте искать страты, вот то, что делает Random Forest неплохо было бы поделать руками с несколькими переменными
— попробуйте себя представить на месте заемщика по кредиту и как бы вы пытались «схимичить», и на каких переменных это отразилось бы.
Удачи!
А еще — отсутствие зачастую элементарной статистической грамотности (это мой «закидон» на будущее — будем исправлять)
Из собственного опыта (в том числе слегка проверенного кагглом), что бы я попробовал в этом конкретном случае:
— не занимайтесь «кусочнечеством» — не восстанавливайте пропущенные данные — просто выбрасывайте их на первом проходе. На последующих — попробуйте то же самое, но с imputed пропущенными. Вы удивитесь, но по моему опыту просто выбросить — в 99% случаев — наилучшее решение
— пробуйте искать страты, вот то, что делает Random Forest неплохо было бы поделать руками с несколькими переменными
— попробуйте себя представить на месте заемщика по кредиту и как бы вы пытались «схимичить», и на каких переменных это отразилось бы.
Удачи!
Насколько я знаю, по правилам Kaggle запрещено выкладывать код и материалы по текущим соревнованиям за пределами платформы.
Также у меня есть ряд комментариев по содержанию статьи.
Слабо представляю, как выполнять эти пункты в таком порядке (особенно 2 и 3), если только «ознакомление с данными» в первом пункте не подразумевает по сути EDA.
На самом деле, не два. Вы забыли, как минимум, mean target encoding, который появляется в топовых решениях на Kaggle чаще других.
Кажется, здесь опечатка.
Во-первых, устранение лишнего столбца для снижения мультиколлинеарности — это стандартный сеттинг OHE, который есть из коробки в том же get_dummies в pandas. Во-вторых, пол — это бинарная фича в данном случае, поэтому логично, что OHE этой фичи ничего хорошего вам не принесёт.
Признак с низкой вариативностью, закодированный Label Encoder'ом, для логрега будет мусором. Признак с высокой вариативностью, закодированный One-Hot Encoder'ом, для деревянных моделей всё равно вряд ли даст перфоманс выше, чем с label encoding. В общем, при выборе энкодинга обычно не на вариативность смотрят, а на наличие порядкового отношения в фиче и на выбранную модель.
Так зачем вы тогда рисовали этот график, если ни вы, ни читатель не понимают, какие выводы из него делать?
Вычитывайте, пожалуйста, такое перед публикацией.
Вам стоило по меньшей мере указать метрику и объяснить, почему здесь получилось 0.5.
Стоит уточнить, что далеко не каждая модель позволяет так просто «посмотреть на важность признаков». В данном случае используется фишка деревянных ансамблей.
1. Понимание проблемы и ознакомление с данными
2. Чистка данных и форматирование
3. EDA
Слабо представляю, как выполнять эти пункты в таком порядке (особенно 2 и 3), если только «ознакомление с данными» в первом пункте не подразумевает по сути EDA.
У нас есть 16 столбцов, в каждом из которых от 2 до 58 разных вариантов значений.… Подхода здесь два
На самом деле, не два. Вы забыли, как минимум, mean target encoding, который появляется в топовых решениях на Kaggle чаще других.
Например, если мы имеем дело с числовым значением, то доход заемщика в 10000 однозначно больше и лучше, чем доход в 20000.
Кажется, здесь опечатка.
One-Hot-encoding, с другой стороны, более безопасен, но может плодить «лишние» столбцы. Например, если мы закодируем тот же пол при помощи One-Hot, у нас получится два столбца, «пол мужской» и «пол женский», хотя хватило бы и одного, «мужчина ли это».
Во-первых, устранение лишнего столбца для снижения мультиколлинеарности — это стандартный сеттинг OHE, который есть из коробки в том же get_dummies в pandas. Во-вторых, пол — это бинарная фича в данном случае, поэтому логично, что OHE этой фичи ничего хорошего вам не принесёт.
По хорошему для данного датасета надо бы кодировать признаки с низкой вариативностью при помощи Label Encoding, а все остальное — One-Hot, но для упрощения закодируем все по One-Hot.
Признак с низкой вариативностью, закодированный Label Encoder'ом, для логрега будет мусором. Признак с высокой вариативностью, закодированный One-Hot Encoder'ом, для деревянных моделей всё равно вряд ли даст перфоманс выше, чем с label encoding. В общем, при выборе энкодинга обычно не на вариативность смотрят, а на наличие порядкового отношения в фиче и на выбранную модель.
Синим показаны возвратные кредиты, красным — невозвратные. Интерпретировать это все довольно сложно
Так зачем вы тогда рисовали этот график, если ни вы, ни читатель не понимают, какие выводы из него делать?
При этом клиенты с 9 и 11 детьми показывают полный невозврат
…
9 2
8 2
11 1
…
Как показывает подсчет значений, эти данные статистически незначимы — всего по 2 клиента обеих категорий. Однако, все 4 вышли в дефолт
Вычитывайте, пожалуйста, такое перед публикацией.
В расчетах нужно отталкиваться от какого-то базового уровня модели, ниже которого упасть уже нельзя. В нашем случае это могло бы быть 0,5 для всех тестовых клиентов — это показывает, что мы совершенно не представляем, вернет кредит клиент или нет.
Вам стоило по меньшей мере указать метрику и объяснить, почему здесь получилось 0.5.
Самый простой метод интерпретации модели — посмотреть на важность признаков.
Стоит уточнить, что далеко не каждая модель позволяет так просто «посмотреть на важность признаков». В данном случае используется фишка деревянных ансамблей.
Спасибо, косяки постепенно поправлю, по правилам Kaggle надо уточнить
Private sharing code or data outside of teams is not permitted. It's okay to share code if made available to all participants on the forums.
Под forums подразумеваются Discussions / Kernels на Kaggle, полагаю.
Я подозреваю, тут речь об обмене какими-то фишками и решениями приватно, но вне команд. Посыл такой, что хотите работать над задачей совместно — создайте команду или пишите для всех. Про форумы тоже можно по-всякому толковать. Я что-то слышал, что нельзя шарить призовые решения, но не могу найти. В любом случае, вряд ли что-то по мотивам популярных кернелов навредит Kaggle или что-то нарушит. Если будут претензии от них — попрошу администрацию Хабра снять мою статью.
Насколько я понял из раздела кернелов, результаты ближе к топу получаются не каким-то тщательным анализом данных и составлением признаков, а тюнингом и комбинацией моделек/их результатов. От .79 можно получить просто посчитав среднее арифметическое предсказаний xgboost и lightgbm, выше по всей видимости в дело идет стэкинг.
Также было бы интересно почитать, как в этой задаче может показать себя Catboost. По заверениям ребят из Yandex он должен чуть ли не лучше всех проявлять себя в таких задачах, но вот лично у меня не получилось его «приготовить».
Про Catboost я уже в разных местах видел мнения, что он был хорошо поначалу, но теперь LighGBM показывает себя значительно лучше и в соревнованиях, и в бою. По крайней мере в кернелах я вижу именно LightGBM и XGboost, catboost ни разу пока не встречал. Я лично его не пробовал, возможно дело именно в умении готовить.
результаты ближе к топу получаются не каким-то тщательным анализом данных и составлением признаков
«Ближе к топу» — это правильное выражение. И ваше ощущение, что большинство участников так и делает, совпадает и с моим мнением. Вот те, которые реально в топе, скорее всего, имеют свои «заначки».
А два месяца на соревнование — вполне нормальный срок для тщательного анализа.
Только вот искусство тщательного анализа большинством не ценится.
По разным причинам.
Sign up to leave a comment.
Соревнование Kaggle Home Credit Default Risk — анализ данных и простые предсказательные модели