10 ошибок, которые я сделал как специалист по анализу данных

Примеры того, где вы могли ошибиться и как это исправить

Вступление

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

с большой силой приходит большая ответственность - дядя Бен

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

Ниже я перечислю 10 критических ошибок, которые я сделал в прошлом как специалист по данным, и что я сделал, чтобы исправить эти ошибки, или что я буду делать в будущем. Я надеюсь, что эти отмеченные ошибки станут полезным руководством и для вас - в вашем путешествии и работе в качестве специалиста по данным.

Ошибки

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

Пропуск объектно-ориентированного программирования (ООП) - я считаю, что мне не нужно знать программную инженерию или объектно-ориентированное программирование. Когда я изучал науку о данных, я мало знал о кодировании или распространенных, разных языках, таких как Python или R. У меня был некоторый опыт работы с SQL, но Python, мой основной язык программирования сейчас, постепенно вводился и использовался только как способ существенно манипулировать моделями и библиотеками науки о данных. Вводя больше ООП, вы можете разбить свой код на модули, что в конечном итоге станет более масштабируемым. Когда ваш Python находится в файлах .py в формате ООП, вы сможете передать его инженеру по машинному обучению или инженеру-программисту, чтобы вашу модель можно было легко выполнить в производственной среде (вы также можете выполнить все шаги самостоятельно, если вы супер-специалист по данным или небольшая компания, у которой нет дополнительных ресурсов инженерии данных).

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

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

Здесь [3] - отличная статья о коде производственного уровня, написанная Венкатешем Паппакришнаном, доктором философии.

2. Не использую GitHub - Я написал две статьи на GitHub и Git, касающиеся науки о данных. Не стесняйтесь проверить и их, у меня будут эти две ссылки в конце этой статьи.

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

Можно легко совершить ошибку, имея сотни блокнотов Jupyter и копии файлов .ipynb только для небольших различий в коде. Лучшее решение - использовать среду GitHub для легкой и простой совместной работы.

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

Bad practice: 
Adding the next iteration for bugs
Good practice:
Add error handling

4. Отказ от написания модульных тестов - это все еще то, на чем мне нужно сосредоточить свои усилия. Большую часть времени специалист по анализу данных тратит свое время на построение модели, настройку параметров и дальнейшие итерации. Однако, когда вы начнете развертывать свои модели в производстве, модульные тесты принесут огромную пользу. Их можно использовать для учета будущих ошибок, чтобы на весь ваш конвейер не повлияло простое изменение процесса. Здесь [4] - отличная статья о модульном тестировании и науке о данных от Ори Коэна.

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

Существует официальный способ написания кода Python, называемый PEP 8, и его можно найти здесь [5].

6. Использование Jupyter Notebooks. Конечно, Jupyter Notebooks отлично подходят для начала исследовательского анализа данных и построения моделей в области науки о данных, но есть определенный момент, когда вам, вам или другому инженеру придется поместите свой код в производство и используйте такие инструменты, как Visual Studio или Sublime Text, для структурирования кода в модули .py. Вот эти полезные инструменты, перечисленные в списке:

Visual Studio
Возвышенный текст
Атом

7. Без учета времени обучения модели - при создании сложных моделей XGBoost для вашего набора данных, который состоит из 100 строк в вашем классе колледжа или, возможно, учебного пособия, как только вы попадете в 'Big Data ', вы больше не сможете легко переварить такой объем данных в свою модель, и на обучение уйдет несколько дней. Важно знать возможности моделей, с которыми вы работаете. Вы также можете прибегнуть к другим алгоритмам, которые на самом деле могут привести к большей точности, скажем, вы используете вместо этого случайный лес и ограничиваете максимальную глубину своих деревьев, вы можете повысить свою точность, снизить вероятность переобучения и значительно сократить время обучения модели. .

Еще один совет - тренировать свою модель не каждый день или каждый день, когда вы получаете новые данные, но если вы получаете определенный объем данных. Примером может быть:

train this model if we get 1000 new rows:
else:
use the previously stored model that was already trained

8. Не практикуете Soft Skills - когда вы впервые изучаете науку о данных, основное внимание уделяется построению моделей и кодированию. То, что не обязательно преподается или требует реального опыта, - это мягкие навыки, необходимые для успеха в вашей должности. Как специалист по данным, вы можете ожидать встреч с множеством нетехнических пользователей на протяжении ваших проектов. Вам нужно будет встретиться с инженерами-программистами или инженерами по обработке данных, чтобы узнать данные и откуда они берутся, затем вы встретитесь с менеджерами по продуктам и профильными экспертами, чтобы обсудить бизнес-проблему и ожидаемое решение, и, наконец, UX / UI-дизайнеры. иногда для реализации результатов вашей модели в красиво оформленном интерактивном интерфейсе. В целом, мягкие навыки отлично подходят для достижения успеха в вашей модели науки о данных, встречаясь лицом к лицу (или через видео) и объясняя процесс и результаты вашего проекта.

9. Забывание о выполнении плана обслуживания. Подобно модульному тестированию, эту часть процесса часто можно упустить из виду. Существуют такие инструменты, как CircleCI и Airflow, а также обычные средства создания визуализаций из информационных панелей, которые описывают поведение вашей модели. Для меня было важно знать, когда определенная модель не обучается, чтобы найти решения неотложных проблем, связанных с ошибками модели. Вот те инструменты, которые перечислены в списке:

CircleCI
Поток воздуха
Tableau
Google Data Studio

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

Резюме

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

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

Вот все ошибки, перечисленные для удобства просмотра: