10 ошибок, которые я допустил как Data Scientist

Автор оригинала: Chris I.
  • Перевод
image

Работать в области data science бывает тяжко, но оно того стоит и, к тому же, приносит хороший доход. Некоторые действия преумножают нашу эффективность (например, отказ от использования Slack). Бездействие порой тоже бывает полезным. Ниже я расскажу о своих ошибках, которые препятствовали развитию либо моей карьеры, либо моей компании.

Непонимание того, что в Data Science существуют различные типы задач


Как-то я пришел в компанию в качестве «data scientist», рассчитывая, что буду заниматься прогнозным моделированием. Но в итоге я писал внутренний код приложения. Я ошибся.

Моя предыдущая деятельность в data science была связана исключительно с построением моделей, и я ошибочно полагал, что и новые обязанности будут аналогичными.

Множество видов задач и работ скрывается под эгидой data science. Добавьте к этому неразборчивые должностные инструкции и получите рецепт приготовления превосходной путаницы.

image

3 действительно различные задачи

Просмотрите публикации по теме data science, вы найдете рабочие задания, соответствующие следующим категориям:

  • конкурентная разведка
  • анализ данных
  • машинное обучение
  • Data engineering
  • программная инженерия

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

Отсутствие наставника


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

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

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

Никто не должен работать в такой высокотехнологичной области, как ИИ, без старшего инженера или наставника, который мог бы подбросить идей. А ведь это крайне ускоряет работу.

Не признавать провала проекта


Я убил 2 недели на то, чтобы создать новую модель и заменить ею существующую. При этом у старой модели производительность была выше.

Вместо того, чтобы больше не терять время и оставить это дело, я потратил еще 2 недели на умозрительные правки, надеясь улучшить свою модель. Но она не заработала. Мы выбросили ее вместе с двумя, потраченными впустую неделями.

Timeboxing явно давал понять, что пора уже остановиться. Но уязвленное неудачей самолюбие велело продолжать.
Timebox, а не scopebox.
— согласно Lean Software Development

Те из нас, кто работает в научных группах по data science, не имеют полного представления о приоритетах компании. Мы можем внести вклад в бесконечное количество проектов. Но некоторые провалятся, и нам нужно будет идти дальше.

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

Не делать заметок по окончанию проекта


У стартапа, в котором я трудился, изменились приоритеты, поэтому я вернулся к работе над проектом NLP, который оставил 1,5 года назад. Никаких записей об опробованных подходах или проведенных исследованиях не оказалось, и мне пришлось начинать все сначала.

С учетом того, что стартапы частенько меняют приоритеты, бывают ситуации, что вы бросаете проект, а затем вновь к нему возвращаетесь.

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

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

Тянуть с обращением за помощью


Я ненавижу тратить чужое время. Я сначала тщательно попробую каждую рекомендацию руководителя/ наставника, а только потом уже, в самом крайнем случае пойду за повторным советом. Поэтому я постоянно откладывал встречи. Хрестоматийный перфекционист.

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

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

Примите совет, опробуйте его и следуйте дальше.

Если бы вы могли преодолеть проблему самостоятельно, вам бы никто не понадобился.

Я понимаю, что с другой стороны есть люди, которые так и норовят попросить помощи, абсолютно при этом не вникнув в проблему — этот пункт к ним не относится.

Не признаваться в своей неосведомленности


Еще до того, как начать работу в области машинного обучения, я встретил своего первого наставника по ИИ за кофе.
Наставник: Вы ранее применяли машинное обучение?
Я: Да, нейронные сети
Наставник: Какие фреймворки использовали?
Я Эм… Питон.
На самом деле, все, что я знал о машинном обучении, это знания, почерпнутые из пары уроков курса по Deep Learning Эндрю Нга. Но я хотел казаться умным.

Мы все-таки стали работать вместе. Тем не менее, не притворяйтесь, что знаете вещи, о которых на самом деле толком не осведомлены. Опытные люди могут за милю учуять чушь. И легче помочь тому, кто признает свои слабости.

Обучение без проекта


Я потратил месяцы на чтение техник и теорий, которые уже не помню. Заметки и безымянные записи в блокноте Jupyter неизбежно теряются.

С другой стороны, я вспоминаю, как всякий раз узнавая что-либо новое, я включал это в рабочее приложение, публиковал код в Jupyter или писал пост в блоге.

Еще одно преимущество последнего заключается в том, что можно легко вернуться назад и сделать ссылку на рабочий код.

Возьмите на себя ответственность за какой-нибудь результат, за все, чему вы посвятили время и учились.

Неверное соотношение разработки vs. исследований


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

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

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

Избегайте недо-исследования, применяя подход первопричин при начале работы с новой проблемы.

Не записывать многоразовые функции


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

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

Вместо того, чтобы закончить проект за 30 минут и выглядеть гением, я провозился несколько часов. Я преодолел этап собеседования, пришлось туго, а могло ведь быть гораздо проще.
Чтобы сделать трудную работу, я всегда выберу ленивого человека, потому что он найдет простой способ сделать ее
— Билл Гейтс
Если обнаружите, что пишите в Jupyter один и тот же код по нескольку раз, сделайте себе одолжение и напишите многоразовый модуль.

Недооценивание важности знаний в конкретной области


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

Быть в курсе новостей отрасли и иметь знания в области — самая недооцененная часть процесса разработки программного обеспечения.

Знание предметной области приобрести труднее, нежели навыки кодирования. Они накапливаются за годы работы.

  1. Остерегайтесь инженеров, не заинтересованных в знании предметной области. В какой-то момент они зайдут в тупик.
  2. Соглашайтесь работать в стартапе только в том случае, если хотя бы один из основателей имеет большой опыт работы в отрасли, для которой создается продукт.

Заключение


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

Надеюсь, вам понравилось читать о моих ошибках. А какие ошибки, как data scientist совершали вы?

image

Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:



Читать еще


SkillFactory
Онлайн-школа по программированию

Комментарии 0

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое