Часть 1: Почему и что

«Ну вот, опять модное слово».

У меня была эта мысль, когда я впервые написал заголовок для этого поста в блоге, и, возможно, то же самое произошло и с вами.
Это может быть связано с тем, что за последние несколько лет в области данных и ИИ появилось много новых терминов (MLOps, DataOps, AIOps, Data Mesh и другие). В то время как для некоторых из них до сих пор неясно, что они означают, для других принципы и лучшие практики постепенно появляются и становятся всемирно признанным стандартом.

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

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

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

Первый пост отвечает на следующие вопросы:

  • Зачем нам нужно расширять MLOps другими концепциями, такими как ML Mesh?
  • Что такое ML Mesh и каковы его основополагающие принципы?

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

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

Могут ли MLOps решить проблемы масштабируемости машинного обучения на уровне организации?

Чтобы ответить на этот вопрос, давайте приведем пример решения MLOps, успешно реализованного в туристическом онлайн-агентстве TourStay (ChatGPT любезно предоставил название компании), которое позволяет клиентам бронировать отели по всему миру через веб-приложение, поддерживаемое платформой данных.

TourStay использует машинное обучение для улучшения пользовательского опыта клиентов за счет:

  • Механизмы рекомендаций: настройка предложений на основе специфики клиента;
  • Чат-боты: используйте Генеративный ИИ для создания круглосуточных помощников клиентов на основе ИИ;
  • Персонализация UX: адаптируйте пользовательский интерфейс веб-сайта для нескольких сегментов клиентов.

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

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

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

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

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

Благодаря этой платформе команда специалистов по персонализации данных UX теперь может надежно внедрять модели персонализации изображений в производство!
Было измерено, что время развертывания моделей машинного обучения в производстве сократилось на 70 %. Заинтересованные стороны бизнеса очень довольны этим первым успехом и хотят масштабировать решение, которое будет принято другими группами специалистов по обработке и анализу данных.

В этот момент автоматически возникает вопрос: «Как мы это делаем?».
Есть еще много вопросов, которые поднимает последний:

  • Как мы присоединяемся к другим текущим и будущим командам по науке о данных?
  • Какие среды они собираются использовать? Те же самые среды, которые использует команда специалистов по персонализации UX?
  • Будет ли эта платформа централизованной? Если да, то должны ли мы выделить команду инженеров MLOps для улучшения и поддержки платформы для всех текущих и будущих групп специалистов по обработке и анализу данных?
  • Используются ли одни и те же компоненты этой архитектуры для производственной реализации всех моделей во всей организации?
  • Кому принадлежит эта платформа?
  • Как мы можем обеспечить правильное управление различными моделями?
  • Как гарантировать, что команды специалистов по обработке и анализу данных не будут «изобретать велосипед»?

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

Мой ответ на эти вопросы — ML Mesh.

ML Mesh: определение и принципы

ML Mesh можно рассматривать как расширение MLOps с принципами Data Mesh. В частности, мы абстрагируем принципы сетки данных и адаптируем их к контексту машинного обучения. Это не просто операция «Копировать и вставить», поскольку сценарий и основные мотивы, лежащие в основе этих двух концепций, совершенно разные.

Не все читатели могут быть знакомы с Data Mesh. В связи с этим я буду представлять принципы ML Mesh, практически не упоминая Data Mesh, когда это возможно. Я напишу будущий пост в блоге, в котором будут описаны различия, общие черты и точки интеграции. Если вы хотите узнать о Data Mesh подробнее, предлагаю прочитать книгу Жамака.

ML Mesh определяется как набор методов, направленных на децентрализацию и масштабируемое распределение прав собственности на процессы MLOps по всей организации.

Этими принципами являются «ML как продукт», «Самостоятельная платформа ML» и «Распределенное владение»,описанные в следующих разделах.

Машинное обучение как продукт

Определение

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

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

Более того, авторы статьи уже используют термин «продукт машинного обучения» при определении MLOps:

«MLOps (Machine Learning Operations) — это парадигма, включающая такие аспекты, как передовой опыт, наборы концепций, а также культура разработки, когда речь идет о сквозной концептуализации, реализации, мониторинге, развертывании и масштабируемости. продуктов машинного обучения».

Они также заявляют, что

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

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

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

Атрибуты продукта машинного обучения

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

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

Индикаторы могут быть:

  • стоимость обучения/развертывания/вывода;
  • время отклика вывода;
  • показатели качества модели и дрейфа смещения;
  • метрики оценки модели;
  • версии модели;
  • бизнес-метрики;

Безопасный
Продукт машинного обучения является безопасным, если:

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

Надежный
Надежный продукт машинного обучения удовлетворяет следующим требованиям:

  • Справедливость: Можете ли вы подтвердить, что модель машинного обучения не обеспечивает систематического невыгодного положения какой-либо группе людей по сравнению с другой в зависимости от таких факторов, как пол, ориентация, возраст или этническая принадлежность?
  • Объяснимость: Можете ли вы объяснить, почему модель приняла конкретное решение? Например, если кто-то подает заявку на получение кредита, банк должен иметь возможность четко объяснить, почему это лицо было отклонено или одобрено.
  • Конфиденциальность: существуют ли надлежащие правила и политики для доступа разных людей к данным на разных этапах жизненного цикла ИИ?
  • Надежность: постоянно ли ведет себя модель при изменении условий? Это масштабируемо? Как вы приспосабливаетесь к дрейфующим шаблонам данных?
  • Прозрачность: есть ли у вас все факты, относящиеся к использованию модели? Захвачены ли они на разных этапах жизненного цикла и легко ли доступны?

