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

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, автоматизуйте звіти і ретрейни. Так моделі залишаться корисними, етичними і комплаєнтними при будь-якій турбулентності даних і трафіку.