Развертывание моделей машинного обучения в производственной среде: экспорт моделей и системная архитектура

"Машинное обучение"

Развертывание моделей машинного обучения в производственной среде: экспорт моделей и системная архитектура

Понимание механизмов экспорта моделей, упрощенной интеграции, методов офлайн и онлайн-размещения моделей

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

Экспорт модели

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

Сколько в нем информации? 3 пары значений коэффициента и имени объекта и одна константа. Однозначно эти семь значений можно записать в файл.

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

Экспорт независимой от платформы модели

Модели машинного обучения обучаются с использованием различных технологических стеков, таких как Python, Java, .NET и т. Д. В Python существуют разные фреймворки, такие как sci-kit-learn, PyTorch, TensorFlow и многие другие. Существует очевидная потребность в независимом от платформы механизме экспорта модели. В большинстве случаев типичное использование моделей будет кроссплатформенным. Модель может быть разработана на платформе Python, но по причинам высокой доступности она может обслуживаться на платформе Java. Мы обсудим это подробно в следующих разделах. Перед этим давайте обсудим два разных формата экспорта моделей.

PMML: PMML означает язык разметки прогнозных моделей. Это стандарт, основанный на XML, и у него есть предопределенная схема. Модель экспортируется как файл XML.

Приведенное выше содержание PMML предназначено для модели линейной регрессии. Мы видим, что он содержит тип модели (в приведенном выше случае регрессия), шаги предварительной обработки (в приведенном выше случае StandardScaler), названия функций и много другой информации. .

PMML страдает от проблем с размером. Слишком много функций создают довольно большие XML-файлы, особенно для моделей NLP.

Поэтому иногда бывает удобно преобразовать содержимое PMML в JSON.

ONNX: это сокращение от Open Neural Network Exchange. Он идеально подходит для моделей глубокого обучения. Он создает сетевой граф, который сериализуется в двоичный файл. Как обычно, график содержит информацию о весах скрытых и выходных слоев и соединениях. В отличие от PMML, он не создает XML.

Оба этих формата переносимы (особенно PMML) на разные платформы.

Потребление и портативность модели

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

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

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

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

Следующая диаграмма объясняет ситуацию.

Модель, разработанная в различных фреймворках Python (scikit-learn, PyTorch, TensorFlow) или в стеке больших данных, например Apache Spark / Flink, может быть экспортирована в любом заданном формате (PMML / ONNX), и то же самое может использоваться различными клиентскими приложениями (Java, Python или .NET). Итак, это ситуация «многие ко многим».

Клиентские приложения анализируют файл модели и извлекают необходимые параметры для построения версии модели в памяти.

Вместо того, чтобы полагаться на PMML / ONNX или любой стандартный формат, пользовательский настраиваемый формат также может быть определен для некоторых очень специфических требований (как показано на диаграмме). В любом случае цель - «сделать модель переносимой на разные платформы».

Развертывание модели и системная архитектура

В большинстве случаев деятельность в области науки о данных выполняется на Python с использованием стандартных библиотек, описанных выше. Но это не очень масштабируемый вариант. Нам нужна надежная платформа разработки и развертывания данных для систем производственного уровня. Здесь большую роль играют большие данные. Модели можно обучать с петабайтами данных на платформах больших данных, таких как Spark, Hadoop, Flink и т. Д. Фактически, они всегда предпочтительны в производственных системах.

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

Apache Spark / Flink не подходят для синхронной интеграции, и они работают в автономном / пакетном / асинхронном режиме.

Таким образом, прямой доступ к API прогнозирования уровня Spark / Hadoop через REST может быть очень опасным для клиентских систем с ожидаемой высокой / умеренной пропускной способностью. Даже при низких требованиях к пропускной способности синхронная интеграция вообще не рекомендуется. Здесь проблему решает механизм экспорта модели с использованием PMML / ONNX или другого формата.

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

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

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

Теперь мы обсудим три разные системные архитектуры развертывания модели, используя концепцию, описанную выше.

Развертывание в облаке по требованию (модель как услуга)

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

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

Автономное облачное развертывание

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

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

Пакетное развертывание

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

Он также идеально подходит для работы в автономном серверном корпусе или в приложениях, основанных на робототехнике.

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

Примечание. Недавно я написал книгу по ML (https://twitter.com/bpbonline/status/1256146448346988546)