Vytvorenie automatického systému na boj proti votrelcom na mieste (podvody)

Posledných asi šesť mesiacov som vytváral systém na boj proti podvodom (podvodná činnosť, podvody atď.) bez akejkoľvek počiatočnej infraštruktúry na to. Dnešné nápady, ktoré sme našli a implementovali do nášho systému, nám pomáhajú odhaliť a analyzovať mnohé podvodné aktivity. V tomto článku by som rád hovoril o princípoch, ktorými sme sa riadili a čo sme urobili, aby sme dosiahli súčasný stav nášho systému, bez toho, aby som zachádzal do technickej časti.

Princípy nášho systému

Keď počujete výrazy ako „automatické“ a „podvod“, s najväčšou pravdepodobnosťou začnete premýšľať o strojovom učení, Apache Spark, Hadoop, Python, Airflow a ďalších technológiách z ekosystému Apache Foundation a oblasti Data Science. Myslím si, že existuje jeden aspekt používania týchto nástrojov, ktorý sa zvyčajne nespomína: vyžadujú určité predpoklady vo vašom podnikovom systéme, kým ich začnete používať. Stručne povedané, potrebujete podnikovú dátovú platformu, ktorá zahŕňa dátové jazero a sklad. Čo ak však takúto platformu nemáte a stále potrebujete túto prax rozvíjať? Nasledujúce princípy, ktoré zdieľam nižšie, nám pomohli dosiahnuť bod, v ktorom sa môžeme sústrediť na zlepšovanie našich nápadov namiesto toho, aby sme našli ten, ktorý funguje. Toto však nie je plató projektu. V pláne je ešte veľa vecí z technologického a produktového hľadiska.

Zásada 1: Obchodná hodnota na prvom mieste

Do popredia všetkého nášho úsilia kladieme „obchodnú hodnotu“. Vo všeobecnosti každý automatický analytický systém patrí do skupiny komplexných systémov s vysokou úrovňou automatizácie a technickej zložitosti. Vytvorenie kompletného riešenia zaberie veľa času, ak ho vytvoríte od začiatku. Rozhodli sme sa dať na prvé miesto obchodnú hodnotu a na druhé technologickú úplnosť. V reálnom živote to znamená, že vyspelú technológiu neprijímame ako dogmu. Vyberáme si technológiu, ktorá nám momentálne najviac vyhovuje. S odstupom času sa môže zdať, že niektoré moduly budeme musieť nanovo implementovať. Toto je kompromis, ktorý sme prijali.

Princíp 2: Rozšírená inteligencia

Stavím sa, že väčšina ľudí, ktorí nie sú hlboko zapojení do vývoja riešení strojového učenia, si môže myslieť, že cieľom je nahradiť ľudí. V skutočnosti sú riešenia strojového učenia ďaleko od dokonalosti a výmena je možná len v určitých oblastiach. Túto myšlienku sme od začiatku odmietli z niekoľkých dôvodov: nevyvážené údaje o podvodných aktivitách a neschopnosti poskytnúť komplexný zoznam funkcií pre modely strojového učenia. Na rozdiel od toho sme zvolili možnosť vylepšenej inteligencie. Ide o alternatívny koncept umelej inteligencie, ktorý sa zameriava na podpornú úlohu AI, pričom zdôrazňuje skutočnosť, že kognitívne technológie sú určené skôr na zlepšenie ľudskej inteligencie, než na jej nahradenie. [1]

Vzhľadom na to by vývoj kompletného riešenia strojového učenia od začiatku vyžadoval obrovské úsilie, čo by oddialilo vytváranie hodnoty pre naše podnikanie. Rozhodli sme sa vybudovať systém s iteratívne rastúcim aspektom strojového učenia pod vedením našich expertov na doménu. Náročnou časťou vývoja takéhoto systému je, že musí našim analytikom poskytnúť prípady nielen z hľadiska toho, či ide o podvodnú činnosť alebo nie. Vo všeobecnosti je akákoľvek anomália v správaní zákazníkov podozrivým prípadom, ktorý musia špecialisti preskúmať a nejako reagovať. Len zlomok z týchto nahlásených prípadov možno skutočne klasifikovať ako podvod.

