Choosing Problems in Data Science and Machine Learning

eugeneyan

eugeneyan

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

Choosing Problems in Data Science and Machine Learning

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

[ datascience machinelearning leadership ] · 12 min read

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

Given 8 data scientists and 20 problems, how do you choose the 3 - 8 problems that the team should work on?

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

This post answers the second most-voted question on the topic poll. We’ll focus on how to choose problems, instead of how to solve problems or how to find problems (though Amazon’s Working Backwards process is great for the latter).

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

I’ll start with the trusty cost-benefit analysis and discuss problems where the solutions aren’t easily quantifiable. Then, we’ll see how problems (and solutions) can range from incremental to disruptive. Finally, I’ll touch on common pitfalls when choosing problems.

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

Quantifying problems via cost-benefit analysis

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

Cost-benefit analysis is an approach to quantify the potential returns from a decision. It usually involves assigning a dollar value to the associated costs and benefits before applying the simple formula below:

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

Benefits - Costs = Overall Return (i.e., Net Benefits)

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

In the simplest scenario, the benefit of solving a problem is either increased revenue or decreased cost. Here’s an example where we try to quantify the benefit of sending customers push notifications on wish-listed items.

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

We work for an e-commerce company that has a wishlist function. Customers use the wishlist extensively, adding $100 million worth of products every quarter. From our analysis of wishlist products and customer behavior, we learn that customers use wishlist for two main reasons: To bookmark out-of-stock products, and to set aside products that cost higher than their usual price point.

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

Furthermore, we find that in any given month, 10% of wishlisted products (i.e., $10 million in value) are either restocked or have a >10% price drop. We can help customers by notifying them of such changes to products on their wishlist. Assuming our push notification system leads to a 1% conversion rate, it will generate additional revenue of $100,000 per month (0.01 x $10 million) or $1.2 million per year.

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

While assessing problems, we’ll also want to consider how many customers are affected (extent) and how serious the problem is (severity). To illustrate, here an example of deciding between which categories to improve product search on.

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

We work for an e-commerce company that has three main product categories: Fashion, Electronics, and Groceries. By analyzing search queries, we learn that customers search for these categories 50%, 20%, and 40% of the time (i.e., extent). We also calculate the click-through rate (CTR) and conversion of these queries and find that groceries search performs the best while electronics search performs the worse (i.e., severity).

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

We estimate we can improve fashion search by 5%, leading to an overall search improvement of 2.5% (50% of search traffic x 5% improvement). For electronics, given the problem is more severe, we estimate an improvement of 10%, leading to an overall search improvement of 2% (20% of search traffic x 10% improvement).

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

In the first example, we quantified the benefit at $1.2 million yearly. But this doesn’t include the improved customer experience of being notified when items are back-in-stock or have a significant price drop. (By the way, this is an actual use case that won a hackathon and got implemented, though the numbers cited are fictitious).

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

In the second example, if deciding based on the numbers alone, we should choose to improve fashion search. But what if our electronics search is so bad that we’re losing customers who shop for electronics on our platform?

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

The point is, try to quantify as much as you can but be aware that it’s hard to fully quantify a problem. Also, overemphasis on quantifiable outcomes can sometimes lead to the wrong decisions. For example, should we work on the problem of de-ranking bad products (i.e., high return rate, low-ratings) if solving it will reduce conversion rate and revenue? If we’re only looking at directly quantifiable outcomes (i.e., reduced revenue), then no. However, I would argue that the improved customer experience (i.e., reduced return rate, greater satisfaction with the product) will more than makeup for it in the long-term.

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

The second part of the equation covers cost where a big chunk goes to compensation. Developing new features or systems requires data scientists and engineers. Take their monthly compensation and multiply it by the development time required (e.g., 3 months)—that’s the development cost. There’s also the ongoing cost of operating and maintaining the system (e.g., on-call, software updates, etc) which can cost 2 - 4 weeks every year.

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

