Гибкое управление DS продуктами

Введение

VentureBeat утверждает , что 87% DS проектов не доходят до прода. Это не единственное такое исследование, есть и другие . В целом цифры схожи.

 

 

В чем причины? На одной из конференций на воркшопе с сайентистами мы получили следующий набор проблем:

 

• Неготовность заказчика
• Недостаточное погружение DS в бизнес
• Качество и достаточность данных
• Отсутствие/качество тестирования
• Нет стандартного пайплайна
• Отсутствие артефактов работы
• Проблемы коммуникации в команде
• Сложности с оценкой результата
• Сложность внедрения и сопровождения

 

Далее в статье мы рассмотрим проблемы и поразмышляем о методах их решения.

 

Командная работа

Проблемы неготовность заказчика

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

— Нам нужны данные для обучения.

— Мы подготовились! У нас есть статьи на Wiki. Пусть ваш чат-бот их прочитает и выучит.

— Ээээ. Так не работает потому что… бла-бла…

— Мы разочарованы. Какой же это искусственный интеллект?

 

Заказчик со стороны бизнеса не всегда адекватно понимает возможности и ограничения DS. Иногда он значительно преувеличивает его возможности.

 

У одной нефтяной компании есть бензовозы. Водители засыпают, курят (в бензовозе!), сажают каких-то друзей или подруг и так далее. Есть камеры в кабине, следящие за водителем. Отсматривать эти камеры само собой некому, просто выборочно проглядывают, если есть подозрения.

 

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

 

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

 

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

 

Сайентисты не разбираются в бизнесе, заказчики в Data Science и этот коммуникационный разрыв надо чем-то заполнять.

 

AI Product Manager (AIPM)

 

AIPM — новая роль, которая должна появится на этом стыке.

 

Первая и основная задача AIPM — понять и коммуницировать команде, какую проблему бизнеса мы решаем и точно также ясным образом транслировать бизнесу результаты работы команды.

 

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

 

Качество работы AI-продукта зависит прежде всего от качества исходных данных. Чаще всего эта задача касается работы других подразделений компании. Даже если полезный AI-продукт у команды не получается, честным итогом работы DS-команды вполне могут быть предложения по изменению подходов работы с данными для других подразделений в компании.

 

Иначе говоря, недостаточно просто сказать “ничего не вышло, потому что данные плохие”. Что нужно изменить в компании, чтобы у нас появились хорошие данные? Как превратить эти идеи в план? Как довести до результата? Это тоже должно входить в сферу ответственности менеджера продукта.

 

Многие AI продукты потребуют перестройки бизнеса. Будут появляться новые департаменты, сокращаться или трансформироваться существующие.

 

Пример. Вы провели успешный пилот системы слежения за соблюдением техники безопасности на объектах стройки. Теперь вместо специально обученных людей, поглядывающих на камеры, это делает нейронная сеть. Для масштабирования продукта на всю компанию надо суметь решить море вопросов. Как будут перестроены регламенты по безопасности? Кто будет отвечать за инциденты по безопасности в новой схеме? Чем будут заниматься люди, ранее следившие за ТБ? Как будет проходить внедрение? Какое подразделение будет поддерживать системы? Как оно будет бюджетироваться? И т.д. и т.п.

 

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

 

AIPM отвечает за ценность итогового результата для компании и пользователей и имеет право принимать соответствующие решения.

 

Недостаточное погружение DS в бизнес

С точки зрения заказчиков, общение с сайентистами в проекте выглядит так: в какой-то момент вся команда вдруг переключается на совершенно непонятный язык и с этой минуты становится совершенно непрозрачно практически все, что затем происходит.

 

 

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

 

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

 

Как наладить прозрачность в проекте для всех сторон? Есть два пути: научить заказчика говорить на языке DS и второй — научить сайентистов говорить на языке бизнеса. Какой путь выбрать?

 

В Software Engineering мы однозначно приняли решение в пользу второго, попросту потому, что первое нереалистично. Для общения между всеми участниками проекта мы используем пользовательскую историю. Это задача, имеющая ценность для клиента и пользователя, описанная на их языке, которая может быть доделана до конца за разумное время. Можем ли мы сделать похожий трюк в DS проектах?

 

Гипотеза

 

В Data Science аналогом пользовательской истории является гипотеза. К ней предъявляются такие же критерии:

 

