{"id":13650,"url":"\/distributions\/13650\/click?bit=1&hash=b4a44ea9299acb416ac92e110a87e80acc960de1a8f124e06d52ec1ea62c252a","title":"\u041a\u0430\u043a \u043f\u043e\u0441\u0442\u0440\u043e\u0438\u0442\u044c \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u044b\u0439 \u0434\u043e\u043c \u043a\u0430\u043a \u0432 Sims","buttonText":"","imageUuid":"","isPaidAndBannersEnabled":false}
Трибуна
Oleg Sokolov

Как мы намучились с рутиной и придумали фреймворк Piper для быстрого создания ML-проектов

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

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

Получается, что для того, чтобы воспользоваться всеми плюсами и “плюшками” от машинного обучения для бизнеса, разработчикам и компаниям нужно в первую очередь попробовать снизить нагрузку при его внедрении. А значит, ускорить прототипирование и создание сложных Machine Learning (ML)-систем, при этом с меньшим объемом работ, и буквально в несколько строк кода.

Решения на рынке

Рынок уже предлагает что-то для решения этой проблемы. Вначале можно рассмотреть некоторые существующие системы для интеграции машинного обучения в прод, а также быстрого написания ML-пайплайнов:
1) Jupyter – де-факто основная экспериментальная среда большинства data-scientistов. Безусловно ускоряет написание экспериментального кода, однако писать все модули и переносить далее в прод нужно руками часто нескольких разных разработчиков.
2) Azure ML / Amazon SageMaker / Google Cloud – Облачные платформы действительно позволяют собрать целую систему из готовых модулей и относительно быстро запустить в работу. Из минусов: большая стоимость, привязка к определенному клауду, а также малая кастомизация под специфические нужды бизнеса. Для крупного бизнеса это самый логичный вариант – строить ML-инфраструктуру в облаке.
3) DataRobot / Baseten – Предлагают интересный, но небольшой набор готовых модулей. Однако в Baseten вся интеграция подразумевается в kubernetes кластер. Это не всегда удобно и необходимо для Proof-of-Concept. Piper – также предоставляет open-source фреймворк, в котором можно будет собрать по-настоящему кастомизированный пайплайн из множества модулей. В основном такие компании либо не предоставляют open-source фреймворк, либо дают очень урезанный набор модулей для экспериментов, что ограничивает свободу, функциональность и применимость данных платформ. Это частично похоже на hub моделей и датасетов в huggingface.
4) Apache Airflow / Luigi – Это весьма популярные инструменты сборки ML-пайплайнов. Airflow можно подключить к kubernetes кластеру или собирать задачи через простой PythonOperator. Минус, что на этом их функционал в целом ограничен, то есть ML-модулей из коробки они не предоставляют, то есть все наработки все равно придется оборачивать в шедулер и это не всегда тривиальная задача.
5) Mlflow / DVC и пр. – Также на рынке много отличных проектов для трекинга экспериментов, сервинга и хранения моделей машинного обучения. Но они все больше утилитарные и не помогают напрямую в задаче ускорения построения MVP-проекта машинного обучения. Мы планируем добавить интеграции в Piper с самыми популярными фреймворками для нужд DS и ML-специалистов.

Так что же мы предлагаем в качестве решения проблемы?

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

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

Мы хотели, чтобы Piper умел делать:

  • Легко собирал новое MVP или PoC из готовых модулей.
  • Добавлял собственные модули для уникальных задач компании.
  • Разворачивал систему в нужную инфраструктуру.

Основной идеей нашего Piper стала модульность:
В ядре фреймворка столпом будет класс модуля или Executor. Из таких блоков разработчик сможет собирать ML-пайплайн. Ниже пример того, как это будет выглядеть в фреймворке Piper:

Ниже пример как это может использовано в связке с другими модулями:

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

  • Python virtualenv для локальной сборки.
  • Docker / Docker-compose в виде микросервисов.
  • Kubernetes.
  • Как DAG в Airflow.
  • Основные клауды.

Для удобства, мы сделали так, что настроить конкретный Environment можно либо в конфигурации проекта, либо с помощью контекстного менеджера, примерно вот так:

Сборку и запуск проекта можно производить из кода или с помощью cli, одной простой командой:

