Как будет выглядеть машинное обучение, если добавить к нему DevOps?

5 мин на чтение

By Ryan Dawson

Мы приоткрываем завесу над технологией MLOps.

Что это вообще такое и зачем оно нужно? А как еще превратить вашу интеллектуальную модель в промышленный продукт?

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

Зачем нужен MLOps?

Модели машинного обучения делают предсказания о новых данных, основываясь на данных, на которых они обучились. Управление этими данными таким сопособом, которые может использоваться в живом окружении - это проблема и причина того, что 80% проектов по анализу данных не доходят до стадии внедрения (оценка Gartner).

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

MLOps - это не просто DevOps

Практики DevOps сосредоточены на процессе “сборка и релиз” и непрерывной интеграции. Обычные программные сборки - это исполняемые объекты, скомпилированные из исходного кода. Данные, не являющиеся кодом, в таких билдах - это обычно небольшие статичные конфигурационные файлы. По сути, DevOps ориентированы на создание программ, состоящих из набора явно определенных правил, выдающих конкретный вывод в ответ на конкретный набор входных данных.

В противоположность этому, модели машинного обучения делают предсказания, выделяя неявные зависимости в данных, а не явно указывая логические правила. Характерная задача машинного обучения состоит в предсказании, основанном на известных данных: например, предсказание цены квартиры на основе известных данных о ценах квартир и дополнительных параметров - количества комнат, метраже и расположении. Программная сборка машинного обучения исполняют последовательность шагов,, выделяющих зависимости из данных и создающих взвешенную исполняемую модель машинного обучения. Такие сборки более сложные, а вся последовательность обработки данных - более экспериментальная. Как результат, вызов, стоящий перед MLOps состоит в поддержке многоступенчатых сборок моделей машинного обучения с большим объемом данных и изменяющимися параметрами.

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

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

Набор инструментов MLOps

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

Некоторые платформы машинного обучения являются частью комплексных облачных решений, таких как AWS SageMaker или AzureML. Это может не подойти организации, в зависимости от ее облачной стратегии. Другие платформы не так привязаны к облакам и предоставляют локальные продукты, либо хостинг на собственном сервере (например, Databricks MLflow).

Вместо использования готовой платформы, организация может выбрать разработку своей собственной. Это может стать предпочтительным решением, если существуют слишком специфические для готовых решений требования, например, необходимость интеграции с собственными организационными системами или требование хранения данных в определенном месте. Разработка собственной платформы требует ориентирования в наборе существующих инструментов машинного обучения. Этот набор широк и сложен и включает различные нишевые инструменты, зачастую, конкурирующие между собой в решении схожих задач, но с использованием разных подходов (см. проект Linux Foundation по визуализации ландшафта инструментов AI или список по категориям от Institute for Ethical AI)

Если ваша организация использует Kubernetes, интересные возможности предоставляет проект kuberflow, направленный на управление набором открытых инструментов и организацией их совместной работы на основе Kubernetes. этот проект организован Google и поддерживается такими компаниями как IB, Cisco, Caicloud, Amazon, и Microsoft, а также такими разработчиками инструментов машинного обучения как Seldon, китайский технический гигант NetEase, японский технический конгломерат NTT, and гигант в производстве аппаратного обспечения Intel.

Управление

Задачи воспроизводимости и мониторинга систем машинного обучения - это управленческие задачи. Их необходимо решать для построения поддерживаемой промышленной системы, в которой вы уверены, что все вопросы наблюдателей и пользователей могут успешно решаться. Вопросы могут возникнуть не только от ожидаемого желания пользователей понять, почему было принято то или иное решение, которое непосредственно их касается. В некоторых случаях это может требование закона, например, европейский закон General Data Protection Regulation указывает, что “субъект данных” имеет право на “осмысленную информацию об используемой логике” в любой автоматизированной системе принятия решений.

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

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