Data Science Project Quick-Start

eugeneyan

Start Here Writing Speaking Prototyping About

Быстрый старт data science-проекта

[ datascience engineering productivity ] · 7 мин чтения

Когда я был начинающим data scientist'ом, старт проекта обычно сводился к тому, что было привычнее всего — обучению моделей машинного обучения. Я был чрезмерно увлечён и не задумывался о бизнес-целях, контексте или метриках успеха. Мой процесс был неорганизованным; воспроизводимость и хорошие инженерные привычки заботили меня меньше всего. В итоге всё сэкономленное на старте время оборачивалось грабительскими процентами, когда дело доходило до продакшена.

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

Поймите намерение и контекст

Начните с понимания намерения, «зачем», стоящего за проектом. Мне помогает задавать такие вопросы:

В чём ожидаемая выгода для клиента или бизнеса? Что не так с тем, как всё устроено сейчас? Почему важно решить эту задачу именно сейчас?

Представьте, что вы работаете в e-commerce-стартапе, и продакт-менеджер просит вас собрать рекомендательный движок.

Вы могли бы начать с вопроса: «А в чём ожидаемая выгода?»

«Клиенты легче находят товары, а мы увеличиваем вовлечённость», — отвечает она.

Тогда вы задаёте уточняющий вопрос: «А как мы определяем вовлечённость? Клики? Покупки?»

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

Также постарайтесь собрать как можно больше контекста. Представьте, что мы получили два запроса на создание feature store, у каждого свои обстоятельства. По первому запросу то, что мы построим, будет использоваться всей организацией. По второму — одним приложением, пока оно ждёт, когда core engineering team запустит свой feature store. Первый запрос потребует расширяемости, масштабируемости и хорошей документации. Второй же, скорее всего, обойдётся «костыльным» решением с долей усилий — а может быть, его и вовсе стоит отклонить. Понимание контекста позволяет корректно очертить рамки решения.

Определите требования, ограничения и метрики

Что должно быть достигнуто, чтобы проект считался успешным? Попробуйте описать это с точки зрения клиента или бизнеса — что они с этого получат?

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

Требования можно сформулировать и как ограничения. Чего наша ML-система делать не должна? Если детектор страхового мошенничества требует ручного разбирательства по каждой помеченной заявке, мы можем ограничить долю ложноположительных срабатываний (прокси для впустую потраченных усилий) уровнем менее 25%. Если хотим вводить новые товары без истории (cold-start) в рекомендации (explore-exploit), можем поставить ограничение, что общая конверсия не должна падать более чем на 5%.

Мне также показалось полезным сразу учитывать продакшен-требования (хоть мы и только начинаем проект). Если у инженерии есть требования по латентности (например, <80мс@p99) и пропускной способности (например, 8 000 транзакций в секунду), мы можем отказаться от методов, которые слишком дорого деплоить на масштабе. Бывают и ресурсные ограничения. Отсутствие real-time feature store исключает рекомендации на основе сессии, а отсутствие бюджета на GPU-кластер означает, что начинать придётся с более простых, неглубоких моделей.

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

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

Вот пример ML-метрики. Допустим, нас попросили построить рекомендатель, который предлагает 100 товаров на каждой странице описания товара. Поскольку рекомендуем 100, можно взять метрику hit@100 или ndcg@100. Но, побродив по сайту, мы замечаем, что виджет рекомендаций показывает на экране лишь 5 товаров — остальные нужно проматывать. С учётом этого мы можем обновить метрику и взять k = 5. Это точнее отразит CX и, вероятно, будет лучше коррелировать с метриками онлайн A/B-тестов.

Погружайтесь в данные рано

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

Допустим, нас просят построить классификатор товаров, относящий товары к категориям по названию и изображению. Изучая данные, мы обнаруживаем, что часть существующих товаров с одинаковыми изображением и названием находится в разных категориях. Например, несколько листингов одного и того же чехла для iPhone у разных продавцов могут попасть и под «телефон → аксессуары → чехол», и под «телефон → iPhone → аксессуары → чехол». В таком случае вместо того, чтобы прямо обучать классификатор и получать низкую точность на этих несогласованных метках, разумнее начать с фазы очистки меток и рефакторинга дерева категорий.

В рамках разведки данных можно собрать и быстрый ML-бейзлайн. Насколько быстрый? День-два. Бейзлайн может подсказать потенциальные сложности в достижении целевых метрик.

Например, у стейкхолдеров было исходное требование, чтобы ваша модель детекции фрода достигала >95% recall и precision. Но ваш бейзлайн выдаёт только 60% recall и precision. Закрыть разрыв между 60% и 95% не невозможно, но это может быть тяжёлой, многолетней работой. Поэтому имеет смысл управлять ожиданиями и корректировать целевые метрики, а также идти на компромиссы между recall и precision.

Советуйтесь с экспертами предметной области, читайте статьи и open-source-код

Один из коротких путей быстро войти в незнакомую задачу — посмотреть, как её решают другие.

Автоматизируете ручной процесс (например, выявление страхового мошенничества)? Посидите рядом с расследователями и изучите эвристики, которыми они руководствуются, а потом превратите эти эвристики в признаки для машинного обучения. Нужно решить незнакомую ML-задачу? Читайте статьи и тех-блоги о том, как с этим справлялись другие. Хотите попробовать новый алгоритм или модель? Ищите на GitHub open-source-реализацию, а ещё лучше — предобученную модель на HuggingFace.

Стандартизируйте и автоматизируйте пайплайн экспериментов

Как и большинство data scientist'ов, ранние эксперименты и прототипирование я делаю в Jupyter-ноутбуках. Чтобы они не превращались в кашу, мне помогает рефакторить ноутбуки еженедельно. Часто используемые между ноутбуками куски кода переносятся в .py-файлы вместо копипасты ячеек (например, metrics.py, plots.py, logger.py). Ручные шаги и закомментированные ячейки, о которых через пару месяцев всё равно забудешь, тоже вычищаются. В результате получается ноутбук, который прогоняется от начала до конца без ручного вмешательства, с метриками и графиками в конце.

Ещё я научился автоматизировать всё, что можно (потому что ленив). Для ML-методов, требующих масштабного подбора гиперпараметров (например, boosted trees, deep learning), я ещё со времён kaggle использую Hyperopt. Из более свежих и популярных фреймворков — Optuna и Tune. Для трекинга метрик MLFlow бесплатен и прост в использовании. А ноутбуки можно даже параметризовать через Papermill, чтобы каждый эксперимент шёл в отдельном ноутбуке. (Я написал короткое руководство по упрощению экспериментирования с помощью MLFlow и Papermill).

• • •

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

Есть ли у вас привычки, которые показались полезными при старте data science-проекта? Пожалуйста, напишите мне или оставьте комментарий ниже!

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

Yan, Ziyou. (Mar 2022). Data Science Project Quick-Start. eugeneyan.com. https://eugeneyan.com/writing/project-quick-start/.

или

@article{yan2022quick, title = {Data Science Project Quick-Start}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2022}, month = {Mar}, url = {https://eugeneyan.com/writing/project-quick-start/} }

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