Оглавление

  1. Введение
    1.1 Рабочие процессы в области науки о данных и разработки программного обеспечения различны
    1.2 В конвейер машинного обучения должно быть включено непрерывное обучение
    1.3 Дрейф модели
  2. Магазин функций
    2.1 Централизованный доступ к данным
    2.2 Управление версиями данных
    2.3 Конвейеры данных
    2.4 Маркировка данных
    2.5 Репозиторий функций и обнаружение данных
  3. Учебный конвейер
    3.1 Управление моделью и экспериментом
    3.2 Управление конвейером
    3.3 Автоматическая разработка функций, HPO и NAS
    3.4 Распределенное обучение
    3.5 Среды и стандарты кодирования
  4. Производство
    4.1 Обслуживание модели
    4.2 Проверка данных, проверка модели, оценка и мониторинг
    4.3 Стратегии развертывания
  5. "Заключение"

1. Введение

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

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

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

Многие принципы, разработанные в сообществе DevOps / SRE, такие как CI / CD и мониторинг, могут быть внедрены в рабочий процесс обработки данных с помощью платформы машинного обучения ².

Лучшие методы для предприятий по внедрению рабочих нагрузок машинного обучения определяются как MLOps. В группе Prosus мы измеряем MLOps по уровням принятия упомянутых методов ³. Переход от ручного процесса к CT, а затем к CI / CD для машинного обучения отражает зрелость того, как компании из нашего портфеля создают модели и в конечном итоге развивают свой бизнес.

Развертывание модели в производстве - это только начало жизненного цикла модели машинного обучения ⁴.

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

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

Рабочий процесс Data Science предоставляет модель посредством процесса выбора комбинаций алгоритмов и параметров. Модель, измеряемая по метрикам (таким как точность), открыта для улучшения. Он внедряется в производство для вывода знаний из данных. Этот процесс вывода зависит от входных данных. И эта динамическая связь между предоставленной моделью и данными отражает разницу между двумя рабочими процессами.

1.2 Пайплайн машинного обучения должен включать непрерывное обучение

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

Стандартизация универсальной платформы машинного обучения впервые была представлена ​​в TFX paper. В нем описаны строительные блоки платформы машинного обучения в виде компонентов и показано повышение производительности в результате ее внедрения. Развертывание TFX может привести к сокращению количества настраиваемого кода и ускорению циклов экспериментов. Это также может сократить время производства с нескольких месяцев до недель и обеспечить стабильность платформы, сводящую к минимуму сбои.

1.3 Дрейф модели

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

В производственной среде, такой как бизнес Prosus (платежи, доставка еды, объявления, онлайн-образование), схема и распределение данных динамически меняются (новые тенденции, привычки). Такое поведение определяется как дрейф данных. Когда меняются статистические свойства целевой переменной, меняется и само понятие того, что вы пытаетесь предсказать. Например, определение мошеннической транзакции со временем может измениться по мере разработки новых способов проведения таких незаконных транзакций. Такое изменение приведет к дрейфу концепции.

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

  • Схема и распределение входящих данных в обучающем наборе данных
  • Распределение меток обучающего набора данных
  • Схема и распределение входящих данных запросов на логический вывод
  • Распространение прогнозов
  • Качество прогнозов

2. Магазин функций

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

2.1 Централизованный доступ к данным

Существует множество форм систем хранения данных: озеро данных, хранилище данных, витрина данных и хранилище функций. Они представляют разные уровни управления данными, и их различия обсуждаются ниже.

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

Хранилище данных (DWH): где компания хранит обработанные, смоделированные и структурированные данные. Все подразделения организации используют хранилище данных для хранения и извлечения операционных показателей, бизнес-показателей и т. Д.

Витрина данных: простое хранилище данных из определенного количества источников, используемых одним конкретным бизнес-отделом.

Некачественные данные - самая частая причина проблем в производственных системах машинного обучения «».

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

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

