Es gibt bereits verschiedene Anleitungen und Literatur zur Planung und Aufsetzen eines Federated Learning (FL)-Projekts. Dabei handelt es sich jedoch vor allem um wissenschaftliche Arbeiten, für die praktische Unterstützung bei der Planung eines FL-Projekts ist dagegen kaum etwas zu finden. Deshalb richtet sich die nachfolgende Anleitung an Administratoren, Organisatoren und Manager kleinerer Organisationen wie KMU zur Planung einer FL-Lösung beginnend mit der Auswahl eines Frameworks, über den Aufbau eines Netzwerks bis zum verteilten Training.

Referenzen

• Einführung in Federated Learning im industriellen Kontext
• Whitepaper „Federated Learning für erfolgreiche KI- und Data-Science-Projekte“ (PDF)
• Fraunhofer ITWM: Fed-DART – Distributed Analytics Runtime for Federated Learning
• Research Paper „Fed-DART and FACT: A solution for Federated Learning in a production environment“ (PDF)

Vorkenntnisse

Wir gehen davon aus, dass Ihre Organisation über ausreichend Grundwissen verfügt, um den Einsatz eines ML Verfahrens zu planen. Falls das benötige Fachwissen nicht vorhanden ist, empfehlen wir zusätzliche Experten heranzuziehen, insbesondere aus den Bereichen Data Science, Informatik oder Betriebswirtschaft. Sie können auch Partner aus dem FedXtract Projekt ansprechen, um Beratungsleistung einzuholen. Sollte sich abzeichnen, dass die Erfolgsaussichten für Ihre Idee nicht hoch genug sind, können Sie überlegen, ob alternative ML/DL Verfahren oder weitere Datenquellen einbezogen werden können.

Grundvoraussetzungen

Die nachfolgende Betrachtung richtet sich an beliebige Branchen und Bereiche wie Healthcare, Finanzen, Wissensmanagement, Marketing, Medien oder Industrie. Voraussetzung ist lediglich, dass Sie vor Geschäftsproblemen stehen, die durch ML-Verfahren mit Trainingsdaten gelöst werden können, die nicht zentral verfügbar sind sondern nur verteilt vorliegen. An dieser Stelle sollte auch bereits geprüft werden, ob die Aufgabenstellung mit einem ML-Verfahren unter den gegebenen Voraussetzungen an Datenmenge und Qualität aussichtsreich ist. Dabei solle man auch abschätzen, ob durch das Projekt ein Mehrwert entsteht und sich die Aufwände für die Einführung des neuen Verfahrens amortisieren können.

Die eigentliche Auswahl eines geeigneten ML-Verfahrens möchten wir im vorliegenden Dokument nicht näher betrachten, da dies eine Aufgabe für sich ist, die i.d.R. von einem Data Scientist zu leisten ist. Dazu sind für eine Aufgabenstellung die aussichtsreichsten ML/DL-Methoden auszuwählen, aus denen nach dem verteilten Training die effizienteste ausgewählt wird. Zur Auswahl von ML/DL-Methoden gibt es eine Reihe von Studien (s.u.). Dabei sollte auch eine Abschätzung vorgenommen werden, welche Datenmengen für die jeweiligen ML/DL-Methoden von den verschiedenen Clients mindestens erforderlich sind. Dabei gilt die Regel, dass mit der Menge der Trainings-Daten auch die Qualität des Modells sich verbessert, vorausgesetzt, dass die Daten für die adressierte Aufgabenstellung relevant sind und eine ausreichende Qualität haben. Hierbei ist eine horizontale und vertikale Nutzung der Daten möglich. Bei einer horizontalen Verwertung werden Datensätze aus gleichen Bereichen und bei einer vertikalen Verwertung Datensätze aus komplementären Bereichen (z.B. verschiedene Informationen zu einer Person) miteinander verknüpft.

Datenqualität und Verfügbarkeit

Hier stellt sich z.B. die Frage, inwieweit die Korrektheit der Daten gesichert ist, in dem sie vollständig oder teilweise von Experten geprüft wurden. Dies ist insbesondere für Bereiche von Bedeutung, in denen eine hohe Sicherheit gewährleistet werden muss und die unterliegenden Quellen anzugeben sind, wie z.B. im Healthcare-Bereich.  Zudem ist zu berücksichtigen, wie regelmäßig die Daten in welchem Umfang zur Verfügung stehen werden und sich auf die Clients verteilen. Hierbei ist die Aufstellung in einer Tabelle hilfreich, auf deren Basis das verteilte Training geplant werden kann und ggf. entscheidbar ist, ob einzelne Clients herausgenommen oder noch neue gewonnen werden sollten.

