Principaux points à retenir

  • En tant que plus grand échange cryptographique au monde, il est essentiel que nous disposions d’un système de détection des risques rapide sans compromettre la précision.

  • Le défi que nous avons rencontré était de garantir que nos modèles utilisaient toujours des informations à jour, en particulier lors de la détection d'activités suspectes sur les comptes en temps réel.

  • Pour obtenir une plus grande cohérence des fonctionnalités et une plus grande vitesse de production, nous faisons désormais des hypothèses raisonnables sur nos données et combinons nos pipelines de lots et de streaming.

Découvrez comment notre pipeline d'ingénierie de fonctionnalités crée des fonctionnalités solides et cohérentes pour détecter les retraits frauduleux sur la plateforme Binance.

Au sein de notre pipeline d'apprentissage automatique (ML) – sur lequel vous pouvez en savoir plus dans un article précédent – ​​nous avons récemment construit un pipeline d'ingénierie de fonctionnalités automatisé qui canalise les données brutes vers des fonctionnalités en ligne réutilisables qui peuvent être partagées entre tous les modèles liés aux risques.

Au cours du processus de création et de test de ce pipeline, nos data scientists ont rencontré un problème fascinant de cohérence des fonctionnalités : comment créer des ensembles précis de fonctionnalités en ligne qui changent dynamiquement au fil du temps ?

Considérez ce scénario du monde réel : un échange cryptographique – dans ce cas, Binance – tente de détecter les retraits frauduleux avant que l'argent ne quitte la plateforme. Une solution possible consiste à ajouter une fonctionnalité à votre modèle qui détecte le temps écoulé depuis la dernière opération spécifique de l'utilisateur (par exemple, se connecter ou lier un mobile). Cela ressemblerait à ceci :

user_id|last_bind_google_time_diff_in_days|...

1|3.52|...

Le défi de la mise en œuvre

Le nombre de clés requis pour calculer et mettre à jour les fonctionnalités dans un magasin de fonctionnalités en ligne n'est pas pratique. Utiliser un pipeline de streaming, tel que Flink, serait impossible car il ne peut calculer que les utilisateurs dont les enregistrements arrivent actuellement dans Kafka.

En guise de compromis, nous pourrions utiliser un pipeline par lots et accepter un certain retard. Supposons qu'un modèle puisse récupérer des fonctionnalités dans un magasin de fonctionnalités en ligne et effectuer une inférence en temps réel en une heure environ. Dans le même temps, s’il faut une heure à un magasin de fonctionnalités pour terminer le calcul et l’ingestion des données, le pipeline par lots résoudrait – en théorie – le problème.

Malheureusement, il existe un problème flagrant : l’utilisation d’un tel pipeline par lots prend beaucoup de temps. Cela rend impossible de terminer en une heure lorsque vous êtes le plus grand échange de cryptographie au monde avec environ une centaine de millions d'utilisateurs et une limite TPS pour les écritures.

Nous avons constaté que la meilleure pratique consiste à faire des hypothèses sur nos utilisateurs, réduisant ainsi la quantité de données entrant dans notre magasin de fonctionnalités.

Résoudre le problème avec des hypothèses pratiques

Les fonctionnalités en ligne sont ingérées en temps réel et changent constamment car elles représentent la version la plus à jour d'un environnement. Avec les utilisateurs actifs de Binance, nous ne pouvons pas nous permettre d’utiliser des modèles aux fonctionnalités obsolètes.

Il est impératif que notre système signale tout retrait suspect dès que possible. Tout retard supplémentaire, même de quelques minutes, donne plus de temps à un acteur malveillant pour échapper à ses crimes.

Ainsi, par souci d’efficacité, nous supposons que les connexions récentes comportent un risque relativement plus élevé :

  • Nous constatons que (250 jours + 0,125[3/24 de délai] jour) produit des erreurs relativement plus petites que (1 jour + 0,125[3/24 de délai] jour).

  • La plupart des opérations ne dépasseront pas un certain seuil ; disons 365 jours. Pour économiser du temps et des ressources informatiques, nous omettons les utilisateurs qui ne se sont pas connectés depuis plus d'un an.

Notre solution

Nous utilisons l'architecture lambda, qui implique un processus dans lequel nous combinons des pipelines par lots et par streaming, pour obtenir une plus grande cohérence des fonctionnalités.

À quoi ressemble conceptuellement la solution ?

  • Batch Pipeline : effectue l’ingénierie des fonctionnalités pour une base d’utilisateurs massive.

  • Pipeline de streaming : corrige le délai du pipeline par lots pour les connexions récentes.

Que se passe-t-il si un enregistrement est ingéré dans le magasin de fonctionnalités en ligne entre le délai d'ingestion par lots ?

Nos fonctionnalités conservent une forte cohérence même lorsque les enregistrements sont ingérés pendant la période de retard d’ingestion par lots d’une heure. En effet, le magasin de fonctionnalités en ligne que nous utilisons chez Binance renvoie la dernière valeur en fonction de l'heure_événement que vous spécifiez lors de la récupération de la valeur.

Rejoins notre équipe!

Vous souhaitez utiliser l’apprentissage automatique pour protéger le plus grand écosystème cryptographique au monde et ses utilisateurs ? Consultez Binance Engineering / AI sur notre page Carrières pour connaître les offres d'emploi.

Pour plus d’informations, lisez les articles utiles suivants :

  • (Blog) Utiliser MLOps pour créer un pipeline d'apprentissage automatique de bout en bout en temps réel

  • (Blog) Un aperçu plus approfondi de notre magasin de fonctionnalités d'apprentissage automatique