Введение

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

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

1. Единообразие упаковки и выпуска

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

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

Первым шагом к единообразной упаковке и выпуску для ввода в действие является создание инструмента управления версиями, такого как Git, для управления всеми версиями кода в вашем продукте. Следующим шагом является упаковка кода и данных. Вы можете создавать сценарии упаковки, которые генерируют моментальные снимки в форме ZIP-файла как для кода, так и для данных внутри сценария; они должны соответствовать модели (или параметрам модели), которую вам необходимо отправить. Затем вы можете развернуть этот ZIP-файл в рабочей среде. Наконец, будьте бдительны в ситуациях, когда размер файла данных слишком велик (например, ›1 ГБ). В этих сценариях вам необходимо создать моментальный снимок и версию необходимых файлов данных в хранилище.

2 - Постоянная переподготовка моделей

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

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

Решение проблемы переобучения лежит в рабочем процессе производства науки о данных. Это означает, что вам необходимо реализовать специальную команду для рабочего процесса, которая выполняет следующие действия: (1) Повторно обучает нового кандидата в прогнозную модель; (2) Повторно оценивает и повторно проверяет модель (на этом этапе создаются необходимые показатели для вашей модели); и (3) меняет старую модель прогнозирования на новую.

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

3 - От A / B-тестирования к многовариантной оптимизации

Целью A / B-тестирования различных моделей является возможность оценивать несколько моделей параллельно, а затем сравнивать ожидаемую производительность модели с фактическими результатами. Офлайн-тестирования недостаточно для проверки производительности информационного продукта. В случаях использования, таких как кредитный рейтинг и обнаружение мошенничества, только реальные тесты могут предоставить фактические требуемые данные. Автономные тесты просто не могут передавать события в реальном времени, такие как авторизация кредита. Кроме того, реальная производственная установка может отличаться от вашей реальной. Как упоминалось выше, согласованность данных является серьезной проблемой, которая приводит к несогласованному производству. Наконец, если базовые данные и их поведение быстро развиваются, тогда будет сложно проверить модели достаточно быстро, чтобы справиться со скоростью изменения.

Существует 3 уровня A / B-тестирования, которые можно использовать для проверки достоверности моделей: (1) Простое A / B-тестирование, (2) Тестирование многоруких бандитов и (3) Тестирование нескольких вооруженных бандитов с оптимизацией. . Первое, простое A / B-тестирование, требуется для большинства компаний, занимающихся цифровой деятельностью, в то время как последнее используется в основном в сложных, конкурентных сценариях использования в режиме реального времени (например, торги в реальном времени / реклама и алгоритмическая торговля).

4 - Функциональный мониторинг

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

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

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

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

5 - Согласованность ИТ-среды

Плавность процесса моделирования во многом зависит от наличия согласованной ИТ-среды во время разработки и производства. Современная наука о данных обычно использует такие технологии, как Python, R, Spark, Scala, а также фреймворки / библиотеки с открытым исходным кодом, такие как H2O, scikit-learn и MLlib.

В прошлом специалисты по обработке данных использовали технологии, которые уже были доступны в производственной среде, такие как базы данных SQL, JAVA и .NET. В сегодняшней среде прогнозных технологий непрактично переводить проект по науке о данных на более старые технологии, такие как SQL, JAVA и .NET - это требует значительных затрат на повторную запись. Следовательно, 80% компаний, занимающихся прогнозным моделированием, используют более новые технологии, такие как Python и R.

Внедрение Python или R в производство создает собственный набор уникальных проблем с точки зрения управления средой и пакетами. Это происходит из-за того, что обычно задействовано большое количество пакетов; проекты по науке о данных полагаются в среднем на 100 пакетов R, 40 пакетов Python и несколько сотен пакетов Java / Scala (большинство из которых находится за зависимостями Hadoop). Еще одна проблема - поддержание контроля версий в среде разработки; например, scikit-learn обновляется примерно два раза в год.

