Choosing Problems in Data Science and Machine Learning

eugeneyan

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

Как выбирать задачи в Data Science и Machine Learning

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

Дано: 8 дата-сайентистов и 20 задач. Как выбрать те 3-8 задач, над которыми должна работать команда?

Этот пост отвечает на второй по популярности вопрос из опроса по темам. Мы сосредоточимся на том, как выбирать задачи, а не на том, как решать или находить их (хотя процесс Working Backwards от Amazon отлично подходит для последнего).

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

Количественная оценка задач через cost-benefit анализ

Cost-benefit анализ — это подход к количественной оценке потенциальной отдачи от решения. Обычно он включает присвоение долларовой стоимости связанным затратам и выгодам с последующим применением простой формулы:

Выгоды − Затраты = Общая отдача (т.е. чистая выгода)

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

Мы работаем в e-commerce компании, у которой есть функция wishlist. Клиенты активно используют wishlist, добавляя товары на $100 миллионов ежеквартально. Анализируя товары в wishlist и поведение клиентов, мы выясняем, что клиенты используют wishlist по двум основным причинам: чтобы сохранять товары, которых нет в наличии, и чтобы откладывать товары, цена которых выше их обычного уровня.

Более того, мы обнаруживаем, что в любой данный месяц у 10% товаров в wishlist (т.е. на $10 миллионов) либо пополняется запас, либо цена падает более чем на 10%. Мы можем помочь клиентам, уведомляя их о таких изменениях по товарам из их wishlist. Если наша система push-уведомлений даёт конверсию 1%, она принесёт дополнительную выручку $100 000 в месяц (0,01 × $10 млн) или $1,2 миллиона в год.

При оценке задач нам также стоит учитывать, сколько клиентов затронуто (extent) и насколько серьёзна проблема (severity). Для иллюстрации — пример выбора, в какой категории улучшать поиск товаров.

Мы работаем в e-commerce компании с тремя основными категориями товаров: Fashion, Electronics и Groceries. Анализируя поисковые запросы, мы выясняем, что клиенты ищут эти категории в 50%, 20% и 40% случаев соответственно (т.е. extent). Также мы считаем click-through rate (CTR) и конверсию этих запросов и обнаруживаем, что поиск по groceries работает лучше всего, а по electronics — хуже всего (т.е. severity).

Мы оцениваем, что сможем улучшить поиск по fashion на 5%, что даст общее улучшение поиска на 2,5% (50% поискового трафика × 5% улучшения). Для electronics, учитывая большую серьёзность проблемы, мы оцениваем улучшение в 10%, что даст общее улучшение поиска на 2% (20% поискового трафика × 10% улучшения).

В первом примере мы оценили выгоду в $1,2 миллиона в год. Но это не учитывает улучшение клиентского опыта от уведомлений о возвращении товаров в наличие или существенном снижении цены. (Кстати, это реальный кейс, который выиграл хакатон и был внедрён, хотя приведённые цифры вымышленные).

Во втором примере, если решать только по цифрам, нужно выбрать улучшение поиска по fashion. Но что, если наш поиск по electronics настолько плох, что мы теряем клиентов, которые покупают электронику на нашей платформе?

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

Вторая часть уравнения охватывает затраты, большую долю которых составляют зарплаты. Разработка новых фич или систем требует дата-сайентистов и инженеров. Возьмите их месячную зарплату и умножьте на время разработки (например, 3 месяца) — это и есть стоимость разработки. Также есть постоянные затраты на эксплуатацию и поддержку системы (например, on-call, обновления ПО и т.д.), которые могут составлять 2-4 недели каждый год.

Другая крупная статья затрат — инфраструктура, особенно если нужно работать с большими объёмами данных или deep learning. Если мы работаем в облаке, можно оценить стоимость каждой задачи на основе её времени выполнения, количества необходимых инстансов (т.е. машин) и стоимости часа инстанса. Если предсказания генерируются на лету (т.е. online inference), нам также понадобятся инстансы для обслуживания модели — это может быть дорого, особенно если нужны GPU. (Если у вас on-premise оборудование, затраты будут другими.)

Capabilities и обучающие упражнения применимы ко всем задачам

