Мониторинг моделей

1) Зачем

Цель — поддерживать качество и безопасность решений модели в проде при соблюдении SLA/SLO, RG/AML/Legal и бюджетов. Мониторинг должен ранно обнаруживать деградации (данные, калибровка, latency, стоимость), минимизировать expected cost ошибок и обеспечивать воспроизводимость/аудит.

2) Области мониторинга (карта)

1. Доступность и производительность: latency p95/p99, error-rate, RPS, автоскейл.
2. Качество предсказаний: PR-AUC/KS (на онлайн-лейблах), калибровка (ECE), expected-cost@threshold.
3. Дрейф и стабильность: PSI/KL по фичам и скору, смена распределений/категорий.
4. Покрытие и полнота: доля успешно обслуженных запросов, доля «пустых» фич, hit-rate кэшей.
5. Slice/Fairness: метрики по рынкам/провайдерам/устройствам/возрасту аккаунта.
6. Guardrails (RG/AML): нарушения политик, частоты интервенций, false positives/negatives.
7. Стоимость: cost/request, cost/feature, GPU/CPU-часы, small-files/IO (для batch/near-RT).
8. Данные/контракты: схема фич, версии, эквивалентность online/offline.

3) SLI/SLO (ориентиры для iGaming)

Latency p95: персонализация ≤ 150 мс, RG/AML алерты ≤ 5 с e2e.
Availability: ≥ 99.9%.
Error-rate 5xx: ≤ 0.5% за 5 мин окно.
Coverage: ≥ 99% запросов получили валидный скор и решение.
Freshness лейблов для online-оценки: D+1 (суточная), для быстрых прокси — ≤ 1 ч.
Drift PSI: фичи/скор < 0.2 (warning с 0.1).
Калибровка ECE: ≤ 0.05.
Expected-cost_live: не выше базовой модели + X% (целевое X выбирает бизнес).

4) Сигналы и формулы

4.1 Дрейф

PSI: суммируем по бинам разницы распределений (train vs prod).
KL-дивергенция: чувствительна к «тонким» хвостам; мониторить для ключевых фич/скора.
KS для скоров (при наличии лейблов): разница CDF для позитивов/негативов.

4.2 Калибровка

4.3 Expected-Cost

Минимизируем (C = c_{fp}\cdot FPR + c_{fn}\cdot FNR) на рабочем пороге; онлайн считаем в скользящем окне с отложенными лейблами.

5) Источники лейблов

Онлайн-лейблы (быстрые прокси): событие «депозит в 7 дней», клик/конверсия, завершенный кейс RG.
Отложенные лейблы: chargeback/фрод (45–90 дней), долгосрочный churn/LTV.
Правила: хранить as-of время; не использовать события «из будущего».

6) Дашборды (минимальный состав)

1. Операционный: RPS, p50/p95/p99 latency, 4xx/5xx, saturation, autoscaling.
2. Качество: score-distribution, PR-AUC (на прокси-лейблах), ECE, expected-cost, KS.
3. Дрейф: PSI/KL по топ-фичам, novelty категорий, missing-rate, feature-fetch latency.
4. Slice/Fairness: PR-AUC/ECE/expected-cost по рынкам/провайдерам/девайсам.
5. Guardrails: RG/AML нарушений, интервенции/1k запросов, false-stop rate.
6. Стоимость: cost/request, CPU/GPU time, cache hit-rate, внешние lookups.

7) Алертинг (правила примера)

HighP95Latency: p95 > 150 мс (5 мин) → page SRE/MLOps.
ErrorBurst: 5xx > 0.5% (5 мин) → rollback-скрипт доступен.
PSI_Drift: PSI(amount_base) > 0.2 (15 мин) → warm-up retrain/канареечный откат.
ECE_Bad: ECE > 0.07 (30 мин) → пересобрать калибровку/пороги.
ExpectedCost_Up: +X% к бенчмарку (1 день) → рассмотреть откат/перетрен.
Slice_Failure: PR-AUC в рынке R упал > Y% (1 день) → владельцу домена тикет.
Guardrails_Breach: доля агрессивных офферов > cap → немедленный kill-switch.

8) Логирование и трассировка

Логи запроса (минимум): `request_id`, `trace_id`, `model_id/version`, `feature_version`, `feature_stats` (missing%, extremes), `score`, `decision`, `threshold`, `policy_id`, `guard_mask`, `latency_ms`, `cost_estimate`, (опционально) объяснения (SHAP top-k).
OTel-трейсы: спаны `feature_fetch` → `preprocess` → `score` → `postprocess` → `guardrail`.
PII: только псевдонимы/токены; маскирование по политике, резидентность ключей.

9) Онлайн-оценка качества

Скользящие окна для PR-AUC/KS по быстрым лейблам (час/день).
Задержанные лейблы: ретроспективные отчеты D+7/D+30/D+90, корректировки expected-cost.
Калибровка: переоценка Isotonic/Platt на D+1, auto-refresh артефакта.

10) Порог и политика решений

Порог держим как конфиг в реестре; онлайн считаем expected-cost и корректируем в пределах допустимого диапазона (rate-limited).
Safety-caps: верхние/нижние границы действий; ручной override для комплаенса.
Backtesting порогов: nightly симуляция на вчерашних данных.

