Кто такой Data Scientist

Представитель сообщества Open Data Science, ML инженер и автор Telegram-канала partially unsupervised Арсений Кравченко в статье на DEV.BY рассказал о профессии Data Scientist. 

Классическое полушуточное определение звучит примерно так: Data Scientist (далее DS) — это человек, который знает статистику лучше, чем средний software engineer, и умеет программировать лучше, чем средний статистик.

Это определение далеко не новое, достаточно правдивое, но недостаточно полное. И, чтобы как-то его расширить, я начну как раз со статистики. 

Оценивая какую-то случайную величину, человек часто не может охватить все распределение и потому смотрит на какие-то ключевые агрегаты — среднее, медиану и так далее, и на основании этих данных уже делает свои выводы. Например, средняя зарплата в IT — $X в месяц, следовательно, быть айтишником довольно выгодно. Иногда агрегат выбран неверно, и выводы получаются странными (например, пресловутая средняя температура по больнице).

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

К чему вообще все эти рассуждения, которым место скорее в книжке «Статистика для младших школьников»? К тому, что довольно сложно объективно описать термин, под которым многие группы людей подразумевают какое-то свое представление (вот она, мультимодальность!). Но давайте попробуем и обозначим какие-то основные моды профессии.

Data Analyst / Аналитик

Большинство data science вакансий в Минске — это аналитик на стероидах. Обычно ожидается, что аналитик будет проверять гипотезы, извлекать информацию из слабо структурированных данных и доносить ее до коллег (иногда это означает необходимость делать ad hoc отчеты для менеджеров 90% рабочего времени).

Если такую позицию назвать data scientist, можно добиться нескольких эффектов:

  • Показать, что от этого человека ожидается хоть какое-то умение программировать;
  • Хайпануть («мы передовая компания, а не рядовая унылая галера!») 
  • Убедить кандидата поработать на менее интересных ему условиях за модные слова в резюме.

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

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

Такой человек может заниматься и машинным обучением, но обычно на это уходит меньшая часть его времени, да и сами модели зачастую не слишком сложные — важнее чувствовать предметную область, чем уметь отлично подкручивать гиперпараметры градиентного бустинга. Пресловутые soft skills тоже часто перевешивают какие-то технические способности. 

Data Engineer

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

Спрос на дата инженеров был порожден предыдущим хайпом, когда многие бредили пресловутой big data. Сейчас обычно дата инженеры работают в средних и крупных компаниях, где в том или ином виде data science функция выполняется несколькими людьми, а то и несколькими командами.

Так как дата инженер обычно работает с достаточно большими наборами данных, ему следует более или менее знать классику computer science, ведь на многих терабайтах данных неоптимальность алгоритма становится заметна очень быстро. Кроме того, в дата инженерии есть свой набор фреймворков (отличается от компании к компании), знакомство с которыми может потребоваться. Пожалуй, роль data engineer больше всего похожа на классическую роль software engineer.

Machine Learning Engineer (MLE)

Как можно догадаться, основная разница с предыдущим подвидом инженера как раз связана с машинным обучением. Пока дата инженер больше работает с подготовкой данных, обычно больших, и собственно модели не обучает, для Machine Learning Engineer это важная часть работы. Вкратце — это software engineer с уклоном в машинное обучение, который может выполнить полный цикл — от сбора данных для модели до деплоймента ее как части продакшен-приложения. 

https://twitter.com/vboykis/status/1047199422772391936

Следовательно, требования к MLE чем-то похожи на требования к дата инженеру: в первую очередь, это просто компетентный разработчик, знающий и алгоритмы, и инженерные практики (может ответить, зачем нужен CI, и рассказать пару баек, почему выкатываться в пятницу может быть плохой идеей). При этом он более или менее понимает теорию машинного обучения (например, понимает bias-variance tradeoff и может написать градиентный спуск с нуля). Хороший MLE знает современные алгоритмы машинного обучения, но не спешит использовать самые горячие новинки. Ему обычно не нужно изобретать что-то с нуля, но слегка адаптировать существующий подход под свою задачу — довольно часто.

В зависимости от домена, у MLE могут быть специфические навыки. Например, для обработки видео на телефоне в реальном времени нужно уметь написать сколько-то быстрый код на C++, а для разработки классического бэкенд-приложения обычно полезно быть «на ты» с Docker.

ML Researcher

Зато ML Researcher как раз должен знать новинки. Более того, не просто знать, но и изобретать новые, двигать науку вперед. Такие исследователи — редкая птица в наших краях, обычно они работают или в лабораториях университетов, или в крупных компаниях (наверное, в Беларуси таким может похвастаться только Яндекс). 

https://twitter.com/chipro/status/1188000997890646017

ML Researcher должен быть хорош в теории, нормально программировать, а вот знанием хороших инженерных практик может похвастаться не всегда. «Академический код» — своего рода мем. Впрочем, ситуация улучшается: на сайте https://paperswithcode.com/, где выкладываются имплементации последних статей, уже довольно часто можно видеть приличный код. 

«Most advanced research projects require you to be excellent at the basics much more than they require you to know something extremely advanced», — Ian Goodfellow

О размытости границ

Следует понимать, что эти четыре подвида не встречаются в сферическом виде в вакууме, зачастую в разных командах и разных компаниях нужны свои комбинации этих архетипов. Например, если компания делает достаточно инновационный продукт, то MLE должен быть немного исследователем, чтобы сделать что-то по-настоящему новое (пример — ребята из AIMatter, чей фреймворк для инференса смог впечатлить Google). Или data scientist в небольшой компании не может сидеть и ждать, пока данные автомагически появятся на его компьютере — придется засучить рукава и самому сделать базовый ETL.

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

От бизнес-метрик до sticky sessions

В силу этого разнообразия вопросы на интервью тоже иногда удивляют. Я не могу похвастаться большим количеством пройденных интервью, но дисперсия вопросов успела впечатлить. Спрашивают всякое: аксиоматику Колмогорова, как написать LRU-cache на салфетке, способы реализации sticky-сессий в распределенных приложениях, методы оценки экономического эффекта от внедрения ML модели в продукт, задачи про гномов и шапки… 

Если позиция предполагает какой-то deep learning, то обязательно спросят, как устроен Adam и зачем нужен Batch Normalization. Тестовые задания, которые я видел, в основном двух типов: «выжми из этого датасета метрику получше» (здесь могут оценивать и саму метрику, и способ подачи результатов) и «напиши эту несложную функцию» (в этом случае обязательно будут смотреть на чистоту кода, тесты и прочие хорошие практики). 

В целом, все те же проблемы, которые часто обсуждаются касательно найма разработчиков, касаются и DS с поправкой на общую незрелости роли (т.е. в среднем все еще хуже). Ситуации, в которых интервьюер что-то недавно узнал/опробовал, и теперь ожидает от кандидата ответ, совпадающий с его собственным опытом — не редкость даже в крупных компаниях. 

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

Вместо вывода

Data Science в очень общем смысле вышел на плато продуктивности, умение работать с данными навсегда останется востребованным, если не случится чего-то совсем близкого к апокалипсису. Зрелости все еще не хватает: мода меняется часто, технологии взлетают и угасают. Тем не менее, уже можно найти какое-то более или менее стабильное подмножество навыков, которые будут нужны индустрии в среднесрочной перспективе.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

Оставьте комментарий

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

Прокрутить вверх