L’AI dietro Uplift

L’approccio teorico di Adyen, che prevede l’offerta di funzionalità end-to-end su un’unica piattaforma, si applica anche a ogni singola transazione. 

Tutti i passaggi nel flusso di pagamento sono interconnessi. Ogni step è influenzato da quello precedente, creando una complessa rete di dipendenze. Ad esempio, l'esperienza di pagamento offerta a un cliente dipende dal rischio previsto, che a sua volta è condizionato dall'esito dell'autenticazione e dalla scelta del metodo di pagamento, che a sua volta determina i costi e la strategia di retry se il pagamento fallisce.

Per gestire la complessità di questo processo, abbiamo investito nello sviluppo di un sistema che prendesse decisioni ottimali a livello globale durante l'intero percorso di pagamento.

Allo stesso tempo, gli esseri umani amano avere il controllo e comprendere le logiche sottostanti i processi, anche se la loro direzione può portare a molti errori. Ad esempio, per soddisfare questa esigenza, sistemi come RevenueProtect (ora un sistema legacy) esponevano un menù infinito di condizioni in base alla quale si formavano determinate regole (“se questo, allora quello”). 

Eppure, nonostante avere il senso del controllo sia apprezzabile, ciò che conta davvero sono i dati alla base di un sistema. In altri termini, la sua qualità non è determinata da come è progettato, ma da come funziona. Trovare un equilibrio tra queste due premesse è l'unico modo per poter scalare sia in complessità che in volume, offrendo le massime performance globali, e non locali; e per farlo occorre delegare la decisione alla macchina. Considerata la complessità dei pattern, l'unica via da percorrere è, quindi, consentire alla macchina di apprendere questi schemi dai dati (anche se, piccola anticipazione sul paragrafo seguente, non ha accesso a tutti i dati). 

Questo vuol dire che, come in qualsiasi applicazione AI, il ruolo degli esseri umani non è competere con la macchina per le sue decisioni o i suoi contenuti, ma supervisionarne il comportamento.  

In questo blog post vengono delineate le scelte e le logiche scientifiche di progettazione alla base dell’AI di Uplift.

In passato abbiamo implementato modelli di machine learning (ML) per ottimizzare localmente ogni passaggio di una transazione in maniera isolata. Ad esempio, un modello antifrode prevedeva la probabilità di un chargeback e bloccava una transazione se la probabilità prevista superava una determinata soglia. Contemporaneamente, un modello di autenticazione completamente separato decideva quale percorso fosse migliore per un determinato utente (ad esempio, le transazioni esenti da SCA o l’autenticazione 3DS1). 

L'AI dietro Uplift cambia questo paradigma. È progettata per supportare il processo decisionale e si compone di diversi modelli di machine learning, che condividono consapevolezza e conoscenza di determinati dati. Questi modelli sono ottimizzati globalmente attraverso il Reinforcement Learning e condividono lo stesso obiettivo: bilanciare frodi, costi e conversioni.

Vediamo alcuni numeri della piattaforma Adyen relativi al 2023:

• 1.000 miliardi di dollari di volume elaborato attraverso la piattaforma

• Crescita del 26% anno su anno

• Service Level Agreement (SLA) per l'elaborazione delle transazioni: 1 secondo, comprese le comunicazioni con l'acquirer che richiedono circa 600 ms.

Ora, consideriamo i numeri della piattaforma di Adyen durante il Black Friday/Cyber Monday del 2024 (4 giorni):

• Numero di transazioni: 670 milioni

• Quantità massima di transazioni: 163.000 al minuto (2.700 transazioni al secondo)

• Quantità massima di richieste API: 25.000 al secondo

• Livello di API uptime: 99.9999% 

I numeri sono già di per sé impressionanti, ma diventano ancora più sorprendenti se consideriamo che tutte queste transazioni sono state gestite dall'IA nel loro percorso sulla piattaforma. Ogni transazione ha raggiunto tra i 2 a 5 endpoint AI, dove un modello di machine learning prendeva una decisione, con una latenza media di 20 ms.

Ciò è possibile grazie a una serie di componenti finemente progettati e ingegnerizzati.

