Серия Feature Engineering
Взлом конвейера обработки данных!
Понимание данных - Take # 01
У нас есть современные передовые алгоритмы для создания совершенно захватывающих визуализаций, выявления моделей покупок потребителей на миллиарды долларов и анализа потоков доходов с использованием больших данных в сочетании с потрясающими масштабируемые механизмы аналитики. Но, будучи специалистом по анализу данных, все сводится к единой точке входа, особенно при входе в отрасль - «Где мне начать проект по науке о данных !!!»
Цель этой записи в блоге
Полный цикл проектов по науке о данных…
Существует множество онлайн-курсов, обеспечивающих полный курс обучения обобщенным моделям машинного обучения, начиная от базовых алгоритмов машинного обучения и заканчивая сложными глубокими нейронными сетями и обучением с подкреплением. Но взлом конвейера функций моделирования в области науки о данных из необработанных, беспорядочных и неполных наборов данных реального мира - одна из самых незаменимых головоломок, без которой мечта о обучении передовых моделей машинного обучения для реального мира остается невыполненной!
Кто целевая аудитория?
У вас должен быть серьезный опыт в следующих областях:
- Терминология машинного обучения
- Хорошее понимание и глубокое владение базовыми алгоритмами машинного обучения
Если у вас есть вышеперечисленное в вашем наборе инструментов, и вы в дальнейшем ищете практический опыт, чтобы развернуть процесс разработки функций от точки сбора данных до создания набора функций для повышения производительности вашей модели машинного обучения, этот пост в блоге для вас!
Результат этого учебного пособия
Мы пройдем через первые этапы конвейера разработки функций на практическом опыте работы с набором данных из реального мира недавно проведенного хакатона на WiDS Datathon 2020.
Есть несколько причин для выбора этого набора данных, перечисленных ниже:
- Это не игрушечный набор данных для отработки алгоритмов машинного обучения. Фактически, это реальный набор данных, и он требует эффективного процесса разработки функций для обучения модели машинного обучения с хорошей производительностью.
- Имеет множество пропущенных строк и множество проблем с данными, с которыми вы точно так же столкнетесь в своих повседневных проектах по науке о данных.
- После полной проработки вы начнете понимать ценность разработки функций и почему стоит тратить время на игру с вашим набором данных!
4. Задача состоит в том, чтобы создать модель, которая использует данные первых 24 часов интенсивной терапии для прогнозирования выживаемости пациентов (метка: Hospital_death). Инициатива сообщества GOSSIS Массачусетского технологического института с сертификатом конфиденциальности Гарвардской лаборатории конфиденциальности предоставила набор данных о более чем 130 000 посещений больничных отделений интенсивной терапии (ICU) пациентами в течение одного года. [Источник]
5. Подробное описание задания можно найти здесь.
Как следовать вместе с этим пошаговым руководством по проекту BlogPost?
Я предлагаю прочитать и понять общий мыслительный процесс, а затем настроить мыслительный процесс , определенный здесь, на реальном наборе данных по вашему выбору.
Достаточно сказано, приступим!
Определение дорожной карты… .. 🚵
Этап №1: разработка функций и ее незаменимая ценность!
А затем: полный обзор проектов на ранних этапах процесса разработки функций
Этап №2: понимание функций
Этап №3: улучшение функций
Этап №4: базовая модель обучения
И наконец, заключительные замечания…
Разработка функций и ее незаменимая ценность!
Что такое разработка функций?
Процесс анализа / моделирования / извлечения функций из необработанных данных.
Задача разработки функций?
Функции - это те атрибуты вашего набора данных, которые включают в себя базовые шаблоны данных, и, следовательно, извлечение / моделирование функций из ваших атрибутов необработанных данных подразумевает высокий прирост производительности вашей модели!
Интересные факты о проекте Data Science. Как правило, специалист по анализу данных тратит 80% времени проекта на разработку функций и только 20% на обучение новейшим моделям. Фактически, разработка функций - самая ценная, но недооцененная часть любого проекта в области науки о данных. Эффективная разработка функций оплачивает тяжелую работу, и вы скоро начнете осознавать ее достойную важность, как только начнете погружаться в наборы данных реального мира!
Фактически, вот хорошо объясненное чтение, чтобы понять важность разработки функций
Осмотр проекта на ранних этапах процесса разработки функций
Этап №2: понимание функций
Понимание функций фокусируется на «понимании ваших данных», и под этим я подразумеваю тщательное изучение вашего набора данных в соответствии со следующей дорожной картой (это не жестко запрограммированная дорожная карта для всех данных. научный проект!) :
Вы можете найти полный код проекта здесь
1. Проверьте, структурированы ли ваши данные или нет. В этом сообщении в блоге мы будем иметь дело только со структурированными данными.
2. Проверьте наличие строк и столбцов в вашем наборе данных.
3. Вычислить описательную статистику
4. Определите типы данных в вашем наборе данных и определите, на каком из четырех уровней данных находится каждый атрибут.
Сопоставьте ваши типы данных с категориальными и числовыми типами данных. Кроме того, ищите порядковые и номинальные категории, а также интервалы и отношения для числовых типов данных. Это обеспечит вам основу для вашего EDA! Вы найдете более подробный EDA в Github Repo Jupyter Notebooks (давайте сделаем его кратким для этого сообщения в блоге). Кроме того, EDA продолжается на всех итерациях любого проекта Data Science, как описано далее в этом сообщении в блоге.
Этап №3: улучшение функций
Очистка данных
Улучшение функций связано с очисткой данных, и только на основе понимания ваших данных вы сможете продолжить разумную очистку набора данных.
Точнее, очистка данных касается:
Выявление пропущенных значений на основе типов данных и а затем определение стратегии работы с ними. Например, строковые типы данных могут быть закодированы как пустые строки как отсутствующие данные, а числовые данные могут быть закодированы как NaN или просто «0» для обозначения пропущенных значений. Кроме того, удаление отсутствующих значений не было бы разумным шагом, если, отбрасывая отсутствующие строки, у вас осталась только половина вашего набора данных или было удалено значительное количество строк. С другой стороны, вменение пропущенных значений зависит от того, какая конкретная стратегия вменения может наилучшим образом заполнить пропущенные значения.
Некоторые из методов вменения отсутствующих значений:
- Замените отсутствующие значения средним, медианным или режимом. Это опять же зависит от вашего понимания данных. Например, для номинальных типов данных режим only может быть быстрой стратегией для заполнения пропущенных значений. Но для порядковых и более высоких уровней атрибутов данных среднее и медианное значение также могут быть жизнеспособными кандидатами, заслуживающими изучения.
- Для атрибутов, имеющих большое количество пропущенных значений, вменение пропущенных значений через другую обученную модель также может быть одной из подходящих стратегий.
Продолжение проекта по науке о данных без выявления пропущенных значений - это немедленная попытка поразить ваши результаты, особенно когда вы будете использовать агрегатные функции (точнее, наши самые любимые значения СРЕДНЕЕ и СЧЁТНОЕ), и кроме этого, есть множество случаев, когда хорошо. Тенденции будут полностью противоположными, и, в конце концов, вы вернетесь к неверному среднему значению, вычисляемому, рассматривая «0» как допустимое значение переменной вместо отсутствующего значения. То же самое и со строковыми значениями! Пустые строковые значения по-прежнему будут отображаться в функциях counts. Чтобы избежать этого, вы должны кодировать числовые пропущенные значения как правильные «NaN» и строки для некоторых других отсутствующих идентификаторов.
Вывод: чтобы определить отсутствующие значения, сначала убедитесь, что они правильно закодированы как отсутствующие значения! Затем, следует ли отбрасывать отсутствующие значения или вменять их и, кроме того, выбирать критерии вменения, все зависит от того, какой тип проблемы с данными у вас в руке, а также от того, с какими ограничениями проекта с точки зрения аппаратных ресурсов и времени вам придется столкнуться.
Довольно теории - сопоставление приведенной выше постановке проблемы
Давайте проверим распределение пропущенных значений по каждому столбцу в нашем наборе данных.
График дает четкое представление о различном распределении процента пропущенных значений от почти 0% до 90%. Ух ты! Для этого проекта это одна из самых серьезных проблем с данными, а также что-то самое полезное, если исправить это правильно.
Кроме того, распространители наборов данных предоставили полный словарь данных, который необходимо детально изучить, чтобы исследовать дальнейшие измерения данных, что наиболее важно, если отсутствующие значения могут быть закодированы каким-либо другим способом, кроме нулей и пустых строк!
Даже если бы документация не была предоставлена, нам все равно нужно было бы копнуть глубже в атрибутах, чтобы понять, какие значения отсутствуют. Например, такие атрибуты, как «высота» и «bmi» никогда не могут быть равны нулю! Если для таких атрибутов присутствует ноль, это означает, что в наших данных отсутствуют значения!
Давайте проверим, сколько строк имеет хотя бы одно пропущенное значение в нашем наборе данных
Только 25 строк из всего набора данных из 91688 содержат полные значения! Поэтому очевидно, что их отбрасывание - неразумный шаг. Кажется, что почти во всех остальных строках отсутствуют значения. Давайте углубимся в то, какие столбцы имеют полные значения строк.
Поскольку мы не можем отбрасывать строки с пропущенными значениями, вместо этого давайте сосредоточимся на столбцах, указанных выше, поскольку наша цель - обучить базовую модель. Кроме того, также обратите внимание, что есть 4 столбца идентификаторов, которые не связаны с прогнозом, поэтому мы бы их отбросили. Это оставляет нам 6 подмножеств столбцов (исключая столбец меток) из 185 атрибутов.
Этап №3: модель контрольных показателей обучения
Изучение подмножества функций
На данный момент у нас есть подмножество из 6 функций без многих пропущенных значений. Набор функций состоит из следующих атрибутов данных:
1. elective_surgery 2. icu_stay_type 3. icu_type 4. pre_icu_los_days 5. readmission_status 6. apache_post_operative
Ярлык / переменная прогноза
hospital_death
EDA распределения типов данных
- Распределение типов данных в соответствии с типами данных определяется распространителем данных (например, WiDS)
2. Распределение типов данных как прочитанных из необработанного файла csv
Приведенный выше простой EDA показывает, что довольно много двоичных / логических типов данных превратились в «числовые» типы данных в читаемом файле. Будучи опытным специалистом по обработке данных, чрезвычайно важно внимательно следить за этими мельчайшими деталями!
Позвольте мне соединить это со сценарием из реальной жизни. Кодирование двоичных / логических переменных как числовых не представляет никакого вреда, но это приведет к накоплению в памяти двоичных / логических переменных, которые занимают меньше байтов по сравнению с объектами с плавающей запятой! И если вам уже не хватает памяти, эти крошечные логические байты, преобразованные как числа с плавающей запятой, в совокупности складываются в большие байты и уничтожают вашу память! Опять же - разбирайтесь в своих данных как можно точнее!
#savvy - всегда стоит читать источники документации, которые прилагаются к вашим данным. Они дадут вам четкое представление о данных. Например, благодаря документации, которую я прочитал, мне было относительно проще гарантировать, что предоставленные типы данных и закодированные типы данных имеют один и тот же тип с помощью документации.
Кроме того, для числовых столбцов вы можете декодировать с помощью документации, что отсутствующее значение может быть закодировано как «0». Легко расшифровать «0» в таких переменных, как возраст, рост и bmi (потому что у нас уже есть знания в предметной области), но документация открывает новые способы исследования, когда наши собственные знания предметной области недостаточны.
Например, в данном наборе данных может быть несколько других атрибутов, которые могут содержать массу пропущенных значений, и для меня, как человека с немедицинским образованием, документация и совместные обсуждения с экспертами в предметной области обеспечат более глубокий уровень понимания данных.
Фактически, тесное сотрудничество с экспертами в предметной области также является незаменимой практикой опытного специалиста по данным для анализа данных из различных невидимых измерений и, следовательно, повышения производительности!
Продолжение EDA ..
Примечание. Графики ниже соответствуют типам данных / столбцам, которые вообще не имеют пропущенных значений, то есть столбцам, перечисленным слева от вас.
3. Распределение типов данных для типов данных чтения файлов после удаления пропущенных значений и выбора подмножества из 6 функций показывает
4. Дальнейшее углубление в приведенную выше визуализацию - Распределение типов данных после дальнейшего сопоставления типов данных чтения файла для определения предоставленных типов данных
Итак, 4 из 8 целочисленных переменных разложены на логические типы данных.
Теперь, когда у нас есть все фиксированные типы данных, при удалении столбцов на основе идентификаторов из более чем 11 столбцов остается 7 столбцов (включая столбец меток). За исключением pre_icu_los_days, все атрибуты имеют категориальный характер.
По умолчанию pd.DataFrame.describe () показывает статистику только непрерывных / числовых переменных. Также,
2. Бросьте дубликаты!
Нам необходимо проверить наличие дубликатов в исходном наборе данных и выбранном подмножестве набора данных по 6 столбцам набора функций.
Итак, у нас изначально было 91713 строк, из которых уникальные строки для выбранных 6 функций составляют только 19438! Есть два чрезвычайно важных момента, которые я хотел бы здесь подчеркнуть:
- Всегда следите за тем, чтобы набор данных, вводимый в вашу модель, состоял из уникальных строк! В противном случае вы добавили бы время вычислений без всякой причины, а в реальном мире время уже является ограниченным ресурсом для соблюдения сроков проекта. Это также могло снизить производительность.
- Если вы заметили, общее количество строк для 6 выбранных функций составляет 91713, то есть равно строкам самого набора данных. НО, удаление дубликатов для выбранных 6 функций показывает ТОЛЬКО 19438 строк! А теперь представьте себе разрушительные эффекты, которые это могло бы произойти, если бы я пропустил этот шаг удаления дубликатов и продолжил обучение модели KNN, которая имеет «k» в качестве важного гиперпараметра! Модель сильно пострадает не только от времени вычислений, но и с точки зрения производительности!
- Отбрасывая дубликаты на основе набора функций, я оставил параметр keep для drop_duplicated «False» вместо «first»
Причина keep = False?
Использование keep = first привело бы к появлению шума! Почему? Поскольку, рассматривая фрейм данных, основанный на 6 функциях, у вас будут разные метки для одних и тех же строк. Поэтому я решил отбросить все эти вводящие в заблуждение строки (на самом деле они не вводят в заблуждение, но на основе 6 функций, да, это так). Если вы вызовете unique для всего фрейма данных этих 6 функций и метки, вы получите 91713 строк, но это совершенно неверно, если мы намерены кормить набор функций только на основе 6 столбцов (что в настоящее время имеет место для базовой модели)
#Savvy - Опять же, эти, казалось бы, незначительные моменты всегда будут иметь огромное влияние на вашу модель - Осторожно!
Также обратите внимание, что на данный момент мы изучаем ~ 20% набора данных только для нашей базовой модели! Да, мы можем использовать базовую модель, но в то же время она показывает:
- Производительность модели была бы явно низкой, если, говоря гипотетически, нам не повезло, что подмножество из 6 выбранных атрибутов состояло ТОЛЬКО из функций (ценных атрибутов)!
Что касается вышеупомянутого пункта, мы вовсе не являемся слепым пятном для улучшения в последующих итерациях. Понимание достоверности вышеизложенного может быть обеспечено путем корреляции атрибутов / столбцов с меткой и проверки, включены ли значимые столбцы с более высокими корреляциями в 6 атрибутов или нет. Кроме того, если имеется значительное изменение в распределении меток за счет рассмотрения только подмножества из 6 атрибутов, форма данных должна была измениться, и, следовательно, это также будет учитывать низкую производительность (точнее, дисбаланс данных).
Возможности для улучшения существуют в более поздних итерациях, когда мы будем добавлять больше столбцов и, следовательно, больше строк (уникальных строк).
Матрица корреляции
#savvy - Еще одно озарение! Столбец readmission_status не отображается в корреляционной матрице! Если глубже изучить его уникальную ценность, можно увидеть:
Это все неверно для выбранного подмножества столбцов и строк! Следовательно, мы бы тоже отбросили этот столбец, поскольку он не будет играть никакой роли в извлечении шаблонов или генерации прогнозов!
#savvy - простой EDA и такая ценная информация. Снова минутное наблюдение, но оно того стоит!
Базовая модель обучения
К настоящему времени у нас есть 5 столбцов, и мы можем приступить к обучению базовой модели. Обратите внимание, что у нас есть две категориальные «строковые» переменные / атрибуты, и нам потребуется некоторое числовое преобразование, прежде чем вводить данные в обучающую модель. Для этого мы будем использовать фиктивную кодировку в нашем конвейере предварительной обработки данных.
Мы будем использовать KNN в качестве классификатора. Разделение набора данных, фиксация категориальных переменных, масштабирование (стандартизация Z-оценки) и поиск по сетке для «k» - все это было добавлено в конвейер предварительной обработки данных (точнее, компоненты конвейера sklearn).
Подгонка и преобразование данных с помощью конвейера и вызова подгонки показывает:
- Количество обучающих рядов: 14578
- Количество обучающих столбцов: 12 (количество столбцов увеличилось с 5 до 12, поскольку во время преобразования добавлено (n-1) столбцов для каждой категориальной переменной, т. Е. Фиктивно закодировано), где n соответствует общему количеству уникальных значений для каждой категориальной строковой переменной. Кроме того, логические категориальные переменные не подвергались никаким преобразованиям фиктивной кодировки или стандартного масштабирования.
- На данный момент лучший k равен 99, поскольку перекрестная проверка со следующими кандидатами
Тестирование базовой модели
- Тестовые ряды: 4860
- Столбцы тестирования: 12
- ROC_AUC: 0,72 - (совсем неплохо, учитывая, что использовалось только 20% набора данных с 5 столбцами)
Прогнозы Kaggle
Большой! позволяет предсказать для набора тестов Kaggle
Стоит упомянуть
Стоит проверить, сколько значений тестового набора действительно существует и сколько уникальных значений тестового набора существует, учитывая подмножество функций из 5 столбцов, которые у нас есть прямо сейчас
#savvy - Проницательность! Таким образом, учитывая только 5 столбцов для набора тестов, мы фактически прогнозируем только 9768 строк набора тестов из 39308 строк, что составляет всего 24%! На данный момент мы рассматриваем большинство строк тестового набора как одни и те же, что не так, но это также означает, что есть много возможностей для потенциального увеличения производительности модели (и, следовательно, представления Kaggle).
Подсчет очков Kaggle
Скоринг дает 0,59035! Это лучше, чем модель с наименьшими показателями в таблице лидеров 😅
А вот краткий обзор базовой модели.
Схема прохождения проекта
И, наконец, вот блок-схема всего процесса, который мы делали до сих пор.
Заключительные примечания…
Важность базовой модели обучения
Пока что у нас есть хорошая базовая модель. Базовая модель служит эталоном для повышения производительности. Мы продолжаем добавлять компоненты в наш конвейер разработки функций и сравниваем недавно полученную производительность с каждым добавленным компонентом с базовой моделью, чтобы оценить, насколько хорошо мы поднялись по лестнице прироста производительности.
Не сомневайтесь - без надлежащей практики разработки программного обеспечения не обойтись !!!
Хотя я не включил фрагменты кода в это сообщение в блоге, но вы можете найти полный код проекта в моем Github Repo. В реальных проектах Data Science мы строго следуем принципам ООП и конвейерному подходу. Добавление новых компонентов к конвейерному подходу довольно просто. Ваш код будет легче повторно использовать, поддерживать, отлаживать и продавать по мере поступления новых вещей. Это также означает, что на более поздних итерациях у вас будет больше времени на решение самой проблемы.
Если вы мне не доверяете, возьмите исходный код любого фреймворка Python для науки о данных, и вы сможете проанализировать все применяемые принципы программной инженерии!
Красота проектов в области науки о данных!
Хотя есть стандартные шаги, которым нужно следовать в конвейере разработки функций для любого проекта Data Science, но есть бесконечное творчество, которое сопровождает каждый набор данных! Чем больше вы погружаетесь в разработку функций, тем больше вы вынуждены мыслить нестандартно, анализировать проблемы с вашими данными, исследовать возможные решения не только для разработки функций, но и для машинного обучения, и продолжать повышать свой уровень знаний в области науки о данных и ВЕСЕЛЬЕ никогда не заканчивается!
Предстоящая публикация будет включать:
- Продолжение того же пошагового обзора проекта для следующих этапов конвейерной разработки функций.
- AUC_ROC, чтобы превзойти, будет 0,59035
Будьте на связи ! 📻
Если у вас есть какие-либо мысли, комментарии или вопросы, не стесняйтесь оставлять комментарии ниже или связываться 📞 со мной в LinkedIn