Хранилище функций по существу отделяет процесс разработки функций от потребления этих функций (например, во время разработки модели). Работа по разработке функций зависит от экспертов в предметной области, которые публикуют функции в хранилище функций (и обычно имеют реестр для поддержки их обнаружения, см. Раздел 2.5 ниже). Эти функции существуют независимо от процесса разработки модели, поэтому их можно использовать повторно.

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

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

Популярные магазины функций включают Michelangelo Pallete (Uber), Feast (Gojek и Google), Zipline (Airbnb) и Hopsworks (LogicalClocks) ⁶.

2.2 Управление версиями данных

Возможность управления версиями данных в хранилище функций является предпосылкой для реализации MLOps, точно так же, как управление версиями кода требуется для практики DevOps. Существует два основных подхода к реализации управления версиями данных: git-style и путешествие во времени.

DVC - популярная система управления версиями данных, использующая git для хранения метаданных о файлах данных. Pachyderm, платформа машинного обучения на Kubernetes, также использует метод в стиле git для управления версиями данных. Это дает возможность веткам Git и Git опробовать различные идеи в качестве системы управления экспериментами.

Однако есть проблемы с этими решениями в стиле git. Git не масштабируется для хранения большого объема данных. Он отслеживает неизменяемые файлы и не сохраняет различия между ними. Наконец, он не может отвечать на запросы о путешествиях во времени по данным в форме «дайте мне значение этой функции, как это было на 1 января».

Путешествие во времени - необходимая возможность для поддержки разработки дополнительных функций. Озеро транзакционных данных предоставляет эту возможность, сохраняя версии схемы и данных в виде транзакций. Это позволяет вычислять функции, которые изменились за определенный период времени. Распространенными озерами транзакционных данных являются Delta lake (Databricks) и Apache Hudi.

Возможность управления версиями данных в хранилище функций является предварительным условием для реализации MLOps, точно так же, как управление версиями кода требуется для практики DevOps.

2.3 Конвейеры данных

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

Концепция извлечения / преобразования / загрузки (ETL) используется предприятиями в мире аналитики, бизнес-аналитики и отчетов и развивалась в последние десятилетия с развитием инженерии данных и больших данных. Автоматическое преобразование необработанных данных в функции может выполняться по расписанию или с помощью триггеров.

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

Выбор технологии и инструмента, обеспечивающего эту функциональность, имеет решающее значение, поскольку это зависит от конвейера машинного обучения. Традиционно для озер данных на основе hadoop имелся менеджер рабочего процесса, такой как Oozie или Azkaban, для выполнения таких действий. Такие проекты, как Airflow и Luigi, доминировали в этом пространстве, предоставляя независимый инструмент за пределами экосистемы hadoop, поскольку компании перемещали свои данные и рабочие нагрузки в облачные озера данных. В настоящее время Airflow является ведущей системой управления рабочими процессами по обработке данных.

2.4 Маркировка данных

Помеченные данные часто требуются для разработки моделей машинного обучения. Когда эти помеченные данные недоступны, может потребоваться действие по маркировке данных в рамках проекта машинного обучения для создания начального набора данных для обучения. В рамках группы Prosus наш рекламный бизнес OLX определил важность маркировки также в конце конвейера машинного обучения. Например, группа модерации OLX помечает аккаунты, которые помечены как мошенники. По сути, они проверяют предсказанные метки моделей обнаружения мошенничества, настраивая набор наземных данных для следующих итераций CT.

Механизмы аннотирования данных таким образом могут быть следующими:

  • внутренний по отношению к организации
  • автоматические сквозные модели
  • через внешний, государственный или частный краудсорсинг

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

В сфере краудсорсинга многие компании предлагают маркировку данных как услугу, например, scale.com и Sagemaker Groundtruth. Часто их бизнес-модель также использует эти данные для обучения моделей, которые могут автоматизировать процесс маркировки. В качестве более традиционного метода Amazon Mechanical Turk и другие аналогичные сервисы предлагают просто рынок, где работники встречаются с запросчиками.

2.5 Репозиторий функций и обнаружение данных

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

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

Портфельные компании Prosus достаточно зрелы в этом отношении, что отражает серьезность отношения к управлению данными. В OLX инструмент каталога данных представляет собой портал управления обнаружением и доступом, который также выполняет функции классификации данных, подписки на данные и потока утверждения; следовательно, он построен и обслуживается по индивидуальному заказу. В iFood, нашем подразделении по доставке еды в Бразилии, внедрение Амундсена помогло организации перейти от курируемой зоны, основанной на чтении документов, к более структурированной базе знаний на основе графиков.

3. Программа обучения

3.1 Управление моделью и экспериментом

Управление моделями и экспериментами связано с отслеживанием происхождения моделей, различных версий и ключевых событий для моделей машинного обучения. Это обеспечивает воспроизводимость, обеспечивает визуальное исследование моделей и результатов, позволяет сотрудничать и, в конечном итоге, непрерывное обучение. Примером происхождения модели являются события, например, когда модель была обучена, создана, развернута, переоценена, переподготовлена, опубликована в каталоге, а также версия модели, теги и описание. Теги этих событий могут быть аннотациями, такими как проект, пользователь, отметка времени и сведения об исходных / обновленных значениях. Кроме того, следует сохранять конкретную информацию для обучения модели, такую ​​как переменные, свойства, скоринг, показатели производительности, история, функция и местоположение.

Реализация обычно осуществляется с помощью библиотек, которые предлагают запись и извлечение таких метаданных, связанных с рабочими процессами разработчика машинного обучения и специалистов по данным. Такая библиотека является неотъемлемой частью платформы машинного обучения; в эталонной архитектуре TFX это называется ML-метаданные (MLMD). Эта функция поддерживается базой данных и API для записи и получения метаданных. Помимо программного взаимодействия с этим набором данных через API, информационная панель также поддерживает визуальное исследование.

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

Для поддержки этой функции существует множество инструментов. Некоторые инструменты с открытым исходным кодом ориентированы на отслеживание экспериментов, такие как Sacred и DVC, до коммерческих и облачных решений, таких как Weights & Biases, Comet и Neptune. Управление экспериментом, обобщенное как управление моделями, также рассматривается как функция ML-платформ, таких как Kubeflow, Polyaxon, Pachyderm, IBM Watson Studio, Microsoft MLOps, Databricks MLflow и H2O.

3.2 Конвейерная оркестровка

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

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

Для реализации стратегии выполнения используется концепция планировщика, механизма рабочего процесса для организации параллельных заданий. Рост технологий обработки больших данных в прошлом привел к появлению таких широко распространенных механизмов обработки данных, как Luigi, а затем и Airflow. Эти системы управления рабочими процессами основаны на центральном планировщике, который управляет выполнением подключенных работников.

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

Наша среда оркестровки, Luigi, была создана для конвейеров данных и не могла справиться с уникальными ограничениями рабочих процессов машинного обучения ⁷.

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

Учитывая наше успешное использование Airflow для работы с ETL, мы были рады использовать планировщик для этих рабочих нагрузок машинного обучения, но столкнулись с многочисленными проблемами при использовании Airflow так, как он не был предназначен для работы. ML DAG требует гораздо большей степени параллелизма задач ⁸.

Airflow и Luigi - отличные планировщики для конвейеров данных, потому что у них есть выполнение на основе задач, задания выполняются последовательно. И именно по этой причине они не подходят для конвейеров ml, где нам нужно выполнение на основе данных ⁹.

Tekton и Argo - это собственные конвейерные технологии Kubernetes, которые, как таковые, управляют своими ресурсами. Задачи Tekton или Argo DAG - это контейнеры. Развертывание DAG выполняется через API или CLI, что делает DAG декларативным. Это дает свободу быть независимым от облака, и переход к другому поставщику облачных услуг в будущем означает лишь применение декларации.

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

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

3.3 Автоматическая разработка функций, HPO и NAS

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

Автоматизация проектирования функций подразделяется как на создание, так и на выбор функций. Инструменты, которые автоматизируют разработку функций, включают инструменты функций, TPOT и TSFRESH. Эти инструменты предлагаются через библиотеки и реализованы как компоненты преобразования данных в конвейере машинного обучения.

Для конкретной задачи нам может потребоваться обучить разные модели с разными параметрами. Это наблюдается как задержка в ручном конвейере машинного обучения. Здесь идет автоматизация поиска архитектуры модели (NAS) и настройки гиперпараметров (HPO). Введение концепции AutoML призвано поддержать исследование и обнаружение той конфигурации, которая дает оптимальные результаты в конкретном случае. Вместо того, чтобы заставлять специалистов по данным думать, какую архитектуру NN или какую конфигурацию гиперпараметров использовать, они переключают свои усилия на выбор метода поиска для активности HPO или NAS. Теперь задержка связана с вычислением, так как пространство исследования велико, а процесс поиска занимает много времени.

Большинство инструментов поддерживают байесовскую оптимизацию, гипердиапазон, случайный поиск, поиск по сетке, NAS с RL, PSO и ASHA. Инструменты в этой области являются либо отдельными, либо частью универсальной платформы, коммерческими или открытыми, облачными или локальными. Их настройка требует минимальных усилий. Стоит упомянуть инструменты Featuretools, Keras-tuner, Hopsworks Maggy и Kubeflow Katib.

3.4 Распределенное обучение

Для масштабирования самого процесса обучения было введено понятие Parameter Server ¹⁰. В этом случае и данные, и рабочие нагрузки распределяются по рабочим узлам, в то время как узел сервера поддерживает глобально общие параметры, такие как обновления весов во время обучения модели NN. Первые версии платформы tensorflow добавили эту функциональность в процесс обучения, но потребовали дополнительных усилий для изменения кода обучения, чтобы использовать структуру.

Horovod от Uber упростил эту работу, используя структуру MPI для общения между сотрудниками. Последние версии инфраструктуры TF предоставляют выбор различных стратегий для выполнения действий по распространению, одновременно обеспечивая простоту использования и переключения между различными стратегиями. Платформы машинного обучения, такие как Kubeflow, Polyaxon и Hopsworks, используют эти методы и распределяют рабочие процессы в контейнерах kubernetes.

3.5 Среда кодирования и стандарты

По мере того, как новые среды разработки машинного обучения растут и вытесняют традиционные инструменты, не рекомендуется устанавливать стандарты для поддерживаемых языков / фреймворков платформы машинного обучения. Платформа должна быть достаточно модульной, чтобы поддерживать добавление новых фреймворков. Тем не менее, Tensorflow, PyTorch, MXnet и Scikit-learn являются обязательными.

Грамотное программирование по-прежнему является способом разработки моделей некоторыми специалистами по данным, которые в последнее время снова стали популярными из-за внедрения блокнотов Jupyter. Требуется возможность запускать записные книжки на платформе машинного обучения для обучения и развертывания без необходимости управления базовыми ресурсами. Совместное использование блокнотов jupyter в организации стало популярным благодаря репозиторию знаний, инструменту, созданному Airbnb для обмена историями данных в форме сообщений в блогах. Разработчиков конвейеров машинного обучения не следует принуждать к использованию записных книжек, поскольку специалисты по обработке данных с инженерным образованием с большей вероятностью будут использовать вместо них стандартные модули кода и инструменты разработки.

Изготовленные компоненты конвейеров должны быть многоразовыми, как показывает TFX. Преобразование данных или модуль перекрестной проверки в форме контейнера должны повторно использоваться другими конвейерами машинного обучения. Среда кодирования должна обеспечивать эту возможность, не имеющую отношения к используемому языку программирования или используемой структуре. Например, анализ данных может выполняться в пандах, преобразование данных с помощью Spark в Scala, обучение с помощью pytorch в Python и некоторые визуализации в ggplot в R. Для этого рекомендуется использовать контейнер в качестве модуля, реализующего каждый компонент конвейера.