Nota: tutti i flussi critici di Adyen funzionano on-premise. Ciò significa che tutti i componenti qui menzionati, compreso l'hardware di calcolo, sono progettati, ingegnerizzati, distribuiti, testati e operati da Adyen. Facciamo molto affidamento sull'open source, come si evince dalla tecnologia menzionata. Una volta che l'infrastruttura è pronta, la proprietà end-to-end e il controllo completo di tutta la filiera ci consentono di implementare rapidamente modifiche senza dipendere da terze parti per garantire l'affidabilità.

La Feature platform

L'AI è collegata a una Feature Platform che fornisce vettori di input a bassa latenza, alta cardinalità, alto volume e multi-geografici, sia per il servizio di addestramento che per quello di inferenza. Per funzionalità lente e complesse utilizziamo il calcolo distribuito tramite Spark, mentre calcoliamo le funzionalità veloci utilizzando Apache Flink, memorizzandole e rendendole disponibili in un backend Cassandra, distribuito in diversi data center in varie parti del mondo, così da garantire la soddisfazione dei requisiti di localizzazione e latenza.

La Feature Platform consente di servire funzionalità con una cardinalità nell'ordine delle decine di miliardi e una latenza di servizio nell'ordine delle decine di millisecondi. 

Il servizio di inferenza

Dopo che un modello è stato addestrato, il suo artefatto viene registrato, memorizzato e messo a disposizione. Il servizio di inferenza (chiamato “Alfred”) consente agli scienziati di creare un esperimento, selezionare un modello, definire una baseline e implementare il modello in un determinato split di traffico. 

Alfred crea un endpoint API interno che si collega al flusso di pagamento (teniamo presente che si tratta di un flusso altamente critico) e si assume la responsabilità di gestire ogni richiesta con un p50 di 20 ms e un p99 di 100 ms. La dimensione dell’artefatto e l'architettura di servizio sono fondamentali per ottenere questo risultato. Una nota a margine: siamo diventati esperti nel rimuovere qualsiasi indicizzazione, metadato o percorso accessorio per i pickle di numpy o pandas. Andiamo dritti al punto!

Il servizio di inferenza si occupa anche della gestione dei modelli. Seguiamo un modello principal-challenger per ogni distribuzione (una distribuzione è un esperimento, vedi sotto). Alfred etichetterà un solo modello come “principal”, ovvero quello che viene distribuito nella stragrande maggioranza del traffico e che fornisce le migliori prestazioni tra tutte le versioni. I nuovi modelli distribuiti sotto forma di esperimenti verranno implementati in diverse fasi: (1) "ghost", dove si registrano solo le telemetrie e le statistiche, ma non si influenzano i risultati; (2) “challenger”, dove si influenzano i risultati per una determinata suddivisione del traffico e si registrano le telemetrie. Quando un challenger dimostra prestazioni migliori rispetto al modello principale con rilevanza statistica, si ritira il modello principale (che diventa “retired”) e si promuove il challenger a nuovo “principal”.

Il servizio di sperimentazione 

