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
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.
- 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.