Dum la lastaj ĉirkaŭ ses monatoj mi kreas sistemon por kontraŭbatali fraŭdon (fraŭda agado, fraŭdo, ktp.) sen iu komenca infrastrukturo por tio. La hodiaŭaj ideoj, kiujn ni trovis kaj efektivigis en nia sistemo, helpas nin detekti kaj analizi multajn fraŭdajn agadojn. En ĉi tiu artikolo, mi ŝatus paroli pri la principoj, kiujn ni sekvis kaj kion ni faris por atingi la nunan staton de nia sistemo, sen eniri la teknikan parton.
Principoj de nia sistemo
Kiam vi aŭdas terminojn kiel "aŭtomata" kaj "fraŭdo", vi plej verŝajne komencas pensi pri maŝina lernado, Apache Spark, Hadoop, Python, Airflow kaj aliaj teknologioj de la Apache Foundation-ekosistemo kaj la Data Science-kampo. Mi pensas, ke estas unu aspekto de uzado de ĉi tiuj iloj, kiu kutime ne estas menciita: ili postulas certajn antaŭkondiĉojn en via entreprena sistemo antaŭ ol vi povas komenci uzi ilin. Mallonge, vi bezonas entreprenan datuman platformon, kiu inkluzivas datuman lagon kaj magazenon. Sed kio se vi ne havas tian platformon kaj ankoraŭ bezonas disvolvi ĉi tiun praktikon? La sekvaj principoj, kiujn mi dividas malsupre, helpis nin atingi punkton, kie ni povas koncentriĝi pri plibonigo de niaj ideoj prefere ol trovi unu kiu funkcias. Tamen, ĉi tio ne estas projekta altebenaĵo. Estas ankoraŭ multaj aferoj en la plano el teknologia kaj produkta vidpunkto.
Principo 1: Komerca Valoro Unue
Ni metas "komercan valoron" ĉe la avangardo de ĉiuj niaj klopodoj. Ĝenerale, ajna aŭtomata analizsistemo apartenas al la grupo de kompleksaj sistemoj kun alta nivelo de aŭtomatigo kaj teknika komplekseco. Krei kompletan solvon prenos multe da tempo se vi kreos ĝin de nulo. Ni decidis meti komercan valoron unue kaj teknologian kompletecon due. En la reala vivo, tio signifas, ke ni ne akceptas altnivelan teknologion kiel dogmon. Ni elektas la teknologion, kiu funkcias plej bone por ni nuntempe. Kun la tempo, eble ŝajnas, ke ni devos reefektigi kelkajn modulojn. Jen la kompromiso, kiun ni akceptis.
Principo 2: Pliigita inteligenteco
Mi vetas, ke plej multaj homoj, kiuj ne estas profunde implikitaj en evoluigado de maŝinlernado-solvoj, povus pensi, ke anstataŭigi homojn estas la celo. Fakte, maŝinlernadsolvoj estas malproksimaj de perfektaj kaj nur en certaj lokoj estas anstataŭaĵo ebla. Ni malakceptis ĉi tiun ideon de la komenco pro pluraj kialoj: malekvilibraj datumoj pri fraŭda agado kaj la malkapablo provizi ampleksan liston de funkcioj por maŝinlernado-modeloj. Kontraste, ni elektis la plifortigitan inteligentecan opcion. Ĉi tio estas alternativa koncepto de artefarita inteligenteco, kiu temigas la subtenan rolon de AI, emfazante la fakton, ke kognaj teknologioj celas plibonigi homan inteligentecon prefere ol anstataŭigi ĝin. [1]
Konsiderante ĉi tion, evoluigi kompletan maŝinlernadsolvon de la komenco postulus grandegan penon, kiu prokrastus la kreadon de valoro por nia komerco. Ni decidis konstrui sistemon kun ripete kreskanta aspekto de maŝinlernado sub la gvidado de niaj domajnaj fakuloj. La malfacila parto de disvolvi tian sistemon estas, ke ĝi devas provizi niajn analizistojn per kazoj ne nur koncerne ĉu ĝi estas fraŭda agado aŭ ne. Ĝenerale, ajna anomalio en klienta konduto estas suspektinda kazo, kiun specialistoj bezonas esplori kaj respondi iel. Nur frakcio de ĉi tiuj raportitaj kazoj povas vere esti klasifikita kiel fraŭdo.
Principo 3: Riĉa Analytics Platformo
La plej malfacila parto de nia sistemo estas fin-al-fina konfirmo de la laborfluo de la sistemo. Analizistoj kaj programistoj devas facile akiri historiajn datumajn arojn kun ĉiuj metrikoj uzataj por analizo. Aldone, la datumplatformo devus provizi facilan manieron kompletigi ekzistantan aron de metrikoj kun novaj. La procezoj, kiujn ni kreas, kaj ĉi tiuj ne estas nur programaj procezoj, devus ebligi al ni facile rekalkuli antaŭajn periodojn, aldoni novajn metrikojn kaj ŝanĝi la datuman prognozon. Ni povus atingi ĉi tion amasigante ĉiujn datumojn, kiujn generas nia produktadsistemo. En ĉi tiu kazo, la datumoj iom post iom fariĝus ĝeno. Ni bezonus konservi kreskantan kvanton da datumoj, kiujn ni ne uzas, kaj protekti ĝin. En tia scenaro, datumoj fariĝos pli kaj pli sensignivaj kun la tempo, sed ankoraŭ postulas niajn klopodojn administri ĝin. Por ni, datuma kolektado ne havis sencon, do ni decidis preni alian aliron. Ni decidis organizi realtempajn datumbutikojn ĉirkaŭ la celaj estaĵoj, kiujn ni volas klasifiki, kaj konservi nur la datumojn, kiuj ebligas al ni kontroli la plej freŝajn kaj rilatajn periodojn. La defio al ĉi tiu penado estas, ke nia sistemo estas heterogena, kun multoblaj datumbutikoj kaj programaraj moduloj, kiuj postulas zorgan planadon por funkcii konsekvence.
Dezajnaj konceptoj de nia sistemo
Ni havas kvar ĉefajn komponantojn en nia sistemo: ingesta sistemo, komputila, BI-analizo kaj spursistemo. Ili servas specifajn, izolitajn celojn, kaj ni tenas ilin izolitaj sekvante specifajn projektajn alirojn.
Kontrakt-bazita dezajno
Antaŭ ĉio, ni konsentis, ke komponantoj devas nur fidi certajn datumstrukturojn (kontraktoj), kiuj estas pasigitaj inter ili. Ĉi tio faciligas integriĝi inter ili kaj ne trudi specifan komponadon (kaj ordon) de komponantoj. Ekzemple, en iuj kazoj ĉi tio ebligas al ni rekte integri la konsuman sistemon kun la atentiga spursistemo. En tia kazo, ĉi tio estos farita laŭ la interkonsentita atentiga kontrakto. Ĉi tio signifas, ke ambaŭ komponantoj estos integritaj per kontrakto, kiun iu ajn alia komponanto povas uzi. Ni ne aldonos plian kontrakton por aldoni atentigojn al la spursistemo de la eniga sistemo. Ĉi tiu aliro postulas la uzon de antaŭfiksita minimuma nombro da kontraktoj kaj simpligas la sistemon kaj komunikadojn. Esence, ni prenas aliron nomitan "Kontrakto Unua Dezajno" kaj aplikas ĝin al streaming-kontraktoj. [2]
Fluante ĉie
Ŝpari kaj administri staton en sistemo neeviteble kondukos al komplikaĵoj en ĝia efektivigo. Ĝenerale, ŝtato devus esti alirebla de iu ajn komponento, ĝi devus esti konsekvenca kaj disponigi la plej aktualan valoron tra ĉiuj komponentoj, kaj ĝi devus esti fidinda kun la ĝustaj valoroj. Aldone, havi vokojn al konstanta stokado por retrovi la lastan staton pliigos la nombron da I/O-operacioj kaj kompleksecon de la algoritmoj uzataj en niaj realtempaj duktoj. Pro tio, ni decidis forigi ŝtatan stokadon, se eble, tute de nia sistemo. Ĉi tiu aliro postulas ke ĉiuj necesaj datenoj estu inkluditaj en la elsendita datumbloko (mesaĝo). Ekzemple, se ni bezonas kalkuli la totalan nombron de iuj observoj (la nombro da operacioj aŭ kazoj kun certaj trajtoj), ni kalkulas ĝin en memoro kaj generas fluon de tiaj valoroj. Dependaj moduloj uzos sekcion kaj batadon por dividi la fluon en entojn kaj funkcii per la plej novaj valoroj. Tiu aliro eliminis la bezonon havi konstantan diskstokadon por tiaj datenoj. Nia sistemo uzas Kafka kiel mesaĝmakleristo kaj ĝi povas esti uzata kiel datumbazo kun KSQL. [3] Sed uzi ĝin forte ligus nian solvon al Kafka, kaj ni decidis ne uzi ĝin. La aliro, kiun ni elektis, ebligas al ni anstataŭigi Kafkan per alia mesaĝmakleristo sen gravaj internaj ŝanĝoj al la sistemo.
Ĉi tiu koncepto ne signifas, ke ni ne uzas disko-stokadon kaj datumbazojn. Por testi kaj analizi sisteman rendimenton, ni devas konservi signifan kvanton da datumoj sur disko, kiu reprezentas diversajn metrikojn kaj statojn. La grava punkto ĉi tie estas, ke realtempaj algoritmoj ne dependas de tiaj datumoj. Plejofte, ni uzas la konservitajn datumojn por eksterreta analizo, senararigado kaj spurado de specifaj kazoj kaj rezultoj, kiujn la sistemo produktas.
Problemoj de nia sistemo
Estas iuj problemoj, kiujn ni solvis al certa nivelo, sed ili postulas pli pripensemajn solvojn. Nun mi nur ŝatus mencii ilin ĉi tie ĉar ĉiu punkto valoras sian propran artikolon.
- Ni ankoraŭ bezonas difini procezojn kaj politikojn, kiuj subtenas la amasiĝon de signifaj kaj rilataj datumoj por nia aŭtomatigita datuma analizo, malkovro kaj esplorado.
- Enkorpiĝo de homaj analizrezultoj en la procezon aŭtomate agordi la sistemon por ĝisdatigi ĝin kun la plej novaj datumoj. Ĉi tio ne nur ĝisdatigas nian modelon, sed ankaŭ ĝisdatigas niajn procezojn kaj plibonigas nian komprenon pri niaj datumoj.
- Trovi ekvilibron inter la determinisma aliro de IF-ELSE kaj ML. Iu diris, "ML estas ilo por senesperaj." Ĉi tio signifas, ke vi volos uzi ML kiam vi ne plu komprenas kiel optimumigi kaj plibonigi viajn algoritmojn. Aliflanke, la determinisma aliro ne permesas la detekton de anomalioj kiuj ne estis antaŭviditaj.
- Ni bezonas simplan manieron testi niajn hipotezojn aŭ korelaciojn inter metrikoj en la datumoj.
- La sistemo devas havi plurajn nivelojn de veraj pozitivaj rezultoj. Fraŭdaj kazoj estas nur frakcio de ĉiuj kazoj, kiuj povas esti konsiderataj pozitivaj por la sistemo. Ekzemple, analizistoj volas ricevi ĉiujn suspektindajn kazojn por konfirmo, kaj nur malgranda parto de ili estas fraŭdoj. La sistemo devas efike prezenti ĉiujn kazojn al analizistoj, sendepende de ĉu ĝi estas reala fraŭdo aŭ nur suspektinda konduto.
- La datumplatformo devus povi retrovi historiajn datumajn arojn kun kalkuloj generitaj kaj kalkulitaj sur la flugo.
- Facile kaj aŭtomate disfaldi iun ajn el la sistemaj komponantoj en almenaŭ tri malsamaj medioj: produktado, eksperimenta (beta) kaj por programistoj.
- Kaj laste sed ne malplej. Ni devas konstrui riĉan rendimentan testan platformon sur kiu ni povas analizi niajn modelojn. [4]
referencoj
fonto: www.habr.com