Tutte le distribuzioni dei modelli sono gestite da un servizio di sperimentazione utilizzato per quantificare le prestazioni di ciascun modello (principal, ghost e challenger) con precisione scientifica, inquadrato come un esperimento (cioè un'ipotesi da testare). Lo facciamo attraverso test A/B/n, confrontando le statistiche di ciascun modello con un gruppo di controllo unificato e garantendo che l'esperimento venga eseguito con roll-out graduali per sfruttare al meglio l'esperienza.

Il gruppo di controllo unificato è una suddivisione del traffico che rimane coerente su tutti gli elementi di una transazione, dove i modelli non intervengono. Viene infatti utilizzato per tracciare le transazioni e, quindi, come base di confronto per tutti i modelli. È importante notare che agiamo ancora sul gruppo di controllo, poiché definiamo la baseline come una “baseline di mercato” - ovvero una qualità dell'esperienza di pagamento che qualsiasi fornitore di pagamenti competente dovrebbe offrire. Per noi, questa baseline consiste nel bloccare le carte che sappiamo essere rubate, applicare l’esenzione della SCA (Strong Customer Authentication), utilizzare obbligatoriamente un network token e riprovare con una challenge se l'autenticazione fallisce. Ciò si traduce in un calcolo di uplift inferiore, ma più realistico per il nostro sistema. 

La risoluzione delle entità

Uno dei più grandi datastore (o database) in Adyen è un grafo che collega tra di loro gli attributi delle transazioni per riconoscere le entità. Questo grafo rappresenta una grande fonte di informazioni che possiamo modellare per estrarre funzionalità, oltre che per l’addestramento dei modelli.

Sotto la rigorosa direttiva delle norme PCI e GDPR e del nostro codice etico, possiamo utilizzare queste informazioni per decisioni risk-based e in ottica due-diligence. Stimiamo di aver visto più di 1 miliardo di individui sulla Terra effettuare transazioni sulla piattaforma Adyen. Poiché il grafo contiene tutti gli attributi delle transazioni, oggi è composto da più di 100 miliardi di nodi e 300 miliardi di archi.

Storicamente abbiamo memorizzato questi dati in database Postgres, che offrono una soluzione eccellente per la gestione del tempo, ma che sono limitati nella complessità del calcolo (logica di collegamento) e nel volume dei dati. Per questo, stiamo migrando il sistema verso un'architettura lambda con un approccio ibrido: un flusso online basato su Cassandra che gestisce i collegamenti in modo più efficiente e fornisce un ulteriore livello di profondità alla complessità di calcolo, e un flusso offline che esegue calcoli complessi e corregge ogni ora il datastore online, sia con nuovi collegamenti che annullando quelli errati. Chiamiamo questo sistema CELL (Customer Event Linking Logic).

Dimensioni di calcolo e archiviazione

Implementare l'AI su larga scala significa necessariamente sfruttare i dati che la alimentano. Abbiamo, quindi, investito nell'infrastruttura e nel framework per gestire tale processo. Ecco alcuni numeri a livello generale relativi alla piattaforma dati di Adyen attuale (gennaio 2025):

• 1500+ nodi

• 600TB di RAM

• 60.000 core CPU

• 70PB di archiviazione

• 96x NVidia A100 Tensor Core GPU con NVLink Bridge

• 1000+ DAG eseguiti giornalmente o ad-hoc sulla piattaforma (siamo fortemente dipendenti da Airflow e Spark).

Investiamo continuamente nella modernizzazione e nelle nostre capacità per soddisfare le esigenze future. “Continuamente” perché disponiamo dei processi, dei talenti e della cultura necessari per gestire il nostro cloud e garantire che sia sempre disponibile e aggiornato.

Regolamentazione, autenticazione e token vault

La scalabilità non riguarda solo il volume di dati, la latenza o l'uptime. È anche una questione di responsabilità, man mano che sempre più clienti si affidano a Adyen per elaborare i loro pagamenti e servizi finanziari. Questo ci impone di fornire soluzioni tecniche che rispettino le normative in modo intrinseco, rispondendo al contempo alle esigenze di scalabilità del nostro business.

A tal fine, abbiamo promosso l’adozione delle direttive di Strong Customer Authentication nell’ambito di PSDx e stiamo esplorando nuovi modi per essere conformi alle normative, portando al contempo sul mercato prodotti che aiutino i nostri merchant a migliorare i loro tassi di conversione. Uplift utilizza un sistema decisionale per scegliere il miglior “canale” di autenticazione al fine di bilanciare frodi, conversioni e costi. Può, inoltre, scegliere tra diverse azioni disponibili come un'esenzione, una versione di 3DS o una passkey.

Allo stesso modo, abbiamo scalato il nostro token vault e ospitiamo oltre 2 miliardi di token che salvaguardano dati altamente sensibili, conformi agli standard PCI. Ad esempio, l'AI in Uplift può scegliere di tokenizzare, utilizzare un token di pagamento o scambiare un token con un PAN, in base agli obiettivi di ottimizzazione globale.

L’efficacia di un’AI dipende dal range di azioni da cui può scegliere. Per questo, all'interno di Uplift abbiamo creato tutte quelle azioni vincolate dalle normative che, su larga scala, permettono di massimizzare le performance dell'AI.

Un sistema decisionale olistico e connesso

Una delle decisioni più complesse è collegare una serie di modelli di machine learning indipendenti a un obiettivo comune. La versione attuale di Uplift utilizza il message passing, che fornisce un approccio semplice, ma efficiente per creare consapevolezza, permettendo ai modelli di condizionare le loro stime e avvicinarsi, così, a un ottimo globale.

Abbiamo provato con artefatti più grandi e modelli di deep learning complessi che possono combinare più decisioni, e abbiamo scoperto che spesso compromettevano i requisiti ingegneristici (latenza, uptime) delle implementazioni online in flussi critici. Tuttavia, continuiamo a esplorare questa linea di pensiero e ad ampliare i confini di ciò che è possibile a livello ingegneristico, con l’intenzione di migrare l'intera pipeline verso architetture di deep learning nel prossimo futuro (vedi sotto).

Stiamo facendo ricerche attive in quest'area: abbiamo finanziato una posizione di dottorato completa con l'AMLab dell'Università di Amsterdam (UvA) per aiutarci ad affrontare questo problema da una prospettiva di Reinforcement Learning. In questo senso, abbiamo già condiviso alcuni lavori con la community in questo conference talk.

La Valutazione off-policy

Eseguire test A/B è dispendioso in termini di tempo e denaro. Se si implementa una variante non efficace, si spreca denaro e la quantità di traffico necessaria per raggiungere la significatività statistica può richiedere molto tempo. Inoltre, c’è un limite massimo al numero di esperimenti che si possono condurre in un anno, il che potrebbe ritardare la scoperta di una variante vincente, realizzando dei mancati guadagni. Inoltre, comporta un carico operativo e cognitivo, oltre a “sacrificare” la suddivisione del traffico per testare un'ipotesi. Anche nelle organizzazioni di prodotto mature, i test A/B spesso non producono risultati significativi, portando ad uno spreco di tempo.

Per questo motivo, abbiamo condotto ricerche sulla Valutazione off-policy, la quale ci consente essenzialmente di eseguire test A/B offline. Le nuove varianti possono essere testate istantaneamente con un'alta correlazione (+80%) con le stime on-policy (i vari test A/B). Questo ci ha permesso di risparmiare circa 20 settimane all’anno di tempo perso in test A/B poco significativi e di ottenere tra 9 e 54 milioni di transazioni aggiuntive in un periodo di sei mesi.

Questa ricerca è stata presentata a RecSys '25 e un preprint è disponibile su arXiv.

Controfattuali e inferenza causale

Nel nostro contesto operativo, comprendere le cause che guidano i risultati di un esperimento è più una necessità che un interesse, poiché ci permetterebbe di rilevare fonti sistemiche di entropia che potremmo evitare in futuro.

Allo stesso modo, una volta che prendiamo una decisione su una transazione (ad esempio, bloccarla per la probabilità di frode), non abbiamo accesso all'esito che si sarebbe verificato se non avessimo agito. In termini statistici, questo viene chiamato controfattuale. Per conoscere l'intera distribuzione del traffico, infatti, bisognerebbe non intervenire su di esso, il che vanificherebbe lo scopo del sistema.

A questo proposito, i gruppi di controllo, la randomizzazione e il traffico di esplorazione possono offrire supporto, ma immergersi in discipline come l'Inferenza causale ci consente di comprendere meglio le ragioni sottostanti dei risultati degli esperimenti e di bypassare i controfattuali.

Stiamo anche investendo nella ricerca in questo campo, finanziando un'altra posizione di dottorato con l'AMLab dell'UvA, per lavorare sull'inferenza causale su dataset come i nostri, sulla nostra scala di volumi. I ricercatori che lavorano al proprio dottorato hanno l'obiettivo di spingere i confini della ricerca e pubblicare articoli, mentre possono collaborare con il team ingegneristico di Adyen per implementare e testare ipotesi. Ad esempio, stiamo lavorando su un simulatore di transazioni con Generative AI, che sarebbe in grado di generalizzare su distribuzioni, controfattuali e informazioni PII, permettendoci di confrontare algoritmi e tecniche prima di eseguire esperimenti con suddivisioni di traffico reali.

La Weak supervision

Le etichette sono difficili per due motivi: quantità e qualità. Data la dimensione dei nostri dati, abbiamo abbastanza etichette per addestrare i modelli e, quindi, potremmo utilizzare tecniche di bilanciamento come il downsampling, ottenendo comunque abbastanza dati per l’addestramento.

Tuttavia, non stiamo sfruttando tutto il potere predittivo poiché le etichette normalmente arrivano in ritardo, non arrivano o arrivano in modo incompleto. Per risolvere questo problema, ci stiamo dedicando alla ricerca sulla Weak supervision. Quest’ultima si basa sul presupposto che il processo di modellazione benefici di più di una maggiore quantità di dati, anche se rumorosi, piuttosto che di una quantità minore di dati di alta qualità. Più precisamente, per una quantità fissa di dati di alta qualità, aggiungere dati rumorosi può essere più vantaggioso. La Weak supervision alimenta il “Data Flywheel di Adyen” che combina gli sforzi per aumentare la qualità e la quantità delle etichette insieme all'Active Learning (per gli sviluppi futuri, leggi più avanti). Utilizzando la Weak supervision in produzione, abbiamo aumentato il recall del +22%, ridotto le perdite in termini di tasso di autenticazione del -46% e ottenuto un guadagno del +13% nel tasso di rifiuto degli emittenti, migliorando l'efficienza nel rilevamento delle frodi.

Esplorazione casuale non uniforme per contextual bandit

Quando si esegue un esperimento in tempo reale con traffico reale su un sistema di apprendimento per rinforzo (RL), ci si trova di fronte al dilemma di eseguire l'azione che fornisce la migliore ricompensa, basata sulle conoscenze acquisite fino a quel momento (sfruttamento), e allo stesso tempo garantire che questa conoscenza sia ancora valida e non si stia agendo ciecamente sulla base di una vecchia verità (esplorazione).

La tecnica più semplice che si può adottare è chiamata epsilon-greedy, dove una suddivisione casuale del traffico di una percentuale epsilon viene destinata all’esplorazione (tipicamente scegliendo un'azione subottimale dallo spazio delle azioni disponibili). Ci sono diverse strade di ricerca per scegliere la migliore azione successiva che permetta di continuare a esplorare mantenendo una baseline subottimale, ma competitiva nell'esplorazione. Abbiamo condotto ricerche e sperimentazioni a livello di piattaforma con diverse tecniche e abbiamo riscontrato risultati significativi con le tecniche legate ai Regression Oracle.

Questa ricerca è stata presentata a WWW '25 e un preprint è disponibile su arxiv: [2412.00569] Contextual Bandits in Payment Processing: Non-uniform Exploration and Supervised Learning at Adyen.

Deep Learning e Ensemble

Uno dei nostri principi culturali è quello di puntare alla semplicità e creare soluzioni ai problemi, non problemi per le soluzioni che vogliamo utilizzare. Pertanto, gli algoritmi di machine learning classici come i boosted tree forniscono ancora una baseline solida per la maggior parte dei problemi di classificazione e regressione i cui input sono dati strutturati e hanno costituito, e talvolta costituiscono ancora, le nostre baseline principali. Abbiamo effettuato e stiamo effettuando sperimentazioni (vedi motore di sperimentazione) dove implementiamo complessi ensemble eterogenei di reti neurali per la valutazione online del flusso di pagamento e non solo abbiamo raggiunto la parità di prestazioni con le baseline di boosting, ma le abbiamo anche superate, con miglioramenti nelle performance che giustificano il delta in termini di carico operativo e complessità.

Nota: per essere precisi, l'uso dell'AI Generativa (cioè un LLM) non è una tecnologia che aiuterebbe a risolvere questo problema. Tuttavia, abbiamo preso ispirazione nel nostro lavoro da aziende come Hyperplane (ottimo prodotto, ottimo team) che hanno creato modelli offline attraverso reti più grandi basate sull'architettura Transformer, eliminando la necessità di progettazione esplicita delle funzionalità (punto successivo).

Le architetture Transformer

Stiamo sperimentando l'uso del pre-addestramento non supervisionato e delle architetture Transformer per sfruttare tutto il potenziale dei nostri dati e incorporare i corretti bias induttivi nel nostro processo di modellazione.

Oltre ai nostri sforzi per utilizzare più dati, come la Weak supervision o l'apprendimento attivo, stiamo anche esplorando degli approcci per cambiare completamente il paradigma supervisionato e permetterci di sbloccare tutto il potenziale dei nostri dati. Ispirati dai recenti progressi nella Self-supervision applicata alla modellazione del linguaggio, stiamo utilizzando gli stessi schemi di pre-addestramento non supervisionato per i dati sui pagamenti. Inferendo etichette dalla struttura dei dati stessi, possiamo ottenere una supervisione senza intervento umano e sfruttare appieno il potenziale dei nostri dataset.

Proprio come le frasi sono sequenze di parole, i clienti sono sequenze di transazioni – questa è la struttura dati principale di Adyen: sequenze di transazioni degli acquirenti. Gli approcci tradizionali alla modellazione spesso ignorano questa assunzione e modellano le sequenze indipendentemente o tentano di modellare l'assunzione con soluzioni alternative come le aggregazioni dei clienti in un dato momento; tuttavia, l'architettura Transformer offre un approccio alternativo per sfruttare appieno il potere predittivo di queste strutture.

Pertanto, le architetture Transformer e la Self-supervision ci permettono di costruire un modello di pagamenti fondativo addestrato su miliardi di transazioni, consentendoci di avviare qualsiasi processo di modellazione con una scala senza pari. Attraverso il fine-tuning a valle e gli embedding delle entità, stiamo migliorando gli insight sui clienti, ottimizzando il rilevamento delle frodi e aprendo nuove opportunità di ricerca come la generazione di dati sintetici.

L’osservabilità

Una volta che i modelli sono stati distribuiti e quantificati attraverso un esperimento, eseguiamo costantemente diagnosi per garantire che le prestazioni rimangano inalterate. Eseguiamo il rilevamento classico del drift (tipicamente sotto l'ombrello dell’MLOps) e utilizziamo algoritmi più complessi per rilevare drift nelle performance aziendali e bias, come combinazioni degli algoritmi MIST (Multiple Irregular Seasonalities and Trend decomposition) e DTW (Dynamic Time Warping). Abbiamo approfondito questi temi nel corso di PyData 2024.

Equità ed explainability

Affidare le decisioni alla macchina comporta inevitabilmente delle sfide legate alla garanzia che tali decisioni non siano influenzate da bias che possono segmentare la popolazione o risultare ingiuste da una prospettiva umana.

Per questo, abbiamo istituito un gruppo di lavoro interno di esperti tecnici e legali per essere al passo con le normative, inclusi il GDPR e l'AI Act, e abbiamo apportato modifiche procedurali per garantire che Adyen rimanga fedele al suo ethos culturale: un'azienda altamente etica. Tutti i prodotti e i modelli devono essere valutati per individuare eventuali bias e controllati per verificare se potrebbero violare manuali e normative. Una volta approvati dal gruppo di lavoro, monitoriamo attraverso strumenti di osservabilità che alcune funzionalità sensibili non causino overfitting. 

Tutte le decisioni prese dall'AI devono essere spiegate. Per questo ogni chiamata di inferenza viene registrata e gli algoritmi che ragionano sui motivi sottostanti vengono valutati (ad esempio, i valori SHAP). L'interfaccia utente di Adyen Uplift offre una spiegazione su ogni decisione legata alla transazione.

Sebbene questo contenuto fornisca un'istantanea del funzionamento interno, delle sfide e delle lezioni apprese durante la costruzione e la distribuzione di Adyen Uplift, è chiaro che abbiamo raggiunto solo una parte di dove vogliamo arrivare.

Stiamo conducendo ricerche attive nei campi sopra menzionati e in altre strade che mostrano i primi risultati promettenti, come Agentic Flow, Alignment, Weak supervision + Active Learning Flywheel e Identity Representation Learning con privacy differenziale.

In questo articolo forniamo un'istantanea trasparente e fattuale della tecnologia dietro Adyen Uplift. Siamo sempre alla ricerca di talenti eccezionali che vogliano unirsi al nostro team eccezionale. Se i contenuti di questo post ti hanno convinto, dai un'occhiata alla nostra pagina delle carriere!