Je nach Ziel und Geschäftsmodell des Projektes kann es sinnvoll sein, vertragliche Absicherungen mit allen Pflichten und Rechten auf die Ergebnisse sowie Kosten- und Abrechnungsmodell festlegen.

Referenzen

• Überblick über Deep Learning-Frameworks
• Research Paper: „Fast-Convergent Federated Learning with Adaptive Weighting“ (PDF)
• Research Paper: „A systematic review of federated learning from clients’ perspective: challenges and solutions“ (PDF)

Nach oben

Die Auswahl eines geeigneten KI-Modells sollte anhand verschiedener Gesichtspunkte erfolgen. Einerseits muss entschieden werden, ob ein Open-Source-Modell verwendet werden soll, was unter Umständen die kommerzielle Nutzung einschränkt. Dies läuft letztlich auch auf die Frage hinaus, ob zur Modellentwicklung keine Kosten anfallen sollen, oder ob zugunsten einer höheren Qualität der Ergebnisse Lizenz- und Beratungskosten in Kauf genommen werden sollen. Da sich die KI-Modelle permanent weiterentwickeln und sehr schnell neue Modelle hinzukommen, ist es wichtig bei der Auswahl einer geeigneten Modellarchitektur zu recherchieren, was aktuell verfügbar ist. Die Auswahl sollte außerdem anhand der verfügbaren Trainingsdatenmenge erfolgen. Hat man nur wenige Trainingsdaten zur Verfügung muss man nicht zwingend auf kleinere Modelle zurückgreifen. Es ist auch möglich ein Fine-Tuning von öffentlich verfügbaren und bereits vortrainierten größeren Modellen vorzunehmen.

Referenzen

• Blogbeitrag: „Was sind Large Language Models? Und was ist bei der Nutzung von KI-Sprachmodellen zu beachten?“
• The best large language models (LLMs) in 2024
• 7 Best Image Classification Models You Should Know in 2023
• Top Instance Segmentation Models

Nach oben

Die verfügbaren Frameworks zum Aufsetzen und Betrieb einer FL Systems entwickeln sich ebenfalls ständig weiter, wenn auch nicht so dynamisch wie die KI-Modelle. Wir haben die in 2023 am weitesten verbreitetsten Frameworks untersucht und bewertet. Da bereits mehrere führende Technologieanbieter wie Google, Intel, Nvidia, IBM vertreten sind, ist nicht zu erwarten, dass es sehr viele neue Anbieter geben wird. Allerdings können wir beobachten, dass diese Technologie noch nicht etabliert ist und alle Frameworks ständig weiter entwickelt werden. Die nachfolgend zusammengestellten Vorgehensvorschläge können mindestens mit allen von uns untersuchten Frameworks, die wir mit mehr als 2 Punkten bewertet haben, umgesetzt werden.

Für unseren Prototyp zur Validierung haben wir das Nvidia Framework ausgewählt, da dies zu diesem Zeitpunkt am weitesten ausgereift war. Ein Vorteil dieses FL Frameworks ist, dass es über einen Simulator verfügt, sodass auch Konfigurationen mit vielen Clients und unterschiedlicher Datenverteilung getestet werden können, die in einem physisch verteilten Netzwerk sehr aufwändig wären.

Referenzen

• Evaluation von neun FL-Frameworks im Rahmen des FedXtract-Projekts

Nach oben

Für den Aufbau des Trainingsnetzwerks sind die Verbindungen zwischen den beteiligten Servern und Clients einzurichten und die Firewalls für die benötigen Zugriffe und Datenaustausch zu konfigurieren. Dies sollte durch die Netzwerk-Administratoren der beteiligten Partner erfolgen, da DNS-Einträge und IP-Ranges festzulegen sind und Ports freigegeben werden müssen.

Datenschutz und Sicherheit

Beim föderierten Lernen können verschiedene Unternehmen gemeinsam ein Modell trainieren und voneinander profitieren ohne die eigenen, sensiblen Daten miteinander zu teilen. Deswegen ist der Datenschutz beim föderierten Lernen ein wichtiger Aspekt. Die Privatsphäre föderierter Modelle kann mittels Metriken wie differentialer Privatsphäre bewertet werden, die die Menge an Informationen über einzelne Instanzen in den Trainingsdaten angibt. Selbst wenn die Daten an sich nicht miteinander geteilt werden, ist es unter Umständen dennoch möglich aus den Gewichten des Modells oder Metriken Rückschlüsse auf die Daten zu ziehen. Mögliche Lösungsansätze sind hier Differential Privacy oder homomorphe Verschlüsselungen. Der Datenschutz ist eine eigene komplexe Herausforderung, die vom FL Framework abgedeckt sein sollte, deshalb werden wir darauf hier nicht näher eingehen.

