Команда DevOps Research and Assessment (DORA) в Google определила 4 метрики (плюс 1), чтобы показать производительность команды разработчиков программного обеспечения.

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

Что такое ДОРА?

Команда DevOps Research and Assessment (DORA) — это 8-летняя инициатива, собирающая данные от более чем 32 000 профессионалов по всему миру, чтобы составить представление о методах и возможностях, которые обеспечивают высокую производительность в командах по доставке технологий (и, следовательно, организационные результаты). Инструмент предоставляет возможность сравнить с аналогами и определить ключевые области для повышения производительности.

Команда DevOps Research and Assessment (DORA) в Google определила 4 показателя, отражающие эффективность команды разработчиков программного обеспечения.

  • Частота развертывания — как часто организация успешно выпускает релизы в рабочую среду.
  • Время подготовки к внесению изменений — время от фиксации до развертывания в рабочей среде.
  • Change Failure Rate — процент развертываний, вызвавших сбой в рабочей среде.
  • Время восстановления службы — сколько времени требуется организации для восстановления после сбоя в работе.

Зрелость измеряется между исполнителями с низким, средним, высоким и элитным уровнем.

Как можно применить DORA к ML

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

Таким образом, исходя из кросс-функционального характера системы ML, зрелость организации ML может быть частично измерена теми же четырьмя показателями, что и любая команда по доставке ЕО.

Однако для систем машинного обучения необходимо учитывать еще один фактор — ДАННЫЕ. Поведение модели машинного обучения определяется как кодом, и данными, так и другими факторами, влияющими на согласованность и точность результатов:

  1. Дрейф:модели машинного обучения обучаются и проверяются на основе наборов данных, предоставленных на этапе экспериментов (при условии стандартного подхода к контролируемому обучению), при условии, что вариант использования проверен и модель соответствует бизнес-целям в сравнении с обучением/тестированием. наборы данных выпущены в производство.

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

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

Таким образом, внедрение системы машинного обучения в продукт обусловлено двумя ключевыми факторами*:

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

Для № 1 приведенные выше показатели верны с точки зрения общей зрелости изменений ПО, применяемых к системе ML, со всеми теми же связанными проблемами.

Для № 2 приведенные выше показатели, с некоторой интерпретацией, могут стать мерой зрелости.

Еще одним соображением для вариантов использования AI/ML является экспериментирование. В то же время важно измерять зрелость вариантов использования, достигающих производства и эксплуатируемых. Разработка вариантов использования AI/ML часто терпит неудачу во время экспериментов по ряду причин, таких как:

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

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

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

*Еще одним соображением будет Ответственный ИИ. Часть одобрения выпуска модели машинного обучения включает проверку модели на соответствие этическим нормам, например. Соответствует ли модель соответствующим KPI справедливости и предвзятости, избегая дискриминации по отношению к определенным группам в наборе данных. Я рассматриваю это так же, как тестирование NFR для любого программного обеспечения, в данном случае рассматривая этику, а не производительность или безопасность API.

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

Критерии оценки зрелости на основе машинного обучения

Для изменений на основе данных новая интерпретация для каждого из вышеперечисленных может быть:

  • Частота развертывания — как часто организация успешно выпускает переобученные модели в рабочую среду.
  • Время подготовки к изменениям – количество времени, которое требуется после повторного обучения модели для развертывания обновленной модели в рабочей среде.
  • Change Failure Rate – процент развертываний, вызвавших сбои в работе в связи с перекосом данных обучения/обслуживания, ответственным искусственным интеллектом (предвзятость, объективность, объяснимость), проблемами качества данных, неработающими функциями и т. д.
  • Time to Restore Service — время, необходимое для обнаружения расхождения данных*, переобучения модели и повторного развертывания в рабочей среде.

С добавлением :

  • Коэффициент неудачных экспериментов:процент вариантов использования, которые не прошли анализ/разработку PoV и не дошли до рабочей версии. Это включает в себя все режимы отказа. Значение частоты отказов 0% или 100% или слишком близкое к тому и другому указывает на неправильный баланс в подходе.

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

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

Change Failure Rate: сколько развертываний привело к сбою выполнения модели в рабочей среде — из-за обнаружения перекосов в обучении/обслуживании, сбоев, выявленных RAI, …? Развертывание должно быть напрямую связано с ошибкой*.

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

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

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

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

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

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