Также рекомендуется структура кодовой базы, как мы наблюдаем с cookie-cutter-data-science в сообществе разработчиков ПО с открытым исходным кодом. Цель состоит в том, чтобы создавать проекты из шаблонов проектов с использованием метода строительных лесов. Это создает некоторую согласованность, позволяющую сотрудничать. Специалист по данным из одной команды может быстрее подключиться к другому проекту. Команда разработчиков платформы машинного обучения iFood разработала собственную систему шаблонов кодовой базы, которая также позволяет специалистам по данным предоставлять свои модели, под названием BruceML. Он делает больше, чем просто строительные леса для проекта, поэтому его можно сравнить с cli-инструментом arena в kubeflow.

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

Наконец, хотя базовое распределение ресурсов может быть независимым от конвейера машинного обучения и его разработчика, платформа машинного обучения должна позволять управлять своими ресурсами изнутри конвейера. Примером может служить управление ресурсами Kubernetes только определенного пространства имен проекта из записной книжки jupyter, которая реализует конвейер машинного обучения.

4. Производство

4.1 Обслуживание модели

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

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

Для оптимизации стоимости обслуживающего компонента решающее значение имеет выбор технологии хостинга. Запуск многих моделей на виртуальной машине позволяет максимально использовать ресурсы (память CPU / GPU) для запросов вывода. Запуск модели для каждого контейнера управляет распространением вывода через уровень оркестрации.

Сам обслуживающий компонент имеет возможности управления жизненным циклом модели для поддержки развертывания версий. Он специфичен для среды разработки, используемой для создания этой модели, и каждая может загружать определенные типы моделей (файлов). Единый формат модели (ONNX) пока не получил широкого распространения. Ведущими обслуживающими компонентами являются сервер модели Tensorflow, Nvidia TensorRT, Seldon и KFServing.

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

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

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

Развернутые модели часто представлены как:

  • gRPC (в основном модели, которым требуются изображения в качестве входных данных, так как они используют protobuf, надежный метод передачи Google)
  • REST (для традиционных моделей машинного обучения и NLP это универсальный способ связи на основе HTTP)
  • Микросервисы принятия решений на основе обмена сообщениями через обертки API, службы очередей и / или потоковой передачи, в основном для пакетной обработки.

Данные для скоринга обычно неструктурированы в виде изображения или текста в моделях глубокого обучения и более структурированы в виде транзакций в классических моделях машинного обучения. Надежность транспортировки больших данных (изображений, текста) требует иных протоколов передачи, чем небольших структурированных данных. HTTP и JSON предлагают простую транспортную среду, которая может быть очень дорогой при больших запросах. Протобуфер и gRPC предлагают надежное альтернативное решение для такого транспорта, которое должен поддерживать обслуживающий компонент. При выборе протокола следует учитывать источник запроса, будь то API на основе HTTP / gRPC или система на основе очередей. Последний обычно используется для пакетного вывода во многих случаях OLX.

Модель обслуживающей технологии инкапсулирует сложность:

  • Автомасштабирование
  • Сети
  • Проверка здоровья
  • Конфигурация сервера

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

Основным требованием платформы машинного обучения является возможность масштабируемого и согласованного обслуживания моделей.

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

Kubernetes - популярный выбор для сред распределенного вывода из-за его встроенных функций управления контейнером и микросервисами, таких как маршрутизация, балансировка нагрузки и декларативное автомасштабирование.

KFServing позволяет бессерверный логический вывод в Kubernetes. Он предоставляет производительные интерфейсы с высокой степенью абстракции для распространенных фреймворков машинного обучения, таких как TensorFlow, XGBoost, scikit-learn, PyTorch и ONNX, а также готовые к использованию функции прогнозирования, предварительной обработки, постобработки и объяснения.

Стек KFServing полагается на Knative для бессерверных приложений, Istio для сервисных сетей и Kubernetes для оркестровки.

Seldon Core - это модель с открытым исходным кодом, обслуживающая платформу для Kubernetes, которая встроена в такие платформы, как Kubeflow, IBM Fabric for Deep Learning (FfDL) и Red Hat OpenShift.

Предлагаемые облачные платформы машинного обучения, такие как AWS SageMaker, Microsoft Azure Machine Learning и Google AI Platform, обычно поддерживают развертывание обученных моделей одним щелчком мыши.

