x
© 1995-2019 Компания «Инфосистемы Джет» Разработано в Liqium
Машинное обучение Итак, у вас есть datascientist’ы и модели – что дальше
Автор
Алексей Каткевич архитектор Департамента разработки Дирекции по разработке и внедрению программного обеспечения компании "Инфосистемы Джет"
Статей: 2 Фото-факт: 26

531

0.

12

0

3

Так уж исторически сложилось, что самым часто употребляемым инструментом для подготовки моделей машинного обучения, или, как их еще называют, предиктивных моделей, является Python, а точнее, ряд прикладных библиотек для него, которые берут на себя как задачи подготовки данных, так и непосредственное обучение моделей и их применение. И с точки зрения аналитиков, которые эти модели строят, это действительно хороший и удобный инструмент, обладающий достаточной гибкостью и невысоким порогом вхождения, ведь в работе Data Scientist’ов и без того немало что нужно знать и уметь. Если бы при этом еще требовалось держать в голове работу с памятью, многопоточность и прочие прелести «взрослых» языков, эти и без того редкие специалисты стали бы «вымирающим видом».

 

Все это приводит к тому, что существуют два не очень связанных мира. Один — это творческий подход и анархия при анализе, построении и проверке гипотез, обучении модели. и второй — строгий и упорядоченный мир продуктива, где важны скорость, потребляемые ресурсы и возможность масштабирования. И пропасть между этими мирами достаточно широка не только потому, что Python никогда не был языком для highLoad и параллельных вычислений, и даже не потому, что DataScientist’ы не могут подготовить быстро работающие модели, а потому, что пока нет устоявшихся и общепризнанных стандартов переноса такой сущности, как обученная модель, из среды разработки/анализа в продуктивную среду.

Для того чтобы было более понятно, о какой проблеме я веду речь, давайте подробнее остановимся на том, что же такое обученная модель. С точки зрения математики это всего лишь набор коэффициентов, описывающий некоторую функцию F(x), при подстановке в которую этих самых x мы получаем ответ в виде y. И тут вроде бы не может быть никаких проблем: уж что-что, а перенести простой массив чисел из одной среды в другую — дело несложное. 

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

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

Одно из очевидных решений — использовать одинаковые среды при анализе и на продуктиве.

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

Несмотря на то что такую модель легковесной никак не назовешь, это вполне работающий вариант. Одним из его неоспоримых плюсов является чрезвычайная гибкость модели — по факту мы вольны написать какой угодно код на Python и использовать его в своих преобразованиях. На другой чаше весов, очевидно, необходимость этот самый код писать. И каждая такая модель будет вашим новым «велосипедом». Хотите масштабируемость и параллельные вычисления? Извольте написать соответствующий код… Нужна оптимизация по памяти и производительности? Добро пожаловать в мир Python-ниндзя! Самое главное, что у этого подхода есть фундаментальное ограничение — первоначально не самая быстрая среда исполнения. Если задержка предсказания в секунду или десять для вас не проблема, беспокоиться не о чем, но если у вас запасе меньше секунды, а обрабатывать надо тысячи операций в секунду?

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

 

PMML

Пожалуй, одной из первых попыток создать универсальный формат переноса предиктивных моделей было появление стандарта PMML (Predictive Model Markup Language) в далеком 1997 г. Причем на ранних этапах речь шла даже не о каком-то реальном воплощении его в коде, а скорее о появлении спецификации как таковой. Впрочем, несмотря на глубоко проработанную консорциумом DMG (Data Mining Group) спецификацию и заявленный широкий круг  компаний и продуктов, которые этот формат поддерживают, сейчас, на мой взгляд, наблюдается явная нехватка реализаций этой самой спецификации. По факту есть лишь одна библиотека JPMML, реализованная на Java, которая поддерживает основные модели и преобразования, заявленные в спецификации версии 4.3. Большинство других продуктов, как правило, имеют ограничения как в экспорте своих моделей в данный формат, так и в применении моделей PMML. И больше всего настораживает то, что практически все наиболее развитые инструменты PMML по факту поддерживает один разработчик из Эстонии — Villu Ruusmann. И хотя он продолжает активно развивать JPPML и сопутствующие конвертеры, только его усилий явно недостаточно.

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

