Lyft: fraude, do raso ao profundo

01 · CONTEXTO

Fraude como classificação, e um bug que expôs o sistema

Em fraude, o interesse principal do Lyft é em algoritmos de classificação que distinguem usuários bons de usuários fraudulentos na plataforma. O caso acompanha a evolução desses modelos e da engenharia ao redor deles, contada por um integrante da equipe de fraude, cobrindo regressão logística, GBDT e deep learning.

O autor conta que fez deploy do serviço de decisão de fraude junto com seu primeiro pull request, que removia uma linha duplicada de coeficientes de uma regressão logística escrita à mão. Esse pequeno bug expôs limitações de um sistema construído para regras de negócio simples e legíveis.

Inconsistências de definição de modelo e de feature entre os protótipos offline, feitos em notebooks, e o serviço de produção ocorriam com mais frequência. Essas inconsistências levaram a ciclos de vai e vem de meses entre engenharia e ciência, que acabaram bloqueando a produção.

1. O diagrama mostra o protótipo offline, o serviço de decisão e o aplicativo ligado a ele.

2. As definições de modelo e de feature do serviço de produção apresentavam inconsistências em relação às do protótipo offline.

3. O serviço de decisão era monolítico: combinava ingestão e pré-processamento de features, execução de modelos e desafios antifraude.

02 · A BASE

Regressão logística: simples, legível e limitada

A regressão logística continua sendo o classificador básico de muitas indústrias. Seus coeficientes indicam o quanto uma feature se correlaciona com a probabilidade de fraude, e, ao diagnosticar erros, as features que mais contribuem são as de maiores parcelas no logit. A equipe também registrava a importância das features de cada predição para depurar e avaliar o desempenho.

O custo dessa simplicidade foi desempenho: os modelos lineares não capturavam toda a informação que as features traziam por meio de correlações lineares. Para capturar interações de ordem mais alta entre features, seria preciso criá-las à mão e adicioná-las como novas features.

03 · GBDT

Interações naturais e precisão com recall fixo

Entre as opções exploradas, a equipe optou por árvores de decisão com gradient boosting (GBDT), treinadas com a biblioteca XGBoost, pela facilidade de uso e pela eficiência.

Na regressão logística, a fronteira de decisão é um hiperplano no espaço de features, o que significa que boas features precisam ter relação linear forte com a probabilidade de fraude. No GBDT, as fronteiras são versões suavizadas de um conjunto de caixas em dimensões mais altas, o que permite codificar interações mais complicadas.

O ganho medido foi de precisão relativa: o GBDT teve mais de 60% de ganho relativo de precisão sobre o modelo anterior, para o mesmo recall de operação e o mesmo conjunto de features.

04 · DO NOTEBOOK À PRODUÇÃO

Interpretar, serializar e versionar

Ensembles são geralmente mais difíceis de interpretar e analisar do que a regressão logística simples. A equipe encontrou substitutos em importâncias de features específicas de árvores impulsionadas e em explicadores de modelo: as primeiras ajudam a priorizar o que levar à produção, e os explicadores mostram as features mais influentes numa predição específica.

Outro obstáculo era produtizar os GBDTs, para os quais a equipe não tinha uma boa forma. Ela avaliou ferramentas como PMML, mas a maioria não dava suporte a modelos de ponta e não capturava detalhes como codificação e transformações de features nos pipelines. A equipe construiu uma biblioteca baseada na API padronizada do scikit-learn e em serialização com pickle, com salvaguardas extras sobre requisitos de pacotes como tentativa simples de versionamento de modelos.

O texto diz usar modelos de deep learning em TensorFlow em produção, pelo desempenho e por trabalharem com sinais difíceis de transformar em features. GBDTs não lidam bem com entradas sequenciais, como históricos de transações, corridas e atividade no aplicativo.

05 · A PLATAFORMA

Do monólito a serviços ao redor dos modelos

O texto descreve também uma mudança de arquitetura: a execução de modelos e o fornecimento de features saíram do serviço de decisão original, e serviços construídos ao redor deles atendem às necessidades de outras equipes.

1. O diagrama parte do aplicativo, que chama o serviço de decisão.

2. A execução de modelos e o fornecimento de features saíram do serviço de decisão original.

3. Os serviços construídos ao redor deles atendem às necessidades de outras equipes.

4. A maioria dos modelos roda de forma síncrona, com limites rígidos de tempo de execução; em alguns pontos, a execução assíncrona liberou o uso de features e modelos mais complicados.

O autor também redesenhou o framework de holdback e experimentação para medir o impacto do sistema de forma hierárquica. Antes, as medições eram baseadas em regras e era impraticável avaliar o sistema como um todo; com o framework atual, ele pode ser avaliado no nível do desafio antifraude e de cada regra ou modelo.

Há ainda uma dimensão de organização: uma mentalidade em silos, em que o cientista para de trabalhar depois que o protótipo de features e modelo está construído. O autor diz ter abandonado o modelo de trabalho em que toda a produção de features e modelos era repassada à engenharia.