Введение

В процессе построения модели переоснащение требует больших усилий. Диагностика переобучения данных иногда очевидна, когда производительность ваших обучающих данных намного лучше, чем проверка, но не всегда. Понимание первопричины сбоя требует много времени, особенно в производственной среде. Мы пробуем множество методов, чтобы убедиться, что мы не переобучаем обучающие данные и хорошо обобщаем, проверяя производительность модели на данных перекрестной проверки.
Переобучение на высоком уровне означает, что наша модель опирается на функции из обучающих данных, что не соответствует действительности. t хорошо обобщать тестовые данные. Есть много причин, по которым модель не соответствует данным. При обучении с учителем переобучение происходит, когда наша модель улавливает шум вместе с базовым шаблоном в данных или, возможно, ей не предоставлены все достаточные вариации как из обучающего, так и из тестового сценариев.
Но рассмотрим сценарий, в котором у вас есть тестовые данные за разные периоды времени, когда изменилось множество шаблонов. В случае обнаружения мошенничества с кредитными картами мошенники могли полностью изменить свои методы ведения мошенничества. В случае использования прогнозирования цен рынок мог измениться. Это очень важные факторы при построении моделей в долгосрочной перспективе.

Рассмотрим ситуацию: примеры обучения и тестирования происходят из одного и того же распределения, так что ошибка проверки должна давать хорошую оценку ошибки теста, а классификатор должен хорошо обобщаться на невидимые примеры тестирования.

Проблема с обучающими примерами, которые отличаются от тестовых примеров, заключается в том, что проверка не годится для сравнения моделей. Это потому, что примеры проверки берут начало в обучающем наборе. Таким образом, наша оценка перекрестной проверки, которая может показать надежность модели, будет иллюзией.

Решение

Решение - состязательная проверка. Это причудливый термин, довольно популярный в соревнованиях Kaggle, но это довольно простой метод, позволяющий избежать переобучения и, что более важно, понять, какие переменные в вашем наборе данных вызывают проблему.

Что такое состязательная проверка?

Состязательная проверка на основе FastML: Состязательная проверка. Общая идея состоит в том, чтобы проверить степень сходства между обучением и тестами с точки зрения распределения функций: если их трудно различить, распределение, вероятно, похоже, и должны работать обычные методы проверки.
Кажется, это не так, поэтому мы можем подозревать, что они совсем другие. Эту интуицию можно количественно оценить, объединив наборы поездов и тестов, присвоив метки 0/1 (0 - поезд, 1-тест) и оценив задачу бинарной классификации. Для состязательной проверки мы хотим изучить модель, которая предсказывает, какие строки находятся в наборе обучающих данных, а какие - в наборе тестов. Поэтому мы создаем новый целевой столбец, в котором тестовые образцы помечены 1, а образцы поездов - 0.
Note: The Performance of this model will be indicator of how big the problem is..

СЛУЧАЙ 1: Набор данных прогнозирования ссуды

В данном случае мы возьмем пример набора данных прогнозирования ссуды из Analytics Vidhya. Набор данных касается прогнозирования права на получение ссуды для компании Dream Housing Finance.

Мы отбросим столбец ID и столбцы статуса ссуды из обучающего и тестового DataFrame и объединим их, создав фрейм основных данных и добавим еще один столбец dataset_label.

Я попытался увидеть распределение данных поезда и набора тестов через график UMAP. Из графика видно, что поезд и тестовый набор происходят из одинакового распределения. Таким образом, в идеале модели будет очень сложно отличить поезд от тестового набора от основных данных.

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

Кривая ROC выше предназначена для набора данных проверки, и значения приближаются к 50%, что указывает на то, что трудно различить поезд и набор тестов, и они происходят из одного и того же распределения.

Таким образом, в этом случае наш обычный метод для расслоенной проверки разделения поездов должен работать нормально и будет одинаково хорошо работать на тестовом наборе Unseen.

Случай 2: прогноз цен на рынке жилья в России

Это набор данных о соревнованиях Kaggle для прогнозирования цен. В этом соревновании Сбербанк предлагает Kagglers разработать алгоритмы, которые используют широкий спектр функций для прогнозирования цен на недвижимость.

Набор данных: https://www.kaggle.com/c/sberbank-russian-housing-market

Я попытался сопоставить подготовленные данные Adversarial с меткой 1/0 для обучения / тестирования, и мы ясно видим, что оба они принадлежат к разным пространствам функций, поскольку имеют существенные различия. Поэтому будет справедливо предположить, что модель будет легко различать их и будет иметь хороший AUC по сравнению с Case-1.

Мы обучаем похожие наборы данных о противодействии, комбинируя обучающие и тестовые наборы данных. Ниже представлена ​​тренировочная кривая ROC для модели.

Из приведенного выше графика со значением AUC, равным 0,91, это означает, что классификатору было довольно легко различать поезд и тестовый образец, просто они сильно отличаются друг от друга, и это оставляет нам высокую вероятность плохой производительности на тестовых данных. . Как указывалось в начале блога, в нашем наборе данных может быть фактор времени или рынка, из-за которого распределение функций из обучающего и тестового набора сильно отличается друг от друга.

Следующий шаг

Но чего процесс не может сделать, так это сказать нам как это исправить. Здесь нам еще нужно применить наши творческие способности. В качестве следующего шага мы можем проанализировать модель состязательности, посмотрев на важность функции. Самая важная функция помогает модели различать метки, поэтому мы можем отбросить эти функции (могут создать компромисс с производительностью обучения) и увидеть падение значения AUC. Идея состоит в том, что вы хотите удалить информацию, которая не важна для прогнозирования мошенничества / цены / неплатежей по кредиту, но важна для разделения ваших обучающих и тестовых наборов. Как я уже сказал, вначале, лучше, чем состязательная модель, а больше проблема.
Наблюдается в некоторых случаях, когда у нас есть функция, зависящая от времени, например, дату выпуска версии программного обеспечения можно заменить на «Дней с момента выпуска».

Надеюсь, идея понятна.

В следующем посте я покажу практический опыт работы с набором данных Kaggle до тех пор, пока продолжайте читать, продолжайте практиковаться.