GH GambleHub

Monitoramento de modelos

1) Porquê

O objetivo é manter a qualidade e a segurança das soluções do modelo vendidas, respeitando SLA/SLO, RG/AML/Legal e orçamentos. O monitoramento deve detectar cedo a degradação (dados, calibração, latency, custo), minimizar erros expectados e garantir a reprodução/auditoria.


2) Áreas de monitoramento (mapa)

1. Disponibilidade e desempenho: latency p95/p99, error-rate, RPS, scail automático.
2. Qualidade das previsões: PR-AUC/KS (nas editoras online), calibragem (ECE), expected-cost @ threshold.
3. À deriva e estabilidade: PSI/KL em fichas e escores, mudança de distribuição/categoria.
4. Cobertura e abrangência: proporção de solicitações atendidas com sucesso, proporção de fichas «vazias», hit-rate em dinheiro.
5. Slice/Fairness: métricas para mercados/provedores/dispositivos/idade da conta.
6. Guardrails (RG/AML): violações de políticas, frequência de intervenções, falsas posturas/negativos.
7. Custo: custo/request, vale/função, GPU/relógio CPU, small-files/IO (para batch/near-RT).
8. Dados/contratos: esquema de fic, versões, equivalência online/offline.


3) SLI/SLO (orientações para iGaming)

Latency p95: personalização ≤ 150 ms, RG/AML alerts ≤ 5 com e2e.
Availability: ≥ 99. 9%.
Error-rate 5xx: ≤ 0. 5% em 5 min janela.
Coverage: ≥ 99% das solicitações receberam um raio de validade e uma solução.
Seleções Freshness para avaliação online: D + 1 (diária), proxy rápido - ≤ 1 h.
Draft PSI: fici/screen <0. 2 (warning с 0. 1).
Calibragem ECE: ≤ 0. 05.
Expected-cost _ live: não acima do modelo básico + X% (o X alvo seleciona o negócio).


4) Sinais e fórmulas

4. 1 À deriva

PSI: Somando para a diferença de distribuição (train vs prod).
Divergência KL: sensível a caudas «finas»; monitor para fic/screen chave.
KS para escores (se houver editoras): diferença de CDF para positivo/negativo.

4. 2 Calibragem

ECE (Expected Calibration Error):predicted-prob − empirical-ratePor cestas.
Reliability curve: gráfico exato vs probabilidade.

4. 3 Expected-Cost

Minimizar (C = c _\fp f.\cdot FPR + c _\fn f.\cdot FNR) na porta de trabalho; online contamos em uma janela deslizante com editoras atrasadas.


5) Fontes de editoras

Editoras online (proxy rápido): evento «depósito de 7 dias», clique/conversão, mala RG completa.
Editoras postergadas: chargeback/frod (45-90 dias), churn/LTV de longo prazo.
Regras: armazenar as-of-time; não usar eventos do futuro.


6) Dashboards (composição mínima)

1. Operação: RPS, p50/p95/p99 latency, 4xx/5xx, saturation, autoscaling.
2. Qualidade: score-distribuição, PR-AUC (em proxy), ECE, expected-cost, KS.
3. À deriva: PSI/KL em top fichs, categoria novelty, missing-rate, função-fetch latency.
4. Slice/Fairness: PR-AUC/ECE/expected-cost sobre mercados/provedores/device.
5. Guardrails: RG/AML violações, intervenções/1k solicitações, falso-stop rate.
6. Custo: cut/request, CPU/GPU time, cachê hit-rate, lookups externos.


7) Alerting (regras de exemplo)

HighP95Latency: p95> 150 ms (5 min) → page SRE/MLOs.
ErrorBurst: 5xx > 0. 5% (5 min) → o script rollback está disponível.
PSI_Drift: PSI(amount_base) > 0. 2 (15 min) → warm-up retrain/reversão de canário.
ECE_Bad: ECE > 0. 07 (30 min) → reaproveitar a calibragem/limiar.
ExpectedCost_Up: + X% para o benchmark (1 dia) → considerar o retrocesso/arrastado.
Slice _ Failure: PR-AUC no mercado de R caiu> Y% (1 dia) → dono do domínio tíquete.
Guardrails _ Breach: proporção de offs agressivos> cap → kill-switch imediato.


8) Logar e traçar

Logs de solicitação (mínimo): 'request _ id', 'trace _ id', 'modelo _ id/versão', 'função _ versão', 'função _ stats' (missing%, extremes), 'score', 'decision', 'threshold',' policy _ id ',' guard _ mask ',' latency _ ms', 'cost _ estimate', (opcionalmente) explicações (SHAP top-k).
OTel-трейсы: спаны `feature_fetch` → `preprocess` → `score` → `postprocess` → `guardrail`.
PII: apenas pseudônimos/tokens; camuflagem política, residência das chaves.


9) Avaliação de qualidade online

Janelas deslizantes para PR-AUC/KS por editoras rápidas (hora/dia).
Gravações atrasadas: relatórios de retrospectiva D + 7/D + 30/D + 90, ajustes expected-cost.
Calibragem: reavaliação Isotonic/Platt em D + 1, artefato auto-refresh.


10) Limiar e política de decisão

O limiar é mantido como config no registro; on-line consideramos o expected-cost e ajustamos dentro da faixa permitida (rate-limited).
Safety-caps: limites superiores/inferiores de ação; override manual para complacência.
Liminares Backtesting: nightly simulação em dados de ontem.


