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

Модель зрелости MLOps от Microsoft или определение уровней MLOps от Google — хорошее начало, но они не обязательно дают практическую информацию о том, как проект может перейти от незрелого MLOps к достижению 100% зрелости MLOps. Вот почему мы решили создать анкету, которая может помочь оценить зрелость MLOps на уровне проекта. Наша анкета охватывает широкий спектр аспектов MLOps, что делает ее ценным ресурсом для команд, стремящихся улучшить свои методы MLOps.

  1. Документация
  2. Отслеживаемость и воспроизводимость
  3. Качество кода
  4. Мониторинг и поддержка
  5. Конвейеры преобразования данных и хранилище функций
  6. Объяснимость модели
  7. A/B-тестирование и обратная связь

Мы считаем, что проект машинного обучения можно считать MLOps зрелым, если на все утверждения в разделах 1–4 (документация, отслеживаемость и воспроизводимость, качество кода, мониторинг и поддержка) можно ответить «да». Это минимум, необходимый для надежного развертывания проекта машинного обучения в рабочей среде. Разделы 5–7 выходят за рамки базовой зрелости MLOps, и можно работать над ее реализацией, хотя некоторые утверждения в разделах 1–4 не были рассмотрены. Тем не менее, мы призываем всех расставить приоритеты по основам, прежде чем переходить к продвинутым практикам MLOps.

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

Вы можете скачать анкету в формате Excel с нашего github: https://github.com/marvelousmlops/mlops_maturity_assessment.

1. Документация

1.1. Документация проекта

  1. Бизнес-цели и ключевые показатели эффективности проекта машинного обучения документируются и обновляются.
  2. Обзор всех членов команды, участвующих в проекте машинного обучения, включая их обязанности, создается и обновляется.
  3. Оценка рисков модели ML создается, документируется и обновляется.

1.2. Документация по модели машинного обучения

  1. Шаги сбора, анализа и очистки данных, включая мотивацию каждого шага, должны быть задокументированы.
  2. Определение данных (какие функции используются в модели ML и что означают эти функции) задокументировано.
  3. Выбор модели машинного обучения документирован и обоснован.

1.3. Техническая документация

  1. API задокументирован для случаев использования логического вывода в реальном времени: структура и определение запросов и ответов, типы данных.
  2. Проект архитектуры программного обеспечения задокументирован и поддерживается в актуальном состоянии.

2. Прослеживаемость и воспроизводимость

2.1. Отслеживаемость и воспроизводимость инфраструктуры

  1. Инфраструктура определяется как код, позже упоминаемый как IaC.
  2. IaC хранится в системе контроля версий.
  3. Процесс запроса на вытягивание используется для внесения изменений в IaC.
  4. Когда запрос на вытягивание объединен, изменения будут автоматически применены к соответствующим средам через конвейер CD.
  5. Только конвейеры CD могут развертывать изменения, отдельные разработчики не имеют прав на развертывание инфраструктуры.
  6. Проекты машинного обучения должны иметь как минимум две среды (предварительную и производственную), которые являются точными копиями друг друга.
  7. Все среды, связанные с проектом ML, должны иметь доступ (чтение и/или запись) к производственным данным (данные должны быть одинаковыми в любой момент времени).

2.2. Отслеживаемость и воспроизводимость кода машинного обучения

  1. Код для сбора, анализа и очистки данных должен храниться в системе контроля версий.
  2. Код модели машинного обучения хранится в системе контроля версий вместе с кодом подготовки данных и кодом API (если применимо).
  3. Запросы на вытягивание (PR) используются для внесения изменений в любой код, связанный с проектом ML.
  4. При объединении PR изменения будут автоматически применены к соответствующим средам через конвейер CD.
  5. Окружающая среда определяется как код и является воспроизводимой.
  6. Код модели машинного обучения не должен требовать изменений для запуска в разных средах. Процессы развертывания модели ML во всех средах должны быть одинаковыми.
  7. Для запуска/развертывания любой заданной модели машинного обучения в любой среде можно однозначно найти: 1. соответствующий код/фиксацию в git, 2. инфраструктуру, используемую для обучения и обслуживания, 3. среду, используемую для обучение и обслуживание, 4. артефакты модели машинного обучения, 5. какие данные использовались для обучения модели.
  8. Стратегия переобучения модели машинного обучения присутствует и мотивирована.
  9. Присутствует стратегия отката, позволяющая вернуться к предыдущей версии модели ML.