Princíp 3: Platforma bohatej analýzy

Najnáročnejšou časťou nášho systému je komplexné overenie pracovného toku systému. Analytici a vývojári by mali jednoducho získať historické súbory údajov so všetkými metrikami používanými na analýzu. Okrem toho by dátová platforma mala poskytovať jednoduchý spôsob, ako doplniť existujúci súbor metrík o nové. Procesy, ktoré vytvárame, a nejde len o softvérové ​​procesy, by nám mali umožniť jednoducho prepočítať predchádzajúce obdobia, pridať nové metriky a zmeniť prognózu údajov. Mohli by sme to dosiahnuť zhromaždením všetkých údajov, ktoré generuje náš produkčný systém. Údaje by v tomto prípade postupne obťažovali. Museli by sme ukladať čoraz väčšie množstvo údajov, ktoré nepoužívame, a chrániť ich. V takomto scenári budú údaje časom čoraz viac irelevantnejšie, no stále si vyžadujú naše úsilie na ich správu. Pre nás hromadenie dát nemalo zmysel, a tak sme sa rozhodli pre iný prístup. Rozhodli sme sa usporiadať úložiská údajov v reálnom čase okolo cieľových entít, ktoré chceme klasifikovať, a ukladať iba údaje, ktoré nám umožňujú skontrolovať najnovšie a relevantné obdobia. Výzvou tohto úsilia je, že náš systém je heterogénny, s viacerými dátovými skladmi a softvérovými modulmi, ktoré si vyžadujú starostlivé plánovanie, aby fungovali konzistentným spôsobom.

Dizajnové koncepcie nášho systému

V našom systéme máme štyri hlavné komponenty: systém prijímania, výpočtový systém, analýzu BI a systém sledovania. Slúžia na špecifické, izolované účely a udržiavame ich izolované dodržiavaním špecifických dizajnových prístupov.

Vytvorenie automatického systému na boj proti votrelcom na mieste (podvody)

Dizajn na základe zmluvy

V prvom rade sme sa zhodli, že komponenty by sa mali spoliehať len na určité dátové štruktúry (zmluvy), ktoré si medzi sebou prenášajú. To uľahčuje integráciu medzi nimi a nevyžaduje špecifické zloženie (a poradie) komponentov. V niektorých prípadoch nám to napríklad umožňuje priamo integrovať sací systém so systémom sledovania výstrahy. V takom prípade sa tak stane v súlade s dohodnutou zmluvou o varovaní. To znamená, že oba komponenty budú integrované pomocou zmluvy, ktorú môže použiť ktorýkoľvek iný komponent. Nebudeme pridávať ďalšiu zmluvu na pridávanie upozornení do systému sledovania zo vstupného systému. Tento prístup vyžaduje použitie vopred stanoveného minimálneho počtu zmlúv a zjednodušuje systém a komunikáciu. V zásade používame prístup nazývaný „Prvý návrh zmluvy“ a aplikujeme ho na zmluvy o streamovaní. [2]

Streamovanie všade

