Объединение пакетных и ML-систем с помощью конвейеров особенностей/обучения/вывода

Интеграция систем пакетной обработки и машинного обучения с использованием специализированных конвейеров

Рекламный контент

От Джима Доулинга, соучредителя и генерального директора Hopsworks

Введение

В этой статье представлена единая архитектурная схема для создания систем машинного обучения (ML) как пакетных, так и в реальном времени. Мы называем ее архитектурой конвейера FTI (Feature, Training, Inference). Пайплайны FTI делят монолитный пайплайн ML на 3 независимых пайплайна с четко определенными входами и выходами, где каждый пайплайн может быть разработан, протестирован и использован независимо. Для исторического понимания развития архитектуры FTI пайплайна вы можете прочитать полную статью о глубоком умственном плане MLOps.

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

• Generative AI в финансах FinGPT, BloombergGPT и далее
• 5 бесплатных книг, чтобы помочь вам овладеть Python
• Гармонизация цифровых каналов взаимодействия с клиентами модель синергии чатботов и ChatGPT с четырьмя квадрантами в современных организациях

Унифицированная архитектура ML-систем на основе пайплайнов Feature/Training/Inference

Подход FTI для этой архитектурной схемы использовался для создания сотен ML-систем. Схема состоит из трех независимых пайплайнов:

• пайплайн Feature, который принимает ввод необработанных данных и преобразует их в признаки (и метки)
• пайплайн Training, который принимает ввод признаки (и метки) и выдает обученную модель, и
• пайплайн Inference, который принимает новые данные признаков и обученную модель и делает предсказания.

В этой схеме FTI нет единого пайплайна ML. Исчезает путаница в том, что делает пайплайн ML (занимается ли он извлечением признаков, обучением моделей или также проводит вывод или только одно из этих действий?). Архитектура FTI применима как для пакетных ML-систем, так и для ML-систем в реальном времени.

Пайплайн признаков может быть пакетной программой или потоковой программой. Пайплайн обучения может выдавать все, начиная с простой модели XGBoost и заканчивая сложной моделью с эффективным использованием параметров (PEFT) или крупной языковой моделью (LLM), обученной на многих графических процессорах. Наконец, пайплайн вывода может быть пакетной программой, создающей набор предсказаний для онлайн-сервиса, который принимает запросы от клиентов и возвращает предсказания в режиме реального времени.

Одним из основных преимуществ пайплайнов FTI является их открытая архитектура. Вы можете использовать Python, Java или SQL. Если вам необходимо проводить инженерию признаков с большими объемами данных, вы можете использовать Spark, DBT или Beam. Обучение как правило выполняется на Python с использованием некоторого фреймворка машинного обучения, а пакетный вывод может быть выполнен как на Python, так и на Spark в зависимости от объема данных. Однако онлайн-пайплайны вывода почти всегда на Python, так как модели обычно обучаются на Python.

Пайплайны FTI также являются модульными, и между различными этапами есть четкий интерфейс. Каждый пайплайн FTI может работать независимо. В отличие от монолитного пайплайна ML разные команды могут отвечать за разработку и управление каждым пайплайном. Влияние этого заключается в том, что, например, для оркестрации одна команда может использовать один оркестратор для пайплайна Feature, а другая команда может использовать другой оркестратор для пакетного пайплайна вывода. Также можно использовать тот же оркестратор для трех разных пайплайнов FTI для пакетной ML-системы. Некоторые примеры оркестраторов, которые могут использоваться в ML-системах, включают общепринятые оркестраторы с широким функционалом, такие как Airflow, или легкие оркестраторы, такие как Modal, или управляемые оркестраторы, предлагаемые платформами для работы с признаками.

Некоторые из конвейеров FTI, однако, не потребуют оркестрации. Конвейеры обучения могут быть запущены по заявке, когда требуется новая модель. Конвейеры потоковых функций и конвейеры онлайн-вычисления работают непрерывно в виде сервисов и не требуют оркестрации. Flink, Spark Streaming и Beam запускаются в виде сервисов на платформах, таких как Kubernetes, Databricks или Hopsworks. Конвейеры онлайн-вычисления развертываются с помощью их модели на платформах обслуживания моделей, таких как KServe (Hopsworks), Seldon, Sagemaker и Ray. Основной идеей здесь является то, что конвейеры МО имеют модульную структуру с ясными интерфейсами, позволяющими выбирать наилучшую технологию для запуска ваших конвейеров FTI.

  

Наконец, мы покажем, как связать наши конвейеры FTI вместе с уровнем с сохранением состояния для хранения МО-артефактов – функций, данных обучения/тестирования и моделей. Конвейеры функций сохраняют свой вывод, функции, в качестве DataFrame в хранилище функций. Инкрементные таблицы хранят каждое новое обновление/добавление/удаление в виде отдельных фиксаций с использованием формата таблицы (мы используем Apache Hudi в Hopsworks). Конвейеры обучения считывают споты, согласованные во времени, снимки данных обучения из Hopsworks для обучения моделей и вывода обученной модели в реестр моделей. Здесь вы можете включить свой любимый реестр моделей, но мы склоняемся к реестру моделей Hopsworks. Конвейеры пакетного восстановления также считывают споты, согласованные во времени, снимки данных вывода из хранилища функций и создают прогнозы, применяя модель к данным вывода. Онлайн-вычисления осуществляются по требованию функций и считывают предрассчитанные функции из хранилища функций для построения вектора функции, который используется для предсказания в ответ на запросы онлайн-приложений/сервисов.

 

Конвейеры функций 

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

