ML-модели деградируют молча - и большинство компаний этого не замечает
Модель, которая была точной при запуске, постепенно перестаёт быть точной по мере того, как меняется мир. Почему мониторинг деградации модели не является опциональным, и как настроить его до того, как это превратится в инцидент.
Деплой модели машинного обучения часто воспринимается как финишная черта. Модель прошла валидацию, результаты выглядели хорошо, и теперь она работает в продакшне. Тому, что происходит дальше, уделяется значительно меньше внимания.
Модели деградируют. Мир, на котором они обучались, меняется. Поведение клиентов смещается. Продуктовый микс эволюционирует. Сезонные паттерны дрейфуют. Модель продолжает выдавать предсказания с той же видимой уверенностью, пока её точность тихо снижается. Поскольку формат вывода не меняется, никто не замечает - до тех пор, пока это не становится очевидным из бизнес-результатов.
Почему это отличается от программных багов
Классический программный баг имеет чёткий симптом: система падает, возвращает ошибку или выдаёт видимо неверный результат. Деградация модели медленнее и тише. Предсказания по-прежнему числено валидны. API по-прежнему отвечает. Единственный сигнал - бизнес-результаты, связанные с выводом модели, начинают ухудшаться, а эта связь редко очевидна тем, кто замечает ухудшение.
Это делает деградацию модели значительно проще для игнорирования, чем сбой сервиса. Никакого алерта нет. Есть лишь постепенный дрейф, который всплывает в бизнес-метриках через месяцы - к тому времени модель может значительно отклониться от исходной точности.
Что её вызывает
Наиболее распространённые причины, которые я встречаю в продакшн-системах, - это сдвиг распределения и концептуальный дрейф.
Сдвиг распределения означает, что статистические свойства входных данных изменились. Если модель обучалась на данных клиентов за 2015-2017 годы и теперь оценивает клиентов, которые ведут себя иначе из-за эволюции продукта или рынка, - входные данные больше не соответствуют обучающему распределению.
Концептуальный дрейф тоньше: сама взаимосвязь между входами и тем, что предсказывается, изменилась. Модель прогнозирования оттока, обученная на рынке без конкуренции, могла научить ассоциациям, которые перестали работать после появления крупного конкурента.
Оба явления нормальны. Это не сбои исходной модели. Это факты о том, как меняется мир.
Как выглядит мониторинг
Минимально жизнеспособная настройка для продакшн-модели включает три вещи.
Первое - отслеживайте распределение входных данных во времени. Если признаки, которые потребляет модель, начинают статистически отличаться от того, на чём она обучалась, это ранний сигнал. Это можно сделать простыми статистическими тестами на выборке недавних входных данных.
Второе - фиксируйте ground truth, когда он становится доступным. Если модель предсказывает отток и клиент через 30 дней либо ушёл, либо нет - это точка данных. Логируйте предсказания с меткой времени и связывайте их с результатами по мере их поступления. Это даёт вам реальную кривую точности во времени.
Третье - установите триггер дообучения. Не календарную дату, а порог: когда измеренная точность падает ниже X, инициируется цикл переобучения. Что такое X, зависит от бизнес-цены деградировавших предсказаний.
Организационная часть
Ничего из этого технически сложным не является. Сложным это делает организационный аспект. Команда, которая строила модель, часто уже перешла к следующему проекту. Команда, эксплуатирующая систему, может не знать, что модель существует как отдельный компонент, требующий мониторинга. А бизнес-команда, наблюдающая за результатами, может не связывать ухудшение с ML-компонентом, о котором она ничего не знает.
Ответ прост: каждая модель, задеплоенная в продакшн, должна иметь владельца, который отвечает за её точность во времени, а не только за первоначальный деплой. Этот владелец получает алерты и отвечает за инициирование переобучения, когда сигнал это требует.
Относиться к деплою модели как к концу проекта - это способ, которым дорогостоящие инвестиции в ИИ тихо перестают приносить ценность.