În ultimele aproximativ șase luni am creat un sistem de combatere a fraudei (activitate frauduloasă, fraudă etc.) fără nicio infrastructură inițială pentru asta. Ideile de astăzi pe care le-am găsit și implementat în sistemul nostru ne ajută să detectăm și să analizăm multe activități frauduloase. În acest articol, aș vrea să vorbesc despre principiile pe care le-am urmat și ce am făcut pentru a atinge starea actuală a sistemului nostru, fără a intra în partea tehnică.
Principiile sistemului nostru
Când auziți termeni precum „automat” și „fraudă”, cel mai probabil începeți să vă gândiți la învățarea automată, Apache Spark, Hadoop, Python, Airflow și alte tehnologii din ecosistemul Apache Foundation și domeniul Data Science. Cred că există un aspect al utilizării acestor instrumente care de obicei nu este menționat: ele necesită anumite cerințe prealabile în sistemul dvs. de întreprindere înainte de a putea începe să le utilizați. Pe scurt, aveți nevoie de o platformă de date de întreprindere care să includă un lac de date și un depozit. Dar dacă nu ai o astfel de platformă și totuși trebuie să dezvolți această practică? Următoarele principii pe care le împărtășesc mai jos ne-au ajutat să ajungem la un punct în care ne putem concentra pe îmbunătățirea ideilor noastre, mai degrabă decât să găsim una care funcționează. Cu toate acestea, acesta nu este un platou de proiect. Sunt încă multe lucruri în plan din punct de vedere tehnologic și de produs.
Principiul 1: valoarea afacerii mai întâi
Punem „valoarea afacerii” în fruntea tuturor eforturilor noastre. În general, orice sistem automat de analiză aparține grupului de sisteme complexe cu un nivel ridicat de automatizare și complexitate tehnică. Crearea unei soluții complete va dura mult timp dacă o creați de la zero. Am decis să punem valoarea afacerii pe primul loc și completitatea tehnologică pe al doilea. În viața reală, asta înseamnă că nu acceptăm tehnologia avansată ca dogmă. Alegem tehnologia care funcționează cel mai bine pentru noi în acest moment. În timp, poate părea că va trebui să reimplementam unele module. Acesta este compromisul pe care l-am acceptat.
Principiul 2: Inteligența sporită
Pun pariu că majoritatea oamenilor care nu sunt profund implicați în dezvoltarea de soluții de învățare automată ar putea crede că înlocuirea oamenilor este scopul. De fapt, soluțiile de învățare automată sunt departe de a fi perfecte și doar în anumite domenii este posibilă înlocuirea. Am respins această idee de la început din mai multe motive: date dezechilibrate privind activitatea frauduloasă și incapacitatea de a oferi o listă cuprinzătoare de caracteristici pentru modelele de învățare automată. În schimb, am ales opțiunea de inteligență îmbunătățită. Acesta este un concept alternativ de inteligență artificială care se concentrează pe rolul de sprijin al AI, subliniind faptul că tehnologiile cognitive sunt menite să îmbunătățească inteligența umană, mai degrabă decât să o înlocuiască. [1]
Având în vedere acest lucru, dezvoltarea unei soluții complete de învățare automată de la început ar necesita un efort uriaș, care ar întârzia crearea de valoare pentru afacerea noastră. Am decis să construim un sistem cu un aspect de învățare automată în creștere iterativă, sub îndrumarea experților noștri în domeniu. Partea dificilă a dezvoltării unui astfel de sistem este că trebuie să furnizeze analiștilor noștri cazuri nu numai în ceea ce privește dacă este vorba de activitate frauduloasă sau nu. În general, orice anomalie în comportamentul clienților este un caz suspect pe care specialiștii trebuie să-l investigheze și să răspundă cumva. Doar o parte din aceste cazuri raportate poate fi cu adevărat clasificată drept fraudă.
Principiul 3: Platformă de analiză bogată
Cea mai dificilă parte a sistemului nostru este verificarea de la capăt la capăt a fluxului de lucru al sistemului. Analiștii și dezvoltatorii ar trebui să obțină cu ușurință seturi de date istorice cu toate valorile utilizate pentru analiză. În plus, platforma de date ar trebui să ofere o modalitate ușoară de a completa un set existent de valori cu altele noi. Procesele pe care le creăm, și acestea nu sunt doar procese software, ar trebui să ne permită să recalculăm cu ușurință perioadele anterioare, să adăugăm noi valori și să modificăm prognoza datelor. Am putea realiza acest lucru acumulând toate datele pe care le generează sistemul nostru de producție. În acest caz, datele ar deveni treptat o pacoste. Ar trebui să stocăm o cantitate tot mai mare de date pe care nu le folosim și să le protejăm. Într-un astfel de scenariu, datele vor deveni din ce în ce mai irelevante în timp, dar necesită totuși eforturile noastre pentru a le gestiona. Pentru noi, acumularea de date nu avea sens, așa că am decis să adoptăm o altă abordare. Am decis să organizăm depozite de date în timp real în jurul entităților țintă pe care dorim să le clasificăm și să stocăm doar datele care ne permit să verificăm perioadele cele mai recente și relevante. Provocarea acestui efort este că sistemul nostru este eterogen, cu mai multe depozite de date și module software care necesită o planificare atentă pentru a funcționa într-o manieră consecventă.
Concepte de proiectare ale sistemului nostru
Avem patru componente principale în sistemul nostru: sistem de asimilare, sistem de calcul, analiză BI și sistem de urmărire. Acestea servesc unor scopuri specifice, izolate și le menținem izolate, urmând abordări specifice de proiectare.
Design bazat pe contract
În primul rând, am convenit că componentele ar trebui să se bazeze doar pe anumite structuri de date (contracte) care sunt transmise între ele. Acest lucru facilitează integrarea între ele și nu impune o compoziție (și ordine) specifică a componentelor. De exemplu, în unele cazuri, acest lucru ne permite să integrăm direct sistemul de admisie cu sistemul de urmărire a alertelor. Într-un astfel de caz, acest lucru se va face în conformitate cu contractul de alertă convenit. Aceasta înseamnă că ambele componente vor fi integrate folosind un contract pe care îl poate folosi orice altă componentă. Nu vom adăuga un contract suplimentar pentru a adăuga alerte la sistemul de urmărire din sistemul de intrare. Această abordare necesită utilizarea unui număr minim predeterminat de contracte și simplifică sistemul și comunicațiile. În esență, adoptăm o abordare numită „Contract First Design” și o aplicăm contractelor de streaming. [2]
Streaming peste tot
Salvarea și gestionarea stării într-un sistem va duce inevitabil la complicații în implementarea acestuia. În general, starea ar trebui să fie accesibilă din orice componentă, ar trebui să fie consecventă și să ofere cea mai actuală valoare pentru toate componentele și ar trebui să fie fiabilă cu valorile corecte. În plus, apelurile la stocarea persistentă pentru a prelua cea mai recentă stare va crește numărul de operațiuni I/O și complexitatea algoritmilor utilizați în conductele noastre în timp real. Din această cauză, am decis să eliminăm complet stocarea de stat, dacă este posibil, din sistemul nostru. Această abordare necesită ca toate datele necesare să fie incluse în blocul de date transmis (mesaj). De exemplu, dacă trebuie să calculăm numărul total al unor observații (numărul de operații sau cazuri cu anumite caracteristici), îl calculăm în memorie și generăm un flux de astfel de valori. Modulele dependente vor folosi partiția și loturile pentru a împărți fluxul în entități și a opera pe cele mai recente valori. Această abordare a eliminat necesitatea de a avea stocare persistentă pe disc pentru astfel de date. Sistemul nostru folosește Kafka ca broker de mesaje și poate fi folosit ca bază de date cu KSQL. [3] Dar utilizarea acesteia ar fi legat foarte mult soluția noastră de Kafka și am decis să nu o folosim. Abordarea pe care am ales-o ne permite să înlocuim Kafka cu un alt broker de mesaje fără modificări interne majore ale sistemului.
Acest concept nu înseamnă că nu folosim stocarea pe disc și bazele de date. Pentru a testa și analiza performanța sistemului, trebuie să stocăm pe disc o cantitate semnificativă de date care reprezintă diferite metrici și stări. Punctul important aici este că algoritmii în timp real nu depind de astfel de date. În cele mai multe cazuri, folosim datele stocate pentru analiza offline, depanare și urmărire a cazurilor și rezultatelor specifice pe care le produce sistemul.
Probleme ale sistemului nostru
Există anumite probleme pe care le-am rezolvat până la un anumit nivel, dar necesită soluții mai atente. Acum aș dori doar să le menționez aici pentru că fiecare punct își merită propriul articol.
- Încă trebuie să definim procese și politici care să sprijine acumularea de date semnificative și relevante pentru analiza, descoperirea și explorarea automată a datelor.
- Încorporarea rezultatelor analizei umane în procesul de configurare automată a sistemului pentru a-l actualiza cu cele mai recente date. Aceasta nu înseamnă doar actualizarea modelului nostru, ci și actualizarea proceselor noastre și îmbunătățirea înțelegerii datelor noastre.
- Găsirea unui echilibru între abordarea deterministă a IF-ELSE și ML. Cineva a spus: „ML este un instrument pentru cei disperați”. Aceasta înseamnă că veți dori să utilizați ML atunci când nu mai înțelegeți cum să vă optimizați și să vă îmbunătățiți algoritmii. Pe de altă parte, abordarea deterministă nu permite detectarea anomaliilor care nu au fost anticipate.
- Avem nevoie de o modalitate simplă de a ne testa ipotezele sau corelațiile dintre valorile din date.
- Sistemul trebuie să aibă mai multe niveluri de rezultate pozitive adevărate. Cazurile de fraudă sunt doar o fracțiune din toate cazurile care pot fi considerate pozitive pentru sistem. De exemplu, analiștii doresc să primească toate cazurile suspecte pentru verificare și doar o mică parte dintre acestea sunt fraude. Sistemul trebuie să prezinte eficient toate cazurile analiştilor, indiferent dacă este vorba de o fraudă reală sau doar de un comportament suspect.
- Platforma de date ar trebui să poată prelua seturi de date istorice cu calcule generate și calculate din mers.
- Implementați ușor și automat oricare dintre componentele sistemului în cel puțin trei medii diferite: producție, experimental (beta) și pentru dezvoltatori.
- Și nu în ultimul rând. Trebuie să construim o platformă bogată de testare a performanței pe care să ne putem analiza modelele. [4]
referințe
Sursa: www.habr.com