Масштабное управление моделью машинного обучения

Автор Peter Saddow и соавтор Daniel Yehdego присоединились к написанию этой статьи.

Сегодня прогнозные модели помогают многим компаниям управлять критически важными бизнес-процессами. Эти прогностические модели являются вероятностными - они включают случайные вариации - и они зависят от некоторых основных предположений, чтобы заставить их работать должным образом. Главные из них: 1.) данные, поступающие в них, распределяются определенным образом и 2.) базовые бизнес-сценарии не меняются с момента создания моделей. В результате компаниям важно отслеживать изменения бизнес-сценариев и качества данных, иначе модель перестанет работать так, как предполагалось.

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

Модели, основанные на машинном обучении (ML), нуждаются в управлении, как и другие модели, но, возможно, даже в большей степени. Это связано с тем, что модели машинного обучения обычно разрабатываются таким образом, чтобы автоматически улучшаться с учетом опыта. Хотя их способность «учиться» обеспечивает большую точность и предсказуемость, она также может увеличивать типы риска, упомянутые ранее, а также приводить к непреднамеренным предубеждениям. Такой динамический характер моделей машинного обучения означает, что им требуется более частый мониторинг производительности, постоянный обзор данных и сравнительный анализ, лучшее понимание инвентаризации контекстной модели и действенные планы действий в чрезвычайных ситуациях.

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

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

Жизненный цикл разработки модели машинного обучения, роли и обязанности

В группе аналитики роста клиентов (CGA) подразделения Cloud + AI в Microsoft мы следуем процессу разработки и развертывания наших моделей, который включает следующие этапы:

1. Концепция
2. Оценка прототипа / модели
3. Готовность к производству
4. Внедрение
5. Мониторинг производства
6. Прекращение поддержки

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

Детали этих этапов

1. Концепция: когда выясняется, что нужна модель машинного обучения. Идея может исходить от владельца модели, руководства или руководителя программы. На этом начальном этапе все стороны могут не быть полностью вовлечены, а некоторые необходимые стороны могут даже не быть вовлечены.
2. Оценка прототипа / модели. На этом этапе владелец модели работает над созданием модели, чтобы проверить первоначальную идею и предположения, лежащие в основе модели. Этот этап помогает определить объем и ожидания проекта, а также влияние модели на формализацию плана продвижения вперед. На этом этапе важно заручиться поддержкой всех членов команды, которые могут быть задействованы. Однако, если на этом этапе прототип не подтверждает первоначальные предположения, важно серьезно подумать, стоит ли продолжать.
3. Готово к производству: этот этап посвящен подготовке модели к запуску в производственной среде с соблюдением и превышением нормативных требований и всех применимых критериев конфиденциальности. Код модели и все зависимые компоненты должны быть полностью автоматизированы, чтобы модель могла работать без ручного вмешательства. План того, как модель будет поддерживаться в производстве, должен быть задокументирован, в том числе, кто будет нести ответственность за решение проблем по мере их появления, ожидаемые сроки их решения и с кем еще следует связаться или уведомить, включая ответственного владельца.
4. Развертывание: на этом этапе модель перемещается в производственную среду и настраивается на выполнение в соответствии с определенным расписанием. Источники данных также загружаются и обновляются в соответствии с установленным графиком. Группа инженеров или другая группа может нести ответственность за фактическое развертывание и требует поддержки от владельца модели для решения любых проблем развертывания. Важно заключить контракт на данные с поставщиками данных и заинтересованными сторонами, чтобы обеспечить документирование ожиданий.
5. Производство и мониторинг: на этом этапе модель работает в соответствии с определенным графиком и отслеживается. Любые проблемы, возникающие во время выполнения, решаются в соответствии с уже установленным планом поддержки. Необходимо выяснить и понять первопричину любых сбоев, чтобы они не повторялись. На этом этапе важно постоянно улучшать инфраструктуру и возможность поддержки модели, чтобы улучшить ее качество в будущем.
6. Прекращение поддержки. Этот этап применяется, когда принимается решение больше не поддерживать модель, потому что стоимость слишком высока, существует более новая модель или принятие не соответствует ожиданиям. Прежде чем остановить запуск модели в производстве, важно уведомить заинтересованные стороны и других пользователей и указать им путь вперед.

