Rilevamento delle frodi in tempo reale con Feature Views

Il rilevamento delle frodi in tempo reale dipende da tre tipi di feature: cosa ha fatto un cliente secondi fa, come spende abitualmente e il confronto con il pagamento corrente. Tali feature devono essere calcolate nello stesso modo sia per l'addestramento del modello che per il live scoring; in caso contrario, il data leakage e il training-serving skew riducono silenziosamente la qualità del modello. I Feature View, parte di Databricks Feature Store, risolvono questo problema. Definisci ciascuna feature una sola volta e tale definizione produce sia dati di addestramento point-in-time sia le pipeline gestite per l'inferenza online.

Un pagamento di 900 $ può essere un'operazione di routine per un cliente e insolita per un altro. Quando arriva, un modello di frode ha a disposizione solo un istante per decidere se sembra normale, richiede una revisione o debba essere bloccato. Approvare una transazione fraudolenta può costare denaro al cliente. Bloccarne una legittima interrompe la sua esperienza di pagamento e compromette la sua fiducia nella piattaforma.

La sola transazione non racconta l'intera storia. Il modello deve anche sapere come questo cliente effettua transazioni abitualmente e cosa ha fatto secondi, minuti, giorni o settimane fa. Durante l'addestramento, le feature devono utilizzare esclusivamente le informazioni disponibili al momento in cui si è verificato ciascun pagamento. Durante il live scoring, devono riflettere le transazioni recenti abbastanza rapidamente da intercettare attività sospette. Se i due percorsi implementano la logica separatamente, si insinuano piccole differenze tra di essi.

Questa procedura dettagliata segue quel pagamento di 900 $ da uno stream Kafka a uno score di frode servito da Model Serving, con codice ad ogni passaggio. L'idea centrale è che una singola definizione di feature, che guida sia l'addestramento che il serving, fornisca dati di addestramento corretti point-in-time e feature online coerenti. Non è necessario creare una pipeline separata per ciascun percorso.

Cos'è un Feature View?

Un Feature View è una definizione di Databricks Feature Store che specifica la sorgente di una feature, le chiavi entità, le semantiche temporali e la trasformazione. La stessa definizione calcola i valori storici per l'addestramento e guida le pipeline gestite che mantengono le feature aggiornate per il serving. Una singola API copre feature batch, in streaming e on-demand. Unity Catalog gestisce le relative definizioni, autorizzazioni e lineage.

Due modalità di errore motivano questa progettazione:

• Training-serving skew si verifica quando una feature viene calcolata in un modo durante l'addestramento e in un altro in produzione. Al momento dell'inferenza, il modello vede quindi input che non corrispondono a ciò su cui è stato addestrato.
• Data leakage si verifica quando i dati di addestramento includono informazioni che non erano disponibili al momento della previsione. Feature corrette point-in-time lo prevengono utilizzando solo gli eventi accaduti prima del momento oggetto di previsione.

I Feature View integrano il calcolo delle feature in streaming nello stesso flusso di lavoro di data science dell'addestramento storico e del live scoring. È possibile valutare le feature rispetto a transazioni passate, quindi utilizzare le stesse definizioni per mantenere aggiornato il contesto del cliente per decisioni in tempo reale.

Di quali feature ha bisogno un modello di frode in tempo reale?

L'obiettivo è segnalare i pagamenti sospetti man mano che arrivano, senza generare falsi allarmi su quelli legittimi. Da solo, il pagamento di 900 $ può sembrare innocuo. Ma se si tratta del decimo pagamento in cinque minuti, potrebbe far parte di un'attività sospetta. Qualsiasi ritardo nel riconoscere tale attività offre a chi ha accesso a un account compromesso più tempo per effettuare ulteriori pagamenti.

Un'applicazione di rilevamento delle frodi creata con Databricks Apps elabora uno stream di transazioni finanziarie. Ogni evento include un ID cliente, un importo, il tipo di pagamento, il timestamp e i paesi di origine e destinazione. L'applicazione invia ogni transazione a un endpoint di Model Serving. Mostra quindi lo score di rischio della transazione insieme al volume delle transazioni in tempo reale, alle transazioni segnalate e ai flussi da paese a paese.
 

