Добро пожаловать в другой пост, документирующий мой прогресс в решении проблемы Kaggle, упомянутой в Части 1, где я буду пытаться различными методами улучшить предсказуемость моих моделей, когда дело доходит до определения того, является ли твит о реальной чрезвычайной ситуации / катастрофе. Сегодня мы рассмотрим еще один столбец в данных, чтобы использовать некоторые функции и потенциально найти новую переменную, которая поможет нашей модели в ее прогнозах.

В прошлый раз мы использовали термин «частота-обратная частота документа» для самих твитов как единственную особенность нескольких моделей. Цель будет заключаться в реализации других функций в дополнение, чтобы увидеть, могут ли какие-либо модели их использовать. Напоминаем, что наши данные нам предоставили в таком формате:

Чтобы немного очистить фрейм данных, мы начали с заполнения любых нулевых значений в столбцах ключевые слова, а также удаления любых «странных» местоположений. Это касается мест, в которых есть странные символы или пробелы, а также мест, в которых есть числа или слишком много слов. Мы также заполнили нулевые значения простой надписью «Отсутствует». Выполнив небольшую инженерию функций, нам удалось выжать пару дополнительных функций из предоставленных нам данных (хотя мы должны помнить о мультиколлинеарности с этими новыми функциями). Наш улучшенный фрейм данных выглядит так:

Итак, первая функция, которую мы попробуем дополнить к модели, будет количество слов в твите, помеченных как num_words в нашем фрейме данных. Важно помнить, что значения TF-IDF, которые мы вычислили ранее, хранятся в разреженной матрице (матрице, в которой большинство значений, то есть более 99,99%, равны нулю). Это означает, что нам придется вытащить трюк из наших рукавов Pythonic, чтобы объединить эту форму данных с количеством слов в твитах, которые в настоящее время представлены как целые числа.

Мы решили сделать переменную num_words категориальной, объединив данные. Поигравшись с парой бункеров разного размера, я остановился на использовании трех бункеров, распределяя данные довольно равномерно. Теперь, когда корзина, к которой принадлежит каждый твит, размещается в новых столбцах, в игру вступает магия возможности комбинировать эти переменные. Используемый инструмент - это cikit-learn DataFrameMapper. Это позволяет нам применять разные преобразования к разным столбцам, эффективно позволяя обрабатывать разные типы данных одновременно. Давайте посмотрим на визуализацию, чтобы лучше понять. Фрейм данных функции с категориальными ячейками «num_words» с горячим кодированием выглядит так:

И средство сопоставления позволяет нам выбирать, что мы хотим сделать с каждым столбцом - в этом случае мы просто хотим, чтобы TF-IDF векторизовал текст, и ничего больше. Итак, наш маппер выглядит так:

После подгонки картографа к нашему фрейму данных мы получаем объект, который будет использоваться в качестве входных данных для наших моделей! После небольшого поиска по сетке мы обнаружили, что модель Multinomial Naive Bayes работает лучше всего, но едва ли лучше, чем при использовании только TF-IDF векторизации твитов в качестве функции. Это наводит меня на мысль, что в данных по-прежнему слишком много шума, который мы попытаемся устранить с помощью дальнейшей очистки / разработки функций.

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

Спасибо за чтение, пожалуйста, свяжитесь с нами, если у вас есть какие-либо мысли о проблеме или о том, как мы ее решаем!