GH GambleHub

MLOps: експлуатація моделей

1) Роль експлуатації в iGaming

У iGaming моделі впливають на реальні гроші і регуляторику: RG-інтервенції, антифрод, виплати, KYC, ліміти, оффери та рекомендації. Експлуатація - це надійна подача передбачень з гарантованими SLO, простежуваністю і безпекою.

Цілі:
  • Передбачувані релізи і відкати без простою.
  • Узгодженість даних і фіч offline/online.
  • Спостережуваність: якість, дрейф, чесність, приватність.
  • Зниження TCO: продуктивність, кеш, GPU/CPU-мікси.
  • Відповідність вимогам (аудит/DSAR/Legal Hold/етика).

2) Архітектури сервінгу

Batch (офлайн): нічні/погодинні скоринги (ліміти, сегменти). Плюси: дешевше, стабільніше. Мінуси: немає миттєвої реакції.
Stream (near-real-time): обробка подій (ставки, аномалії) з вікнами 1-5 хв.
Online (sync API): <100-300 мс p95 для UX/ризик-рішень, кешування та деградації.
Гібрид: «baseline з batch + онлайн-уточнення» (приклад: RG-ризик за 7 днів + онлайн-тригери сесії).

Патерни:
  • Ensemble/Stacking з легким «гейт-моделлю» на критичному шляху.
  • Fallback-евристики при відмові моделі/фіч.
  • Circuit Breaker і rate limiting на піках або при деградації провайдерів.

3) Реєстр моделей та управління версіями

Model Registry: версії, власники, дата релізу, метрики (AUC/PR, калібрування), dataset_version, feature_set_version, обмеження використання.
Картка моделі (Model Card): завдання, дані/фічі, fairness/privacy-розділ, ризик-зони, частота рев'ю.
Політика релізів: `MAJOR. MINOR. PATCH'+ обов'язковий rollback-план.
Champion–Challenger: паралельний прогін challenger зі звітами; автоматичне підвищення при виконанні критеріїв.

4) Онлайн-фічі та узгодженість

Feature Store: offline (навчання) і online (інференс) вітрини з суворими контрактами.
Time travel і point-in-time join при навчанні.
Ідемпотентні апдейти фіч і захист від витоку таргета.
Узгодженість: гарантії «read-your-writes» або SLA доставки (наприклад, ≤ 60 сек).
Політика ознак: allow/deny-листи, маскування, токенізація, заборона проксі-PII.

5) Стратегії релізів

Shadow: все навантаження → champion; challenger отримує копію запитів, відповіді не впливають на бізнес.
Canary: 1-10% трафіку → нова версія; порівняння KPI/метрик, авто-відкат по порогах.
Blue-Green: два пули сервера/ендпоінта; перемикання DNS/маршрутом.
Прапори: тонке налаштування по ринках/тенантах/каналах.

6) Спостережуваність і алертинг

Сигнали (онлайн):
  • Надійність: error rate, timeouts, p50/p95/p99 latency, QPS, saturation.
  • Дані/фічі: свіжість, повнота, розподілу, аномалії, пропуски, schema drift.
  • Якість: калібрування, post-fact метрики (AUC/PR, uplift), відгук інтервенцій.
  • Дрейф: біля входів (PSI/KS) і біля виходів (score drift).
  • Етика/справедливість: EO/EOp-дельти, disparate impact.
  • Приватність: Attack-AUC (membership/inversion) ≈ 0. 5, ε -usage (якщо DP).
  • Бізнес: chargeback, RG-інтервенції, конверсія оферів - з розкладанням по сегментах.
Типові пороги:
  • p95 latency ≤ 200 мс (онлайн-скоринг RG/антифрод).
  • Error rate ≤ 0. 1% 5-хв. середнє.
  • Drift PSI ≤ 0. 2 за ключовими фічами; EOp-дельта ≤ 3 п.п.
  • Freshness фіч ≤ 60 сек; пропуски ≤ 0. 5%.
  • Калібрування ACE ≤ 0. 02.

7) Інциденти і плейбуки

Sev-рівні: P1 (блокування виплат/помилка RG), P2 (зростання помилок> порогу), P3 (деградація якості).
Авто-мітигації: переключення на champion, зниження частоти запитів, включення fallback-правил, ізоляція «токсичних» фіч.
Runbooks: чеклісти для «фічі застаріли», «виріс дрейф», «типізація фіда змінилася», «GPU вичерпаний».
Пост-мортем: RCA, фікс-план, оновлення тестів/порогів/контрактів.

8) Експерименти і контроль змін

A/B і multi-armed bandit - тільки зі стратифікацією за ключовими групами (країна/канал/пристрій).
Етичні стоп-правила: при різкому зростанні RG-ризику/скарг.
Dual-run вітрин фіч і моделей перед перемиканням.
Версіонування KPI і визначень (BI contract) для стабільної інтерпретації результатів.

9) Безпека і приватність в проді

mTLS/TLS 1. 3, підпис запитів, анти-replay (nonce/idempotency).
Секрети з Secrets Manager, JIT-видача, аудит.
Токенізація входів/логів; заборона PII в трасах.
ТЕЄ/конфіденційний інференс для VIP-виплат/AML (за необхідності).
Політики доступу (RBAC/ABAC/JIT) до фічів та ендпоінтів.
DSAR/Legal Hold: траса рішень для пояснюваності і видалення по токену.

10) Продуктивність і вартість

Кеш (feature/score) з TTL, особливо для стабільних сигналів.
Квантизація/дистиляція для прискорення (INT8/FP16).
Автоскейлінг: горизонтальний по QPS/latency, вертикальний по batch-size.
Гібрид CPU/GPU: latency-критичні на GPU, «маса» на CPU.
Трасування холодних стартів, прогрів моделі.
Пул моделей і «sticky routing» по ринках/тенантам для кеш-локальності.

11) Кейси iGaming (референси)

RG-скоринг: онлайн-скоринг при вході і в сесії; строгі overrides (самовиключення), цільова метрика - EOp + калібрування.
Антифрод/виплати: пред-авторизаційні рішення <150 мс; EO-контроль FPR, robust-агрегатори сигналів.
KYC/AML: thin-file підтримка; PSI/MPC з партнером; DSAR-сумісність.
Персоналізація: uplift-моделі та частотні ліміти; виключення high-risk з агресивних офферів.

12) Метрики і SLO експлуатації (приклад)

КатегоріяМетрикаМета
НадійністьJob/Endpoint success rate≥ 99. 5%
Латентністьp95 / p99≤ 200 мс/400 мс
ЯкістьAUC (онлайн), ACE≥ цільового/ ≤ 0. 02
ДаніFreshness фіч≤ 60 сек
ДрейфPSI входів≤ 0. 2
ЕтикаEOp-дельта≤ 3 п.п.
ПриватністьAttack-AUC~ 0. 5
БізнесFPR антифрод≤ цільового порогу

13) Шаблони артефактів

13. 1 Release Notes (ескіз)

Модель: `rg_risk@2. 1. 0` (MINOR)

Зміни: додана фіча'loss _ streak _ 7d'; калібрування оновлено

Валідація: shadow 14 днів; delta KPI ≤ 0. 3%; EOp-дельта в нормі

Rollout: canary 10% EU → 50% → 100%

Rollback: прапор'rg. use_v1=true`

Власник/дата/тікет

13. 2 Картка моделі (фрагмент)

Завдання: антифрод виплат

Дані: `payments_gold v3. 2', фіч-сет'payout _ signals v1. 7`

Метрики: AUC=0. 89, ACE=0. 015, FPR @опер. поріг = 1. 2%

Fairness: EO TPR/FPR Δ ≤ 2 п.п. по «country/method»

