Hvad er Federated Learning?

Federated learning er en metode til maskinlæring, hvor flere enheder eller organisationer træner en fælles model uden at samle rå træningsdata ét centralt sted. Metoden bruges især, når data er følsomme, spredte eller dyre at flytte, men den kræver stadig styring af sikkerhed, modelkvalitet, drift og ansvar.

Hvordan fungerer federated learning i praksis?

I federated learning starter en koordinerende server typisk med en fælles model. Modellen sendes til udvalgte klienter, for eksempel telefoner, sensorer, hospitaler, banker eller afdelinger i samme koncern. Hver klient træner modellen på sine egne lokale data og sender derefter en modelopdatering tilbage.

Serveren samler de lokale opdateringer til en ny global model. Den nye model kan derefter sendes ud i næste runde. Processen gentages, indtil modellen opnår den ønskede kvalitet, eller indtil træningen stoppes af praktiske, økonomiske eller sikkerhedsmæssige grunde.

Pointen er ikke, at data aldrig behandles. Pointen er, at rå træningsdata normalt bliver hos den part, der allerede har dem. Det ændrer arkitekturen for machine learning og deep learning, fordi læringen flyttes tættere på datakilden.

Hvad sendes mellem klienter og server?

Den centrale server sender modelparametre, modelversioner eller instruktioner for næste træningsrunde. Klienten bruger sine lokale data til at beregne en opdatering. Det kan være vægte, gradienter eller andre statistiske ændringer, som beskriver, hvordan modellen bør justeres.

Rådata som tastetryk, patientjournaler, kundetransaktioner eller sensormålinger behøver ikke blive sendt til serveren for at indgå i træningen. Det reducerer databevægelse, men det betyder ikke, at opdateringerne er ufarlige. Modelopdateringer kan i visse tilfælde afsløre mønstre om de lokale data, hvis systemet ikke er beskyttet.

Derfor bliver federated learning ofte kombineret med adgangskontrol, krypteret transport, secure aggregation, støjtilføjelse, revisionsspor og regler for, hvilke klienter der må deltage. Den tekniske arkitektur skal passe til risikoniveauet i de data, modellen lærer af.

Hvilke typer federated learning findes der?

Den mest almindelige opdeling skelner mellem cross-device og cross-silo federated learning. Cross-device handler om mange enheder med begrænset beregning, ustabil netværksforbindelse og meget ujævne datasæt. Smartphones, wearables og IoT-enheder er typiske eksempler.

Cross-silo handler om færre, mere stabile parter, for eksempel flere hospitaler, banker, forskningsmiljøer eller datterselskaber. Her er forbindelsen normalt mere kontrolleret, men governance, kontrakter, rollefordeling og revisionskrav fylder mere.

Hvorfor bruges federated learning til følsomme data?

Federated learning er relevant, når data har høj værdi for modeltræning, men lav mobilitet. Det kan skyldes persondata, forretningshemmeligheder, datamængder, sikkerhedskrav, sektorregler eller praktiske omkostninger ved at samle data ét sted.

I sundhed kan flere institutioner eksempelvis ønske en fælles model uden at eksportere patientnære data til én database. I finans kan flere parter ønske at forbedre en risikomodel uden at dele rå transaktionshistorik. I industri kan maskindata blive på lokale anlæg, fordi de er store, følsomme eller tæt knyttet til driftsmiljøet.

Metoden passer også til AI edge computing, hvor data opstår tæt på brugeren eller maskinen. Hvis data allerede ligger lokalt, kan lokal træning være mere realistisk end konstant upload til et centralt træningsmiljø.

Hvad gør federated learning ikke privat af sig selv?

Federated learning skal ikke forveksles med anonymisering. Hvis en klient sender modelopdateringer, kan opdateringerne stadig indeholde information om den lokale datastruktur. En angriber kan i nogle scenarier forsøge at udlede karakteristika, medlemskab eller konkrete datapunkter fra opdateringerne.