Referenzen

• Research Paper: „Shielding Federated Learning: A New Attack Approach and Its Defense“ (PDF)
• Research Paper: „A review of secure federated learning: Privacy leakage threats, protection technologies, challenges and future directions“
• Federated Learning: Jeder profitiert vom Wissen des AnderenTop Instance Segmentation Models
• Research Paper: „Federated Learning with Differential Privacy: Algorithms and Performance Analysis“ (PDF)
• Research Paper: „FedML-HE: An Efficient Homomorphic-Encryption-Based Privacy-Preserving Federated Learning System“ (PDF)

Nach oben

Für das Training sollte man abschätzen, wie die Daten über die Clients verteilt sind. Über die Aufteilung der Daten haben wir hinsichtlich einer heterogenen und homogenen Verteilung bereits in Abschnitt s.o. gesprochen. Dabei steht man zunächst vor der Frage, wie man die aktuelle Aufteilung der Daten identifizieren kann. Im günstigen Fall stellt der Produzent oder Owner der Daten bereits Informationen über Aufteilung bereit. Ansonsten gibt es bei gelabelten Daten, d.h. wenn bereits eine Klassifikation erfolgt ist, die Möglichkeit anhand der Labels die Aufteilung abzuschätzen. Zudem kann man durch manuelle Stichproben den Inhalt der Daten abschätzen, eine umfassende manuelle Analyse wird i.d.R. aufgrund der Datenmenge nicht möglich sein. Eine weitere Option besteht darin, ein Tool zu implementieren, mit dem die Aufteilung abgeschätzt werden kann.

Für das Training werden die vorhandenen Daten in Trainings-, Validierungs- und Testdaten aufgeteilt. Dafür ist klassischerweise ein Verhältnis von 80 zu 10 zu 10 üblich. Bei großen Datenmengen können Validierungs- und Testmenge auch kleiner ausfallen. Wichtig ist, dass die ausgewählte Datenmenge die zugrundeliegende Verteilung repräsentiert, da sonst die Evaluationsergebnisse nicht zielführend sind. Bei unbalancierten Daten, also wenn eine Klasse gegenüber einer anderen deutlich über repräsentiert ist, besteht die Gefahr, dass das Modell einen Bias gegenüber der überrepräsentierten Klasse lernt. In diesem Fall kann man die Trainingsdaten so auswählen, dass beide Klassen gleich balanciert sind.

Zum verteilten Training erfolgt die Aufteilung pro Client mit seinen häufig vertraulichen Daten.

Referenzen

• Train Test Validation Split: How To & Best Practices [2023]
• Introduction to Balanced and Imbalanced Datasets in Machine Learning
• Balancing Act: Classification with Imbalanced Data

Nach oben

Da die aktuellen KI-Modelle oft sehr groß und die Daten für das ML/DL-Training häufig auch sehr umfangreich sind, sollte man abschätzen, wie viel Speicher benötigt wird, benötigt man 64 GB, 128 GB oder mehr RAM ? Ansonsten wird voraussichtlich die Lauffähigkeit oder Performance beeinträchtigt. Falls der benötigte Speicher nicht von vornherein gut abgeschätzt werden kann, ist es sinnvoll keine eigene Infrastruktur zu nutzen, sondern Cloud Services zu verwenden, da diese dynamisch skalierbar sein. D.h. man kann klein anfangen und bei Bedarf erhöhen. Bei einer eigenen Infrastruktur kann es sein, dass man den Bedarf überschätzt, sodass unnötige Kosten anfallen, oder unterschätzt , sodass man mühsam nachlegen muss. Die Bereitstellung der Cloud-Services erfolgt i.d.R. durch die Netzwerk-Administratoren, da hierzu verschiedene Credentials und Konfigurations-Parameter benötigt werden.

Nach oben

Für die Entwicklung von Modellen mit FL durch Training von Modellen auf dezentralen Datenquellen wird eine geeignete Evaluation erforderlich. Dazu gehört ein Bewertungsrahmen, der Metriken zur Messung der Qualität der gelernten Modelle sowie Metriken zur Bewertung der Leistung des föderierten Lernprozesses selbst, wie z. B. Kommunikations-Overhead und Datenschutz, umfasst. Der Bewertungsrahmen für föderierte Lernsysteme sollte mehrere Aspekte berücksichtigen, darunter Modellqualität, Genauigkeit, Kommunikationsaufwand und Datenschutz. Die Evaluation sollte zeigen, dass die vorgesehenen Metriken die Leistung von föderierten Lernsystemen effektiv bewerten und die Kompromisse zwischen den verschiedenen Aspekten wie Datenschutz und Kommunikationsaufwand angemessen sind.

