Этот материал был подготовлен как групповая курсовая работа для университетской аттестации вместе с двумя друзьями, Разваном Милициным и Франсуа Гаусом. Курсовая работа позволила нам выбрать любое прошедшее или настоящее соревнование Kaggle, изучить данные и построить различные модели машинного обучения, чтобы увидеть, как они будут работать.

Мы выбрали конкурс Microsoft Malware Prediction. Задача состояла в том, чтобы предсказать, будет ли машина поражена вредоносным ПО, на основе набора функций, предоставляемых Microsoft. В этой статье мы представим различные особенности, которые мы обнаружили в данных.

Введение

Описание каждой функции можно найти здесь. В этом разделе мы представим обзор проблем, с которыми сталкивается этот набор данных. Во-первых, мы представим подход, использованный при изучении данных, и решения, принятые для функций с отсутствующими и смещенными значениями. Далее мы объясним, почему большинство признаков можно рассматривать как категориальные, и как мы их закодировали, чтобы их можно было в дальнейшем использовать в наших моделях. Наконец, мы покажем, как мы обнаружили и преодолели проблему, связанную с наличием функций управления версиями с непересекающимися значениями в наборах данных обучения и тестирования.

Отсутствуют данные

Первым шагом в исследовании данных является просмотр значений с высоким процентом отсутствующих значений. Мы решили отказаться от тех, у которых очень большой процент отсутствующих значений, таких как PuaMode (99% нулевых значений), Census ProcessorClass (99% нулевых значений) и DefaultBrowsersIdentifier (95% нулевых значений и действительные значения не имеют значимой разницы).

Следующим шагом будет рассмотрение типов пропущенных значений или анализ и диагностика механизма пропущенных данных. Три типа отсутствующих типов данных отсутствуют полностью случайным образом (MCAR), отсутствуют случайно (MAR) и отсутствуют неслучайно (MNAR) и будут определять, как мы поступаем со столбцами, в которых есть отсутствующие данные. Если данные представляют собой MCAR, отсутствующие данные распределены равномерно, и отсутствие данных не зависит от других переменных, наблюдаемых или ненаблюдаемых. Если отсутствующие данные классифицируются как MAR, то отсутствующие данные зависят от наблюдаемых данных. MNAR - это когда отсутствие коррелирует как с отсутствующими, так и с наблюдаемыми точками данных, отсутствующие данные соотносятся с фактическими значениями отсутствующего значения. Мы не можем измерить, являются ли данные MAR против MNAR, так как для этого мы должны были бы иметь возможность наблюдать и измерять отсутствующие данные.

Самый простой способ сделать вывод о характере пропажи — это знание процедуры сбора данных. К сожалению, недостаточно информации о процессе сбора или отбора проб. Лучшей альтернативой является визуальное исследование отсутствия данных. На рисунке ниже мы можем наблюдать матрицу nullity (мы использовали внешний модуль), показывающую полноту столбцов. Показаны столбцы с процентными отсутствующими значениями до 0,5%. Это позволяет нам визуально проверять любые очевидные закономерности в отсутствующих данных. Отмечено наличие нескольких столбцов со значительным количеством пропущенных значений. Есть также столбцы, в которых отсутствуют данные в одних и тех же/похожих строках. Это Census_OEMNameIdentifier и Census_OEMModelIdentifier, Wdft_isGamer, Wdft_RegionIdentifier, три функции, связанные с основным дисплеем, Census_PrimarydiskTotalVolume и Census_SystemVolumeTotalCapacity. Это позволяет визуализировать структуру недостающих данных. Похоже, что в отсутствующих данных нет какой-либо серьезной закономерности.

Кроме того, на рисунке ниже мы видим тепловую карту, которая измеряет корреляцию недействительности. Тепловая карта показывает, как отсутствие или отсутствие одной переменной соотносится с отсутствием или отсутствием другой переменной. Корреляция -1 представляет собой отношение, при котором если одна переменная появляется, то другая нет. И наоборот для соотношения 1.

