Ниже — подробный, практический ML-пайплайн для задачи мошенничества с сильно несбалансированными данными (5% положительных), с обоснованием каждого шага. Пайплайн покрывает предобработку, работу с дисбалансом, выбор метрик, подбор моделей, валидацию для временных рядов, тестирование и мониторинг в продакшне.

Ключевые принципы, которыми будем руководствоваться

Не допускать утечки по времени и по сущностям (account/user/карта).Оценивать модель с точки зрения бизнеса (стоимости ошибок), а не только по общим метрикам.Учитывать задержку и неполноту меток (labels) в фрод‑задачах.Сделать систему наблюдаемой: логирование, мониторинг дрейфа данных и деградации производительности.

1) Сбор данных и разметка (важные моменты)

Явно фиксировать временные метки транзакций и идентификаторы сущностей (account_id, card_id, user_id).Флажки и метки строить так, чтобы метка транзакции использовалась только на моментах >= времени события (никакого будущего).Фрод‑метки часто приходят с задержкой (например, chargeback через дни). Храните колонку label_time и используйте стратегии для работы с задержкой (см. раздел про задержку меток).Собирайте логи инференса (входные фичи + предсказание + timestamp + модель_id) и реальные метки по мере поступления.

2) Предобработка данных

Очистка и валидация:
Удалить явные дубликаты, проверить аномальные timestamps.Убедиться, что агрегаты/фичи построены только на исторических данных.Работа с пропусками:
Для числовых: медиана/квантили либо отдельный индикатор (is_missing) — аномалии пропусков сами по себе информативны.Для категориальных: специальная метка "".Категориальные переменные:
Для больших кардинальностей: target encoding с регуляризацией / smoothing по времени (важно: вычислять только на обучающем периоде, избегать утечки).Для малой кардинальности: one‑hot или бинарное кодирование.Числовые признаки:
Логарифмирование сильно скошенных переменных (amount).Нормализация/стандартизация нужна для некоторых моделей (LR, NN), для деревьев обычно не нужна.Фичи времени:
Временные признаки (hour_of_day, day_of_week, is_holiday).Скользящие агрегаты по сущности (count/mean/std суммы за последние 1h, 24h, 7d и т.п.). Очень важно при расчете использовать только данные до момента транзакции (backtest-safe).Интервалы между событиями (time_since_last_txn).Работа с выбросами: не “отбрасывать” без анализа — часто аномалии важны для фрода.Feature selection: предварительно убрать высококоллинеарные признаки, но не слишком агрессивно — деревья устойчивы к корреляции.

3) Обработка несбалансированности (методы + когда применять)
Принцип: комбинировать методы на уровне данных, алгоритма и потерь, а также ориентироваться на бизнес‑метрику.

3.1 На уровне данных

Random undersampling majority — быстро и просто, но риск потерять разнообразие негативов. Подходит как baseline и при ограничениях на обучение.Clustered undersampling (кластеры негативов, отобрать репрезентативные примеры) — уменьшает риск потери разнообразия.Oversampling minority (SMOTE и его варианты — SMOTE‑ENN, Borderline SMOTE) — генерирует синтетические примеры; осторожно с временной сериализацией и кат. признаками.EasyEnsemble / BalanceCascade — ансамбли, в которых строятся несколько моделей на разных undersampled подвыборках, показывают хорошую стабильность.

3.2 На уровне алгоритма и потерь

Class weights (в XGBoost/LightGBM/LogReg): повышать вес редкого класса. Простой и безопасный подход.Focal loss (для NN): фокусирует обучение на сложных примерах.Cost‑sensitive learning: прямо оптимизировать ожидаемую финансовую потерю (включить матрицу затрат в loss).Специализированные реализации: BalancedRandomForest, class_weight в sklearn.

3.3 На уровне постобработки

Threshold tuning и calibration: модель даёт вероятности — подобрать порог, исходя из бизнес‑стоимости false positives / false negatives, precision@k или ограничений на ручную проверку.Использование скорингового ранжирования и ручной ревью топ‑k (precision@topK).

Обоснование: начните с class_weights + деревьев (LightGBM) как baseline; если качество недостаточно — добавляйте ансамбли с undersampling (EasyEnsemble) или oversampling с регуляризацией. Для финального решения обязательно оптимизация порога по бизнес‑метрике.

4) Метрики оценки (что и почему)
Общая идея: для несбалансированных задач AUC-ROC малоинформативен — смотреть на precision/recall и бизнес‑метрики.

Основные:

Precision, Recall (Sensitivity), F1 (обычно Fβ с β>1 если важнее recall): важны для оценки баланса между упущенными фродами и лишними блокировками.Precision@k / recall@k (или Top‑k capture rate): когда у вас ограничен ресурс ручной проверки (например, можно просмотреть 1% транзакций в день), важно знать, как много фрода попадёт в top‑k по скору.PR AUC (Area under Precision‑Recall curve): даёт представление при сильном дисбалансе.ROC AUC дополнительно, но интерпретировать осторожно.Cost-based metric: ожидаемая финансовая потеря = sum(FN cost_fn + FP cost_fp) — использовать для финального отбора/threshold tuning.Calibration metrics (Brier score, reliability diagram): чтобы вероятность интерпретировалась как риск.Business KPIs: false positive rate (FPR), manual review rate, avg time to detect, true fraud $ stopped.

Обоснование: PR AUC и precision@k напрямую отражают полезность модели в условиях редкого положительного класса и ограниченных действий (ручной проверки).

5) Выбор моделей (рекомендации)
Начать с простого к сложному:

Базовые модели/бенчмарки:
Logistic Regression (с L2, class_weight): быстрый и интерпретируемый baseline.Decision Tree простой.Сильные кандидаты:
Gradient Boosted Trees: LightGBM, XGBoost, CatBoost — обычно лучшие в табличных данных, хорошо работают с несбалансированностью через class_weight/scale_pos_weight, быстрый inference для продакшна.Random Forest / BalancedRandomForest — устойчивы к шуму.Специализированы/ансамбли:
EasyEnsemble (ансамбли деревьев + undersampling) — хорошо при экстремальном дисбалансе.Stacking: логистическая регрессия на выходах нескольких моделей.Нейросети:
Применять если много данных и сложные фичи (sequence models для session‑level, RNN/transformer для последовательностей поведенческих фич). Использовать focal loss или class weighting.Anomaly Detection / Unsupervised:
Autoencoder, Isolation Forest — в дополнение для выявления неожиданных паттернов, но не как единственный инструмент.

Критерии выбора: качество (PR AUC, precision@k), скорость инференса (latency), интерпретируемость, способность обновляться. Для большинства финансовых продакшнов LightGBM/CatBoost + threshold tuning и explainability (SHAP) — хорошая комбинация.

6) Валидция и тестирование для временных рядов
Очень важно: разделять данные по времени и по сущностям.

6.1 Разделение данных

Holdout тест: оставить последний период (например, последние N недель/месяцев) как финальный тест. Никакого использования этого периода для фичей/тюнинга.Validation для hyperparameter tuning: использовать временную CV (см. ниже), не random KFold.

6.2 Временная кросс‑валидация

Rolling / expanding window CV:
Expanding window: train = [t0..t_i], val = (t_i..t_i+Δ], затем сдвиг i вперёд.Sliding/rolling window: train = [t_i..t_i+L], val = (t_i+L..t_i+L+Δ], затем сдвиг.Для каждой итерации: вычислять признаки строго на основе исторических данных до начала validation периода.Подбирать шаг и размер валидации исходя из частоты данных (например, train 6 мес, val 1 мес, сдвиг 1 мес).Для гиперпараметров использовать time-aware nested CV: outer rolling для оценки, inner rolling для тюнинга.

6.3 Group-wise split

Если одна сущность генерирует много транзакций и их поведение коррелировано, нужно group‑split (чтобы действия одной карты не появлялись в train и val). Это предотвращает утечку через сущности.

6.4 Что логировать в CV

Для каждой временной итерации сохранять метрики (PR AUC, precision@k, cost) и распределение предсказаний. Это поможет оценить стабильность во времени.

Обоснование: обычный random CV приводит к утечке и завышению качества (т.к. паттерны одного аккаунта могут появиться и в train и val). В fraud‑сценарии временная валидация — must.

7) Подбор порога и калибровка

Калибровка вероятностей (Platt / isotonic) на validation set (временной).Подбор порога:
Оптимизировать порог на минимизацию ожидаемой финансовой потери (cost function).Или подобрать порог, чтобы соблюсти ограничение по manual review rate (например, не более 2% транзакций в сутки).Для ранжирования важно: использовать scores непосредственно (probabilities), но конечные операции — по порогу/кластеру.

8) Работа с задержкой меток (label latency)

Проблема: реальный fraud label может появляться через дни/недели.Подходы:
Train only on settled labels (с известной задержкой): работает, но «съедает» свежие данные.Использовать proxy labels (например, аномальные отклонения) + позднюю корректировку через delayed feedback learning.Semi-supervised / weak supervision: использовать модель для pseudo-labeling на свежих данных, обновлять после подтверждения.Survival / time-to-event modeling: модельирует вероятность того, что событие будет помечено как фрод в будущем — полезно, но сложнее.Обоснование: если метки приходят с задержкой, нужно корректно оценивать и тренировать модель, учитывать смещение и не обучаться на частично помеченных данных без учета.

