🥇Creazione di un sistema automatico per contrastare i malintenzionati sul sito (frode)

Negli ultimi sei mesi circa, mi sono occupato della creazione di un sistema di lotta contro le frodi (fraudulent activity, fraud, ecc.) senza alcuna infrastruttura iniziale per farlo. Le idee che abbiamo trovato e implementato nel nostro sistema ci aiutano a rilevare numerosi comportamenti fraudolenti e ad analizzarli. In questo articolo, vorrei parlare dei principi che abbiamo seguito e di ciò che abbiamo fatto per raggiungere l'attuale stato del nostro sistema, senza approfondire la parte tecnica.

Principi del nostro sistema

Quando senti termini come «automatico» e «frodi», probabilmente inizi a pensare all'apprendimento automatico, Apache Spark, Hadoop, Python, Airflow e ad altre tecnologie dell'ecosistema Apache Foundation e del campo della Data Science. Credo che ci sia un aspetto dell'utilizzo di questi strumenti che, di solito, non viene menzionato: richiedono determinate condizioni preliminari nel tuo sistema aziendale prima di poterli utilizzare. In breve, hai bisogno di una piattaforma di dati aziendale che includa un lago di dati e uno storage. Ma cosa succede se non hai una piattaforma del genere e hai comunque bisogno di sviluppare questa pratica? I seguenti principi di cui parlo di seguito ci hanno aiutato a raggiungere un momento in cui possiamo concentrarci sul miglioramento delle nostre idee, piuttosto che sulla ricerca di soluzioni funzionanti. Tuttavia, questo non è un «piatto» del progetto. Ci sono ancora molte cose da considerare dal punto di vista tecnologico e di prodotto.

Principio 1: valore per il business prima di tutto

All'apice di tutti i nostri sforzi abbiamo posto il «valore per il business». In generale, qualsiasi sistema di analisi automatica appartiene a un gruppo di sistemi complessi con elevati livelli di automazione e complessità tecnica. Creare una soluzione completa richiederà molto tempo se la costruisci da zero. Abbiamo deciso di dare priorità al valore per il business e in secondo luogo alla completezza tecnologica. Nella vita reale, questo significa che non adottiamo le tecnologie avanzate come se fossero una dogma. Scegliamo la tecnologia che funziona meglio per noi in questo momento. Con il tempo, potrebbe sembrare che dobbiamo reimplementare alcuni moduli. Questo è il compromesso che abbiamo accettato.

Principio 2: Intelligenza umana avanzata (augmented intelligence)

Scommetto che la maggior parte delle persone che non sono profondamente coinvolte nello sviluppo di soluzioni di machine learning potrebbero pensare che la sostituzione degli esseri umani sia l'obiettivo. In realtà, le soluzioni di machine learning sono lontane dalla perfezione e la sostituzione è possibile solo in ambiti specifici. Abbiamo scartato questa idea fin dall'inizio per diversi motivi: dati sbilanciati sulle attività fraudolente e l'impossibilità di fornire un elenco completo delle caratteristiche per i modelli di machine learning. Al contrario, abbiamo scelto un'opzione con intelligenza estesa. Questa è un concetto alternativo di intelligenza artificiale che si concentra sul ruolo di supporto dell'IA, sottolineando il fatto che le tecnologie cognitive sono progettate per migliorare l'intelligenza umana anziché sostituirla. [1]

Tenendo conto di ciò, lo sviluppo di una soluzione completa di machine learning fin dall'inizio richiederebbe un enorme sforzo, ritardando la creazione di valore per il nostro business. Abbiamo deciso di costruire un sistema con un aspetto di machine learning in crescita iterativa sotto la guida dei nostri esperti del settore. La parte complessa dello sviluppo di un tale sistema è che deve fornire ai nostri analisti casi non solo dal punto di vista di se sia attività fraudolenta o meno. In generale, qualsiasi anomalia nel comportamento dei clienti è un caso sospetto che gli specialisti devono indagare e a cui devono rispondere in qualche modo. Solo una parte di questi casi registrati può effettivamente essere classificata come frode.

Principio 3: piattaforma di analisi dati vaste

La parte più complessa del nostro sistema è il monitoraggio continuo del flusso di lavoro. Gli analisti e gli sviluppatori devono poter accedere facilmente a set di dati dei periodi passati con tutte le metriche utilizzate per l'analisi. Inoltre, la piattaforma dati deve fornire un modo semplice per integrare nuovi indicatori a quelli esistenti. I processi che creiamo, non solo quelli software, devono consentire di ricalcolare facilmente i periodi precedenti, aggiungere nuove metriche e modificare le previsioni dei dati. Potremmo ottenere questo accumulando tutti i dati generati dal nostro sistema produttivo. In tal caso, i dati diverrebbero gradualmente un ostacolo. Dovremmo conservare un volume crescente di dati che non utilizziamo e proteggerli. In uno scenario del genere, col passare del tempo i dati diventerebbero sempre più irrilevanti, ma richiederebbero comunque i nostri sforzi per gestirli. Per noi, l'accumulo di dati (data hoarding) non aveva senso, così abbiamo deciso di adottare un approccio diverso. Abbiamo scelto di organizzare i magazzini di dati in tempo reale attorno a entità obiettivo che desideriamo classificare e di conservare solo i dati che ci permettono di verificare i periodi più recenti e pertinenti. La complessità di questi sforzi risiede nel fatto che il nostro sistema è eterogeneo, con più magazzini di dati e moduli software che richiedono una pianificazione accurata per un funzionamento coerente.

