Saltar para o conteúdo
SwankyForge
SwankyForge
Todos os casos técnicos
Sistemas de MLMLOpsMonitorização5 meses

Pipeline de deteção de fraude + monitorização

Os analistas passavam o dia com falsos alarmes. A fila de revisão tem agora um terço do tamanho.

Taxa de falsos positivos

1,6%

Modelo calibrado por custo, mesmo recall

Antes

4,1%

Regras estáticas com o recall-alvo

Em termos simples

O que é isto.

Sem jargão nesta secção. A descrição técnica está mais abaixo.

O que estava a correr mal

Um conjunto fixo de regras apanhava a fraude que já conhecia e mais nada. Os analistas passavam o dia a atravessar falsos alarmes, enquanto padrões de ataque realmente novos passavam despercebidos durante semanas.

O que construímos

Construímos um scoring em tempo real que pondera o custo real de cada tipo de erro, acrescentámos monitorização que dá o alerta quando o comportamento muda, e implementámo-lo gradualmente ao lado das regras existentes em vez de as substituir de um dia para o outro.

O que mudou

Apanhando a mesma quantidade de fraude, os falsos alarmes caíram de 4,1% para 1,6% — o que reduziu a fila de revisão em quase dois terços. Os novos padrões surgem agora em poucos dias, e cada transação recusada vem acompanhada de uma razão.

Arquitetura

Como tudo se encaixa.

Percorra as etapas. Tudo o que está marcado como acrescentado é um componente que não existia antes deste projeto.

FEATURESREVISÃOLOGTransaçãoTEMPO REALFeature storeONLINEScorer GBDT241 FEATURESMatriz de custosLIMIARESFila de analistasEXPLICADOMonitor de driftPSI + KS
  1. Transação

    tempo real

    alimenta
    Feature storefeatures
  2. Feature store

    online

    Acrescentámos isto
    recebe de
    Transaçãofeatures
    alimenta
    Scorer GBDT
  3. Scorer GBDT

    241 features

    Acrescentámos isto
    recebe de
    Feature store
    alimenta
    Matriz de custos · Monitor de driftlog
  4. Matriz de custos

    limiares

    Acrescentámos isto
    recebe de
    Scorer GBDT
    alimenta
    Fila de analistasrevisão
  5. Fila de analistas

    explicado

    recebe de
    Matriz de custosrevisão
  6. Monitor de drift

    psi + ks

    Acrescentámos isto
    recebe de
    Scorer GBDTlog
A descrição

Como seria construído.

Conjunto de dados, abordagem, métricas-alvo e a stack. Escrito para quem tiver de o rever.

Sistemas de MLMLOpsMonitorização5 meses

Pipeline de deteção de fraude + monitorização

Scoring em tempo real com pipelines de features, monitorização e implementações controladas.

Problema

Um conjunto estático de regras apanhava padrões de fraude conhecidos e mais nada. Os analistas afogavam-se em falsos positivos enquanto padrões de ataque novos ficavam semanas sem ser sinalizados.

Conjunto de dados

linhas
186 M de transações
features
241
fontes
Pagamentos, dispositivo, comportamento
janela
28 meses

Abordagem

  1. 01Construímos uma feature store em tempo real com paridade estrita offline/online
  2. 02Treinámos um modelo de gradient boosting com tratamento forte do desequilíbrio de classes
  3. 03Definimos os limiares a partir de uma matriz de custos explícita em vez do F1
  4. 04Acrescentámos monitorização de drift e um ciclo de retreino champion/challenger

Métricas

0,79
PR-AUC
+0,34
-61%
falsos positivos
com o mesmo recall
28 ms
p95 do scoring
inline
0,041
PSI de drift
monitorizado

Evidência

fonte
Design de referência
números
Ilustrativo — valores típicos para este design
medição
Não medido. Valores típicos para um design de referência deste tipo, não observados num sistema de cliente.
referência
Não disponível para este projeto
última revisão
2026-08-25

Impacto no negócio

  • Fila de revisão dos analistas reduzida em quase dois terços
  • Padrões novos detetados em dias em vez de semanas
  • Cada recusa explicável com atribuições por feature

Stack tecnológica

  • Python
  • Kafka
  • Flink
  • LightGBM
  • Feast
  • Prometheus
  • Grafana

Seguinte

Precisa de um sistema como este?

Responda a seis perguntas e dizemos-lhe se esta forma se adequa ao seu problema — incluindo quando não se adequa.