Ответ
В рабочем ML-проекте по прогнозированию оттока клиентов итоговая оценка качества была многоэтапной и включала как оффлайн-метрики, так и онлайн-валидацию.
1. Оффлайн-оценка на hold-out и кросс-валидации: Основной задачей была бинарная классификация. Поскольку классы были несбалансированы (отток ~15%), основной метрикой выбрали ROC-AUC, так как она устойчива к дисбалансу и показывает качество ранжирования. Дополнительно отслеживали Precision@Top-200, потому что бизнес мог точечно работать только с небольшим числом клиентов с самым высоким скором оттока.
from sklearn.metrics import roc_auc_score, precision_score
import numpy as np
# y_true_true, y_pred_proba - истинные метки и предсказанные вероятности
roc_auc = roc_auc_score(y_true, y_pred_proba)
print(f"ROC-AUC на тестовом наборе: {roc_auc:.3f}")
# Рассчитываем Precision для 200 клиентов с наибольшей вероятностью оттока
top_k_indices = np.argsort(y_pred_proba)[-200:]
precision_top_k = precision_score(y_true[top_k_indices], (y_pred_proba[top_k_indices] > 0.5))
print(f"Precision@Top-200: {precision_top_k:.3f}")2. A/B-тест в production: После оффлайн-валидации модель запускалась в A/B-тесте. Контрольная группа пользователей получала прогнозы от старой эвристической системы, тестовая — от новой ML-модели. Ключевой бизнес-метрикой было снижение реального оттока в тестовой группе за месяц. Мы также мониторили guard-метрики, такие как количество исходящих обращений в поддержку (чтобы наша активная работа с клиентами из «группы риска» не вызывала негативную реакцию).
3. Мониторинг после внедрения: После успешного A/B-теста и полного rollout'а мы настроили мониторинг:
- Дрейф данных (Data Drift): Сравнивали распределение ключевых фичей (например, частота транзакций) между обучающей выборкой и текущим трафиком.
- Дрейф концепции (Concept Drift): Отслеживали падение скользящего ROC-AUC на отложенной выборке.
- Бизнес-метрики: Коррелировали предсказанный скор оттока с фактическим оттоком в последующие периоды.
Такой комплексный подход позволял быть уверенным не только в математической корректности модели, но и в ее реальном бизнес-воздействии.
Ответ 18+ 🔞
Давай разберём эту историю про оценку модели, чтобы не было как в том анекдоте — построили, запустили, а она нихуя не работает. Тут подход был, в принципе, здравый, не на коленке слепленный.
1. Сначала проверили на отложенной выборке и кросс-валидации. Задача стандартная — бинарная классификация: уйдёт клиент или нет. Но классы несбалансированные, отток всего около 15%. Если бы мы смотрели на accuracy, то могли бы охуеть от красивых цифр, просто предсказывая всем "не уйдёт". Поэтому основным мерилом выбрали ROC-AUC. Она, во-первых, от баланса классов не зависит, а во-вторых, показывает, насколько хорошо модель ранжирует клиентов — кто реально в зоне риска, а кто нет. Это самое важное.
Плюс, добавили Precision@Top-200. Логика простая: бизнес-ребята физически не могут обзвонить всех десять тысяч человек, которых модель пометила как рискованных. У них ресурсов хватит, условно, на пару сотен самых "горячих". Вот и надо понять: из этих двухсот у кого реально самый высокий шанс сваливать? Если из 200 с самым высоким скором оттока реально уйдут 50 — это уже офигенный результат для отдела удержания.
from sklearn.metrics import roc_auc_score, precision_score
import numpy as np
# y_true_true, y_pred_proba - истинные метки и предсказанные вероятности
roc_auc = roc_auc_score(y_true, y_pred_proba)
print(f"ROC-AUC на тестовом наборе: {roc_auc:.3f}")
# Рассчитываем Precision для 200 клиентов с наибольшей вероятностью оттока
top_k_indices = np.argsort(y_pred_proba)[-200:]
precision_top_k = precision_score(y_true[top_k_indices], (y_pred_proba[top_k_indices] > 0.5))
print(f"Precision@Top-200: {precision_top_k:.3f}")2. Потом — святая святых — A/B-тест в продакшене. Оффлайн-метрики — это, конечно, хорошо, но доверия к ним, блядь, ноль, пока не проверишь в бою. Запустили эксперимент: одна группа клиентов получала прогнозы от старой, допотопной системы на эвристиках (контроль), а другая — от нашей новой ML-модели (тест). Главной бизнес-метрикой было реальное снижение оттока в тестовой группе за месяц. Не какие-то там вероятности, а живые люди, которые остались. Параллельно следили за guard-метриками, например, за количеством жалоб в поддержку. А то мало ли: начнём мы названивать клиентам из "группы риска" с навязчивыми предложениями, а они, вместо того чтобы остаться, ещё быстрее нахуй сбегут, да ещё и негатив на весь бренд наведут. Такое бывает, ёпта.
3. И наконец, мониторинг после полного внедрения. Когда A/B-тест показал, что модель таки работает, и её запустили на всех, расслабляться было рано. Настроили постоянный присмотр:
- Дрейф данных (Data Drift): Сравнивали, не поменялись ли распределения ключевых признаков (скажем, средний чек или частота заказов) между теми данными, на которых учили модель, и тем, что приходит сейчас. Вдруг мир изменился, а модель — нет.
- Дрейф концепции (Concept Drift): Следили, не падает ли скользящий ROC-AUC на свежих отложенных данных. Бывает, связь между признаками и целевой переменной со временем рвётся — модель начинает нести хуйню, а мы и не в курсе.
- Бизнес-метрики: Постоянно смотрели, насколько предсказанный риск оттока коррелирует с реальным оттоком в последующие недели. Чтобы не получилось "модель говорит, что риск высокий, а человек уже десять лет как не клиент".
Вот такой, блядь, многослойный бутерброд. Цель — не просто похвастаться красивым AUC на Kaggle, а быть уверенным, что эта железяка в проде реально приносит пользу, а не просто жрёт вычислительные ресурсы. Иначе зачем всё это, спрашивается?