Качество модели против свежести данных: что важнее в прикладной аналитике
В большинстве реальных задач выигрывает не более умная модель, а более правильно настроенная операционная петля обновления данных.
В разговорах об аналитических проектах я часто слышу один и тот же вопрос: нам нужна более сложная модель или достаточно того, что есть? За этим вопросом стоит допущение, что именно модель определяет качество результата.
В реальности это допущение верно реже, чем кажется. Для большинства прикладных задач - прогнозирование спроса, скоринг клиентов, предсказание оттока - определяющим фактором оказывается не сложность модели, а то, насколько актуальны данные, на которых она работает.
Это не значит, что модели не имеют значения. Это значит, что инвестиция в более сложную модель при устаревших данных даёт меньший эффект, чем инвестиция в операционную петлю, которая держит данные свежими. Этот принцип прямо следует из того, что качество данных первично по отношению к аналитике.
Почему свежесть данных важнее, чем кажется
Рассмотрим задачу прогнозирования оттока клиентов. Модель обучена на исторических данных о поведении: частота покупок, сумма среднего чека, давность последней активности.
Если эти данные обновляются раз в месяц, то модель на протяжении месяца работает с картиной, которая устарела в момент её получения. Клиент, который три недели назад купил и больше не возвращается - по-прежнему выглядит активным. Клиент, у которого изменился паттерн поведения - этого изменения ещё не видно.
Более умная модель на тех же устаревших данных даст более умный ответ на устаревший вопрос. Это редко то, что нужно.
Операционная петля - это не только технический вопрос
Операционная петля - это весь цикл от возникновения события в реальном мире до момента, когда это событие отразилось в данных, на которых работает модель.
Событие произошло. Данные обновились. Модель переобучилась или получила новые признаки. Предсказание скорректировалось. Решение принято.
Длина этой петли определяет, насколько хорошо система реагирует на изменения реальности. И в большинстве компаний эта петля не управляется сознательно - она просто такая, какая сложилась.
Типичная картина: транзакционные данные - в CRM, который интегрируется с аналитикой раз в ночь. Ночная аналитика идёт на склад данных, который обновляет признаки для модели раз в неделю. Модель переобучается раз в квартал. В итоге реальный мир и то, что видит модель, расходятся на недели.
Когда сложность модели действительно важна
Есть задачи, где модель принципиальна. Как правило, это задачи, где:
- данные свежи и хорошо структурированы;
- базовая логистическая регрессия или дерево решений уже упирается в потолок качества;
- есть возможность чётко измерить улучшение и сопоставить с затратами.
Это хороший порядок рассуждений: сначала убедиться, что данные актуальны и чисты, убедиться, что простая модель действительно упёрлась в потолок, и только потом инвестировать в сложность.
На практике шаг "убедиться, что простая модель упёрлась в потолок" часто пропускается. Команда сразу переходит к более сложной модели, потому что это интереснее.
Конкретный тест
Если у вас есть аналитическая модель в production - задайте себе несколько вопросов:
- С какой задержкой реальные события попадают в данные, на которых работает модель?
- Когда последний раз переобучалась модель и на данных какого периода?
- Если бы данные обновлялись в два раза чаще - насколько изменилось бы качество предсказания?
- Есть ли задокументированный базовый ориентир (baseline) - насколько хорошо работает простейшая эвристика для той же задачи?
- Когда в последний раз проверяли, не изменилось ли распределение входных данных со времени обучения?
Ответы на эти вопросы чаще всего указывают на то, что нужно улучшать - и это редко оказывается архитектура модели.