What I Do Before a Data Science Project to Ensure Success

eugeneyan

Start Here Writing Speaking Prototyping About

Что я делаю перед проектом по data science, чтобы обеспечить его успех

[ mechanism datascience productivity ] · 12 мин чтения

Когда кто-то приходит ко мне с задачей по data science, мне всегда не терпится сразу нырнуть в неё. Давайте поизучаем данные, построим что-нибудь крутое, принесём пользу! Да… я нетерпелив в этом плане, хотя предпочитаю смотреть на это позитивно — как на склонность к действию.

Поработав над несколькими проектами, я начал задумываться: а действительно ли это быстрее? Есть ли способ получше? Я проанализировал свою работу и понял, что терял время на таких вещах, как:

Восхождение не на тот холм Использование базуки там, где хватило бы мухобойки Уход в кроличьи норы и тупики

Чтобы это исправить, я ввёл для себя три предпроектные задачи. Несколько коллег по команде тоже попробовали и нашли их полезными. Здесь я расскажу про one-pager, time-box и разбиение задачи.

Это первая часть (до) трёхчастной серии о практиках работы над data science проектами. Смотрите также часть 2 (во время) и часть 3 (после).

Сначала нарисуйте карту до пункта назначения (One-Pager)

Карта охватывает намерение, желаемый результат, поставляемый продукт и ограничения.

Намерение (зачем?)

Какую проблему мы пытаемся решить или какую возможность хотим использовать? Какую выгоду получат клиенты? Зачем мы это делаем и почему это важно?

«Менеджмент — это делать всё правильно; лидерство — это делать правильные вещи». — Peter Drucker

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

Подход Amazon «Working Backwards» — отличный способ определить намерение и понять «Зачем?». Он начинается с движения в обратную сторону от клиента и того, какую пользу он получит. Это формулируется в виде (учебного) пресс-релиза для клиентов. Если выгоды не звучат интересно или захватывающе — обратно к чертёжной доске.

Пресс-релиз Working Backwards для AWS S3

Сравните это с «Построй — и они придут». Это хорошая киноцитата, но довольно плохой совет для продукта и техники. Знаю, что сам часто виноват в том, что начинаю с какой-то сексуальной идеи или новой блестящей технологии, строю её, а потом пытаюсь прикрутить к ней клиентов.

А что, если клиенты не придут? Это куча усилий впустую. Стартапы с ограниченными ресурсами не могут себе такого позволить.

Неясная проблема и намерение порождают ещё одну сложность: как мы решаем, какое решение лучше? Как мы узнаем, что преуспели? Записав это, мы получаем точку отсчёта. Её можно использовать для сравнения проблем при приоритизации, а также для сравнения решений при проектировании.

Желаемый результат (что?)

Теперь, когда у нас есть намерение, можно обсудить, как выглядит успех. Насколько хорошо мы должны решить эту проблему? Как мы это измерим? В data science это обычно бизнес-метрика: конверсия, экономия от снижения мошенничества, net promoter score и т.д.

«Если ты не можешь это измерить, ты не можешь это изменить». — Peter Drucker

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

Это также помогает решить, какие проекты брать. Решить задачу на 95% может потребовать в 3–4 раза больше усилий, чем на 90%; решить на 99% — в 10–100 раз больше. Учитывая ограниченные ресурсы (дайте знать, если у вас неограниченные), мы, скорее всего, не возьмёмся за задачу, требующую 99%-й точности (например, клиническая диагностика) — это позволит нам вложиться во что-то более стоящее.

Поставляемый продукт (как?)

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

Например, e-commerce платформа имеет намерение улучшить, как клиенты находят и покупают товары. Чтобы этого добиться, улучшать ли поиск? Или рекомендации? Или email-кампании? Если это рекомендатель, как мы его развернём? Это будет кеш, обновляемый ежедневно? Или сервис, принимающий клиента и/или товар на вход и возвращающий набор рекомендаций?

