Jumio DI sistema: sukčiavimą gaudo per milisekundes ir taupo pinigus

·


Jumio realaus laiko DI funkcijų saugyklos architektūra AWS aplinkoje

Yra vietų, kur „palaukime iki ryto“ kainuoja pinigus. Kartais daug.

Jumio, tapatybės patvirtinimo įmonė, AWS bloge parodė, kaip susitvarkė DI sukčiavimo aptikimą realiu laiku. Tikslas buvo paprastas: modeliai turi gauti reikalingus požymius greičiau nei per 100 milisekundžių. Ne po minutės. Ne po valandos.

Ir čia prasideda tikras DI darbas, apie kurį konferencijose mažiau blizgučių.

Problema ne modelyje

Daug komandų vis dar galvoja: „reikia geresnio modelio“. Kartais taip. Bet Jumio istorija rodo kitą bėdą: modelis gali būti geras, bet jei jis gauna vėluojančius, dubliuotus arba skirtingai apibrėžtus duomenis, jis sprendžia kaip žmogus su puse bylos.

AWS aprašyme Jumio minėjo kelias skausmingas vietas: skirtingos komandos turėjo savo offline duomenų saugyklas, požymiai buvo perkeliami į produkciją rankomis, o sukčiavimo scenarijuose reikėjo labai mažos delsos.

Žodžiu, ne romantika. Santechnika.

Kaip jie sutvarkė duomenų kelią

Jumio pasirinko srautinį principą. Įvykiai keliauja per Amazon Kinesis, Apache Flink juos apdoroja, o Amazon SageMaker Feature Store laiko požymius modeliams. Karšti duomenys pasiekiami per atmintyje veikiančią saugyklą, šaltesni – per standartinį sluoksnį.

Čia labai ūkiška logika. Tai, ko reikia dabar, laikai po ranka. Tai, ko reikės analizei ir mokymui, dedi į ilgesnę lentyną.

AWS rašo, kad toks sprendimas Jumio atveju padėjo sutaupyti apie 120 tūkst. JAV dolerių per metus, neprarandant mažos delsos. Čia jau ne „DI gražiai atsako“. Čia DI atsiperka.

Ką iš to pasiimti mažesnei įmonei

Ne kiekvienai Lietuvos įmonei reikia Kinesis, Flink ir kelių regionų architektūros. Bet principas tinka beveik visiems.

Jei nori naudoti DI sprendimams, pirmiau paklausk:

  • ar mūsų duomenys apibrėžti vienodai?
  • ar modelis gauna naujausią informaciją?
  • ar žinome, kiek kainuoja delsimas?
  • ar turime monitoringą, kai modelis pradeda gauti prastesnį signalą?

Čia nuobodus sąrašas. Bet būtent tokie sąrašai išgelbėja projektus nuo „pabandėm DI, neveikė“ kapinių.

DI pradeda bręsti

Man Jumio pavyzdys patinka dėl vienos priežasties: jis ne apie pažadą. Jis apie gamybą. Apie duomenų vėlavimą, kainą, monitoringą, komandų susitarimus.

Trumpai tariant: jei tavo DI projektas neturi duomenų tvarkos, jis dar nėra projektas. Jis yra eksperimentas.

Šaltinis: AWS Machine Learning Blog.

Norisi DI panaudoti ne prezentacijai, o rezultatui? Per Salvaro padedame įmonėms atsirinkti procesus, kur DI turi aiškią grąžą.