НАУКА ДАННЫХ
Четыре вредных привычки в науке о данных, от которых трудно избавиться
Вы, вероятно, по крайней мере сделать один из них
За свою карьеру я сделал несколько хобби-проектов по науке о данных. Например, построение модели прогнозирования стоимости дома на основе xgboost, модели, которая автоматически выполняла административную работу на основе наивного Байеса, и модели ранжирования компаний с использованием Keras. Итак, я накопил некоторый опыт в области науки о данных.
Выполнив эти несколько проектов и многое другое, я заметил, что на этом пути у меня выработались некоторые плохие привычки в науке о данных. Откровенно говоря, эти привычки настолько стойкие, что попытка исправить их потребует гораздо больше усилий. Вместо этого я стал жить с этими плохими привычками в науке о данных только потому, что я ленив.
Если вы хотите прочитать статью о том, как избежать и исправить вредные привычки в науке о данных, Теренс Шин написал отличную статью под названием Пять вредных привычек, которых каждый день должен избегать ученый по данным.
В этой статье о вредных привычках рассказывается другой взгляд, и я пишу о своих вредных привычках, которые, я думаю, могут иметь отношение по крайней мере к нескольким специалистам по данным, и иногда они просто слишком ленивы, чтобы решить их самостоятельно.
1. Использование R вместо Python и наоборот
R делает некоторые вещи лучше, чем Python, а Python делает некоторые вещи лучше, чем R. Например, TidyR является явным в своем синтаксисе, а Pandas более компактен.
Вот пример фильтрации данных в R по сравнению с Python.
R - TidyR
df %>% filter('Field' == 'Hello World')
Python - Pandas
df[df.field=='Hello World']
Откровенно говоря, если кому-то кинуть код Pandas, он/она даже не догадается, фильтруется ли что-то.
Когда мне нужно выполнить очистку данных, я обычно использую R, так как это был первый язык науки о данных, который я изучил. Однако обычно, примерно после половины очистки данных, я полагаю, что мог бы использовать API, чтобы ускорить процесс очистки данных. За исключением того, что многие из замечательных API-интерфейсов проверки данных имеют только API-интерфейсы Python. Следовательно, мне нужно кропотливо воссоздать весь процесс очистки данных в Python, чтобы использовать эти API только для Python.
И наоборот, иногда я начинаю с Python, потому что загрузить блокнот Google Colab проще, чем открыть IDE на старом ноутбуке, и это Google, поэтому вы знаете, что получите IDE хорошего качества. Но опять же, к середине проекта я понимаю, что могу лучше запускать определенные алгоритмы машинного обучения в R, чем в Python, поскольку у меня больше опыта в R. Например, я могу использовать Xgboost лучше в R, чем я. в Python, потому что я понимаю, как манипулировать факторами в R, чтобы соответствовать требованиям к данным для Xgboost. Мне потребуется больше времени на очистку данных в Python, чтобы я мог загрузить это в Xgboost. Следовательно, мне снова нужно воссоздать процесс очистки данных на другом языке.
В настоящее время я не так часто использую эту вредную привычку, как раньше, из-за опыта, но иногда я впадаю в нее.
2. Всегда используйте Xgboost или Deep Learning, когда достаточно чего-то более простого
По привычке, когда я вижу структурированный набор данных, я просто использую Xgboost, не задумываясь об этом. Точно так же, когда я вижу наборы данных, содержащие только числа или изображения, я автоматически использую глубокое обучение.
Это загадка, потому что алгоритмы Xgboost и глубокого обучения не всегда являются лучшими алгоритмами для использования — во всяком случае. Это даже подтверждается Теоремой об отсутствии бесплатных обедов, которая говорит нам, что все алгоритмы машинного обучения работают одинаково хорошо, когда производительность усредняется по всем возможным задачам.
Единственная причина, по которой это важно для нас, заключается в том, что 80% времени тратится на очистку данных и только 20% времени тратится на точную настройку вашей модели, даже если она нуждается в точной настройке. Другими словами, чтобы ускорить машинное обучение, я буду очищать данные до минимальной степени и помещать их в известный мне алгоритм, который может обрабатывать практически любой тип данных без ошибок.
Например, я создал модель предсказания стоимости дома шириной в 40 столбцов (большинство столбцов были одной горячей закодированной переменной) и запустил модель через Xgboost. Он работал относительно хорошо по сравнению с фактическими продажными ценами.
Затем я сделал простую модель, используя только 6 числовых столбцов, и прогнал ее через Kmeans. Оказывается, более простой набор данных и модель работали так же хорошо, как и модель Xgboost.
Итак, получается, что я мог бы сэкономить гораздо больше времени на очистке данных, если бы я исследовал данные немного больше и начал с более простой модели, чем использование всех данных и переход к модели черного ящика, которая, вероятно, была в любом случае переобучайтесь ко всему шуму.
3. Отказ от EDA
У меня довольно плохой процесс EDA. Это двухэтапный процесс. Выясните, с какими типами данных я работаю, и подсчитайте количество строк.
Я думаю, у меня есть эта плохая привычка, потому что многие данные, которые мы получаем в настоящее время, поступают из RESTful API, где мы тщательно отбираем данные, которые входят в нашу модель, а не изучаем все возможные атрибуты.
Моя дурная привычка — работать на обоих концах крайностей. Либо добавьте все переменные в модель, либо выберите только несколько переменных, которые, я думаю, будут работать. Обычно, в конце концов, обе модели в любом случае имеют тенденцию превосходить обучающую выборку.
Скорее всего, если бы я выполнял EDA лучше, я бы вообще не создавал такие плохо работающие модели. Причина отказа от EDA довольно проста — EDA отнимает много времени. Проще говоря, очистка данных для визуализации чего-либо может занять столько же времени, сколько очистка данных для машинного обучения.
Например, если у вас есть ужасное свободное текстовое поле, и вы хотите создать категориальный график, вам придется приложить усилия по проектированию поля, чтобы получить желаемый объект, и даже тогда вы не уверены, что он будет включить в вашу модель машинного обучения. В качестве примера на ум приходит поле Имя в знаменитом наборе данных Титаника.
4. Угадывать с помощью Stack Overflow, а не обдумывать проблему
Для меня Stack Overflow похож на надежного джинна в лампе. Он редко разочаровывает, когда вам что-то нужно от него. На веб-сайте есть практически решение любой проблемы с кодированием. Но это тоже проблема. Я склонен копировать и вставлять ответы переполнения стека вместо того, чтобы думать о том, как человек, который ответил, добрался до него, а в других случаях я копирую и пропускаю подробные ответы, а не выясняю, как решить проблему.
Я предполагаю, что эта проблема связана с тем, что я так устал от очистки данных, что хочу что-то сделать в ближайшее время. Это делается для того, чтобы я мог как можно быстрее перейти к машинному обучению, что немного веселее. К сожалению, когда вы пишете так много кода, иногда вы хотите использовать ярлыки и использовать эвристику, а не использовать наиболее эффективный и читаемый код.
Заключение
Это мои плохие привычки в науке о данных. Вы также можете поделиться некоторыми из этих вредных привычек. Я полагаю, что ответ на их решение вполне очевиден, и просто подумайте стратегически, прежде чем заниматься наукой о данных, но, учитывая, что в проекте по науке о данных так много дел, у кого действительно есть время думать в наши дни?
Запланируйте сеанс DDIChat в Data Science / AI / ML / DL:
Подайте заявку на участие в программе DDIChat Expert здесь.
Работайте с DDI: https://datadriveninvestor.com/collaborate
Подпишитесь на DDIntel здесь.