Concetti costruttivi del nostro sistema

Abbiamo quattro componenti principali nel nostro sistema: il sistema di acquisizione (ingestion system), il sistema computazionale (computational), l'analisi (BI analysis) e il sistema di monitoraggio (tracking system). Questi servono a obiettivi isolati specifici, e li manteniamo separati seguendo approcci determinati nello sviluppo.

Design basato sui contratti

Prima di tutto, abbiamo convenuto che i componenti devono basarsi solo su strutture dati specifiche (contratti) che vengono scambiate tra loro. Questo consente una facile integrazione e non impone una composizione (e ordine) specifica dei componenti. Ad esempio, in alcuni casi, questo ci consente di integrare direttamente il sistema di ricezione con il sistema di monitoraggio degli avvisi. In tale caso, sarà fatto in conformità con il contratto concordato sugli avvisi. Ciò significa che entrambi i componenti saranno integrati utilizzando un contratto che può essere utilizzato da qualsiasi altro componente. Non aggiungeremo un contratto aggiuntivo per l'aggiunta di avvisi nel sistema di monitoraggio dal sistema di input. Questo approccio richiede l'uso di un numero minimo predefinito di contratti e semplifica il sistema e le comunicazioni. In sostanza, utilizziamo un approccio chiamato "Contract First Design" e lo applichiamo ai contratti di streaming dei dati. [2]

Streaming ovunque

Il salvataggio e la gestione dello stato in un sistema porteranno inevitabilmente a complicazioni nella sua implementazione. In linea generale, lo stato deve essere accessibile da qualsiasi componente, deve essere coerente e fornire il valore più attuale per tutti i componenti, e deve essere affidabile con valori corretti. Inoltre, le chiamate a uno storage persistente per ottenere l'ultimo stato aumenteranno il numero di operazioni di input/output e la complessità degli algoritmi utilizzati nei nostri pipeline in tempo reale. Per questo motivo, abbiamo deciso di eliminare completamente la memorizzazione dello stato dal nostro sistema, se possibile. Questo approccio richiede l'inclusione di tutti i dati necessari nel blocco di dati trasmesso (messaggio). Ad esempio, se dobbiamo calcolare il numero totale di alcune osservazioni (numero di operazioni o casi con caratteristiche specifiche), lo calcoliamo in memoria e generiamo un flusso di tali valori. I moduli dipendenti utilizzeranno il partizionamento e il batching per suddividere il flusso in entità e operare sugli ultimi valori. Questo approccio ha eliminato la necessità di avere uno storage persistente su disco per tali dati. Il nostro sistema utilizza Kafka come broker di messaggi e può essere utilizzato come database con KSQL. [3] Tuttavia, il suo utilizzo legerebbe fortemente la nostra soluzione a Kafka, e abbiamo deciso di non utilizzarlo. L'approccio che abbiamo scelto consente di sostituire Kafka con un altro broker di messaggi senza apportare cambiamenti interni significativi al sistema.

Questo concetto non significa che non utilizziamo storage su disco e database. Per testare e analizzare le performance del sistema, è necessario memorizzare su disco una parte significativa dei dati che rappresentano vari indicatori e stati. Un punto importante qui è che gli algoritmi in tempo reale non dipendono da tali dati. Nella maggior parte dei casi, utilizziamo i dati memorizzati per analisi autonome, debugging e monitoraggio di casi e risultati specifici forniti dal sistema.

Problemi del nostro sistema

Ci sono problemi specifici che abbiamo risolto fino a un certo livello, ma richiedono soluzioni più ponderate. Ora vorrei solo citarli qui, perché ogni punto meriterebbe un articolo a parte.

Abbiamo ancora bisogno di definire processi e politiche che favoriscano l'accumulo di dati significativi e attuali per la nostra analisi automatica, rilevamento e studio dei dati.
L'integrazione dei risultati dell'analisi umana nel processo di configurazione automatica del sistema per il suo aggiornamento con i dati più recenti. Non si tratta solo di aggiornare il nostro modello, ma anche di rinnovare i processi e migliorare la comprensione dei nostri dati.
Trovare un equilibrio tra un approccio deterministico IF-ELSE e il ML. Qualcuno ha detto: «Il ML è uno strumento per chi è senza speranza». Ciò significa che si desidera utilizzare il ML quando non si comprende più come ottimizzare e migliorare i propri algoritmi. D'altra parte, l'approccio deterministico non permette di rilevare anomalie che non sono state previste.
Abbiamo bisogno di un modo semplice per verificare le nostre ipotesi o correlazioni tra le metriche nei dati.
Il sistema deve avere vari livelli di risultati veri positivi. I casi di frode sono solo una parte di tutti i casi che possono essere considerati positivi per il sistema. Ad esempio, gli analisti vogliono ricevere tutti i casi sospetti per la verifica, e solo una piccola parte di essi è frode. Il sistema deve fornire efficacemente agli analisti tutti i casi, indipendentemente dal fatto che si tratti di frodi reali o solo di comportamenti sospetti.
La piattaforma dati deve consentire di ottenere set di dati per periodi passati con calcoli generati e calcolati al volo.
Distribuzione semplice e automatica di qualsiasi componente del sistema in almeno tre ambienti diversi: produzione, sperimentale (beta) e per sviluppatori.
E infine, ma non meno importante. Dobbiamo creare una piattaforma completa di verifica delle prestazioni, sulla quale possiamo analizzare i nostri modelli. [4]