Могут ли аналитики-разработчики закрывать все DS задачи?

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

На самом деле, в командах это выглядит более размыто - то есть скорее относится к нотации T-shaped специалистов. Если команда работает в своих проектах end-to-end, то скорее вы не увидите там аналитика, который даже там регулярный расчет SQL-скриптов в прод выкатить не сможет, так же как и нет только разработчиков, которые не смогут провести легкую аналитику или не поговорят с бизнесом. Все это скорее подразумевает такой подход, где у всех есть определенная база и пара очень сильно вкачанных веток развития скиллов.

Почему это работает именно в таком виде?

Потому что направление работы сильно зависит от зрелости продукта:

1️⃣Идея

Бизнес только задачу. И продукт-менеджер (Product Owner) вместе с аналитиком-разработчиком формулируют гипотезу и определяют метрики. Здесь важно понять, какую проблему будет решать продукт/фича или моделька и сразу понять что и зачем делать

2️⃣Рисеч

Допустим, аналитик-разработчик проводит EDA, собирает MVP модели в ноутбуке, чекает гипотезу. Самое главное - это быстрые итерации и вообще похер какой код (главное, чтобы работало и воспроизводилось). Нам нужно быстро доказать или опровергнуть ценность идеи с минимальными затратами

3️⃣Прод

Если наш MVP показал необходимый результат, то его надо выводить в прод - короче сделать решение автоматизируемым. И здесь уже нужна другая вкачанная ветка нашего аналитика-разработчика, чтобы этот самый код переписать нормально, с пониманием архитектуры, масштабируемости. Приправить это логированием, тестированием и при необходимости интегрировать с другими сервисами. Самое простое - обернуть модель в API, поднять несколько под или Docker-контейнер, ну и настроить CI/CD, просто чтобы решение работало надежно, стабильно и эффективно

4️⃣Мониторинг и поддержка

После выкатки аналитик-разработчик (в дэшах, сделанных им же) следит не только за бизнес-метриками и считает эффекты от модели и влияние на бизнес, а также чекает технические моменты: время ответа, нагрузка. Дополнительно к этому проводятся итеративные улучшения от обратной связи коллег или работы с краевыми кейсами

Сколько ролей мы здесь насчитали?

Как минимум аналитик, разработчик, mlops

Распределив роли, мы можем не заставлять аналитика писать идеальный код, а разработчика часами копаться в сырых данных. Каждый занимается тем, в чем он наиболее силен. Но аналитик-разработчик занимается всем 😂

Достаточно ли аналитика-разработчика для решения всех DS проблем?

Нет

Потому что есть тот, кто не строит ML-модели и не пишет бэкенд. Но этот специалист и пишет много кода, и работает с данными. Вы наверно уже догадались, что это Data Engineer - и его суть превращать сырые данные из хранилищ в чистые и понятные витрины, на которых уже будут работать аналитики. По сути, аналитик-разработчик без этого не сможет делать свою работу. И кстати вкачать эту ветку развития будет довольно не быстро (попробуйте например заботать HDFS и Spark).

К чему я веду

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

Проблема не в том, чтобы найти "многорукого многонога" или заплатить две ставки. Проблема в том, чтобы выстроить процесс и собрать команду, где каждый специалист максимально эффективен на своем этапе. И тогда вы платите не "за две ставки", а за десять, а инвестируете в целостный процесс создания data-driven продуктов.

👍Лайки - за аналитиков-разработчиков
❤‍🔥Сердечки - за разработчиков-аналитиков
🔥Огонечки - за дата-инженеров (ну и mlops пусть будет сюда же)

#career

Интересное что-то от ребят, кого я читаю v0.33

Предыдущий пост тут
Интересное что-то тут

Всех с кайфовым теплым денечком, надеюсь вы не провели его за компом, как я 😈

1. Женя сделал небольшой гайд с применяемыми им AI-инструментами. Ребята в коментах справедливо докинули про Copilot, но в целом больше придраться не к чему - хорошая емкая информация, на крайняк свериться со своими инструментами (на самом деле я хотел пилить примерно похожий пост, но уже сомневаюсь)

2. Влад в двух частях 1, 2 приготовил обзор дельта-метода для прикладных задач в A/B-тестировании. Это не значит, что нужно уходить от бутстрапа, но автор настоятельно рекомендует.

