5 уроков, которые необходимо знать специалистам по данным о переносе моделей в производство

5 уроков, которые необходимо знать специалистам по данным о переносе моделей в производство

Первоначально опубликовано на https://retina.ai/blog/moving-models-to-production/ Мо Мессиди, старшим инженером по операциям с данными в Retina.

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

Проблема 1: несовпадающие показатели

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

Это Боб. Боб работает специалистом по обработке данных в компании по организации видеоконференцсвязи под названием «Soom».

«Soom» предлагает своим клиентам набор продуктов для видеоконференцсвязи для различных онлайн-мероприятий, включая онлайн-встречи, конференции, вебинары и встречи. У них есть два основных предложения продукта: бесплатный веб-продукт для видеоконференцсвязи с 45-минутным ограничением на собрания и веб-продукт для видеоконференцсвязи за 20 долларов в месяц без ограничения по времени для встреч.

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

«Итак, - подумал Боб, - это будет совсем несложно». Бизнес-задача очень хорошо трансформируется в проблему контролируемого обучения с двумя классами меток.

• Пользователи, которые подписались на бесплатный продукт и приобрели платный продукт в течение 90 дней.
• Пользователи, которые подписались на бесплатный продукт и не приобрели платный продукт в течение 90 дней.

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

К концу двух недель у него была простая рабочая модель с оценкой точности 0,86, оценкой отзыва 0,77 и оценкой площади под кривой 0,88 при валидации. Не идеально, но все же многообещающе.

Во время его двухнедельной регистрации менеджер Боба спрашивает: «Как дела, Боб? У нас есть модель, готовая к производству? » Боб отвечает: «Мне удалось разработать простую модель, точность которой в моих тестах составила 0,88. Это отличные предварительные результаты. Я уверен, что смогу повысить свою точность, если попробую несколько более продвинутых методов моделирования ».

Проходит еще две недели, в течение которых Боб опробует пару конфигураций ансамблевой модели и даже реализует современную модель глубокой нейронной сети, о которой он читал в недавней исследовательской статье. К концу двух недель он повысил свои оценки эффективности валидации до 0,90 точности, 0,98 отзыва и 0,99 площади под кривой.

Во время следующей двухнедельной проверки менеджер Боба спрашивает: «Как дела, Боб? У нас есть модель, готовая к производству? » и Боб говорит: «Мне удалось повысить точность модели на 10%, и я считаю, что при правильной настройке гиперпараметров я смогу выжать еще несколько процентных пунктов».

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

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

Урок 1. Не гонитесь за совершенством: достаточно хорошо, достаточно быстро

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

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

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

Проблема 2: Скрытые зависимости

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

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

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

Оказывается, продуктовая команда добавила в свой продуктовый сервис новый тип мероприятия: фестивальное мероприятие.

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

Урок 2. Убедитесь, что создание функций устойчиво к изменениям в базовых данных.

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

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

Проблема 3: производительность в производстве не соответствует производительности в разработке

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

Когда у вас есть модель в производстве, вы можете повторно оценить производительность модели сразу после развертывания, используя более свежие данные. Итак, Боб проверяет, работает ли эта модель в производственной среде, путем тестирования со свежим производственным набором данных. Он отмечает, что точность модели резко упала с 0,85 до 0,55 всего за несколько дней. Так что случилось?

Урок 3: Остерегайтесь проблем с местностью, сезонностью и выборкой.

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

• Проблемы с локализацией: Обобщенные модели обычно плохо локализуются для определенных распределений подмножеств. Это касается как географической, так и временной местности. Обучение модели на международной клиентской базе не обязательно дает хорошие результаты для прогнозирования клиентской базы в США. Местность не ограничивается только географическим положением. Временная локализация также может быть проблемой. Если модель обучается с использованием прошлых данных за пять лет, но два года назад в бизнесе произошел серьезный поворот, то из более старых данных мало что можно извлечь. Фактически, это могло быть больше шума, чем сигнала.
• Проблемы сезонности: в зависимости от количества доступных исторических данных, может быть сложно учесть эффекты сезонности на длительном горизонте. Например, в типичных наборах данных по розничной торговле необходимы данные за несколько лет, чтобы зафиксировать сезонность курортного сезона.
• Распределение выборки по сравнению с распределением совокупности: если данные выборки не точно представляют данные совокупности, возникает несоответствие между формой распределения выборок в производстве и выборок в разработке, что может повлиять на производительность модели. Чтобы смягчить эту проблему, убедитесь, что образцы, используемые для обучения моделей, действительно случайны. Избегайте горизонтального разделения наборов данных на обучающие и тестовые наборы; вместо этого используйте методы случайной выборки.

Проблема 4: дрейф модели

Бобу удалось внедрить более репрезентативную модель в производственную среду, показатели точности которой соответствуют метрикам разработки. Его менеджер чрезвычайно воодушевлен, и после успешного A / B-тестирования бизнес начинает использовать прогнозы модели для увеличения маркетинговых затрат на пользователей бесплатных продуктов, которые, по прогнозам, не превратятся в платных пользователей. Маркетинговая инициатива работает очень хорошо в течение первых нескольких недель, но начинает быстро ухудшаться. Что случилось?

Урок 4: Если вы развернете один раз, вы будете развертывать несколько раз.

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

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

Проблема 5: онлайн-обучение и мониторинг

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

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

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

Однако в некоторых случаях, например, в случае с командой Боба, истинный график качества модели во времени выглядел примерно так:

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

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

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

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

В Retina мы создаем модели для наших клиентов, чтобы прогнозировать их жизненную ценность на ранних этапах пути к покупке. Если вы хотите узнать больше о CLV и переносе моделей из НИОКР в производство, давайте поговорим.

Первоначально опубликовано на https://retina.ai 26 мая 2020 г.