Unpopular Opinion: Data Scientists Should be More End-to-End

eugeneyan

Начни здесь Тексты Выступления Прототипирование Обо мне

Непопулярное мнение: Data Scientist'ы должны быть более end-to-end

[ datascience machinelearning leadership 🔥 ] · 17 мин чтения

Недавно мне попался тред на Reddit о различных ролях в data science и machine learning: data scientist, decision scientist, product data scientist, data engineer, machine learning engineer, machine learning tooling engineer, AI architect и так далее.

Я нахожу это тревожным. Сложно быть эффективным, когда процесс data science (постановка задачи, дата-инжиниринг, ML, развёртывание/поддержка) разнесён между разными людьми. Это ведёт к накладным расходам на координацию, размыванию ответственности и отсутствию общей картины.

IMHO, я считаю, что data scientist'ы могут быть эффективнее, работая end-to-end. Здесь я обсужу преимущества и контраргументы, как стать end-to-end, а также опыт Stitch Fix и Netflix.

От начала (поставить задачу) до конца (решить её)

Вам могли встречаться похожие ярлыки и определения, например:

Generalist: ориентация на роли (PM, BA, DE, DS, MLE); порой с негативной коннотацией. Full-stack: ориентация на технологии (Spark, Torch, Docker); термин популяризован full-stack разработчиками. Unicorn: ориентация на мифологию; считается, что таких не существует.

Мне кажется, эти определения слишком предписывающие. Я предпочитаю более простое (и прагматичное) определение: end-to-end data scientist умеет выявлять и решать задачи с помощью данных, принося ценность. Чтобы достичь цели, он наденет столько шляп, сколько потребуется. Он также освоит и применит любую технологию, методологию и процесс, которые работают. По ходу он задаёт вопросы вроде:

В чём задача? Почему она важна? Можем ли мы её решить? Как именно её решать? Какова ожидаемая ценность? Какова фактическая ценность?

Ещё один способ определить end-to-end data science — через процессы. Они обычно сложные, и я вынес их за рамки основного обсуждения. Тем не менее, вот несколько, если вам любопытно:

CRISP-DM: Cross-Industry Standard Process for Data Mining (1997). KDD: Knowledge Discovery in Databases. TDSP: Team Data Science Process, предложенный Microsoft в 2018 году. DSLP: Data Science Lifecycle Process.

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

Больше контекста, быстрее итерации, выше удовлетворённость

Для большинства ролей в data science работа end-to-end повышает вашу способность приносить значимый impact. (Тем не менее, есть роли, сфокусированные на machine learning.)