3. Качество кода

3.1. Требования к качеству кода инфраструктуры

  1. Конвейер CI, который включает проверку файлов конфигурации и выполнение автоматических тестов, запускается при создании запроса на вытягивание.
  2. Другие члены команды (например, разработчики/специалисты по безопасности) должны просмотреть и одобрить изменения перед слиянием запроса на вытягивание.

3.2. Требования к качеству кода модели машинного обучения

  1. Перехватчики перед фиксацией реализованы, чтобы гарантировать, что код соответствует рекомендациям по качеству кода, прежде чем он будет отправлен в систему контроля версий.
  2. Код модели ML содержит тесты для всех этапов процесса ML (обработка данных, обучение модели ML, развертывание API).
  3. Конвейер непрерывной интеграции, который включает выполнение автоматических тестов, запускается при создании запроса на вытягивание.
  4. Другие члены команды (например, разработчики/специалисты по безопасности) должны одобрить изменения перед слиянием запроса на вытягивание.
  5. Для случаев использования логических выводов в реальном времени должна присутствовать стратегия для регулярного выполнения нагрузочных и стресс-тестов API и обеспечения соответствия API требованиям к задержке.
  6. Для случаев использования логического вывода в реальном времени аутентификация и работа в сети должны соответствовать рекомендациям по безопасности.
  7. Код модели ML должен быть задокументирован (документация как код).
  8. Примечания к выпуску следует создавать каждый раз, когда появляется новый выпуск кода модели ML.

4. Мониторинг и поддержка

4.1. Требования к мониторингу инфраструктуры

  1. Настроен учет затрат на инфраструктуру; оценка стоимости выполняется регулярно для проекта машинного обучения.
  2. Отслеживается работоспособность ресурсов инфраструктуры. Оповещение настроено в случае возникновения проблем.

4.2. Требования к мониторингу приложений

  1. Для случаев использования вывода в реальном времени все запросы и ответы API должны регистрироваться, время ответа API, коды ответов и состояние работоспособности должны отслеживаться.
  2. Для случаев пакетного использования необходимо контролировать непрерывность доставки в целевую систему.

4.3. KPI и требования к мониторингу производительности модели

  1. Показатели автономной оценки (например, оценка F1, вычисленная на основе исторических данных для задач классификации) сохраняются и отслеживаются.
  2. Цикл обратной связи используется для оценки и постоянного мониторинга ключевых показателей эффективности, которые были определены вместе с заинтересованными сторонами для этого проекта машинного обучения.

4.4. Дрейф данных и мониторинг выбросов

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

5. Конвейеры преобразования данных и хранилище функций

  1. Функции предварительно вычисляются в хранилище функций и/или импортируются в виде кода, который можно использовать в проектах.
  2. Данные автономного обучения и данные онлайн-прогнозирования преобразуются с помощью одного и того же кода.
  3. Все функции модели берутся из хранилища функций или внешних библиотек.
  4. Специалист по данным может добавлять функции в хранилище функций с помощью PR.
  5. Зависимость функций автоматически управляется хранилищем функций.
  6. Хранилище функций отслеживает использование функций для каждой модели.
  7. Конфигурация функции отделена от ее кода.

6. Объяснимость модели

  1. Система ИИ способна дать объяснение своим выводам с доказательствами в поддержку объяснения.
  2. Объяснение системы ИИ имеет смысл, если пользователь системы может понять объяснение.
  3. Система ИИ способна четко описать, как она пришла к своим решениям.
  4. Система ИИ работает в пределах своих знаний и знает, когда она выходит за эти пределы.

7. A/B-тестирование и обратная связь

  1. Входные и выходные данные модели сохраняются автоматически.
  2. A/B-тестирование проводится регулярно.
  3. При проведении A/B-тестирования можно гарантировать, что один и тот же клиент будет получать прогнозы на основе одной и той же версии модели в течение всего эксперимента.