Clasificarea este una dintre cele mai frecvent întâlnite modalități pentru dezvoltarea de soluții în sistemele bazate pe inteligență artificială. Câteva dintre cele mai populare aplicații ale acestor algoritmi sunt: recunoașterea obiectelor din imagini, transcrierea scrisului de mână și recunoașterea literelor, diagnosticarea medicală, detecția spamului, analiza sentimentelor în procesarea limbajului natural, clasificarea utilizatorilor sau a clienților unei piețe, predicția abandonului clienților, detecția operațiilor bancare. Articolul de față prezintă o suită de servicii ale platformei Google Cloud Platform (GCP) în rezolvarea unei probleme de clasificare binară: detecția tranzacțiilor frauduloase.
În funcție de rezultatul ce soluționează problema de clasificare, putem vorbi despre două categorii: clasificare binară și clasificare în mai multe clase. În cazul de față, întrucât ne dorim să etichetăm tranzacțiile folosind numai două etichete, frauduloase, respectiv nefrauduloase, problema devine una de clasificare binară. Pornind de la o mulțime inițială M cu tranzacții bancare despre care nu știm dacă sunt sau nu frauduloase, ne dorim să prezicem apartenența fiecăreia dintre aceste tranzacții la una din cele două submulțimi disjuncte (SM1 și SM2) ale mulțimii inițiale M: la submulțimea cu tranzacțiile frauduloase sau la cea cu operațiile obișnuite.
De-a lungul acestui proces, vom folosi BigQuery ML pentru antrenarea și evaluarea modelului de regresie logistică folosit, dar și GCP Dataflow pentru încărcarea datelor în BigQuery și Looker Studio pentru vizualizările ce descriu rezultatele predicțiilor.
BigQuery ML este o extensie a serviciului Google BigQuery care permite utilizatorilor să creeze și să antreneze modele de învățare automată direct în mediul BigQuery, fără a fi nevoie să transfere datele către altă platformă sau să folosească un instrument separat de învățare automată. Am ales să folosim acest serviciu luând în calcul numeroasele beneficii, printre care cele mai evidente sunt: ușurința cu care l-am utilizat, fără a fi nevoie să transferăm datele în altă locație, dar și timpul redus de dezvoltare și implementare. Mai mult de atât, având în vedere flexibilitatea serviciului BigQuery ML, partea de învățare automată a proiectului pe care l-am dezvoltat nu a fost deloc afectată, ținând cont de lista de modele din care am avut de ales, dar și parametrizarea facilă a acestora. Fiind un serviciu ușor de integrat și anex BigQuery, extensia BigQuery ML folosește SQL, astfel că prelucrarea datelor (calcularea unor noi proprietăți pe baza celor existente, înlăturarea datelor redundante etc.) a fost ușor de aplicat. De asemenea, inclusiv crearea modelului și evaluarea, respectiv antrenarea lui am realizat-o tot folosind unele comenzi asemănătoare celor SQL.
Google Cloud Dataflow este un serviciu eficient de prelucrare a datelor care funcționează perfect atât cu datele livrate în batch, cât și cu cele în flux continuu. Acesta permite utilizatorilor să proceseze și să analizeze volume mari de date în mod scalabil și eficient. Google Cloud Dataflow utilizează Apache Beam, permițând dezvoltatorilor să scrie cod pentru a defini transformările și analizele de date. Acest serviciu este ideal pentru sarcini precum procesarea streaming, analiza de date în timp real, ETL (Extract, Transform, Load). Cu Google Cloud Dataflow, gestionarea volumelor mari de date este mult mai facilă, tocmai din cauza integrării cu alte servicii GCP, cum ar fi BigQuery sau Storage, pentru a construi soluții de analiză de date avansate și pentru a extrage statistici.
Regresia logistică este o tehnică de analiză statistică și un algoritm de învățare automată folosit pentru a prezice probabilitatea unui eveniment de a se întâmpla, cum ar fi clasificarea unui obiect în una din două categorii.
Fig. 1. Enumerarea pașilor din procesul prezentat: în celulele albe am descris activitatea specifică pasului respectiv, iar în celula gri de sub fiecare pas este numele limbajului de programare (de exemplu, Scala) sau al serviciului de Google Cloud folosit (Dataflow, BigQuery ML sau Looker Studio)
În Figura 1 am descris vizual succesiunea pașilor pe care i-am parcurs pentru a realiza acest proiect. Întrucât nu am folosit un set de date furnizat de o bancă, am generat noi un set de date cu o structură asemănătoare cu cea a unei tranzacții bancare reale. Ulterior, am împărțit această mulțime în trei submulțimi disjuncte, pe care le-am folosit în cele trei etape diferite ale modelului de regresie logistică: antrenare, validare și, în final, testare. Folosind un dataflow job, am încărcat datele în BigQuery, unde le-am pregătit pentru a fi cât mai relevante pentru modelul de clasificare: am adăugat noi coloane pe baza celor deja generate, dar am eliminat și informațiile redundante. Am folosit un set de date folosind 300.000 tranzacții bancare, pe care le-am împărțit în 80% tranzacții pentru antrenarea modelului și 20% dintre date pentru validare. Am repetat experimentele cu diferite modele de regresie logistică, folosind diverși parametri până am obținut rezultatele mulțumitoare, după care am aplicat modelul selectat pe ultimul set de date, cel de test, la fel de mare cu setul de date folosit pentru antrenare și validare: 300.000 tranzacții.
Pentru acest studiu, am generat date sintetice folosindu-ne de un script intern conceput pentru a imita datele tranzacționale. Datele sintetice respectă o schema predefinită care seamănă mult cu înregistrările reale de tranzacții. Schema include următoarele câmpuri cheie:
transactional_id: Un număr întreg pozitiv care servește drept identificator unic pentru fiecare tranzacție.
timestamp: Marcaje de timp cu precizie la milisecunde, începând din septembrie.
customer_id: Numere întregi generate aleatoriu între 0 și 999 pentru a reprezenta identificatori unici ai clienților.
transaction: Un câmp imbricat care conține următoarele subcâmpuri:
city: O enumerare cu posibile valori: Cluj, Oradea și Timișoara, reprezentând locul tranzacției.
type: O altă enumerare cu posibile valori: achiziție, retragere sau transfer. Există o probabilitate de 1% de a obține o valoare nulă pentru acest câmp.
Un exemplu cu atributele și valorile asociate acestora în trei tranzacții din setul de antrenare este:
{
"customer id": 1112,
"timestamp": "2023-09-16T16:37:42.958Z",
"transaction": {
"amount": 65.9657471694887, "city": "Cluj",
"type": "transfer"
},
"transaction id": 130904
},
{
"customer id": 1232,
"timestamp": "2023-09-16T16:10:11.728Z",
"transaction": {
"amount": 76.3690012480496,
"city": "Timisoara",
"type": "transfer"
},
"transaction id": 6180953
},
{
"customer_id": 1245,
"timestamp": "2023-09-17T15:26:41.710Z",
"transaction": {
"amount": null,
"city": "Cluj",
"type": "withdrawal"
},
"transaction id": 9472075
}În total, a fost generat un set de date care conține 300.000 de tranzacții sintetice în format JSON. Aceste tranzacții servesc drept date de antrenare pentru modelul nostru de învățare automată, permițându-i să învețe modele indicative ale comportamentului suspect.
În plus, pentru a evalua performanța modelului, am generat un alt set de 30.000 de tranzacții sintetice care respectă aceeași schemă. Aceste tranzacții vor fi folosite pentru a evalua abilitatea modelului de a identifica corect tranzacțiile suspecte.
După ce am obținut datele sintetice, am stocat fișierele în Google Cloud Storage și am explorat alternativele prin care le putem introduce în Google BigQuery. Am optat pentru folosirea Google Dataflow datorită ușurinței de a-l utiliza: Dataflow furnizează șabloane predefinite, unul dintre acestea fiind destinat ingestiei datelor din Google Cloud Storage în BigQuery. În acest caz, am specificat calea de intrare a fișierelor, tabela țintă și schema acesteia, precum și un fișier JavaScript care conține o transformare aplicată datelor de intrare înainte de a le scrie în BigQuery.
Am prelucrat datele în trei pași, de-a lungul cărora am calculat noi proprietăți pe baza celor generate în setul de date sintetic. Folosindu-ne de data și ora unei tranzacții, dar și de ID-ul unui client, am etichetat o tranzacție drept frauduloasă în oricare din cele patru situații din tabelul următor:
| 1. | Același client a făcut două sau mai multe tranzacții în mai puțin de un minut. |
| 2. | Un client a avut asociate contului său minim două tranzacții invalide în decurs de 4 ore. |
| 3. | Un client a tranzacționat de mai mult de două ori aceeași sumă într-un interval de 4 ore. |
| 4. | Clientul a avut peste 10 tranzacții în 4 ore. |
Tabel 1. Situațiile în care am considerat o tranzacție ca fiind frauduloasă
În acest fel, am etichetat ca fiind frauduloase peste 13.000 din cele 300.000 de tranzacții. Ulterior, am eliminat proprietățile redundante din setul de date, precum ID-ul tranzacției, care nu ajută algoritmul de învățare automată să clasifice tranzacțiile.
Folosindu-ne de BigQuery ML, am creat un model căruia i-am furnizat 80% din cele 300.000 tranzacții, adică 240.000 tranzacții, ceea ce constituie setul de date de antrenament. Printre parametrii pe care i-am mai specificat la crearea modelului se numără: tipul modelului (în cazul nostru, regresie liniară), coloana ce conține etichetele ce vor reprezenta rezultatul predicției (în tabelul nostru, coloana suspicious) și modul de împărțire a datelor în mulțimile de antrenament și validare (noi am optat pentru o împărțire aleatorie). Am încercat câteva experimente și cu alți parametri, însă rezultatele au fost fie mult mai slabe, fie mult prea bune. Deși metricile prezentau rezultate mai bune în cazul unor alte modele, nu le-am ales deoarece modelul prezenta fenomenul denumit în scrierile din domeniu drept overfit, adică învăța mult prea bine datele de antrenament, dar risca să prezică mult mai slab în cazul unui set de date nou. AUTO_CLASS_WEIGHTS este un exemplu de parametru la care am renunțat. Inițial l-am inclus în experimente pentru a echilibra cantitatea de tranzacții frauduloase cu cele ce nu prezintă tentativa unei fraude, având în vedere că numai 13.000 tranzacții din cele 300.000 sunt frauduloase. Însă am renunțat să îl mai folosim când am văzut că are un impact negativ asupra metricilor luate în considerare (precizie, acuratețe).
OPTIONS(
model_type='logistic_reg',
input_label_cols=['suspicious'],
DATA_SPLIT_METHOD = 'RANDOM',
DATA_SPLIT_EVAL_FRACTION = 0.80
)Pe lângă crearea propriu-zisă a modelului (model ce se va regăsi stocat în BigQuery asemănător oricărei alte entități deja cunoscute - tabel, view etc.), BigQuery ML furnizează (la fel ca la finalul execuției oricărei comenzi), și o suită de statistici reprezentate grafic ce descriu detaliile execuției și graficul execuției. Detaliile execuției prezintă durata fiecărei iterații de antrenament, dar și evoluția funcțiilor loss, respectiv learning rate de-a lungul acestor iterații. Graficul execuției prezintă durata necesară fiecărui pas din comanda de creare a modelului: preprocesarea, antrenamentul, evaluarea.
Fig. 3. Detaliile execuției comenzii de creare a modelului de regresie liniară
Fig. 4. Graficul execuției comenzii de creare a modelului de regresie liniară
Evaluarea modelului este la fel de intuitivă și de simplu de realizat ca partea de antrenament, întrucât se face tot printr-o comandă de tip SQL. Rezultatele evaluării sunt prezentate tabelar, unde fiecare metrică este detaliată într-o coloană. În cazul nostru, rezultatele sunt unele foarte bune, atât pe setul de date de validare, cât și pe cel de test. Metricile pe care le-am luat noi în calcul pot fi observate în Figura 4.
Deoarece numărul de tranzacții nefrauduloase este mult mai mare decât cel al celor frauduloase (în toate seturile de date, și în cel de antrenament, și în cel de test), o acuratețe bună nu relevă neapărat și o precizie bună, întrucât clasificarea unui număr mare de tranzacții ca fiind nefrauduloase crește cu mult procentul de acuratețe. Tocmai de aceea, în evaluarea modelului, am acordat o deosebită importanță metricii de precizie și nu numai metricii de acuratețe. Precizia este esențială în contexte în care costurile pentru predicții incorecte sunt ridicate, cum ar fi în domeniul medical sau financiar. Precizia este importantă în evaluarea performanței unui algoritm de clasificare binară, arătând, în cazul nostru, procentul de tranzacții clasificate corect ca frauduloase din totalul de tranzacții clasificate ca frauduloase. În cazul setului de date de test, modelul prezintă o acuratețe de 94% și o precizie de 68.5%.
Pentru obținerea predicțiilor, modelul este ușor de folosit, fiind necesară doar selectarea datelor cu un query în care se folosește ca parametru al funcției ML.PREDICT, modelul deja creat anterior.
Fig. 5. Metricile evaluării modelului și rezultatele acestora pe setul de date de validare
Pentru vizualizarea rezultatelor, am ales să folosim tot un serviciu al platformei Google Cloud, Looker Studio. Looker Studio este o unealtă puternică de analiză și vizualizare de date care oferă suport pentru construirea rapidă a unor rapoarte, tablouri de bord interactive și vizualizări grafice ușor de înțeles. Pentru scenarii mai complexe, platforma oferă echipelor oportunitatea de a lucra împreună pe aceleași documente pentru a descoperi tendințe, a lua decizii mai informate și a obține avantajul competitiv din datele lor, contribuind astfel la transformarea digitală a afacerilor. În cazul de față, noi am folosit Looker Studio direct din BigQuery, cele două servicii fiind integrate perfect.
Fig. 6. În partea stângă, matricea de confuzie, iar în partea din dreapta, reprezentarea grafică (în procente) a matricii de confuzie (atât tabelul, cât și figura sunt create cu Looker Studio).
Figura 6 descrie performanța algoritmului pe setul de date de test. Tabelul din stânga prezintă clasificarea reală a tranzacțiilor (actual_suspicious) în comparație cu clasificarea făcută de model (predicted_suspicious). Ambele etichete pot lua două valori: true, în cazul în care tranzacția este clasificată ca fiind frauduloasă, respectiv false, în cazul în care aceasta nu este etichetată ca fraudă. Analizând partea din dreapta a Figurii 6, putem observa că modelul etichetează corect majoritatea tranzacțiilor (având în vedere cantitatea mare de albastru închis de pe primul rând și cantitatea mare de albastru deschis de pe al doilea rând), însă tinde să clasifice ca fiind frauduloase mai multe tranzacții decât în realitate. Cu o îmbunătățire ulterioară a modelului, vom putea prezenta un model cu rezultate mai bune, dar, momentan, acest lucru nu reprezintă o problemă foarte mare, întrucât preferăm să avem tranzacții etichetate ca fiind frauduloase deși ele nu sunt decât invers (ca modelul să eticheteze greșit ca fiind în regulă unele tranzacții frauduloase).
În concluzie, acest articol arată ușurința integrării a trei servicii disponibile pe platforma Google Cloud printr-un exemplu concret: clasificarea tranzacțiilor bancare. Pe lângă o foarte eficientă integrare, recomandăm DataFlow, BigQuery ML și Looker Studio din numeroase alte motive: numărul mare de șabloane din care utilizatorii pot alege, numărul mare de configurări pe care dezvoltatorii le pot aplica proceselor, datelor și figurilor astfel încât, indiferent de domeniul de aplicabilitate al proiectului, calitatea rezultatelor să nu fie afectată.
