Principalele produse la pachet

  • La Binance, folosim învățarea automată (ML) pentru a rezolva diverse probleme de afaceri, inclusiv, dar fără a se limita la, frauda de preluare a conturilor (ATO), escrocherii P2P și detalii de plată furate.

  • Folosind operațiuni de învățare automată (MLOps), oamenii de știință de date Binance Risk AI au construit o conductă ML de la capăt la capăt în timp real, care furnizează continuu servicii ML pregătite pentru producție.

De ce folosim MLOps?

Pentru început, crearea unui serviciu ML este un proces iterativ. Oamenii de știință de date experimentează în mod constant pentru a îmbunătăți o anumită măsurătoare, fie offline, fie online, pe baza obiectivului de a oferi valoare afacerii. Deci, cum putem permite ca acest proces să fie mai eficient – ​​de exemplu, scurtând timpul de lansare pe piață al modelului ML?

În al doilea rând, comportamentul serviciilor ML este afectat nu numai de codul pe care noi, dezvoltatorii, îl definim, ci și de datele pe care le colectează. Această idee, cunoscută și sub numele de deriva de concept, este subliniată în lucrarea Google intitulată Datoria tehnică ascunsă în sistemele de învățare automată.

Luați ca exemplu frauda; escrocul nu este doar o mașină, ci un om care se adaptează și schimbă constant modul în care atacă. Ca atare, distribuția datelor de bază va evolua pentru a oglindi schimbările în vectorii de atac. Cum ne putem asigura în mod eficient că modelul de producție ia în considerare cel mai recent model de date?

Pentru a depăși provocările menționate mai sus, folosim un concept numit MLOps, termen propus inițial de Google în 2018. În MLOps, ne concentrăm pe performanța modelului și pe infrastructura care susține sistemul de producție. Acest lucru ne permite să construim servicii ML care sunt scalabile, foarte disponibile, de încredere și care pot fi întreținute.

Defalcarea conductei noastre de ML end-to-end în timp real

Gândiți-vă la diagrama de mai sus ca la procedura noastră standard de operare (SOP) pentru dezvoltarea modelelor în timp real cu un magazin de caracteristici. Conducta ML end-to-end dictează modul în care echipa noastră aplică MLops și este construită cu două tipuri de cerințe: funcționale și nefuncționale.

Funcţional

  • Procesarea datelor

  • Training model

  • Dezvoltarea modelului

  • Implementarea modelului

  • Monitorizarea

Cerințe nefuncționale

  • Scalabil

  • Foarte disponibil

  • De încredere

  • De întreținut

Conducta este în continuare împărțită în șase componente cheie:

  • Stratul de calcul

  • Store Layer

  • DB centralizat

  • Training model

  • Implementarea modelului

  • Monitorizare model

1. Stratul de calcul

Stratul de calcul este responsabil în principal de ingineria caracteristicilor, procesul de transformare a datelor brute în caracteristici utile.

Clasificăm stratul de calcul în două tipuri în funcție de frecvența pe care o actualizează: calculul în flux pentru intervale de un minut/secundă și calculul în lot pentru intervale zilnice/orare.

Datele de intrare ale stratului de calcul provin în general din baza de date bazată pe evenimente, care include Apache Kafka și Kinesis, sau baza de date OLAP, care include Apache Hive pentru open-source și Snowflake pentru soluții cloud.

2. Store Layer

Stratul de stocare este locul în care înregistrăm definițiile caracteristicilor și le implementăm în magazinul nostru de caracteristici, precum și efectuăm completarea, un proces care ne permite să reconstruim caracteristici prin date istorice ori de câte ori este definită o nouă caracteristică. Completarea este, de obicei, o sarcină unică pe care oamenii de știință de date o pot face într-un mediu de notebook. Deoarece Kafka poate stoca doar evenimente din ultimele șapte zile, folosește un mecanism de rezervă în tabelul s3/hive pentru a crește toleranța la erori.

Veți observa că stratul intermediar, Hive și Kafka, este găzduit în mod deliberat între straturile de calcul și magazin. Gândiți-vă la această plasare ca la un tampon între caracteristicile de calcul și scriere. O analogie ar fi separarea producătorului de consumator. Stream computing este producătorul, în timp ce stream computing este consumatorul.