• Является ли конвейер функций пакетным или потоковым? 
• Являются ли приемы функций инкрементными или полными операциями?
• Какой фреймворк/язык используется для реализации конвейера функций?
• Выполняется ли проверка данных функций перед их передачей в хранилище функций? 
• Какой оркестратор используется для планирования конвейера функций? 
• Если некоторые функции уже были вычислены другой системой (например, хранилищем данных), как предотвратить дублирование этих данных и считывать только те функции, которые необходимы для создания данных обучения или пакетных данных вывода?

 

Конвейеры обучения

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

• Какой фреймворк/язык используется для реализации конвейера обучения?
• Какая платформа отслеживания экспериментов используется?
• Запускается ли конвейер обучения по расписанию (если да, какой оркестратор используется), или он запускается по требованию (например, в ответ на снижение производительности модели)?
• Требуются ли графические процессоры для обучения? Если да, как они распределяются по конвейерам обучения?
• Какое преобразование/масштабирование функций выполняется на каких функциях? (Мы обычно сохраняем функциональные данные необработанными в хранилище функций, чтобы их можно было использовать для EDA (обновления данных для исследования). Преобразование/масштабирование выполняется единообразно для конвейеров обучения и вывода). Примерами методов кодирования функций являются конвейеры scikit-learn или декларативные преобразования в представлениях функций (Hopsworks).
• Какой процесс оценки и проверки модели используется?
• Какое хранилище моделей используется для хранения обученных моделей?

 

Конвейеры вычислений

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

• Кто является потребителем распознавания – это панель управления, онлайн-приложение – и как потребляются прогнозы? 
• Это пакетный или онлайн-конвейер вычислений?
• Какой тип преобразования/масштабирования функций выполняется на каких функциях? 
• Для пакетного конвейера вывода, какой фреймворк/язык используется? Какой оркестратор используется для его запуска по расписанию? Какой приемник используется для потребления созданных прогнозов?
• Для онлайн-конвейера вывода, какой сервер обслуживания модели используется для размещения развернутой модели? Как реализован онлайн-конвейер вывода – в виде класса предсказателя или с отдельным этапом преобразователя? Требуются ли графические процессоры для вывода? Существует ли СЛА (соглашения об уровне обслуживания) по времени отклика на запросы прогноза?

 

Принципы MLOps

 Существует мнение, что MLOps заключается в автоматизации непрерывной интеграции (CI), непрерывной доставки (CD) и непрерывного обучения (CT) для систем машинного обучения. Но это слишком абстрактно для многих разработчиков. MLOps на самом деле заключается в непрерывной разработке продуктов с использованием машинного обучения, которые развиваются со временем. Доступные входные данные (функции) меняются со временем, цель, которую вы пытаетесь предсказать, меняется со временем. Вам нужно вносить изменения в исходный код, и вы хотите убедиться, что любые изменения, которые вы вносите, не ломают вашу систему машинного обучения или не ухудшают ее производительность. И вы хотите ускорить время, необходимое для внесения этих изменений и их тестирования, прежде чем они автоматически развернутся в производство.

Таким образом, с нашей точки зрения, более лаконичное определение MLOps, которое позволяет развивать системы машинного обучения в течение времени, требует, как минимум, автоматизированного тестирования, версионирования и мониторинга артефактов машинного обучения. MLOps – это автоматизированное тестирование, версионирование и мониторинг артефактов машинного обучения.

  

На рисунке 4 мы видим, что в системах машинного обучения требуется больше уровней тестирования, чем в традиционных программных системах. Даже небольшие ошибки в данных или коде могут легко привести к неверным прогнозам модели машинного обучения. С точки зрения тестирования, если веб-приложения – это самолеты с пропеллерами, то системы машинного обучения – это реактивные двигатели. Требуется значительное инженерное усилие, чтобы протестировать и проверить ML-системы и сделать их безопасными! В общих чертах, нам нужно тестировать как исходный код, так и данные для ML-систем. Функции, созданные с помощью конвейеров функций, могут быть протестированы с помощью модульных тестов, а входные данные могут быть проверены с помощью тестов на валидацию данных (например, Great Expectations). Модели должны быть протестированы на производительность, а также на отсутствие предвзятости по отношению к известным группам уязвимых пользователей. Наконец, на вершине пирамиды системы машинного обучения должны протестировать свою производительность с помощью A/B-тестов, прежде чем они смогут перейти к использованию новой модели.

Наконец, нам необходимо версионировать артефакты машинного обучения, чтобы операторы систем машинного обучения могли безопасно обновлять и откатывать версии развернутых моделей. Поддержка системы для кнопочного обновления/отката моделей является одной из священных граалей MLOps. Но моделям требуются функции для предсказания, поэтому версии моделей связаны с версиями функций, и модели и функции должны быть обновлены/откатаны синхронно. К счастью, вам не нужен год работы в компании Google SRE, чтобы легко обновлять/откатывать модели – поддержка платформы для версионированных артефактов машинного обучения должна сделать эту операцию по обслуживанию системы машинного обучения простой и понятной.

 

Примеры систем машинного обучения

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

Пакетные системы машинного обучения

• Прогнозирование потребления электроэнергии (452 звезды на github)
• Прогнозирование игр NBA (152 звезды на github)
• Прогнозирование счета матчей английской премьер-лиги (101 звезда на github)
• Прогнозирование оттока клиентов (113 звезд на github)

Системы машинного обучения в режиме реального времени

• Онлайн-мошенничество с кредитными картами (113 звезд на github)
• Прогнозирование цены криптовалюты (65 звезды на github)
• Одобрение заемных заявок (113 звезд на github)

 

Резюме

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

Узнайте больше о фундаментальных принципах и элементах, которые составляют архитектуру FTI Pipeline, в нашей полной подробной картине MLOps.