СЕРИЯ ОБУЧЕНИЯ ПРЕДПРИНИМАТЕЛЬСКИМ МАШИНАМ
Enterprise ML - Почему доведение модели до производства занимает больше времени, чем ее создание
Краткое руководство по сложностям развертывания модели и интеграции с корпоративным приложением и конвейером данных. Что делают Data Scientist, Data Engineer, ML Engineer и ML Ops, простым языком.
Допустим, мы определили серьезную бизнес-проблему в нашей компании, построили модель машинного обучения (машинного обучения) для ее решения, обучили ее и довольны результатами прогнозов. Решить эту проблему было непросто, и потребовалось много исследований и экспериментов. Поэтому мы очень рады, что наконец-то сможем использовать эту модель для решения проблемы нашего пользователя!
Однако вскоре мы обнаружим, что построение самой модели - это только верхушка айсберга. Большая часть тяжелой работы по запуску этой модели в производство еще впереди. Я обнаружил, что этот второй этап может занять до 90% времени и усилий по проекту.
Итак, из чего состоит этот этап? И почему на это уходит столько времени? Этому посвящена данная статья.
В нескольких статьях моя цель - изучить различные аспекты пути организации к машинному обучению на всем пути от развертывания первой модели машинного обучения до настройки гибкого процесса разработки и развертывания для быстрого экспериментирования и реализации проектов машинного обучения. Если вам интересно, вот моя другая статья на эту тему:
- Построение и обучение модели из реального мира (Рабочий процесс проекта машинного обучения на предприятии и проблемы построения моделей)
Чтобы понять, что нужно сделать на втором этапе, давайте сначала посмотрим, что будет сделано в конце первого этапа.
Что дает этап построения модели и обучения?
Модели обычно создаются и обучаются командой Data Science. Когда он будет готов, у нас есть код модели в записных книжках Jupyter вместе с обученными весами.
- Его часто обучают с использованием статического снимка набора данных, возможно, в файле CSV или Excel.
- Снимок, вероятно, был подмножеством полного набора данных.
- Обучение проводится на локальном ноутбуке разработчика или, возможно, на виртуальной машине в облаке.
Другими словами, разработка модели осуществляется достаточно автономно и изолированно от приложений и конвейеров данных компании.
Что означает «Производство»?
Когда модель запускается в производство, она работает в двух режимах:
- Вывод в реальном времени - выполняйте онлайн-прогнозы для новых входных данных, по одной выборке за раз
- Переобучение - для переподготовки модели в автономном режиме каждую ночь или каждую неделю с текущим обновленным набором данных.
Требования и задачи, связанные с этими двумя режимами, совершенно разные. Это означает, что модель помещается в две производственные среды:
- Обслуживающая среда для выполнения логического вывода и обслуживания прогнозов
- Учебная среда для переподготовки
Вывод в реальном времени - это то, что имеет в виду большинство людей, когда они думают о «производстве». Но есть также много вариантов использования, которые выполняют пакетный вывод вместо реального времени.
- Пакетный вывод - выполняйте автономные прогнозы еженедельно или еженедельно для полного набора данных
Для каждого из этих режимов по отдельности модель теперь необходимо интегрировать с производственными системами компании - бизнес-приложением, конвейером данных и инфраструктурой развертывания. Давайте распакуем каждую из этих областей, чтобы увидеть, что они влекут за собой.
Мы начнем с сосредоточения внимания на логическом выводе в реальном времени, а затем рассмотрим пакетные случаи (переподготовка и пакетный вывод). Некоторые из возникающих сложностей уникальны для машинного обучения, но многие из них являются стандартными задачами разработки программного обеспечения.
Вывод - интеграция приложений
Модель обычно не является независимой сущностью. Это часть бизнес-приложения для конечных пользователей, например. рекомендательная модель для сайта электронной коммерции. Модель должна быть интегрирована с потоком взаимодействия и бизнес-логикой приложения.
Приложение может получать входные данные от конечного пользователя через пользовательский интерфейс и передавать их модели. В качестве альтернативы он может получать входные данные из конечной точки API или из системы потоковой передачи данных. Например, алгоритм обнаружения мошенничества, который утверждает транзакции по кредитным картам, может обрабатывать ввод транзакций из темы Kafka.
Точно так же выходные данные модели потребляются приложением. Он может быть представлен обратно пользователю в пользовательском интерфейсе, или приложение может использовать прогнозы модели для принятия некоторых решений в рамках своей бизнес-логики.
Необходимо наладить межпроцессное взаимодействие между моделью и приложением. Например, мы могли бы развернуть модель как отдельный сервис, доступ к которому осуществляется через вызов API. В качестве альтернативы, если приложение также написано на том же языке программирования (например, Python), оно может просто выполнить локальный вызов функции для кода модели.
Эта работа обычно выполняется разработчиком приложений в тесном сотрудничестве с специалистом по данным. Как и при любой интеграции между модулями в проекте разработки программного обеспечения, это требует сотрудничества, чтобы гарантировать, что предположения о форматах и семантике данных, передаваемых туда и обратно, согласованы с обеих сторон. Все мы знаем, какие проблемы могут возникнуть. например. Если модель ожидает, что числовое поле «количество» будет неотрицательным, выполнит ли приложение проверку перед передачей его в модель? Или ожидается, что модель выполнит эту проверку? В каком формате приложение передает даты и ожидает ли модель того же формата?
Вывод - интеграция данных
Модель больше не может полагаться на статический набор данных, содержащий все функции, необходимые для прогнозирования. Ему необходимо получать «живые» данные из хранилищ данных организации.
Эти функции могут находиться в источниках транзакционных данных (например, в базе данных SQL или NoSQL) или в полуструктурированных или неструктурированных наборах данных, таких как файлы журналов или текстовые документы. Возможно, некоторые функции вызываются путем вызова API, либо внутренней микрослужбы или приложения (например, SAP), либо внешней сторонней конечной точки.
Если какие-либо из этих данных находятся в неправильном месте или в неправильном формате, может потребоваться создание некоторых заданий ETL (извлечение, преобразование, загрузка) для предварительной выборки данных в хранилище, которое приложение будет использовать.
Решение всех проблем интеграции данных может оказаться серьезным делом. Например:
- Требования к доступу - как вы подключаетесь к каждому источнику данных и каковы его политики безопасности и контроля доступа?
- Обработка ошибок. Что делать, если истечет время ожидания запроса или система не работает?
- Задержки сопоставления - сколько времени занимает запрос к источнику данных по сравнению с тем, как быстро нам нужно ответить пользователю?
- Конфиденциальные данные - есть ли личная информация, которую нужно замаскировать или обезличить.
- Расшифровка: нужно ли расшифровать данные, прежде чем модель сможет их использовать?
- Интернационализация - может ли модель обрабатывать необходимые кодировки символов и форматы чисел / даты?
- и многое другое…
Этот инструмент создается инженером по данным. На этом этапе они также будут взаимодействовать с Data Scientist, чтобы гарантировать, что предположения согласованы, а интеграция проходит гладко. например. Достаточно ли очистки данных и предварительной обработки, выполненных моделью, или нужно проводить какие-то еще преобразования?
Вывод - Развертывание
Пришло время развернуть модель в производственной среде. Возникают все факторы, которые необходимо учитывать при развертывании любого программного обеспечения:
- Хостинг моделей - в мобильном приложении? В локальном центре обработки данных или в облаке? На встроенном устройстве?
- Упаковка моделей - какое зависимое программное обеспечение и библиотеки машинного обучения ему нужны? Обычно они отличаются от ваших обычных библиотек приложений.
- Совместное размещение - будет ли модель совмещена с приложением? Или как внешний сервис?
- Параметры конфигурации модели - как они будут поддерживаться и обновляться?
- Требуемые системные ресурсы - ЦП, ОЗУ, диск и, самое главное, графический процессор, поскольку для этого может потребоваться специализированное оборудование.
- Нефункциональные требования - объем и пропускная способность трафика запросов? Какое ожидаемое время отклика и задержка?
- Автоматическое масштабирование - какая инфраструктура требуется для его поддержки?
- Контейнеризация - нужно ли его упаковывать в контейнер Docker? Как будет выполняться оркестровка контейнеров и планирование ресурсов?
- Требования безопасности - учетные данные, которые нужно сохранить, закрытые ключи, которыми нужно управлять для доступа к данным?
- Облачные сервисы - при развертывании в облаке требуется интеграция с любыми облачными сервисами, например. (Amazon Web Services) AWS S3? Что насчет привилегий управления доступом AWS?
- Инструменты автоматического развертывания - для подготовки, развертывания и настройки инфраструктуры и установки программного обеспечения.
- CI / CD - автоматизированные модульные или интеграционные тесты для интеграции с конвейером CI / CD организации.
Инженер по машинному обучению отвечает за реализацию этого этапа и развертывание приложения в производственной среде. Наконец, вы можете представить приложение клиенту, что является важной вехой!
Однако еще не время сидеть сложа руки и расслабляться 😃. Теперь начинается задача ML Ops по мониторингу приложения, чтобы убедиться, что оно продолжает оптимально работать в производственной среде.
Заключение - Мониторинг
Цель мониторинга - убедиться, что ваша модель продолжает делать правильные прогнозы в производственной среде на основе данных о клиентах в реальном времени, как это было во время разработки. Вполне возможно, что ваши показатели будут не такими хорошими.
Кроме того, вам необходимо отслеживать все стандартные показатели приложения DevOps, как и для любого приложения - задержку, время отклика, пропускную способность, а также системные показатели, такие как использование ЦП, ОЗУ и т. Д. Вы должны запустить обычные проверки работоспособности, чтобы гарантировать время безотказной работы. и стабильность приложения.
Не менее важно, чтобы мониторинг был постоянным процессом, потому что есть все шансы, что показатели оценки вашей модели со временем ухудшатся. Сравните свои оценочные показатели с прошлыми показателями, чтобы убедиться, что нет отклонений от исторических тенденций.
Это может произойти из-за дрейфа данных.
Вывод - проверка данных
Со временем ваши данные будут развиваться и меняться - могут добавляться новые источники данных, собираться новые значения функций, новые клиенты будут вводить данные с другими значениями, чем раньше. Это означает, что распределение ваших данных может измениться.
Поэтому проверка вашей модели с использованием текущих данных должна быть постоянной деятельностью. Недостаточно смотреть только на оценочные показатели для глобального набора данных. Вы также должны оценивать метрики для разных срезов и сегментов ваших данных. Весьма вероятно, что по мере развития вашего бизнеса и изменения демографии, предпочтений и поведения клиентов будут меняться и ваши сегменты данных.
Предположения в отношении данных, сделанные при первом построении модели, могут больше не соответствовать действительности. Чтобы учесть это, ваша модель также должна развиваться. Очистка данных и предварительная обработка, которые выполняет модель, также могут нуждаться в обновлении.
И это подводит нас ко второму производственному режиму - режиму пакетной переподготовки на регулярной основе, чтобы модель продолжала учиться на свежих данных. Давайте рассмотрим задачи, необходимые для настройки пакетной переподготовки в производственной среде, начиная с модели разработки.
Переподготовка - Интеграция данных
Когда мы обсуждали интеграцию данных для вывода, она предполагала получение одной выборки последних «живых» данных. С другой стороны, во время переподготовки нам нужно получить полный набор исторических данных. Кроме того, эта переподготовка происходит в пакетном режиме, например, каждую ночь или каждую неделю.
Исторические не обязательно означают «старые и устаревшие» данные - они могут включать, например, все данные, собранные до вчерашнего дня.
Этот набор данных обычно находится в хранилищах аналитики организации, таких как хранилище данных или озеро данных. Если некоторых данных там нет, вам может потребоваться создать дополнительные задания ETL для передачи этих данных в хранилище в требуемом формате.
Переподготовка - интеграция приложений
Поскольку мы переобучаем только модель, все приложение не задействовано. Таким образом, никакой работы по интеграции приложений не требуется.
Переподготовка - развертывание
Переподготовка, вероятно, произойдет с огромным объемом данных, вероятно, намного большим, чем тот, который использовался во время разработки.
Вам нужно будет выяснить, какая аппаратная инфраструктура необходима для обучения модели - каковы ее требования к графическому процессору и оперативной памяти? Поскольку обучение должно выполняться в разумные сроки, его необходимо распределить по множеству узлов в кластере, чтобы обучение происходило параллельно. Каждый узел должен быть подготовлен и управляться планировщиком ресурсов, чтобы аппаратные ресурсы могли быть эффективно распределены для каждого процесса обучения.
Настройка также должна гарантировать, что эти большие объемы данных могут быть эффективно переданы на все узлы, на которых выполняется обучение.
И прежде чем мы подведем итоги, давайте рассмотрим наш третий вариант использования в производственной среде - сценарий Batch Inference.
Пакетный вывод
Часто логический вывод не обязательно запускать «в реальном времени» для одного элемента данных за раз. Есть много вариантов использования, для которых его можно запустить как пакетное задание, когда выходные результаты для большого набора выборок данных предварительно вычисляются и кэшируются.
Затем предварительно вычисленные результаты можно использовать по-разному в зависимости от варианта использования. например.
- Они могут храниться в хранилище данных для отчетности или для интерактивного анализа бизнес-аналитиками.
- Они могут быть кэшированы и отображены приложением пользователю при следующем входе в систему.
- Или они могут быть кэшированы и использоваться в качестве входных функций другим нижележащим приложением.
Например, модель, которая прогнозирует вероятность оттока клиентов (т. Е. Они перестают покупать у вас), может запускаться каждую неделю или каждую ночь. Затем результаты можно использовать для проведения специальной акции для всех клиентов, относящихся к группе высокого риска. Или им может быть сделано предложение при следующем посещении сайта.
Модель пакетного вывода может быть развернута как часть рабочего процесса с сетью приложений. Каждое приложение выполняется после завершения его зависимостей.
Здесь также применимы многие из тех же проблем интеграции приложений и данных, которые возникают при выводе в реальном времени. С другой стороны, пакетный вывод не требует таких же требований к времени отклика и задержке. Но он предъявляет высокие требования к пропускной способности, поскольку работает с огромными объемами данных.
Заключение
Как мы только что убедились, запуск модели в производство стоит перед множеством проблем и требует значительного объема работы. Даже после того, как специалисты по обработке данных подготовят обученную модель, в организации есть множество ролей, которые объединяются, чтобы в конечном итоге донести ее до ваших клиентов и поддерживать ее работу месяц за месяцем. Только тогда организация действительно получит преимущества от машинного обучения.
Теперь мы увидели сложность создания и обучения реальной модели, а затем внедрения ее в производство. В следующей статье мы рассмотрим, как ведущие технологические компании решили эти проблемы, чтобы быстро и плавно выпускать приложения машинного обучения.
И, наконец, если вам понравилась эта статья, возможно, вам понравится и другая моя серия статей о преобразователях, глубоком обучении аудио и машинном обучении с геолокацией.
