Обнаружение дрейфа

Погорелов Петр — ML Engineer

Прямое измерение Model Drift

Позволяет измерить дрейф модели напрямую.
Выполняется с помощью замера offline метрики (Precision, Recall, AUC-ROC, RMSE, …).
Требует оперативного получения разметки целевой величины (не всегда доступно).

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

Наибольшее влияние на предсказательную силу модели оказывает Concept Drift, и для нас, как разработчиков ML системы - было бы правильным попытаться отследить именно его. Concept Drift представляет собой изменение структурной связи между факторами и целевой величиной, и наиболее очевидный способ его обнаружения - это периодический замер оффлайн-метрик вроде ROC-AUC, F1, Precision, Recall; R^2, RMSE и тд на новых размеченных данных, и проверка насколько сильно они деградировали относительно того момента, когда модель была обучена.

Естественно, на практике - не все так просто. Есть ряд задач, в которых новая разметка органично формируется на регулярной основе, как например - в задачах построения рекомендаций. В таких случаях действительно разумно опереться на оффлайн метрики модели и реализовать мониторинг феномена Concept Drift’a. Однако часто возникает ситуация когда разметку нужно отдельно запрашивать у асессоров, то есть - разметка дорогая и приходит с лагом.

Косвенное измерение Model Drift

Позволяет измерить дрейф модели по косвенным признакам.
Опирается на изменение распределения целевой величины / описательных признаков.

Альтернативный способ обнаружения Model Drift’a - это мониторинг Data Drift’a. Если у нас доступна целевая величина - то можно мониторить феномен Label Shift, но тут встает вопрос рациональности. Наличие Label Shift не является достаточным условием для деградации качества модели, и если у нас доступна целевая величина - то лучше сразу реализовать механизм мониторинга явления Concept Drift.

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

Обнаружение. Статистики.

Есть два основных подхода для обнаружения Model Drift. Первый из них - сравнение статистик распределений (среднее, медиана, персентили, дисперсия, коэффициенты асимметрии и эксцесса распределения) между контрольным и тестовым периодом. Этот подход применим как для детекции Concept Drift’a, так и для Data Drift’a. В первом случае мы мониторим отклонение целевой метрики от экспертно заданного диапазона (например, не хотим чтобы метрика Precision опускалась больше чем на 20% относительно контрольного периода). Во втором случае - мониторим отклонение целевой величины, либо описательных признаков.

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

Обнаружение. Статистические тесты.

Постановка:

Нулевая гипотеза (H0): Распределения source и target - не отличаются.
Альтернативная гипотеза (H1): Распределения source и target - отличаются.

Статистические тесты

Непрерывные величины: тесты Смирнова-Колмогорова и Андерсена Дарлинга, бутстрап.
Категориальные величины: тест Хи-квадрат.
Векторные величины: тесты на базе Maximum Mean Discrepancy, Least-Squares Density Difference.

Второй способ обнаружение Model Drift’a основан на применении статистических тестов. Мы формируем нулевую гипотезу о том что отслеживаемая нами величина распределена одинаково за тестовый и контрольный период. Альтернативная гипотеза говорит что распределение отличается. Если величина имеет вещественный тип - можно использовать тесты Смирнова-Колмогорова [2], Андерсена-Дарлинга [3], либо тест на базе бутстрапа. Тест на базе бустрапа вычислительно более сложный и его имеет смысл использовать в том случае, если у нас нет жестких требований по времени ответа сервиса мониторинга. Если величина распределена по дискретному закону - то хорошим вариантом будет использовать тест Хи^2 [4].

Если же величина представляет собой вектор (например, мы работаем с изображениями), то можно использовать перестановочный тест [5] на базе величины Maximum Mean Discrepancy [6] либо величины Least-Squares Density Difference [7].

[2] https://www.itl.nist.gov/div898/handbook/eda/section3/eda35g.htm [3] https://www.itl.nist.gov/div898/handbook/eda/section3/eda35e.htm [4] https://www.itl.nist.gov/div898/handbook/eda/section3/eda35f.htm [5] https://en.wikipedia.org/wiki/Permutation_test [6] https://docs.seldon.io/projects/alibi-detect/en/latest/cd/methods/mmddrift.html [7] https://docs.seldon.io/projects/alibi-detect/en/latest/cd/methods/lsdddrift.html

Сезонность

Если мы выполняем мониторинг явления Concept Drift’a, иными словами - опираемся на технические метрики качества модели, то наличие сезонности в данных - не должно быть для нас проблемой. В идеальном сценарии модель должна демонстрировать стабильное качество вне зависимости от сезонных циклов. С другой стороны - при мониторинге описательных признаков модели сезонность может стать головной болью.

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

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

Пакетный и поточный мониторинг

Поточный (стримовый) мониторинг качества дрейфа

Плюсы:

Предоставляет оперативные данные (дрейф рассчитывается в реальном времени).
Позволяет настроить оперативную систему оповещений / триггеров.

Минусы:

Затруднительно мониторить Concept Drift, даже если целевая величина доступна в логах.
Технически сложно реализовать.
В случае сбоя потокового сервиса мониторинга, могут некорректно отработать оповещения / триггеры.
Чувствительность к выбросам.

Пакетный (батчевый) мониторинг качества дрейфа

Плюсы:

Низкая чувствительность к выбросам.
Позволяет строить более-сложные алгоритмы расчета метрик.
При наличии целевой величины в логах - можно мониторить Concept Drift.
Технически просто реализовать.

Минусы:

Не применимо для бизнес-сценариев, когда важно оперативно реагировать на деградацию модели.

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

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

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

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