Существует несколько способов обработки пропущенных значений. Самый простой — выполнить удаление строк или пар. Другой метод заключается в использовании импутации. Самое простое — заменить отсутствующие значения средним или медианой существующих (для числовых признаков), модой (для числовых и категориальных). Эти два метода, хотя и просты, уменьшают дисперсию. Другой подход заключается в использовании подхода на основе моделей, что означает построение модели для прогнозирования пропущенных значений. Более продвинутые меры включают использование случайных лесов для данных MAR и NMAR. Этот подход использует несколько деревьев решений, используемых для оценки отсутствующих значений, и выводит оценки ошибок вменения «из коробки». Лучше всего работает с большими наборами данных. Другим решением является использование многомерного вменения с помощью цепных уравнений. Это предполагает, что данные отсутствуют случайным образом, а модель вменения является переменной в зависимости от типа объекта. Прогнозное сопоставление среднего может использоваться для непрерывных функций, а логистическая регрессия может использоваться для бинарных переменных. Для факторных переменных можно использовать байесовскую регрессию и модель пропорциональных шансов для упорядоченных переменных. Нерелевантные функции должны быть удалены.

Другим важным аспектом является асимметрия или процент значений в самой большой категории. Можно заметить, что 27 признаков имеют более 90% значений в одной категории. Мы решили отказаться от функций, которые имеют более 99% значений в самой большой категории. Это Census_IsWIMBootEnabled, IsBeta, Census_IsFlightsDisabled,
Census_IsFlightingInternal, AutoSampleOptIn, Census_ThresholdOptIn, SMode, Census_IsPortableOperatingSystem, Census_DeviceFamily и UacLuaenable. Теоретически существуют методы исправления асимметрии, но, как мы увидим позже, большинство признаков являются категориальными, а не числовыми, поэтому мы не можем выполнять над ними какие-либо преобразования.

Нестационарные объекты

При изучении данных мы заметили характеристику набора данных, которая также объясняется в описании конкурса: «Обнаружение вредоносных программ по своей сути является проблемой временных рядов, но она усложняется введением новых машин». Как видно, обучающие данные были собраны в августе и сентябре 2018 года, а тест состоит из точек данных за октябрь и ноябрь 2018 года. Это означает, что мы не можем полагаться на функции управления версиями для нашей модели, и нам придется заменить их на новые черты, представляющие зависимость от времени.

Первым шагом была загрузка сопоставления функции AvSigVersion (которая представляет версию антивирусной сигнатуры) с временными метками дат, когда они были выпущены, чтобы лучше понять, когда были записаны данные. Затем мы добавили в набор данных новую функцию под названием Date, которая представляет значение сопоставления, упомянутого ранее. Последним шагом было построение графика плотности данных и скорости обнаружения с течением времени. Плотность представлена ​​сплошными линиями, а частота обнаружения представлена ​​пунктирными линиями. На основе следующих графиков можно сделать несколько замечаний. Как упоминалось ранее, в августе и сентябре наблюдается значительный всплеск количества точек данных в обучающей выборке, в то время как аналогичный всплеск появляется в тестовой выборке, но в октябре и ноябре. Во-вторых, можно заметить, что количество обнаружений увеличивается пропорционально количеству точек данных.

Одним из возможных методов тестирования нестационарных функций является выполнение состязательной проверки, при которой тестовые и обучающие данные объединяются, добавляется функция для тестирования и обучения как isTest, а затем они объединяются. Затем используется классификатор, чтобы указать, является ли точка данных тестовыми или обучающими данными. В идеале мы хотим, чтобы показатель AUC был равен 0,5, поэтому классификатор будет не лучше, чем угадывать, являются ли данные тестовыми или обучающими.

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

Категорические признаки