Metoden fjerner heller ikke behovet for datasikkerhed. Klienter kan være kompromitterede, serveren kan være forkert konfigureret, og ondsindede deltagere kan forsøge at forgifte modellen med manipulerede opdateringer. En fælles model kan derfor blive påvirket af både datakvalitet og sikkerhedshændelser hos deltagere.

Den praktiske læresætning er enkel: federated learning reducerer centralisering af rådata, men privatliv og sikkerhed kræver flere lag. Hvis systemet behandler persondata, skal du vurdere hele behandlingskæden, ikke kun om rådata flyttes.

Hvordan adskiller metoden sig fra centraliseret machine learning?

I centraliseret machine learning samles data normalt i et fælles miljø, hvor modellen trænes. Det giver nemmere adgang til datarensning, analyse, fejlfinding og samlet evaluering. Ulempen er, at data skal flyttes, kopieres eller replikeres, hvilket kan øge risiko, kompleksitet og governance-krav.

I federated learning bliver træningen distribueret. Serveren ser normalt kun de indsendte modelopdateringer og den samlede model, ikke de lokale datasæt. Det ændrer arbejdsdelingen mellem dataejere og modelansvarlige.

Forskellen kan sammenfattes sådan: centraliseret læring flytter data til modellen, mens federated learning flytter modellen til data. Begge tilgange er former for kunstig intelligens, men de har forskellige krav til infrastruktur, kontrol og kvalitetssikring.

Hvornår giver federated learning mening?

Federated learning giver bedst mening, når flere lokale datasæt tilsammen kan forbedre en model, men hvor fuld datadeling er upraktisk eller uønsket. Det gælder især, hvis data er fordelt på mange kilder, og hvis den ønskede model kan lære af lokale mønstre uden at kræve manuel inspektion af hvert datasæt.

En organisation bør typisk overveje metoden, når mindst tre forhold er opfyldt: data kan ikke nemt samles, lokale parter kan afvikle træning stabilt, og en fælles model skaber en tydelig gevinst i forhold til lokale modeller.

• Brug metoden, når dataminimering, lokal kontrol eller samarbejde mellem uafhængige parter er en væsentlig arkitekturbetingelse.
• Vælg centraliseret træning, hvis data kan samles lovligt, sikkert og praktisk, og hvis central kvalitetskontrol er vigtigere end lokal databevarelse.
• Vælg lokale modeller, hvis hver part har nok data til at træne sin egen model, og en fælles model ikke giver tilstrækkelig ekstra værdi.

Hvilke tekniske udfordringer skal løses?

Kommunikation er en af de største udfordringer. En model kan have mange millioner parametre, og hver træningsrunde kan kræve upload og download mellem server og klienter. Den oprindelige forskning i Federated Averaging fokuserede netop på at reducere antallet af nødvendige kommunikationsrunder.

Klienter er heller ikke altid tilgængelige. En telefon kan være offline, et hospitalsmiljø kan have vedligeholdelsesvinduer, og et edge-system kan have begrænset beregning. Systemet skal kunne håndtere klientudfald uden at ødelægge træningen eller skabe bias i den fælles model.

Derudover kræver federated learning overvågning af modelversioner, lokale træningsmiljøer, datafordeling, opdateringsstørrelser og fejltilstande. Det er sjældent nok at implementere en træningsalgoritme. Man skal også kunne drive den som et distribueret system.

Hvordan påvirker uens data modelens kvalitet?

Federated learning arbejder ofte med data, der ikke er ens fordelt mellem klienter. Det kaldes ofte non-IID data. En brugers tastaturhistorik, et hospitals patientgrundlag eller en fabriks sensordata kan afspejle lokale forhold, som ikke ligner gennemsnittet.

Uens data kan gøre modellen sværere at træne. Nogle klienter kan have meget lidt data, andre kan have skæve mønstre, og visse deltagere kan mangle hele datatyper. Aggregationen kan derfor komme til at favorisere dominerende klienter eller gennemsnit, der ikke fungerer godt for mindre grupper.