Это не обязательно должно быть детально проработано; сейчас нам не нужна полная архитектура и спецификации. Но полезно иметь грубый эскиз, чтобы заранее получить одобрение бизнес-, продуктовой и технической команд. Нам не нужен поставляемый продукт со всеми наворотами, который не приносит результата. Мы не хотим строить real-time мультимодальный deep learning рекомендатель, который невозможно интегрировать. Обязательно соберите обратную связь.

Ограничения (как не?)

То, как не решать задачу, часто важнее, чем как её решать. К сожалению, этому уделяется недостаточно внимания.

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

В чём разница между границами и ограничениями?

Оставайтесь внутри границ; держитесь подальше от ограничений.

Границы охватывают или ограничивают что-то, например, область применения решения. Например, мы можем решить, что наш рекомендатель не будет real-time на первой итерации. Эта граница ясно показывает, что нам не следует рассматривать, и освобождает нас, чтобы сфокусироваться на рекомендателе с ежедневным обновлением.

Ограничения запрещают чему-то меняться, например, бизнес-метрикам. Например, если мы намеренно вводим новые товары с холодным стартом в поиск, ограничение может быть «не снижать конверсию более чем на 5%». Это ограничение освобождает нас рассматривать идеи, которые могут привести к падению конверсии на 0–5%.

Хотя технически они различаются, я использую эти термины взаимозаменяемо.

Вот короткая история, иллюстрирующая бизнес-ограничение. Раньше передо мной стояла цель ввести новые товары на страницах поиска и категорий. Намерение заключалось в увеличении их (то есть новых товаров) показов, CTR и конверсии.

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

К счастью, мне было дано одно бизнес-ограничение: «Не снижать конверсию более чем на 5%». Это дало «бюджет», а также свободу экспериментировать в рамках ограничения. В результате мы смогли быстро выпустить рабочее решение. (Примечание: хотя мы ожидали падения конверсии, A/B testing показал, что она фактически выросла, хотя и незначительно.)

Технические ограничения распространены при построении machine learning систем для production. Front-end, скорее всего, имеет лимиты по latency в районе 50–100 мс, а также требования к пропускной способности (например, x одновременных запросов). Возможно, нам придётся соблюдать определённый интерфейс, схему или формат, ожидаемый потребителями.

Также мы можем столкнуться с ресурсными ограничениями. Пайплайны data science и machine learning могут быть требовательны к вычислениям и памяти. Переобучение модели может требоваться завершить за x часов на кластере из y машин. Это задаёт границы того, насколько ресурсоёмкими могут быть наши пайплайны, помогая нам сфокусироваться на построении чего-то, что можно развернуть в production.

«Ограничения двигают инновации и заставляют фокусироваться. Вместо того чтобы пытаться их убрать, используйте их в свою пользу». — 37Signals (ныне Basecamp)

One-pager (среда)

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

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

Написание one-pager теперь для меня обязательная практика (хотя я могу и не рассылать их). Я часто теряюсь в дебрях исследований, экспериментов и разработки. Слишком легко отвлечься на новые блестящие исследования и технологии или забыть, как это должно помочь клиенту. Возвращение к one-pager всегда возвращало меня на правильный путь.

Затем — определите бюджет времени и усилий (Time-Box)

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

Я склонен делать наоборот. Учитывая бюджет (читай: time-box), как нам спроектировать решение, которое в него уместится? Намерение и желаемый результат определяют time-box, а time-box определяет дизайн решения. Так же это делает и Basecamp — у них разный аппетит к различным задачам, и они соответствующим образом ограничивают объём решений.

Более важные и сложные задачи должны иметь больший time-box. Между задачей на 10 миллионов долларов и задачей на 100 миллионов вторая должна получить больше ресурсов и больший time-box. Меньшие time-box могут обойтись более простыми техниками (например, регрессией, деревьями решений), высвобождая усилия на более крупные задачи, требующие более сложных решений (например, deep learning).

