GH GambleHub

Monitoraggio dei modelli

1) Perché

L'obiettivo è mantenere la qualità e la sicurezza delle soluzioni del modello in vendita, rispettando SLA/SLO, RG/AML/Legale e budget. Il monitoraggio deve rilevare presto il degrado (dati, calibrazione, latency, costo), ridurre al minimo gli errori expected cost e garantire la riproduzione/controllo.


2) Aree di monitoraggio (mappa)

1. Disponibilità e prestazioni: latency p95/p99, errore-rate, RPS, scale automatico.
2. Qualità delle previsioni: PR-AUC/KS (in etichetta online), calibrazione (ECE), expected-cost @ threshold.
3. Deriva e stabilità: PSI/KL per filo e scorrimento, cambio di distribuzione/categoria.
4. Copertura e completezza: percentuale di richieste gestite correttamente, percentuale di fich vuoti, hit-rate cache.
5. Slice/Fairness: metriche per mercati/provider/dispositivi/età dell'account.
6. Guardrails (RG/AML) - Violazioni delle regole, frequenza di intervento, false positive/negative.
7. Costo: cost/richiest, cost/feature, orologio GPU/CPU, small-files/IO (per batch/near-RT).
8. Dati/contratti: schema, versioni, equivalenza online/offline.


3) SLI/SLO (punti di riferimento iGaming)

Latency p95 personalizzazione da 150 ms, RG/AML alert da 5 con e2e.
Availability: ≥ 99. 9%.
Error-rate 5xx: ≤ 0. 5% per 5 minuti di finestra.
Coverage: il 99% delle richieste ha ricevuto uno scatto e una soluzione.

Etichette Freshness per la valutazione online: D + 1 (giornaliera), proxy veloci di 1 ora

Drift PSI: fitta/scansione <0. 2 (warning с 0. 1).
Calibrazione ECE: ≤ 0. 05.
Expected-cost _ live: non superiore al modello di base + X% (la X di destinazione seleziona l'azienda).


4) Segnali e formule

4. 1 Deriva

PSI: riassume in base alla differenza di distribuzione.
La divergenza KL è sensibile alle code sottili; Monitor per il fich/screen chiave.
KS per scali (con etichette): differenza CDF per positivi/negativi.

4. 2 Calibrazione

ECE (Expected Calibration Error):predicted-prob − empirical-ratesui cestini.
Reliability curve: grafico di precisione vs probabilità.

4. 3 Expected-Cost

Minimizza (C = c _ {fp }\cdot FPR + c _ {fn }\cdot FNR) sulla soglia di lavoro; contano online in una finestra slittante con etichette posticipate.


5) Sorgenti discografiche

Etichette online (proxy veloci): evento deposito a 7 giorni, click/conversione completato valigetta RG.
Etichette posticipate: chargeback/frod (45-90 giorni), churn/LTV a lungo termine.
Regole: conservare l'as-of del tempo; Non usare eventi futuri.


6) Dashboard (composizione minima)

1. Operativo: RPS, p50/p95/p99 latency, 4xx/5xx, saturation, autoscaling.
2. Qualità: score-distribuzione, PR-AUC (nelle etichette proxy), ECE, expected-cost, KS.
3. Deriva: PSI/KL per top-feech, novelty categorie, missing-rate, feature-fetch latency.
4. Slice/Fairness: PR-AUC/ECE/expected-cost sui mercati/provider/device.
5. Guardrails: RG/AML violazioni, interventi/1k richieste, false-stop rate.
6. Costo: cost/richiest, CPU/GPU time, cache hit-rate, lookups esterni.


7) Alerting (regole di esempio)

HighP95Latency: p95> 150 ms (5 min) → SRE/MLOs.
ErrorBurst: 5xx > 0. Il 5% (5 min) dello script rollback è disponibile.
PSI_Drift: PSI(amount_base) > 0. 2 (15 min) → warm-up retrain/scalo canareo.
ECE_Bad: ECE > 0. 07 (30 min) per → la calibrazione/soglia.
: + X% al benchmark (1 giorno) per considerare il ritorno/annullamento.
Slice _ Failure: PR-AUC nel mercato R è crollato> Y% (1 giorno) al proprietario del dominio ticket.
Guardrails _ Breach: percentuale di off-off aggressivi> cap → kill-switch immediato.


8) Loging e traccia

I fogli di query (minimo) sono: 'richiest _ id', 'trace _ id', 'model _ id/variante', 'feature _ versione',' feature _ stat' ('feature' ('%%, extremes),' score ',' decision', 'threshold', 'policy _ id', 'guard _ guard' mask', 'latency _ ms', 'cost _ estimate', (opzionale) spiegazioni (SHAP top-k).
OTel-трейсы: спаны `feature_fetch` → `preprocess` → `score` → `postprocess` → `guardrail`.
PII: solo alias/token mascheramento per policy, residenza delle chiavi.


9) Valutazione qualità online

Finestre scivolanti per PR-AUC/KS su etichette veloci (ora/giorno).
Etichette ritardate: rapporti retrospettivi D + 7/D + 30/D + 90, regolazioni expected-cost.
Calibrazione: rivalutazione Isotonic/Platt su D + 1, artefatto auto-refresh.


10) Soglia e politica decisionale

Teniamo la soglia come config nel registro; online consideriamo l'expected-cost e la regolazione entro l'intervallo consentito (rate-limited).
Safety-caps - Limite di azione superiore/inferiore override manuale per la compilazione.
Le soglie di backtesting sono le simulazioni nightly sui dati di ieri.


11) Slice & Fairness

