Сегодня просто написать хорошую модель уже недостаточно: важно постоянно следить за её предсказаниями, так как поведение клиентов меняется со временем, и модель может терять в их качестве. Чтобы эффективно отслеживать её работу, нужна система мониторинга, которая определяет методы и частоту проверок, критерии отклонений. Построение целой системы часто пугает ML-команды объёмом работ — так модели остаются и вовсе без мониторинга.
Одна из наших моделей, которая предсказывает отток клиентов, начала выдавать странные результаты. Стоит отметить, что она на тот момент уже не использовалась, поскольку была разработана новая, но старая оставалась как индикатор оттока с устаревшей методологией. Мы решили разобраться в странном поведении и понять, какие признаки нужно добавить в мониторинг, чтобы не упускать важные детали из виду.
В чём проблема старой модели
В начале 2024 года мы заметили, что старая модель оттока начала показывать рост клиентов с высокой вероятностью ухода. У нас также были выстроены аналитические сигналы, по которым мы не видели каких-то сильных изменений, а значит, не наблюдали роста оттока. Действующая модель также не показывала, что наши клиенты хотят от нас уйти. Тем не менее, мы продолжили наблюдать, чтобы проверить предсказания и подтвердить или опровергнуть наши опасения.
Подождав три месяца, мы посмотрели реальные данные, и не обнаружили схожести с предсказаниями старой модели. Значит, она давала нам ошибочные прогнозы.
Расскажем немного о старой модели. С момента первого предсказания мы следили за моделью и выявили её особенности:
Первая связана с расчётами на определённые дни месяца: доля клиентов в каждом бине предсказаний менялась, но тенденция сохранялась. Мы думали, что это связано с поведением клиентов в разные периоды месяца, но, забегая вперед, эта гипотеза будет опровергнута в процессе исследования.
Вторая особенность — нерегулярные предсказания из-за нагрузки системы. Пропуски дней были допустимы, так как предсказания не использовались ежедневно, но в какой-то момент мы всё равно решили оптимизировать процесс.
Во время работы с моделью мы делили клиентов на четыре группы по вероятности оттока — это помогало нам целенаправленно работать с каждой группой, в скобочках указали вероятность оттока:
Самые здоровые (0-0.01): эти клиенты точно не собираются уходить, их всё устраивает.
Здоровые (0.01-0.1): имеют необычное поведение, но в целом довольны. Хорошо идут на контакт, но использовать инструменты удержания нет смысла.
Сомневающиеся (0.1-0.3): недовольны или заинтересованы предложениями конкурентов. Продолжают работать с нами, но уже склонны к оттоку. Мы фокусировались на этой группе, так как они готовы обсуждать проблемы.
Оттекающие (0.3-1): настроены уйти в ближайшие месяцы и почти не реагируют на предложения.
Теперь, зная особенности старой модели, можно приступать к исследованию причин неверных предсказаний. Проанализируем результаты и попытаемся снизить негативное влияние на модель.
Наш план действий на время исследования:
Рассчитать метрики модели и найти отклонения.
Провести тесты на дрифт фичей и исправить проблемные.
Сделать новые предсказания для исправленных фичей.
Сравнить результаты до и после исправлений.
Итак, проблема определена, цель ясна, план написан. Можно приступать к исследованию!
Как мы исследовали качество предсказаний модели
При обучении и тестировании модели мы фиксировали целевые показатели, которыми определяли, что предсказаниям нашей модели можно доверять:
ROC AUC.
Average Precision.
LogLoss.
Использование этих показателей поможет нам получить более полную картину работы нашей модели, выявить крупные проблемы и небольшие неточности в конкретных бинах предсказаний.
После расчёта показателей мы приступили к проверке качества предсказаний. Поскольку обучающие выборки были утеряны, мы использовали продовые данные за первый месяц работы модели как референс. Выбрали именно этот месяц, потому что портрет клиента изменился минимально, и в нём не было значительных праздников или других нюансов.
Теперь мы имеем два показателя:
Исходные — продовые значения за первый месяц. В таблице ниже будем называть reference.
Новые — значения с июня 2023 по май 2024. Чтобы понять, что у нас произошли расхождения в ключевых показателях, мы задали исходным величинам допустимые отклонения.
Внизу привели таблицу со всеми результатами. Слева наши показатели, цветом показано, насколько значение низкое в сравнении с другими внутри своего столбца. В правой стороне рассчитаны отклонения показателей, красным подсвечены ситуации, когда новые и исходные величины различаются.
Из этих расчётов видно, что метрика ROC AUC не подсвечивает проблем с моделью, но можно присмотреться, что значения наиболее сильно проседают с января по март. В случае с AP мы уже наблюдаем ощутимую разницу в показателях, но в этой ситуации метрика наоборот стала лучше. У последнего показателя, мы можем рассмотреть самые сильные изменения. LogLoss резко вырос с января и сохраняет достаточно высокие значения. Проанализировав все показатели, мы убедились в снижении качества предсказаний старой модели оттока.
Далее мы построили таблицу, где для каждой группы клиентов в определённом бине предсказаний рассчитали реальный отток. Сравнив предсказанные и реальные данные, обнаружили интересную закономерность: клиенты с более высокими предсказаниями оттока на самом деле имеют более низкую вероятность оттока. При этом с начала 2024 года наблюдается устойчивый рост числа таких клиентов.
После общего анализа модели мы перешли к фичам. Важно помнить, что фичи делятся по степени влияния на предсказание. Мы искали баланс между затрачиваемыми ресурсами и важностью фичей, поэтому начали с самых значимых. Не обращали внимания на дрифт малозначимых признаков, так как они не сильно влияют на итоговые предсказания.
После ранжирования фичей по важности мы выбрали порог, который отсек признаки с маленьким влиянием, по порогу получили 50 самых значимых для анализа. Проверили их качество и дрифт данных с помощью двух контрольных точек в месяце: 1-е и 15-е число, что позволило сравнить разные наборы признаков.
Для расчёта тестов и визуализации была выбрана уже проверенная нами библиотека Evidently AI: в ней есть нужные тесты и она работает с большими данными.
Для определения дрифта фичей выбрали эти тесты:
Population Stability Index (PSI): менее чувствителен к малым изменениям, но реагирует на значительные. Разделяет значения на бины, что помогает заметить переход значений в другие интервалы.
Wasserstein distance/Jensen-Shannon distance: более чувствителен к изменениям, полезен для обнаружения умеренного дрифта.
Важная деталь — предварительное изучение данных и статистических тестов. Рассмотрим первый используемый тест — Wasserstein distance. Его базовое определение предполагает, что он является симметричным. Но для лёгкой интерпретации значение предлагают нормировать. В библиотеке Evidently результат делится на стандартное отклонение reference. Это делает метрику несимметричной, поэтому стоит обращать внимание на порядок аргументов. Также метрика стала сильно зависимой от разброса значений в reference. Это значит, что мы можем не заметить изменений в распределениях, когда наблюдаем в reference слишком большой разброс значений.
Одно из главных отличий PSI от других тестов — разбиение распределения фичи на промежутки. Выбор функции, которая будет задавать эти границы данных — ключевой компонент, поскольку именно он влияет на частоту срабатывания теста. Разбивка в библиотеке Evidently не чувствительна к колебаниям около определённого значения при широком диапазоне данных. В таком подходе мы опять рискуем не заметить изменения в распределении фичи из-за высокой дисперсии.
В обоих случаях есть проблема, когда мы сильно зависим от разброса значений фичи. Нужно заранее ознакомиться со статистикой распределения, и в некоторых ситуациях избавиться от выбросов/слишком далеких значений от среднего. Такой первичный анализ поможет не упускать дрифт данных.
В процессе тестирования мы создали таблицу, которая отслеживает месячную динамику дрифта каждой фичи. Анализ показал, что около 15 фичей часто не проходили тесты. Исходя из полученных результатов мы выявили несколько типов дрифта:
постоянный,
периодический (каждый третий месяц),
дрифт в начале месяца,
единоразовый.
На основе этих данных мы предложили гипотезы, которые объясняют, почему фичи уходят в дрифт.
Чтобы понять, что произошло с каждой фичей, мы изучили все её значения и построили динамику среднего по выбранным датам. Это помогло выявить сильные изменения у некоторых фичей и найти несколько причин дрифта:
Изменение логики расчёта. При оптимизации кода для снижения нагрузки на БД уменьшили горизонт просмотра данных. Это сделало фичу более чувствительной к внешним изменениям, которые влияют на поведение клиента.
Добавление новых параметров. Внедрение новых каналов сбора данных, например, обновление версии сайта, может сделать старые переменные неактуальными. Важно быстро реагировать на такие изменения и своевременно добавлять новые параметры в код.
Проведение мероприятия. Массовые закрытия клиентов или переводы на новые счета могут влиять на результаты фичей. Эти события нужно учитывать при анализе.
Сезонные изменения. Квартальные налоги или экономические изменения тоже могут влиять на фичи.
После выявления причин дрифта мы попытались исправить каждую фичу. Небольшие изменения в коде помогли устранить дрифт у некоторых из них. Мы также заметили, что ошибка в одной фиче может влиять на весь блок, поэтому разделили их на смысловые группы — это упростило диагностику. Например, дрифт фичей, связанных с платежами, совпадал с мероприятиями банка, что вызвало всплески и изменения среднего значения.
Во время исследования мы обнаружили важный кейс. В нашей модели есть ключевая фича, которая больше всего влияет на предсказания. По задумке она должна была рассчитываться на данных за последние три скользящих месяца. Но в реализации была использована таблица, где данные агрегированы за каждый месяц на первое число. Получилось так, что мы неправильно собирали фичу все это время. Эта ошибка приводила к значительному росту значений от начала к концу месяца, что усложняло интерпретацию.
Кроме того, при расчёте на первое число месяца горизонт данных увеличивался до четырёх месяцев и влиял на предсказания. Мы переписали расчёт, чтобы сгладить скачки, но есть нюанс: модель изначально обучалась на данных, где параметр не менялся в течение месяца. Переписывание скрипта улучшит баланс данных, но может быть не совсем корректным.
С числовыми фичами всё понятно, но как же быть с категориальными — они же тоже могут дрифтить?
Всё верно, тесты ловили дрифт и у них. Для таких фичей мы использовали долю каждой категории среди всех клиентов за разные даты месяца. Например, у одной из фичей мы заметили резкое изменение доли в двух взаимосвязанных категориях. Эта фича связана с наличием определённого продукта у клиента. Собирая информацию, мы выяснили, что раньше этот продукт подключали всем новым клиентам, а со временем стали отключать тех, кто им не пользуется. Этот период массового отключения и вызвал дрифт одной из категориальных фичей.
Удалось ли нам полностью устранить дрифт? К сожалению, нет. Естественные факторы и мероприятия банка всё ещё влияют на фичи, и отличить их влияние от типичного поведения клиентов сложно.
Перед тем, как приступить к следующему шагу, мы решили рассчитать вероятность оттока по каждому клиенту на старых данных. Однако, результаты показали, что предсказания не совпадают с прежними. Это связано с тем, что некоторые фичи пересчитывались заново, так как не были записаны в момент первого предсказания. Восстановить все фичи в их первоначальном виде невозможно, если данные изменяются со временем. Таким образом, определить влияние конкретных фичей на результат модели сложно, поэтому сохранение исторической информации о них становится критически важным.
После исправлений и перерасчёта фичей, новые предсказания модели стали точнее совпадать с фактическим оттоком клиентов. Теперь почти в каждом месяце предсказанный отток почти полностью соответствует реальному уходу клиентов, что указывает на улучшение модели.
Мы также построили новые графики, которые показали снижение перетекания клиентов между бинами и уменьшение разброса предсказаний в течение месяца. При этом не стоит забывать, что первые числа месяца часто являются крайними случаями, и их нужно анализировать осторожно. С начала 2024 года в бине 0-0.01 осталось небольшое проседание, связанное с фичами платежей. Точную причину их дрифта установить не получилось.
После улучшения предсказаний мы пересчитали метрики. ROC AUC остался стабильным, а AP улучшился по каждому месяцу. Отклонение от референса увеличивается, но это не критично.
LogLoss улучшился, но в начале 2024 года значения всё ещё проседали. Это связано с тем, что в маленькие бины попадают клиенты, далёкие от предсказания. Мы выяснили, что отток «хороших» клиентов в этом периоде связан с прекращением работы партнёра. После исключения таких клиентов, которых было несколько сотен, мы подтвердили гипотезу: доля ушедших в бине 0-0.01 осталась стабильной.
Итоги
Что получилось сделать во время исследования:
Нам удалось достичь улучшения точности предсказания модели через снижение дрифта фичей. При этом количество клиентов, распределённых по бинам, на основе новых улучшенных предсказаний, получилось сохранить почти неизменным.
Был успешно реализован подход к устранению дрифта фичей, который не обусловлен естественными факторами. Для достижения этой цели были внесены изменения в скрипт, по которому рассчитывались фичи. В некоторых случаях приходилось возвращать старые параметры, которые были изменены в процессе оптимизации кода, а иногда добавлять новые переменные, так как старые становились неактуальными.
Пришли к следующим выводам:
Если невозможно устранить дрифт среди фичей, обусловленных естественными факторами, то, возможно, пора задуматься о переобучении модели.
Сохранение исторической информации о признаках — это важный аспект. Также стоит правильно подходить к выбору данных, на которых будут рассчитываться будущие признаки модели. Данные не должны изменяться со временем, чтобы их можно было восстановить на любое число в первоначальном виде.
В следующей статье расскажем, как мы настраивали автоматическую систему мониторинга для наших моделей, с какими трудностями столкнулись, какие кейсы уловили и смогли вовремя починить. Оставайтесь с нами!
Авторы:
Наталья Мальцева, аналитик данных.
Татьяна Бородина, аналитик данных.
Артур Сосновиков, тимлид нескольких ML-команд.