The other big cost involved is infra, especially if you need to work with large volumes of data or deep learning. If we’re running in the cloud, we can estimate the cost of each job based on the time required per job, the number of instances (i.e., machine) required, and the cost per instance hour. If our predictions are generated on-the-fly (i.e., online inference), we’ll also need instances to serve our model—this can get expensive, especially if we need GPUs. (If you have on-premise hardware, your costs will differ.)

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

Capabilities & learning exercises apply to all problems

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

We’ve seen how it can be difficult to quantify customer benefits, especially if these benefits don’t directly increase revenue or reduce cost. This extends to problems where solving them has no direct customer benefit at all. However, solving such problems leads to capabilities and learning that help us to solve other problems.

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

Capabilities act as multipliers, often to reduce the cost of solving other customer-facing problems. For example, we might have the problem of getting features into production—building/adopting a feature store seems like the right solution. In this case, the feature store doesn’t generate revenue on its own, but it reduces the effort needed to put features into production (see example below).

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

GoJek found that getting features into production was difficult. Engineers had to spend time setting up infra, and data scientists had to rewrite offline, batch feature transforms to work online. Thus, they built Feast, a feature store that allows data scientists to use features—for training and serving—via a simple API.

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

This enabled feature sharing across teams and reduced the time spent by data scientists brainstorming for features in their offline experiments. Feast also made it way easier to use those same features in production. This reduced the time spent getting their machine learning models into production. (More on feature stores here.)

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

Another example is building a pipeline that enables data scientists to deploy their own machine learning models, instead of having to wait for ML engineers. (We can rig a simple pipeline with Docker and SageMaker). Similarly, this cuts development time and cost, allowing the team to solve more problems in the same amount of time.

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

Capabilities also include research and data assets. For example, we might invest time in training embeddings of tweets, products, or stores that can be used across various teams and applications. This reduces the cost of each team creating their own embeddings. Also, the addition of embeddings (as features) often gives a boost to the performance of existing machine learning systems. Similar work includes building knowledge graphs that other teams can use in their applications (e.g., LinkedIn, WalMart, Airbnb).

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

Taken together, engineering capabilities, research, and data assets help to reduce development costs and increase iteration rate. Assuming they cut the development cycle by half, this means we now have the time and resources to take on twice as many problems—that’s how capabilities contribute as a multiplier.

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

Another set of problems we can tackle are learning exercises. These are problems where we are uncertain about our ability to solve them, or if they bring any benefits. Nonetheless, solving these problems can be valuable. Thus, we might invest a month or two in a learning exercise to gain more clarity.

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

For example, product and business stakeholders might be bullish on the benefits of image search and recommendation, especially for categories such as fashion, furniture, and toys. However, the data science team is uncertain whether we have the capability for it (e.g., deep learning on images at scale). To gain clarity, we might conduct a series of learning exercises, first with image classification, then with image search and recommendation. The outcomes of these learning exercises pave the way and allow us to solve problems that were previously thought unsolvable.

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

Incremental vs. Disruptive (aka short vs. long-term)

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

Other than costs and benefits, I find it helpful to also consider if the problem requires an incremental or disruptive solution. Incremental changes include improvements on existing systems (e.g., new feature columns) while disruptive changes include building a new (replacement) system. From this perspective, incremental and disruptive changes are sometimes viewed as short-term vs. long-term efforts (though there can be simple, quick solutions that are disruptive).

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

Incremental solutions require less time, lead to small wins, and demonstrate consistent progress. This helps the team win trust within the organization, especially if the team is new. Business stakeholders love incremental results that they can parade at monthly/quarterly management updates.

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

Jumping from S-curve to S-curve in the music industry (source)

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

Nonetheless, incremental improvements eventually plateau and it’ll require a disruptive solution to step up to the next innovation curve. Take music for example:

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

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

From the example above, each disruptive solution provides a step-up on the customer experience, from vinyl records to cassettes (portability) to CDs (quality) to MP3 players (quantity) to streaming (on-demand).

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

The same applies to data and machine learning. For data processing and transformation, there’s only so much we can squeeze out of SQL queries on a traditional, non-distributed database. We’ll eventually need to bite the bullet and shift to a distributed framework such as Spark or Flink. This disruptive change leads to a step improvement, letting us work with larger amounts of data, run jobs at greater frequency, and even process streaming data.

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

