Data Science в производстве: опыт, инструменты и фреймворки

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

Ландшафт данных быстро меняется

Когда я впервые начал заниматься машинным обучением, работая инженером по большим данным в 2014 году, оно в основном применялось в контексте больших данных. Не то чтобы машинное обучение или наука о данных были чем-то новым, но MapReduce в Hadoop и более поздние механизмы в памяти, такие как Apache Spark, соединили мощь машинного обучения с возможностями распределенных вычислений и огромными объемами (веб-данных). Мы видели много серьезных изменений, начиная с взлета и падения (локальной) экосистемы Hadoop (не в последнюю очередь из-за огромных затрат на администрирование) и продолжающейся тенденции обработки данных в облаке, и мы можем быть уверены что только одно неизменно: изменение.

Изменилась не только инфраструктура, но и рамки и методы. От TensorFlow до Pytorch, от CRISP-DM до Agile и от SOAP до Serverless. Сложно уследить за тенденциями.

MLOps Buzz

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

Нет никого, чтобы управлять ими всеми

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

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

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

Языки

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

питон

Конечно, я рекомендую стек Python с использованием pandas, scikit-learn, seaborn, tensorflow, pytorch, huggingface, jupyter и так далее. Однако более важным с точки зрения MLOps является развертывание этого стека. Если у вас есть облегченные скрипты, я рекомендую использовать AWS Lambda, если он становится более продвинутым, я предпочитаю запускать облачный сервер (например, AWS EC2) и изолировать все в Докере. Разумно использовать терраформ для инфраструктуры. Я также рекомендую использовать anaconda, так как их репозиторий курируется и довольно дешев для профессионального использования.

R

Иногда вам может понадобиться запустить R-скрипты в производство. В этом случае либо выберите управляемую службу, либо используйте Docker для изоляции сред. Не устанавливайте R на «голое железо» и не пытайтесь запускать там сценарии производства, вы пройдете через ад, так как R точно не предназначен для использования в качестве языка производственного уровня. И помните о последствиях для безопасности репозитория R.

Джава

Если у вас есть Java, как во многих компаниях, может быть проще использовать java ml framework. Во многих случаях имеет смысл интегрировать ваши модели непосредственно в ваш программный ландшафт. Но вам нужны люди, которые либо умеют программировать на Java, либо вам нужны инженеры, которые транспилируют код. Хотя мне лично не нравится WEKA и я бы избегал deeplearning4j, мне очень понравилось использовать Smile-ML.

Фреймворки и продукты

Отслеживание экспериментов

Вокруг много разных инструментов, но лично мне нравится Neptune.ai. Они называют себя хранилищем метаданных для ML-Ops, и это довольно точно. Вы можете использовать их бесплатно даже в небольшой команде, отслеживать свои эксперименты и сохранять свои модели, поддерживая множество различных фреймворков, таких как scikit-learn, TensorFlow, Pytorch, R…

Развертывание сценариев и развертывание моделей глубокого обучения

Если вы развертываете модели глубокого обучения, я бы посоветовал вам использовать модельный сервер. Это может быть Triton, tensorflow serve или что угодно, но используйте модельные серверы! Если у вас нет пользовательских слоев, используйте ONNX в качестве формата, если у вас есть пользовательские слои, оставайтесь с модельным сервером фреймворка, чтобы избежать лишней работы. Здесь я писал об этом подробнее, акцентируя внимание на TensorFlow.

Если вы развертываете скрипты для пакетных прогнозов, пойдите простым путем и запустите их в Docker. Для API вы можете, как было сказано ранее, бессерверные продукты, такие как AWS Lambda, или запускать FastAPI внутри контейнера Docker.

Обучение модели

С помощью terraform вы также можете автоматизировать обучение моделей в облаке на экземплярах GPU (AWS, GCP, Azure). Тем не менее, мне лично нравится мощный графический процессор на моей машине для разработки, чтобы очень быстро тестировать вещи и оценивать модели. Гораздо быстрее для прототипирования иметь локальный графический процессор. Также обратите внимание, что существуют определенные экземпляры графического процессора для логического вывода.

Оркестровка

Для оркестровки AirFlow или Prefect кажутся хорошим выбором, однако Prefect требует, чтобы вы установили агент на каждый сервер (что обычно не нравится администраторам), в Airflow вы можете использовать SSH.

Мониторинг

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

SQL и векторные базы данных

Я был счастлив работать с чистыми базами данных SQL, такими как MySQL или PostgeSQL. Однако в какой-то момент разумно использовать хранилища данных, и поскольку кластер Hadoop в 2022 году никто не строит, вам лучше присмотреться к облачным хранилищам данных, таким как Снежинка, которые предлагают множество расширенных функций, особенно для ML и DS (Snowpark ).

Но есть еще кое-что, если вы используете некоторые поисковые системы сходства (например, визуальное сходство), вы можете исследовать векторную базу данных. Прямой подход — использовать HNSWlib (поддерживает множество языков, включая Java) или Annoy от Spotify, где индекс — это просто файл. Но есть и более продвинутые варианты вроде Milvus.io.

Управление проектом

Не используйте Scrum, используйте Kanban, но это мое мнение. Подробности смотрите здесь.

Настройка вывода

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

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

Пакетная обработка намного проще, так как ее можно легко повторить в случае сбоя, вам не нужно учитывать задержку, и обычно вам нужен только ввод -> вывод без особого участия сети.

Я надеюсь, что это даст вам некоторое представление и поможет понять, что такое MLOps. Как всегда, здесь много мнений, это нормально, если есть другой опыт, но я рад услышать ваше в комментариях.