Zentrale und verteilte Evaluation

Wenn zentrale Trainingsdaten zur Verfügung stehen, kann zunächst eine zentrale Validierung des entstehenden Modells auf dem Server vorgenommen werden. Häufig dürfen Clients ihre Daten jedoch nicht herausgeben, sodass nur eine verteilte Evaluierung möglich ist. Für ein Monitoring des föderierten Trainings ist in jedem Fall eine verteilte Evaluation sinnvoll. Denn nur so kann die Konvergenz des  zentralen Modells verfolgt werden, und bewerten werden, wie gut die Modellaktualisierungen von verschiedenen Clients miteinander übereinstimmen. Da jeder Client verschiedene Daten nutzt, verändert er das Modell nur partiell und kann zunächst auch nur sein neu generiertes Modell bewerten. Die Konvergenz der sich weiter entwickelnden verteilten Modelle aller Clients kann durch Bewertung der Varianz oder Verteilung der Modellparameter oder die Überwachung der Änderung von Genauigkeit und Verlust mit fortschreitenden Epochen bewertet werden.

Aggregationsalgorithmen

Eine wichtige Rolle für die Qualität des entstehenden föderierten Modells spielen die Aggregationsalgorithmen zur Zusammenführung der neuen Gewichtungen aller Clients. Hier gibt es zunächst einfache Verfahren wie FedAvg die den Durchschnitt der zurückgelieferten Werte aller Clients verwenden. Komplexere Verfahren wie FedProx bestrafen Werte, die sehr weit vom globalen Modell abweichen oder Verfahren, die mit der Zeit dazulernen wie FedOpt. Die Auswahl eines Verfahrens hängt von der Verteilung der Trainingsdaten ab, hier sich z.B. gezeigt, dass mit mit wachsender Heterogenität der Daten komplexere Aggregationsalgorithmen wie Scaffold bessere Ergebnisse erzielen.

Metriken

Die Genauigkeit des gemeinsamen zentralen Modells und der verteilten Modelle wird mit ihren Validierungs- und Testdatensätzen bewertet. Für die Genauigkeit kann zwischen verschiedenen Metriken gewählt werden. Die Auswahl der Metriken hängt von der Art des Problems ab. Bei Klassifikationsproblemen nimmt man z.B. Precision, Recall, F1-Score oder ROC AUC, wohingegen bei Regressionsproblemen typischerweise MAE, MSE, RMSE oder R-Quadrat verwendet werden und bei Segmentierungsproblemen die IoU. Jeder Client kann lokal bei sich die ausgewählten Metriken berechnen und so die Vorhersagegüte des Modells auf seinen Daten bewerten. Die Bewertung des globalen Modells kann, falls vorhanden, anhand eines globalen Testdatensatzes bewertet werden oder die Metriken müssen über die einzelnen Clients aggregiert werden.

Nach oben

Es gibt eine Reihe von Tools zur Visualisierung der Trainingsergebnisse wie TensorBoard (TensorBoard|TensorFlow ) , Weights & Biases, Neptune, Guild AI, Sacred, oder Comet. Sie erlauben ein Monitoring der Trainingsergebnisse und bieten Werkzeuge zur Visualisierung die für maschinelles Lernen benötigt werden:

• Verfolgung und Visualisierung des Trainings- und Validierungsverlustes (Loss) sowie von zusätzlichen sinnvollen Metriken

• Visualisierung der Modellarchitektur

• Betrachten von Histogrammen von Gewichten, Verzerrungen oder anderen Tensoren, wie sie sich über die Zeit verändern

• Falls das Modell Embeddings/Einbettung erstellt: Projizieren von Einbettungen in einen niedrigdimensionalen Raum, um zu überprüfen, ob sich sinnvolle Cluster bilden

• Anzeigen von Bildern, Text und Audiodaten

• Profiling von TensorFlow-Programmen.

Die verschiedenen FL-Frameworks bieten i.d.R. eine Einbindung von mindestens einem dieser Visualisierungstools an.

Ein typischer Weg, ein Monitoring mit dem Tensorboard – eines der führenden Tools – zu nutzen, besteht darin, dass alle Clients ihre Logs an den Server senden, der dann die Entwicklung aller Client-Modelle und das zentrale Modell mit den ausgewählten Metriken wie Verlust und Genauigkeit anzeigen kann (vgl. Experimenting with Novel Distributed Applications Using NVIDIA Flare 2.1).

Referenzen