Decuplarea calculului și a ingerării oferă o varietate de beneficii pentru conductele noastre ML. Pentru început, putem crește robustețea conductei în caz de defecțiuni. Oamenii noștri de date pot extrage în continuare valoarea caracteristicilor din baza de date centralizată, chiar dacă stratul de asimilare sau de calcul nu este disponibil din cauza problemelor operaționale, hardware sau de rețea.

În plus, putem scala diferite părți ale infrastructurii în mod individual și putem reduce energia necesară pentru construirea și operarea conductei. De exemplu, dacă eșuează din orice motiv, stratul de asimilare nu va bloca stratul de calcul. În ceea ce privește inovația, putem experimenta și adopta noi tehnologii, cum ar fi o nouă versiune a aplicației Flink, fără a afecta infrastructura noastră existentă.

Atât stratul de calcul, cât și stratul de magazin sunt ceea ce numim conducte de caracteristici automate. Aceste conducte sunt independente, rulează pe programe diferite și sunt clasificate ca conducte în flux sau în loturi. Iată cum funcționează diferit cele două conducte: un grup de caracteristici dintr-o conductă batch se poate reîmprospăta noaptea, în timp ce un alt grup este actualizat din oră. Într-o conductă de streaming, grupul de caracteristici se actualizează în timp real pe măsură ce datele sursă ajung pe un flux de intrare, cum ar fi un subiect Apache Kafka.

3. DB centralizat

Stratul DB centralizat este locul în care oamenii de știință de date își prezintă datele gata de funcționare într-un magazin de caracteristici online sau offline.

Magazinul de caracteristici online este un magazin cu latență scăzută, cu disponibilitate ridicată, care permite căutarea în timp real a înregistrărilor. Pe de altă parte, magazinul de caracteristici offline oferă un depozit sigur și scalabil al tuturor datelor caracteristicilor. Acest lucru le permite oamenilor de știință să creeze seturi de date de instruire, validare sau de evaluare în loturi dintr-un set de grupuri de caracteristici gestionate central, cu o înregistrare istorică completă a valorilor caracteristicilor în sistemul de stocare a obiectelor.

Ambele magazine de funcții se sincronizează automat una cu cealaltă la fiecare 10-15 minute pentru a evita deformarea servirii antrenamentului. Într-un articol viitor, vom face o analiză profundă a modului în care folosim magazinele de caracteristici.

4. Model Training

Stratul de antrenament al modelului este locul în care oamenii de știință extrag datele de antrenament din magazinul de funcții offline pentru a ne ajusta serviciile ML. Folosim interogări punctuale pentru a preveni scurgerea datelor în timpul procesului de extracție.

În plus, acest strat include o componentă esențială cunoscută sub numele de buclă de feedback de reantrenare a modelului. Reantrenarea modelului minimizează riscul de derive a conceptului, asigurându-se că modelele implementate reprezintă cu exactitate cele mai recente modele de date - de exemplu, un hacker care își schimbă comportamentul de atac.

5. Implementarea modelului

Pentru implementarea modelului, folosim în primul rând un serviciu de punctare bazat pe cloud ca coloană vertebrală a servirii noastre de date în timp real. Iată o diagramă care arată cum se integrează codul de inferență curent cu magazinul de caracteristici.

6. Monitorizare model

În acest nivel, echipa noastră monitorizează valorile de utilizare pentru servicii de punctare, cum ar fi QPS, latența, memoria și rata de utilizare a CPU/GPU. Pe lângă aceste valori de bază, folosim datele capturate pentru a verifica distribuția caracteristicilor de-a lungul timpului, abaterea de servire a antrenamentului și deviația de predicție pentru a asigura o deviere minimă a conceptului.

Gânduri de închidere

În concluzie, împărțirea vagă a infrastructurii noastre într-un strat de calcul, un strat de magazin și DB centralizat ne oferă trei beneficii cheie față de o arhitectură mai strâns cuplată.

  1. Conducte mai robuste în caz de defecțiuni

  2. Flexibilitate sporită în alegerea instrumentelor de implementat

  3. Componente scalabile independent

Vă interesează să utilizați ML pentru a proteja cel mai mare ecosistem cripto din lume și utilizatorii săi? Consultați Binance Engineering/AI pe pagina noastră de cariere pentru postări de locuri de muncă deschise.