Совместимость
Совместимость позволяет:

  1. Интеграция продуктов машинного обучения с другими системами, такими как веб-приложения;
  2. Объединение продуктов ML последовательным или параллельным способом для решения бизнес-задачи;

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

Например, давайте рассмотрим популярный вариант использования «Ответы на вопросы» с использованием LLM (больших языковых моделей) при применении подхода RAG (расширенная генерация поиска).
Мы используем как минимум две модели:

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

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

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

Продукт ML как квант архитектуры: мост между ML Mesh и MLOps

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

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

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

Код:

  • Эксперименты (например, тетради)
  • Обучение (например, код для создания модели, выполнения предварительной обработки, обучения/настройки, оценки)
  • Развертывание (например, код для упаковки и развертывания модели и обеспечения ее доступности через API)
  • Вывод (например, код для использования модели)
  • Мониторинг (например, код для мониторинга дрейфа смещения и качества)
  • Оркестровка (например, конвейеры)
  • Политики как код (реализуйте политики как код для применения к каждому продукту ML)
  • Интерфейсы как код: обеспечивают доступ к документации, метрикам, SLO, версиям модели, используемым конечным точкам модели и т. д.
  • Инфраструктура как код: позволяет создавать, развертывать и отслеживать код модельного продукта (например, экземпляры, на которых выполняются задания предварительной обработки/обучения/развертывания/мониторинга).

Метаданные:

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

Артефакты:

  • Артефакты модели
  • Другие (например, выходные данные предварительной обработки данных)

Если вы посмотрите на компоненты, определенные в логической архитектуре MLOps, показанной на рисунке 1, вы заметите, что почти все они включены в структурные элементы кванта архитектуры ML.

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

Применение функций и процессов разработки функций

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

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

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

К счастью, литература уже предлагает способ рассматривать признаки как продукт данных. И конкретное определение продукта данных, о котором я говорю, описано в подходе сетка данных. Более того, кажется, что они очень хорошо сочетаются друг с другом (кто бы мог подумать!).
Внедрение продуктов данных путем внедрения подхода Data Mesh — это лишь одно из различных решений.

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

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

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

Структура продуктовой команды машинного обучения

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

Платформа самообслуживания ML

Определение

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

Могут возникнуть различные проблемы, такие как:

  • Дублирование усилий при создании продуктов ML децентрализованным способом;
  • Отсутствие информации о продуктах ML с точки зрения стоимости, владения, удобства использования и ценности для бизнеса;
  • Для доступа к продуктам машинного обучения и их использования могут использоваться разные стандарты;

Принцип самообслуживания платформы машинного обучения решает эти проблемы, определяя платформу, которая:

  • Дает возможность командам разработчиков машинного обучения создавать и поддерживать высококачественные продукты машинного обучения быстрым, беспрепятственным и автономным способом;
  • Позволяет заинтересованным сторонам бизнеса и техническим командам иметь управляемое и централизованное представление о каждом продукте ML и его деталях;
  • Определить глобальный стандарт для доступа и использования продуктов машинного обучения;

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

В зависимости от стратегии организации платформа может быть реализована в виде

  • Единая и тесно интегрированная платформа, часто продаваемая основным поставщиком или сочетанием различных технологий;
  • С открытым исходным кодом или продается другими поставщиками;

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

Интерфейсы

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

Создать продукт машинного обучения
Команды разработчиков машинного обучения должны иметь возможность быстро настроить продукт машинного обучения, используя интерфейс «Создать продукт машинного обучения». В этом случае пригодится понятие «шаблон».

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

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

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

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

Эта операция должна выполняться только старшими и ведущими ролями. Этого можно достичь путем создания политик в виде кода (часть элементов структуры кода продукта ML).

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

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

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

Распределенное владение

Определение

Очень важно определить границы владения между платформой ML и продуктами ML.

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

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

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

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

Связь между продуктом и платформой машинного обучения

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

Командная перспектива
Центральная часть — это команда платформы, а периферийные — команды разработчиков.

Концентратор:

  • Создает и публикует шаблоны;
  • Предоставляет интерфейсы для создания продуктов машинного обучения и взаимодействия с ними;
  • Предоставляет наборы инструментов для ускорения создания продуктов машинного обучения и предотвращения дублирования усилий;

Лучи взаимодействуют с концентратором, используя интерфейсы, описанные в предыдущем разделе.

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

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

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

Обратите внимание, что «команда ML Product Team A» владеет «ML Product 1» и «ML Product 2». Они соединены вместе, чтобы составить продукт машинного обучения более высокого уровня.

Распределенная собственность и организационная структура

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

Не имеет смысла указывать конкретную структуру, полностью совместимую с ML Mesh, но минимальным требованием будет использование функций бизнес-подразделений, которые сопоставлены с командами продуктов ML.

Выводы

В этом посте представлена ​​новая концепция под названием ML Mesh, которая направлена ​​на масштабируемую децентрализацию практики MLOps в организации.

Мы начали с того, что поставили перед собой задачу: в настоящее время нет практик, объясняющих, как масштабировать MLOps для использования многими различными группами специалистов по данным в организации.
Предлагаемое решение этой проблемы — ML Mesh. В посте были представлены ML Mesh и его принципы: «ML как продукт», «Самостоятельная платформа ML» и «Распределенное владение».

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

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

Чего не хватает, так это изложить эти практики на бумаге, и ML Mesh может заполнить этот пробел.

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