• Research Paper: „Evaluation Framework for Large-Scale Federated Learning“ (PDF)
• Research Paper: „Reviewing Federated Learning Aggregation Algorithms; Strategies, Contributions, Limitations and Future Perspectives“ (PDF)
• Research Paper: „MHAT: An efficient model-heterogenous aggregation training scheme for federated learning“

Nach oben

Die Planung des Projektes beginnt mit der Auswahl der genannten Methoden und Parameter wie ML/DL- und FL Framework. Zudem sind die Hyperparameter der Modell-Architektur mit Anzahl und Größe der verschiedenen Layer, verschiedene Regularisierungsparamter und Lernrate bzw. Lernstrategie festzulegen und die technischen Infrastruktur mit Server, Clients und deren Vernetzung bereitzustellen. Folgende Schritte erfolgen iterativ um das Modell im Training schrittweise zu verfeinern:

1. Zu den Daten und Parametern, die iterativ immer weiter verbessert werden, gehören die Auswahl der Trainingsdaten, die Clients und Trainingsparameter wie Anzahl der Epochen.

2. Nach dem Starten des Trainings sollte ein Monitoring erfolgen, so dass durch Trace-Ausgaben auf der Konsole und dem Monitoring von Zwischenergebnissen mit einem Visualisierungstool verfolgt werden kann, in wie weit ein Trainingslauf erfolgreich abgeschlossen wurde. Dabei sollte das Monitoring sowohl auf dem Server – für das aggregierte zentrale Modell – wie auch auf jedem Client – für das Training der lokalen Modelle – erfolgen.

3. Dadurch wird erkennbar, ob die Konfiguration korrekt aufgesetzt wurde und sinnvolle Zwischenergebnisse geliefert werden. Im Verlauf des Trainings sollten sowohl Trainings- wie auch Validierungsverlust sinken. Sinkt der Trainingsverlust nicht, lernt das Modell keine Zusammenhänge, was z.B. an fehlerhaften Labeln oder ungeeigneter Modellparameter liegen kann. Sinkt nur der Trainingsverlust, aber nicht der Validierungsverlust ist dies ein Zeichen für sogenanntes Overfitting. Das Modell lernt dann die Zusammenhänge in den Trainingsdaten zu gut, kann aber nicht auf unbekannte Daten im Validierungsdatensatz generalisieren. Dieses Problem lässt sich durch verschiedene Regularisierungsansätze lösen.

4. Wenn die Zwischenergebnisse generell richtig aussehen, ist zu prüfen, ob sich die Qualität des zentralen Modells mit fortschreitendem Training immer weiter verbessert und konvergiert. Eine finale Prüfung könnte sein, dass das Modell mit den Testdaten akzeptable Ergebnisse liefert.

5. Wenn die Ergebnisse nicht akzeptabel sind, kann das Training mit veränderten Einstellungen wiederholt werden. Dabei gibt es die folgenden Möglichkeiten 

• mehr oder andere Trainingsdaten zu verwenden (z.B. balancierte Daten, Datenaugmentierung)

• die Anzahl Clients zu anzupassen ; z.B. könnten Clients, die stark abweichende Werte liefern herausgenommen werden.

• Hyperparameter (Lernrate, Regularisierung) anpassen

• Architektur anpassen

• andere Funktion für den Loss wählen

6. In der Regel sollte sich irgendwann das Modell bei weiteren Epochen und Vergrößern der Trainingsdatenmenge nicht mehr wesentlich ändern.

Nach oben

• Aktualität: Die Modelle werden anhand von realen Trainingsdaten aus dem Anwendungsbereich ständig verbessert, ohne dass die Daten für kontinuierliches Lernen zentral aggregiert werden müssen.

• Flexibilität: Finetuning mit FL ermöglicht es, das Model an die sich verändernde Bedingungen anzupassen, die bei der ersten Erstellung des Modells noch nicht bekannt waren. Das Modell kann für neue Aufgaben eingesetzt werden, ohne dass es von Grund auf neu erstellt und trainiert werden muss. Dabei trainieren mehrere Clients ein universales Modell gemeinsam, welches sie dann für ihre eigenen Belange noch weiter nachtrainieren können.

• Nachhaltigkeit: FL erlaubt die Ausnutzung der Kapazität vieler ohnehin vorhandener Geräte. Dabei kann die verfügbare Rechenleistung und Speicherplatzbedarf auf jedem Gerät deutlich geringer sein, als bei einem zentralen Training.

• Skalierbarkeit: FL ermöglicht bei steigendem oder sinkendem Volumen an Trainingsdaten und Rechenleistung eine Anpassung der eingebundenen Clients

Nach oben