Как же выглядит процесс переноса данной модели на примере использования JPMML? Для начала вы должны подготовить обученную модель в одном из инструментов, для которого существуют конвертеры. Сейчас это LightGBM, R, SkLearn, SparkML, TensorFlow, Xgboost — для них конвертеры написаны автором JPPML, а также большой ряд продуктов типа Weka, RapidMiner, IBM, SPSS и др., в которых есть встроенные возможности экспорта в формат PMML. Конечно, если мы говорим о стандарте, при подготовке модели должны учитывать возможности, которые он предоставляет. Как правило, это означает, что мы не можем использовать самые свежие методы и какие-то элегантные решения. Но практика использования машинного обучения показывает, что в реальном мире, в отличие от соревнований DataScientist’ов, разница в результате на несколько десятых и даже на 2–3%, которая может быть обеспечена новейшими методами и моделями, не влияет на ценность результатов работы модели. После подготовки модели с помощью экспорта или конвертера вы сохраняете обученную модель в pmml-файл в формате xml. Теперь все, что нужно сделать, — загрузить эту модель на сервер и выполнить ее с помощью Java-библиотеки JPMML. Причем для упрощения данного процесса есть замечательный инструмент Openscoring, который предоставляет REST-интерфейс над методами JPPML. По заявлениям компании AirBnB, после небольших доработок данный подход позволял им получать предсказания при анализе возможного мошенничества в течение 10 мс. наши измерения также подтверждают высокую производительность использования JPPML в связке с Openscoring, что дает возможность использовать это решение в тех случаях, когда время ответа критично — например, при выявлении мошенничества в операциях с картами.

 

PFA

Естественным дальнейшим развитием стандарта PMML стал формат PFA (Portable Format for Analytics). Собственно, это попытка преодолеть минусы PMML, к которым относится список методов преобразований данных и моделей, ограниченный стандартом. Для этого в спецификации, кроме стандартных методов, появились элементарные операции типа арифметических и алгебраических выражений или операций над строками, а также элементы управления типа условий и циклов: комбинируя их, можно описывать алгоритмы напрямую. Кроме того, переход с XML на JSON также положительно сказался на объеме конечного файла модели. При этом, к сожалению, главный недостаток PMML пока так и не преодолен: реализаций спецификации совсем немного, к ним можно отнести Hadrian (Java), Titus (Python), Aurelius (R). И все эти реализации поддерживаются OpenDataGroup, которая предоставляет продукты с их использованием на коммерческой основе, что в целом неплохо, так как позволяет им развивать и поддерживать функционал. С точки зрения применения модели, пожалуй, стоит отметить тот факт, что генерация моделей возможна только из Python и R, также существует конвертер из pmml, в остальных случаях вы должны будете подготовить модель в pfa-формате в ручном режиме.

 

практика использования машинного обучения показывает, что в реальном мире, в отличие от соревнований DataScientist’ов, разница в результате на несколько десятых и даже на 2–3%, которая может быть обеспечена новейшими методами и моделями, не влияет на ценность результатов работы модели.

Mleap

Еще одна заметная попытка написать общий формат сериализации и выполнения моделей  — это проект Mleap. Несмотря на то что проект достаточно молодой: первые коммиты на GitHub от 2016 г., — он уже обладает функционалом, необходимым для переноса моделей между средами. В отличие от pmml и pfa, создатели mleap не пытались описать универсальную спецификацию, а сконцентрировались на возможности переноса моделей из основных инструментов, которые сейчас используют аналитики: PySpark, Scikit-learn, Spark, Tensorflow. Это позволило гораздо более полно поддерживать те возможности, которые предоставляют данные инструменты. Кроме того, к плюсам можно отнести единый движок выполнения. Это означает, что проблем совместимости с моделями, экспортированными из разных инструментов, не возникнет. Также хочется отметить, что при написании движка авторы сделали большой упор на производительность, многопоточность и параллельное выполнение из коробки — по их заявлениям, было достигнуто время отклика менее 1 мс. При этом выполнение моделей можно запускать в таких средах, как Spark. Данный проект выглядит достаточно перспективно, особенно если в аналитике вы используете один из поддерживаемых инструментов и вам требуется экстраординарная скорость выполнения готовых моделей.

 

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

 

Следите за нашими обновлениями

Спасибо!
Ваш материал отправлен.
Мы с вами свяжемся
Предложить
авторский материал
Спасибо!
Вы подписались на обновления наших статей
Подписаться
на рубрику
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Оформить
подписку на журнал
Спасибо!
Вы подписались на наши новости.
Оформить
подписку на Новости
Ваш комментарий отправлен.
После прохождения модерации комментарий будет опубликован на сайте.
Оставить
комментарий
Спасибо!
Ваша заявка отправлена.
Мы с вами скоро свяжемся.
Задать вопрос
редактору

Оставить заявку

Мы всегда рады ответить на любые Ваши вопросы

* Обязательные поля для заполнения

Спасибо!

Благодарим за обращение. Ваша заявка принята

Наш специалист свяжется с Вами в течение рабочего дня