Руководство по ускоренной разработке продуктов машинного обучения с помощью Agile
В этой статье основное внимание будет уделено реальным приложениям машинного обучения в контексте гибкой разработки продуктов. Это руководство предназначено для того, чтобы внедрить продукты Agile для машинного обучения и быстрее выполнять итерации для достижения исключительных результатов для клиентов. Некоторые из использованных примеров взяты из моего опыта работы в телекоммуникационной отрасли, где я работал над расширением возможностей обработки данных в одной из крупнейших телекоммуникационных компаний мира. Поскольку все компании разные, а их клиенты и варианты использования уникальны, это должно служить планом для разработки Agile ML, а не авторитетным мнением.
Прежде чем мы начнем, несколько советов о том, как будут использоваться определенные термины:
Команда Data Science: междисциплинарная команда, целью которой является создание продукта.
Машинное обучение. Процесс создания моделей производственного уровня с оптимизированными и задокументированными автоматическими тестами и обработкой ошибок. Подробнее о том, что такое продакшн-окружение, можно прочитать в этой статье от PagerDuty.
MLOps: методология поддержки инфраструктуры, конвейеров и других инструментов и платформ для достижения результатов машинного обучения.
Scrum:методология, которая существует для решения сложных задач и недостаточной видимости всех возможных будущих результатов. Он стремится предоставить способ решения сложных проблем, которые также присутствуют в разработке машинного обучения. Например, создание решения для предотвращения оттока или рекомендательной системы для прогнозирования того, какие устройства следует рекомендовать клиентам.
Спринт. Короткий, ограниченный по времени период, в течение которого выполняется работа, обычно две недели.
Продукт
Существуют разные интерпретации того, что является целью команды по науке о данных. Тем не менее, продукт всегда должен быть результатом клиента. Вы можете определить его как реализацию модели машинного обучения, но не как саму модель. Потребность клиента определяет, каким будет продукт. Продукт не определяется исключительно специалистом по данным или владельцем продукта, это скорее идея, которая материализуется через несколько итераций. В разработке программного обеспечения продукт не является программным обеспечением или функцией, добавленной к программному обеспечению. В командах по науке о данных продукт — это опыт работы с клиентами, поддерживаемый применением данных с помощью методов науки о данных. Результат в разработке продукта достигается в соответствии с определением готовности, с которым согласна команда.
Баланс имеет значение
Одним из распространенных препятствий для эффективного масштабирования является отсутствие правильного баланса навыков в команде. Например, если у вас слишком мало специалистов по данным, вы не сможете создать полезный актив данных, с которым будут работать специалисты по данным. Краткосрочным решением может быть перекрестное обучение специалистов по данным самообслуживанию и использованию инструментов Data Engineering, однако зрелая команда по разработке продуктов для обработки данных будет иметь все необходимые навыки.
Машинное обучение не существует в вакууме, обычно оно является частью сложного процесса доставки, поддерживаемого множеством различных технологий и людей. В состав продуктовых команд обычно входят исполнительный спонсор (например, руководитель отдела маркетинга), специалисты по данным, инженеры по машинному обучению, инженеры по данным, владелец продукта, разработчики DevOps или платформы, инженеры-программисты и другие, в зависимости от варианта использования.
Если продуктовая команда становится слишком большой, ее следует разделить на одного владельца продукта и сосредоточиться на функциях. Например, группы продуктов машинного обучения в телекоммуникационном гиганте редко превышают 7 человек и обычно состоят только из одного специалиста по данным и одного инженера по данным. Функцией может быть что угодно: от введения новой, улучшенной версии модели до нового способа отображения рекомендаций на веб-сайте. Владелец продукта должен сосредоточиться на общей картине, а не на функциях. Между тем, команда должна сосредоточиться на целях спринта, связанных с функциями, уточняя и повторяя их по ходу дела. На практике это может означать создание базовой модели с 70-процентной точностью для оттока, ее внедрение для снижения оттока в краткосрочной перспективе, а затем работу над повышением точности модели с каждой итерацией. Это можно сделать, добавив новые точки данных или, например, поэкспериментировав с архитектурой модели.
Все модели ошибочны, но некоторые из них полезны
Помните, что Agile не всегда может быть лучшим способом делать что-то. Например, эксперимент с беспилотным автомобилем может быть не лучшим местом для выпуска функций, которые приводят к рискованным результатам для клиентов, таких как новая версия системы технического зрения без тщательного тестирования. Если скорость доставки необходимо сопоставить с рисками преждевременной доставки модели, вы можете использовать более традиционный анализ затрат и выгод, чтобы обосновать свой подход. Несмотря на это, группа по науке о данных, как и традиционная группа по доставке программного обеспечения, должна сосредоточиться на результатах, будь то создание конвейера данных, добавление функции в существующую модель машинного обучения или создание новой модели.
На практике модель может не быть развернута в производственной среде, даже если она очень точна. В телекоммуникационном гиганте я видел модели, которые не были реализованы по разным причинам: отсутствие заинтересованности со стороны бизнеса, непонимание того, что модель делает или призвана предсказать, стоимость или сложность внедрения или сроки. Не волнуйтесь, если это произойдет, продолжайте повторять. Вы всегда можете вернуться к модели позже, когда ее реализация будет иметь больше смысла.
В конце концов, человек
Поскольку мы знаем, что машинное обучение не существует в вакууме, всегда будут зависимости от других людей, как внутренних, так и внешних, которые могут помешать вашему прогрессу в достижении целей спринта. Такие компании, как Amazon, пытались уменьшить трения и зависимость от человеческих разговоров, используя API для получения ответов по всему бизнесу. Но это не всегда возможно — по крайней мере, поначалу — для развивающейся компании или новых внедрений. Командам, занимающимся наукой о данных, по-прежнему придется полагаться на старые добрые человеческие разговоры.
Важным навыком в Agile-командах является общение, особенно общение с людьми из разных слоев общества. Например, техническая вики должна быть использована и понятна как техническими, так и нетехническими заинтересованными сторонами. Команда по науке о данных должна согласовать цели каждого с достижением целей спринта и, таким образом, с улучшением качества обслуживания клиентов.
В отличие от научных кругов, цель машинного обучения для разработки продукта — создать продукт, а не модель. Нет никакой ценности ни в модели, которая никогда не будет запущена в производство, ни в модели, которая не улучшает качество обслуживания клиентов. Если вы не уверены, насколько осуществимо что-то (например, создание новой архитектуры модели), создайте ограниченный по времени всплеск, когда новая функция отменяется или откладывается, если она не реализуема в течение установленного срока.
Одной из вольностей, которую мы изначально могли себе позволить в команде по науке о данных, было время, затрачиваемое на разработку модели. Многие специалисты по обработке и анализу данных, в том числе и я, хотят предоставить миру лучшую модель — оптимизировать такую метрику, как точность, — а затем наблюдать, как наша модель дает ожидаемые результаты в реальных условиях. Однако это не так в мире разработки продуктов. Анализ затрат/выгод подсказывает, что лучше предоставить базовую модель, чем вообще не использовать ее. Как правило, лучше предоставить модель, которая точно предсказывает отток в 70% случаев, пока вы продолжаете итеративно настраивать ее, чтобы повысить точность модели.
Однако бывают случаи, когда базовая модель нежелательна. Например, исследование 2019 года* показало, что модели распознавания лиц гораздо менее точны при идентификации лиц, принадлежащих к разным этническим группам. Это может быть проблематично в приложениях, развернутых государственными учреждениями, например полицией. Следовательно, некоторые города запретили использование таких технологий, однако я считаю, что ответ лежит где-то посередине с необходимостью более тщательного контроля в форме проверки человеком, пока они не созреют. Риски развертывания технологии необходимо сопоставлять с преимуществами и рассматривать в каждом конкретном случае.
Покажи мне деньги
Это теория. Давайте поговорим о практическом применении вышеизложенного на примере из реальной жизни, когда я работал в сфере телекоммуникаций. Стало ясно, что рекомендации, которые мы размещали на нашем веб-сайте, были неуместными и не обеспечивали удовлетворительного обслуживания клиентов. У нас было ПОЧЕМУ, но прежде чем перейти к КАК, для прогресса требовалась определенная поддержка. Нашими основными спонсорами были команды по обновлению и перекрестным продажам, которые были заинтересованы в повышении продаж. Наша интуиция подсказывала, что рекомендательная система сможет давать лучшие рекомендации, чем текущие рекомендации на основе правил на веб-сайте, и что мы можем проверить эту гипотезу, направив небольшой процент трафика на новую систему. Мы продали это как доказательство концепции спонсорам, что потребовало созыва команды для создания продукта.
Помните, что продуктом был клиентский опыт получения лучших рекомендаций, а не сама система рекомендаций, поэтому нам нужна была междисциплинарная команда, состоящая из специалистов по данным, инженеров данных, разработчиков интерфейса и AWS SME. Наша первая зависимость также стала очевидной, поскольку нам нужно было передавать потоковые данные, найденные в кластерах Kafka, в AWS Kinesis, чтобы передать их рекомендательной системе. Со всеми этими знаниями мы могли определить истории и начать планировать спринты.
В ходе нашего первого спринта мы стремились разблокировать зависимость от данных, поэтому нашим инженерам по данным пришлось работать вместе с локальными техническими командами, чтобы данные из кластеров Kafka передавались в AWS через коннектор. Как только данные достигли AWS, необходимо было установить конвейеры Glue, чтобы обеспечить извлечение загрузки преобразования (ETL) из потоков Kinesis в режиме, близком к реальному времени. В очередной раз инженеры данных сыграли важную роль в обеспечении функциональности конвейера и необходимых базовых преобразований. Тем временем специалисты по обработке и анализу данных в команде изучали документацию по AWS Personalize — готовому решению, которое позволит быстро создать прототип с минимальной конфигурацией. Разработчики веб-сайта были заняты пониманием того, какие ответы API необходимы для интеграции с веб-сайтом, например, идентификатор клиента и идентификатор продукта для рекомендуемых продуктов, которые будут отображаться на веб-сайте, а также объединение идентификаторов продукта с изображениями конкретного продукта из другой базы данных. . Пример того, как скорее всего выглядела наша доска в какой-то момент времени, можно найти ниже.
Некоторые из первоначальных проблем с доступностью данных означали, что у специалистов по данным не было данных для обучения модели. Пока инженеры данных и платформ работали над переносом данных в AWS, специалисты по данным создали прототип базовой модели с фиктивными данными, которые они создали сами, чтобы воспроизвести формат данных, которые будут доступны им в следующем спринте. Таким образом, в Agile очень важно стараться как можно быстрее удалить блокираторы и разрешить другим. Еще одной проблемой было слишком много вариантов отображения рекомендаций на веб-сайте. В Agile паралич принятия решений можно устранить, установив, как хорошо выглядит в данный момент, а затем пересматривая его позже.
После многих итераций и решения проблем POC превратился в MVP, который был запущен в производство, а часть клиентов получила новые персонализированные рекомендации. Взаимодействия с клиентами сводились в отчет, в котором отслеживались такие показатели эффективности, как количество кликов и коэффициент конверсии. Они были сопоставлены с взаимодействиями с клиентами на странице без механизма рекомендаций. В целом эксперимент оказался успешным, и проект был реализован в более широком масштабе с функцией цикла обратной связи, которая автоматически переобучает модель и выбирает лучшую модель в соответствии с конкретными показателями.
Создание будущего. Ежедневно.
Я надеюсь, что этот план достижения исключительных результатов для клиентов поможет вам. Каждый бизнес уникален, поэтому то, что работало у нас в то время, может не сработать у вас. В Slalom Build мы работали с клиентами из разных отраслей в сценариях использования, охватывающих MLOps, разработку платформ, разработку данных, разработку программного обеспечения, внедрение облачных технологий и многое другое, поэтому напишите нам, если вы хотите узнать больше о совместной работе.
https://www.slalombuild.com/ru-ru
Вот несколько полезных ссылок для более глубокого изучения MLOps и прочего:
MLOps: конвейеры CI/CD, контроль версий, четко определенные процессы проверки PR, позволяющие специалистам по обработке и анализу данных экспериментировать в контейнерных средах.
Платформа: многократно используемая инфраструктура и архитектура для поддержки различных вариантов использования. Вычисления, хранилище данных и API-интерфейсы являются ключевыми строительными блоками для большинства моделей машинного обучения.
Инженерия данных: приведенные ниже руководства содержат многоразовые схемы конвейеров ETL, витрины данных и примеры рабочих процессов.
Машинное обучение: разнообразный портфель моделей и знание разных типов моделей для разных вариантов использования (например, когда использовать XGBoost или нейронную сеть). Автоматизированные сценарии настройки гиперпараметров и схемы создания моделей. Многие архитектуры моделей могут быть повторно использованы для различных вариантов использования, например: схемы классификации моделей оттока могут быть повторно использованы для классификации клиентов с обновлением, изменятся только данные и цель.
Отличная шпаргалка, которая отражает широкий спектр машинного обучения:
* Исследование 2019 года, опубликованное BBC — https://www.bbc.com/news/technology-50865437
Благодарим Яснин Ашрофф, Майкл Пилосов и Чака Снайвли за неоценимую помощь в редактировании этой статьи.
