Eine Einführung in Federated Learning im industriellen Kontext: Grundlagen

Mithilfe von Daten können Unternehmen fundiertere Entscheidungen treffen, ihre Arbeitsabläufe optimieren und mit der Kraft des maschinellen Lernens (ML) einen Vorteil in der wettbewerbsintensiven Geschäftswelt erlangen. Allerdings ist der Umgang mit Daten im Laufe der Jahre zunehmend schwierig geworden. Heute stehen Unternehmen vor der Herausforderung, sich an ständig wechselnde regulatorische und Cybersicherheitsanforderungen anzupassen und gleichzeitig die Privatsphäre der Dateneigentümer zu gewährleisten. Aufgrund dieser Herausforderungen haben viele Branchen noch immer begrenzten Zugang zu den Spitzentechnologien des 21. Jahrhunderts im Bereich Daten.

Was können wir also dagegen tun? Nun, wenn wir die Daten nicht zum Machine-Learning-(ML) Modell bringen können, wie wäre es dann, wenn wir die ML-Modelle zu den Daten bringen? Genau das versucht Federated Learning zu erreichen. Das wollen wir uns einmal genauer im industriellen Kontext ansehen.

Federated Learning setzt sich daraus zusammen, die maschinellen Lernoperationen von der Cloud auf Edge-Geräte zu verlagern und lokal mit den Daten zu interagieren. Die beiden grundlegenden Komponenten des Federated Learning sind Server und Client. Unten siehst du die grundlegenden Schritte eines Federated Learning:

Wie in der Grafik (Arbeit des Autors) dargestellt, beginnen wir mit der Initialisierung eines globalen Modells. Wir senden dieses Modell dann an die einzelnen Clients, die es mit ihren lokalen Daten trainieren. Später senden diese Clients ihre Updates an den Server zurück, wo sie aggregiert werden. An diesem Punkt ist eine Iteration abgeschlossen und wir gehen zurück zum ersten Schritt – der Server sendet das aktualisierte globale Modell zurück an die Clients und der gesamte Prozess beginnt von vorn.

Das ist das grundlegende Prinzip von Federated Learning! Wie du dir denken kannst, steckt hinter jedem Punkt in dem Diagramm oben aber noch viel mehr. Die großen Konzepte beinhalten: Strategie, Techniken zur Verbesserung der Privatsphäre (engl. PETs) und sichere Mehrparteienberechnung (engl. SMPC). Das Ziel dieser Artikelserie, die aus 2 Blogbeiträgen besteht, ist es, einen grundlegenden Überblick über diese Themen zu geben und wie jedes von ihnen sich auf Federated Learning bezieht.

Strategie für federated learning

Was ist dann eine „Strategie“ im Kontext von Federated Learning? Eine Strategie ist der Versuch, den effektivsten Weg zu finden, das Modell zu trainieren und die Gewichte zu aggregieren. Gewichte sind die „Erkenntnisse“ des Modells aus dem Training. Denken wir einmal über die Client-Auswahl nach und nehmen an, dass wir 1000 Clients haben. Sollten wir alle Clients auswählen, wenn wir das Training starten? Mehr Clients bedeuten zwar in der Regel mehr Daten, aber sind mehr Daten immer besser für unser ML Modell? Forschungen haben gezeigt, dass das Nutzen aller Clients häufig zu einer langsameren Konvergenz führen kann, was bedeutet, dass das ML Modell langsamer angelernt wird, als wenn wir weniger Clients mit hochwertigen Datensätzen verwendet hätten (Németh et al. 4).

Eines sollte dabei immer im Hinterkopf behalten werden: Das ist, was die empirische Forschung vorschlägt und keine Regel, also ist es nicht in Stein gemeißelt und alle hier erwähnten Ideen sollten hinterfragt werden, da die beste Strategie stark kontextabhängig ist. Wie wählen wir also die Clients aus, die wir in unserem Aktualisierungsschritt einbeziehen möchten? Nicht alle Clients sind gleich in ihrer Kommunikations- oder Rechenkapazität sowie ihrem Zugang zu den Datenpunkten. Es wurden viele Strategien von der Forschung vorgeschlagen. Einige von ihnen schließen die Priorisierung der Clients mit einzigartigen Datenpunkten ein (Németh et al. 6), während einige vorschlagen, die Clients auf die energieeffizienteste Weise zu wählen (Németh et al. 5).

Jetzt werfen wir einen Blick darauf von der Server-(Aggregator-) Seite. Die Menge der Datenpunkte, die jedem Client zur Verfügung stehen, variiert. Daher haben auch die trainierten Gewichte unterschiedliche „Erfahrungsniveaus“. Ein Modell, das auf 1000 Datenpunkten trainiert wurde, befindet sich in einer anderen Phase als eines, das lediglich 100 Datenpunkte gesehen hat. Wenn wir aggregieren würden, wäre das Modell mit 1000 Datenpunkten stärker auf das globale Modell einflussreich. Um eine gerechtere Verteilung an die Clients zu geben, kann beispielsweise der FedAvg-Algorithmus verwendet werden, um die Modellupdates, die von den Clients kommen, zu mitteln.

Im obigen Diagramm (Németh et al. 5) kannst du die breite Palette von Ideen sehen, die im Laufe der Jahre von den Forschern vorgeschlagen wurden.

Proof of Concept: Predictive Maintenance

Bevor wir weitermachen, möchte ich einen Proof of Concept vorstellen, an dem ich gearbeitet habe, der sich auf Predictive Maintenance bezieht und warum es ein wichtiges Thema ist, das Federated Learning lösen kann.