Ukladanie a správa stavu v systéme nevyhnutne povedie ku komplikáciám pri jeho implementácii. Vo všeobecnosti by mal byť stav dostupný z akéhokoľvek komponentu, mal by byť konzistentný a poskytovať najaktuálnejšiu hodnotu vo všetkých komponentoch a mal by byť spoľahlivý so správnymi hodnotami. Okrem toho volania do trvalého úložiska na získanie najnovšieho stavu zvýšia počet I/O operácií a zložitosť algoritmov používaných v našich potrubiach v reálnom čase. Z tohto dôvodu sme sa rozhodli štátne úložisko podľa možnosti úplne odstrániť z nášho systému. Tento prístup vyžaduje, aby všetky potrebné údaje boli zahrnuté v prenášanom dátovom bloku (správe). Ak napríklad potrebujeme vypočítať celkový počet niektorých pozorovaní (počet operácií alebo prípadov s určitými charakteristikami), vypočítame ho v pamäti a vygenerujeme prúd takýchto hodnôt. Závislé moduly budú používať rozdelenie a dávkovanie na rozdelenie toku do entít a pracovať s najnovšími hodnotami. Tento prístup eliminoval potrebu mať trvalé diskové úložisko pre takéto dáta. Náš systém využíva Kafku ako sprostredkovateľa správ a možno ho použiť ako databázu s KSQL. [3] Ale jeho použitie by naše riešenie výrazne spájalo s Kafkom a rozhodli sme sa ho nepoužiť. Prístup, ktorý sme zvolili, nám umožňuje nahradiť Kafku iným sprostredkovateľom správ bez veľkých interných zmien v systéme.

Tento koncept neznamená, že nepoužívame diskové úložiská a databázy. Aby sme mohli testovať a analyzovať výkon systému, musíme na disk uložiť značné množstvo údajov, ktoré predstavujú rôzne metriky a stavy. Dôležité je, že algoritmy v reálnom čase nezávisia od takýchto údajov. Vo väčšine prípadov používame uložené údaje na offline analýzu, ladenie a sledovanie konkrétnych prípadov a výsledkov, ktoré systém vytvára.

Problémy nášho systému

Existujú určité problémy, ktoré sme do určitej miery vyriešili, no vyžadujú si premyslenejšie riešenia. Teraz by som ich tu rád spomenul, pretože každý bod stojí za vlastný článok.

  • Stále musíme definovať procesy a zásady, ktoré podporujú zhromažďovanie zmysluplných a relevantných údajov pre našu automatizovanú analýzu, zisťovanie a prieskum údajov.
  • Začlenenie výsledkov ľudskej analýzy do procesu automatického nastavenia systému s cieľom aktualizovať ho najnovšími údajmi. Nejde len o aktualizáciu nášho modelu, ale aj o aktualizáciu našich procesov a zlepšenie nášho chápania našich údajov.
  • Nájdenie rovnováhy medzi deterministickým prístupom IF-ELSE a ML. Niekto povedal: "ML je nástroj pre zúfalcov." To znamená, že budete chcieť používať ML, keď už nebudete rozumieť tomu, ako optimalizovať a zlepšovať svoje algoritmy. Na druhej strane deterministický prístup neumožňuje odhaliť anomálie, s ktorými sa nepočítalo.
  • Potrebujeme jednoduchý spôsob, ako otestovať naše hypotézy alebo korelácie medzi metrikami v údajoch.
  • Systém musí mať niekoľko úrovní skutočne pozitívnych výsledkov. Prípady podvodov sú len zlomkom všetkých prípadov, ktoré možno považovať za pozitívne pre systém. Analytici chcú napríklad dostávať na overenie všetky podozrivé prípady a len malá časť z nich sú podvody. Systém musí analytikom efektívne prezentovať všetky prípady bez ohľadu na to, či ide o skutočný podvod alebo len o podozrivé správanie.
  • Dátová platforma by mala byť schopná získať historické súbory údajov s výpočtami generovanými a vypočítanými za behu.
  • Ľahko a automaticky nasadzujte ktorýkoľvek zo systémových komponentov aspoň v troch rôznych prostrediach: produkčné, experimentálne (beta) a pre vývojárov.
  • A v neposlednom rade. Potrebujeme vybudovať bohatú platformu na testovanie výkonu, na ktorej môžeme analyzovať naše modely. [4]

referencie

  1. Čo je to Augmented Intelligence?
  2. Implementácia API-First Design Methodology
  3. Kafka sa transformuje na „databázu streamovania udalostí“
  4. Pochopenie krivky AUC - ROC

Zdroj: hab.com

Pridať komentár