Il modello combina tre tipi di contesto:

• Attività recente: un conteggio delle transazioni a cinque minuti e un importo totale a 10 minuti, calcolati con RollingWindow, catturano la frequenza con cui il cliente effettua pagamenti e la quantità di denaro spesa.
• Baseline di spesa: una media a 30 giorni e una deviazione standard, gestite con SawtoothWindow, descrivono l'importo tipico dei pagamenti del cliente e la misura in cui questo varia.
• Dettagli della transazione: l'importo del pagamento corrente, il tipo di pagamento e i paesi di origine e destinazione forniscono il contesto per la decisione.

L'architettura presenta un percorso storico per l'addestramento e un percorso online per l'inferenza. Entrambi partono dalle stesse definizioni di feature in Unity Catalog. Il percorso storico legge la tabella di ingestione dello Stream per creare set di addestramento point-in-time. Il percorso online materializza gli aggregati nell'Online Feature Store, da cui Model Serving li legge al momento della richiesta.

Come definire feature in streaming da Kafka

Prima di decidere quali feature servire, è possibile testare le alternative rispetto alle transazioni storiche. Un conteggio delle transazioni a cinque minuti fornisce un segnale più forte rispetto a un conteggio a 15 minuti? Il confronto tra l'importo corrente e la variabilità della spesa del cliente aiuta più del semplice utilizzo della sua media?

In questo esempio, gli eventi di transazione dei clienti arrivano come stream Kafka. Uno Stream registrato mantiene la connessione, lo schema e le impostazioni di ingestione, e un StreamSource vi fa riferimento per calcolare le feature in tempo reale. I topic Kafka non conservano una cronologia sufficiente per l'addestramento del modello. Databricks gestisce pertanto una copia offline dello stream in una tabella di ingestione. Per l'addestramento o il backfill di un online store, Databricks calcola i valori storici dalla tabella di ingestione e utilizza il feed Kafka live per i dati più recenti.

Al momento dell'ingestione, transformation_sql rimodella i campi annidati dal payload di valore Kafka nello schema richiesto dalle feature. La proiezione diventa parte della definizione della sorgente, quindi non è necessario distribuire una pipeline di pre-elaborazione separata. Per il nostro pagamento, il payload di valore Kafka contiene:

La demo utilizza demo_user_id insieme a customer_id per mantenere separate le cronologie dei clienti dei diversi utenti dell'app.

Definiamo il conteggio a cinque minuti con RollingWindow. Il notebook di accompagnamento include importazioni, configurazione e la proiezione della sorgente completa.

È possibile ispezionare i suoi valori storici in un notebook con compute_features(features=[recent_transaction_count]). Il totale a 10 minuti utilizza la stessa sorgente e le stesse chiavi, con Sum su una RollingWindow di 10 minuti.

Una finestra Sawtooth è un'aggregazione con lookback esteso il cui confine più remoto avanza in passaggi giornalieri. Combina la cronologia calcolata in batch con gli aggiornamenti in streaming per l'attività recente. Per il nostro pagamento di 900 $, SawtoothWindow aggiunge una baseline di spesa a 30 giorni alle finestre mobili brevi. Entrambi i tipi di finestra mantengono fresca l'attività recente. Poiché il confine più remoto della finestra Sawtooth si sposta giornalmente anziché continuamente, il suo lookback effettivo è leggermente superiore a 30 giorni. La baseline utilizza le aggregazioni integrate Avg, StddevPop e Count sugli importi dei pagamenti nell'arco della stessa finestra Sawtooth.

Databricks avvia una pipeline di ingestione gestita quando viene creato uno Stream e conserva gli eventi in arrivo nella sua tabella di ingestione. Se sono necessari anche eventi precedenti alla creazione dello Stream, StreamBackfillSource consente di fornire la propria cronologia durante la configurazione dello Stream. Una volta che la tabella copre l'intero lookback, una nuova feature Sawtooth può utilizzarla immediatamente anziché attendere 30 giorni affinché gli eventi si accumulino.