Мы видели, насколько сложно количественно оценить выгоду для клиентов, особенно если эти выгоды не приводят напрямую к росту выручки или снижению затрат. Это распространяется и на задачи, решение которых вообще не приносит прямой выгоды клиенту. Однако решение таких задач даёт capabilities и обучение, которые помогают решать другие задачи.

Capabilities работают как мультипликаторы, часто снижая стоимость решения других клиентских задач. Например, у нас может быть проблема вывода фич в продакшен — построение или внедрение feature store кажется правильным решением. В этом случае feature store сам по себе не генерирует выручку, но снижает усилия, необходимые для вывода фич в продакшен (см. пример ниже).

GoJek обнаружили, что вывод фич в продакшен сложен. Инженерам приходилось тратить время на настройку инфры, а дата-сайентистам — переписывать офлайн batch-преобразования фич для работы в онлайне. Поэтому они построили Feast — feature store, позволяющий дата-сайентистам использовать фичи (для обучения и продакшена) через простой API.

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

Другой пример — построение пайплайна, позволяющего дата-сайентистам самим деплоить свои ML-модели, не дожидаясь ML-инженеров. (Простой пайплайн можно собрать на Docker и SageMaker.) Аналогично, это сокращает время и стоимость разработки, позволяя команде решать больше задач за то же время.

Capabilities также включают исследования и data-активы. Например, мы можем вложить время в обучение эмбеддингов твитов, товаров или магазинов, которые можно использовать в разных командах и приложениях. Это снижает стоимость создания собственных эмбеддингов в каждой команде. Также добавление эмбеддингов (в качестве фич) часто даёт прирост производительности существующих ML-систем. Похожая работа включает построение knowledge graphs, которые могут использовать другие команды в своих приложениях (например, LinkedIn, WalMart, Airbnb).

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

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

Например, продуктовые и бизнес-стейкхолдеры могут возлагать большие надежды на выгоды от image search и рекомендаций, особенно для категорий вроде fashion, мебели и игрушек. Однако команда дата-сайенс не уверена, есть ли у нас capability для этого (например, deep learning на изображениях в масштабе). Чтобы прояснить, мы можем провести серию обучающих упражнений — сначала с image classification, затем с image search и рекомендациями. Результаты этих упражнений прокладывают путь и позволяют решать задачи, которые раньше считались нерешаемыми.

Инкрементальные vs. прорывные (т.е. краткосрочные vs. долгосрочные)

Помимо затрат и выгод, полезно также учитывать, требует ли задача инкрементального или прорывного решения. Инкрементальные изменения включают улучшения существующих систем (например, новые feature-колонки), а прорывные — построение новой (замещающей) системы. С этой точки зрения инкрементальные и прорывные изменения иногда рассматриваются как краткосрочные vs. долгосрочные усилия (хотя бывают простые и быстрые решения, которые при этом прорывные).

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

Перескакивание с одной S-кривой на следующую в музыкальной индустрии (источник)

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

В 1970-х были кассеты и Sony Walkman. Они разрушили рынок виниловых пластинок и сделали музыку портативной. Инкрементальные инновации увеличили хранение музыки с 60 до 90 минут, хотя её качество оставалось прежним. В 1980-х CD разрушили кассеты и качественно подняли уровень звука. Тем не менее каждый CD мог хранить лишь около 80 минут музыки. В 1990-х MP3-плеер (например, iPod) разрушил CD и позволил пользователям носить тысячи песен в кармане. В 2000-х музыкальный стриминг (например, Spotify) разрушил MP3-плееры. Теперь пользователи могут слушать любую музыку по запросу.

Из примера выше видно, что каждое прорывное решение даёт ступенчатый рост клиентского опыта: от виниловых пластинок к кассетам (портативность), к CD (качество), к MP3-плеерам (количество), к стримингу (on-demand).

То же относится к данным и machine learning. Для обработки и преобразования данных можно выжать из SQL-запросов на традиционной нераспределённой базе только определённый объём. В итоге придётся стиснуть зубы и перейти на распределённый фреймворк типа Spark или Flink. Это прорывное изменение даёт ступенчатое улучшение, позволяя работать с большими объёмами данных, запускать задачи чаще и даже обрабатывать стриминговые данные.

