Многие бизнес-компании нацелены на применение машинного обучения (МО) для улучшения продуктов и услуг. Однако специалисты по данным слишком увлекаются созданием идеальной модели и новейшими технологиями. Действуя таким образом, они забывают об одной важной вещи: разработке минимально жизнеспособного продукта (аббр. MVP). В статье мы рассмотрим три причины, почему сначала лучше сосредоточиться на выпуске работоспособного MVP, чем тратить много времени на сложную модель. В конце поделюсь тремя советами, касающимися самого MVP.
Когда шесть лед назад я только начинала работать специалистом по данным, то особо не интересовалась такими темами, как наивный байесовский алгоритм, линейная регрессия и статистика. Объясняется это полученным математическим образованием, и тем фактом, что весь перечисленный материал уже изучался во время занятий. На тот момент больший интерес вызывали нейронные сети, языковые модели, машинное распознавание образов и обучение с подкреплением. Эти темы были настолько увлекательными, что я прошла специальные курсы для быстрого их освоения. Решая уже реальные бизнес-задачи в компаниях, всегда старалась разрабатывать сложные модели и решения, которые вызывали у меня особый азарт. Зачастую они включали глубокое обучение, извлечение датасетов с веб-ресурсов и непростую архитектуру. К сожалению, в результате получался грязный и трудночитаемый код.
Как-то я несколько месяцев работала над одним проектом. Участвовала в еженедельных встречах с бизнес-клиентами, на которых мне отводилась роль единственного спикера. Но в итоге представленный конечный продукт оказался слишком сложным и неприменимым на практике. Из полученного опыта были сделаны следующие важные выводы: не усложнять решения на основе МО и меньше болтать. Надеюсь, этой статьей уберечь вас от совершения подобных ошибок и задать правильный курс действий.
Не зацикливайтесь на сложных технологиях
На мой взгляд, существуют 3 главные причины, почему не следует основывать проект на сложных технологиях.
Причина 1. Бизнес-клиентам все равно
Именно так звучит первая и самая главная причина. Заинтересованные стороны проекта не обращают внимания на технические детали модели. Им все равно, используются ли усиленные деревья (англ. boosted trees) или нейронная сеть. Они хотят знать, как предлагаемая модель помогает им в достижении бизнес-целей. Если она требует частого переобучения, можно вместо нейронной сети задействовать такую простую модель, как логистическая регрессия, и обосновать это решение быстротой ее обучения.
Как правило, от модели МО не требуется 100% точность. Ее задача — помогать в бизнес-процессах. Чрезмерные времязатраты на оптимизацию модели задерживают вывод готового продукта на рынок. Лучше всего создать MVP, убедиться, что он соответствует бизнес-требованиям, и запустить его в продакшн. Необходимо учитывать не только производительность, но и интерпретируемость, скорость вычислений, стоимость разработки, надежность и время обучения. Эти важные факторы имеют такое же большое значение для бизнес-клиентов, как и производительность.
Не только вы, но и ваши коллеги могут увлекаться сложными моделями и новейшими методами. Чаще всего к ним относятся исследователи и специалисты по данным. Если вы теснее сотрудничаете с ними, а не с бизнес-клиентами, то станете считать процесс построения модели своей главной целью. Чтобы этого не произошло, старайтесь работать в тесном контакте с заказчиками. Реализовали новую функциональность — сразу показывайте продукт и уточняйте, верны ли предположения. Незначительные на первый взгляд решения могут оказаться очень важными для бизнес-клиентов.
Причина 2. Сложная модель приносит меньше пользы, чем работоспособный MVP
Чем больше времени тратится на модель, тем меньше его остается на хорошие принципы проектирования, такие как модульный код, тестирование, архитектура, логирование и мониторинг. Если вы с самого начала правильно настроите все эти процессы, то сэкономите много времени. В надежную базу кода можно легко добавлять новые функциональности. Такой подход приносит больше пользы, чем сложная модель в Jupyter Notebook, которая может и получше работает, но зато не функционирует в продакшн. Дополнительным преимуществом простой модели является интерпретируемость. Это свойство помогает убеждать заинтересованные стороны, поскольку они видят целесообразность предварительных прогнозов.
Особенно в начале следует сосредоточиться на создании продукта, который работает, имеет надежный код и грамотно спроектированный конвейер CI/CD. Выполнение этих требований упрощает оптимизацию решения в дальнейшей перспективе. Если бизнес-клиент не настаивает на улучшении текущего решения, то можно спокойно переходить к работе над другим проектом. При этом вы не тратите напрасно время на создание “идеальной” модели.
Так работает принцип Парето. Он гласит, что 80% результата можно достичь за счет 20% усилий (так называемое правило 80/20). Зачастую создание сложной модели, функционирующей немного лучше простого решения, не укладывается в 80% результата, а превращается в обременительную и времязатратную задачу. Сложная модель — это те самые оставшиеся труднодостижимые 20%, которые требуют 80% усилий. Прежде чем начинать, убедитесь, что оно того стоит.
Причина 3. Сложные проекты требуют больше затрат на сопровождение
Чем сложнее проект, тем больше ресурсов и времени требуется для его сопровождения. Это значит, что вы тратите больше времени на исправление ошибок, оптимизацию модели, обновление данных и меньше времени на добавление новых функциональностей и улучшение продукта. А вот простой проект не такой затратный в сопровождении. Он позволяет больше времени уделить итерации MVP и добавлению новых функциональностей для улучшения продукта.
Важно помнить, что наилучшим часто оказывается простое решение, которое соответствует требованиям. Это наблюдение поможет определить, стоит ли новейшая модель глубокого обучения сопряженной с ней дополнительной работы! Если есть две равно работоспособные модели, одна из которых простая, а другая сложная, выбирайте простую.
Приведу пример из личного опыта. Как-то мы решали задачу планирования с помощью обучения с подкреплением. Было сложно, продвигались медленно. Бизнес-клиенты не скрывали своего раздражения и разочарования, поскольку мы не могли предоставить положительные результаты. Но после замены первоначального метода решения на старую добрую математическую оптимизацию, работа сразу пошла быстрее! Такой подход был менее интересным, но зато позволил завоевать доверие партнеров, легко реализовывать новые функциональности и вводить ограничения.
Создание MVP
Иногда возникают трудности с определением того, что именно должен охватывать MVP. Далее поделюсь 3 советами, чтобы помочь обозначить спектр действия MVP и сохранить его в неизменном виде.
Совет 1. Перед написанием кода ответьте на ряд вопросов
Необходимо ответить на следующие вопросы. Убедитесь, что ответы предоставлены бизнес-экспертами, и все участники проекта присутствуют на обсуждении.
- Зачем создавать продукт?
Данный вопрос выявляет значимость продукта. Задавая его, вы начинаете думать о метриках для расчета ценности продукта.
- Что должен делать продукт?
Вместо того чтобы концентрироваться на “как”, ответьте лучше на вопрос “что”. О том “как” вы поговорите позже, когда соберетесь узким кругом специалистов по данным. Пока же следует сосредоточиться на том, что бизнес-клиенты считают важным и какой они ожидают результат. Не забудьте поинтересоваться, как они представляют себе идеальное решение. Так вы сможете определить обязательные и желательные характеристики продукта. Для создания MVP особое внимание уделяется обязательным составляющим.
- Как данная проблема решается в настоящее время?
Об этом могут рассказать сами бизнес-эксперты! Полученная информация поможет определить важные функциональные возможности, которыми должен обладать продукт.
- К каким бизнес-экспертам можно обратиться за помощью?
Помимо инженеров ПО и специалистов по данным в создании продукта должен участвовать хотя бы один бизнес-эксперт. Желательно привлечь к сотрудничеству и конечного пользователя, который точно знает, что в итоге должен делать продукт. Рядом должен быть человек, к которому можно обратиться на любом этапе разработки, и он поможет с принятием правильных решений.
Это минимальный перечень вопросов, но их часто упускают из виду. Если вы сразу займетесь решением вопроса “как” и сосредоточитесь на технологиях МО, не выяснив пожеланий заинтересованных сторон, то провалите проект. Слушайте внимательно, не перебивая, и во время обсуждения обходитесь без заявлений о том, что какие-то желаемые функциональности продукта невозможны.
Совет 2. Создайте рабочий обновляющийся документ с описанием всех идей и функциональностей
Документ, содержащий все идеи и понятную схему с функциональностью, может стать отличным способом общения с разными заинтересованными сторонами. Вы обновляете его по мере развития проекта, отслеживаете текущие функциональности и добавляете новые. Не следует перенасыщать схему техническими или структурными деталями. Она должна содержать все бизнес-функциональности, описанные на простом английском или другом языке. Ниже представлен простой пример схемы для чат-бота:
Совет 3. Не меняйте спектр действия MVP до выпуска
Если вы работаете с творческими и изобретательными людьми, и вероятно, сами из их числа, то вам будет сложно придерживаться изначального плана. Вот вы показываете свой продукт и получаете обратную связь в виде предложения: “Было бы здорово добавить функциональность распознавания образов”. Вы с азартом подхватываете эту идею, но именно здесь начинаются проблемы.
Незаметно для себя вы начинаете создавать сложную систему и не укладываетесь в установленные сроки выпуска продукта. Лучше всего в такой ситуации поблагодарить за идею и записать ее. После выпуска MVP можно пересмотреть эти предложения и решить, стоит ли их реализовывать. На экспериментальном этапе целесообразно установить временные ограничения. Это поможет сфокусироваться на главной задаче и опробовать только определенное количество стратегий. После проведенных экспериментов работа продолжается с самым успешным решением.
Заключение
Создание сложной модели МО может казаться наилучшим способом для получения высокопроизводительного продукта. Однако разумнее сначала заняться выпуском MVP. Работоспособный MVP демонстрирует заинтересованным сторонам ценность продукта. Кроме того, итерацию легче проводить на простой модели. Помните: бизнес-клиентов больше заботит вопрос о том, как продукт способствует достижению их целей, тогда как технические детали отходят для них на второй план. Поэтому уделите внимание разработке функционирующего MVP, который соответствует требованиям, и не зацикливаетесь на создании идеальной модели МО.
Конечно, бывают исключения. Например, основной бизнес-целью является производительность. Или эксперты МО с соответствующим практическим опытом одобряют разработку нового решения. В этом случае вам повезло, и вы смело можете экспериментировать со всеми имеющимися новинками.
Читайте также:
- Топ-6 инструментов и фреймворков для искусственного интеллекта
- Плохие модели машинного обучения? Но их можно откалибровать
- Улётные пакеты Julia для машинного обучения - мечта программиста!
Читайте нас в Telegram, VK и Дзен
Перевод статьи Hennie de Harder: Simplify Your Machine Learning Projects