Come confrontare un pagamento in tempo reale con la baseline di un cliente

Una feature on-demand viene calcolata al momento della richiesta combinando i valori della richiesta di scoring con le feature memorizzate. Il confronto tra una transazione in tempo reale e la baseline storica di un cliente è un modo comune per individuare comportamenti anomali. Nei Feature Views, le informazioni di inferenza sono rappresentate con un RequestSource — qui, transaction_amount dalla richiesta dell'applicazione.

Due clienti possono avere entrambi una media di 300 $ per pagamento ma spendere in modo molto diverso. Con deviazioni standard di 100 $ e 600 $, lo stesso pagamento di 900 $ si trova a sei deviazioni standard sopra la media di un cliente e a una sola sopra quella dell'altro. Il modello combina questo confronto con l'attività recente e i dettagli del pagamento per stimare il rischio di frode.

Le aggregazioni Sawtooth mantengono la media a 30 giorni e la deviazione standard. La feature on-demand le combina con l'importo corrente per calcolare (current_amount - average) / standard_deviation. Implementiamo questo calcolo come una Python UDF registrata in Unity Catalog:

La definizione della feature utilizza oggetti Feature upstream registrati. FeatureViewSource unisce l'importo corrente e le tre statistiche a 30 giorni, e CustomUDF richiama la funzione:

Quando non c'è abbastanza cronologia utilizzabile, la funzione restituisce zero come fallback. Un indicatore separato consente al modello di distinguere quel fallback da uno zero reale, il che significa che il pagamento corrisponde alla media del cliente. La stessa feature derivata viene valutata rispetto agli input storici durante il training e rispetto alla richiesta corrente più le statistiche recuperate durante l'inferenza.

Come testare i candidati delle feature prima di distribuirli

Durante lo sviluppo delle feature, puoi ispezionare le definizioni delle feature in un notebook con compute_features(). Questo funziona per le feature derivate i cui input provengono interamente da dati di origine storici. Per i confronti dipendenti dalla richiesta come amount_deviation, usa invece create_training_set(), che fornisce i campi di pagamento correnti da esempi etichettati. La funzione Unity Catalog deve esistere, ma le definizioni delle feature possono rimanere non registrate mentre testi i candidati.

Questo ti consente di verificare se una feature migliora le prestazioni offline del modello di frode prima di distribuirlo per lo scoring in tempo reale. Ad esempio, puoi confrontare i modelli con e senza amount_deviation su pagamenti successivi trattenuti (hold-out). Questi esperimenti vengono eseguiti su compute batch sulla cronologia delle transazioni, in modo da poter valutare ciascun candidato senza configurare la materializzazione online. Una volta selezionate le feature, registra le loro definizioni e materializza le aggregazioni mobili e Sawtooth per il serving.

Come creare dati di training corretti nel punto nel tempo (point-in-time correct)

Ciascun esempio di training storico richiede feature calcolate alla marca temporale di quel pagamento. Per il nostro pagamento di 900 $ alle 10:00, il conteggio di cinque minuti dovrebbe includere le transazioni dalle 9:55 fino alle 10:00 esclusa. Un conteggio recuperato alle 10:03 potrebbe includere un pagamento effettuato alle 10:02, che non era disponibile quando è stato valutato il pagamento originale. Questo è data leakage: il modello impara dall'attività futura e le sue prestazioni offline sembrano migliori di quanto non siano in realtà. I Feature Views utilizzano le chiavi cliente e la marca temporale di ciascun esempio per calcolare la finestra storica corretta dagli eventi nella tabella di inserimento dello Stream.

Dopo aver registrato le feature selezionate, create_training_set() crea i dati di training del modello. Il DataFrame etichettato fornisce le chiavi cliente, l'ora dell'evento, i campi del pagamento corrente e is_fraud. Questo estratto seleziona le feature registrate della procedura guidata, inclusa la baseline a 30 giorni, e utilizza le righe precedenti a un limite scelto per il training:

