Foar de lêste sawat seis moannen haw ik in systeem makke om fraude te bestriden (frauduleuze aktiviteit, fraude, ensfh.) Sûnder in earste ynfrastruktuer foar dit. De ideeën fan hjoed dy't wy hawwe fûn en ymplementearre yn ús systeem helpe ús in protte frauduleuze aktiviteiten te ûntdekken en te analysearjen. Yn dit artikel wol ik prate oer de prinsipes dy't wy folgen en wat wy dien hawwe om de hjoeddeistige steat fan ús systeem te berikken, sûnder yn te gean nei it technyske diel.
Prinsipes fan ús systeem
As jo termen hearre as "automatysk" en "fraude", begjinne jo wierskynlik te tinken oer masine learen, Apache Spark, Hadoop, Python, Airflow, en oare technologyen út it Apache Foundation-ekosysteem en it fjild fan Data Science. Ik tink dat d'r ien aspekt is fan it brûken fan dizze ark dat normaal net neamd wurdt: se fereaskje bepaalde betingsten yn jo bedriuwsysteem foardat jo se kinne begjinne te brûken. Koartsein, jo hawwe in bedriuwsgegevensplatfoarm nedich dat in gegevensmar en pakhús omfettet. Mar wat as jo sa'n platfoarm net hawwe en dizze praktyk noch moatte ûntwikkelje? De folgjende prinsipes dy't ik hjirûnder diel hawwe ús holpen om in punt te berikken wêr't wy kinne konsintrearje op it ferbetterjen fan ús ideeën ynstee fan ien te finen dy't wurket. Dit is lykwols gjin projektplato. Der steane noch in soad dingen yn it plan út in technologysk en produkt eachpunt.
Prinsipe 1: Business Value First
Wy sette "saaklike wearde" op 'e foargrûn fan al ús ynspanningen. Yn it algemien heart elk automatysk analysesysteem ta de groep komplekse systemen mei in heech nivo fan automatisearring en technyske kompleksiteit. It meitsjen fan in folsleine oplossing sil in protte tiid nimme as jo it fanôf it begjin meitsje. Wy besletten om bedriuwswearde foarop te setten en technologyske folsleinens twadde. Yn it echte libben betsjut dit dat wy avansearre technology net akseptearje as dogma. Wy kieze de technology dy't it bêste foar ús wurket op it stuit. Nei ferrin fan tiid kin it lykje dat wy guon modules opnij moatte ymplementearje. Dit is it kompromis dat wy hawwe akseptearre.
Prinsipe 2: Fergrutte yntelliginsje
Ik wedde dat de measte minsken dy't net djip belutsen binne by it ûntwikkeljen fan oplossingen foar masine-learen miskien tinke dat it ferfangen fan minsken it doel is. Yn feite binne oplossingen foar masine learen fier fan perfekt en allinich yn bepaalde gebieten is ferfanging mooglik. Wy hawwe dit idee fan it begjin ôf ôfwiisd om ferskate redenen: unbalansearre gegevens oer frauduleuze aktiviteit en it ûnfermogen om in wiidweidige list mei funksjes te leverjen foar modellen foar masine-learen. Yn tsjinstelling hawwe wy de opsje foar ferbettere yntelliginsje keazen. Dit is in alternatyf konsept fan keunstmjittige yntelliginsje dy't him rjochtet op 'e stypjende rol fan AI, mei de klam op it feit dat kognitive technologyen bedoeld binne om minsklike yntelliginsje te ferbetterjen ynstee fan it te ferfangen. [1]
Sjoen dit soe it ûntwikkeljen fan in folsleine oplossing foar masine-learen fan it begjin ôf in enoarme ynspanning fereaskje, wat de skepping fan wearde foar ús bedriuw soe fertrage. Wy besletten om in systeem te bouwen mei in iteratyf groeiende aspekt fan masinelearen ûnder begelieding fan ús domeineksperts. It útdaagjende diel fan it ûntwikkeljen fan sa'n systeem is dat it ús analisten gefallen moat leverje, net allinich yn termen fan oft it frauduleuze aktiviteit is of net. Yn 't algemien is elke anomaly yn klantgedrach in fertocht gefal dat spesjalisten op ien of oare manier moatte ûndersykje en reagearje. Allinich in fraksje fan dizze rapporteare gefallen kin wier wurde klassifisearre as fraude.
Prinsipe 3: Rich Analytics Platfoarm
It meast útdaagjende diel fan ús systeem is end-to-end ferifikaasje fan 'e workflow fan it systeem. Analysten en ûntwikkelders moatte maklik histoaryske datasets krije mei alle metriken dy't brûkt wurde foar analyse. Derneist soe it gegevensplatfoarm in maklike manier moatte leverje om in besteande set metriken oan te foljen mei nije. De prosessen dy't wy meitsje, en dit binne net allinich softwareprosessen, moatte ús tastean om foarige perioaden maklik opnij te berekkenjen, nije metriken ta te foegjen en de gegevensprognose te feroarjen. Wy koene dit berikke troch alle gegevens te sammeljen dy't ús produksjesysteem genereart. Yn dit gefal soene de gegevens stadichoan in oerlêst wurde. Wy soene in groeiende hoemannichte gegevens moatte opslaan dy't wy net brûke en it beskermje. Yn sa'n senario sille gegevens yn 'e rin fan' e tiid mear en mear irrelevant wurde, mar fereasket noch altyd ús ynspanningen om it te behearjen. Foar ús wie it opslaan fan gegevens gjin sin, dus besleaten wy in oare oanpak te nimmen. Wy besletten om realtime gegevenswinkels te organisearjen om 'e doelentiteiten dy't wy wolle klassifisearje, en allinich de gegevens opslaan wêrmei wy de meast resinte en relevante perioaden kinne kontrolearje. De útdaging foar dizze ynspanning is dat ús systeem heterogeen is, mei meardere gegevenswinkels en softwaremodules dy't soarchfâldige planning nedich binne om op in konsekwinte manier te operearjen.
Untwerpkonsepten fan ús systeem
Wy hawwe fjouwer haadkomponinten yn ús systeem: yntaksysteem, komputaasje, BI-analyse en folchsysteem. Se tsjinje spesifike, isolearre doelen, en wy hâlde se isolearre troch spesifike ûntwerpbenaderingen te folgjen.
Kontrakt-basearre ûntwerp
Alderearst hawwe wy ôfpraat dat komponinten allinich moatte fertrouwe op bepaalde gegevensstruktueren (kontrakten) dy't tusken har trochjûn wurde. Dit makket it maklik te yntegrearjen tusken harren en net oplizze in spesifike gearstalling (en folchoarder) fan komponinten. Bygelyks, yn guon gefallen kinne wy it yntaksysteem direkt yntegrearje mei it warskôgingssysteem. Dat sil yn sa'n gefal dien wurde neffens it ôfpraat warskôgingskontrakt. Dit betsjut dat beide komponinten wurde yntegrearre mei in kontrakt dat elke oare komponint kin brûke. Wy sille gjin ekstra kontrakt tafoegje om warskôgings ta te foegjen oan it folchsysteem fanút it ynfiersysteem. Dizze oanpak fereasket it gebrûk fan in foarbeskaaide minimum oantal kontrakten en simplifies it systeem en kommunikaasje. Yn essinsje nimme wy in oanpak neamd "Contract First Design" en tapasse it op streamingkontrakten. [2]
Streaming oeral
It bewarjen en behearen fan steat yn in systeem sil ûnûntkomber liede ta komplikaasjes yn syn ymplemintaasje. Yn 't algemien moat steat tagonklik wêze fan elke komponint, it moat konsekwint wêze en de meast aktuele wearde leverje oer alle komponinten, en it moat betrouber wêze mei de juste wearden. Derneist sil it hawwen fan oproppen nei persistente opslach om de lêste steat werom te heljen it oantal I/O-operaasjes en kompleksiteit fan 'e algoritmen dy't brûkt wurde yn ús real-time pipelines ferheegje. Hjirtroch hawwe wy besletten om steatopslach, as mooglik, folslein út ús systeem te ferwiderjen. Dizze oanpak fereasket dat alle nedige gegevens opnommen wurde yn it oerdroegen gegevensblok (berjocht). Bygelyks, as wy moatte berekkenje it totale oantal guon observaasjes (it oantal operaasjes of gefallen mei bepaalde skaaimerken), wy berekkenje it yn it ûnthâld en generearje in stream fan sokke wearden. Ofhinklike modules sille partition en batching brûke om de stream te splitsen yn entiteiten en operearje op 'e lêste wearden. Dizze oanpak eliminearre de needsaak om persistente skiifopslach te hawwen foar sokke gegevens. Us systeem brûkt Kafka as berjochtmakelaar en it kin brûkt wurde as database mei KSQL. [3] Mar it brûken derfan soe ús oplossing bot bûn hawwe oan Kafka, en wy besletten it net te brûken. De oanpak dy't wy hawwe keazen lit ús Kafka ferfange troch in oare berjochtmakelaar sûnder grutte ynterne feroaringen oan it systeem.
Dit konsept betsjut net dat wy gjin skiif opslach en databases brûke. Om systeemprestaasjes te testen en te analysearjen, moatte wy in signifikante hoemannichte gegevens op skiif bewarje dy't ferskate metriken en steaten fertsjintwurdigje. It wichtige punt hjir is dat real-time algoritmen net ôfhinklik binne fan sokke gegevens. Yn 'e measte gefallen brûke wy de bewarre gegevens foar offline analyse, debuggen en folgjen fan spesifike gefallen en resultaten dy't it systeem produsearret.
Problemen fan ús systeem
D'r binne bepaalde problemen dy't wy op in bepaald nivo hawwe oplost, mar se fereaskje mear trochtochte oplossingen. No wol ik se hjir mar neame, om't elk punt in eigen artikel wurdich is.
- Wy moatte noch prosessen en belied definiearje dy't de accumulation fan sinfolle en relevante gegevens stypje foar ús automatisearre gegevensanalyse, ûntdekking en ferkenning.
- Opname fan resultaten fan minsklike analyse yn it proses fan it automatysk ynstellen fan it systeem om it te aktualisearjen mei de lêste gegevens. Dit is net allinich it bywurkjen fan ús model, mar ek it bywurkjen fan ús prosessen en it ferbetterjen fan ús begryp fan ús gegevens.
- In lykwicht fine tusken de deterministyske oanpak fan IF-ELSE en ML. Immen sei: "ML is in ark foar de wanhopige." Dit betsjut dat jo ML wolle brûke as jo net langer begripe hoe't jo jo algoritmen kinne optimalisearje en ferbetterje. Oan 'e oare kant lit de deterministyske oanpak de ûntdekking fan anomalies net ta dat net ferwachte.
- Wy hawwe in ienfâldige manier nedich om ús hypotezen of korrelaasjes tusken metriken yn 'e gegevens te testen.
- It systeem moat ferskate nivo's fan wiere positive resultaten hawwe. Fraude gefallen binne mar in fraksje fan alle gefallen dy't kin wurde beskôge posityf foar it systeem. Bygelyks, analysten wolle ûntfange alle fertochte gefallen foar ferifikaasje, en mar in lyts part fan harren binne fraude. It systeem moat effisjint presintearje alle gefallen oan analysts, likefolle oft it is werklike fraude of gewoan fertocht gedrach.
- It gegevensplatfoarm moat histoaryske gegevenssets kinne ophelje mei berekkeningen dy't op 'e flecht generearre en berekkene binne.
- Ynsette ien fan 'e systeemkomponinten maklik en automatysk yn op syn minst trije ferskillende omjouwings: produksje, eksperiminteel (beta) en foar ûntwikkelders.
- En last but not least. Wy moatte in ryk prestaasjetestplatfoarm bouwe wêrop wy ús modellen kinne analysearje. [4]
referinsjes
Boarne: www.habr.com