Punti principali
In Binance, utilizziamo l'apprendimento automatico (ML) per risolvere vari problemi aziendali, inclusi ma non limitati a frodi di acquisizione di account (ATO), truffe P2P e dettagli di pagamento rubati.
Utilizzando operazioni di machine learning (MLOps), i nostri data scientist AI di Binance Risk hanno creato una pipeline ML end-to-end in tempo reale che fornisce continuamente servizi ML pronti per la produzione.
Perché usiamo MLOps?
Per cominciare, la creazione di un servizio ML è un processo iterativo. I data scientist sperimentano costantemente per migliorare una metrica specifica, offline o online, in base all'obiettivo di fornire valore all'azienda. Quindi, come possiamo rendere questo processo più efficiente, ad esempio riducendo il time-to-market del modello ML?
In secondo luogo, il comportamento dei servizi ML è influenzato non solo dal codice che noi sviluppatori definiamo, ma anche dai dati che raccoglie. Questa idea, nota anche come deriva del concetto, è enfatizzata nel documento di Google intitolato Hidden Technical Debt in Machine Learning Systems.
Prendiamo come esempio la frode; il truffatore non è solo una macchina ma un essere umano che si adatta e cambia costantemente il modo in cui attacca. Pertanto, la distribuzione dei dati sottostanti si evolverà per rispecchiare i cambiamenti nei vettori di attacco. Come possiamo garantire in modo efficace che il modello di produzione consideri il modello di dati più recente?
Per superare le sfide sopra menzionate, utilizziamo un concetto chiamato MLOps, termine inizialmente proposto da Google nel 2018. In MLOps, ci concentriamo sulle prestazioni del modello e sull'infrastruttura che supporta il sistema di produzione. Ciò ci consente di creare servizi ML scalabili, altamente disponibili, affidabili e manutenibili.
Abbattere la nostra pipeline di ML end-to-end in tempo reale
Pensa al diagramma precedente come alla nostra procedura operativa standard (SOP) per lo sviluppo di modelli in tempo reale con un archivio di funzionalità. La pipeline ML end-to-end determina il modo in cui il nostro team applica MLops ed è costruita con due tipi di requisiti: funzionali e non funzionali.
Funzionale
Elaborazione dati
Formazione del modello
Sviluppo del modello
Distribuzione del modello
Monitoraggio
Requisiti non funzionali
Scalabile
Altamente disponibile
Affidabile
Mantenibile
La pipeline è ulteriormente suddivisa in sei componenti chiave:
Livello informatico
Memorizza livello
DB centralizzato
Formazione del modello
Distribuzione del modello
Monitoraggio del modello
1. Livello informatico
Il livello informatico è principalmente responsabile dell’ingegneria delle funzionalità, il processo di trasformazione dei dati grezzi in funzionalità utili.
Classifichiamo il livello di elaborazione in due tipi in base alla frequenza con cui vengono aggiornati: elaborazione in flusso per intervalli di un minuto/secondo e elaborazione batch per intervalli giornalieri/orari.
I dati di input del livello di elaborazione provengono generalmente dal database basato su eventi, che include Apache Kafka e Kinesis, o dal database OLAP, che include Apache Hive per soluzioni open source e Snowflake per soluzioni cloud.
2. Memorizza livello
Il livello del negozio è il luogo in cui registriamo le definizioni delle funzionalità e le distribuiamo nel nostro archivio delle funzionalità, nonché eseguiamo il backfill, un processo che ci consente di ricostruire le funzionalità tramite dati storici ogni volta che viene definita una nuova funzionalità. Il recupero è in genere un lavoro una tantum che i nostri data scientist possono svolgere in un ambiente notebook. Poiché Kafka può archiviare solo eventi degli ultimi sette giorni, utilizza un meccanismo di backup nella tabella s3/hive per aumentare la tolleranza agli errori.
Noterai che il livello intermedio, Hive e Kafka, è deliberatamente ospitato tra i livelli di elaborazione e di archiviazione. Pensa a questa posizione come a un buffer tra le funzionalità di elaborazione e scrittura. Un’analogia potrebbe essere quella di separare il produttore dal consumatore. Lo streaming computing è il produttore, mentre l'ingestione di flussi è il consumatore.
Il disaccoppiamento dell'elaborazione e dell'acquisizione offre una serie di vantaggi per le nostre pipeline di machine learning. Per cominciare, possiamo aumentare la robustezza della pipeline in caso di guasti. I nostri data scientist possono comunque ricavare valore dalle funzionalità del database centralizzato, anche se il livello di acquisizione o di elaborazione non è disponibile a causa di problemi operativi, hardware o di rete.
Inoltre, possiamo ridimensionare individualmente diverse parti dell’infrastruttura e ridurre l’energia necessaria per costruire e far funzionare il gasdotto. Ad esempio, se fallisce per qualsiasi motivo, il livello di acquisizione non bloccherà il livello di elaborazione. Sul fronte dell’innovazione, possiamo sperimentare e adottare nuove tecnologie, come una nuova versione dell’applicazione Flink, senza intaccare la nostra infrastruttura esistente.
Sia il livello di elaborazione che quello di negozio sono ciò che chiamiamo pipeline di funzionalità automatizzate. Queste pipeline sono indipendenti, vengono eseguite in base a pianificazioni variabili e sono classificate come pipeline in streaming o batch. Ecco come funzionano in modo diverso le due pipeline: un gruppo di funzionalità in una pipeline batch potrebbe aggiornarsi ogni notte mentre un altro gruppo viene aggiornato ogni ora. In una pipeline di streaming, il gruppo di funzionalità si aggiorna in tempo reale quando i dati di origine arrivano su un flusso di input, ad esempio un argomento Apache Kafka.
3. DB centralizzato
Il livello DB centralizzato è il luogo in cui i nostri data scientist presentano i dati pronti per le funzionalità in un archivio di funzionalità online o offline.
L'archivio di funzionalità online è un archivio a bassa latenza e alta disponibilità che consente la ricerca dei record in tempo reale. D'altro canto, l'archivio delle funzionalità offline fornisce un archivio sicuro e scalabile di tutti i dati delle funzionalità. Ciò consente agli scienziati di creare set di dati di addestramento, convalida o punteggio batch da un insieme di gruppi di funzionalità gestiti centralmente con un record storico completo dei valori delle funzionalità nel sistema di storage degli oggetti.
Entrambi gli store di funzionalità si sincronizzano automaticamente tra loro ogni 10-15 minuti per evitare distorsioni nel servizio di formazione. In un prossimo articolo, approfondiremo il modo in cui utilizziamo i feature store nelle pipeline.
4. Formazione modello
Il livello di addestramento del modello è il luogo in cui i nostri scienziati estraggono i dati di addestramento dall'archivio di funzionalità offline per ottimizzare i nostri servizi ML. Utilizziamo query point-in-time per evitare perdite di dati durante il processo di estrazione.
Inoltre, questo livello include una componente cruciale nota come ciclo di feedback di riqualificazione del modello. La riqualificazione dei modelli riduce al minimo il rischio di deriva concettuale garantendo che i modelli distribuiti rappresentino accuratamente i modelli di dati più recenti, ad esempio un hacker che modifica il proprio comportamento di attacco.
5. Distribuzione del modello
Per l'implementazione del modello, utilizziamo principalmente un servizio di scoring basato su cloud come spina dorsale della nostra fornitura di dati in tempo reale. Ecco un diagramma che mostra come il codice di inferenza corrente si integra con l'archivio funzionalità.
6. Monitoraggio del modello
In questo livello, il nostro team monitora le metriche di utilizzo per valutare servizi come QPS, latenza, memoria e tasso di utilizzo di CPU/GPU. Oltre a queste metriche di base, utilizziamo i dati acquisiti per verificare la distribuzione delle funzionalità nel tempo, l'inclinazione del servizio di formazione e la deriva delle previsioni per garantire una deriva minima dei concetti.
Pensieri conclusivi
Per concludere, dividere liberamente la nostra infrastruttura di pipeline in un livello di elaborazione, un livello di archivio e un DB centralizzato ci offre tre vantaggi chiave rispetto a un'architettura più strettamente accoppiata.
Pipeline più robuste in caso di guasti
Maggiore flessibilità nella scelta degli strumenti da implementare
Componenti scalabili in modo indipendente
Ti interessa utilizzare il machine learning 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 offerte di lavoro aperte.