Chiavi e marche temporali selezionano la cronologia del cliente ma vengono escluse come input del modello. I campi di richiesta alimentano i calcoli delle feature; il classificatore utilizza le feature denominate risultanti. Le righe successive formano un set di validazione utilizzando le stesse definizioni.

Addestriamo un classificatore random-forest e valuto la precisione media e la ROC AUC su quest'ultimo. Registriamo quindi il modello tramite il client di Feature Engineering. Il passaggio di training_set=train_set registra le dipendenze delle feature di cui il serving avrà bisogno:

Come servire feature in tempo reale per l'inferenza online

Il trasferimento delle feature selezionate sopra nello scoring in tempo reale richiede pipeline per mantenere aggregati di streaming, elaborare dati storici e mantenere aggiornato l'online store. La creazione e la gestione di queste pipeline aggiunge mesi di lavoro di data engineering oltre allo sviluppo del modello di frode. Con i Feature Views, le definizioni delle feature registrate guidano questo processo: una chiamata a materialize_features() crea pipeline gestite che rendono le aggregazioni disponibili in Databricks Online Feature Store, basato su Lakebase.

Il percorso di streaming utilizza Spark Real-Time Mode (RTM) per elaborare gli eventi in arrivo continuamente e aggiornare gli aggregati mobili man mano che arrivano.

Materializziamo le aggregazioni mobili e Sawtooth. Per la baseline Sawtooth a 30 giorni, Databricks mantiene la porzione storica con il calcolo batch e l'attività recente con lo streaming. I due vengono uniti in lettura in un'unica feature, e StreamingMode() gestisce questo percorso ibrido senza una chiamata batch separata. Controlla entrambi i percorsi di materializzazione in Catalog Explorer prima del serving. La guida a Sawtooth consiglia di attendere due giorni interi prima dell'uso in produzione.

RequestSource fornisce i valori da ogni richiesta di scoring e le feature derivate vengono calcolate su richiesta. Una volta distribuito il modello, l'applicazione invia le chiavi del cliente e i campi di pagamento correnti al suo endpoint. Model Serving recupera le feature del cliente più recenti e valuta la deviazione on-demand, quindi passa gli input al modello di frode. Ecco il nostro pagamento di 900 $ nel formato di richiesta dell'app, utilizzando la chiamata SDK dello scorer:

L'app invia event_time in questa richiesta, ma la ricerca online utilizza le feature del cliente più recenti disponibili, non un'istantanea storica selezionata da quel timestamp. In questa demo, l'app assegna un punteggio a ciascun pagamento prima di pubblicarlo su Kafka. In questo modo il pagamento corrente non rientra nella sua cronologia, il che corrisponde all'esclusione di tale pagamento dalla finestra di training. Gli aggiornamenti delle feature e lo scoring vengono comunque eseguiti in modo asincrono, quindi potrebbero esserci altri eventi in corso quando viene valutato il pagamento successivo.

L'endpoint restituisce una probabilità in fraud_probability e un flag in fraud_prediction. L'applicazione archivia le transazioni sottoposte a scoring in Lakebase per la dashboard.

Come gestire le feature ML in Unity Catalog

I modelli di frode in produzione sollevano questioni di governance: quali modelli utilizzano una feature, da dove proviene e chi può leggerla. Unity Catalog unisce definizioni delle feature, autorizzazioni e lignaggio per rispondere a queste domande. MLflow registra quali feature utilizza ciascun modello e Model Serving utilizza tali dipendenze quando gestisce una richiesta di inferenza.

I privilegi delle feature controllano il ciclo di vita:

• CREATE FEATURE controlla la registrazione.
• READ FEATURE concede l'accesso ai metadati delle feature.
• MANAGE autorizza operazioni come la materializzazione.

I privilegi delle feature non sostituiscono le autorizzazioni SELECT necessarie sulle tabelle di origine o materializzate per il training e la distribuzione.