К счастью, существует несколько вариантов создания согласованной ИТ-среды. Вы можете использовать встроенные механизмы в дистрибутивах с открытым исходным кодом (например, virtualenv, pip для Python) или полагаться на стороннее программное обеспечение (например, Anaconda TM для Python). AnacondaTM становится все более популярным среди пользователей Python, и треть наших респондентов указали на его использование. Что касается Spark, Scala и R, подавляющее большинство сообщества специалистов по науке о данных полагается исключительно на варианты с открытым исходным кодом. Вы также можете использовать сборку из исходной системы (например, pip для Python) или бинарный механизм (например, wheel). В научном сообществе бинарные системы пользуются все большей популярностью. Отчасти это связано со сложностью создания оптимизированной библиотеки, которая использует все возможности пакетов для научных вычислений, таких как NumPy. Наконец, вы можете положиться на стабильную версию и общий список пакетов (во всех ваших системах) или создать виртуальную среду для каждого проекта. В первом случае ИТ-отделы предпочли бы вести общий список «доверенных» пакетов, а затем направлять эти пакеты в разработку программного обеспечения. В последнем случае у каждого проекта данных будет своя собственная выделенная среда. Помните, что первая значительная миграция или поставка нового продукта может потребовать от вас поддержки нескольких сред для поддержки перехода.

6 - Стратегия отката

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

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

7 - Надежный поток данных

Подготовка к худшему - часть разумной стратегии; в мире прогнозной аналитики это означает наличие надежной стратегии аварийного переключения. В конце концов, надежные приложения для обработки данных должны полагаться на процедуры восстановления после сбоя и проверки, чтобы поддерживать стабильность. Задача стратегии аварийного переключения состоит в том, чтобы интегрировать все события в производственной системе, контролировать систему, если кластер работает плохо, и немедленно предупреждать ИТ, если задание не работает. Возникает вопрос: как написать сценарий для процесса, который будет перезапускаться или восстанавливаться в случае сбоя?

В традиционных системах бизнес-аналитики ETL (извлечение - преобразование - загрузка) предоставляет некоторые механизмы аварийного переключения, но стратегии аварийного переключения и проверки зависят от внутренних знаний приложения. Кроме того, технологии ETL плохо сочетаются с Python, R, прогнозными моделями и Hadoop. Возможны некоторые уровни доступа, но маловероятно, что существует уровень детализации, необходимый для надежного написания сценариев. Например, при работе в Hadoop обычно используются базовые средства MD5 и хеширования для проверки целостности файлов и хранения / управления рабочим процессом. Эту возможность обычно нелегко реализовать с помощью ETL. Без надлежащей стратегии аварийного переключения ваш рабочий процесс данных и аналитики не удастся. Результатом будет потеря доверия к использованию подхода науки о данных в вашей ИТ-среде. Важно посвятить время и внимание созданию стратегии аварийного переключения, так как ее, как известно, сложно усовершенствовать с первого раза.

Формулировка стратегии аварийного переключения в рабочем процессе с большими данными представляет некоторые уникальные проблемы, в основном из-за огромного объема задействованных данных. Невозможно использовать подход «восстановления», так как информации слишком много, чтобы сделать это эффективно. Учитывая это, рабочий процесс с большими данными должен «учитывать состояние», что означает, что он должен принимать решения на основе ранее рассчитанного состояния. Как и ожидалось, методы ETL обычно не способны кодировать такую ​​логику.

  • Будьте параллельны. Некоторая обработка может быть распараллелена на уровне рабочего процесса, в отличие от кластера, уменьшения карты и уровня Spark. По мере развития продукта вполне вероятно, что количество ветвей будет расти - использование параллельной методологии помогает поддерживать скорость вашей системы.
  • Интеллектуальное повторное выполнение: это просто означает, что данные автоматически повторно обновляются после временного прерывания ввода данных, такого как позднее обновление или временно отсутствующие данные. Например, ваш рабочий процесс с большими данными может получать ежедневные данные о ценах через FTP; ваш рабочий процесс объединяет эти данные с данными существующего браузера и заказа, чтобы сформулировать стратегию ценообразования. Если эти сторонние данные не обновляются, стратегию ценообразования можно по-прежнему создавать с использованием существующих актуальных данных… но в идеале данные должны быть повторно обновлены, когда недостающие данные станут доступны.
  • Пользовательский интерфейс. Графическое представление рабочего процесса позволяет пользователям более полно понимать и исследовать общий ход рабочего процесса. В какой-то момент текстовый интерфейс или необработанные журналы достигают своего предела с точки зрения возможности описать общую картину. Когда это происходит, лучший вариант - простой в использовании веб-интерфейс.