Bedeutung von KI-gestützter Predictive Maintenance

Maschinen sind das Herzstück der Industrie und ihre Ausfallzeiten sind mit erheblichen Kosten verbunden. Predictive Maintenance bezieht sich auf das Konzept, den Ausfall von Maschinen vorherzusagen und Wartungsarbeiten durchzuführen, bevor sie ausfallen. Laut einer Studie von McKinsey & Company kann mit Hilfe von künstlicher Intelligenz „die Verfügbarkeit in einigen Fällen um mehr als 20% steigen. Die Inspektionskosten können um bis zu 25% reduziert werden und eine generelle Reduzierung der jährlichen Wartungskosten um bis zu 10% ist möglich.“ (McKinsey & Company, Inc. 8).

Das eigentliche Problem jedoch ist die begrenzte Datenverfügbarkeit für einzelne Fabrikbesitzer. Wie oft fallen moderne Maschinen tatsächlich aus? Vielleicht einmal oder zweimal im Monat? Und wie oft haben diese Ausfälle die gleiche Ursache? Mit nur einer geringen Anzahl von Maschinen, die jeder Organisation zur Verfügung steht, wird es schwierig sein, genügend qualitativ hochwertige Ausfalldaten zu sammeln.

In einer traditionellen ML-Umgebung könnten wir nach Anerkennung des Mangels an ausreichenden Daten nach ähnlichen Daten außerhalb unserer Organisation suchen. Verständlicherweise zögern Fabrikbesitzer jedoch, ihre Daten mit externen Organisationen zu teilen - ein schwieriges Szenario für konventionelles ML, jedoch nicht so sehr für das föderierte Lernen, da es einer großen Anzahl von Maschinen ermöglicht, zu einem größeren zentralen ML-Modell beizutragen, während gleichzeitig die Privatsphäre gewahrt bleibt.

Implementierung

Wir haben das Framework Flower gewählt, da es sehr anfängerfreundlich ist und eine ziemlich aktive Community hat, die bereit ist, bei Diskussionen und Fragen zu helfen. Wir haben den „Machine Predictive Maintenance Classification"-Datensatz von Kaggle verwendet. Es handelt sich um einen synthetischen Datensatz und daher ist nicht viel Vorverarbeitung erforderlich. Der Datensatz wurde in kleinere Teile unterteilt, sodass jeder Kunde einen einzigartigen Teilbereich zur Verfügung hatte, um das Modell lokal zu trainieren. Werfen wir einen genaueren Blick auf den Server und die Client-Seite.

Server-Seite

Auf der Server-Seite definierst und kompilierst du zuerst das Modell, wie du es normalerweise tun würdest. Als Strategie haben wir FedAvg gewählt, das jedem Client einen gleichen Einfluss auf das globale Modell gibt, wenn die Modelle aggregiert werden. Es gibt bessere Strategien, aber seine Einfachheit macht es für unseren Proof of Concept ziemlich gut. Als Anfangsparameter übergeben wir zufällige Werte, aber in einem realen Anwendungsfall kannst du einen Client bitten, dir die Anfangsgewichte zu geben, damit du realistischere Startgewichte hast, was wiederum eine schnellere Konvergenz bedeutet.

Anhand des Bildes (Arbeit des Autors) kannst du erkennen, was der Server ausgibt und welche Prozesse er durchläuft. Wie du sehen kannst, befolgt der Server nach der Initialisierung die Schritte, die wir zuvor erwähnt haben. In jeder Runde wählt er eine Gruppe von Clients für das Training (fit_rounds) aus, fasst die Daten zusammen und liefert dann eine Bewertung für diese Runde.

Client-Seite

Auf der Client-Seite verwenden wir dieselbe Modell-Architektur, da es unmöglich wäre, die Gewichtungen zu aggregieren, ohne zu wissen, zu welcher Modell-Architektur sie gehören. Die Gewichtungen können als Materialien zum Bau eines Gebäudes betrachtet werden. Ohne den Bauplan (die Modell-Architektur) des Gebäudes wäre es unmöglich, die Materialien an den richtigen Positionen zu platzieren.

Aus dem Bild (Arbeit des Autors) kann man erkennen, dass der Client zuerst eine Verbindung zum Server herstellt. Danach trainiert er das Modell mit lokalen Daten und zeigt auch an, wie das Modell mit diesen Daten abschneidet.

Fazit

Federated Learning ist ein faszinierendes Konzept, das nicht nur aus technischer Sicht interessant ist, sondern auch aus geschäftlicher Sicht. Die Idee, Modelle direkt auf den verteilten Datenquellen der Nutzer zu trainieren, ermöglicht es, datenintensive ML-Anwendungen in Bereiche zu erweitern, die zuvor aufgrund von Datenschutzbedenken oder begrenztem Datenzugang ausgeschlossen waren. Im nächsten Blogbeitrag werden wir uns mit den fortgeschrittenen Techniken und bekannten Problemen von Federated Learning befassen.

References:

1. Németh, Gergely Dániel, et al. "A Snapshot of the Frontiers of Client Selection in Federated Learning." Transactions on Machine Learning Research, 2022, https://openreview.net/forum?id=vwOKBldzFu

2. McKinsey & Company, Inc. Smartening up with Artificial Intelligence (AI) - What’s in it for Germany and its Industrial Sector? Digital McKinsey, 2017, www.mckinsey.com/~/media/mckinsey/industries/semiconductors/our%20insights/smartening%20up%20with%20artificial%20intelligence/smartening-up-with-artificial-intelligence.ashx . Accessed 24 July 2023.