In Catalog Explorer, i Feature Views vengono visualizzati sotto Functions, con le relative definizioni, collegamenti di origine, tabelle materializzate e stato. Le materializzazioni di streaming si collegano ai relativi pipeline Lakeflow gestiti dal sistema per l'ispezione. Tag di materializzazione consentono ai team di attribuire i costi di calcolo della pipeline o del lavoro a un team o a un progetto specifico.

Punti chiave per il rilevamento delle frodi in tempo reale

Il nostro pagamento di 900 $ ha ora un contesto: attività recente, una baseline a lungo termine e la richiesta corrente. Tre pratiche hanno reso tutto ciò possibile:

• Definisci una volta, usa due volte. Definizioni di feature condivise per il training e la distribuzione riducono lo sfasamento tra training e distribuzione derivante da implementazioni separate.
• Calcola il punto nel tempo. Le finestre di training che escludono gli eventi futuri prevengono la fuga di dati e mantengono coerenti le metriche offline.
• Lascia che sia la piattaforma a eseguire le pipeline. La materializzazione e la ricerca online sono gestite, in modo che il lavoro rimanga concentrato sulla scelta di segnali di frode migliori.

Gli stessi pattern vanno oltre questa panoramica. LastN mantiene sequenze come i paesi di destinazione dei 10 pagamenti più recenti di un cliente, il che aiuta i modelli a individuare i cambiamenti nei percorsi di pagamento. Le feature batch possono anche utilizzare aggregazioni basate sulla cronologia completa per riassumere la storia completa di un'entità.

Per un'analisi più approfondita dell'infrastruttura alla base della freschezza dello streaming inferiore al secondo, leggi Come Databricks Feature Store fornisce feature con una freschezza inferiore al secondo. Per i dettagli sull'implementazione, consulta la documentazione per Feature Views API, materialization e esplorazione dei Feature Views in Unity Catalog.

FAQ

Cosa sono i Databricks Feature Views?

I Feature Views sono una funzionalità di Databricks Feature Store per definire le feature ML una sola volta e utilizzarle sia per il training che per la produzione. Ciascuna definizione specifica un'origine, chiavi di entità, semantica temporale e una trasformazione. La stessa API copre feature batch, in streaming e on-demand, e Unity Catalog le gestisce.

In che modo i Feature Views prevengono la fuga di dati durante il training di un modello di frode?

I Feature Views calcolano le feature di ciascun esempio di training in base al timestamp di quell'esempio. Per un pagamento alle 10:00, un conteggio delle transazioni di cinque minuti include i pagamenti dalle 9:55 fino alle 10:00 (esclusa). In questo modo le attività future vengono escluse dai dati di training, evitando di gonfiare le prestazioni offline.

Cos'è lo sfasamento tra training e distribuzione e in che modo i Feature Views lo riducono?

Lo sfasamento tra training e distribuzione si verifica quando le feature vengono calcolate in un modo per il training e in un altro per l'inferenza live. I Feature Views lo riducono utilizzando una singola definizione registrata sia per il calcolo storico che per la materializzazione online. I team non devono reimplementare la logica delle feature per la produzione.

I Feature Views possono calcolare le feature dai flussi Kafka?

Sì. Uno Stream registrato contiene la connessione Kafka, lo schema e le impostazioni di inserimento, e StreamSource vi fa riferimento nelle definizioni delle feature. Databricks mantiene una copia offline del flusso in una tabella di inserimento per il training e il backfill. La modalità in tempo reale aggiorna gli aggregati in streaming man mano che arrivano nuovi eventi.

Come vengono fornite le feature in tempo reale a un modello di frode in produzione?

La chiamata di materialize_features() crea pipeline gestite che mantengono aggiornati gli aggregati in Online Feature Store, basato su Lakebase. Quando il modello viene registrato con log_model() e distribuito su Model Serving, l'endpoint recupera le feature del cliente più recenti e calcola le feature on-demand dalla richiesta. Restituisce quindi la probabilità di frode.

(Questo post sul blog è stato tradotto utilizzando strumenti basati sull'intelligenza artificiale) Post originale