Punti principali

  • Essendo il più grande scambio di criptovalute al mondo, è fondamentale disporre di un sistema di rilevamento dei rischi che sia veloce ma che non comprometta la precisione.

  • La sfida che abbiamo incontrato è stata quella di garantire che i nostri modelli utilizzassero sempre informazioni aggiornate, soprattutto quando rilevavano attività sospette sugli account in tempo reale.

  • Per ottenere una maggiore coerenza delle funzionalità e una maggiore velocità di produzione, ora facciamo ipotesi ragionevoli sui nostri dati e combiniamo le nostre pipeline batch e streaming.

Scopri come la nostra pipeline di ingegneria delle funzionalità crea funzionalità forti e coerenti per rilevare prelievi fraudolenti sulla piattaforma Binance.

All'interno della nostra pipeline di machine learning (ML), di cui puoi saperne di più in un articolo precedente, abbiamo recentemente creato una pipeline di progettazione automatizzata delle funzionalità che incanala i dati grezzi in funzionalità online riutilizzabili che possono essere condivise tra tutti i modelli relativi al rischio.

Nel processo di creazione e test di questa pipeline, i nostri data scientist hanno riscontrato un intrigante problema di coerenza delle funzionalità: come possiamo creare set accurati di funzionalità online che cambiano dinamicamente nel tempo?

Considera questo scenario reale: uno scambio di criptovalute, in questo caso Binance, sta cercando di rilevare prelievi fraudolenti prima che il denaro lasci la piattaforma. Una possibile soluzione è aggiungere una funzionalità al modello che rilevi il tempo trascorso dall'ultima operazione specifica dell'utente (ad esempio, accesso o associazione del cellulare). Sarebbe qualcosa del genere:

user_id|last_bind_google_time_diff_in_days|...

1|3.52|...

La sfida dell'implementazione

Il numero di chiavi necessarie per calcolare e aggiornare le funzionalità in un negozio di funzionalità online non è pratico. L'utilizzo di una pipeline di streaming, come Flink, sarebbe impossibile poiché può solo calcolare gli utenti con record che entrano in Kafka in questo momento.

Come compromesso, potremmo utilizzare una pipeline batch e accettare un certo ritardo. Supponiamo che un modello possa recuperare funzionalità da un negozio di funzionalità online ed eseguire inferenze in tempo reale in circa un'ora. Allo stesso tempo, se un feature store impiega un’ora per completare il calcolo e l’acquisizione dei dati, la pipeline batch – in teoria – risolverebbe il problema.

Sfortunatamente, c’è un problema evidente: l’utilizzo di una pipeline batch di questo tipo richiede molto tempo. Ciò rende impossibile finire entro un’ora quando sei il più grande scambio di criptovalute al mondo che ha a che fare con circa cento milioni di utenti e un limite TPS per le scritture.

Abbiamo scoperto che la pratica migliore è fare supposizioni sui nostri utenti, riducendo così la quantità di dati inseriti nel nostro archivio di funzionalità.

Alleggerire la questione con ipotesi pratiche

Le funzionalità online vengono acquisite in tempo reale e cambiano costantemente perché rappresentano la versione più aggiornata di un ambiente. Con gli utenti Binance attivi, non possiamo permetterci di utilizzare modelli con funzionalità obsolete.

È fondamentale che il nostro sistema segnali eventuali prelievi sospetti il ​​prima possibile. Qualsiasi ritardo aggiuntivo, anche di pochi minuti, significa più tempo a disposizione di un malintenzionato per farla franca.

Pertanto, per motivi di efficienza, presumiamo che gli accessi recenti comportino un rischio relativamente più elevato:

  • Troviamo che (250 giorni + 0,125[3/24 ritardo] giorno) produce errori relativamente più piccoli rispetto a (1 giorno + 0,125[3/24 ritardo] giorno).

  • La maggior parte delle operazioni non supererà una certa soglia; diciamo 365 giorni. Per risparmiare tempo e risorse informatiche, omettiamo gli utenti che non effettuano l'accesso da più di un anno.

La nostra soluzione

Utilizziamo l'architettura lambda, che prevede un processo in cui combiniamo pipeline batch e streaming, per ottenere una maggiore coerenza delle funzionalità.

Come si presenta concettualmente la soluzione?

  • Pipeline batch: esegue l'ingegneria delle funzionalità per una vasta base di utenti.

  • Pipeline di streaming: risolve il tempo di ritardo della pipeline batch per gli accessi recenti.

Cosa succede se un record viene inserito nell'archivio di funzionalità online tra il tempo di ritardo nell'acquisizione batch?

Le nostre funzionalità mantengono una forte coerenza anche quando i record vengono acquisiti durante il periodo di ritardo di acquisizione batch di un'ora. Questo perché il negozio di funzionalità online che utilizziamo su Binance restituisce il valore più recente in base all'event_time specificato quando si recupera il valore.

Entra nel nostro gruppo!

Sei interessato a utilizzare l'apprendimento automatico per salvaguardare il più grande ecosistema crittografico del mondo e i suoi utenti? Dai un'occhiata a Binance Engineering / AI sulla nostra pagina delle carriere per le opportunità di lavoro.

Per ulteriori informazioni, leggere i seguenti articoli utili:

  • (Blog) Utilizzo di MLOps per creare una pipeline di machine learning end-to-end in tempo reale

  • (Blog) Uno sguardo più da vicino al nostro negozio di funzionalità di machine learning