Negli ultimi sei mesi ho creato un sistema per combattere le frodi (attività fraudolente, frodi, ecc.) senza alcuna infrastruttura iniziale per questo. Le idee di oggi che abbiamo trovato e implementato nel nostro sistema ci aiutano a rilevare e analizzare molte attività fraudolente. In questo articolo vorrei parlare dei principi che abbiamo seguito e di cosa abbiamo fatto per raggiungere lo stato attuale del nostro sistema, senza entrare nella parte tecnica.
Principi del nostro sistema
Quando senti termini come "automatico" e "frode", molto probabilmente inizi a pensare al machine learning, Apache Spark, Hadoop, Python, Airflow e altre tecnologie dell'ecosistema Apache Foundation e del campo della scienza dei dati. Penso che ci sia un aspetto dell'utilizzo di questi strumenti che di solito non viene menzionato: richiedono determinati prerequisiti nel sistema aziendale prima di poter iniziare a utilizzarli. In breve, è necessaria una piattaforma dati aziendale che includa un data Lake e un warehouse. Ma cosa succede se non disponi di una piattaforma del genere e devi ancora sviluppare questa pratica? I seguenti principi che condivido di seguito ci hanno aiutato a raggiungere un punto in cui possiamo concentrarci sul miglioramento delle nostre idee piuttosto che trovarne una che funzioni. Tuttavia, questo non è un plateau del progetto. Ci sono ancora tante cose in programma dal punto di vista tecnologico e di prodotto.
Principio 1: il valore aziendale innanzitutto
Mettiamo il “valore aziendale” al centro di tutti i nostri sforzi. In generale, qualsiasi sistema di analisi automatica appartiene al gruppo di sistemi complessi con un elevato livello di automazione e complessità tecnica. La creazione di una soluzione completa richiederà molto tempo se la crei da zero. Abbiamo deciso di mettere al primo posto il valore aziendale e al secondo posto la completezza tecnologica. Nella vita reale, ciò significa che non accettiamo la tecnologia avanzata come dogma. Scegliamo la tecnologia che funziona meglio per noi in questo momento. Con il passare del tempo, potrebbe sembrare che dovremo reimplementare alcuni moduli. Questo è il compromesso che abbiamo accettato.
Principio 2: Intelligenza aumentata
Scommetto che la maggior parte delle persone che non sono profondamente coinvolte nello sviluppo di soluzioni di machine learning potrebbero pensare che l’obiettivo sia sostituire gli esseri umani. In effetti, le soluzioni di machine learning sono tutt’altro che perfette e solo in alcune aree è possibile sostituirle. Abbiamo rifiutato questa idea fin dall'inizio per diversi motivi: dati sbilanciati sulle attività fraudolente e l'incapacità di fornire un elenco completo di funzionalità per i modelli di machine learning. Noi invece abbiamo scelto l’opzione di intelligenza avanzata. Si tratta di un concetto alternativo di intelligenza artificiale che si concentra sul ruolo di supporto dell’intelligenza artificiale, sottolineando il fatto che le tecnologie cognitive sono destinate a migliorare l’intelligenza umana piuttosto che a sostituirla. [1]
Detto questo, sviluppare fin dall’inizio una soluzione completa di machine learning richiederebbe uno sforzo enorme, che ritarderebbe 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 di dominio. La parte difficile dello sviluppo di un sistema del genere è che deve fornire ai nostri analisti casi non solo in termini di attività fraudolenta o meno. In generale, qualsiasi anomalia nel comportamento del cliente è un caso sospetto su cui gli specialisti devono indagare e rispondere in qualche modo. Solo una frazione di questi casi segnalati può essere realmente classificata come frode.
Principio 3: piattaforma di analisi avanzata
La parte più impegnativa del nostro sistema è la verifica end-to-end del flusso di lavoro del sistema. Analisti e sviluppatori dovrebbero ottenere facilmente set di dati storici con tutte le metriche utilizzate per l'analisi. Inoltre, la piattaforma dati dovrebbe fornire un modo semplice per integrare una serie di parametri esistente con quelli nuovi. I processi che creiamo, e questi non sono solo processi software, dovrebbero consentirci di ricalcolare facilmente i periodi precedenti, aggiungere nuove metriche e modificare la previsione dei dati. Potremmo raggiungere questo obiettivo accumulando tutti i dati generati dal nostro sistema di produzione. In questo caso, i dati diventerebbero gradualmente una seccatura. Avremmo bisogno di archiviare una quantità crescente di dati che non utilizziamo e di proteggerli. In uno scenario del genere, i dati diventeranno sempre più irrilevanti nel tempo, ma richiederanno comunque i nostri sforzi per gestirli. Per noi l'accumulo di dati non aveva senso, quindi abbiamo deciso di adottare un approccio diverso. Abbiamo deciso di organizzare archivi di dati in tempo reale attorno alle entità target che vogliamo classificare e archiviare solo i dati che ci consentono di controllare i periodi più recenti e rilevanti. La sfida a questo sforzo è che il nostro sistema è eterogeneo, con molteplici archivi dati e moduli software che richiedono un’attenta pianificazione per funzionare in modo coerente.
Concetti di progettazione del nostro sistema
Abbiamo quattro componenti principali nel nostro sistema: sistema di acquisizione, calcolo, analisi BI e sistema di tracciamento. Servono a scopi specifici e isolati e noi li manteniamo isolati seguendo approcci progettuali specifici.
Progettazione basata sul contratto
Innanzitutto abbiamo concordato che i componenti debbano basarsi solo su determinate strutture dati (contratti) che vengono scambiati tra loro. Ciò facilita l'integrazione tra loro e non impone una composizione (e un ordine) specifica dei componenti. Ad esempio, in alcuni casi questo ci permette di integrare direttamente il sistema di assunzione con il sistema di tracciamento degli alert. In tal caso, ciò avverrà in conformità al contratto di allerta concordato. Ciò significa che entrambi i componenti verranno integrati mediante un contratto utilizzabile da qualsiasi altro componente. Non aggiungeremo un contratto aggiuntivo per aggiungere avvisi al sistema di tracciamento dal sistema di input. Questo approccio richiede l'utilizzo di un numero minimo predeterminato di contratti e semplifica il sistema e le comunicazioni. Essenzialmente, adottiamo un approccio chiamato "Contract First Design" e lo applichiamo ai contratti di streaming. [2]
In streaming ovunque
Salvare e gestire lo stato in un sistema porterà inevitabilmente a complicazioni nella sua implementazione. In generale, lo stato dovrebbe essere accessibile da qualsiasi componente, dovrebbe essere coerente e fornire il valore più aggiornato su tutti i componenti e dovrebbe essere affidabile con i valori corretti. Inoltre, le chiamate all'archiviazione persistente per recuperare lo stato più recente aumenteranno il numero di operazioni di I/O e la complessità degli algoritmi utilizzati nelle nostre pipeline in tempo reale. Per questo motivo, abbiamo deciso di rimuovere completamente l'archiviazione dello stato dal nostro sistema, se possibile. Questo approccio richiede che tutti i dati necessari siano inclusi nel blocco dati trasmesso (messaggio). Ad esempio, se dobbiamo calcolare il numero totale di alcune osservazioni (il numero di operazioni o casi con determinate caratteristiche), lo calcoliamo in memoria e generiamo un flusso di tali valori. I moduli dipendenti utilizzeranno la partizione e l'invio in batch per dividere il flusso in entità e operare sui valori più recenti. Questo approccio ha eliminato la necessità di disporre di spazio di archiviazione su disco permanente per tali dati. Il nostro sistema utilizza Kafka come broker di messaggi e può essere utilizzato come database con KSQL. [3] Ma utilizzarlo avrebbe legato fortemente la nostra soluzione a Kafka, e abbiamo deciso di non utilizzarlo. L'approccio che abbiamo scelto ci consente di sostituire Kafka con un altro broker di messaggi senza grandi modifiche interne al sistema.
Questo concetto non significa che non utilizziamo storage su disco e database. Per testare e analizzare le prestazioni del sistema, dobbiamo archiviare su disco una quantità significativa di dati che rappresentano vari parametri e stati. Il punto importante qui è che gli algoritmi in tempo reale non dipendono da tali dati. Nella maggior parte dei casi, utilizziamo i dati archiviati per l'analisi offline, il debug e il monitoraggio di casi e risultati specifici prodotti dal sistema.
Problemi del nostro sistema
Ci sono alcuni problemi che abbiamo risolto fino a un certo livello, ma richiedono soluzioni più ponderate. Ora vorrei solo citarli qui perché ogni punto vale un articolo a sé.
- Dobbiamo ancora definire processi e policy che supportino l’accumulo di dati significativi e rilevanti per la nostra analisi, scoperta ed esplorazione automatizzata dei dati.
- L'integrazione dei risultati dell'analisi umana nel processo di impostazione automatica del sistema per aggiornarlo con i dati più recenti. Questo non significa solo aggiornare il nostro modello, ma anche aggiornare i nostri processi e migliorare la nostra comprensione dei nostri dati.
- Trovare un equilibrio tra l'approccio deterministico di IF-ELSE e ML. Qualcuno ha detto: “Il machine learning è uno strumento per i disperati”. Ciò significa che vorrai utilizzare il machine learning quando non capirai più come ottimizzare e migliorare i tuoi algoritmi. D’altro canto, l’approccio deterministico non consente di individuare anomalie non previste.
- Abbiamo bisogno di un modo semplice per testare le nostre ipotesi o correlazioni tra i parametri nei dati.
- Il sistema deve avere diversi livelli di veri risultati positivi. I casi di frode rappresentano solo una frazione 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 sono frodi. Il sistema deve presentare in modo efficiente tutti i casi agli analisti, indipendentemente dal fatto che si tratti di frode effettiva o semplicemente di comportamento sospetto.
- La piattaforma dati dovrebbe essere in grado di recuperare set di dati storici con calcoli generati e calcolati al volo.
- Distribuisci facilmente e automaticamente qualsiasi componente del sistema in almeno tre ambienti diversi: produzione, sperimentale (beta) e per sviluppatori.
- Ultimo ma non meno importante. Dobbiamo costruire una ricca piattaforma di test delle prestazioni su cui possiamo analizzare i nostri modelli. [4]
riferimenti
Fonte: habr.com