11) Slice & Fairness

Сегменты: рынок/юрисдикция, провайдер, устройство/ASN, возраст аккаунта, депозит-сила.
Метрики: PR-AUC, ECE, expected-cost, FPR/TPR разницы (equalized odds), disparate impact.
Действия: калибровка/порог по слайсам, переобучение с весами, пересмотр фич.

12) Эквивалентность online/offline

Тест равенства фич: MAE/MAPE на контрольной выборке; алерт при расхождении > порога.
Версионирование: `feature_spec_version`, `logic_version`; WORM-архив.
Контракты схем: breaking-change запрещен без двойной записи (v1/v2).

13) Guardrails (RG/AML)

Pre-/Post-filter действий, частотные лимиты, cooldown, списки запретов.
Логи `policy_id/propensity/mask/decision`; отчет нарушений.
Метрика time-to-intervene и false-intervention rate.

14) Инциденты и runbook

1. Latency↑/5xx↑: проверить внешние фич-провайдеры → включить кэш/таймауты → масштабирование → при необходимости rollback.

2. PSI/ECE/Expected-cost ухудшились: freeze трафик (canary↓), включить fallback-пороги/модель, запустить retrain.

3. Slice провал: временный слайс-специфичный порог, тикет владельцу домена.

4. Guardrails breach: kill-switch, аудит кейсов, пост-морем.

15) Стоимость и производительность

Профилировка: доля времени в feature-fetch vs score vs IO.
Кэш-стратегии: TTL/eviction, «горячие» фичи в RAM, холодные — lazy.
Квантизация/оптимизация модели: FP16/INT8 при сохранении качества.
Chargeback: cost/request, cost/feature по командам/рынкам.

16) Примеры (фрагменты)

python thr_grid = np.linspace(0.01, 0.99, 99)
costs = [expected_cost(y_true, y_prob >= t, c_fp, c_fn) for t in thr_grid]
thr_best = thr_grid[np.argmin(costs)]

text model_inference_latency_ms_bucket feature_fetch_latency_ms_bucket model_request_total{code}
model_score_distribution_bucket psi_feature_amount_base ece_calibration expected_cost_live slice_pr_auc{slice="EEA_mobile"}

text
ALERT DriftDetected
IF psi_feature_amount_base > 0.2 FOR 15m

17) Процессы и RACI

R (Responsible): MLOps (наблюдаемость/алерты/реестр), Data Science (метрики качества/калибровка/порог), Data Eng (фичи/контракты/эквивалентность).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/DPO (PII/RG/AML/DSAR), Security (KMS/аудит), SRE (SLO/инциденты), Finance (стоимость).
I (Informed): Продукт/Маркетинг/Операции/Поддержка.

18) Дорожная карта

1. Базовые SLI/SLO (latency/5xx/coverage) + дашборд.

2. PSI для топ-10 фич и score-distribution; ECE и expected-cost на прокси-лейблах.

3. Логи решений + OTel-трейсы; тест эквивалентности online/offline.

4. Алерты HighP95Latency/PSI_Drift/ECE_Bad + runbook’и.

• Slice/fairness-панели, nightly backfill метрик на отложенных лейблах.
• Авто-пересбор калибровки и симулятор порогов.
• Cost-дашборд и квоты/лимиты на фичи/реплеи.

• Авто-релаут/ретрейн по дрейфу с канареечным контролем.
• WORM-архивы отчетов качества и артефактов.
• Chaos-тесты мониторинга и DR-учения.

19) Чек-лист прод-готовности

• SLI/SLO согласованы и промониторены на shadow/canary ≥ 24 ч.
• PSI/KL, ECE, expected-cost и PR-AUC считаются онлайн; пороги и алерты заданы.
• Slice/fairness-панели включены; владельцы сегментов назначены.
• Логи/трейсы полные (решения, пороги, маски), PII-маскирование и резидентность соблюдены.
• Тест эквивалентности online/offline зеленый; схемы фич под контрактом.
• Runbook’и и one-click rollback проверены; kill-switch для guardrails.
• Стоимость вписывается в бюджеты; кэш/квоты/лимиты активны.
• WORM-архив метрик/артефактов и отчетов качества сохранен.

20) Анти-паттерны и риски

Отсутствие online-лейблов и ретроспективной оценки.
Мониторинг только ROC-AUC без expected-cost и калибровки.
Игнор slice/fairness → скрытые провалы в регионах/устройствах.
Нет эквивалентности online/offline фич → «двойная реальность».
Ноль guardrails: токсичные офферы, нарушения RG/AML.
Нет планов отката/DR, нет WORM-архива.

21) Итог

Мониторинг моделей — это система раннего предупреждения и управления риском/стоимостью, а не «посмотреть раз в неделю». Введите SLO, измеряйте дрейф/калибровку/expected-cost, отслеживайте слайсы и guardrails, держите кнопки rollback/kill-switch, автоматизируйте отчеты и ретрейны. Так модели останутся полезными, этичными и комплаентными при любой турбулентности данных и трафика.