Мы рады сообщить, что открыли наш фреймворк Piper для всех разработчиков на гитхабе. Несмотря на то, что мы не закончили некоторые важные аспекты ядра, решили не ждать, а сразу поделиться, и теснее пообщаться о нашей разработке. В конце концов, мы изначально задумали, чтобы продукт был опенсорсным и все могли его использовать, решая свои задачи. Приветствуем любую обратную связь и помощь в доработке!✌️В этой статье расскажем о фреймворке Piper, его целях, конкурентах, о том, что есть в текущей версии и что планируем добавить в ближайшее время. Начнем с предыстории…
Искусственный интеллект, кластеризация данных для больших корпораций, домашние наработки для нейросетей, стартапы с миллионным финансированием или собранные на коленке - все они используют инструменты им доступные, пусть то предобученные модели, размеченные данные или инструменты для упрощения написания кода. Давайте посмотрим и разберем в свободной дискуссии плюсы и минусы, необходимость всех этих инструментов?
Но сначала о ML решениях конкурентов:
1) Jupyter – де-факто основная экспериментальная среда большинства data-scientistов. Безусловно ускоряет написание экспериментального кода, однако писать все модули и переносить далее в прод нужно руками часто нескольких разных разработчиков.
2) Azure ML / Amazon SageMaker / Google Cloud – Облачные платформы действительно позволяют собрать целую систему из готовых модулей и относительно быстро запустить в работу. Из минусов: большая стоимость, привязка к определенному клауду, а также малая кастомизация под специфические нужды бизнеса. Для крупного бизнеса это самый логичный вариант – строить ML-инфраструктуру в облаке.
3) DataRoot / Baseten – Предлагают интересный, но небольшой набор готовых модулей. Однако в Baeten вся интеграция подразумевается в kubernetes кластер. Это не всегда удобно и необходимо для Proof-of-Concept. Piper – также предоставляет open-source фреймворк, в котором можно будет собрать по-настоящему кастомизированный пайплайн из множества модулей. В основном такие компании либо не предоставляют open-source фреймворк, либо дают очень урезанный набор модулей для экспериментов, что ограничивает свободу, функциональность и применимость данных платформ.
4) Apache Airflow / Luigi – Это весьма популярные инструменты сборки ML-пайплайнов. Airflow можно подключить к kubernetes кластеру или собирать задачи через простой PythonOperator. Минус, что на этом их функционал в целом ограничен, то есть ML-модулей из коробки они не предоставляют. Таким образом все наработки все равно придется оборачивать в шедулер и это не всегда тривиальная задача.
5) Mlflow / DVC и пр. – Также на рынке много хороших проектов для трекинга экспериментов, сервинга и хранения моделей машинного обучения. Но они все чисто утилитарные и не помогают напрямую в задаче ускорения построения MVP-проекта машинного обучения. Мы планируем добавить интеграции в Piper с самыми популярными фреймворками для нужд ML-специалистов.
6) Hugginface - Платформа, где можно скачать и опубликовать нейросеть и пайплайн к ней на любой вкус. Вероятно главный наш конкурент по духу. У них мощное комьюнити, SOTA модели появляются через неделю после выхода статей, а также добавляют разные возможности деплоев. Однако их фокус именно на самих моделях. У нас больше упор на отдельные домены вроде распознавания лиц, а также разные варианты деплоя, а также no-code платформе для сборки сложных систем.
Кажется кое-что все-таки упущено: скорость разработки полноценной ML-системы, гибкость модулей, возможность кастомизаций, а также достаточный уровень качества самих модулей.
Вот мы и собрали как дополнительный инструмент – Piper – python фреймворк, позволяющий собрать полноценную ML-систему из набора готовых или кастомных модулей и развернуть систему в нужной среде.
Мы хотели, чтобы Piper умел делать:
Легко собирал новое MVP или PoC из готовых модулей
Добавлял собственные модули для уникальных задач компании
Разворачивал систему в нужную инфраструктуру
Основной идеей нашего Piper стала модульность:
В ядре фреймворка столпом является класс модуля для решения небольшой задачи или иначе Executor. Из таких блоков разработчик сможет собирать ML-пайплайн. Сейчас это выглядит как в примере ниже:
class MyExecutor(FastAPIExecutor):
def run(self, my_image_path: str):
cv2.imread
…
return result
Далее экзекьютор можно использовать подобно pytorch.nn.Module, то есть как некий Сallable
result = MyExecutor()(“image.png”)
В данный момент нужно унаследовать готовый экзекьютор для конкретной задачи, например у нас есть HTTPExecutor и FastAPIExecutor, который могут обернуть ваш код в микросервис. Это логика далее будет базовой для некоего общего Executor. Свои базовые экзекьюторы можно писать унаследовав BaseExecutor.
Простыми словам - вы можете написать некий ml код и внутри своего класса экзекьютора и затем его развернуть, например, внутри микросервиса на FastAPI.
Для этого экзекьютор запускается в неком Enviroment, в данном случае в Docker контейнере.
with envs.Docker():
result = MyExecutor()(“image.png”)
Piper понимает, что нужно сделать кодогенерацию в микросервис и развернуть его как докер контейнер. Результа получается из сервиса как json простым POST запросом.
Но если вы хотите протестировать или запусть MyExecutor локально, то можно просто выбрать локальный энв (по сути это тот python, где вы работаете в данный момент).
with envs.CurrnetEnv():
result = MyExecutor()(“image.png”)
Но, это конечно не все – мы планируем добавить поддержку следующих вариантов деплоя пайплайна:
Python virtual env для локальной сборки
Docker / Docker-compose в виде микросервисов
Kubernetes
Как DAG в Airflow
Основные клауды (Google, AWS, Azure)
Смысл Piper в том, чтобы Data-Scientist или любой разработчик мог собрать из готовых модулей пайплайн. Это может выглядеть как на примере ниже:
with envs.Docker():
document = PDF()(“1.pdf”)
image =PDFToImage()(document)
result = MyEexcutor()(image)
Где модули PDF, PDFToImage разработчик берет уже готовые из фреймворка, а затем обрабатывает своим кастомным MyExecutor.
На данный момент у нас нет модулей для PDF, но у нас добавлены FaceRecognition, TesseractOCR, Milvus для эмбедингов лиц или текстов. Но мы расширяем функциональность Piper параллельно с разработкой ядра. В планах разработка обработчиков основных файлов, а также покрыть основные домены вроде классификации изображений или Named Entity Recognition, а также различные новые домены вроде мультимодальных моделей CLIP или генерации картинок со Stable Diffusion.
Еще раз о целях Piper:
Цель нашего фреймворка в ускорении ml разработки. Представим себе, что компания или стартап решает создать новую ml систему, это может быть Face Recognition или рекомендательная система.
Рассмотрим два возможных пути решения (покупку готового решения опустим, так как тяжело сравнивать):
Силами собственной команды собрать in-house решение с нуля.
Использовать Piper и собрать решение из готовых модулей.
При решение с Piper сборка производится на 90% за счет уже подготовленных модулей из библиотеки фреймворка, это помогает сократить затраты на поиск актуального решения и написания кода с нуля. Однако добавляется шаг сборки всей цепочки в пайплайн, чтения документации модулей. Но этот этап по нашему опыту получается значительно быстрее, так как в большинстве случаев DS-специалистам не нужно читать много статей по теме или искать рабочее решение в open-source. Нужно лишь найти подходящие модули в Piper, добавить нужную конфигурацию и собрать все в единый пайплайн. Возможно для уникальных кейсов придется дописать кастомную логику или на начальном этапе и в редких случаях дописать свои модули, но мы для этого делаем максимально удобный флоу кастомизации. То есть даже для уникальных задач прототипирование с Piper будет быстрее обычного in-house решения.
Вторым важным фактором ускорения разработки является возможность развернуть систему минимальными усилиями с помощью нескольких команд Piper. Можно указать необходимый вид инфраструктуры и запустить деплой системы. Это дает ускорения процессов в команде разработчиков. Так как в обычных in-house процессах data-scientist передает код (зачастую не самый понятный) разработчикам и девопсам для развертывания или встраивает в прод самостоятельно с помощью некой не самой удобный для этого системы вроде Airflow. То есть тратится много времени на взаимодействие разработчиков, менеджеров и обертывания кода модели в прод сервисы. На этом этапе зачастую могут возникнуть ошибки вида “потеряли” какую-то фичу, разработчик не понял принцип работы модели и неправильно настроил ее в сервисе, или оптимизировал предпроцессинг по-своему, что тоже повлияло на точность результатов в проде. Поэтому в таком подходе время еще уходит и на тестирование модели в проде, а также исправление ошибок интеграции. С Piper шансы таких ошибок минимальны, так как фреймворк предоставляет протестированную автоматическую обертку в микросервисы или другую инфраструктуру.
Ниже приведена наша данные сроков небольшой ML задачи во внутренних проектах:
Этапы | in-house | Piper |
Изучение задачи и данных аналитиком, подготовка среды | 10 дней | 5 дней |
Написание подготовки данных и обучение модели в Jupyter | 21 день | - |
Сбор пайплайна из модулей Piper и обучение моделей в Piper | - | 5 дней |
Перенос кода в прод | 14 дней | 3 дня |
Устранение багов и оптимизации | 10 дней | 2 дня |
Тестирование результатов решения | 3 дня | 3 дня |
Итого | ~2 месяца | 18 дней |
Подводя итог:
Мы открыли доступ к open-source фреймворку Piper. Его преимущества и задачи:
Piper помогает в создании пайплайнов и не зависит от сторонних сервисов. Вы добавляете выбранный модуль в пайплайн, запускаете docker и строите всю инфраструктуру через venv, docker или клауд.
Piper ускоряет процесс разработки от эксперимента до продакшена, а также уменьшает количество рутинных задач.
Сейчас уже можно посмотреть как устроено ядро и первые модули. Мы активно ищем контрибьюторов и развиваем комьюинити. Нам требуются сильные разработчики Python для ядра, ML-разработчики для написания экзекьюторов любого домена в области машинного обучения, а также тестировщики и JS разработчики для no-code платформы.
Как контрибьютить?
Добавляйтесь в наш чат https://t.me/pipertool, также можете писать там или здесь на Хабре, если интересно поучаствовать в разработке.
Мы отвечаем и выбираем наиболее нужный на данный момент модуль, допустим Face Recognition, интеграция DVC или Stable Diffusion. Потом все стандартно присылаете PR, командой ядра смотрим и мержим, если все концептуально устраивает.
Вы также можете прислать свой модуль любого интересного вам домена машинного обучения, мы обсудим подходит ли он по духу Piper и, скорее всего, добавим Ваш модуль к нам.
Также есть задачи на само ядро, там больше работы с Docker, инфраструктурные задачи, алгоритмы работы Piper на Python. Там процесс чуть более сложный, поэтому на эти задачи нужно общаться более детально.
Работы предстоит еще много - в ближайшие месяцы мы планируем завершить написание ядра системы, покрыть основные окружения для деплоя и написать 10 базовых модулей в области обработки документов, текстов и изображений.
