Scoring delle frodi in tempo reale su larga scala

Lo scoring delle frodi su larga scala richiede un'architettura fondamentalmente diversa dall'elaborazione batch. Quando un pagamento viene autorizzato o un account viene creato, si hanno millisecondi — non minuti — per fornire un punteggio di rischio. In tracio.ai elaboriamo oltre 50.000 eventi al secondo con una latenza di scoring mediana di 22ms. Questo articolo spiega l'architettura che rende tutto ciò possibile.

La pipeline di scoring

Ogni evento in arrivo entra in una pipeline a tre fasi: arricchimento dei segnali, calcolo dei vettori e scoring del rischio. L'arricchimento dei segnali collega all'evento grezzo i dati di intelligence dei dispositivi — l'impronta del visitatore, i risultati del rilevamento dei bot, l'IP intelligence e il comportamento storico. Il calcolo dei vettori trasforma questi segnali arricchiti in un vettore di feature a lunghezza fissa, ottimizzato per il nostro modello di scoring. Lo scoring del rischio fa passare il vettore attraverso il nostro modello addestrato e restituisce un punteggio compreso tra 0.0 e 1.0.

La decisione di progettazione chiave è che l'arricchimento e il calcolo dei vettori sono separati dallo scoring. I dati di arricchimento sono pre-calcolati e messi in cache. Quando un visitatore carica una pagina, calcoliamo il suo profilo del dispositivo e lo memorizziamo in Redis con un TTL di 60 minuti. Quando arriva una richiesta di scoring — tipicamente attivata da un pagamento o da un login — recuperiamo il profilo pre-calcolato invece di ricalcolarlo. Questo riduce la latenza di scoring da oltre 200ms a meno di 30ms.

Stream processing con Go

Il nostro livello di ingestione è scritto in Go e usa un'architettura fan-out. Gli eventi in arrivo giungono via HTTP POST e vengono immediatamente collocati su un canale interno. Un pool di worker goroutine legge da questo canale, esegue l'arricchimento e scrive gli eventi arricchiti su ClickHouse per le analitiche e su una coda di scoring per l'elaborazione in tempo reale. Il pool di fan-out si scala dinamicamente in base alla profondità della coda.

Abbiamo scelto Go per il livello di ingestione per le sue eccellenti primitive di concorrenza e l'allocazione della memoria prevedibile. Ogni worker goroutine consuma circa 4KB di spazio di stack, permettendoci di eseguire migliaia di worker concorrenti su un singolo nodo. Le pause inferiori al millisecondo del garbage collector sono cruciali per mantenere una latenza costante a throughput elevato.

Edge caching e vettori di segnale

Per i nostri clienti con i volumi più elevati, distribuiamo i modelli di scoring all'edge usando una cache di vettori di segnale pre-calcolati. Quando un dispositivo viene visto per la prima volta, calcoliamo il suo vettore di segnale completo e lo memorizziamo nella nostra cache edge (distribuita su Cloudflare Workers KV). Le successive richieste di scoring per lo stesso dispositivo recuperano il vettore in cache ed eseguono lo scoring localmente all'edge, raggiungendo una latenza sotto i 10ms.

Il modello di scoring all'edge è una versione distillata del nostro modello completo — più piccolo e veloce, ma ottimizzato per gli stessi obiettivi di precisione. Ri-addestriamo il modello edge settimanalmente e distribuiamo gli aggiornamenti tramite rolling deployment per evitare tempeste di invalidazione della cache. Il modello completo viene eseguito lato server per i casi in cui la confidenza del modello edge è sotto una soglia configurabile.

ClickHouse per le analitiche

Tutti gli eventi arricchiti vengono memorizzati in ClickHouse, il nostro database analitico colonnare. La compressione e le prestazioni di query di ClickHouse ci permettono di memorizzare miliardi di eventi supportando al contempo query analitiche in tempo reale. I nostri clienti usano queste analitiche per comprendere gli schemi di frode, calibrare le soglie di scoring e investigare i singoli eventi.

Usiamo viste materializzate in ClickHouse per mantenere metriche pre-aggregate: tasso di frode per Paese, distribuzione dello scoring per tipo di dispositivo e tassi di falsi positivi per soglia. Queste viste materializzate si aggiornano in tempo reale man mano che gli eventi arrivano, fornendo metriche pronte per la dashboard senza costose query di aggregazione.

Lezioni apprese

Costruire un sistema di scoring in tempo reale ci ha insegnato diverse lezioni. Primo, il pre-calcolo è l'ottimizzazione più importante — qualsiasi lavoro che si può svolgere prima dell'arrivo della richiesta di scoring è lavoro che non pesa sul budget di latenza. Secondo, il modello di concorrenza di Go è ben adatto all'elaborazione di eventi ad alto throughput, ma bisogna essere disciplinati nell'allocazione della memoria per evitare pressione sul GC. Terzo, il deployment all'edge è trasformativo per la latenza ma richiede una gestione attenta del modello per evitare previsioni obsolete.