Я наткнулся на технический документ MLOps: Emerging Trends in Data, Code, and Infrastructure (от AWS/Sequoia) несколько недель назад, и когда я прочитал его, я подумал: Хорошо, это имеет смысл.
Это нашло отклик у меня и во многих местах хорошо описывало то, о чем я думал в течение некоторого времени. Это также во многом соответствует тому, как мы думаем о создании и использовании инструментов машинного обучения в Neptune.
Я решил поделиться с вами самыми важными знаниями. Мне любопытно узнать, что другие думают об этих моментах. Был бы рад поговорить об этом подробнее.
Итак, поехали.
1. Цель не создание инфраструктуры, а внедрение моделей в производство.
(Да, решил начать с чего-то столь очевидного.)
Вам нужны модели в производстве.
Но вы не хотите строить инфраструктуру.
Итак, вы выбираете сквозную облачную платформу (например, Sagemaker).
Одна из больших проблем сквозных платформ?
Вы хотите настроить компоненты стека в соответствии со своим вариантом использования.
Но деловые люди не хотят, чтобы вы работали над деятельностью, которая не является «основными проблемами бизнеса».
Вещи, которые не создают долгосрочной дифференциации.
Ну так что ты делаешь?
Как объясняет Вин Шарма из AWS в «MLOps: новые тенденции в данных, коде и инфраструктуре»:
«Сегодня настройка различных компонентов жизненного цикла машинного обучения может быть очень ручной, и специалисты-практики в основном используют подход «сделай сам».
Предприятия предпочитают некоторую степень абстракции от базовых функций и оборудования на каждом этапе процесса моделирования. У них нет собственных ресурсов или они не хотят инвестировать в собственные ресурсы для индивидуальной настройки основных функций, таких как маркировка данных, отслеживание экспериментов, мониторинг моделей и т. д.».
Давайте посмотрим правде в глаза.
Вы не будете продвигать бизнес вперед в долгосрочной перспективе, взламывая компонент оркестровки конвейера или решение для развертывания модели. Или трекер экспериментов, если уж на то пошло.
Это может быть классный проект, но с точки зрения «долгосрочного бизнеса» он не выдерживает никакой критики.
Решение, по словам Вин, а не меня (ок, я тоже это вижу :) ), таково:
«Мы видим, что организации выбирают лучшие в своем классе решения от специализированных поставщиков, чтобы получить дополнительный контроль над своим рабочим процессом моделирования, не беспокоясь о том, что происходит «под капотом».
В общем, то, что Якопо Тальябуэ уже давно говорит, объясняя ML/MLOps в разумных масштабах.
«Чтобы быть продуктивным в машинном обучении в разумных масштабах, вы должны инвестировать свое время в свои основные проблемы (какими бы они ни были) и покупать все остальное».
Если это не ваш основной бизнес, и есть решения, которые делают то, что вы хотите (или вы ожидаете, что они смогут делать то, что вы хотите в ближайшее время), -› не создавайте его самостоятельно.
Я знаю, что трудно устоять, потому что «вы можете создать v1 за выходные».
Вы, наверное, могли бы.
Но тогда вам нужно будет исправлять, поддерживать, документировать, обновлять, улучшать, создавать резервные копии и т. д.
Это ваше время, о котором мы говорим здесь.
Это то, за что бизнес платит большие деньги.
Не ежемесячные подписки SaaS или корпоративные контракты.
Используйте свое время с умом.
Если это означает создание трекера экспериментов — отлично.
Но чаще всего аутсорсинг поставщику является правильным выбором для бизнеса… и для вас.
2. Люди хотят иметь возможность настраивать свою инфраструктуру машинного обучения
Начнем еще раз с того же.
Вам нужны модели в производстве.
Но вы не хотите строить инфраструктуру.
Итак, вы выбираете сквозную облачную платформу (например, Sagemaker).
Но у вас есть особые требования и вам нужно настроить свой стек MLOps.
Таким образом, вы в конечном итоге заменяете компоненты своей комплексной платформы и комбинируете поставщиков, инструменты с открытым исходным кодом, собственные инструменты и предложения облачных провайдеров.
Хотите пример?
Ну вот:
- Brainly использовала сквозную платформу Sagemaker. Они были довольны этим.
- Они начали активно экспериментировать с CV-моделями.
- Они поняли, что им нужно более глубокое решение для компонента стека отслеживание экспериментов.
- Они заменили эксперименты Sagemaker на лучшее в своем классе точечное решение Neptune.
- Они с удовольствием используют и Sagemaker, и Neptune.
Если сквозная платформа спроектирована так, чтобы быть открытой, это не «или-или». Это «и то, и другое».
Вот вся история, если интересно.
Как объясняет Вин Шарма в «MLOps: Emerging Trends in Data, Code, and Infrastructure»:
«Для любой организации, которая хочет получать прибыль от бизнес-приложений для предметной области или курируемых наборов данных, базовая платформа машинного обучения и усилия по управлению ее инфраструктурой являются лишь средством для достижения цели и потенциально представляют собой тяжелое бремя без каких-либо различий.
Платформы Cloud ML предоставляют управляемые услуги, которые просты в использовании по более низкой цене для таких организаций.
…
Однако эти сквозные услуги не удовлетворяют потребности многих клиентов с более специализированными требованиями.
Поэтому они решили внедрить платформу машинного обучения, состоящую из лучших в своем классе продуктов от поставщиков, открытого исходного кода, собственного кода и собственных сервисов AWS.
…
В конечном счете, этим организациям нужен детальный контроль над всем стеком, и они охотно берут на себя дополнительные сложности и затраты, связанные с эксплуатацией «сделай сам».
…
Они надеются предоставить уникальную ценность, основанную на их программном обеспечении платформы машинного обучения, базовой инфраструктуре и инженерном опыте машинного обучения».
По мере развития ваших потребностей меняется и ваш набор инструментов.
Просто поймите, что вам нужно сегодня.
Будь честен с собой.
Не создавайте все, потому что «это было в той замечательной диаграмме поста в блоге FANG» и «вам это понадобится в будущем».
Секретный ключ — это интероперабельность компонентов.
В этом разница между успехом и разочарованием при создании платформы MLOps.
В классическом споре между созданием, собственными силами или покупкой лучшего в своем классе ответ (если вы избавитесь от лишнего) почти всегда будет и тем, и другим.
В статье «MLOps: Emerging Trends in Data, Code and Infrastructure» Вин Шарма из AWS объясняет, почему это «обычно заканчивается тем и другим».
Для самостоятельного строительства необходимо:
- найти/нанять/удержать отличных (и дорогих) людей
- отличать то, что вы строите, от того, что доступно в экосистеме (иначе зачем строить?)
«Неизбежно, постоянный технический директор получает вазу с фруктами, собранную из проектов с открытым исходным кодом, проприетарных инструментов, предоставляемых поставщиком, и услуг от облачного провайдера». — Вин Шарма
Но когда вы комбинируете инструменты из экосистемы MLOps (с открытым исходным кодом или предоставленные поставщиком), у вас возникают новые проблемы.
Вам необходимо спроектировать интероперабельность модулей, которые решают определенные проблемы.
«Если не сделать это продуманно, разработчики могут обнаружить, что архитектура этих платформ лучше подходит для слайдеров, чем для программного обеспечения.
…
В конечном счете, взаимодействие между модулями становится секретным ключом к успеху или разочарованию MLOps». — Вин Шарма
Если вы добавите к этому, что большинство инструментов пересекаются в том, что они делают, и пытаются стать шире, а не глубже,
Вы попадаете в неприятную ситуацию, в которой сегодня находится инструментальная экосистема MLOps.
Одним из решений этой проблемы является использование платформ с заменяемыми компонентами.
А тут модульность…
Как объясняет Вин Шарма из AWS в «MLOps: новые тенденции в данных, коде и инфраструктуре»:
«Ведущие организации внедряют процесс машинного обучения, подобный DevOps, под названием MLOps, чтобы создать прочное и конкурентное преимущество.
Эти системы продолжают развиваться с головокружительной скоростью, при этом самые важные компоненты очевидны: модульность и функциональная совместимость».
«ожидайте, что модульные системы машинного обучения выиграют благодаря хорошей интеграции в остальную часть стека».
Модульные компоненты + хорошо справляются с одной задачей + хорошо интегрируются
Звучит мечтательно.
Но если вы посмотрите на DevOps 10–15 лет назад, где MLOps, вероятно, находится сегодня, то это реальность.
Как объясняет Соня Хуанг из Sequoia в «MLOps: Emerging Trends in Data, Code, and Infrastructure»:
«Модульность является ключевым фактором. Производственные системы машинного обучения обслуживают модели, которые являются «основными» для предприятия.
Привязка наиболее важных моделей к проприетарному поставщику, который плохо интегрируется с другими решениями, просто не работает для амбициозных организаций машинного обучения.
…
Каждый компонент должен хорошо выполнять свою роль — будь то хранилище функций или решение для мониторинга.
Таким образом, мы должны ожидать, что модульные системы машинного обучения выиграют за счет хорошей интеграции в остальную часть стека».
Именно так мы смотрим на свое место в экосистеме MLOps в Neptune.
- Быть компонентом -> Хранилище метаданных ML (отслеживание эксперимента + реестр моделей)
- Делайте одно хорошо –› мы идем глубже. Нет планов решать другие части стека MLOps.
- Хорошо интегрируйте -› 30+ интеграций и подсчет
Но,
«Модульность не исключает комплектации»
Вы по-прежнему можете быть модульным компонентом стека и делать несколько вещей.
Вам просто нужно делать каждую из этих вещей хорошо и позволить людям выбирать только те части, которые они хотят.
В «MLOps: новые тенденции в данных, коде и инфраструктуре» Соня Хуанг из Sequoia объясняет:
«Тем не менее, модульность не исключает объединения, если вы можете хорошо делать несколько вещей.
Мы видели, как компании очень хорошо обслуживают несколько частей стека машинного обучения.
Hugging Face — это пример компании, которая преуспела в нескольких частях стека машинного обучения — от поиска моделей до обучения и развертывания.
Но что важно, так это то, что у клиента есть возможность интегрировать Hugging Face со своим собственным стеком, если он захочет, или просто использовать его для одного компонента.
Это требует от Hugging Face оставаться в тонусе и побеждать в каждой подкатегории, в которой она конкурирует».
Инструменты могут быть связаны, но они не должны быть связаны.
(сильно) связанное может быть проблемой, поскольку вам нужно использовать несколько инструментов от одного поставщика.
Они хорошо работают вместе, но привязывают вас к самоуверенному и ограничивающему способу ведения дел.
Комплектация означает, что вы можете выбрать то, что вам нужно.
Пакеты всегда будут несколько связаны, поскольку они лучше всего работают вместе.
Но это вкус блокировки, который кажется положительным.
AWS Sagemaker — интересный пример инструмента, который связан и в некоторой степени связан, но определенно открыт.
Мы видим, как команды (например, Brainly) меняют компонент отслеживания экспериментов на лучший в своем классе инструмент, такой как Neptune.
Мы слышали, как команды заменяют компонент мониторинга модели на точечное решение, такое как WhyLabs.
Тем не менее, многие люди считают, что Sagemaker — это очень сильно связанная сквозная платформа.
Интересно посмотреть, как это изменится со временем.
Как мы, как экосистема инструментов MLOps, поддерживаем это?
Давайте поговорим о модульности.
В недавней беседе между Стефаном Кравчиком и Чипом Хьюеном Чип отмечает, что модульные инструменты MLOps великолепны, но у нас даже нет четко определенных категорий.
И так много инструментов так сильно перекрывают друг друга, что трудно понять, где начинаются и заканчиваются категории.
Посмотрите статью THE MLOps Операции машинного обучения (MLOPs): обзор, определение и архитектура Доминик Кройцбергер, Никлас Кюль, Себастьян Хиршль.
Посмотрите на эту замечательную схему.
Возьмите практически любой компонент.
Найдите инструмент, который делает именно это.
Да, тяжело.
Модульность сложна, когда все хотят быть сквозной платформой MLOps.
А совместимость?
Хорошо, мы делаем некоторые шаги:
- такие инструменты, как ZenML для независимой абстракции конвейера,
- рост популярности концепции модельного реестра,
- открытые архитектуры сквозных платформ, таких как Sagemaker.
Так что дела идут лучше.
Но мы бы двигались намного быстрее, если бы пытались быть более модульными и интегрированными, а не охватывать большие части ландшафта MLOps.
3. «не существует единой платформы для разработки программного обеспечения «все в одном»»
Точно.
Тем не менее, сегодня в MLOps (который, как говорят люди, похож на DevOps 10+ лет назад, мы вернемся к этому через секунду), инструментальные компании строят в направлении сквозных платформ.
Почему? MLOps проще, чем DevOps?
Похоже, что разработка машинного обучения более сложна, чем разработка программного обеспечения, а не меньше.
+ во всяком случае, это расширение DevOps.
Соня Хуанг из Sequoia в статье «MLOps: Emerging Trends in Data, Code, and Infrastructure» делится:
«Посмотрите, как развивался стек разработки программного обеспечения, что, я считаю, является подходящей аналогией того, как будет развиваться ландшафт машинного обучения.
По мере роста таких поставщиков, как Atlassian, Datadog и GitHub, они приобретали все больше смежных функций.
Но единой универсальной платформы для разработки программного обеспечения не существует — клиенты по-прежнему хотят выбирать из нескольких поставщиков, которые лучше всего подходят для каждой цели — это просто слишком большая область для одного поставщика, чтобы обеспечить хорошие результаты.
…
Я считаю, что аналогичная динамика будет проявляться в машинном обучении.
Амбициозные поставщики расширят свои функциональные возможности за пределы своего первоначального клина — например, компании, обслуживающие машинное обучение, могут заняться мониторингом машинного обучения — но мы должны увидеть несколько победителей.
Лучшие компании найдут баланс.
Они невероятно хорошо работают на своем клине, имеют амбиции расширяться в смежные области, и они не слишком наивны в отношении масштабов своего проекта».
Так что да, конечно, имеет смысл объединить некоторые вещи и перейти к смежным категориям инструментов.
Мы сделали это с отслеживанием экспериментов и реестром моделей, поскольку люди продолжали запрашивать эти функции вместе. Мы объединили их вместе.
Но маловероятно, что сквозные платформы в MLOps будут иметь смысл в долгосрочной перспективе.
Если только вы не создадите его как комплексный набор слабо связанных инструментов.
Возможно, это могло бы сработать.
Но, вы должны знать, что…
4. Даже AWS Sagemaker не верит в единую сквозную платформу MLOps для всех.
Вин Шарма говорит, что командам «нужна гибкость для настройки всех компонентов модели и рабочего процесса построения модели».
Да, точно. И это хорошо для всех.
Различные варианты использования машинного обучения — потребность в гибких компонентах
В «MLOps: новые тенденции в данных, коде и инфраструктуре» он говорит:
«С появлением более сложных вариантов использования ИИ и более продвинутых специалистов по данным предприятиям больше не нужны только интегрированные системы черного ящика.
Им нужна гибкость для настройки всех компонентов их модели и рабочего процесса построения модели для получения наиболее оптимальных анализов и систем для их конкретных бизнес-потребностей.
…
В AWS мы понимаем, что командам нужна такая гибкость. Amazon Sagemaker намеренно спроектирован так, чтобы быть модульным и гибким, чтобы поддерживать команды, которые хотят работать с платформами с открытым исходным кодом.
…
Мы поддерживаем как сквозные рабочие процессы SageMaker, так и DIY».
И многие команды машинного обучения делают это.
В долгосрочной перспективе гибкость компонентов (или ее отсутствие) убивает платформы машинного обучения.
И AWS понимает это и строит его открытым, чтобы дать людям надежный старт, с которого они могут настраивать.
5. Некоторые компоненты стека просто не стоит создавать
«Клиенты рассматривают определенные продукты в конвейере MLOps как более простые в использовании, предоставляющие более широкие возможности или функциональные возможности и, возможно, даже более экономичные. “
Слово.
Мы видим, что многие команды рады принять зрелое точечное решение для чего-то, что просто не имеет смысла с финансовой или иной точки зрения для создания собственными силами.
Как делятся Тим Портер и Джон Туроу из Madrona Venture Group в «MLOps: новые тенденции в данных, коде и инфраструктуре»:
«еще больше организаций [...] захотят использовать компонуемый подход, выбирая лучшие в своем классе продукты от различных поставщиков, выборочно использовать программное обеспечение с открытым исходным кодом,
строить на гипермасштабируемой инфраструктуре и комбинировать их со своим собственным кодом, который лучше всего соответствует потребностям их бизнеса и приложений.
Иногда это связано с тем, что их данные или клиенты находятся в нескольких местах, а их приложение должно работать в нескольких облаках и даже локально.
Почти всегда это происходит потому, что клиенты считают определенные продукты в конвейере MLOps более простыми в использовании, предоставляющими более широкие возможности или функциональность и, возможно, даже более экономичными».
Сложная часть сегодня состоит в том, чтобы понять, какие компоненты являются достаточно зрелыми и достаточно очевидными для аутсорсинга.
Отслеживание эксперимента кажется хорошим кандидатом.
- Очень скучно в плане мл.
- Много работы на бэкэнде, чтобы сделать это масштабируемым и надежным.
- На рынке уже некоторое время есть несколько надежных вариантов.
Как вы думаете, какие из них являются хорошими кандидатами?
6. Итак… MLOps-стартапы, идущие от начала до конца, могут быть не лучшим направлением
Теоретически одна компания могла решить все.
Но на практике невозможно обеспечить достаточно хороший опыт разработки по всем направлениям.
Является ли неудачный опыт разработки MLOps в целом причиной того, что так много компаний сами создают инфраструктуру MLOps?
Или почему поставщики считают, что они могут широко использовать многие компоненты и делать это достаточно хорошо (или неплохо)?
Или это просто невежество?
Как делятся Тим Портер и Джон Туроу из Madrona Venture Group в «MLOps: новые тенденции в данных, коде и инфраструктуре»:
«Тенденция в MLOps заключается в том, что компании, добившиеся успеха в подкатегории MLOps, похоже, развиваются или расширяются, предлагая комплексные решения.
Однако иногда мы задаемся вопросом, является ли это ответом на притяжение клиентов или просто империализм и амбиции стартапов в более широком смысле.
Мы видели и то, и другое: если поставщик предоставляет надежное решение на «переднем конце» конвейера машинного обучения (скажем, для маркировки, обучения или создания модели), клиенты также могут захотеть его развертывания.
и управление, которое может закрыть цикл обучения.
Однако во многих других случаях мы видим, что клиентам нужна модульная система, в которой они могут объединить лучшие в своем классе решения, которые лучше всего подходят для их среды и бизнес-потребностей».
Так почему же это происходит?
Мы бы сказали, что это, вероятно, сочетание невежества и клиентов, которые просят об этом.
Вы не знаете, насколько сложно создавать каждый компонент, пока не начнете углубляться в этот компонент. К тому времени вы чрезмерно инвестируете в то, чтобы «заставить это работать».
И вы создаете что-то в 2 раза хуже, чем лучшее в своем классе точечное решение, на котором кто-то сосредотачивает 100% своего времени.
С точки зрения разработчиков, это просто «не очень хорошо» по сравнению с этим точечным решением.
Итак, вы хотите сделать его лучше. Но у вас есть этот и десять других компонентов, которые нужно улучшить.
В любом случае, в долгосрочной перспективе это, вероятно, неустойчиво.
В любом случае.
В конце концов, все мы, как компании, предоставляющие инструменты MLOps, будем просто расширением набора инструментов DevOps.
Да, сейчас самое время поговорить об этом.
7. MLOps — это как DevOps в 1990-х и начале 2000-х
Лучшие практики не ясны.
Непонятно, где заканчивается один компонент стека инструментов и начинается другой.
Причины, по которым люди носят спортивные костюмы и брюки-клеш, неясны.
Как делится Соня Хуанг из Sequoia в «MLOps: Emerging Trends in Data, Code, and Infrastructure»:
«Мы считаем, что экосистема машинного обучения напоминает экосистему программного обеспечения в 1990-х и начале 2000-х годов, до того, как DevOps как дисциплина взяла верх, а стек разработки программного обеспечения стал профессиональным и объединился вокруг таких систем, как GitHub, Atlassian и Datadog.
ML сейчас переживает момент «DevOps», когда технологические компании понимают, что им необходимо ввести в действие свои стеки ML, чтобы их команды данных и ML могли развиваться с максимальной отдачей».
Захватывающие времена, чтобы быть в MLOps как на стороне пользователя/практика, так и на стороне поставщика инструментов.
Для тех, кто помнит, каким был DevOps 20 лет назад?
Было ли тогда много сквозных платформ?
Больше инструментов, чем вы можете сосчитать, решающих почти одно и то же?
Кроме того, если MLOps похож на DevOps 10 лет назад, как, по вашему мнению, MLOps будет выглядеть через 10 лет?
Будет ли MLOps просто частью DevOps?
В конечном счете, мы помогаем командам работать с программным обеспечением. Особый тип программного обеспечения под названием ML.
Итак, говоря в долгосрочной перспективе, будет ли когда-нибудь иметь смысл иметь как DevOps, так и MLOps как отдельные команды/стеки?
В «MLOps: новые тенденции в данных, коде и инфраструктуре» Тим Портер и Джон Туроу из Madrona Venture Group говорят:
«Интересный связанный с этим вопрос заключается в том, продолжает ли MLOps существовать как отдельная категория или же она просто сводится к DevOps, поскольку почти каждое приложение становится интеллектуальным приложением, ориентированным на данные.
Мадрона считает, что эти два пространства начнут в значительной степени сближаться, но определенные уникальные потребности клиентов, характерные для MLOps, продолжат сохраняться».
Что вы думаете?
Сойдутся ли MLOps с DevOps?
Или, может быть, это всегда был DevOps, мы просто сделали его особенным :)
Кто станет Atlassian MLOps?
Конечно, сегодня MLOps только зарождается. У нас нет стандартов, нечеткие границы между категориями инструментов и т.д.
Но в какой-то момент мы достигнем зрелости.
У нас будут более очевидные пользовательские сегменты, четко определенные потребности, лучшие практики и т. д.
Будет ли тогда единая платформа, выполняющая все модульные компоненты MLOps?
Или Atlassian просто купит модульные точечные решения MLOps, чтобы иметь больший набор продуктов?
Райан Каннингем из AI Fund объясняет свою точку зрения в «MLOPs: Emerging Trends in Data, Code, and Infrastructure»:
«Ни одна компания не может владеть всеми модульными системами прямо сейчас, потому что все еще активно разрабатывают лучшие фреймворки для проведения этих операций.
Область MLOps находится в зачаточном состоянии, и это захватывающе, потому что чем больше людей будут участвовать в этих диалогах с открытым исходным кодом, тем быстрее мы придем к стандартам для разработки, развертывания и управления машинным обучением.
Мы все еще находимся в нескольких годах от единой доминирующей компании, которая станет центральным хабом для существования продукта MLOps.
В долгосрочной перспективе, по мере формализации стандартов MLOps, мы ожидаем, что более крупные игроки начнут приобретать смежные продукты и масштабироваться горизонтально.
Оттуда мы можем начать видеть полноценные платформы, подобные Atlassian».
К тому времени, когда мы достигнем зрелости MLOps, может быть ясно, что MLOps — это всего лишь часть DevOps.
Доставка программного обеспечения машинного обучения — это просто доставка программного обеспечения. Или нет.
Думаю, нам просто нужно подождать и посмотреть.
Итак, кто, по вашему мнению, станет Atlassian MLOps через 10 лет?
Я иногда делюсь своими мыслями о ландшафте ML и MLOps в моем профиле Linkedin. Не стесняйтесь следовать за мной там, если это интересная тема для вас. Кроме того, свяжитесь, если вы хотите поговорить об этом.