Работа end-to-end даёт больше контекста. Специализированные роли могут повышать эффективность, но снижают контекст (для data scientist'а) и ведут к субоптимальным решениям.

Чтобы забыть общую картину, нужно рассматривать всё крупным планом. – Chuck Palahniuk

Трудно спроектировать целостное решение без полного понимания вышестоящей проблемы. Допустим, конверсия упала, и PM просит улучшить алгоритм поиска. Но что вообще вызвало это падение? Причины могут быть разные:

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

Чаще всего и проблема, и решение лежат вне machine learning. Подход «улучшить алгоритм» прошёл бы мимо корневой причины.

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

Строить near-real time рекомендатель, если инфраструктура и инженеры не могут его поддержать. Строить рекомендатель с бесконечной прокруткой, если он не вписывается в наш продукт и приложение.

Работая end-to-end, data scientist'ы получают полный контекст, чтобы выявлять правильные задачи и разрабатывать применимые решения. Это также может приводить к инновационным идеям, которые специалисты с их узким контекстом упустили бы. В целом это повышает способность приносить ценность.

Снижаются накладные расходы на коммуникацию и координацию. Чем больше ролей, тем больше overhead. Рассмотрим пример: data engineer (DE) очищает данные и создаёт фичи, data scientist (DS) анализирует данные и обучает модель, а machine learning engineer (MLE) её разворачивает и поддерживает.

То, что один программист делает за месяц, двое сделают за два. – Frederick P. Brooks

DE и DS должны договариваться о том, какие данные доступны (и недоступны), как их очищать (выбросы, нормализация) и какие фичи создавать. Аналогично DS и MLE обсуждают, как развёртывать, мониторить и поддерживать модель, как часто её переобучать. Когда возникают инциденты, в комнате (вероятно, с PM) понадобится трое, чтобы найти корневую причину и шаги по устранению.

Это также порождает дополнительную координацию — расписания приходится синхронизировать, а работа передаётся по цепочке. Если DS хочет поэкспериментировать с новыми данными и фичами, придётся ждать, пока DE их загрузит и создаст. Если новая модель готова к A/B тесту, придётся ждать, пока MLE её (переписав в production-код) развернёт.

Сама разработка может занимать дни, но коммуникация туда-обратно и координация — недели, если не больше. С end-to-end data scientist'ами мы можем минимизировать этот overhead, а также избежать потери технических деталей в переводе.

(Но действительно ли один end-to-end DS способен на всё это? Думаю, да. Хотя DS может уступать DE или MLE в каких-то задачах, большинство он сможет выполнить эффективно. Если нужно масштабирование или закаливание решения, всегда можно подключить специализированных DE и MLE.)

Гарвардский психолог Ричард Хэкман показал, что число связей в команде равно N(N-1) / 2, где N — число людей. Это даёт экспоненциальный рост связей:

У стартап-команды из 7 человек — 21 связь. У группы из 21 человека (то есть трёх стартап-команд) — 210 связей. У группы из 63 человек — почти 2000 связей.

В нашем простом примере было всего три роли (то есть шесть связей). Но как только добавляются PM, BA и другие участники, коммуникационные и координационные издержки растут быстрее, чем линейно. Поэтому, хотя каждый новый участник увеличивает общую продуктивность команды, рост происходит с уменьшающимся темпом из-за накладных расходов. (Амазоновские two-pizza teams — возможное решение.)

Растёт скорость итераций и обучения. Имея больше контекста и меньше overhead, мы можем быстрее итерировать, ошибаться (читай: учиться) и приносить ценность.

Это особенно важно для разработки продуктов на данных и алгоритмах. В отличие от software engineering (куда более зрелого ремесла), мы не можем закончить всё обучение и проектирование до того, как начнём строить — наши чертежи, архитектуры и паттерны проектирования не настолько проработаны. Поэтому быстрая итерация критична для цикла design-build-learn.

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

Распространённый анти-паттерн — «перебросить через стену». Например, DE создаёт фичи и перебрасывает таблицу базы данных DS'у, DS обучает модель и перебрасывает R-код MLE, а MLE переводит его в Java для продакшна.

Если что-то теряется в переводе или результат не оправдывает ожиданий, кто отвечает? При сильной культуре ownership каждый берёт на себя свою часть. Без неё работа вырождается в прикрывание задниц и перекидывание стрелок, пока проблема остаётся, а страдают клиенты и бизнес.

Если end-to-end data scientist берёт на себя ownership и ответственность за весь процесс, это смягчает проблему. У него должны быть полномочия действовать от начала до конца: от клиентской задачи и входных данных (то есть сырых данных) до выхода (то есть развёрнутой модели) и измеримых результатов.

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

Одна из его форм — эффект свидетеля: Kitty Genovese была убита возле дома напротив того, где она жила. Несмотря на 38 свидетелей, видевших или слышавших нападение, никто не вызвал полицию и не помог ей.

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

У (некоторых) data scientist'ов это повышает мотивацию и удовлетворённость работой, которые тесно связаны с автономией, мастерством и смыслом.

Автономия: возможность решать задачи самостоятельно. Вместо того чтобы ждать и зависеть от других, end-to-end data scientist может сам выявить и сформулировать задачу, построить дата-пайплайны, развернуть и валидировать решение. Мастерство: в задаче, решении и результате — от начала до конца. Он также осваивает домен и технологии по мере необходимости. Смысл: глубоко вовлекаясь во весь процесс, он сильнее связан с работой и её результатами, что усиливает ощущение смысла.

Но нам также нужны узкие специалисты

Быть end-to-end подходит не всем (и не каждой команде), по разным причинам:

Желание специализироваться в machine learning или в какой-то конкретной нише, например, в нейронной генерации текста (см.: GPT-3 primer). Работа end-to-end ценна, но нам нужны и эксперты мирового класса в исследованиях и индустрии, которые двигают границы. Многое из того, что есть в ML, пришло из академии и чистых исследований.

Никто не достигает величия, становясь дженералистом. Невозможно отточить навык, размывая своё внимание на его развитие. Единственный способ перейти на новый уровень — фокус. – John C. Maxwell

Отсутствие интереса. Не каждому хочется общаться с клиентами и бизнесом, чтобы формулировать задачу, собирать требования и писать дизайн-документы. Так же не каждый интересуется software engineering, продакшен-кодом, юнит-тестами и CI/CD пайплайнами.

Работа над крупными high-leverage системами, где улучшение в 0,01% даёт гигантский эффект. Например, алготрейдинг и реклама. В таких ситуациях нужна гиперспециализация, чтобы выжать эти улучшения.

Другие также приводили аргументы за специализацию data scientist'ов (вместо end-to-end). Вот несколько статей для баланса и контраргументов:

Why You Shouldn't Be A Data Science Generalist Why Every Data Scientist Needs to Specialize Want a Job in Data Science? Here's Why You Should Specialize

Лучший способ это освоить — учиться на практике

Если вам всё же хочется стать более end-to-end, обсудим, как этого добиться. Прежде чем углубляться в конкретные технологии, вот наборы навыков, которые обычно используют end-to-end data scientist'ы:

Продукт: понимать проблемы клиентов, формулировать и приоритизировать требования. Коммуникация: координировать команды, добиваться согласия, писать документы, делиться результатами. Дата-инжиниринг: перемещать и преобразовывать данные из точки A в B. Анализ данных: понимать и визуализировать данные, A/B тестирование и инференс. Machine learning: обычные задачи плюс эксперименты, реализация и метрики. Software engineering: практики продакшен-кода, включая юнит-тесты, документацию, логирование. Dev Ops: базовое владение контейнеризацией и облаком, сборочные и автоматизационные инструменты.

(Этот список ни обязателен, ни исчерпывающий. Большинству проектов не нужно всё.)

Вот четыре способа приблизиться к роли end-to-end data scientist:

Изучайте правильные книги и курсы. (Окей, это не «обучение на практике», но всем нужно с чего-то начинать). Я бы сосредоточился на курсах, передающих неявные знания, а не конкретные инструменты. Сам я подобных материалов не встречал, но слышал хорошие отзывы о Full Stack Deep Learning.

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

Слышу — забываю. Вижу — запоминаю. Делаю — понимаю. – Конфуций

Начните с выявления задачи и определения метрики успеха (product). Затем найдите сырые данные (то есть не данные с Kaggle-соревнования); это позволит вам очистить и подготовить данные и создать фичи (data engineering). Дальше попробуйте разные ML-модели, изучая кривые обучения, распределение ошибок и метрики оценки (data science).

Оцените производительность каждой модели (например, латентность запросов, объём памяти), выберите одну и напишите вокруг неё базовый inference-класс для продакшна (software engineering). (Возможно, вы захотите построить простой пользовательский интерфейс.) Затем упакуйте в контейнер и разверните онлайн через выбранного облачного провайдера, чтобы другие могли пользоваться (dev ops).

После этого пройдите лишнюю милю и расскажите о своей работе. Можно написать статью на своём сайте или выступить на митапе (communication). Покажите, что вы нашли в данных, через осмысленные визуализации и таблицы (data analysis). Поделитесь работой на GitHub. Учиться и работать публично — отличный способ получить обратную связь и найти потенциальных соавторов.

Волонтёрьте через сообщества вроде DataKind. DataKind работает с социальными организациями (например, НКО) и специалистами по данным над гуманитарными проблемами. Сотрудничая с такими НКО, вы получаете возможность работать в команде над реальными задачами с реально грязными данными.

Хотя волонтёрам могут назначать конкретные роли (например, PM, DS), вы всегда можете присоединиться и просто наблюдать. Вы увидите (и поймёте), как PM работают с НКО, чтобы сформулировать проблему, определить решения и организовать команду. У других волонтёров вы научитесь работать с данными и создавать рабочие решения. Волонтёрство в хакатоно-подобных DataDives и более долгих DataCorps — отличный способ внести вклад в процесс data science end-to-end.

Присоединяйтесь к стартап-подобной команде. Заметьте: стартап-подобная команда — не синоним стартапа. Бывают крупные организации с командами в стартап-стиле (например, two-pizza teams) и стартапы из узких специалистов. Найдите небольшую команду, где вас поощряют и где у вас есть возможность работать end-to-end.

End-to-end в Stitch Fix и Netflix

Эрик Колсон из Stitch Fix изначально «поддался привлекательности функционального разделения труда из-за эффективности процессов» (то есть фабрики дата-сайентистов). Но методом проб и ошибок он обнаружил, что end-to-end data scientist'ы эффективнее. Теперь, вместо организации дата-команд ради специализации и продуктивности, Stitch Fix организует их ради обучения и разработки новых продуктов на данных и алгоритмах.

Цель data science не в выполнении. Скорее, цель — учиться и развивать новые бизнес-возможности. … Чертежей нет; это новые возможности с присущей им неопределённостью. … Все необходимые элементы должны быть получены через эксперименты, пробы и ошибки, итерации. – Eric Colson

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

Наличие end-to-end data scientist'ов улучшило способности Stitch Fix к обучению и инновациям, позволив открывать и создавать больше бизнес-возможностей (по сравнению с командой специалистов).

Netflix Edge Engineering поначалу имела специализированные роли. Однако это создавало неэффективности по всему жизненному циклу продукта. Релизы кода занимали больше времени (недели вместо дней), проблемы развёртывания дольше выявлялись и устранялись, а продакшен-инциденты требовали многочисленных переписок.

В крайнем случае за каждой функциональной областью/продуктом стоят 7 человек (источник)

Чтобы решить это, они поэкспериментировали с Full Cycle Developers, которым дали полномочия работать на всём жизненном цикле ПО. Это потребовало смены мышления — помимо проектирования и разработки, разработчики должны были думать о развёртывании и надёжности.

Вместо нескольких ролей и людей теперь есть full cycle dev (источник)

Чтобы поддержать full cycle разработчиков, централизованные команды строили инструменты для автоматизации и упрощения общих процессов разработки (например, билд- и деплой-пайплайны, мониторинг, управляемые откаты). Такие инструменты переиспользуются между командами, действуют как множитель силы и помогают разработчикам быть эффективными на всём цикле.

С подходом full cycle developer Edge Engineering смогла итерировать быстрее (вместо координации между командами), с более быстрыми и рутинными развёртываниями.

Сработало ли это у меня? Вот несколько примеров

В IBM я был в команде, создававшей рекомендации вакансий для сотрудников. Запуск всего пайплайна занимал очень много времени. Я думал, что можно сократить его вдвое, перенеся подготовку данных и feature engineering в базу. Но у специалиста по базам не было времени это протестировать. Не имея терпения, я прогнал бенчмарки и сократил общее время работы на 90%. Это позволило экспериментировать в 10 раз быстрее и сэкономить на compute в продакшне.

Создавая систему ранжирования Lazada, я понял, что для дата-пайплайнов нужен Spark (из-за большого объёма данных). Однако наш кластер поддерживал только Scala API, с которым я не был знаком. Не желая ждать (поддержки от data engineering), я выбрал более быстрый — но болезненный — путь: разобраться со Scala Spark и написать пайплайны самому. Это, вероятно, сократило время разработки вдвое и дало мне лучшее понимание данных для построения лучшей модели.

После успешного A/B теста мы обнаружили, что бизнес-стейкхолдеры не доверяют модели. В результате они вручную выбирали топ-товары для показа, ухудшая онлайн-метрики (например, CTR, конверсию). Чтобы лучше понять ситуацию, я ездил на наши маркетплейсы (например, в Индонезию, Вьетнам). Через взаимное обучение мы смогли снять их опасения, сократить ручные правки и получить выгоду.

В приведённых примерах выход за рамки обычной работы DS и ML помог принести больше ценности и быстрее. В последнем примере это было необходимо, чтобы разблокировать наши усилия в data science.

Попробуйте

Возможно, сейчас вы не end-to-end. Это нормально — мало кто такой. Тем не менее, обдумайте преимущества и попробуйте подтянуться ближе.

Какие аспекты непропорционально улучшили бы вашу способность приносить ценность как data scientist? Более тесное взаимодействие с клиентами и стейкхолдерами для создания более целостных, инновационных решений? Построение и оркестрация собственных дата-пайплайнов? Большая осведомлённость об инженерных и продуктовых ограничениях ради быстрой интеграции и развёртываний?

Выберите одно и попробуйте. Когда станете лучше — попробуйте что-то ещё. Расскажите, как идут дела, в твите или комментариях ниже!

Непопулярное мнение: data scientist'ы должны быть более end-to-end. Хотя это порицают (слишком дженералист!), я видел, как такой подход даёт больше контекста, более быстрые итерации, больше инноваций — больше ценности и быстрее. Детали и опыт Stitch Fix и Netflix 👇 https://t.co/aOBjuBSsSz— Eugene Yan (@eugeneyan) August 12, 2020

Дополнение: уточняю замысел этого поста

Через пару месяцев после публикации я понял, что некоторые читатели воспринимают этот пост с точки зрения навыков и технических знаний. Они видят его как призыв к data scientist'ам / ML-инженерам стать full-stack и обладать глубокими знаниями о том, как настраивать K8s, делать PhD-исследования, проектировать фронтенд и т. д. Это не моё намерение.

Я пытаюсь убедить, что end-to-end видимость, целостность (то есть обратный закон Конвея) и ownership ведут к лучшим результатам. Хотя видимость должна сопровождаться способностью влиять, для начала достаточно уметь использовать инструменты не умея их настраивать. Эффективные data scientist'ы, которых я знаю, — мощные пользователи своих инструментов, даже если не умеют поднять всё с нуля (хотя уверен, что освоят быстро).

Чтобы быть пилотом, не обязательно уметь построить самолёт, взлётно-посадочную полосу или аэропорт.

Спасибо Yang Xinyi за чтение черновиков и Basil Han и @gSajko за указание на баги.

Если это оказалось полезным, цитируйте, пожалуйста, этот текст так:

Yan, Ziyou. (Aug 2020). Unpopular Opinion: Data Scientists Should be More End-to-End. eugeneyan.com. https://eugeneyan.com/writing/end-to-end-data-science/.

или

@article{yan2020end, title = {Unpopular Opinion: Data Scientists Should be More End-to-End}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Aug}, url = {https://eugeneyan.com/writing/end-to-end-data-science/} }

Присоединяйтесь к 11 800+ читателям, которые получают обновления о machine learning, RecSys, LLM и инженерии.