К другим широко используемым процессам жизненного цикла модели машинного обучения относятся межотраслевой стандартный процесс интеллектуального анализа данных (CRISP-DM), командный процесс анализа данных (TDSP) и обнаружение знаний в базах данных (KDD).

Общение с заинтересованными сторонами и руководством

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

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

Примеры общения

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

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

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

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

Метаданные модели и статус выполнения

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

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

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

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

Мониторинг производительности модели (MPM)

Мониторинг производительности модели включает два ключевых аспекта. Первый - это дрейф концепции, а второй - дрейф данных.

Дрейф концепций

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

Например, представим, что мы можем вернуться в прошлое и применить модель для прогнозирования оттока клиентов на заре развития телекоммуникационной отрасли. Сначала номера телефонов были привязаны к поставщику услуг, например AT&T, T-Mobile и так далее. Клиенты, которые не были довольны их услугами, не хотели вносить изменения, потому что они не хотели менять свой номер телефона. Представьте себе разработку модели оттока в то время, когда не было переносимости номеров, и что она хорошо предсказывает отток в этой среде. А теперь вспомните те времена, когда была введена переносимость номеров, и многие клиенты, недовольные их услугами, начали переходить к другим поставщикам услуг, сохраняя при этом свой номер телефона. В связи с этим изменением бизнес-сценария, не предполагавшимся при создании модели, прогноз больше не действителен: изменилось ключевое предположение, на котором он основывался. Появился новый бизнес-сценарий, который может вызвать более высокий отток.

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

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

Дрейф данных

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

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

В CGA мы автоматизировали процесс мониторинга производительности модели со следующими возможностями:

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

Проверка модели

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

1. Проблемы науки о данных (мониторинг данных, скоринговый мониторинг)
2. Проблемы с операциями (системный мониторинг)

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

• Распределение прогнозов модели (алгоритмы регрессии) или частоты (алгоритмы классификации).
• Распределение входных данных модели (числовые признаки) или частоты (категориальные признаки), а также проверка отсутствующих значений.

Мониторинг ввода модели

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

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

Вот пример того, как мы включили мониторы наборов данных в Машинное обучение Azure (AML), чтобы включить эту поддержку:

Мониторинг вывода модели

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

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

Вот пример, в котором мы можем сравнить распределение подсчетов по месяцам.

Зависимость модели

Модели не существуют изолированно. Часто данные перетекают в модели, генерируя выходные данные, которые затем могут быть переданы в другие модели. Например, если у вас есть модель, которая прогнозирует вероятность оттока в будущем, она, вероятно, будет иметь результат, который будет использоваться для многих последующих моделей с учетом вероятности оттока. Из-за этих взаимозависимостей могут возникнуть непредвиденные последствия - например, последующие модели могут быть нарушены, когда данные или модели изменяются в восходящем направлении.

Модели могут зависеть от переменных, которые создаются или хранятся другими системами машинного обучения (внутренними или внешними). Эти системы могут изменить способ получения данных, и, к сожалению, часто об этом не сообщается четко. Эффект цепочки заключается в том, что сегодняшние переменные не идентичны тем, которые были созданы пару лет назад. Либо код функции изменится, результаты могут немного отличаться, либо описание функции может измениться. Например, внешняя система может регулировать возраст вождения с 16 до 18 лет. Если возраст вождения является важной характеристикой модели, это изменит ее прогнозы.

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

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

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

Телеметрия использования модели и отслеживание заинтересованных сторон

Чтобы проверить влияние модели, важно установить такие метрики, как влияние на доход или принятие клиентами. После согласования показателей важно автоматизировать их с помощью телеметрии. Как минимум, телеметрия модели должна измерять принятие клиентами, отзывы пользователей и статус выполнения модели. Модель телеметрии должна подтверждать допущения, сделанные во время разработки проекта о заинтересованных сторонах, которые, как ожидается, примут. В CGA мы управляем более 60 моделями машинного обучения и многочисленными заинтересованными сторонами. Возможность отслеживать отношения между моделями и заинтересованными сторонами имеет решающее значение для обеспечения точного взаимодействия с соответствующими заинтересованными сторонами и правильности нашего анализа влияния модели.

Заключение

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

Мы хотели бы поблагодарить Рона Сиелински и Кейси Дойла за помощь в рецензировании работы.

Статья по теме: MLOps: управление моделями, развертывание и мониторинг с помощью машинного обучения Azure.

Также этого автора: