млн операций в секунду

Обзор жизненного цикла машинного обучения

Эволюция жизненного цикла ML от пакетного анализа данных с ограниченными ресурсами до MLOps в облачном масштабе

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

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

Основные этапы интеллектуального анализа данных/науки остались более или менее такими же:

  1. Понять проблему домена или бизнеса
  2. Собирайте необходимые данные из различных источников.
  3. Проверить данные, очистить и пометить их
  4. Преобразуйте данные, согласуйте их и придайте им форму.
  5. Исследуйте и визуализируйте данные
  6. Обучайте модель, проверяйте ее и настраивайте гиперпараметры.
  7. Использовать или развернуть модели

Но природа данных, обработки и приложений значительно изменилась:

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

Эволюцию можно условно разделить на 3 эпохи (временные линии перекрываются):

  • Эра пакетной обработки: конвейеры ETL доставляли данные из операционных систем в хранилища данных и витрины данных, после чего данные извлекались.
  • Эра больших данных. Данные стали слишком большими для складов того времени. Данные текли в озера данных, которые часто превращались в болота. Только несколько организаций внедряют онлайн-модели.
  • Эпоха MLOps: упрощение непрерывного развертывания онлайн-моделей для всех.

оглавление

Пакетная эра

Можно назвать это древними временами. Интернет все еще находился в зачаточном состоянии. Большинство корпоративных приложений генерировали и обрабатывали данные пакетами.

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

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

Данных было не так много. РСУБД с индексами, ориентированными на столбцы, оказались удобными, и OLAP-кубы правили днем.

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

KDD: обнаружение знаний в базе данных

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

  1. Выбор: выбор набора данных, подмножества переменных или образцов данных.
  2. Предварительная обработка: очистка данных, обработка отсутствующих значений и т. д.
  3. Преобразование: выбор функций и проекция параметров для уменьшения эффективного количества переменных.
  4. Интеллектуальный анализ данных. Применение определенного метода интеллектуального анализа данных, например, обобщение, классификация, регрессия, кластеризация.
  5. Интерпретация и оценка: извлечение шаблонов/моделей, отчет о них вместе с визуализацией данных.

Современные конвейеры данных имеют примерно такие же шаги.

CRISP-DM: общеотраслевой стандартный процесс интеллектуального анализа данных

Затем появился процесс CRISP-DM (Модель CRISP-DM: новый план интеллектуального анализа данных Колина Ширера, 2000 г.), который остается влиятельным даже сегодня (CRISP-ML(Q)). В нем описывается, как аналитики данных должны исходить из потребностей бизнеса, анализировать данные и развертывать модель. Он разбивает процесс интеллектуального анализа данных на шесть основных этапов:

  1. Понимание бизнеса: определение бизнес-целей. Оцените ресурсы, требования, ограничения, риски и непредвиденные обстоятельства. Определите цели интеллектуального анализа данных и составьте план проекта.
  2. Понимание данных. Соберите исходные данные, изучите их и проверьте качество данных.
  3. Подготовка данных. Выберите и очистите данные. Добавьте производные атрибуты и сгенерированные записи. Объедините данные и сформируйте их в соответствии с желаемой схемой.
  4. Моделирование. Создайте модель и оцените ее качество.
  5. Оценка. Проверьте построение модели, чтобы убедиться, что она достигает заявленных бизнес-целей.
  6. Развертывание. Создайте отчет или внедрите повторяемый процесс интеллектуального анализа данных на предприятии. Планируйте мониторинг результатов интеллектуального анализа данных и обслуживание процесса синхронизации данных.

«Развертывание» — это то, где он опередил свое время. Не было возможности развернуть модель как функцию вывода. В нем говорится (клиент здесь относится к заказчику аналитиков, то есть к бизнес-организации/менеджерам):

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

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

SEMMA: выборка, исследование, изменение, моделирование и оценка

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

  1. Образец. Образец и выбор данных для моделирования.
  2. Изучение. Визуализируйте данные, чтобы обнаруживать ожидаемые и непредвиденные связи между переменными данных и выявлять аномалии.
  3. Изменить. Выберите и преобразуйте переменные данных, чтобы подготовить данные для моделирования.
  4. Модель. Применение различных методов моделирования для подготовки данных.
  5. Оценка. Оцените и сравните эффективность моделей.

Стадии SEMMA, по-видимому, находятся где-то между KDD и CRISP-DM.

Эпоха больших данных

Данные обладают сверхъестественной способностью перерастать любые технологии хранения и обработки. Появились большие данные, а хранилищ данных стало недостаточно для обработки огромного количества данных, которые генерировались предприятиями. Итак, мы изобрели Data Lake (репозиторий больших двоичных объектов) для хранения необработанных файлов данных в любом масштабе. Это привело к переходу от «схемы при записи» к «схеме при чтении».

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

Можно назвать это средневековьем. Масштабы анализа данных и бизнес-аналитики выросли многократно. Data Scientist стал самой сексуальной профессией.

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

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

OSEMN: Obtain, Scrub, Eexplore, Mmodel и IN. сильный> интерпретировать

Хилари Мейсон и Крис Виггинс описали процесс OSEMN в сообщении блога Таксономия науки о данных (от 25 сентября 2010 г.). Он состоит из 5 этапов: Поиск, Поиск, Изучение, Моделирование и I Н интерпретировать.

  1. Получить: указывание и щелчок не масштабируются.
    Сканируйте или используйте API для автоматизации сбора данных.
  2. Клиника: мир — грязное место.
    Ваша модель тоже будет грязной, если вы не очистите и не канонизируете данные.
  3. Исследуйте. Взглянув, вы многое увидите.
    Это то, что мы делаем в исследовательском анализе данных (EDA).
  4. Модели: всегда плохие, иногда уродливые.
    Оптимизируйте выбранную функцию потерь и выберите лучшую с помощью перекрестной проверки.
  5. Интерпретировать: Целью вычислений является понимание, а не числа.
    В отличие от арифметики, статистические результаты требуют тонкой интерпретации.

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

TDSP: жизненный цикл командного процесса обработки данных Microsoft

Жизненный цикл Team Data Science Process (TDSP) Microsoft состоит из четырех этапов:

  1. Понимание бизнеса
  2. Сбор и понимание данных
  3. Моделирование
  4. Развертывание

Этапы «Сбор и понимание данных» и «Моделирование» далее разбиты на более подробные этапы. Он задуман как модель водопада, заканчивающаяся принятием клиентов, но не требует большого воображения, чтобы сделать его интерактивным.

В значительной степени это то, чему в настоящее время сознательно или неосознанно следует большинство компаний.

В докладе на конференции ICSE-SEIP 2019 Saleema Amershi, et al. от Microsoft Research описывают 9 этапов рабочего процесса машинного обучения, который отличается от TDSP:

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

Эпоха MLOps

Подъем DevOps характеризует современную эпоху. Когда организации регулярно внедряют модели машинного обучения в производство как часть своих программных приложений/продуктов, им необходим процесс обработки данных, соответствующий лучшим практикам непрерывной интеграции и непрерывной доставки (CI/CD) DevOps. Именно это подпитывает ажиотаж вокруг MLOps.

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

ML встречает DevOps: 3 цикла

Очевидный способ смешивания ML с DevOps — создать цикл MLOps, добавив ML к бесконечному циклу DevOps и адаптировав Dev и Ops к науке о данных.

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

Есть и другие попытки создания петли MLOps с тремя обручами. Например, следующее описывает 3 широких этапа Итеративно-инкрементный процесс MLOps имеет три широких этапа (которые все еще являются грубыми IMO):

Цикл Data-ML-Dev-Ops

В сообщении в блоге Дэнни Фараха описаны 4 цикла жизненного цикла MLOps, по одному для данных, машинного обучения, разработки и эксплуатации. Мне нравится по двум причинам:

  • Он сохраняет детали данных и шагов ML
  • Это кажется более знакомым w.r.t. бесконечный цикл DevOps.

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

Облако Google

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

Google, возможно, является первым и крупнейшим магазином машинного обучения с платформой Vertex AI MLOps. В мае 2021 года он опубликовал технический документ под названием Руководство для практиков по MLOps. Я цитирую раздел жизненного цикла MLOps из технического документа, в котором описаны следующие части:

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

Веб-сервисы Амазонки

Amazon первой предложила сквозную платформу MLOps: SageMaker. В июне 2022 года компания опубликовала технический документ MLOps: новые тенденции в данных, коде,
и инфраструктуре, технический документ AWS, в котором определяется гораздо более простой жизненный цикл. Это настолько просто, что не требует пояснений. Это больше похоже на KDD и CRISP-DM, чем на цикл DevOps.

Microsoft Azure

В августе 2021 года Microsoft также опубликовала технический документ MLOps «MLOps with Azure Machine Learning», определяющий жизненный цикл машинного обучения и рабочий процесс MLOps. Это похоже на AWS: просто и понятно.

Мой взгляд на жизненный цикл машинного обучения

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

Во-первых, каковы ключевые характеристики жизненного цикла ML в эпоху MLOps?

  • Эволюционный, а не революционный. Он должен быть знаком специалистам по данным, которые до сих пор используют CRISP-DM, OSEMN или TDSP. Это также должно быть знакомо инженерам, использующим бесконечный цикл DevOps.
  • Оптимизирован для запоминания, а не точности. Легко запоминающийся процесс с большей вероятностью станет частью словарного запаса команды. Например, бесконечный цикл DevOps не является точным. Каждый шаг имеет несколько неявных стрелок возврата к предыдущим шагам. Не все после Теста ведет к Освобождению. Неудачи возвращаются к шагу Кодекса или даже Плана.
  • Облегчает внедрение модели машинного обучения в производство. Это должно улучшить прозрачность и совместную работу команды разработчиков, специалистов по данным и инженеров данных, особенно мою философию консолидации владения, ранней интеграции и частых итераций.
  • Гибкий. Он должен позволять частям команды выбирать свою частоту. Наука о данных и разработка программного обеспечения по своей сути разные. Специалисты по данным не могут ежедневно получать дополнительные результаты. Целью жизненного цикла и процесса является наглядность и сплоченность, а не трехэтапная гонка.

Цикл разработки модели

Если вы проигнорируете развертывание, у разработки модели будет бесконечный цикл, как и у цикла DevOps.

Представьте CRISP-DM в виде бесконечного цикла. Шаги в цикле разработки модели:

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

Собираем все вместе

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

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

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

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

Краткое содержание

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

Рекомендации

Если вам понравилось, пожалуйста:

Первоначально опубликовано на ML4Devs.com.