11) Slice & Fairness

Segmentos: mercado/jurisdição, provedor, dispositivo/ASN, idade da conta, poder de depósito.
Métricas: PR-AUC, ECE, expected-cost, FPR/TPR diferença (equalized odds), disparate impact.
Ações: calibragem/limiar por slides, reaproveitamento com balança, revisão de fique.


12) Equivalência online/offline

Teste de igualdade fic: MAE/MAPE na amostra de controle; alert em caso de discrepância> limiar.
Versioning: 'função _ spec _ versão', 'logic _ version'; Arquivo WORM.
Contratos de esquema: breaking-mudança é proibido sem dupla gravação (v1/v2).


13) Guardrails (RG/AML)

Pré-/Post-filter ações, limites de frequência, cooldown, listas de proibições.
Логи `policy_id/propensity/mask/decision`; Relatório de violação.
Metrica time-to-intervene e falso-intervenção rate.


14) Incidentes e runbook

Cenários e passos:

1. Latency↑/5xx↑: Verificar os provedores de fit externos → ativar o dinheiro/timeout → escalar o → se necessário.

2. PSI/ECE/Expected-cost piorou: tráfego freeze (canary↓), ativar liminares fallback/modelo, iniciar retrain.

3. Slice falha: limite de slides específico temporário, tíquete para o dono do domínio.

4. Guardrails breach: kill-switch, auditoria de malas, pós-mar.


15) Custo e desempenho

Perfil: proporção de tempo na função-fetch vs score vs IO.
Estratégias em dinheiro: TTL/evento, fitas quentes em RAM, frias em lazy.
Quantificação/otimização do modelo: FP16/INT8, mantendo a qualidade.
Chargeback: vale/request, vale/função por comandos/mercados.


16) Exemplos (fatias)

Limite expected-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 (ideias de métricas):
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 (ideia):
text
ALERT DriftDetected
IF psi_feature_amount_base > 0.2 FOR 15m

17) Processos e RACI

R (Resolvível): MLOps (observabilidade/alertas/registro), Data Science (métricas de qualidade/calibragem/limiar), Data Eng (fichas/contratos/equivalência).
A (Accountable): Head of Data / CDO.
C (Consulted): Compliance/DPO (PII/RG/AML/DSAR), Security (KMS/auditoria), SRE (SLO/incidentes), Finance (valor).
I (Informed): Produto/Marketing/Operações/Suporte.


18) Mapa de trânsito

MVP (2-4 semanas):

1. SLI/SLO básico (latency/5xx/coverage) + dashboard.

2. PSI para top 10 fic e score-distribuição; ECE e expected-cost em proxy.

3. Logs de soluções + OTel-trails; teste de equivalência online/offline.

4. Alertas HighP95Latency/PSI_Drift/ECE_Bad + runbook 'i.

Fase 2 (4-8 semanas):
  • Slice/fairness painel, nightly backfill métricas em editoras postas.
  • Calibragem de carro e simulador de liminares.
  • Costa-dashboard e quotas/limites para fici/réplicas.
Fase 3 (8-12 semanas):
  • Auto-relout/retrain à deriva com controle canário.
  • arquivos WORM de relatórios de qualidade e artefatos.
  • Chaos-testes de monitoramento e ensinamentos Dr.

19) Folha de cheque pré-pronta

  • SLI/SLO estão alinhados e proferidos em shadow/canary ≥ 24 h.
  • PSI/KL, ECE, expected-cost e PR-AUC são considerados online; liminares e alertas definidos.
  • Os painéis slice/fairness estão incluídos; os donos dos segmentos estão nomeados.
  • Logs/trens completos (soluções, liminares, máscaras), camuflagem PII e residência respeitados.
  • Teste de equivalência online/offline verde; Os esquemas estão sob contrato.
  • Runbook 'e one-click rollback foram testados; kill-switch для guardrails.
  • O custo se encaixa nos orçamentos; dinheiro/quotas/limites estão ativos.
  • O arquivo WORM de métricas/artefatos e relatórios de qualidade está guardado.

20) Anti-pattern e riscos

Falta de editoras online e avaliação retrospectiva.
Monitoramento apenas ROC-AUC sem expected-cost e calibração.
Ignorar slice/fairness → falhas ocultas em regiões/dispositivos.
Não há equivalência online/offline fic «realidade dupla».
Zero Guerrails, óferas tóxicas, perturbações RG/AML.
Nenhum plano de reversão/DR., nenhum arquivo WORM.


21) Total

O monitoramento de modelos é um sistema de alerta precoce e gerenciamento de risco/custo, em vez de «olhar uma vez por semana». Digite SLO, mede a deriva/calibragem/expected-cost, rastreie slides e guindastes, mantenha os botões rollback/kill-switch, automatize relatórios e retrações. Assim, os modelos permanecerão úteis, éticos e complicados em qualquer turbulência de dados e tráfego.

Contact

Entrar em contacto

Contacte-nos para qualquer questão ou necessidade de apoio.Estamos sempre prontos para ajudar!

Iniciar integração

O Email é obrigatório. Telegram ou WhatsApp — opcionais.

O seu nome opcional
Email opcional
Assunto opcional
Mensagem opcional
Telegram opcional
@
Se indicar Telegram — responderemos também por lá.
WhatsApp opcional
Formato: +indicativo e número (ex.: +351XXXXXXXXX).

Ao clicar, concorda com o tratamento dos seus dados.