Проблемы, извлеченные уроки и некоторые руководящие принципы
В последнее время MLOps, ориентированные на данные, заняли центральное место, особенно когда эта тема была поднята в центр внимания пионером отрасли, таким как Эндрю Нг. Это было проблемой в течение долгого времени, так почему же это вдруг такая горячая тема?
Несмотря на то, что все впечатляющие разработки, связанные с внедрением принципов и платформ DevOps для управления жизненным циклом модели, действительно значительно ускоряют воспроизводимость «модели» и сам процесс развертывания, самый большой источник изменчивости, т. е. процесс генерации данных, который питает все эти Системы машинного обучения по-прежнему требуют большого объема ручного труда, и их сложно внедрить на предприятиях.
Почему MLOps, ориентированные на данные, занимают центральное место?
Большинство предприятий, особенно в сфере производства, не основаны на ДНК, управляемой данными, т. е. традиционно не делались крупномасштабные инвестиции в инфраструктуру данных и организации данных. Если основной бизнес предприятия — т. е. то, что они «продают», — не основан на данных и не поддерживается ими, то все последующие процессы генерации данных, формирующие основу для возможного внедрения ML/AI, будут сильно различаться. Это связано с тем, что культура данных имеет тенденцию быть изменчивой и микроклиматической.
Часто MLOps рассматриваются изолированно, однако стоит отметить, что команды инженеров данных для традиционной аналитики и DevOps существовали задолго до того, как команда MLOps дала о себе знать.
Возможность обнаружения данных остается ключевой проблемой
Команды инженеров данных часто представляют собой параллельные организации. Это означает, что видимость данных за рамками определенных приложений все еще находится в зачаточном состоянии. Это значительно влияет на MLOps с точки зрения данных, поскольку требует серьезной работы, доработок и реинжиниринга — в основном из-за отсутствия хорошего механизма публикации для существующих конвейеров данных и активов.
Поздно на вечеринку, а! MLOps и, возможно, DevSecOps, вероятно, являются самыми последними поступлениями в экосистему данных. Утопия слабосвязанной архитектуры все еще далека от реальности на большинстве предприятий, что требует, чтобы команды MLOps в значительной степени полагались на существующие команды инженеров данных. Политики управления данными и контроля доступа в зависимости от того, насколько хорошо они были разработаны, могут стать мечтой (или кошмаром!) для навигации.
Быстрые победы на ранних стадиях MLOps для предприятия означают объединение всех вместе. Data Engineering/Ops, DevOps, DevSecOps и т. д. Почему?
MLOps требует уникального сочетания навыков на стыке машинного обучения, разработки программного обеспечения, DevOps, проектирования данных и конвейеров, инфраструктуры и CloudOps. Создание таких команд является дорогостоящим и трудоемким процессом. Немногие предприятия могли принять и оправдать такие затраты по номинальной стоимости, не продемонстрировав сначала ценность! Это само по себе требует огромных усилий со стороны лидера MLOps с точки зрения образования, евангелизации и убеждения, чтобы обеспечить согласованность вне технических проблем, которые естественным образом возникают на этой территории.
Большой камень в бэклоге технического долга — отсутствие повторяемости при генерации и сборе данных. Чтобы MLOps действительно сократила время окупаемости, особенно с учетом распространения науки о данных и модельных экспериментов с течением времени, потребуется тяжелая работа с точки зрения внедрения повторяющихся механизмов генерации данных и управления версиями. Рассмотрим область роботизированной автоматизации процессов, которая находится в неконтролируемой области, которая в значительной степени зависит от человеческой интерпретации для создания меток и достоверности (т.е. для получения данных в форме, которую можно легко использовать для контролируемого обучения). Обычно в таких случаях пользовательские форматы данных генерируются инженерными группами, поскольку процесс масштабируется, что приводит к многочисленным версиям. В результате становится невозможным многократное подключение метаданных приложения к созданным вручную меткам. Поскольку смена версии данных является одним из основных триггеров MLOps, из-за этого цикл автоматизации прерывается. Модельно-ориентированная CI/CD для внезапно кажется легкой.
Распространение конвейера — это один из самых сложных аспектов производства машинного обучения и развертывания обновлений для развернутых приложений машинного обучения. Факторами, способствующими этому, обычно являются
- Несколько специалистов по данным одновременно воздействуют на различные этапы потока создания ценности по отдельности. Количество комбинаций конвейеров, необходимых во время экспериментов, может увеличиваться комбинаторно, как показано в примере ниже (каждый цвет представляет рабочий процесс другого специалиста по данным). Как правило, с точки зрения модели CI принудительное применение схемы/интерфейса данных и самообнаружение не были настроены в механизмах сборки, а механизмов совместной работы и публикации с самоуведомлением для изменений интерфейса и схемы не существует.
- Организационная структура — как правило, право собственности на конвейер данных лежит на группе разработки и эксплуатации данных, поэтому способность проектировать, гибко создавать и тестировать варианты конвейера в большей или меньшей степени возлагается на группы разработки данных. В результате возникают большие накладные расходы с точки зрения обмена информацией между этими двумя командами, чтобы заставить эту работу работать. Это одна из областей, где широкое взаимодействие между группами Data Science и Data Engineering имеет важное значение для производительности и воспроизводимости. Другой альтернативой является очень гибкая структура передачи данных с механизмом самостоятельной публикации, создание и установка которого нетривиальна.
- Это также обусловливает потребность в гибкой архитектуре, в которой границы ролей между группами Data Engg-Ops/MLOps должны быть значительно размыты.
Небольшая часть головоломки. В отличие от компаний, которые родились из парадигмы, ориентированной на данные, машинное обучение или искусственный интеллект — это лишь малая часть того, что обычно «поставляется» или принимается на поставку для большинства крупных предприятий.
Успешные MLOps на предприятиях с физическими активами диктуют обширную интеграцию с существующими аппаратными процессами и операциями управления жизненным циклом продукта.
Если портфель продуктов состоит из чистого программного обеспечения, эта интеграция не так сложна. Однако на предприятиях, где возможности машинного обучения должны сочетаться с производимыми «физическими» продуктами, включение MLOps требует, по крайней мере, минимального уровня гибкости на нескольких уровнях, таких как:
- Интегрированное управление выпуском аппаратного, программного обеспечения, микропрограммы и продуктов машинного обучения и гибкая трансформация. Это означает включение DataOps, DevOps и MLOps в методологии, которые исторически были ориентированы на аппаратные активы и имели тенденцию быть похожими на водопад.
- Увеличение затрат на проверку и валидацию по мере того, как происходит больше итераций, что может быть значительным.
Такие усилия требуют предварительных инвестиций и их трудно оправдать в типичных сценариях промышленного производства. Напрашивается вопрос о преобразовании бизнес-модели в модель «как услуга», где окупаемость инвестиций доказуема, только тогда такие инвестиции могут быть оправданы.
Так есть ли какой-то план, чтобы сделать путешествие MLOps легким? Это не так просто, каждая команда столкнется со своим набором уникальных задач! Убедившись в этом на собственном опыте для промышленного производства и цепочек поставок по вертикали в розничной торговле, потребительских товарах, транспорте, энергетике, полупроводниках и авиации, некоторые ключевые принципы, которые служат внутренним компасом, таковы:
Открытость, сотрудничество и возможность самостоятельной публикации
Модульная и слабосвязанная архитектура конвейера, гибкость при построении и тестировании конвейеров для разных ролей
Совместимость — в облаке, гибриде и вне его
Возможность монетизации — можно ли измерить рентабельность инвестиций, иначе какой в этом смысл?
Наконец, евангелизация является ключевой частью путешествия MLOps, так как это требует обучения, согласованности и объединения различных навыков и команд для достижения общей цели!
Эти узкие места в потоке создания ценности машинного обучения открывают новые операционные модели как для бизнеса, так и для групп специалистов по обработке и анализу данных. Некоторые тенденции, которые мы можем ожидать, включают в себя большее внимание к созданию групп специалистов по обработке и анализу данных полного цикла с одновременным ускорением работы гражданских платформ с минимальным кодом и без кода для машинного обучения, обслуживания и визуализации DS. Я планирую обсудить эти тенденции и то, как и где мы можем ожидать изменения ландшафта, в продолжении этой публикации. Я хотел бы услышать ваши мысли, точки зрения, знания и стратегии, которые помогли командам машинного обучения преодолеть аналогичные проблемы.