3. Просто мощнейшая база от Толи про тестирование собственных финансовых стратегий на эффективность. Суть какая: если на оптимизатор находит профит в случайных алгориитмах - возможно что-то не так с оптимизатором и надо искать лики.

4. Сергей рассказал про e-value. Это короче как p-value, но отвечает на немного другой вопрос: "Насколько сильным должен быть некоторый неучтённый фактор, а не тритмент, чтобы полностью объяснить результат?"

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

По классике надеюсь, что вам зашли посты, если есть что-то реально топовое - делитесь в каментах!

#interesting

Саморазвивающее хобби

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

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

По сути хобби стало саморазвитием

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

🌟Научился формулировать мысли и структурно их подавать
🌟Слегка погрузился в продающие тексты и даже записывал пару видео
🌟Поборол стеснение показать самого себя на канале
🌟Узнал и познакомился с большим количеством коллег и по работе, и по блогингу
🌟До сих пор не особо понял, интересны вам длиннопосты или нет

Мне кажется, что самый основной вывод отсюда, что блог - это в первоую очередь не про обучение и развитие других. Оно может в себя это включать. Но кажется, что главная идея здесь - это про то, чтобы учиться самому и подавать пример. Пример дисциплины, пример обучаемости, пример стратегического мышления. Сразу оговорюсь, что на 100% с меня пример брать не стоит, но хотя бы берите пример с развития в своем направлении!

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

#life

Minority drift

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

Один из способов этого избежать - это заранее убрать признаки, которые будут разлетаться в проде, например я про это писал в посте про PSI

Коллеги по цеху пошли дальше в этом плане и решили провести вебинар на 2 часа вместе с Team Lead из Yandex на практике учиться распознавать виды Minority Drift, делать модели устойчивыми к дрейфу и оценивать деградацию и финансовые риски.

Когда:

▫️6 октября, ПН
▫️19:00 по мск
▫️2 часа

Что будет на уроке:

1️⃣Виды Minority Drift в продакшен данных: Class-wise, Conditional, Subpopulation, Hidden Drift

2️⃣Оценка деградации моделей и финансовых потерь на практике

3️⃣Методы стабилизации признаков и моделей: PSI и KL-дивергенция

4️⃣Контроль качества — построение Fairness Metrics

Преподает Дмитрий Сафонов, Data Science Team Lead в Яндексе.

Урок для Data Scientists, Classic ML и NLP-инженеров. Нужны базовые знания основ машинного обучения, математики и программирования.

➡️ Записаться на урок

Быстрый принт для контестов

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

Часто бывало такое, что вроде уже наоптимизировал код, а он ну совсем не проходит по времени и надо еще 50-100 мс откуда-то достать

Оказалось, что привычный для нас print() - это функция поверх sys.stdout.write()

Пока она отработает до вывода в аутпут инфы, может пройти достаточно много времени. И вот почему - исполняя print(), интерпретатор Python выполняет несколько шагов:

1️⃣Принимает аргументы (*args). То есть мы можем написать print(a, b, c).
2️⃣Преобразует каждый аргумент в строку. Если мы передадим число i, print(i) вызовет str(i).
3️⃣Джойнит аргументы, используя разделитель (по умолчанию пробел).
4️⃣Добавляет в конец строки символ (по умолчанию \n).
5️⃣Вызывает sys.stdout.write()

Ну вот сами посчитайте количество дополнительной логики

Я спросил у гпт в чем отличие, и вот что он выдал:

print() — это как заказать в ресторане "комплексный обед". Вы просто говорите название, а повар сам готовит салат, суп и второе, а затем подает все вместе. Это удобно, но требует от кухни больше действий

sys.stdout.write() — это как напрямую сказать повару: "Дай мне кусок хлеба", "Теперь положи на него сыр". Вы даете точные, низкоуровневые команды. Это быстрее для повара, но требует от вас больше указаний

В цикле, где эти операции повторяются миллионы раз, накладные расходы на дополнительную логику print() становятся заметными.

Звучит немного кринжовенько, но думаю основной смысл понятен. Кстати, в цикле на 10М вызовов функции записи, sys.stdout.write() почти в 2 раза быстрее обычного принта

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

P.S. Этой инфой поделились ребята с моей команды, так что в первую очередь спасибо им💪🏿

#python #code