Galvenās līdzņemamās vietas
Uzņēmumā Binance mēs izmantojam mašīnmācīšanos (ML), lai atrisinātu dažādas uzņēmējdarbības problēmas, tostarp, bet ne tikai, konta pārņemšanas (ATO) krāpšanu, P2P krāpniecību un zagtu maksājumu informāciju.
Izmantojot mašīnmācīšanās darbības (MLOps), mūsu Binance Risk AI datu zinātnieki ir izveidojuši reāllaika pilnīgu ML cauruļvadu, kas nepārtraukti nodrošina ražošanai gatavus ML pakalpojumus.
Kāpēc mēs izmantojam MLOps?
Iesācējiem ML pakalpojuma izveide ir iteratīvs process. Datu zinātnieki pastāvīgi eksperimentē, lai uzlabotu konkrētu metriku gan bezsaistē, gan tiešsaistē, pamatojoties uz mērķi nodrošināt uzņēmuma vērtību. Tātad, kā mēs varam padarīt šo procesu efektīvāku, piemēram, saīsinot ML modeļa laiku, lai tas nonāktu tirgū?
Otrkārt, ML pakalpojumu uzvedību ietekmē ne tikai mūsu, izstrādātāju, definētais kods, bet arī tajā apkopotie dati. Šī ideja, kas pazīstama arī kā koncepcijas novirze, ir uzsvērta Google dokumentā ar nosaukumu Hidden Technical Debt in Machine Learning Systems.
Ņemiet par piemēru krāpšanu; krāpnieks nav tikai mašīna, bet arī cilvēks, kas pielāgojas un pastāvīgi maina uzbrukuma veidu. Tādējādi pamatā esošais datu sadalījums attīstīsies, lai atspoguļotu izmaiņas uzbrukuma vektoros. Kā mēs varam efektīvi nodrošināt, ka ražošanas modelī tiek ņemts vērā jaunākais datu modelis?
Lai pārvarētu iepriekš minētās problēmas, mēs izmantojam koncepciju MLOps — šo terminu Google sākotnēji ierosināja 2018. gadā. MLOps mēs koncentrējamies uz modeļa veiktspēju un ražošanas sistēmu atbalsta infrastruktūru. Tas ļauj mums izveidot ML pakalpojumus, kas ir mērogojami, ļoti pieejami, uzticami un apkopjami.
Mūsu reāllaika pilnīga ML cauruļvada sadalīšana
Iedomājieties iepriekš minēto diagrammu kā mūsu standarta darbības procedūru (SOP) reāllaika modeļa izstrādei ar funkciju veikalu. Pilnīgs ML konveijers nosaka, kā mūsu komanda izmanto MLops, un tas ir izveidots, ievērojot divu veidu prasības: funkcionālas un nefunkcionālas.
Funkcionāls
Datu apstrāde
Modeļu apmācība
Modeļa izstrāde
Modeļa izvietošana
Uzraudzība
Nefunkcionālās prasības
Mērogojams
Ļoti pieejams
Uzticams
Uzturams
Cauruļvads ir sadalīts sešos galvenajos komponentos:
Skaitļošanas slānis
Veikala slānis
Centralizēta DB
Modeļu apmācība
Modeļa izvietošana
Modeļa uzraudzība
1. Skaitļošanas slānis
Skaitļošanas slānis galvenokārt ir atbildīgs par funkciju inženieriju, neapstrādātu datu pārveidošanu noderīgos funkcijās.
Mēs iedalām skaitļošanas slāni divos veidos, pamatojoties uz to atjaunināšanas biežumu: straumes skaitļošana vienas minūtes/sekundes intervāliem un pakešu skaitļošana ikdienas/stundas intervāliem.
Skaitļošanas slāņa ievades dati parasti tiek iegūti no uz notikumiem balstītas datu bāzes, kurā ietilpst Apache Kafka un Kinesis, vai OLAP datubāzes, kurā ietilpst Apache Hive atvērtā koda un Snowflake mākoņrisinājumiem.
2. Veikala slānis
Veikala slānis ir vieta, kur mēs reģistrējam funkciju definīcijas un izvietojam tās mūsu funkciju krātuvē, kā arī veicam aizpildīšanu — procesu, kas ļauj mums atjaunot līdzekļus, izmantojot vēsturiskos datus, kad tiek definēts jauns līdzeklis. Aizpildīšana parasti ir vienreizējs darbs, ko mūsu datu zinātnieki var veikt piezīmjdatora vidē. Tā kā Kafka var saglabāt tikai pēdējo septiņu dienu notikumus, tas izmanto rezerves mehānismu s3/stropu tabulā, lai palielinātu kļūdu toleranci.
Jūs ievērosiet, ka starpslānis Hive un Kafka ir apzināti izvietots starp skaitļošanas un veikala slāni. Uztveriet šo izvietojumu kā buferi starp skaitļošanas un rakstīšanas funkcijām. Analogija būtu ražotāja nošķiršana no patērētāja. Straumes skaitļošana ir ražotājs, savukārt straumes uzņemšana ir patērētājs.
Skaitļošanas un pārsūtīšanas atsaiste nodrošina dažādas priekšrocības mūsu ML cauruļvadiem. Iesācējiem mēs varam palielināt cauruļvada robustumu kļūmju gadījumā. Mūsu datu zinātnieki joprojām var iegūt funkcijas vērtību no centralizētās datu bāzes, pat ja pārsūtīšanas vai skaitļošanas slānis nav pieejams darbības, aparatūras vai tīkla problēmu dēļ.
Turklāt mēs varam individuāli mērogot dažādas infrastruktūras daļas un samazināt cauruļvada izbūvei un ekspluatācijai nepieciešamo enerģiju. Piemēram, ja tas kāda iemesla dēļ neizdodas, ievades slānis nebloķēs skaitļošanas slāni. Inovācijas jomā mēs varam eksperimentēt un pieņemt jaunas tehnoloģijas, piemēram, jaunu lietojumprogrammas Flink versiju, neietekmējot mūsu esošo infrastruktūru.
Gan skaitļošanas slānis, gan veikala slānis ir tas, ko mēs saucam par automatizētiem funkciju cauruļvadiem. Šie cauruļvadi ir neatkarīgi, darbojas dažādos grafikos un tiek klasificēti kā straumēšanas vai pakešu cauruļvadi. Lūk, kā abi konveijeri darbojas atšķirīgi: viena pakešu konveijera līdzekļu grupa var tikt atsvaidzināta katru nakti, bet cita grupa tiek atjaunināta katru stundu. Straumēšanas konveijerā līdzekļu grupa tiek atjaunināta reāllaikā, kad ievades straumē tiek saņemti avota dati, piemēram, Apache Kafka tēma.
3. Centralizētā DB
Centralizētais DB slānis ir vieta, kur mūsu datu zinātnieki tiešsaistes vai bezsaistes funkciju veikalā iepazīstina ar funkcijām gatavus datus.
Tiešsaistes funkciju veikals ir zema latentuma, augstas pieejamības veikals, kas ļauj reāllaikā meklēt ierakstus. No otras puses, bezsaistes funkciju krātuve nodrošina drošu un mērogojamu visu līdzekļu datu krātuvi. Tas ļauj zinātniekiem izveidot apmācības, validācijas vai pakešu vērtēšanas datu kopas no centralizēti pārvaldītu līdzekļu grupu kopas ar pilnu objektu vērtību vēsturisko ierakstu objektu uzglabāšanas sistēmā.
Abi funkciju veikali automātiski sinhronizējas viens ar otru ik pēc 10–15 minūtēm, lai izvairītos no treniņu apkalpošanas novirzes. Nākamajā rakstā mēs padziļināti izpētīsim, kā mēs izmantojam funkciju veikalus, kas tiek gatavoti.
4. Modeļu apmācība
Modeļa apmācības slānis ir vieta, kur mūsu zinātnieki iegūst apmācību datus no bezsaistes funkciju veikala, lai precizētu mūsu ML pakalpojumus. Mēs izmantojam noteikta laika vaicājumus, lai novērstu datu noplūdi ieguves procesa laikā.
Turklāt šis slānis ietver būtisku komponentu, kas pazīstams kā modeļa pārkvalifikācijas atgriezeniskās saites cilpa. Modeļu pārkvalificēšana samazina koncepcijas novirzes risku, nodrošinot, ka izvietotie modeļi precīzi atspoguļo jaunākos datu modeļus, piemēram, hakeris maina savu uzbrukuma uzvedību.
5. Modeļa izvietošana
Modeļa izvietošanai mēs galvenokārt izmantojam uz mākoņiem balstītu vērtēšanas pakalpojumu kā mūsu reāllaika datu apkalpošanas mugurkaulu. Šeit ir diagramma, kas parāda, kā pašreizējais secinājumu kods tiek integrēts ar līdzekļu krātuvi.
6. Modeļu uzraudzība
Šajā slānī mūsu komanda uzrauga tādu pakalpojumu izmantošanas rādītājus kā QPS, latentums, atmiņa un CPU/GPU izmantošanas līmenis. Papildus šiem pamata rādītājiem mēs izmantojam iegūtos datus, lai pārbaudītu funkciju sadalījumu laikā, apmācības novirzi un prognozēšanas novirzi, lai nodrošinātu minimālu koncepcijas novirzi.
Noslēguma domas
Visbeidzot, mūsu cauruļvadu infrastruktūras brīva sadalīšana skaitļošanas slānī, krātuves slānī un centralizētā DB sniedz mums trīs galvenās priekšrocības salīdzinājumā ar ciešāk savienotu arhitektūru.
Izturīgāki cauruļvadi bojājumu gadījumā
Palielināta elastība, izvēloties, kurus rīkus ieviest
Neatkarīgi mērogojami komponenti
Vai vēlaties izmantot ML, lai aizsargātu pasaulē lielāko šifrēšanas ekosistēmu un tās lietotājus? Apskatiet Binance Engineering/AI mūsu karjeras lapā, lai iegūtu atklātus darba sludinājumus.