9) Техническая организация обучения и развёртывания

Pipeline orchestration (Airflow/Kubeflow): этапы ETL → feature engineering → training → validation → packaging → deployment.Feature store: хранить версии фичей и обеспечить offline/online consistency.Model packaging: docker image + version control (model registry, например MLflow, Sagemaker).A/B или Champion–Challenger: деплой новой модели как challenger, запускать в shadow или split трафика, сравнение по business KPIs.

10) Мониторинг деградации в продакшне (какие метрики и как)
10.1 Что логировать

Для каждой предсказанной транзакции: timestamp, features snapshot, pred_probability, decision (block/manual review/allow), model_version, latency, customer_id.Позже: истина (label) и time_of_label (если доступна).

10.2 Метрики мониторинга

Performance metrics over time (daily/week): precision, recall, PR AUC, precision@k, FPR, manual_review_rate, cost_metric.Data drift:
Перемещение распределений фич (Population Stability Index — PSI, Kolmogorov‑Smirnov, Wasserstein distance) для ключевых фич.Доля новых категорий в кат. признаках.Concept drift:
Изменение распределения предсказаний (score drift).Изменение отношения меток (label rate) — резкое увеличение/уменьшение доли фродов.Explainability drift:
Изменения в SHAP importance между версиями.Latency & errors: среднее/95/99 перцентили задержки инференса и ошибок сервисов.

10.3 Триггеры и реакция

Автоматические алерты:
Если precision или recall упали ниже заранее заданного порога.Если PSI для ключевой фичи > 0.2 (примерный порог), или Wasserstein > порога.Если ручной ревью превышает SLA.Действия:
При мягком дрейфе: увеличить частоту переобучения и начать backtest.При сильном дрейфе: опустить модель на «failover» (раньше рабочая) и переключиться на conservative policy (повышать threshold, переводить больше транзакций на manual review).Запуск отката на предыдущую модель, если challenger хуже.

10.4 Политика ре‑трейна

Комбинировать:
Регулярное переобучение (например, еженедельно/ежемесячно) + мониторинг на события.Performance‑triggered retrain: при ухудшении KPI за X дней.При переобучении: использовать последние N месяцев данных, учитывать задержку меток (включать только fully labeled периоды или применять correction).

11) Объяснимость и соответствие регуляциям

SHAP/feature importance для объяснений решений (нужно для ручной ревью и регуляторов).Для каждой отклонённой транзакции предоставлять короткий «reason» (несколько top‑3 признаков).Версионирование и audit trail: хранить модель_id, weights, дата обучения, seed, полные тренировочные данные/фичи.

12) Практические замечания и anti‑patterns

Не делать random oversampling/SMOTE до временной split — это даёт утечку.Не использовать future information при генерации фичей (например, агрегаты, включающие транзакции после текущей).Не доверять одной метрике (например, ROC AUC) — смотреть на бизнес‑метрики.Не забывать про проверку статистической значимости изменений в A/B тестах (особенно при редком положительном классе).

13) Примерная последовательность пайплайна (короткая)

Сбор raw данных + метаданных меток (label_time).Offline feature engineering (rolling aggregates, encoding) безопасно по времени.Split: train/val/test по времени (group-aware).Обработка дисбаланса: class_weight на LightGBM + пробовать EasyEnsemble.Hyperparameter tuning с rolling CV (time-aware).Подбор порога по бизнес‑метрике на validation.Final train на объединённых train+val (до cutoff), тест на holdout.Деплой в shadow / A/B, логирование предсказаний.Мониторинг дата/концепт дрейфа + KPI, триггеры для retrain/rollback.

14) Заключение — практические рекомендации для старта

Стартовать с LightGBM с class_weight и carefully engineered temporal features.Оценивать по precision@k и PR AUC, а также по ожидаемой стоимости ошибок.Использовать time‑aware CV (rolling windows) и отдельный последний период как holdout.Логировать всё и настроить мониторинг дрейфа и KPI; иметь план отката и регулярный retrain с учётом латентности меток.При необходимости повышенного качества использовать ансамбли (EasyEnsemble) и cost‑sensitive training.

Если нужно, могу:

Предложить конкретные параметры для rolling CV (напр., train 6 мес / val 1 мес / сдвиг 1 мес) под ваш темп транзакций.Написать примерный код‑скелет для time-aware feature engineering / rolling CV.Помочь составить cost matrix и подобрать порог оптимально по бизнес‑целям.