Что такое МЛОпс? Почему MLOps должны быть ориентированы на данные

Это начало серии статей о MLOps, ориентированных на данные. Запланированная серия:

  1. Почему MLOps должны быть ориентированы на данные (текущая статья)
  2. Шесть этапов датацентричных MLOps
  3. Колесо данных

Оглавление

· The Origin
· Что такое DevOps?
· MLOps по дешевке?
· Software 2.0
· Model-Centric vs. Центральные подходы
∘ Модельно-ориентированный подход
∘ Датоцентричный подход
· Резюме

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

Происхождение

Слово MLOps представляет собой комбинацию машинного обучения (ML) и операций (MLOps = ML + Ops). Это относится к набору инженерных практик для разработки и эксплуатации моделей машинного обучения в производстве. На самом деле он включает в себя три дисциплины: машинное обучение, инженерию данных и DevOps.

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

Что такое DevOps?

DevOps — это инженерная практика, которая сочетает в себе разработку программного обеспечения и ИТ-операции. Противоположным подходом была традиционная водопадная модель разработки программного обеспечения, в которой программное обеспечение разрабатывалось поэтапно, начиная с планирования и написания кода и заканчивая созданием, тестированием и выпуском. После его выпуска за эксплуатацию и техническое обслуживание отвечала отдельная группа инженеров (в зависимости от компании она называлась «оперативной» или «поддерживающей инженерной»).

Модель водопада была в фаворе, когда программное обеспечение поставлялось в коробке. В прежние времена, когда вокруг бродили динозавры, приложения записывались на компакт-диски и DVD-диски для доставки клиентам. Стоимость выпуска была высока и требовала тщательного планирования, проектирования и разработки.

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

MLOps по дешевке?

Может возникнуть соблазн подумать, что, поскольку модели ML поставляются в виде программного обеспечения, вы можете просто заменить часть кодирования разработкой модели ML, чтобы превратить DevOps в MLOps. Это приводит к MLOps Франкенштейна, когда вы втыкаете конвейер машинного обучения в DevOps.

Программное обеспечение 2.0

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

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

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

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

В Software 2.0 данные и ответы передаются программе (т. е. модели), которая самостоятельно вычисляет основные правила. Эксперты предметной области нужны для того, чтобы маркировать данные (X или входные данные) ожидаемыми результатами (Y или истина), но не формулировать лежащие в их основе правила.

Смена парадигм программирования привела к значительному сокращению кода. Например, код языкового перевода Google сократился с 500 000 до 500 строк кода (Джефф Дин, 2017).

Модельно-ориентированные и датацентрические подходы

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

Модельно-ориентированный подход

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

Ориентированный на данные подход

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

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

Одним из них является набор данных Корейский тротуар, в котором аннотируются различные объекты на изображениях тротуаров.

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

Одна и та же модель (YOLO v5) была обучена с двумя наборами данных, и сравниваются показатели производительности (mAP). Вот график mAP, поскольку количество обучающих изображений увеличилось со 100 до 1000.

Как и следовало ожидать, модель, обученная с использованием набора данных панели мониторинга, работала намного лучше. Всего с 200 обучающими изображениями модель, обученная данным приборной панели, достигла точности более 80%. Напротив, модель, обученная на данных тротуаров, едва достигла 40% mAP после добавления 1000 изображений.

Причина различия должна быть очевидна. Изображения на приборной панели очень похожи, и все символы одного класса выглядят одинаково: например, ремни безопасности, фары двигателя и т. д. С другой стороны, изображения тротуаров содержат самые разные объекты: например, автомобили, людей, деревья, кошек. , собаки, тумбы, скамейки и т. д. Кроме того, объекты в каждом классе имеют большое разнообразие. У собак много пород, как и у кошек, деревьев и людей.

Пример показывает, что правильным ответом на вопрос «Сколько данных нам нужно?» должен быть «Это зависит». Зависимость исходит из цели, сложности данных и модели, количества классов и т. д.

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

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

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

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