Segmenti: mercato/giurisdizione, provider, dispositivo/ASN, età dell'account, deposito-forza.
Metriche: PR-AUC, ECE, expected-cost, FPR/TPR di differenza (equalized odds), disparate impact.
Azioni: calibrazione/soglia per diapositiva, rielaborazione con bilancia, revisione del fich.


12) Equivalenza online/offline

Test di uguaglianza Fich: MAE/MAPE su un campione di controllo; alert in caso di discrepanza> soglia.
Versioning: 'feature _ spec _ variante', 'logic _ variante'; Archivio WORM.
I contratti di diagramma sono disabilitati senza doppia scrittura (v1/v2).


13) Guardrails (RG/AML)

Pre-/Post-filter azioni, limiti di frequenza, cooldown, liste di proibizioni.
Логи `policy_id/propensity/mask/decision`; Report delle violazioni.
Metrica time-to-intervene e false-intervent rate.


14) Incidenti e runbook

Script e passaggi:

1. - Controllare i provider FIC esterni e attivare la cache/timeout per ridimensionare il se necessario.

2. PSI/ECE/Expected-cost sono peggiorati: traffico freeze (canary↓), attivare soglie fallback/modello, avviare retrain.

3. Slice non riuscito: soglia temporanea specifica, ticket per il proprietario del dominio.

4. Guardrails breach: kill-switch, controllo delle valigette, post-mare.


15) Costi e prestazioni

Profilatura: parte del tempo nella feature-fetch vs score vs IO.
Strategie di cache: TTL/eviction, hot five in RAM, freddo in lazy.
Quantificazione/ottimizzazione del modello: FP16/INT8 mantenendo la qualità.
Chargeback: cost/sollest, cost/feature per comando/mercato.


16) Esempi (sezioni)

Soglia di esported-cost (pseudocode):
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)]
Prometheus (idee di metriche):
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"}
Alert (idea):
text
ALERT DriftDetected
IF psi_feature_amount_base > 0.2 FOR 15m

17) Processi e RACI

R (Secondable): MLOs (osservabilità/alert/registro), Data Science (metriche di qualità/calibrazione/soglia), Data Eng (fici/contratti/equivalenza).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/DPO (PII/RG/AML/DSAR), Security (KMS/Auditel), SRE (SLO/incidenti), Finance (costo).
I (Informed) - Prodotto/Marketing/Operazioni/Supporto.


18) Road map

MVP (2-4 settimane):

1. SLI/SLO di base (latency/5xx/coverage) + dashboard.

2. PSI per top 10 fich e score-distribuzione; ECE e expected-cost nelle etichette proxy.

3. Logi di soluzioni + trade OTEL; test di equivalenza online/offline.

4. Alert HighP95Latency/PSI_Drift/ECE_Bad + runbook e.

Fase 2 (4-8 settimane):
  • Pannelli Slice/fairness, nightly backfill metriche nelle etichette posticipate.
  • Calibrazione automatica e simulatore di soglie.
  • Cost-dashboard e quote/limiti per fici/repliche.
Fase 3 (8-12 settimane):
  • Auto relout/retraine alla deriva con controllo delle canarie.
  • Archivi WORM di report di qualità e manufatti.
  • Test Chaos per il monitoraggio e le esercitazioni DR.

19) Foglio di assegno prod pronto

  • SLI/SLO concordati e promozionali su shadow/canary 24 ore
  • PSI/KL, ECE, expected-cost e PR-AUC sono considerati online; soglie e alert sono stati impostati.
  • I pannelli Slice/fairness sono attivati; i proprietari dei segmenti sono assegnati.
  • Logi/trailer completi (soluzioni, soglie, maschere), maschera PII e residenza sono stati rispettati.
  • Test di equivalenza online/offline verde; schemi di Fich sotto contratto.
  • Runbook e one-click rollback verificati; kill-switch для guardrails.
  • Il costo rientra nei budget; cache/quote/limiti sono attivi.
  • L'archivio WORM di metriche/artefatti e report di qualità è stato salvato.

20) Anti-pattern e rischi

Nessuna etichetta in linea e valutazione retrospettiva.
Monitoraggio solo ROC-AUC senza expected-cost e calibrazione.
Ignorare slice/fairness consente di nascondere errori nelle regioni/dispositivi.
Non c'è equivalenza online/offline fich «doppia realtà».
Zero guardrail: Offer tossici, disturbi RG/AML.
Nessun piano di ripristino/DR, nessun archivio WORM.


21) Totale

Il monitoraggio dei modelli è un sistema di allarme rapido e gestione dei rischi/costi, anziché «guardare una volta alla settimana». Digitare SLO, misurare la deriva/calibrazione/expected-cost, tenere traccia delle diapositive e dei guardrail, tenere traccia dei pulsanti rollback/kill-switch, automatizzare i rapporti e i retrasfermi. In questo modo i modelli rimarranno utili, etici e complessi in qualsiasi turbolenza di dati e traffico.

Contact

Mettiti in contatto

Scrivici per qualsiasi domanda o richiesta di supporto.Siamo sempre pronti ad aiutarti!

Avvia integrazione

L’Email è obbligatoria. Telegram o WhatsApp — opzionali.

Il tuo nome opzionale
Email opzionale
Oggetto opzionale
Messaggio opzionale
Telegram opzionale
@
Se indichi Telegram — ti risponderemo anche lì, oltre che via Email.
WhatsApp opzionale
Formato: +prefisso internazionale e numero (ad es. +39XXXXXXXXX).

Cliccando sul pulsante, acconsenti al trattamento dei dati.