Det hænger tæt sammen med forskellen mellem supervised og unsupervised learning. Hvis lokale labels, kategorier eller målemetoder varierer, skal modeldesign og evaluering tage højde for, at læringssignalet ikke er ens på tværs af deltagere.

Hvilke sikkerhedstiltag hører typisk med?

Secure aggregation er et centralt sikkerhedslag i mange federated learning-designs. Ideen er, at serveren kan beregne en samlet opdatering uden at kunne inspicere hver enkelt klients bidrag. Det reducerer risikoen ved individuelle opdateringer, men det erstatter ikke anden sikkerhed.

Differential privacy kan bruges til at begrænse, hvor meget en enkelt datapost kan påvirke den samlede model. Det kan dog påvirke modelkvaliteten, hvis støjen bliver for kraftig. Kryptering, signering, klientattestation og adgangsstyring kan beskytte kommunikationen og deltagernes identitet.

Modelrobusthed kræver også forsvar mod forgiftning, outliers og bevidst manipulerede opdateringer. Hvis du vurderer et federated learning-projekt, bør sikkerhedsdesignet dække både privatliv, integritet, tilgængelighed og ansvar for hændelser.

Hvordan hænger metoden sammen med GDPR og dataminimering?

Federated learning kan understøtte dataminimering, fordi rå træningsdata ikke nødvendigvis samles hos en central part. Det passer godt med tanken om, at personoplysninger skal begrænses til det, der er nødvendigt for formålet. Det er dog ikke det samme som en automatisk GDPR-løsning.

Hvis lokale data er personoplysninger, skal organisationen stadig have styr på formål, behandlingsgrundlag, rollefordeling, sikkerhedsforanstaltninger, databehandlerforhold, dokumentation og rettigheder. En modelopdatering kan også være relevant i en databeskyttelsesvurdering, hvis den kan knyttes til personer eller grupper.

For danske og europæiske organisationer er en praktisk tilgang at behandle federated learning som et designvalg i dataarkitekturen. Metoden kan reducere nogle risici, men den skal vurderes sammen med GDPR for AI-træningsdata, sikkerhed og governance.

Hvordan kan en organisation vurdere om federated learning er det rigtige valg?

Start med databehovet. Hvis modellen kun bliver marginalt bedre af flere lokale datasæt, kan federated learning være unødigt komplekst. Hvis gevinsten derimod afhænger af data, som ikke kan flyttes forsvarligt, bliver metoden mere relevant.

Dernæst bør du vurdere driftsmodellen. Hvem ejer den globale model? Hvem godkender klienter? Hvordan håndteres dårlige opdateringer? Hvem kan revidere træningsforløbet? Hvilke krav stilles til versionering, test og dokumentation?

1. Afklar, om rådata faktisk skal blive lokalt, eller om en central løsning er mulig med lavere kompleksitet.
2. Undersøg, om lokale klienter har nok datakvalitet, beregning og netværksstabilitet til at deltage.
3. Fastlæg sikkerhedslag for transport, aggregering, klientkontrol og modelrobusthed.
4. Definer målinger for modelkvalitet på tværs af grupper, ikke kun et samlet gennemsnit.
5. Dokumentér ansvar, formål og ændringer, så modellen kan forklares og kontrolleres efter træning.

Hvilke kilder ligger til grund?

Definitionen og den tekniske grundmodel bygger på Google Researchs forklaring af federated learning uden centraliserede træningsdata og på AISTATS 2017-artiklen om decentraliseret træning. De bredere begrænsninger og åbne problemer er kontrolleret mod oversigtsartiklen Advances and Open Problems in Federated Learning. Afsnittet om sikker aggregering bygger på Google Researchs publikation om secure aggregation, og dataminimering er holdt op mod EUR-Lex’ tekst om GDPR.