Хотя многие функции выглядят числовыми, большинство из них являются категориальными. Единственный по-настоящему числовой столбец — Census_SystemVolumeTotalCapacity. Другие являются категориальными и представляют такие данные, как версии и идентификаторы. Для представления категориальных переменных мы учитываем пять различных кодировок, которые можно использовать на основе распределения признака или алгоритма, выбранного на втором этапе.

Кодировка категорий

Мы оставляем функцию как категорию и потенциально группируем их в меньшее количество важных категорий. Алгоритмы live Decision Tree Classifier и LightGBM могут принимать категориальные переменные, но большинство других алгоритмов их не принимают.

Двоичное кодирование

Для каждой категории объекта добавляется новый столбец. Столбец, соответствующий категории, будет иметь значение 1, а другой будет иметь значение 0. Проблема с этим кодированием заключается в том, что если у объекта много категорий, размер набора данных будет экспоненциально увеличиваться. В приведенном примере мы видим, что 10% значений относятся к категории ExistsNotSet. Однако для этой категории процент обнаружения вредоносных программ составляет 80%. Эта
переменная не зависит от времени, поэтому мы можем двоично закодировать, принимает ли переменная значение ExistsNotSet или нет.

Числовое кодирование

Это используется, когда категориальная переменная представлена ​​в числовом виде (например, версии), и мы можем наблюдать корреляцию между естественным порядком чисел и значением этой категории. Определив порядок, мы можем закодировать каждое вхождение этого исходного числа с его ранговым номером. Логика этого заключается в том, что обычно мы не хотим использовать категориальные признаки в качестве числа, поскольку алгоритмы сделают вывод, что существует порядок. Однако существует порядок значений. В этом случае мы можем наблюдать тенденцию в пропорции категории, когда она построена против AvProductsInstalled числового значения. Кроме того, эта переменная также не зависит от времени. Следовательно, мы можем численно закодировать эту функцию.

Частотное кодирование

Как следует из названия, в этой ситуации мы просто кодируем функцию, заменяя категорию подсчетом того, сколько раз встречается определенное значение (частота этого значения) в этой категории. Для Census_OSInstallTypeName мы можем видеть тенденцию в пропорции категории, построенную по отношению к ней. Кроме того, это не зависит от времени, поэтому мы можем кодировать его по частоте.

Целевая кодировка

Здесь мы должны рассчитать долю случаев, когда HasDetections имеет значение 1 в пределах категории. Далее мы заменяем каждое вхождение этого значения пропорцией. Как видно из графиков, функция не зависит от времени. Кроме того, он не может быть закодирован в двоичном виде, поскольку имеет 222 категории. Он также не может быть закодирован по частоте, потому что нет корреляции со скоростью обнаружения, ни числовое кодирование. Следовательно, мы можем только таргетировать его, так как это единственная корреляция, которую мы нашли.

Функции управления версиями кодирования

Как упоминалось ранее, некоторые функции, такие как Census_OSVersion, AvSigVersion, EngineVersion и AppVersion, зависят от времени, а некоторые из них не имеют никакого перекрытия между набором обучающих данных и набором тестовых данных. Чтобы заменить эти переменные, мы можем создать новый столбец, который фиксирует временную скорость наблюдения. Например, мы можем закодировать количество недель, прошедших с начала 2018 года, и проверить, есть ли связь между прошедшим временем и уровнем обнаружения. Наконец, мы можем увидеть тенденцию частоты.

Заключение

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

Связаться

Если вы хотите связаться со мной, вы можете связаться со мной на одной из следующих платформ:

Источники

  1. https://www.kaggle.com/
  2. https://www.kaggle.com/c/microsoft-malware-prediction
  3. https://www.kaggle.com/c/microsoft-malware-prediction/data
  4. https://github.com/ResidentMario/missingno
  5. https://manishbarnwal.com/blog/2017/02/15/introduction_to_adversarial_validation/
  6. https://towardsdatascience.com/understanding-auc-roc-curve-68b2303cc9c5
  7. https://arxiv.org/abs/1604.06737