Time-box будет меняться по стадиям проекта. В начале, когда мы ещё исследуем и неопределённость высока, нужны более жёсткие time-box, чтобы ограничить погоню за призраками. Когда появляется больше уверенности в выходе в production, можно выделять большие time-box.

«Работа заполняет всё время, отведённое на её выполнение». — Закон Паркинсона

Обычно мы начинаем с оценки осуществимости. Можем ли мы решить эту задачу с имеющимися данными и технологиями? Если да, то в какой мере? На этой стадии мы стремимся к быстрому и грязному исследованию. Я обычно отвожу на это 1–2 недели.

После определения осуществимости мы переходим к proof of concept (POC). На этой стадии мы сколачиваем прототип, чтобы оценить, технически ли достижимо наше решение. В идеале мы также тестируем точки интеграции с поставщиками данных вверху и потребителями внизу. Можем ли мы соблюсти технические ограничения (например, latency, пропускную способность)? Удовлетворительна ли производительность модели? Это обычно занимает месяц-два.

Если всё идёт хорошо, мы затем разрабатываем для production. На это тоже стоит установить time-box. Чрезмерно щедрая шкала времени может привести к тому, что в проект будут впихиваться второстепенные фичи, и разработка станет бесконечной — без фактического развёртывания никому от неё пользы. Это обычно занимает 3–6 месяцев, включая инфраструктуру, оркестрацию задач, тестирование, мониторинг, документацию и т.д.

(Примечание: я не решаюсь приводить конкретные цифры для каждой стадии выше, так как это действительно зависит от проекта и организации. Тем не менее, они дают представление об относительных усилиях, которые я бы вложил в каждую.)

Вот как могут выглядеть эти стадии (из предыдущего поста).

Мы постепенно увеличиваем time-box по мере роста уверенности.

Разбейте на части, чтобы выявить кроличьи норы и тупики

Наличие one-pager и time-box повышает шансы проекта на успех. Обычно этого достаточно. Тем не менее бывает полезно разбить задачу на части, особенно если она связана с незнакомыми данными или технологиями. Цель — заранее выявить возможные кроличьи норы и тупики и сократить время, потраченное на них.

Работаете с новым источником данных? Свяжитесь с DBA, чтобы понять целостность данных и частоту их обновления. Нет смысла переобучать модель в течение дня, если источник данных обновляется только в полночь. Рассматриваете новую технологию для обработки больших данных? Проконсультируйтесь с senior data engineer о потенциальных трудностях и блокерах.

«Предвидение — это не предсказание будущего, это минимизация неожиданностей». — Karl Schroeder

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

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

Это дополнительные размышления, но они экономят усилия

Может показаться, что это лишняя дополнительная работа. Но она не отнимает много времени, и я бы поспорил, что она снижает общий объём работы.

Накидать one-pager обычно занимает 1–2 дня, максимум неделю. На самом деле, чем больше времени вы тратите на one-pager, тем больше времени вы экономите. Если требуется больше времени — это значит, что проблема и идеальное решение всё ещё неясны; начинать строить сейчас — значит тратить усилия впустую.

Аналогично, правильный time-boxing гарантирует, что мы разумно инвестируем в решение в соответствии с масштабом задачи. Раннее выявление кроличьих нор и тупиков помогает нам их избежать и сокращает напрасные усилия.

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

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

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

Yan, Ziyou. (Jun 2020). What I Do Before a Data Science Project to Ensure Success. eugeneyan.com. https://eugeneyan.com/writing/what-i-do-before-a-data-science-project-to-ensure-success/.

или

@article{yan2020planning, title = {What I Do Before a Data Science Project to Ensure Success}, author = {Yan, Ziyou}, journal = {eugeneyan.com}, year = {2020}, month = {Jun}, url = {https://eugeneyan.com/writing/what-i-do-before-a-data-science-project-to-ensure-success/} }

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