Обмеження: VIP-клієнти - тільки з human-review

Приватність: TEE-інференс; логування без PII

Рев'ю: раз на 90 днів

13. 3 Політика SLO ендпоінта (фрагмент)

yaml endpoint: /v1/score/rg slo:
latency_p95_ms: 200 success_rate: 0. 995 max_error_burst_per_5m: 50 data:
feature_freshness_s: 60 allowed_missing_pct: 0. 5 ethics:
eop_delta_pp: 3 privacy:
attack_auc_max: 0. 55

13. 4 Runbook «Фічі застаріли»

1. Перевірити лаг в Feature Store і джерело фіда.
2. Перемкнути на запасний канал/кеш.
3. Знизити трафік/включити fallback-правила.
4. Комунікація в #ml -status; інцидент P2/P1 по SLA.
5. RCA і правки контрактів/ретраїв.

14) Процеси тестування перед релізом

Контракти фіч: schema/enum/nullable, SLA свіжості.
Дані: DQ-тести, point-in-time, витік таргета.
Модель: unit/integration, калібрування, стрес/навантаження.
Безпека: секрети, mTLS, Zero-PII в логах.
Етика/приватність: fairness-чек, attack-suite.
Спостережуваність: дашборди/алерти, SLO конфіги.
Документація: Release Notes + rollback-план.

15) RACI (приклад)

ML Lead (A/R): якість, релізи, метрики.
Data Platform (R): Feature Store, регістр, оркестрація, спостережуваність.
Domain Owners (R): контракти джерел/фіч.
Security/DPO (A/R): доступи, приватність, токенізація, TEE.
SRE/SecOps (R): інциденти, SLO, автоскейл, SOAR.
Analytics/Finance (C): вплив на KPI і звіти.
Support/RG/Risk (C): human-in-the-loop і зрозумілість.

16) Дорожня карта впровадження

0-30 днів (MVP)

1. Model Registry + картки для high-impact моделей (RG/виплати/антифрод).
2. Базовий моніторинг: latency, errors, freshness, drift входів.
3. Shadow-прогони нових версій, canary-контури.
4. Контракти фіч і Zero-PII в логах.
5. Runbooks і канал #ml -status.

30-90 днів

1. Champion-Challenger і авто-підвищення за критеріями.
2. Fairness/privacy-гейти в CI/CD, attack-suite.
3. Кешування, квантизація, автоскейл; бюджет SLO/вартості.
4. BI/ML узгодження KPI і online-метрик; дашборди SLO.

3-6 місяців

1. Регулярні пост-мортеми, квартальні рев'ю моделей.
2. Гео/тенант-ізоляція ендпоінтів, ключів і фіч.
3. TEE/MPC для приватного інференса виплат/AML.
4. Повна автоматизація Release Notes з лінійджа і diff.
5. Зовнішній аудит процесів (де потрібно ліцензією).

17) Анти-патерни

Реліз без shadow/canary і rollback-плану.
Неузгоджені offline/online фічі → деградація.
Логи з PII, відсутність token-policy.
«Вічні» пороги без перегляду; ігнор дрейфу і калібрування.
Відсутність human-in-the-loop для high-risk рішень.
Експерименти без стратифікації та етичних стоп-правил.

18) Пов'язані розділи

DataOps-практики, Контроль доступу, Токенізація даних, Безпека і шифрування, Аудит і версійність, Зниження упередженості, Конфіденційне ML, Federated Learning, Політики зберігання даних, Походження і шлях даних, Етика даних.

Підсумок

Експлуатація моделей - це інженерна дисципліна на рівні продакшн-сервісів: чіткі контракти і версії, передбачувані релізи, спостережуваність 24/7, керовані ризики етики/приватності і прозорий вплив на бізнес. Так ML стає надійним продуктом, а не «кращим скриптом в ноутбуці».

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.