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

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

Получается, что для того, чтобы воспользоваться всеми плюсами и “плюшками” от машинного обучения для бизнеса, разработчикам и компаниям нужно в первую очередь попробовать снизить нагрузку при его внедрении.  А значит, ускорить прототипирование и создание сложных 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: 

class MyCustomExecutor(piper.Executor):
def call(self, my_image_path: str):
cv2.imread…
…
return result

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

image = piper.pdf.PdfToImage(format=”opencv”)(pdf_path)
image_path = piper.image.ImageToTmpFile(format=”jpg”)(image)
custom_executor_result = MyExecutor()(image_path)
print(custom_executor_result)

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

• Python virtualenv для локальной сборки.

• Docker / Docker-compose в виде микросервисов.

• Kubernetes.

• Как DAG в Airflow.

• Основные клауды.

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

with piper.envs.Docker():
image_path = “hello.png”
executor = MyExecutor()
result = executor(image_path)
print(result)

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

piper deploy –env=docker/

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

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

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

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

• У банка есть биографии клиентов, которые выплатили кредит и тех, которые не выплатили.

• Цель – построить модель прогнозирования возврата кредита, что позволит оптимизировать направление кредитования и увеличить прибыль банка.

• Данные: pdf файлы с биографиями, csv файл с отметками 1 – вернул, 0 – не вернул.

• Задача: на основе данных из биографий, транзакций и меток возврата построить классификатор возврата кредита.

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

1. Силами собственной команды собрать in-house решение с нуля.

2. Использовать 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, пишите в комменты и мы с удовольствием пообщаемся и пришлем фреймворк на тестирование, когда будет готова первая версия. Спасибо!