В machine learning переход от классических моделей (например, линейная регрессия, деревья решений) к deep learning также может дать ступенчатые улучшения производительности моделей. Можно также развивать сам способ использования ML — например, перейти от ежедневных рекомендаций к рекомендациям в реальном времени. Real-time рекомендации лучше обслуживают клиентов, когда путь клиента зависит от времени или контекста, или когда у нас нет исторических данных о клиентах (например, cold-start).

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

Ловушки: resume-driven development и pet projects

При этом маятник иногда заносит слишком далеко в сторону прорывных задач. Один из симптомов — resume driven development, когда инженеры намеренно используют новые или модные технологии, чтобы приукрасить резюме — речь не о том, что работает лучше, а о том, что круче. Это случается и в machine learning, где дата-сайентисты впихивают новейшие state-of-the-art техники (GPT-4, Vision BERT и т.д.) в свои проекты.

К сожалению, такое слишком часто встречается в tech, где от людей ожидают изощрённых (читай: византийских) решений, чтобы продемонстрировать масштаб и глубину. Это приводит к излишне сложным системам, которые охватывают несколько команд, используют вдвое больше технологий, чем нужно, и применяют deep learning техники, опубликованные только вчера. В результате мы порой видим шлейф из заброшенных скорлуп, которые забросили, когда их создатели получили повышение или ушли.

Остерегайтесь Highest Paid Person's Opinion и Zero Evidence But Really Arrogant (источник)

Другая ловушка — взяться за задачу, потому что это чей-то pet project. Мы можем делать это, чтобы заслужить доверие важных стейкхолдеров, или потому что не знаем, как (или не можем) сказать «нет». Иногда стейкхолдер теряет интерес после того, как мы вложили значительное время и ресурсы в решение задачи. Или это оказывается погоней за призраком, потому что мы недостаточно продумали задачу.

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

Описание в матрице 2×2 «Выгода × Инновационность»

Чтобы подытожить обсуждённое выше, попробуем уложить это в матрицу 2×2. По вертикальной оси — выгоды от положительных до неположительных. По горизонтальной оси — инновационность от инкрементальной до прорывной.

Выбор задач по шкалам выгоды (вертикальная ось) и инновационности (горизонтальная ось)

Положительные и инкрементальные: сюда входят улучшения существующих систем (например, новые feature-колонки, обновление ML-архитектуры). Такие задачи дают стабильный, ровный прогресс, и их решение помогает заслужить доверие. Иногда называются «низковисящими фруктами».

Неположительные и инкрементальные: иногда мы делаем множество мелких изменений, которые не приносят пользы, но экспоненциально увеличивают сложность. Может привести к «смерти от тысячи порезов».

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

Неположительные и прорывные: требуют большего размышления. Строим ли мы новые capabilities, умножающие выход команды, или это обучающее упражнение для разблокировки более ценных задач? Или это ловушка resume-driven development, или следование мнению HiPPO? Действуйте осторожно.

Как и большинство матриц 2×2, эта упрощает реальный мир. Тем не менее надеюсь, что обсуждённые концепции — cost-benefit анализ, capabilities, обучающие упражнения, инкрементальные vs. прорывные изменения — будут полезны вам при выборе и приоритизации задач data science и machine learning. Есть фидбэк? Пишите мне в @eugeneyan!

Как выбирать задачи machine learning?• Количественно оценивайте затраты и выгоды• Фокусируйтесь на capabilities, умножающих выход• Делайте упражнения, разблокирующие более ценные задачи• Избегайте resume driven development и pet projects• Балансируйте инкрементальное vs. прорывноеhttps://t.co/Md359mVmC3— Eugene Yan (@eugeneyan) 23 марта 2021

Спасибо Yang Xinyi за вычитку черновиков.

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

Yan, Ziyou. (Mar 2021). Choosing Problems in Data Science and Machine Learning. eugeneyan.com. https://eugeneyan.com/writing/how-to-choose-problems/.

или

@article{yan2021problem, title = {Choosing Problems in Data Science and Machine Learning}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2021}, month = {Mar}, url = {https://eugeneyan.com/writing/how-to-choose-problems/} }

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