8 - Аудит

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

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

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

9 - Производительность и масштабируемость

Производительность и масштабируемость идут рука об руку: по мере тестирования пределов масштабируемости (больше данных / клиентов / процессов) производительность должна соответствовать этим ограничениям или превышать их. Стратегически проблемы заключаются в том, чтобы создать эластичную архитектуру; среда, которая может обрабатывать значительные переходы (например, от 10 вызовов в час до 100 тыс. в час) без сбоев. По мере того, как вы внедряете рабочий процесс обработки данных в производственную среду, вам необходимо подумать о соответствующем увеличении производственных возможностей.

  • Масштабируемость тома. Что произойдет, если объем данных, которыми вы управляете, вырастет с нескольких гигабайт до десятков терабайт?
  • Масштабируемость запросов: что произойдет, если количество запросов клиентов умножить на 100?
  • Масштабируемость сложности. Что произойдет, если вы увеличите количество рабочих процессов или процессов с 1 до 20?
  • Масштабируемость команды. Может ли ваша команда справиться с изменениями, связанными с масштабируемостью? Могут ли они сотрудничать, сотрудничать и работать одновременно?

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

  1. Переполнение данных за ночь. Несколько зависимых пакетных заданий, которые длятся 1-2 часа, в конечном итоге нарушают ожидаемый временной интервал, эффективно выполняясь всю ночь и на следующий день. Без надлежащего управления заданиями и тщательного мониторинга ваши ресурсы могут быть быстро использованы неконтролируемыми процессами.
  2. Узкие места. Узкие места в данных могут стать серьезной проблемой в любой архитектуре, независимо от того, сколько вычислительных ресурсов используется. Регулярное тестирование может помочь решить эту проблему.
  3. Журналы и бункеры: объем данных может быстро расти, но в авангарде роста данных находятся журналы и бункеры. Это особенно верно, когда кластер или база данных Hadoop переполнены - при поиске виновника всегда сначала проверяйте журналы и корзины, поскольку они обычно полны мусора.

10 - Устойчивое управление жизненным циклом модели

Мы можем упростить путь от аналитики прототипов до надежной производственной аналитики, выполнив следующие шаги: (1) развертывание моделей и целых рабочих процессов в производственной среде быстрым и эффективным способом; (2) Мониторинг и управление этими моделями с точки зрения дрейфа и их переобучение либо регулярно, либо в соответствии с заранее определенным триггером; и (3) обеспечение того, чтобы модели в производстве продолжали служить своей цели, насколько это возможно, с учетом изменений в данных и бизнес-потребностей. С этим последним моментом большинство организаций не сталкивались или даже не сталкивались, но об этом важно помнить сейчас, потому что поддержание жизненного цикла моделей в производстве - это цена успешного развертывания и управления ими.

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

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

Чтобы управлять жизненным циклом моделей устойчивым образом, а также продлевать жизненный цикл этих моделей, вам необходимо уметь:

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

Заключение

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

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

— —

Если вы хотите следить за моей работой над Data Science и MLOps, вы можете проверить мои Medium и GitHub, а также другие проекты на https: // jameskle. com / . Вы также можете написать мне в Твиттере, написать мне напрямую или найти меня в LinkedIn. Или «присоединяйтесь к моей рассылке, чтобы получать мои последние мысли прямо на ваш почтовый ящик!