После того, как мы протестировали Piper на своих проектах в различных отраслях: от распознавания объектов до классификации документов – мы поняли, что зачастую трудности возникают на первых этапах проекта, – долгий ресерч и однообразная настройка инфраструктуры под нужды заказчика. Пообщавшись с нашими разработчиками, заказчиками и дата-саентистами, стало ясно, что такой фреймворк как Piper действительно имеет потенциал ускорения и упрощения разработки, после чего начали воплощать его в жизнь для подтверждения гипотезы и уже на первых этапах увидели его полезность. В наших планах добавить в открытый доступ большое число протестированных модулей для широкого спектра задач индустрии. От распознавания лиц до классификаторов документов по текстам и рекомендательных систем. Также будут добавлены удобные интеграции с основными библиотеками для ML и Data-Science: numpy, pandas, scikit-learn, pytorch. Это необходимо, чтобы любой разработчик мог легко добавить нужную бизнес-логику с использованием популярных фреймворков.

Применение Piper на примере проекта

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

Представим следующие условия:

  • У банка есть биографии клиентов, которые выплатили кредит и тех, которые не выплатили.
  • Цель – построить модель прогнозирования возврата кредита, что позволит оптимизировать направление кредитования и увеличить прибыль банка.
  • Данные: pdf файлы с биографиями, csv файл с отметками 1 – вернул, 0 – не вернул.
  • Задача: на основе данных из биографий, транзакций и меток возврата построить классификатор возврата кредита.

Рассмотрим два возможных пути решения:

  • Силами собственной команды собрать in-house решение с нуля.
  • Использовать Piper и собрать решение из готовых модулей.

При решение с Piper сборка производится на 90% за счет уже подготовленных модулей из библиотеки фреймворка, это помогает сократить затраты на поиск актуального решения и написания кода с нуля. Однако добавляется шаг сборки всей цепочки в пайплайн, чтения документации модулей. Но этот этап по нашему опыту получается значительно быстрее, так как в большинстве случаев DS-специалистам не нужно читать много статей по теме или искать рабочее решение в open-source. Нужно лишь найти подходящие модули в Piper, добавить нужную конфигурацию и собрать все в единый пайплайн. Возможно для уникальных кейсов придется дописать кастомную логику или на начальном этапе и в редких случаях дописать свои модули, но мы для этого делаем максимально удобный флоу кастомизации. То есть даже для уникальных задач прототипирование с Piper будет быстрее обычного in-house решения.
Вторым важным фактором ускорения разработки является возможность развернуть систему минимальными усилиями с помощью нескольких команд Piper. Можно указать необходимый вид инфраструктуры и запустить деплой системы. Это дает ускорение процессов в команде разработчиков. Так как в обычных in-house процессах data-scientist передает код (зачастую не самый понятный) разработчикам и девопсам для развертывания или встраивает в прод самостоятельно с помощью некой не самой удобной для этого системы вроде Airflow. То есть тратится много времени на взаимодействие разработчиков, лидов, менеджеров и на обертывания кода модели в прод сервисы. На этом этапе зачастую могут возникнуть ошибки вида: “потеряли” какую-то фичу, разработчик не понял принцип работы модели и неправильно настроил ее в сервисе или оптимизировал предпроцессинг по-своему, что тоже повлияло на точность результатов в проде. Поэтому в таком подходе время еще уходит и на тестирование модели в проде, а также исправление ошибок интеграции. С Piper шансы таких ошибок минимальны, так как фреймворк предоставляет протестированную автоматическую обертку в микросервисы или другую инфраструктуру.

Ниже приведена наша примерная оценка сроков небольшого MVP для описанной банковской задачи:

Подводя итог

  • Piper позволил достигнуть 300% увеличения продуктивности в 3 раза дешевле!
  • Piper помогает в создании пайплайнов и не зависит от сторонних сервисов. Вы добавляете выбранный модуль в пайплайн, запускаете и легко строите всю инфраструктуру через venv, docker или клауд.
  • Piper ускоряет процесс разработки от эксперимента до продакшена, а также уменьшает количество рутинных задач.

Понятно, что это лишь наши предварительные выводы. Работы предстоит еще много - к концу 2022 года мы планируем завершить написание ядра системы, покрыть основные окружения для деплоя и написать 10 базовых модулей в области обработки документов, текстов и изображений. Сейчас Piper еще активно тестируется, поэтому если вам этот инструмент показался интересным или уже есть запрос на добавление определенных модулей, то смело добавляйтесь в наш чат https://t.me/pipertool, пишите в комменты и мы с удовольствием пообщаемся и пришлем фреймворк на тестирование, когда будет готова первая версия. Спасибо!

0
2 комментария
Dennis Prochko

а что не на гитхабе? проприетарщина?

Ответить
Развернуть ветку
Oleg Sokolov
Автор

Будет часть функционала в полном опенсорсе, еще дописываем ядро пока, сообщим о старте беты в нашем канале

Ответить
Развернуть ветку
Читать все 2 комментария
null