Detecção de fraude

01 · CONTEXTO

Uma pergunta de entrevista que parece simples

Dado um conjunto de compras de cartão de crédito em que cada registro é rotulado como fraudulento ou seguro, como construir um algoritmo de detecção de fraude? É a formulação clássica do exercício, e a descrição do curso que o aborda resume o objetivo como identificar transações incomuns ou suspeitas em dados financeiros para prevenir atividade fraudulenta. É um bom ponto de partida para pensar em sistemas de ML em produção.

Muitas perguntas dessa lista são ambíguas de propósito: cabe a quem responde pedir esclarecimentos e delimitar o escopo antes de desenhar.

02 · DESBALANCEAMENTO

A fraude é rara

Em dados reais de pagamento, a fraude é rara: na ordem de um em cada mil pagamentos, segundo o time de fraude da Stripe. Num conjunto de transações de cartão de crédito, as compras fraudulentas podem somar menos de zero vírgula um por cento dos exemplos, segundo o curso intensivo de ML do Google.

Esse desbalanceamento atrapalha o treino: um conjunto severamente desbalanceado pode não conter exemplos suficientes da classe minoritária para um treino adequado. Atrapalha também a avaliação, pois a acurácia costuma ser uma métrica ruim para avaliar um modelo treinado em dados desbalanceados.

O treino padrão mistura dois objetivos: aprender como cada classe se parece e aprender o quão comum cada classe é. A técnica de duas etapas de subamostrar e reponderar a classe majoritária separa esses dois objetivos.

03 · RÓTULOS ATRASADOS

O rótulo chega meses depois

Detecção de fraude é um exemplo de tarefa com ciclos de retorno longos: por um período depois da transação, o usuário pode contestar se ela foi fraudulenta ou não.

Uma janela típica de contestação vai de um mês a três meses. Passada a janela sem contestação do usuário, pode-se presumir que a transação foi legítima.

Isso pesa no monitoramento: se há um problema no modelo de fraude e ele leva meses para ser percebido, as fraudes que o modelo deixou passar podem ter levado um pequeno negócio à falência. Quando o rótulo verdadeiro não está disponível ou chega tarde demais para ser útil, pode-se monitorar outras distribuições de interesse.

04 · LIMIAR SENSÍVEL A CUSTO

Quanto custa errar

O Radar da Stripe precisa equilibrar o bloqueio de transações ruins contra falsos positivos, isto é, pagamentos bons bloqueados, que prejudicam consumidores e o resultado dos usuários da Stripe.

Um exemplo de crédito mostra como o custo entra na conta: no conjunto German credit usado pelo scikit-learn, classificar um crédito ruim como bom é, em média, cinco vezes mais custoso do que o contrário.

Uma solução descrita pelo scikit-learn é ajustar o limiar de decisão do classificador depois que o modelo foi treinado. O limiar ótimo é escolhido para maximizar uma métrica dada; no exemplo da documentação, o limiar ajustado otimiza uma métrica de utilidade definida pelo negócio. A mesma documentação alerta para não usar os mesmos dados para treinar o classificador e para ajustar o limiar, pelo risco de sobreajuste.

05 · A ARQUITETURA

Decisão rápida, aprendizado lento

O diagrama abaixo junta os três temas: o caminho da decisão, o laço de rótulos e o ajuste do limiar. Os eventos passam por uma fila de mensagens antes de chegarem ao registro de transações.

1. No diagrama, o comprador chega à API de pagamentos, que está ligada ao serviço de pontuação.

2. No diagrama, o serviço de pontuação consulta o armazém de features online. Como referência, o Radar da Stripe toma a decisão de fraude em menos de cem milissegundos.

3. O limiar da política de decisão é ajustado depois do treino do modelo, para maximizar uma métrica; no exemplo da documentação, uma métrica de utilidade definida pelo negócio.

4. No diagrama, a API publica cada transação e a decisão numa fila de eventos, que alimenta o registro de transações.

5. Por um período depois da transação o cliente pode contestá-la, e uma janela típica vai de um mês a três meses. Passada a janela sem contestação, pode-se presumir que a transação foi legítima.

6. No diagrama, a junção de rótulos alimenta o treino, que publica o modelo no serviço de pontuação e o limiar na política de decisão. A documentação alerta para não usar os mesmos dados para treinar o classificador e ajustar o limiar, pelo risco de sobreajuste.

06 · FEATURES

Tempo real ou quase tempo real

Features de tempo real são calculadas quando o pedido de previsão chega, e a latência do cálculo soma-se diretamente à latência vista pelo usuário. Features quase em tempo real são pré-calculadas com um motor de processamento de fluxo; como são calculadas de forma assíncrona, sua latência não se soma à do usuário.

1. As features quase em tempo real são calculadas com um motor de processamento de fluxo, aqui alimentado pela fila de eventos.

2. Como essas features são calculadas de forma assíncrona, a latência do cálculo não se soma à latência vista pelo usuário.

3. No diagrama, um job em lote lê o registro histórico e grava no mesmo armazém online.

4. No diagrama, o serviço de pontuação lê do armazém as features já prontas. As features de tempo real, ao contrário, são calculadas quando o pedido de previsão chega, e a latência do cálculo se soma diretamente à latência vista pelo usuário.