Ik heb het concept van federatief leren (FL) geïntroduceerd via een strip van Google in 2019. Het was een briljant stuk en heeft uitstekend werk geleverd door uit te leggen hoe producten kunnen verbeteren zonder gebruikersgegevens naar de cloud te sturen. De laatste tijd wil ik de technische kant van dit vakgebied meer in detail begrijpen. Trainingsgegevens zijn zo’n belangrijk handelsartikel geworden omdat ze essentieel zijn voor het bouwen van goede modellen, maar veel hiervan blijft ongebruikt omdat ze gefragmenteerd, ongestructureerd of opgesloten zijn in silo’s.
Toen ik dit veld begon te verkennen, vond ik de Bloem kader om de meest eenvoudige en beginnersvriendelijke manier te zijn om aan de slag te gaan in FL. Het is open source, de documentatie is duidelijk en de gemeenschap eromheen is zeer actief en behulpzaam. Het is een van de redenen voor mijn hernieuwde interesse in dit vakgebied.
Dit artikel is het eerste deel van een serie waarin ik dieper inga op federatief leren, waarbij ik bespreek wat het is, hoe het wordt geïmplementeerd, de openstaande problemen waarmee het wordt geconfronteerd en waarom het van belang is in privacygevoelige omgevingen. In de volgende afleveringen ga ik dieper in op de praktische implementatie met de Bloemraamwerk, privacy in federatief leren bespreken en onderzoeken hoe deze ideeën zich uitstrekken tot meer geavanceerde gebruiksscenario’s.
Wanneer gecentraliseerd machinaal leren niet ideaal is
We weten dat AI-modellen afhankelijk zijn van grote hoeveelheden gegevens, maar toch zijn veel van de nuttigste gegevens gevoelig, gedistribueerd en moeilijk toegankelijk. Denk aan gegevens in ziekenhuizen, telefoons, auto’s, sensoren en andere randsystemen. Privacyproblemen, lokale regels, beperkte opslag en netwerklimieten maken het verplaatsen van deze gegevens naar een centrale plek erg moeilijk of zelfs onmogelijk. Als gevolg hiervan blijven grote hoeveelheden waardevolle gegevens ongebruikt. Vooral in de gezondheidszorg is dit probleem zichtbaar. Ziekenhuizen genereren elk jaar tientallen petabytes aan gegevens, maar studies schatten dat dit oploopt tot 97% van deze gegevens blijft ongebruikt .
Traditioneel machine learning gaat ervan uit dat alle trainingsgegevens op één plek kunnen worden verzameld, meestal op een gecentraliseerde server of datacenter. Dit werkt wanneer gegevens vrijelijk kunnen worden verplaatst, maar het mislukt wanneer gegevens privé of beschermd zijn. In de praktijk is gecentraliseerde training ook afhankelijk van stabiele connectiviteit, voldoende bandbreedte en lage latentie, die moeilijk te garanderen zijn in gedistribueerde of edge-omgevingen.
In dergelijke gevallen verschijnen er twee veelvoorkomende keuzes. Eén optie is om de gegevens helemaal niet te gebruiken, wat betekent dat waardevolle informatie in silo’s opgesloten blijft.
De andere optie is om elke lokale entiteit een model te laten trainen op zijn eigen data en alleen te delen wat het model leert, terwijl de ruwe data nooit de oorspronkelijke locatie verlaten. Deze tweede optie vormt de basis van federatief leren, waardoor modellen kunnen leren van gedistribueerde gegevens zonder deze te verplaatsen. Een bekend voorbeeld is Google Gboard op Android, waar functies als volgende woordvoorspelling en Slim samenstellenlopen over honderden miljoenen apparaten.
Federated Learning: het model naar de gegevens verplaatsen
Federated learning kan worden gezien als een collaboratieve machine learning-opstelling waarbij training plaatsvindt zonder gegevens op één centrale plek te verzamelen. Voordat we kijken hoe het onder de motorkap werkt, laten we eerst een paar voorbeelden uit de praktijk bekijken die laten zien waarom deze aanpak van belang is in omgevingen met een hoog risico, variërend van domeinen van de gezondheidszorg tot beveiligingsgevoelige omgevingen.
Gezondheidszorg
In de gezondheidszorg maakte federatief leren een vroege screening op COVID mogelijk Curiële AI een systeem dat in meerdere NHS-ziekenhuizen is getraind met behulp van routinematige vitale functies en bloedtesten. Omdat patiëntgegevens niet tussen ziekenhuizen konden worden gedeeld, werd op elke locatie lokaal getraind en werden alleen modelupdates uitgewisseld. Het resulterende mondiale model generaliseerde beter dan modellen die in individuele ziekenhuizen waren getraind, vooral wanneer ze op onzichtbare locaties werden geëvalueerd.
Medische beeldvorming
Gefedereerd leren wordt ook onderzocht in de medische beeldvorming. Onderzoekers van de UCL en het Moorfields Eye Hospital gebruiken het om grote vision-funderingsmodellen te verfijnen op gevoelige oogscans die niet gecentraliseerd kunnen worden.
Verdediging
Naast de gezondheidszorg wordt federatief leren ook toegepast in veiligheidsgevoelige domeinen zoals defensie en luchtvaart. Hier worden modellen getraind op gedistribueerde fysiologische en operationele gegevens die lokaal moeten blijven.
Verschillende soorten federatief leren
Op een hoog niveau kan federatief leren worden gegroepeerd in een aantal veelvoorkomende typen, op basis van: wie de klanten zijnEn hoe de gegevens worden gesplitst .
• Cross-device versus cross-silo federatief leren
Federatief leren op verschillende apparaten omvat het gebruik van vele klanten, die kunnen oplopen tot miljoenen, zoals persoonlijke apparaten of telefoons, elk met een kleine hoeveelheid lokale gegevens en onbetrouwbare connectiviteit. Op een gegeven moment neemt echter slechts een klein deel van de apparaten deel aan een bepaalde ronde. Google Gboard is een typisch voorbeeld van deze opzet.
Cross-silo federatief leren, anderzijds, Het betreft een veel kleiner aantal klanten, meestal organisaties zoals ziekenhuizen of banken. Elke client beschikt over een grote dataset en beschikt over stabiele rekenkracht en connectiviteit. De meeste gebruiksscenario’s in het bedrijfsleven en de gezondheidszorg lijken op federaal leren tussen silo’s.
• Horizontaal versus verticaal federatief leren
Horizontaal federatief leren beschrijft hoe gegevens over klanten worden verdeeld. In dit geval delen alle clients dezelfde featureruimte, maar bevatten ze allemaal verschillende samples. Meerdere ziekenhuizen kunnen bijvoorbeeld dezelfde medische variabelen registreren, maar voor verschillende patiënten. Dit is de meest voorkomende vorm van federatief leren.
Verticaal federatief leren wordt gebruikt wanneer clients dezelfde set entiteiten delen, maar verschillende functies hebben. Een ziekenhuis en een verzekeringsmaatschappij kunnen bijvoorbeeld allebei gegevens hebben over dezelfde personen, maar met verschillende kenmerken. Training vereist in dit geval een veilige coördinatie omdat de functieruimten verschillen, en deze opzet is minder gebruikelijk dan horizontaal federatief leren.
Deze categorieën sluiten elkaar niet uit. Een echt systeem wordt vaak beschreven met behulp van beide assen, bijvoorbeeld a cross-silo, horizontaal federatief lerenopstelling.
Hoe federatief leren werkt
Gefedereerd leren volgt een eenvoudig, herhaald proces dat wordt gecoördineerd door een centrale server en wordt uitgevoerd door meerdere clients die gegevens lokaal bewaren, zoals weergegeven in het onderstaande diagram.
Training in federatief leren verloopt via herhaling federatieve leerrondes. In elke ronde selecteert de server een kleine willekeurige subset van clients, stuurt hen de huidige modelgewichten en wacht op updates. Elke klant traint het model lokaal met behulp van stochastische gradiëntafdaling meestal voor verschillende lokale tijdperken in zijn eigen batches, en retourneert alleen de bijgewerkte gewichten. Op een hoog niveau volgt het de volgende vijf stappen:
- Initialisatie
Op de server wordt een globaal model gemaakt, dat als coördinator fungeert. Het model kan willekeurig worden geïnitialiseerd of starten vanuit een vooraf getrainde toestand.
2. Modeldistributie
In elke ronde selecteert de server een reeks clients (gebaseerd op willekeurige steekproeven of een vooraf gedefinieerde strategie) die deelnemen aan de training en stuurt hen de huidige globale modelgewichten. Deze klanten kunnen telefoons, IoT-apparaten of individuele ziekenhuizen zijn.
3. Lokale opleiding
Elke geselecteerde klant traint het model vervolgens lokaal met behulp van zijn eigen gegevens. De gegevens verlaten de klant nooit en alle berekeningen gebeuren op het apparaat of binnen een organisatie zoals een ziekenhuis of een bank.
4. Communicatie over modelupdates
Na de lokale training sturen clients alleen de bijgewerkte modelparameters (dit kunnen gewichten of gradiënten zijn) terug naar de server, terwijl onbewerkte gegevens op elk moment worden gedeeld.
5. Aggregatie
De server verzamelt de clientupdates om een nieuw globaal model te produceren. Terwijl Federatieve middeling (Fed Avg) is een gebruikelijke benadering voor aggregatie, andere strategieën worden ook gebruikt. Het bijgewerkte model wordt vervolgens teruggestuurd naar klanten, en het proces herhaalt zich tot convergentie.
Gefedereerd leren is een iteratief proces en elke passage door deze lus wordt een ronde genoemd. Voor het trainen van een federatief model zijn doorgaans vele, soms honderden, rondes nodig, afhankelijk van factoren zoals modelgrootte, gegevensdistributie en het probleem dat wordt opgelost.
Wiskundige intuïtie achter Federated Averaging
De hierboven beschreven workflow kan ook formeler worden geschreven. Onderstaande figuur toont het origineel Federatieve middeling (Fed Avg) algoritme uit het baanbrekende artikel van Google. Dit algoritme werd later het belangrijkste referentiepunt en toonde aan dat federatief leren in de praktijk kan werken. Deze formulering werd in feite het referentiepunt voor de meeste federatieve leersystemen van vandaag.
Het originele Federated Averaging-algoritme, dat de server-client-trainingslus en de gewogen aggregatie van lokale modellen toont.
De kern van Federated Averaging is de aggregatiestap, waarbij de server het globale model bijwerkt door een gewogen gemiddelde te nemen van de lokaal getrainde clientmodellen. Dit kan worden geschreven als:
Deze vergelijking maakt duidelijk hoe elke klant bijdraagt aan het mondiale model. Cliënten met meer lokale gegevens hebben een grotere invloed, terwijl cliënten met minder steekproeven verhoudingsgewijs minder bijdragen. In de praktijk is dit eenvoudige idee de reden waarom Fed Avg de standaardbasislijn voor federatief leren werd.
Een eenvoudige NumPy-implementatie
Laten we eens kijken naar een minimaal voorbeeld waarbij vijf klanten zijn geselecteerd. Voor de eenvoud gaan we ervan uit dat elke klant de lokale training al heeft afgerond en de bijgewerkte modelgewichten heeft teruggestuurd, samen met het aantal gebruikte monsters. Met behulp van deze waarden berekent de server een gewogen som die het nieuwe globale model voor de volgende ronde oplevert. Dit weerspiegelt rechtstreeks de Fed Avg-vergelijking, zonder training of details aan de klantzijde te introduceren.
import numpy as np
# Client models after local training (w_{t+1}^k)
client_weights = (
np.array((1.0, 0.8, 0.5)), # client 1
np.array((1.2, 0.9, 0.6)), # client 2
np.array((0.9, 0.7, 0.4)), # client 3
np.array((1.1, 0.85, 0.55)), # client 4
np.array((1.3, 1.0, 0.65)) # client 5
)
# Number of samples at each client (n_k)
client_sizes = (50, 150, 100, 300, 4000)
# m_t = total number of samples across selected clients S_t
m_t = sum(client_sizes) # 50+150+100+300+400
# Initialize global model w_{t+1}
w_t_plus_1 = np.zeros_like(client_weights(0))
# FedAvg aggregation:
# w_{t+1} = sum_{k in S_t} (n_k / m_t) * w_{t+1}^k
# (50/1000) * w_1 + (150/1000) * w_2 + ...
for w_k, n_k in zip(client_weights, client_sizes):
w_t_plus_1 += (n_k / m_t) * w_k
print("Aggregated global model w_{t+1}:", w_t_plus_1)
-------------------------------------------------------------
Aggregated global model w_{t+1}: (1.27173913 0.97826087 0.63478261)
Hoe de aggregatie wordt berekend
Om de zaken in perspectief te plaatsen: we kunnen de aggregatiestap voor slechts twee klanten uitbreiden en kijken hoe de cijfers in elkaar passen.
Uitdagingen in federatieve leeromgevingen
Gefedereerd leren brengt zijn eigen uitdagingen met zich mee. Een van de belangrijkste problemen bij de implementatie ervan is dat de gegevens tussen clients vaak niet-IID zijn (niet-onafhankelijk en identiek gedistribueerd). Dit betekent dat verschillende klanten zeer verschillende gegevensdistributies kunnen zien, wat op zijn beurt de training kan vertragen en het mondiale model minder stabiel kan maken. Ziekenhuizen in een federatie kunnen bijvoorbeeld verschillende populaties bedienen die verschillende patronen kunnen volgen.
Bij federatieve systemen kan van alles betrokken zijn, van een paar organisaties tot miljoenen apparaten, en het beheren van deelname, uitval en aggregatie wordt moeilijker naarmate het systeem schaalt.
Hoewel federatief leren de ruwe data lokaal houdt, lost het de problemen niet volledig op privacy op zichzelf. Modelupdates kunnen nog steeds privé-informatie lekken als deze niet wordt beschermd, en daarom zijn vaak extra privacymethoden nodig. Eindelijk, mededelingkan een bron van knelpunten zijn. Omdat netwerken traag of onbetrouwbaar kunnen zijn en het regelmatig verzenden van updates kostbaar kan zijn.
Conclusie en hoe nu verder
In dit artikel hebben we begrepen hoe federatief leren op een hoog niveau werkt en hebben we ook een eenvoudige Numpy-implementatie doorlopen. In plaats van de kernlogica met de hand te schrijven, zijn er echter raamwerken zoals Flower die een eenvoudige en flexibele manier bieden om gefedereerde leersystemen te bouwen. In het volgende deel zullen we Flower gebruiken om het zware werk voor ons te doen, zodat we ons kunnen concentreren op het model en de gegevens in plaats van op de mechanismen van federatief leren. Wij gaan ook eens kijken federatieve LLM’swaarbij modelgrootte, communicatiekosten en privacybeperkingen nog belangrijker worden.
Let op: Alle afbeeldingen zijn, tenzij anders vermeld, gemaakt door de auteur.