4.2 Валидация данных, валидация модели, оценка и мониторинг

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

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

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

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

Зрелый мир DevOps предоставляет нам лучшие инструменты для хранения, использования и визуализации метрик и журналов.

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

Запросы на вывод вместе с ответами хранятся в виде журналов. Эти журналы представляют собой текущие знания (запрос) и новые знания (ответ), что составляет суть нашего бизнеса. Для хранения и анализа журналов эту функцию могут предоставить как решения с открытым исходным кодом, так и коммерческие решения, такие как стек ELK и Splunk. Для каждой из этих операций оценки (или вывода) (следовательно, метрики и записи в журнале) должна быть ссылка на метаданные используемой модели. Современные платформы собирают эти журналы в виде событий, следуя спецификации Cloudevents. Такие события могут доставляться через различные стандартные протоколы (например, HTTP, AMQP, MQTT, SMTP), протоколы с открытым исходным кодом (например, Kafka, NATS) или протоколы, зависящие от платформы / поставщика (AWS Kinesis, Azure Event Grid). В универсальные платформы интегрированы инструменты с открытым исходным кодом.

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

Вопросы, которые могут возникнуть у специалиста по данным при наблюдении за моделью в производстве, включают:

  • Какое среднее / стандартное значение полученных прогнозов?
  • Какова относительная частота различных значений, которые может принимать категориальная переменная X?

4.3 Стратегии развертывания

Платформы могут помочь обеспечить безопасное и эффективное развертывание модели за счет

  1. автоматизация внедрения поэтапных развертываний и
  2. управление онлайн-экспериментами

Эти два имеют прямые аналоги со стратегиями развертывания, которые команды DevOps дорабатывают для поддержки безопасного развертывания микросервисов. Следующие три метода основаны на механизмах автоматического развертывания модели с учетом версий, а также на функциях балансировки нагрузки и управления трафиком, предоставляемых платформой.

  1. A / B-тестирование позволяет тестировать конкурирующие модели на реальном трафике.
  2. Сине-зеленое тестирование позволяет быстро откатить новые модели, которые не работают при развертывании.
  3. Развертывания Canary позволяют тестировать новые модели с небольшими объемами трафика, пока они не будут проверены.

Платформа развертывания обрабатывает входящий в модель трафик с помощью стратегии. Это может быть полный производственный трафик, его часть или зеркало. Самый простой способ - переключить трафик запросов на новую версию модели. Расширенное управление выбором между различными версиями модели вводится со стратегией развертывания. Стратегии развертывания включают сине-зеленые развертывания, A / B-тестирование и канареечные выпуски. Синий / зеленый - метод развертывания, используемый для создания полноценного образа производства с новыми версиями компонентов и переключения трафика, когда он будет готов. Стратегия A / B-тестирования ориентирована на эксперименты с новыми функциями. В canary новая версия модели выпускается для небольшого набора запросов на вывод, и результаты отслеживаются для выявления отличий от предыдущей версии. Эти три стратегии также могут сосуществовать.

Как обсуждалось ранее при обслуживании модели, сервисная сетка - это современный способ реализации этих стратегий. Ведущими сервисными сетками являются Istio, Linkerd и Consul. Сравнительную таблицу с характеристиками сервисной сетки можно увидеть в репозитории weaveworks flagger.

Заключение

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

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

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

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

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

Kubeflow позиционируется как способ заниматься машинным обучением в Kubernetes за счет реализации TFX. Он предоставляет среду кодирования, реализуя записные книжки jupyter в форме ресурсов kubernetes. Поставщики облачных услуг также участвуют в этом проекте и реализуют свои механизмы загрузки данных в компонентах KF. Оркестровка осуществляется через конвейеры KF, а обслуживание модели через службу KF. Метаданные его компонентов указаны в спецификациях ресурсов Kubernetes по всей платформе.

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

Я хотел бы поблагодарить моих коллег из команды Prosus AI за их предложения и помощь в структурировании этого в формате сообщения в блоге. Не стесняйтесь задавать вопросы / предлагать предложения в разделе комментариев или пишите нам по адресу [email protected].