Per gran parte dell’ultimo decennio, il manuale del machine learning \u00e8 stato semplice: raccogliere dati, spedirli su un server centrale, allenare, distribuire. Funzionava, ma con un prezzo \u2014 costi di trasferimento, latenza, e un mal di testa di compliance ogni volta che “dati personali” e “cloud” finivano nella stessa frase.<\/p>\n\n\n\n
Il Federated Learning (FL) ribalta la pipeline. Invece di spostare i dati verso il modello, sposta il modello verso i dati. L’allenamento avviene direttamente dove i dati gi\u00e0 vivono \u2014 uno smartphone, un server ospedaliero, un’auto \u2014 e solo gli aggiornamenti appresi<\/em> tornano a un coordinatore centrale. I dati grezzi non lasciano mai la loro origine.<\/p>\n\n\n\n Non \u00e8 un componente di privacy aggiunto sopra l’infrastruttura ML esistente. \u00c8 un’architettura diversa, e gira gi\u00e0 in produzione su Google, Apple, e un numero crescente di sistemi sanitari e finanziari.<\/p>\n\n\n\n Il FL \u00e8 un paradigma di allenamento distribuito in cui pi\u00f9 client \u2014 dispositivi o organizzazioni \u2014 allenano collaborativamente un modello condiviso senza mettere in comune i dati grezzi. Ogni client allena una copia locale del modello sul proprio dataset e invia indietro solo:<\/p>\n\n\n\n Ci\u00f2 che non lascia mai il client: foto, messaggi, cartelle cliniche, cronologie finanziarie \u2014 qualsiasi dato grezzo e identificabile.<\/p>\n\n\n\n L’assunto alla base: i dati hanno gravit\u00e0, ed \u00e8 spesso pi\u00f9 economico, pi\u00f9 sicuro e legalmente pi\u00f9 semplice spostare il calcolo verso i dati piuttosto che il contrario.<\/p>\n\n\n\n ML centralizzato:<\/strong> Dispositivo \u2192 dati grezzi \u2192 server centrale \u2192 allenamento \u2192 modello. I dati di ogni client finiscono in un unico posto, il che significa un solo punto da proteggere, un solo punto che pu\u00f2 bucarsi, e un trasferimento di dataset che deve superare la revisione legale.<\/p>\n\n\n\n Federated Learning:<\/strong><\/p>\n\n\n\n Il server non vede mai un singolo esempio di training grezzo \u2014 solo l’aggregato di ci\u00f2 che tutti hanno imparato.<\/p>\n\n\n\n 1. Server federato (coordinamento)<\/strong> Inizializza il modello base, seleziona quali client partecipano a un dato round, riceve gli aggiornamenti, esegue l’algoritmo di aggregazione e ridistribuisce il modello migliorato. Lo stack di Federated Learning di Google, TensorFlow Federated e Flower implementano tutti questo ruolo.<\/p>\n\n\n\n 2. Client federati (allenamento locale, edge computing)<\/strong> Ogni client scarica il modello corrente, lo allena in locale sui propri dati, calcola l’aggiornamento risultante e rimanda indietro solo quello \u2014 nient’altro. Tutto il calcolo avviene sull’edge; nessun dato grezzo viene trasmesso.<\/p>\n\n\n\n 3. Estrazione e protezione dell’aggiornamento<\/strong> Prima che un aggiornamento lasci il client, viene tipicamente avvolto in una protezione aggiuntiva \u2014 secure aggregation o differential privacy \u2014 cos\u00ec il server non pu\u00f2 risalire ai contributi individuali da quello che riceve. \u00c8 questo lo strato che trasforma “non inviamo dati grezzi” in una garanzia di privacy reale, non solo un’intenzione di design.<\/p>\n\n\n\n 4. Aggregazione centrale<\/strong> Il server combina gli aggiornamenti in arrivo in un nuovo modello globale. L’algoritmo standard qui \u00e8 FedAvg (Federated Averaging)<\/strong>, introdotto da Google nel 2017: i pesi locali di ogni client vengono combinati in una media pesata, pesata in base a quanti dati quel client ha usato per allenare. Il risultato \u00e8 un nuovo modello globale che ha assorbito conoscenza da ogni partecipante senza che nessuno di loro esponesse il proprio dataset.<\/p>\n\n\n\n No \u2014 non da solo. Inviare gradienti invece di dati grezzi \u00e8 un miglioramento reale, non una soluzione definitiva. I vettori di attacco noti includono:<\/p>\n\n\n\n Per questo i sistemi FL in produzione aggiungono difese ulteriori:<\/p>\n\n\n\nCos’\u00e8 davvero il Federated Learning<\/h2>\n\n\n\n
\n
Come funziona, concretamente<\/h2>\n\n\n\n
\n
L’architettura, componente per componente<\/h2>\n\n\n\n
ML centralizzato vs. Federated Learning<\/h2>\n\n\n\n
<\/th> ML centralizzato<\/th> Federated Learning<\/th><\/tr><\/thead> Posizione dei dati<\/td> Aggregati su un server<\/td> Restano su ogni dispositivo\/istituzione<\/td><\/tr> Cosa viene trasmesso<\/td> Dati grezzi<\/td> Pesi del modello \/ gradienti<\/td><\/tr> Esposizione privacy<\/td> Alta \u2014 singolo punto di fallimento<\/td> Bassa \u2014 nessun dato grezzo in transito<\/td><\/tr> Superficie di compliance<\/td> Ampia (trasferimento, storage, retention)<\/td> Ridotta (nessun dato grezzo lascia l’origine)<\/td><\/tr> Luogo di allenamento<\/td> Infrastruttura centrale<\/td> Dispositivi edge \/ server locali<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Framework da conoscere<\/h2>\n\n\n\n
\n
Il FL garantisce davvero la privacy?<\/h2>\n\n\n\n
\n