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

В Опросе SAS 2017 года 83% организаций инвестировали в большие данные от умеренных до значительных, но только 33% говорят, что они извлекли выгоду из своих инвестиций. Аналогичные результаты показали и другие, более недавние опросы. Мы обнаружили, что основной причиной этого пробела является непонимание всего объема того, что требуется для практической реализации прогнозов таким образом, чтобы это действительно принесло пользу вашему бизнесу. В этом посте я хотел бы провести вас через пример сценария и показать, как для успеха требуется процесс, который обеспечивает согласованность с затронутыми людьми, сохраняет фокус на извлекаемой ценности для бизнеса и итеративно создает технологическую платформу.

Процесс операционализации модели начинается до того, как ваша команда по науке о данных загрузит первый фрейм данных. Высокоэффективная команда специалистов по данным будет генерировать идеи вместе с бизнесом с видением ценности для бизнеса, которая будет получена. Например, недостаточно просто сказать: Мы хотим прогнозировать отток клиентов. Лучшей бизнес-гипотезой может быть: Мы хотим сэкономить 720 тысяч долларов в год, предотвратив 10% клиентов, которые, скорее всего, уйдут, отправив им целевые рекламные акции. При определении приоритетов незавершенной работы команда специалистов по обработке и анализу данных должна сосредоточиться на тех идеях, которые имеют самый высокий потенциал рентабельности инвестиций. Эта задача, как указал мой коллега Шон МакКолл, должна возлагаться на Владельца продукта науки о данных. Вы можете найти пример расчета оттока клиентов ниже:

($300 cost of acquisition (measured)
— $100 cost of promotion(assumed))
* 30% success of retaining with promotion (assumed)
* 10000 customer churn per month (measured)
= $60K / month
= $720K / year

Как только команда специалистов по данным начинает разрабатывать модели для поддержки бизнес-идеи, они должны начать с самой простой модели и регулярно делиться результатами с наиболее затронутыми командами, сотрудничать с ними в улучшении модели и вместе решать, когда модель хороша. достаточно. Здесь на помощь приходит наша предыдущая грубая оценка. Разговор с вашими заинтересованными сторонами о RMSE, собственных векторах и кривых ROC, скорее всего, заставит их ошеломиться. Переводя точность того, что вы пытаетесь предсказать, в заявление о ценности для бизнеса, вы будете говорить на одном языке. «Мы можем прогнозировать отток клиентов с точностью 75 %» звучит намного лучше, если дополнить его «что сэкономит нам около 45 000 долларов США в месяц, исходя из текущих предположений», особенно если вы фактически начнете применять модель на следующем этапе. .

Когда команда, стоящая за моделью, принимает решение запустить ее в производство, они также должны понимать затраты на создание и запуск рабочей версии (включая платформу данных для подачи входных данных, конечную точку прогнозирования модели и мониторинг модели). услуга). Это, наряду с приведенными выше расходами на специалистов по данным, обеспечивает стоимостную сторону уравнения ROI. Детали для разработки этой оценки выходят за рамки этой статьи, поэтому давайте просто предположим, что стоимость составляет 180 тысяч долларов. При такой стоимости решение должно окупиться за 4 месяца и обеспечить рентабельность инвестиций в размере 540 000 долларов США за год. Это отличная отдача, поэтому мы начинаем процесс автоматизации подачи данных, развертывания модели веб-службы, создания прогнозов и интеграции результатов прогнозов в новые и существующие приложения, чтобы упростить их использование. Поскольку мы все время работали с конечными пользователями прогнозов, мы знаем, какие детали они хотят видеть, чтобы повысить доверие к прогнозам.

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

Итак, теперь, когда мы создали отличную систему размещения моделей и измеряем 75% ожидаемого удержания (люди всегда переоценивают такие предположения, но это нормально, поскольку мы все еще на пути к экономии 405 000 долларов США), команда, вероятно, перешла к созданию других ценных моделей. Одним из ключевых шагов, который часто упускают из виду, является встраивание общих операций, которые происходят в нескольких моделях, в платформу или структуру. Чтобы операционализировать модели в любом масштабе, базовая платформа данных должна быть достаточно гибкой, чтобы можно было проводить быстрые эксперименты, но также и достаточно масштабируемой, чтобы очень быстро обрабатывать преобразования и облегчать прогнозирование большого объема данных. Чтобы оправдать затраты на эти инвестиции, их можно амортизировать по ROI нескольких моделей.

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

Затем, в один прекрасный день через 6 месяцев, срабатывает сигнализация о том, что модель оттока больше не работает. Точность снизилась до 50%, так что это просто предположение. Команда по науке о данных должна изо всех сил пытаться выяснить, что не так, и исправить это. Что изменилось во входных данных? Когда мы в последний раз развертывали эту модель? Патч на базовой машине что-то сломал? Было бы очень хорошо вернуться к точному состоянию, когда мы обучали модель, чтобы мы могли определить, что изменилось. В конце концов, кто-то находит и исправляет проблему (метрика использования была установлена ​​на 0 для всех клиентов из-за ошибочного развертывания). Подобные инциденты заставляют команду сосредоточиться на создании упреждающих инструментов отладки, таких как обнаружение аномалий в ключевых функциях и прогнозирование результатов, чтобы быстрее обнаруживать и изолировать проблемы.

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

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

Первоначально опубликовано на http://parivedaperspectives.com 13 августа 2018 г.