• Описана на языке, понятном бизнесу.
• Указаны целевые метрики
• Достаточно атомарна. Большие гипотезы лучше разбивать на более мелкие.
• Достаточно крупная, для того, чтобы команда могла сфокусироваться на ней. Мелкие гипотезы, которые проверяются совместно проще объединить в одну
• Содержит входные предположения и ограничения (assumptions).

 

Пример гипотезы:

 

Возможно получить отрисовку скелета человека на видео в реальном времени человека на мобильном телефоне без видимых задержек для визуализации и анализа техники выполнения упражнений

 

Предположения

— Интернета на моб телефоне нет

— iPhone X и все выше него

Нежесткие ограничения

— 200ms

— 5-8 fps

 

На раннем этапе проекта мы не всегда способны сформулировать гипотезу. На практике мы часто вместо нее используем вопрос (Question). Это один или несколько вопросов, ответ на которые мы хотим получить.

 

Канбан-доска

 

В большинстве продуктов гипотезы (или вопросы) проходят по достаточно стандартному жизненному циклу. В CRISP-DM он выглядит следующим образом:

 

 

Для повышения прозрачности процесса очень удобно использовать канбан-доску. Каждый тикет на доске представляет собой гипотезу и движется слева направо.

 

Состав колонок может меняться в зависимости от продукта и специфики. Например, если ваша команда занимается в большей степени исследованиями, то последней перед Done колонкой может быть Customer Acceptance. Если ваша команда выводит в прод ML модели, то вам может понадобится колонка Engineering (или Development) для оборачивания модели в продакшн код и колонка Testing для A/B тестирования результата.

 

Помимо гипотез, по доске также могут двигаться и другие типы работ. Например, часто используется задача (Task). Это инженерная задача, например по автоматизации пайплайна, не связанная ни с какой гипотезой.

 

Практики канбан

 

Давайте рассмотрим несколько практик канбана и что они означают в применении к продуктам в Data Science.

 

• Визуализация потока работ. Гипотезы и другие работы помещаются на доску. Это позволяет сделать работу прозрачной для команды и всех заинтересованных лиц.
• Ограничивайте WIP. Позволяет команде сфокусироваться на важных гипотезах и ускорить их прохождение по доске. Оно формулируется отдельно для каждой колонки. Например, мы можем указать, что одновременно в анализе находится не более двух гипотез.
• Управляйте потоком.
• Устанавливайте формальные политики (Explicit policy). Для каждой колонки создается чеклист. Работа может быть переведена на следующую колонку только если выполнены все условия чеклиста. Например, в такой чеклист может входить правила проведения experiment review для колонки Modeling.
• Встраивание обратной связи. Ежедневный стендап позволяет получать обратную связь всем участникам команды.
• Совместное улучшение процесса. Команда регулярно собирается для обсуждения процесса и его улучшения. Принятые решения часто отражаются на доске: появляются новые колонки, изменяются формальные политики, добавляются новые задачи (например, по автоматизации пайплайна).

 

Качество и достаточность данных, отсутствие / качество тестирования

Отличие DS проектов от разработки ПО — часто результатом работы является не продукт, который можно протестировать, а несколько чисел.

 

В разработке ПО большинство ошибок рано или поздно будут обнаружены. Даже если ошибка просочится через тестирование и показы заказчику, ее обнаружит пользователь.

 

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

 

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

 

Эта проблема очень сложная и комплексная и ее решение должно строится в нескольких направлениях.

 

Data quality

Нам жизненно необходим строгий процесс верификации, валидации и накопления информации о данных внутри организации.

 

Верификация убеждается, что при работе с данными команда не допустила ошибок. Все данные достаются, трансформируются, размечаются и хранятся без ошибок.

 

Задача валидации — убедится, что данные правильно интерпретируются, то есть мы верно понимаем их значение и смысл с точки зрения бизнеса.

 

Для решения этой сложной задачи во многих компаниях создается отдельная роль и компетенция — data quality engineer или . data steward Его задача — обеспечить качественные и легко доступные данные внутри организации.

 

Experiment review

Вы бы удивились, узнав какой процент команд не занимается проверкой своих моделей. Даже очевидное требование воспроизводимости (reproducibility) соблюдается далеко не везде ( и в академической науке в том числе ).

 

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

 

