Duomenų srauto optimizavimas orientuotas į efektyvų neapdorotų duomenų perkėlimą ir transformavimą analizei, o modelių srauto optimizavimas supaprastina mašininio mokymosi modelių mokymą, patvirtinimą ir diegimą. Abu šie būdai yra labai svarbūs keičiamo mastelio dirbtinio intelekto sistemoms, tačiau skirti skirtingiems mašininio mokymosi gyvavimo ciklo etapams.
Neapdorotų duomenų įrašymo, transformavimo ir pateikimo tolesnei analizei ir mašininio mokymosi naudojimo atvejams tobulinimo procesas.
Praktika, kuria siekiama supaprastinti visą mašininio mokymosi darbo eigą – nuo funkcijų inžinerijos iki mokymo, vertinimo ir diegimo.
| Funkcija | Duomenų srauto optimizavimas | Modelių srauto optimizavimas |
|---|---|---|
| Pagrindinis tikslas | Greitai pateikite švarius, patikimus duomenis | Efektyviai apmokykite ir diegkite tikslius modelius |
| ML gyvavimo ciklo etapas | Išankstinis modeliavimas (duomenų paruošimas) | Modeliavimas ir postmodeliavimas (mokymai, pateikimas) |
| Pagrindiniai rodikliai | Vėlavimas, pralaidumas, duomenų naujumas, kaina už užklausą | Mokymo laikas, išvados delsa, modelio tikslumas, GPU panaudojimas |
| Įprasti įrankiai | Oro srautas, kibirkštis, DBT, snaigė, AWS klijai | MLflow, Kubeflow, TFX, SageMaker, Metaflow |
| Tipinės kliūtys | Lėtos užklausos, schemos dreifas, duomenų iškraipymas, tinklo įvestis/išvestis | Neveiki GPU, perteklinis funkcijų skaičiavimas, dideli modelio artefaktai |
| Optimizavimo metodai | Padalijimas, kaupimas talpykloje, laipsniškas įkėlimas, užklausų perrašymas | Paskirstytas mokymas, mišrus tikslumas, genėjimas, kvantizavimas |
| Gedimų režimai | Pasenę duomenys, trūkstami įrašai, neveikiančios transformacijos | Mokymo skirtumai, duomenų nutekėjimas, pateikimo iškreipimas |
| Reikalingas įgūdžių rinkinys | SQL, Python, paskirstytos sistemos, duomenų modeliavimas | ML karkasai, statistika, MLOp, konteinerių orkestravimas |
Duomenų srauto optimizavimas susijęs su tuo, kaip informacija teka iš operacinių sistemų į analizei paruoštus formatus. Tikslas – užtikrinti, kad tinkami duomenys patektų į tinkamą vietą tinkamu laiku, neviršijant biudžeto. Tuo tarpu modelių srauto optimizavimas prasideda, kai duomenys yra paruošti, ir sutelkiamas į jų pavertimą veikiančia prognozavimo sistema. Jis reglamentuoja, kaip kuriamos funkcijos, kaip stebimi eksperimentai ir kaip apmokyti modeliai pasiekia gamybą.
Kai komandos derina duomenų srautą, jos paprastai stebi užklausų vykdymo laiką, įkėlimo vėlavimą, saugojimo išlaidas ir klaidų dažnį. Modelių srauto komandoms rūpi skirtingi skaičiai: mokymo trukmė per epochą, sunaudotos GPU valandos, patvirtinimo tikslumas ir galutiniams vartotojams pateikiamų prognozių delsa. Abu pasauliai vertina ekonomiškumą, tačiau jų naudojami svertai yra gana skirtingi.
Duomenų srautų srityje dominuoja orkestravimo įrankiai, tokie kaip „Airflow“ ir „Dagster“, transformavimo varikliai, tokie kaip „dbt“ ir „Spark“, ir sandėliams pritaikyti skaičiavimo įrenginiai iš „Snowflake“ arba „BigQuery“. Modelių srautai remiasi MLOps platformomis, tokiomis kaip „MLflow“ ir „Kubeflow“, bei mokymo infrastruktūra, sukurta naudojant „Kubernetes“, „Ray“ arba valdomas paslaugas, tokias kaip „Vertex AI“. Yra dubliavimosi, ypač aplink funkcijų saugyklas, tačiau ekosistemos išlieka labai skirtingos.
Duomenų srautai dažnai nutrūksta dėl schemos pakeitimų prieš srovę, vėlai gaunamų duomenų arba prastai parašytų transformacijų, kurios nuskaito per daug duomenų. Modelių srautai nutrūksta dėl tokių priežasčių kaip mokymo aptarnavimo iškraipymas, kai gamyboje naudojamos funkcijos skiriasi nuo tų, kurios matomos mokymo metu, arba dėl to, kad hiperparametrų peržiūra eikvoja išteklius nesukurdama geresnių modelių. Abiem atvejais reikia stebėti, tačiau signalai atrodo labai skirtingai.
Duomenų srauto darbas paprastai vyksta duomenų inžinerijos komandų, kurios bendradarbiauja su analitikos ir valdymo suinteresuotosiomis šalimis, rankose. Modelių srauto nuosavybė paprastai tenka mašininio mokymosi inžinerijos arba daugiapakopės prieigos (MLOps) grupėms, dirbančioms kartu su duomenų mokslininkais, kurie perduoda apmokytus modelius. Brandžiose organizacijose šios komandos dalijasi infrastruktūra, pavyzdžiui, funkcijų saugyklomis ir stebėjimo įrankiais, tačiau kasdienės pareigos išlieka atskiros.
Duomenų srautų sąnaudų mažinimas dažnai reiškia brangių užklausų perrašymą, failų glaudinimą į stulpelinius formatus, tokius kaip „Parquet“, arba užduočių planavimą ne piko valandomis. Modelių srautų atveju sutaupymai gaunami taikant tokius metodus kaip taškinis egzempliorių mokymas, modelių distiliavimas ir mažesnių kvantuotų didelių modelių versijų aptarnavimas. Abiem atvejais naudingas automatinis mastelio keitimas, tačiau mastelio keitimas apima gana skirtingus išteklius.
Vieno vamzdyno optimizavimas automatiškai pagerina kitą.
Žaibiškai greitas duomenų srautas nesutrumpina modelio mokymo laiko, o gerai suderintas modelio srautas negali ištaisyti trūkstamų ar pasenusių duomenų. Kiekvienam sluoksniui reikalingas atskiras tikslinis darbas, net jei jie dalijasi infrastruktūra.
Duomenų srautai svarbūs tik analizei, o ne mašininiam mokymuisi.
Šiuolaikinės mašininio mokymosi sistemos labai priklauso nuo funkcijų srautų, kurie iš esmės yra duomenų srautai su griežtesniais patvirtinimo ir versijų reikalavimais. Jų traktavimas kaip atskirų pasaulių dažnai sukelia mokymo ir aptarnavimo iškraipymą.
Modelių srauto optimizavimas yra tiesiog greitesnio GPU pasirinkimas.
Aparatinė įranga padeda, tačiau daugiausia naudos gaunama iš programinės įrangos lygio pokyčių, tokių kaip mišraus tikslumo mokymas, geresni duomenų įkrovikliai, paskirstytos strategijos ir modelių architektūrų genėjimas.
Kai vamzdynas sėkmingai veikia, jis išlieka optimizuotas.
Duomenų kiekiai auga, schemos vystosi ir modelių architektūros keičiasi. Vamzdynams reikia nuolatinio profiliavimo ir derinimo, antraip jie laikui bėgant tyliai tampa brangūs ir lėti.
Jums reikia tik vieno orkestravimo įrankio abiem vamzdynams.
Nors tokios priemonės kaip „Airflow“ ir „Kubeflow“ techniškai gali suplanuoti abu, dauguma komandų kiekvienai sričiai naudoja specializuotus orkestratorius, nes gedimų tvarkymas, pakartotinio bandymo logika ir išteklių reikalavimai labai skiriasi.
Duomenų srauto optimizavimą rinkitės, kai jūsų kliūtis – greitai ir pigiai pateikti patikimus duomenis analitikams ir tolesnėms sistemoms. Investuokite į modelių srauto optimizavimą, kai mokymo ciklai yra lėti, diegimas yra nestabilus arba išvados išlaidos mažina pelno maržas. Praktiškai brandžioms dirbtinio intelekto organizacijoms reikia abiejų, nes greitas modelių srautas, sukurtas ant lėto ar nepatikimo duomenų srauto, vis tiek bus našus.
„Kafka“ ir „Flink“ sudaro paskirstytą srautinio apdorojimo ekosistemą realaus laiko duomenų srautams, o apdorojimas atmintyje pagreitina analizę, nes duomenys saugomi tik RAM atmintyje – kiekvienas iš jų tenkina iš esmės skirtingus architektūrinius greičio, mastelio ir tvarumo poreikius.
„Netflix“ vidinė mašininio mokymosi platforma siūlo glaudžiai integruotus, didelio masto įrankius, skirtus transliacijų suasmeninimui, o nepriklausomi mašininio mokymosi įrankiai suteikia mažesnėms komandoms lankstumo ir kontrolės. Pasirinkimas priklauso nuo masto, pritaikymo poreikių ir esamų investicijų į infrastruktūrą.
Adaptyvi infrastruktūra dinamiškai prisitaiko prie kintančių darbo krūvių, naudodama automatizavimą ir mastelio keitimą realiuoju laiku, o statinės infrastruktūros projektavimas remiasi fiksuotais, iš anksto sukonfigūruotais ištekliais. Pasirinkimas priklauso nuo darbo krūvio kintamumo, biudžeto nuspėjamumo ir veikimo brandos jūsų debesijos aplinkoje.
Apkrovos balansavimas mašininio mokymosi sistemose valdo GPU reikalaujančius išvadų ir mokymo darbo krūvius specializuotoje įrangoje, o paprastas API užklausų apdorojimas paskirsto nedidelį HTTP srautą bendrosios paskirties serveriuose. Jie labai skiriasi sudėtingumu, išteklių poreikiu ir maršruto parinkimo išmanumu.
Atsparumas gedimams proaktyviai perkelia darbo krūvius į sveikas sistemas, kol vartotojai nepastebi problemų, o sistemos gedimų atveju iš naujo paleidžiamos sistemos reaktyviai atkuria paslaugas po netikėtų gedimų. Abu metodai siekia palaikyti prieinamumą, tačiau iš esmės skiriasi laiku, architektūros sudėtingumu ir poveikiu vartotojams.
