Blog.

Horizontal vs Vertical vs Transfer Federated Learning


Autore
Andrea Provino
Data
Tempo di lettura
6 minuti
Categoria
machine-learning, Privacy Preserving

transfer-fedearted-learning-vertical-horizontal-example-data-science-machine-learning

Quali sono le differenze tra Horizontal Federated Learning, Vertical Federated Learning e Transfer Federated Learing?

In questo post le esaminiamo insieme, trovando importarti casi d’uso per approfondire questi affascinanti mondi.

Vele ammainate capitano. Siamo pronti a una nuova traversata!

Cosa centrano le vele, un capitano e una traversata?

Te lo spiego subito.

Sappi che in questo post riprenderò la metafora del marinaio e del capitano, in un ipotetico viaggio verso l’irraggiungibile conoscenza suprema.

Sono sicuro che questo appunto risparmierà alla tua mente estenuanti tentativi di ragionamento su parole e significati apparentemente sconnessi: oggi vestiamo i panni di ambiziosi marinai bramanti di conoscenza.

Il viaggio attraverso gli aspetti del Federated Learning sarà la nostra conquista.

Categorie di Federated Learning

Siamo in grado di distinguere diverse architetture di apprendimento federato attraverso le caratteristiche del set di dati impiegato.

Continua a leggere…

Prima di procedere, occorre però allineare il nostro linguaggio, così da evitare di perderci preziose informazioni e nozioni lungo la rotta.

Nel briefing (ricordati che prima di salpare è fondamentale!) abbiamo compreso il significato di Federated Learning.

Non temere, ho trascritto le comunicazioni e puoi trovarle qui.

Ora completiamo il nostro vocabolario comune con altri termini tecnici.

Definiamo allora matrice Di i dati posseduti da ciascun data owner i.

Ciascuna riga della matrice rappresenta un campione o sample, mentre ogni colonna una caratteristica del campione, o feature.

Chiaramente, alcuni data set possono contenere anche una label, la caratteristica chiave che assumiamo essere legata da una funzione matematica alle feature.

L’insieme, o meglio lo spazio (space) delle feature lo indicheremo come X, il label space come Y e infine il sample ID space con I.

Ora il punto del Federated Learning è che le cose sono spesso meno rosee di come appaiano.

Quando ci troviamo a confrontarci con dati generati da diverse parti, è chiaro che il feature spaces possono variare notevolmente, determinando una variazione nell’approccio del loro handling.

Sulla base del feature space e sample ID space distinguiamo dunque:

  • Horizontal Federated Learning
  • Vertical Federated Learning
  • Transfer Federated Learning

Per ogni metodo ne esamineremo i tratti salienti, considerando anche il delicato e importante tema della definizione di sicurezza.

Studiamo il primo.

Horizontal FL

L’apprendimento federato orizzontale si adatta alle situazioni in cui i set di dati considerati condividono lo stesso feature space ma differiscono nel sample space.

Un esempio veloce?

Due banche site in regioni differenti raccolgono gli stessi dati sui clienti, che chiaramente apparterranno ad altrettanti gruppi utenti delle rispettive regioni.

L’intersezione degli utenti è quindi evidentemente piccola, con pochi o nessun campione in comune.

Che tradotto significa: è verosimile ritenere che ci siano pochissime persone con due conti in altrettante regioni in cui la stessa banca opera.

Piccolo appunto, il termine regione si riferisce in senso lato ad area geografica e non a mera differenza tra Lombardia e Piemonte ad esempio.

Teniamo poi presente che l’applicazione dell’Horizontal Federated Learning può essere estesa a due aziende che operino in un business simile, non necessariamente in competizione, con clienti differenti ma stessi parametri chiave, quindi identico fetaure space.

Security Definition

Vediamo un primo modello di sicurezza applicabile.

Un sistema di horizontal federated learning assume tipicamente che i partecipanti siano onesti e una certa sicurezza contro un server centrale definito onesto ma curioso.

Al termine del training, il modello generale e i tutti parametri sono esposti a ogni partecipante.

Date queste considerazioni, solamente il server centrale può potenzialmente compromettere la privacy dei dati dei partecipanti.

Per questo sono adottate tecniche crittografiche come lhomomorphic encryption che forniscono un layer di sicurezza aggiuntivo sul server centrale per l’aggregazione dei parametri in fase di training.

Un altro modello di sicurezza, proposto in una pubblicazione del 2017 ammette invece la presenza di un utente malevolo che apre le porte a nuove altre considerazioni.

Le approfondiremo in un secondo momento, quando valuteremo con più attenzione gli attacchi a questi sistemi.

Vertical FL

Il sistema di apprendimento federato verticale assume che i dati considerati abbiano lo stesso sample space ma diverso feature space.

Formalmente dunque: feature e label differiscono, seppur con stessi sample ID, per ogni campione dei dataset delle parti considerate, con parti diverse tra loro.

