Data Science Project Quick-Start

eugeneyan

eugeneyan

Start Here Writing Speaking Prototyping About

Data Science Project Quick-Start

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

[ datascience engineering productivity ] · 7 min read

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

When I was a new data scientist, starting a project often meant defaulting to what I was familiar with—training machine learning models. I was overeager and didn’t consider the business goals, context, or success metrics. My process was disorganized; reproducibility and good engineering habits were the least of my concerns. Thus, whatever time saved early on was paid for with exorbitant interest when we went to production.

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

Several mistakes and mentors later, I’ve gained some hard-won lessons on how to start data science projects effectively. I’ll share them here so you can go from nebulous problem to usable prototype, without repeating my errors.

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

Understand the intent and context

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

Start by understanding the intent, the “why”, behind the project. I’ve found asking these questions helpful:

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

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

Imagine you work at an e-commerce startup and a product manager asks you to build a recommendation engine.

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

You might start by asking, “What’s the expected benefit?”

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

“Customers find products easier and we increase engagement”, she replies.

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

You then follow-up with, “How do we define engagement? Clicks? Purchases?”

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

How we define engagement will determine the labels used for training (i.e., clicks or purchase). If purchases is the goal, we want to distinguish between conversion and revenue. Optimizing for conversion is relatively straightforward—we can train on sales and predict a purchase probability. If the goal is revenue, we might want to weigh purchase labels by item price, similar to how YouTube weighs videos by watched time.

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

Also, try to get as much context as you can. Imagine we get two requests to build a feature store, each with its own circumstances. For the first request, what we build will be used by the entire organization. For the second request, it will be used by a single application while the app waits for the feature store by the core engineering team to come online. The first request will need to be extensible, scalable, and well documented. In contrast, the second request can probably do with a hacky solution and a fraction of the effort, or outright declined. Understanding the context enables us to scope the solution appropriately.

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

Define requirements, constraints, and metrics

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

What should be achieved for the project to be a success? Try describing it from the customer’s or business’ point of view—what’s in it for them?

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

If we’re improving search, we might have requirements to reduce the proportion of reformulated and abandoned queries. If we’re building a recommender, requirements include increasing the number of clicks and/or attributed purchases on the widget. If we’re automating a manual product categorization process, we’ll set targets on the proportion of products automatically categorized with high confidence, and manpower saved.

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

Requirements can also be framed as constraints. What can our ML system not do? If our insurance fraud detector requires manual investigation for each flagged claim, we might constrain the number of false positives, a proxy for wasted effort, to be less than 25%. If we want to introduce new, cold-start products in our recommendations (for explore-exploit), we might set a constraint that overall conversion should not drop by more than 5%.

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

I’ve also found it helpful to consider production requirements (though we’re just starting the project). If engineering has a requirement on latency (e.g., <80ms@p99) and throughput (e.g., 8,000 transactions per second), we might not consider techniques that are prohibitively costly to deploy at scale. There could also be resource constraints. Not having a real-time feature store would preclude session-based recommendations, while not having the budget for a GPU cluster may mean starting with simpler, shallower models.

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

While these constraints may be limiting, I believe they help by narrowing our search space and saving us the unnecessary effort of considering solutions that can’t be used. Clearly defined constraints free us to do anything except breach those constraints, empowering us to innovate. You’ll be surprised how much the team can do with a frugal mindset.

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

To measure how we’re doing on the requirements, we need a set of metrics. This may require us to dogfood our own product to understand how the customer experiences it.

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

Here’s an ML metric example: Assume we’re asked to build a recommender that suggests 100 products for each product detail page. Given that we’re recommending 100 products, we might use a metric such as hit@100 or ndcg@100. However, while browsing the site, we find that the recommendation widget only displays 5 products on the screen; customers have to swipe to view the other recommendations. With this insight, we might update our metric to adopt k = 5. This would reflect the CX more accurately and likely correlated better with online A/B test metrics.

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

Dig into the data early

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

Ideally, we’re able to do this before the requirements are finalized. Exploring the data might reveal the proposed requirements to be too much of a stretch.

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

Assume we’re asked to build a product classifier that categorizes products based on title and image. While inspecting the data, we find a portion of existing products to have the same image and title, but be in different categories. For example, multiple seller listings of the same iPhone case could be categorized under “phone -> accessories -> case” and “phone -> iPhone -> accessories -> case”. In this case, instead of directly building the product classifier and achieving poor accuracy on these inconsistent labels, we might start with a phase of label cleaning and refactoring the product category tree.

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

We might implement a quick ML baseline as part of data exploration. How quick? A day or two. The baseline may suggest potential challenges in achieving target metrics.

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

For example, stakeholders have an initial requirement for your fraud detection model to achieve >95% recall and precision. However, your baseline is only able to achieve 60% recall and precision. While closing the gap between 60% and 95% isn’t impossible, it could be a challenging, multi-year effort. Thus, we might want to manage expectations and adjust the target metrics, as well as make trade-offs between recall and precision.

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

Consult domain experts, papers, and open-source code

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

One shortcut to getting up to speed on an unfamiliar problem is to observe how others do it.

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

Trying to automate a manual process (e.g., insurance claims fraud detection)? Sit with the investigators and learn the heuristics that guide their process, and turn those heuristics into features for machine learning. Need to solve an unfamiliar machine learning problem? Read papers and tech blogs on how others have done it. Want to try a new algorithm or model? Search on GitHub if there’s an open-source implementation available, or better yet, a pre-trained model available on HuggingFace.

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

Standardize and automate your experiment pipeline

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

Like most data scientists, I do my early experiments and prototyping in Jupyter notebooks. To prevent them from getting too messy, I’ve found it helpful to refactor my notebooks weekly. Code snippets commonly used across notebooks are refactored into .py files instead of copy-pasting code cells (e.g., metrics.py, plots.py, logger.py). Manual steps and commented-out cells—which will be forgotten after a few months—are also pruned. The result is a notebook that can run from start to finish, without any manual intervention, with metrics and plots at the end.

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

I’ve also learned to automate as much as possible (because I’m lazy). For ML techniques that require extensive hyperparameter tuning (e.g., boosted trees, deep learning), I’ve been using Hyperopt since my kaggling days. More recent and popular frameworks include Optuna and Tune. For tracking metrics, MLFlow is free and easy to use. You can even parameterize notebooks with Papermill so each experiment is run in a separate notebook. (I wrote a short guide on using MLFlow and Papermill to simplify experimentation).

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

• • •

• • •

If we do the above, we’ll have a good understanding of the business intent, requirements, and constraints. We’ll also have a feel for the data, a set of initial papers and code to explore, and an experiment pipeline to iterate quickly. Now, we can dive deeper into the data and try increasingly sophisticated techniques as we confidently solve the right problem and deploy a usable solution.

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

Are they any habits you’ve found useful when starting a data science project? Please reach out or comment below!

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

If you found this useful, please cite this write-up as:

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

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

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

or

или

@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/} }

@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/} }

Join 11,800+ readers getting updates on machine learning, RecSys, LLMs, and engineering.

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