In machine learning, switching from conventional models (e.g., linear regression, decision trees) to deep learning can also lead to step improvements in model performance. We can also advance how we use machine learning—for example, by switching from daily recommendations to real-time recommendations. Real-time recommendations can serve customers better when the customer journey is time or context-sensitive, or when we have no historical data about customers (e.g., cold-start problem).

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

At the risk of stereotyping, business stakeholders bias towards faster, incremental improvements while data scientists and engineers prefer working on longer-term, disruptive solutions. I’ve found that picking a mix of incremental and disruptive problems/solutions leads to the greatest benefit in the medium to long-term.

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

Pitfalls: Resume driven development & Pet projects

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

That said, the pendulum can sometimes swing too far towards solving disruptive problems. One symptom of this is resume driven development, where engineers deliberately use new or popular technologies to embellish their resume—it’s not about what works best but what’s the coolest. This happens in machine learning too, where data scientists wedge the latest state-of-the-art techniques (GPT-4, Vision BERT, etc.) into projects.

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

Sadly, this happens too often in tech, where people are expected to deliver sophisticated (read: byzantine) solutions to demonstrate scope and depth. This leads to unnecessarily complex systems that cut across multiple teams, involve twice the tech needed, and apply deep learning techniques that were just published yesterday. As a result, we sometimes see a trail of husks that were abandoned when their creators got promoted or moved on.

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

Beware the Highest Paid Person's Opinion and Zero Evidence But Really Arrogant (source)

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

Another pitfall is jumping into a problem because it’s someone’s pet project. We might do this to earn the trust of important stakeholders, or because we don’t know how to (or can’t) say “no”. Sometimes, the stakeholder loses interest after we’ve poured significant time and resources into solving the problem. Or it ends up being a wild goose chase because we didn’t think through the problem enough.

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

When the team is new, taking on such projects can help to demonstrate value and build trust with stakeholders. Nonetheless, we’ll eventually have more problems than resources and will need to be more deliberate about choosing problems to tackle. One solution is to work with stakeholders to define the problem via a one-pager and get their commitment to follow through with the project.

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

Framing it in a 2 x 2 of Benefits vs. Innovation

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

To summarize what we’ve discussed above, let’s try to frame it in a 2 x 2. On the vertical axis, we have benefits ranging from positive to non-positive. On the horizontal axis, we have innovation ranging from incremental to disruptive.

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

Choosing problems on the scale of benefits (vertical axis) and innovation (horizontal axis)

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

Positive & incremental: This includes improvements to existing systems (e.g., new feature columns, updating ML architecture). Such problems allow for consistent, steady progress, and solving them helps to earn trust. Sometimes referred to as “low-hanging fruit”.

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

Non-positive & incremental: Sometimes, we make multiple small changes that add no value but exponentially increase complexity. Can lead to “death by a thousand cuts”.

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

Positive & disruptive: This includes building new systems or adopting ML breakthroughs that results in positive value within the short to medium-term. A no-brainer.

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

Non-positive & disruptive: This requires more thought. Are we building new capabilities that multiply the team’s output, or it is a learning exercise to unlock higher-value problems? Or is it a pitfall of resume-driven development or following the HiPPO’s opinion? Thread carefully.

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

Like most 2 x 2s, this is oversimplifying the real-world. Nonetheless, I hope you’ll find the concepts discussed—cost-benefit analysis, capabilities, learning exercise, incremental vs. disruptive changes—useful when choosing and prioritizing your data science and machine learning problems. Have any feedback? Let me know at @eugeneyan!

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

How to choose machine learning problems?

• Quantify costs & benefits
• Focus on capabilities that multiply output
• Do exercises that unlock higher-value problems
• Avoid resume driven development & pet projs
• Trade off incremental vs. disruptivehttps://t.co/Md359mVmC3

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

Thanks to Yang Xinyi for reading drafts of this.

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

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

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

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

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

or

или

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

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

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

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