Un sistema di questo tipo risulta pertanto applicabile laddove due diverse aziende (due parti) operino nella stessa regione, avendo dunque business anche differenti ma rivolti ai medesimi clienti.

Consideriamo un caso d’uso reale tra una banca, con dati relativi alla capacità di acquisto e ai movimenti bancari dei clienti, e un e-commerce, con dati storici relativi ai prodotti visualizzati e quelli acquistati, che codificano gli interessi dei clienti.

Il sistema di vertical federated learning consentirebbe alle parti di sviluppare un modello condiviso sulla probabilità di acquisto prodotti, e dunque spesa sostenuta, attraverso i dati utente e prodotto.

Un progetto win-win in cui tutti beneficiano del risultato.

L’apprendimento federato verticale consente dunque di aggregare le differenti feature e calcolare il training loss e i gradients con un approccio privacy-preserving.

Attraverso questo sistema e considerando le attuali misure applicabile, è possibile compiere task di :

Secure definition

Un primo modello di sicurezza assume che i partecipanti siano onesti ma curiosi. Nel caso in cui due parti siano coinvolte, consideriamo che queste non colludano e almeno una sia compromessa da un avversario.

La definizione di sicurezza assicura dunque che l’avversario possa apprendere solo i dati della parte compromessa, e nulla dell’altra al di fuori di quelli in input e output.

Per agevolare la comunicazione sicura tra le parti, è possibile definire una così detta Semi-honest Third Party (STP), che assumiamo non colluda con alcuna altra parte e fornisca prove formali di privacy per i protocolli.

Al termine dell’allenamento ciascuna parte possiede solamente i parametri relativi alle proprie features. Dunque l’inferenza deve essere eseguita con approccio collaborativo.

Passiamo ora all’ultimo sistema

Transfer Federated Learning

Il Federated Transfer Learning è il sistema attraverso cui gestire i casi che non rientrano nei precedenti scenari.

Più nello specifico è applicabile laddove i dati delle due parti considerate differiscano non solo a livello di sample space ma anche nel feature space.

Consideriamo due istituzione: una banca cinese e un’azienda di e-commerce statunitense.

Le restrizione geografiche fanno si che i gruppi utenti abbiano una piccola interesezione e le caratteristiche del dataset, a causa del diverso business, si sovrappongono solo parzialmente.

Tecnicamente questo è quello che avviene.

Una rappresentazione comune dei due feature space è rappresentata in un modello usando l’intersezione comune degli utenti e successivamente usata per asserire i dati mancanti nei campioni con solamente un gruppo di caratteristiche.

Secure definition

Possiamo qui estendere le considerazione del Vertical Federated Learning

Questa pubblicazione è ricca di spunti e ulteriori approfondimenti.

Per il momento è tutto.

Per aspera, ad astra.

Un caldo abbraccio, Andrea

Taggedfederated learningmachine learningprivacy preserving machine learning


Ultimi post

Patricia Merkle Trie

Il Practical Algorithm To Retrieve Information Coded In Alphanumeric Merkle Trie, o Patricia Merkle Trie è una struttura dati chiave-valore usatada Ethereum e particolarmente efficiente per il salvataggio e la verifica dell’integrità dell’informazione. In questo post ne studieremo le caratteristiche. Prima di procedere, ci conviene ripassare l’introduzione al Merkle Tree nella quale abbiamo chiarito il […]

Andrea Provino
ethereum-patricia-merkle-tree
Tree Data Structure: cos’è un Merkle Tree

Un Merkle Tree è una struttura dati efficiente per verificare che un dato appartenga a un insieme esteso di elementi. È comunemente impiegato nelle Peer to Peer network in cui la generazione efficiente di prove (proof) contribuisce alla scalabilità della rete. Capire i vantaggi di questa struttura ci tornerà utile nel nostro percorso di esplorazione […]

Andrea Provino
merkle-tree-cover
UTXO: come funziona il modello Unspent Transaction Outputs

Per tenere traccia dei bilanci utente, la blockchain di Bitcoin sfrutta un modello di contabilità definito UTXO o Unspent Transaction Outputs. In questo articolo ne esaminiamo le caratteristiche. Ogni blockchain è dotata di un sistema di contabilità, un meccanismo attraverso cui tenere traccia dei bilanci di ciascun utente. I due grandi modelli di riferimento nel […]

Andrea Provino
bitcoin-utxo
Cos’è Ethereum

Possiamo definire Ethereum come una macchina a stati distribuita che traccia le transizioni di un archivio dati general-purpose (i.e. una memoria in grado di registrare qualsiasi dato esprimibile come coppia di chiave e valore o key-value) all’interno della Ethereum Blockchain. È arrivato il momento di esplorare uno dei progetti tecnologici più innovativi e interessanti degli […]

Andrea Provino
ethereum