MLOps переобучение. Вот почему
Причина переобучения в MLOps
Опросы VC показывают, что сегодня существует сотни компаний, которые определяют себя как часть категории MLOps.
Системы MLOps предоставляют инфраструктуру, которая позволяет специалистам по машинному обучению управлять жизненным циклом своей работы от разработки до внедрения в надежном и воспроизводимом режиме. Инструменты MLOps могут охватывать все потребности или фокусироваться на конкретной фазе (например, исследование/разработка) или артефакте (например, функции) в процессе.
Мир данных включает в себя непрерывный спектр специалистов по данным, от аналитиков, использующих в основном ad hoc SQL-запросы, до докторов наук, запускающих собственные алгоритмы.
Существует ли один подход DevOps, который универсален для всех, или МО – уникальная практика, требующая собственного подхода для обеспечения наилучших практик и соответствующей инфраструктуры?
- Как использовать API ChatGPT на Python для ваших данных в режиме реального времени
- Двенадцать стран призывают гигантов социальных сетей бороться с незаконным сбором данных
- Идеальное руководство по освоению сезонности и повышению бизнес-результатов
Чтобы ответить на этот вопрос, мы рассмотрим основы DevOps и то, что DataOps является естественным экспертизом в рамках DevOps, отвечающим потребностям специалистов по данным. Затем мы рассмотрим потребности МО и постараемся понять, отличаются ли они от DataOps и как.
И наконец, мы рассмотрим вопрос о том, сколько инфраструктуры должен управлять специалист по МО. Отличается ли это от другого специалиста по данным? Где это находится по сравнению с программными инженерами?
Этот вопрос актуален для рассматриваемого вопроса, так как он определяет необходимость предоставления инфраструктуры практикующему.
Что такое DevOps?
**”DevOps** – методология в области разработки программного обеспечения и информационных технологий. Используется как набор практик и инструментов, DevOps интегрирует и автоматизирует работу по разработке программного обеспечения (Dev) и операций IT (Ops) в качестве средства для улучшения и сокращения жизненного цикла разработки систем.”
DevOps является дополнением к гибкой разработке программного обеспечения; несколько аспектов DevOps происходят из гибкого способа работы”.
Давайте разберем. Гибкая методология является частью методологии DevOps; она полагается на возможность поддержания короткого цикла обратной связи между разработчиками продукта и пользователями.
Чтобы поддержать короткий цикл обратной связи, необходимо иметь эффективный жизненный цикл доставки программного обеспечения от разработки до внедрения в производство. Инфраструктура и инструменты, необходимые для поддержания этого процесса, лежат на ответственности команды DevOps.
Таким образом, эффективность – это главная цель.
Вкратце, основными компонентами являются:
- Среда разработки: среда разработки, которая позволяет сотрудничество и тестирование нового или измененного кода.
- Непрерывная интеграция: возможность непрерывно добавлять новый/измененный код в кодовую базу, при этом поддерживая его качество.
- Стэйджинг: для обеспечения качества системы, включая новую/измененную функциональность, перед ее внедрением в производство, создается и запускаются тесты качества в среде, похожей на производственную.
- Непрерывное развертывание: возможность развертывания новой/измененной функциональности в производственные среды.
- Мониторинг: наблюдение за состоянием производства и возможность быстро восстановить работу после возникновения проблем путем отката.
- Модульность: возможность легко добавлять компоненты, такие как новые сервисы, в производство, сохраняя стабильность и мониторинг состояния производства.
Могут существовать различные названия должностей в зависимости от структуры организации (DevOps/SRE/Production Engineering), но их ответственность остается неизменной.
Эта функция отвечает за предоставление инфраструктуры для перемещения кода от разработки в производство. Команды по разработке продукта могут участвовать в выборе некоторых инструментов, более специфичных для их экспертизы, таких как аспекты их среды разработки.
Чтобы поддержать эту цель и позволить эти гибкие процессы, программные инженеры обучаются различным инструментам, включая системы контроля версий, такие как Git, и инструменты автоматизации, такие как Jenkins, Unit и платформы интеграционного тестирования.
Любой программный инженер знает, что самая важная “на рабочем месте” тренировка, которую получают программные инженеры, связана с пониманием управления жизненным циклом приложения и работой с инструментами, поддерживающими его. Ваша производительность намного выше, когда вы овладеваете этим, и, как только вы это сделаете, это естественная часть вашей повседневной работы.
Источник: AWS
Что такое DataOps?
DataOps – это DevOps для приложений, требующих интенсивной работы с данными. Эти приложения полагаются на конвейеры данных для создания производных данных, которые являются основой приложений.
Примеры приложений, требующих интенсивной работы с данными, включают:
- Внутренние BI-системы,
- Цифровые приложения в области здравоохранения, основанные на больших наборах данных о пациентах для улучшения диагностики и лечения заболеваний,
- Возможности автономного вождения в автомобилях,
- Оптимизация производственных линий,
- Генеративные AI-движки,
- и многие другие…
Цель команды DataOps аналогична цели команды DevOps, но их стек технологий включает экспертизу в технологиях, позволяющих практикующим в области данных достичь короткого цикла обратной связи.
Эти технологии включают распределенное хранилище, распределенные вычислительные движки, распределенные системы ввода данных, инструменты оркестрации для управления потоками данных и инструменты наблюдаемости данных для обеспечения тестирования качества и мониторинга производства аспектов приложения, связанных с данными.
Вкратце, эта экспертиза позволит:
- Среда разработки: среда разработки, позволяющая сотрудничество и тестирование новых или измененных потоков данных. Инфраструктура будет включать не только управление функциональным кодом, но и кодом потоков данных и самими данными.
- Непрерывную интеграцию кода: возможность непрерывного добавления нового или измененного кода в кодовую базу
- Непрерывную интеграцию данных: возможность непрерывного добавления новых или измененных данных в набор данных.
- Тестирование на стадии подготовки: обеспечение качества системы с новой или измененной функциональностью перед ее развертыванием в производство. Это включает тестирование как кода, так и данных.
- Непрерывное развертывание: возможность автоматического развертывания новой или измененной функциональности или данных в производственных средах.
- Мониторинг состояния производства и возможность быстрого восстановления после возникновения проблем. Это включает как приложение, так и встроенные в него данные.
- Возможность легко добавлять компоненты, такие как новые службы/артефакты данных, в производство, при этом поддерживая стабильность и мониторинг состояния производства.
MLOps против DataOps
В контексте DevOps и DataOps MLOps – это случай DataOps, нацеленный на жизненный цикл ML.
Здесь нам предлагается ответить на главный вопрос этой статьи. Действительно ли MLOps отличается от DataOps? И если да, то в чем?
Поскольку приложения, основанные на ML, требуют контроля версий кода, данных и среды, оркестрации и предоставления технологий данных, их потребности в этих областях подобны потребностям других практикующих в области данных и полностью вписываются в DataOps, как это определено здесь.
То же самое относится к инструментам контроля качества данных и инструментам мониторинга данных. Хотя некоторые из этих инструментов могут быть специфичными для ML в некоторых аспектах тестирования, это не отличается от различий между инструментами разработчика C++ и разработчика JavaScript.
Мы не определяем их как отдельные категории от DevOps, не так ли?
Отметим, что необходимость в таких инструментах не вызывает сомнений, и категории контроля качества данных и мониторинга данных будут успешными, но они не изменяют парадигму DevOps или делают MLOps отдельной категорией продуктов.
И это приводит нас к реальной разнице: в среде разработки. Эта разница известна в DevOps, и она реальна.
У каждого практика в области программной инженерии есть свои специфические требования к его среде разработки. Эти требования дополняют базовый контроль версий кода и данных и хорошо настроенную тетрадь, которые требуются всем.
Например, практикующим ML требуется хорошая система управления экспериментами, хороший способ оптимизации гиперпараметров и хороший способ создания тренировочных наборов данных.
Тренировочный набор данных! О, да, это действительно разница! Ученым по данным требуется инфраструктура для хранения и управления маркировкой данных, на которых они основываются для обучения своих моделей.
Хотя некоторая часть этой инфраструктуры является общей для данных, такой как хранилище или база данных, используемые для сохранения метаданных маркировки, часть из нее крайне специфична для самого процесса маркировки и управления тренировочными наборами данных.
Оправдывает ли это создание новой категории Ops? Я не думаю. Это будет то же самое, что говорить, что приложение, требующее графовой базы данных, нуждается в новой категории Ops.
Почему мы переобучили MLOps?
Во многих обсуждениях о потребностях инфраструктуры ученых по данным возникает вопрос о их базовых навыках программирования. Издается заявления типа “Не ожидайте, что ученый по данным поймет концепции Git”, “Ученые по данным не могут создавать код с правильным логированием, они не являются программными инженерами” и т.д.
Я не согласен с таким мышлением, и я считаю, что оно привело нас к переобучению MLOps.
Ученые по данным – это высококвалифицированные специалисты, которые быстро осваивают концепции контроля версий и овладевают сложностями работы с автоматизированными серверами для непрерывной интеграции и доставки. Как я уже упоминал, младшие программные инженеры учатся этому на практике, и я считаю, что так же должны поступать ученые по данным, которые намерены приносить ценность коммерческой компании. Я считаю, что мы создаем категорию инструментов для решения проблемы недостатка обучения ученых по данным. Это исследование подтверждает эту точку зрения.
Тем не менее, вопрос, насколько операционным инженерам по программному обеспечению должны быть доступны, по-прежнему открыт, и разные организации имеют разные взгляды на то, как DevOps реализуется внутри организации.
Общим для всех является понимание того, что команда DevOps отвечает за обеспечение инфраструктуры, и программные инженеры должны ее понимать, использовать и предлагать требования, чтобы убедиться, что она постоянно улучшается.
Переходя к инженерам данных, ожидания остаются теми же. Почему это должно измениться для инженеров машинного обучения/данных ученых?
Заключение
Организации с обширными операциями с данными (вскоре все организации) должны убедиться, что их команды DevOps обладают экспертизой в области данных, чтобы обеспечивать высококачественную и общую инфраструктуру для всех практикующих данных, а также убедиться, что все практикующие данные хорошо образованы в использовании этой инфраструктуры для оптимального управления своими конвейерами. В предприятиях это может быть отдельным отделом.
Хорошие практики и внутреннее обучение могут устранить необходимость в излишне специализированных инструментах, которые в конечном итоге ограничивают доступ практикующих данных к необходимой гибкости, предлагаемой общими инструментами операций.
Преимущество излишне специализированного инструмента заключается в том, что в краткосрочной перспективе, для очень простой системы, он предоставляет все необходимое в одном месте.
Зачем работать с нашей командой DevOps, если мы можем просто купить этот инструмент “от начала до конца”? Но в долгосрочной перспективе, потребности эволюционируют от упрощенных случаев использования, и требуется глубина экспертных систем. Например, для оркестрации вместо использования инструментов “от начала до конца”, которые предлагают упрощенную оркестрацию, среди прочего, компании будут переходить к мощным системам оркестрации, таким как Airflow, Prefect или Dagster.
