Вы слышали, как это говорили, слышали, как это писали, и вы слышали, как это пели с крыш аналитики и поставщики в равной степени: 87% проектов по науке о данных никогда не переходят в производство.

Почему это?

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

Вот как я начал думать об этом:

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

И не только я. В недавней статье идейный вдохновитель программного обеспечения Мартин Фаулер рассказывает, почему услуги машинного обучения такие сложные:

«Помимо кода, изменения в моделях машинного обучения и данные, используемые для их обучения, — это еще один тип изменений, которыми необходимо управлять и внедрять в процесс доставки программного обеспечения».

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

Параметр 1: Код

Роль кода в приложении ML — это, по сути, «клей», который:

  • Предоставляет API
  • Преобразует данные для извлечения соответствующих функций
  • Использует модель для вывода
  • Включает бизнес-логику

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

Ниже приведены несколько проблем, с которыми вы можете столкнуться при управлении кодом службы машинного обучения:

Обновления кода могут привести к регрессии

Код извлечения признаков обычно пишет специалист по данным. Когда придет время создавать API, разработчикам потребуется перенести код из среды обучения в службу прогнозирования. Кроме того, им может потребоваться преобразовать ввод в службу (возможно, запрос REST) ​​в пригодные для использования данные. Разработчики и специалисты по данным непременно захотят обновить этот код по мере того, как они будут работать над сервисом, что может привести к регрессии.

Советы:

  • Если нет веских причин не делать этого, создайте сервис обслуживания модели на Python. Большинство специалистов по данным используют Python. Это делает процесс развертывания более рациональным. По моему опыту, пользователи переходят от «недель/месяцев» к дням при повторном развертывании новой модели. Некоторым командам нужна невероятно высокая производительность, и они предпочитают конвертировать весь код в Rust/Go. Большинство этого не делает. Кстати, AWS Sagemaker написан на Python.
  • Не забывайте применять хорошие методы кодирования даже в ноутбуках Jupyter. Вы будете удивлены, какой код попадет в производство.

Обновления зависимостей могут иметь непредвиденные последствия

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

Совет. Убедитесь, что вы используете ту же версию Python и библиотеку машинного обучения, которые вы использовали для обучения модели. Вы можете использовать «заморозку пипсов», чтобы определить, какие версии вы используете.

Среда развертывания может быть нестабильной

Масштабируемому сервису прогнозирования требуется надлежащая среда для правильного выполнения кода. Например, определенные библиотеки машинного обучения могут работать только в определенных дистрибутивах ОС. Docker — это стандарт для настройки воспроизводимой среды, но настройка Docker для варианта использования ML может оказаться чрезвычайно сложной задачей. При правильной настройке он предоставит вам чистый артефакт, из которого вы сможете выполнить развертывание в ряде различных служб, а также предоставит возможность запуска службы локально, чтобы вы могли отлаживать ее в случае возникновения проблемы.

Советы:

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

Измерение 2: данные

После того как вы решили основные проблемы, связанные с управлением кодом, пришло время взглянуть на данные.

Данные в некотором роде детерминированы, но, потратив годы на создание конвейеров данных, трудно понять, какие типы данных и в каких объемах вы будете их получать. Вы всегда будете удивлены. По этой причине я бы сказал, что данные — это самая изменчивая часть головоломки.

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

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

Изменения данных с течением времени могут привести к целому ряду проблем: модель может давать менее точные прогнозы или вообще не работать. Дрейф данных или вариации входных производственных данных может происходить с течением времени или при смене сезонов. Важно знать, происходит ли это, чтобы при необходимости можно было переобучить модель.

Советы:

  • Частое и быстрое развертывание придаст вам больше уверенности в вашем конвейере. Мало того, он имеет дополнительные преимущества, такие как предотвращение проблем из-за дрейфа входных данных.
  • Используйте специальные инструменты мониторинга ML, такие как WhyLabs, Evidently.ai или Aporia, которые могут помочь обнаружить дрейф данных и контролировать производительность.

Производительность модели также может меняться с течением времени, но ее гораздо сложнее отслеживать, поскольку для этого требуется, чтобы вы соединили прогнозы с последующими результатами. Например, соединение точек между рекомендацией продукта, основанной на машинном обучении, и тем, действительно ли продукт был куплен потребителем.

Совет. Мониторинг производительности часто включает объединение с нижестоящими показателями. Убедитесь, что вы отправляете результаты логического вывода в то же место (вероятно, в хранилище данных), что и метрики, к которым хотите присоединиться.

Неверные данные могут нарушить работу службы

API — мощная конструкция, потому что она раскрывает функциональность миру. Это означает, что вы вряд ли сможете контролировать то, что отправляется на ваш сервис. Неожиданные данные так же плохи, как и неверные данные, и вполне вероятно, что в какой-то момент ваша служба получит и то, и другое. Постарайтесь убедиться, что это не нанесет вред вашей системе.

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

Необходимы свежие данные для проверки новых моделей

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

Совет. Использование сервисной сетки, такой как Istio или AWS App Mesh, может помочь распределить производственный трафик и проверить новые модели с помощью теневых конвейеров.

Измерение 3: Модель

Последнее измерение — это, конечно же, сама модель.

Я думаю о модели как о детерминированной функции, хотя и о самом черном ящике из трех измерений. Это похоже на опыт чтения «спагетти-кода», в котором не могут разобраться даже самые опытные инженеры: обученная модель состоит из сложных векторов, которые сами по себе очень сложны для понимания, но при определенном входе результат должен всегда быть одним и тем же для данной версии модели.

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

Модели трудно воспроизвести

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

Совет. Изучите вопрос при сохранении модели и убедитесь, что это рекомендуемый способ сохранения. Например, Pytorch имеет документацию, в которой объясняются различные методы сохранения модели в зависимости от вашего контекста.

Переключение между людьми и системами может быть сложным

Сохранение модели может привести к созданию нескольких файлов, содержащих веса модели и связанные метаданные. Все это необходимо для повторного создания экземпляра модели. Вы захотите переместить эти артефакты в централизованное место, где конвейер автоматизированного развертывания сможет отправить модель в производство.

Проблема в том, что производственные конвейеры CI/CD, скорее всего, расположены в безопасных облачных средах. Разработка безопасной, оптимизированной системы, которая переходит от ноутбука исследователя данных (или среды удаленного обучения) к производственной среде, может оказаться сложной задачей.

Совет. Попробуйте найти стандарт, который можно использовать для координации обучения модели с модельным сервисом. Такие инструменты, как MLFlow, BentoML, TFServing и Cortex, помогают координировать модель в реестре моделей и, в конечном итоге, в месте развертывания. Например, используйте MLFlow для управления экспериментами и обучением, а BentoML — для обслуживания и развертывания моделей.

Вы можете случайно потерять хорошие модели

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

Совет. Такие инструменты, как S3 или Google Cloud Storage, могут стать элегантным решением в качестве общего репозитория моделей, который ученые и разработчики данных могут использовать для обмена моделями.

Заключение

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

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