В одном крупном ритейле над задачей кросс-проверки задумались после забавного случая. Возникла типовая для команды задача проверки эффекта от маркетинговой акции. Из-за спешки задачу нечаянно дали сразу двум сайентистам параллельно и назависимо. Через несколько дней один выдал отчет, что эффекта нет, а второй показал большой эффект.

 

Процесс должен включать строгий experiment review — проверку результатов работы одного члена команды другим.

 

Такое ревью обязательно должно быть контекстным, то есть тот, кто проводит ревью должен очень хорошо понимать бизнес-задачу. В противном случае вместо проверки решения задачи мы получим просто техническую проверку кода.

 

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

 

Есть несколько паттернов эффективной работы.

 

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

 

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

 

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

 

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

 

Configuration management

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

 

Все разработчики ПО не представляют работы без инструментов версионного контроля (таких как git).

 

Особенностью DS проектов является также наличие большого количества тяжелых датасетов. Они также должны быть частью такого версионного контроля.

 

Сложности с оценкой результата

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

 

Если нет постоянной коммуникации между ними, то из-за отсутствия информации сайентисты тратят много времени на проверку гипотез, не имеющих ценности.

 

Есть и вторая сторона проблемы — получение максимальной ценности от экспертов. Именно они могут придумать максимально ценные гипотезы благодаря опыте и чутью в индустрии. Для этого их нужно вовлекать в процесс оценки промежуточных результатов.

 

По-сути, за время проекта сайентисты должны разобраться в предметной области, а эксперты — в DS.

 

Мгновенная отчетность

 

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

 

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

 

Сложность внедрения и сопровождения

Итак, мы получили работающую на тестовой выборке модель. Что получится при выводе на реальных потребителей? Насколько новое решение лучше существующего?

 

Testing in prod

Отдельная большая область — A/B тестирование работающих моделей в проде.

 

Смысл A/B тестирования в следующем. Сравнивать новый продукт с прошлым месяцем или годом бесполезно, там была совсем другая ситуация. Вместо этого пользователей случайным образом делят на сегменты. Контрольный сегмент “A” остается без изменений, а пользователи из сегмента “B” получают измененную версию продукта. После измерения разницы можно делать выводы о реальном эффекте на бизнес.

 

Нет стандартного пайплайна

Эффективность DS команды определяет скорость и качество проверки гипотез. Самыми важными метриками эффективности являются следующие:

 

• Throughput — количество проверяемых гипотез в единицу времени и

 

• Lead time — среднее время от постановки гипотез до ее проверки/поставки.

 

Lead time у похожих по контексту и технологиям команд может отличаться в десятки раз — от недели до нескольких месяцев.

 

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

 

Pipeline automation

Автоматизация пайплайна является аналогом CI/CD в разработке ПО и должна обеспечивать следующие вещи:

 

• ETL
• Автоматическая проверка reproducibility
• Автоматический прогон тестов
• Управление экспериментами
• Автоматизированное развертывание
• Управление данными
• A/B тестирование
• Отчетность

 

Коммуникации в команде

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

 

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

 

Адаптация гибких подходов к AI проектам

Практики гибкой итеративной работы команд существуют и давно используются в разработке ПО. Однако, у них есть явные ограничения, которые не позволяют их транслировать вслепую в AI.

 

Например, не всегда AI команда способна достичь инкремента продукта за спринт. Ревью спринта совместно с заказчиком может поставить в тупик, так как итогом часто является просто одна цифра. В середине спринта может оказаться, что все запланированная работа до конца спринта не имеет смысла.

 

Это не означает, что Agile не работает в AI. Однако, очевидно, требует адаптации к новому окружению.

 

Это опять приводит к появлению новой роли в проекте.

 

AI Delivery Manager. Прямым аналогом AIDM является Scrum Master в Scrum. Его задача — помочь команде стать эффективной. Его основной фокус — выстраивание эффективного процесса поставки командой ценного результата.

 

Выводы

Потребность в строгом, коллаборативном, и экономном процессе для создания AI продуктов будет расти. Будут появляться новые роли, такие как AI Product Manager и AI Delivery Manager.

 

Зрелая проектная команда означает высокий уровень технической культуры. Этого не так-то просто достичь. Многие сайентисты приходят в индустрию со студенческой скамьи. У них нет опыта разработки ПО и трансляция опыта из software engineering в AI совсем не гарантирована.