Почему модель в проде деградируети как это заметить

Модель сдали с точностью 94%. Через восемь месяцев пользователи начинают жаловаться, замер показывает 79%. Код не менялся, ошибок в логах нет. Изменился мир вокруг модели — и это происходит со всеми моделями без исключения. Разберём, почему так, какие бывают виды деградации и что нужно измерять, чтобы узнавать об этом из мониторинга, а не из жалоб.

Модель — это снимок прошлого

Модель выучила закономерности данных на момент обучения. Она не адаптируется сама: если реальность сдвинулась, модель продолжает уверенно применять устаревшие правила. Причём качество падает постепенно, без единого момента поломки, — поэтому заметить сдвиг без измерений почти невозможно.

Три вида дрейфа

Меняются входные данные

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

Меняется связь между данными и результатом

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

Модель меняет реальность, на которой училась

Самый неочевидный вид. Антифрод-модель блокирует схему — мошенники меняют схему, и данные, на которых модель училась, больше не встречаются. Рекомендательная система продвигает товары, влияя на продажи, и следующая версия учится на данных, которые сама и сформировала. Модель обучается на последствиях собственной работы.

Что мониторить

Уровень первый: технические метрики

Доступность, время ответа, доля ошибок, объём запросов. Это базовая гигиена — она ловит поломки, но не деградацию качества. Модель может отвечать быстро, стабильно и неправильно.

Уровень второй: распределение данных

Сравнение того, что приходит сейчас, с тем, что было при обучении. Появились ли новые значения категорий, сдвинулись ли средние, изменилась ли доля пропусков. Ловит первый вид дрейфа и не требует знания правильных ответов — поэтому работает в реальном времени.

Уровень третий: поведение модели

Распределение предсказаний и уверенности. Если модель начала чаще выдавать один класс или в среднем стала менее уверенной — это сигнал до того, как появятся жалобы. Дёшево в реализации и удивительно информативно.

Уровень четвёртый: фактическое качество

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

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

Когда переобучать

Есть три стратегии, и выбор между ними зависит от того, как быстро меняются ваши данные.

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

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

Чего нельзя делать при переобучении

• Выкатывать новую версию без сравнения со старой на одинаковых данных. Новее не значит лучше — регрессии случаются регулярно.
• Обучаться на данных, сформированных предыдущей версией модели, без учёта этого факта. Так модель закрепляет собственные ошибки и уходит от реальности.
• Терять возможность откатиться. Предыдущая версия должна оставаться доступной, а переключение — быть вопросом минут.
• Менять модель и обработку данных одновременно. При ухудшении результата будет непонятно, что именно виновато.

Что заложить в проект с самого начала

1. Логирование всех входов и предсказаний с версией модели. Без этого невозможно ни расследовать ошибку, ни собрать данные на переобучение.
2. Механизм сбора истинных ответов — автоматический там, где возможно, выборочно-ручной там, где нет.
3. Мониторинг с порогами и оповещением ответственному, а не дашборд, на который никто не смотрит.
4. Воспроизводимый процесс обучения: одна команда, тот же результат. Иначе переобучение через год превратится в исследование.
5. Процедуру приёмки новой версии: на каких данных сравниваем, какой прирост считаем достаточным, кто принимает решение.

Кто за это отвечает

Самая частая организационная причина деградации — отсутствие ответственного. Проект сдан, подрядчик ушёл, ИТ считает, что это бизнес-система, бизнес считает, что это ИТ. Модель работает сама по себе ровно до первой заметной ошибки.

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

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

Инциденты: что делать, когда качество упало

Падение качества — рабочая ситуация, а не катастрофа, если для неё есть процедура. Порядок разбора обычно такой.

1. Убедиться, что упало именно качество, а не сломалась подача данных. Половина «деградаций» оказывается изменившимся форматом выгрузки или отвалившимся полем.
2. Посмотреть, изменилось ли распределение входов. Если да — это дрейф данных, и понятно, что делать.
3. Проверить, не менялся ли процесс. Новый поставщик, новый регламент, обновление смежной системы — типичные причины.
4. Локализовать: упало везде или на конкретном сегменте. Часто выясняется, что проблема только в одном типе входа, и лечится точечно.
5. Решить, что делать сейчас: снизить порог автоматики и отправить больше случаев человеку — временная мера, которая держит процесс, пока готовится переобучение.
6. Переобучить на свежих данных и сравнить со старой версией на одинаковой выборке перед выкаткой.

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

Сколько стоит эксплуатация

Ориентир, который мы обычно называем: 15–25% стоимости проекта в год. Разброс определяется тем, как быстро меняются ваши данные и насколько критична система.

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

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

Минимальный набор, который стоит завести сразу

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

1. Логирование входов и предсказаний с версией модели и меткой времени.
2. Ежедневный отчёт по распределению предсказаний с оповещением при существенном сдвиге.
3. Выборочная ручная проверка сотни случаев в месяц силами специалиста.
4. Воспроизводимый процесс обучения: одна команда, зафиксированные данные и параметры, тот же результат.
5. Хранение предыдущей версии модели и возможность переключиться на неё за минуты.
6. Регламент: кто смотрит на метрики, с какой периодичностью и что делает при отклонении.

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

Как выкатывать новую версию

Переобучение — половина дела; вторая половина в том, как новая версия попадает в эксплуатацию. Здесь есть отработанные приёмы, и они недорогие.

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

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

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

Как это выглядит в разных типах задач

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

• Распознавание документов известных типов деградирует медленно. Основной источник изменений — новые контрагенты со своими формами. Проверки раз в квартал обычно достаточно.
• Контроль качества по изображению чувствителен к физическим изменениям: освещение, оснастка, партия сырья. Здесь мониторинг должен быть постоянным, а переобучение — по триггеру.
• Прогноз спроса ломается на изменениях ассортимента и промо-активности. Регулярное переобучение на свежих данных здесь норма, а не исключение.
• Антифрод и выявление аномалий деградируют быстрее всего, потому что противодействующая сторона адаптируется. Это самый требовательный класс задач по эксплуатации.
• Поиск по документам почти не деградирует как модель, но страдает от устаревания корпуса. Здесь следить надо не за моделью, а за актуальностью документов.

Практический вывод: регламент обслуживания составляется под конкретную задачу на этапе проектирования, а не берётся типовым. И он должен быть записан — в виде документа с периодичностью проверок, порогами и ответственными, а не в виде устной договорённости, которая забудется через полгода вместе со сменой сотрудников.

Коротко

• Модель — снимок прошлого; деградация неизбежна и происходит постепенно, без момента поломки.
• Дрейф бывает трёх видов, и самый опасный — изменение связи между данными и результатом: по входам он не виден.
• Минимум мониторинга: распределение входов, распределение предсказаний, выборочная проверка сотни случаев в месяц.
• Переобучение по триггеру плюс обязательная проверка раз в квартал — рабочий выбор для большинства задач.
• Логирование, воспроизводимость обучения и возможность отката закладываются в первый же релиз, а не добавляются потом.