Principais conclusões

  • Como a maior exchange de criptomoedas do mundo, é crucial que tenhamos um sistema de detecção de risco que seja rápido, mas que não comprometa a precisão. 

  • O desafio que encontramos foi garantir que nossos modelos sempre usassem informações atualizadas, especialmente ao detectar atividades suspeitas em contas em tempo real. 

  • Para obter maior consistência de recursos e maior velocidade de produção, agora fazemos suposições razoáveis ​​sobre nossos dados e combinamos nossos pipelines de lote e de streaming. 

Descubra como nosso pipeline de engenharia de recursos cria recursos fortes e consistentes para detectar saques fraudulentos na plataforma Binance. 

Dentro do nosso pipeline de aprendizado de máquina (ML), sobre o qual você pode aprender mais em um artigo anterior, construímos recentemente um pipeline automatizado de engenharia de recursos que canaliza dados brutos em recursos online reutilizáveis ​​que podem ser compartilhados entre todos os modelos relacionados a riscos. 

No processo de construção e teste desse pipeline, nossos cientistas de dados encontraram um problema intrigante de consistência de recursos: como criamos conjuntos precisos de recursos on-line que mudam dinamicamente ao longo do tempo?

Considere este cenário do mundo real: uma exchange de criptomoedas – neste caso, a Binance – está tentando detectar saques fraudulentos antes que o dinheiro saia da plataforma. Uma solução possível é adicionar um recurso ao seu modelo que detecte o tempo decorrido desde a última operação específica do usuário (por exemplo, fazer login ou vincular o celular). Seria algo assim:

user_id|last_bind_google_time_diff_in_days|...

1|3,52|...

O desafio da implementação

O número de chaves necessárias para calcular e atualizar recursos em uma feature store online é impraticável. Usar um pipeline de streaming, como o Flink, seria impossível, pois ele só pode calcular usuários com registros que chegam ao Kafka no momento. 

Como compromisso, poderíamos usar um pipeline em lote e aceitar algum atraso. Digamos que um modelo possa buscar recursos em uma loja de recursos online e realizar inferência em tempo real em cerca de uma hora. Ao mesmo tempo, se levar uma hora para um feature store terminar de calcular e ingerir dados, o pipeline em lote resolveria – em teoria – o problema.

Infelizmente, há um problema evidente: usar esse pipeline em lote consome muito tempo. Isso torna inviável terminar em uma hora quando você é a maior exchange de criptomoedas do mundo, lidando com aproximadamente cem milhões de usuários e um limite de TPS para gravações.  

Descobrimos que a prática recomendada é fazer suposições sobre nossos usuários, reduzindo assim a quantidade de dados que entram em nosso armazenamento de recursos. 

Facilitando o problema com suposições práticas

Os recursos online são ingeridos em tempo real e estão em constante mudança porque representam a versão mais atualizada de um ambiente. Com usuários ativos da Binance, não podemos nos dar ao luxo de usar modelos com recursos desatualizados.

É imperativo que o nosso sistema sinalize quaisquer levantamentos suspeitos o mais rapidamente possível. Qualquer atraso adicional, mesmo que seja de alguns minutos, significa mais tempo para um ator mal-intencionado escapar impune de seus crimes. 

Portanto, por uma questão de eficiência, presumimos que logins recentes apresentam um risco relativamente maior:

  • Descobrimos que (250 dias + 0,125[atraso de 3/24] dia) produz erros relativamente menores do que (1 dia + 0,125[atraso de 3/24] dia).

  • A maioria das operações não excederá um determinado limite; digamos 365 dias. Para economizar tempo e recursos computacionais, omitimos usuários que não fazem login há mais de um ano. 

Nossa solução

Usamos a arquitetura lambda, que envolve um processo em que combinamos pipelines em lote e de streaming, para obter uma consistência de recursos mais forte.

Como é a solução conceitualmente?

  • Pipeline em lote: realiza engenharia de recursos para uma enorme base de usuários.

  • Pipeline de streaming: corrige o tempo de atraso do pipeline em lote para logins recentes.

E se um registro for ingerido no feature store online entre o tempo de atraso na ingestão em lote?

Nossos recursos ainda mantêm forte consistência mesmo quando os registros são ingeridos durante o período de atraso de uma hora na ingestão em lote. Isso ocorre porque o feature store online que usamos na Binance retorna o valor mais recente com base no event_time que você especifica ao recuperar o valor.

Junte-se a nossa equipe!

Interessado em usar o aprendizado de máquina para proteger o maior ecossistema criptográfico do mundo e seus usuários? Confira Binance Engineering / AI em nossa página de carreiras para vagas de emprego. 

Para obter mais informações, leia os seguintes artigos úteis:

  • (Blog) Usando MLOps para construir um pipeline de aprendizado de máquina ponta a ponta em tempo real

  • (Blog) Uma análise mais detalhada de nossa loja de recursos de aprendizado de máquina