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

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

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

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

  1. Бизнес-результат: как будут использоваться результаты модели? Это вариант использования потребления в реальном времени, когда другое приложение будет вызывать конечную точку модели через Rest API? Или достаточно ли периодических прогнозов (ежедневно, еженедельно, ежемесячно)?
  2. Доступность данных. Какие атрибуты данных доступны в качестве входных данных для модели? Достаточно ли у них деталей, чтобы быть полезными (например, если вы строите модель для прогнозирования ежедневных продаж, есть ли у вас данные, которые обновляются хотя бы ежедневно)? Совместимы ли исходные системы данных с результатами вашего бизнеса?

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

Спринт. Спринт - это ключевая единица итеративной разработки в процессе машинного обучения. Обычно он длится 2–4 недели и включает в себя все действия, показанные на Рисунке 1 ниже. В типичном спринте специалист по анализу данных может получить доступ к необработанным данным из нового или существующего источника данных, выполнить создание идей и разработку функций, а затем повторно обучить и протестировать модель машинного обучения перед ее развертыванием на конечной точке или выполнением пакетной оценки. Точность модели в конце спринта имеет меньшее значение, чем улучшение точности по сравнению с предыдущим спринтом.

Спринт 0. Спринт 0, или первый спринт, имеет несколько иную структуру, поскольку он направлен на закладку основы для будущих спринтов. Спринт 0 - это когда специалист по анализу данных создаст конвейер проектирования функций и обучения модели. Это значительно ускоряется, если специалист по анализу данных имеет доступ к «инструментальным средствам машинного обучения» определенного типа, где уже существует доступ к источникам данных и программному обеспечению или пакетам для разработки моделей. Во время спринта 0 специалист по обработке данных также начинает выбирать алгоритмы-кандидаты, наиболее подходящие для типов данных и заинтересованных сторон бизнеса.

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

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

Структура команды: ключевые роли при создании продукта Agile ML: Исполнительный спонсор, Владелец продукта, Эксперт по предметам данных , инженер по данным, инженер по машинному обучению и специалист по данным. Эта основная группа может быть дополнена инженерами-программистами, инженерами DevOps и другими ролями по мере необходимости в зависимости от определения продукта.

Полученные результаты

Как и в случае с любой другой структурой, концепция Agile ML полезна ровно настолько, насколько она приносит результаты. В частности, для одного клиента доказательство концепции обнаружения аномалий, доставленное через эту структуру, было весьма успешным по трем ключевым причинам:

  1. Гибкое машинное обучение поощряло участие нетехнических заинтересованных сторон, предоставляя прозрачность процессу, который часто может показаться черным ящиком. Спонсоры проекта могли участвовать в процессе создания идей, делясь своими гипотезами о том, какие входные данные будут коррелировать с переменной результата (т. Е. Среднесуточной температурой в качестве предиктора ежедневного дохода от продаж), а затем повторно откалибровали каждый спринт в сессиях уточнения бэклога. .
  2. Гибкое машинное обучение позволяло группе по анализу данных сосредоточиться на результатах, рассматривая модель как продукт и итеративно добавляя функции. Структура спринта сборки и развертывания идеально интегрируется с мышлением DevOps непрерывной доставки, которое формирует лучшие в своем классе группы по анализу данных. Создавая наши модели-кандидаты в Sprint 0, мы избежали погони за точностью за счет увеличения сложности модели и вместо этого установили приоритеты для источников данных и функций.
  3. Agile ML сократило время окупаемости до недель вместо месяцев. Поскольку мы отслеживали, как итеративно улучшалась модель машинного обучения в течение каждого спринта (рис. 2), мы смогли принять более обоснованное решение о том, когда остановить разработку модели и перейти к следующей инициативе, вместо того, чтобы гнаться за идеальной моделью с открытым исходным кодом. закончилась временная шкала.

Slalom успешно предоставил доказательную концептуальную модель, которая позволила заинтересованным сторонам бизнеса заранее прогнозировать и, следовательно, смягчать аномалии. Хотя в этом случае мы действительно нашли значимые предикторы, мы установили ожидание, что сбой возможен, и смогли ограничить время потенциального сбоя, используя структуру спринта. Если бы мы не добились значительного повышения точности модели между спринтами 1 и 2, а затем снова между спринтами 2 и 3, мы бы остановили разработку этого продукта и перешли к следующему.

Следующие шаги

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

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

Патрик Догерти (Patrick Dougherty) - руководитель отдела данных и аналитики в новом офисе Slalom в Шарлотте. Вы можете связаться с ним по электронной почте [email protected].