Mittlerweile haben Sie eine Vorstellung von der Tragweite des Datenschutzproblems und fragen sich wahrscheinlich – sofern es Ihnen ähnlich wie mir ergeht –, warum Unternehmen überhaupt so viele Daten erheben. Gibt es denn keinen besseren Weg?
In der Tat, den gibt es! Das sogenannte Federated Learning sowie Distributed Data Science bieten neue Möglichkeiten, Datenanalysen durchzuführen, indem die Daten direkt am Edge1 gehalten bzw. auf den Endgeräten gespeichert werden: auf Smartphones, Laptops, in Edge-Services – oder sogar in einer On-Premise-Architektur (d.h. auf eigenen Servern) bzw. in einer separaten Cloud-Architektur im Rahmen der Zusammenarbeit mit Partnern. Die Daten werden nicht gesammelt oder in Ihre eigene Cloud oder Ihren Speicher kopiert, bevor Sie eine Analyse oder ein Machine Learning durchführen.
In diesem Kapitel erfahren Sie, wie sich das in der Praxis umsetzen lässt und in welchen Fällen dieser Ansatz für einen bestimmten Anwendungsfall geeignet ist. Sie werden anschließend auch beurteilen können, wie Sie beim Federated Machine Learning den Datenschutz gewährleisten können und welche Arten von Daten oder Entwicklungsproblemen mit föderalen Ansätzen gelöst werden können und welche eher nicht.
In der Data Science arbeiten Sie fast immer mit verteilten Daten (engl. Distributed Data). Jedes Mal, wenn Sie einen Kubernetes- oder Hadoop-Cluster starten oder eine Multi-Cloud-Konfiguration für die Datenanalyse verwenden, sind Ihre Daten de facto verteilt. Da das immer mehr zur »Normalität« wird, bedeutet dies, dass verteilte Datenanalysen zunehmend in den Tools und Systemen vorgesehen sind, die Datenexpertinnen und -experten verwenden.
In diesem Kapitel geht es jedoch darum, verteilte Daten der zentralen Verarbeitung zu entziehen. Was wäre, wenn Sie die Daten nicht in Ihren eigenen Rechenzentren, Clouds oder Clustern verteilen, sondern dort belassen, wo sie entstehen, und Ihre Analysen auf Hunderten, Tausenden oder sogar Millionen kleinerer verteilter Datensätze durchführen? Was wäre, wenn Sie niemals Daten aus einer Anwendung, einem Telefon, einem Browser, einer Datenbank oder einer API abrufen würden, die Ihnen nicht gehören, sondern stattdessen die Daten am Edge nutzen und nur die Antworten auf Ihre Analysefragen abrufen würden?
Dieses Kapitel befasst sich mit dieser Art von verteilten Daten. Das ändert die Art und Weise, wie Sie den Datenschutz, die Datenerfassung und Ihre Arbeit als Data Scientist angehen, grundlegend. Im Folgenden erfahren Sie, warum, wann und wie das funktionieren kann.
Wenn Sie verteilte Daten so verwenden, wie es in diesem Kapitel beschrieben wird, verringern Sie Ihr Risiko erheblich. Keine Daten, kein Risiko (oder zumindest: weniger Daten, weniger Risiko).
Dies ist das Grundprinzip der »Datensparsamkeit« (https://oreil.ly/Dnkyg), die ein zentraler Bestandteil vieler Datenschutzgesetze, zahlreicher Datenschutzgrundsätze und einiger Privacy-by-Design-Konzepte ist. Das Prinzip der Datensparsamkeit zwingt Sie, darüber nachzudenken, welche Daten Sie unbedingt benötigen, und nur diese zu erheben. Wenn Sie weniger Daten sammeln, schützen Sie nicht nur die Privatsphäre, sondern sorgen auch dafür, dass Ihr Datenspeicher nicht zur Zielscheibe wird.
Sofern Sie mit Daten in hochsensiblen Umgebungen arbeiten, ist es Ihnen möglicherweise nicht einmal gestattet, Daten aus dem Netzwerk oder der Speicherinfrastruktur zu transferieren. Dies ist häufig der Fall bei hochsensiblen Daten, die sich in lokalen Systemen befinden. In diesen Fällen müssen Sie einen Weg finden, entweder die benötigten Daten sicher zu extrahieren oder mit diesen Systemen zu arbeiten und nur die Ergebnisse Ihrer Analyse oder Verarbeitung zu exportieren. Hier kann Ihnen die föderale bzw. verteilte Analyse (engl. Federated Analysis) helfen, indem die Verarbeitung in diese sicheren Rechenzentren verlagert wird, anstatt Daten aus sicheren in weniger sichere Umgebungen zu extrahieren.
Dieser Fall tritt häufig ein, wenn Sie mit riesigen Datensätzen in mehreren Datenzentren oder Datenspeichersystemen arbeiten. Bei der Verarbeitung über große verteilte Systeme oder Clouds hinweg ist es oft teuer sowie zeit- und rechenintensiv, alle Daten an einen zentralen oder eine Reihe zentraler Dienste zu übertragen. Es ist wesentlich sinnvoller und in Bezug auf die Kosten für Berechnungen und die Cloud weitaus kostengünstiger, die Analyse zu den Daten zu verlagern und nicht umgekehrt.
Es gibt rechtliche Gründe, über die Arbeit mit Daten auf Geräten und am Edge oder dort, wo sie bereits existieren, nachzudenken. Ein zwingender Grund ist die Herausforderung durch transatlantische Datenflüsse. Max Schrems (https://oreil.ly/q3EYO) ist ein Datenschutzaktivist und Anwalt, der mehrere bedeutende Prozesse geführt hat, um die Datenrechte europäischer Bürgerinnen und Bürger zu verteidigen, die durch nicht einvernehmliche Datenflüsse in die USA verletzt wurden.2 Er hat bereits mehrere Prozesse gewonnen, und es ist anzunehmen, dass es zu weiteren Klagen und Durchsetzungsmaßnahmen kommen wird. Sollte er damit erfolgreich sein, könnte dies eine grundlegende Umstrukturierung bedeuten, sodass keine europäischen Daten mehr in die USA gelangen.
Darüber hinaus wächst in vielen Teilen der Welt der Druck seitens der Politik in Bezug auf die Datenhoheit (engl. Data Sovereignty). Auch wenn man darüber streiten kann, inwieweit diese Bedenken berechtigt sind, konzentrieren sich viele Politiker darauf, wie die Daten ihres Landes und ihrer Bürger transferiert werden und welche Auswirkungen dies hat. Wenn der Druck, die Daten eines Landes innerhalb dieses Landes zu halten, weiter zunimmt, wird das zweifellos auch die Art und Weise verändern, in der multinationale Unternehmen Daten nutzen.
Schließlich haben sich in jüngster Zeit einige Bedenken aus der sich ändernden Auslegung der Gesetze und Rechte durch den Obersten Gerichtshof in den Vereinigten Staaten ergeben. Wenn Ihr Unternehmen Daten erhebt, die zu einer strafrechtlichen Verfolgung einer Person verwendet werden könnten, ist es möglich, diesen Personen mehr Schutz zu bieten, indem Sie diese Daten nicht erheben. Sind Sie nicht im Besitz der Daten, können Sie nicht verpflichtet werden, sie preiszugeben.3
Darüber hinaus gibt es auch in der Softwareentwicklung und in der Forschung einen Vorstoß in Richtung local first, d.h., es wird nach Wegen gesucht, wie Software für Menschen zugänglicher gemacht werden kann, die bestimmte Dinge lieber offline und nur mit lokalen Ressourcen nutzen möchten. Ich empfehle Ihnen, einen Blick auf die Arbeit von Martin Kleppmann et al. zu den Grundsätzen für Local-first-Architektur und Softwaredesign (https://oreil.ly/JHKj0) zu werfen.
In Anbetracht der vielen potenziellen Vorteile (Datenschutz, rechtliche Aspekte, Sicherheit, Rechen- und Speicherkosten) ist es nur logisch, weniger Daten zu sammeln. Doch wie funktioniert eigentlich eine Analyse, wenn sich die Daten nicht auf Ihren Servern oder in Ihrer Cloud befinden?
Wenn Sie Hadoop, Spark, EMR oder Kubeflow-Dienste verwenden, nutzen Sie bereits eine Form der verteilten Datenanalyse (engl. Distributed Data Analysis), bei der der Orchestrator verteilte Rechenknoten verwaltet und diese Aufgabe von Ihrer Schnittstelle weg abstrahiert. Wenn Sie beispielsweise eine Spark-Abfrage ausführen, wird diese Abfrage in Wirklichkeit einem Plan zugeordnet, der auf separaten Rechnern oder zumindest in separaten Virtualisierungen mit unterschiedlichen physischen Speicherorten ausgeführt wird. Die Schnittstelle mag den Eindruck erwecken, dass Sie mit einer einzigen Datenquelle interagieren – z.B. mit Ihren RDDs (Resilient Distributed Datasets), Datensätzen oder Dataframes –, aber diese Abstraktion ist eine rein logische Konstruktion, die sich über verteilte Speicher erstreckt (siehe Abbildung 6-1).
Abbildung 6-1: Apache Spark im Detail
In Abbildung 6-1 können Sie nachvollziehen, wie der Dataframe bzw. die SQL-Abfrage auf die eigentlichen Rechner und Datenspeicher übertragen wird. Zunächst wird Ihr Programm in einen logischen Plan kompiliert, der die Abfrage mittels eines Katalogs abbildet. Anschließend wird dieser Plan optimiert und in einen physischen Plan überführt – an dieser Stelle wird die Abfrage also zunächst auf den tatsächlichen verteilten Speicher abgebildet. Dann wird der beste physische Plan auf Basis eines Kostenmodells ermittelt, in Code kompiliert und ausgeführt. Weitere Einzelheiten zu diesem Prozess finden Sie in dem entsprechenden Blogbeitrag von Databricks, in dem der Prozess und das Diagramm noch ausführlicher beschrieben werden (https://oreil.ly/FWEif).
Dieser Prozess findet auch bei zahlreichen Abstraktionen Anwendung, bei denen viele Knoten bzw. Microservices in der Cloud oder lokal betrieben werden und Software zum Einsatz kommt, um diese zu verbinden, zu orchestrieren und Analysen durchzuführen. Meist senden diese Dienste die Daten über lokale Netzwerke. Bis der Prozess abgeschlossen ist, werden Daten und Ergebnisse oft via Netzwerk übertragen oder im lokalen Rechenspeicher gehalten.
Um eine verteilte Datenarchitektur zu schaffen, die dem Datenschutz Rechnung trägt, muss man dieses Netzwerk auf die Edge-Ebene ausdehnen und die Software sowie die Abfragen so umstrukturieren, dass man nicht mehr die Daten von der Edge-Ebene zu einem zentralen Rechenknoten oder einem zentralen Speicher bewegt, sondern die Berechnungen dorthin, wo sich die Daten befinden!
Betrachten wir einmal, wie ein Workflow aussehen könnte (siehe Abbildung 6-2). Angenommen, Sie hätten drei Randknoten (engl. Edge Nodes), die verschiedene Speichertypen repräsentieren, die Sie in einem verteilten Datenanalyseworkflow vorfinden könnten, z.B. Smartphones, IoT-(Internet-of-Things-)Geräte und Robotikhardware. Diese Geräte werden nicht von Ihnen oder Ihrem Netzwerk gesteuert, aber Sie können über eine öffentliche Internetverbindung oder einen sicher verbundenen Netzwerktunnel und eine Software- bzw. Hardwareschnittstelle auf sie zugreifen. Im weiteren Verlauf dieses Kapitels lernen Sie noch einige Softwarelösungen kennen, die Sie für den Einstieg verwenden können.
Abbildung 6-2: Verteilte Datenanalyse
Wenn Sie Analysen oder Abfragen durchführen, möchten Sie, dass diese Abfragen an die Edge-Geräte gesendet werden. Dazu sind zwei Dinge erforderlich: Erstens muss jedes dieser Geräte die Abfrage lokal ausführen, und zweitens müssen die Geräte online sein, damit Ihre Analyse erfolgreich durchgeführt werden kann. Das Ergebnis der Abfrage wird gesammelt und an den Aggregationspunkt zurückgeschickt. An diesem Punkt kann der Aggregator das Endergebnis auf der Grundlage aller Zwischenergebnisse der Geräte berechnen und dieses Ergebnis an den Abfragegenerator senden. Auf diese Weise erhält man dasselbe Ergebnis, das man erhalten hätte, wenn man alle Daten gesammelt und zentral gespeichert hätte, jedoch ohne das Risiko, das mit der Speicherung der Daten auf den eigenen Diensten verbunden ist. Dieser Ansatz ist daher wesentlich datenschutzfreundlicher.
Beim Übergang von einem zentralisierten Ansatz der Datenanalyse zu einem verteilten bzw. föderalen Ansatz sind einige Punkte zu beachten. Zum einen können die Geräte über unterschiedliche Analysefunktionen verfügen, sodass einige Berechnungen einfacher durchzuführen sind als andere. Es kann erforderlich sein, Abfragen kreativ zu strukturieren oder zu sequenzieren, um die gewünschten Ergebnisse zu erzielen. Außerdem müssen die Geräte bzw. Randknoten über dieselbe Software verfügen, möglicherweise sogar über dieselben Softwareversionen, die Sie ausliefern, damit sie die lokalen Abfragen einheitlich ausführen können. Darüber hinaus könnte ein Gerät von Dritten manipuliert werden, entweder durch Beschädigung der Daten auf dem Endgerät selbst oder durch Manipulation der Software. Eine solche Bedrohung ist schwer zu erkennen, selbst wenn die Daten zentralisiert sind. Daher sollten Sie dies mit Ihrem Sicherheitsteam besprechen, um geeignete Maßnahmen zu ergreifen.
Zum anderen können sich die Daten an jedem dieser Knotenpunkte stark voneinander unterscheiden oder inkonsistent sein. Das gilt auch für eine zentral angelegte Analyse, wenn sich eine systematische Veränderung (engl. Shift) hinsichtlich der Population bzw. der Verteilung der Daten einstellt, die als Model Drift oder auch Data Drift bezeichnet wird. Unter Umständen ist dies allerdings bei einer verteilten bzw. föderalen Analyse schwieriger zu erkennen, da man keine einzelnen Datenpunkte zu Gesicht bekommt. Wenn Sie bereits mit dem Konzept unabhängiger und identisch verteilter (iid) Zufallsvariablen (engl. Independent and Identically Distributed (IID) Random Variables) (https://oreil.ly/hs8_M) vertraut sind, ist Ihnen wahrscheinlich bewusst, dass dadurch einige Aspekte der Analyse erschwert werden können.4 In realen Datensätzen sind Daten oft nicht unabhängig und identisch verteilt (iid). Gleiches gilt auch für die Analyse verteilter Daten. Dennoch müssen Sie diese Analyse durchführen, um ein Ergebnis zu erhalten, das als Grundlage für Entscheidungen oder Rückschlüsse dienen kann.
Führen Sie sich einmal das folgende Beispiel vor Augen. Angenommen, Sie möchten einen Objekterkennungsalgorithmus (engl. Object Recognition Algorithm) auf Endgeräten lokal laufen lassen und Informationen darüber gewinnen, welche Arten von Fotos Menschen mit ihrem Smartphone aufnehmen. Dazu müssen Sie die folgenden Schritte gehen:
Wenn eine Nutzerin jedoch nur Fotos von Katzen und ein Nutzer dagegen nur Fotos von Hasen auf dem Smartphone hat, verzerrt dies die Ergebnisse, und Sie würden davon ausgehen, dass alle Nutzerinnen und Nutzer Fotos von Katzen und Hasen haben. Außerdem könnte es sich als problematisch erweisen, wenn die meisten Nutzer nur eine geringe Anzahl von Fotos und einige Superuser Millionen von Fotos auf ihrem Smartphone haben. Diese Superuser sind dann stark überrepräsentiert, wodurch auch der Schutz ihrer Privatsphäre gefährdet ist. Da die Daten nicht unabhängig und identisch verteilt (iid) wären, müssten Sie dies bei Ihrer Analyse berücksichtigen. Seien Sie also vorsichtig dabei, welche Annahmen Sie treffen. Erarbeiten Sie erforderlichenfalls Möglichkeiten, durch die die Privatsphäre geschützt wird und Sie gleichzeitig eine gewisse Zuordnung der Nutzer zu ihren jeweiligen Ergebnissen beibehalten können, oder erheben Sie die Daten so, dass Ausreißer weitaus seltener berücksichtigt werden (Downsampling).
Spätestens hier wird deutlich, dass selbst eine verteilte Datenanalyse den Schutz der Privatsphäre beeinträchtigen und Informationen über Ausreißer preisgeben kann. Ausreißer und Superuser haben, wie Sie in Kapitel 2 gelernt haben, einen viel größeren Privacy Loss als andere – selbst wenn Sie die Daten nicht zentral erheben. Betrachten Sie Ihre in Schritt 4 durchgeführte Analyse und erinnern Sie sich zurück an Ihre Erkenntnisse aus Kapitel 4. Welche Angriffsmöglichkeiten wären denkbar, mit denen sich Personen re-identifizieren lassen?
Erstens könnte sich ein Angreifer Zugriff auf den Aggregator verschaffen und die eingehenden Daten verfolgen. Auf diese Weise könnte er sehr leicht IP-Adressen oder andere Informationen aufzeichnen, wenn die neuesten Daten an den Aggregator gesendet werden. Das würde bedeuten, dass er auch die einzelnen Analyseergebnisse aller Smartphones einsehen könnte, was jegliche Datenschutzgarantien zunichtemacht.
Zweitens könnte der Angreifer die Analysen jeweils vor und nach dem Beitritt eines Nutzers durchführen und die Analyseergebnisse vergleichen. Durch diese Differencing Attack bzw. die Singling Out Attack ist es für jeden, der Zugriff auf die Analyseabfragen und -ergebnisse hat, ein Leichtes, Informationen über die Daten eines bestimmten Nutzers zu erhalten.
Zu guter Letzt gilt, wie Sie aus dem zentralen Grundsatz der Differential Privacy wissen, dass selbst ohne Zugriff auf den Aggregator aggregierte Aktualisierungen und Ergebnisse nicht den nötigen Schutz der Privatsphäre bieten, wenn kein Differential-Privacy-Mechanismus verwendet wird.
Aus diesem Grund werden bei verteilten Abfragen und Datenanalysen, bei denen die Privatsphäre gewahrt bleiben soll, oft mehrere Ansätze kombiniert, um den Grad an Datenschutz zu gewährleisten, den Nutzer erwarten.
Inzwischen haben Sie zahlreiche Maßnahmen und Verfahren, mit denen Sie den Datenschutz gewährleisten – oder zumindest erhöhen – können, kennengelernt. Um einen sicheren und den Schutz der Privatsphäre gewährleistenden Aggregator einzurichten, müssen Sie sicherstellen, dass dieser in Bezug auf die Software- und Hardwarevoraussetzungen gut gesichert ist und nur wenige Personen Zugriff auf ihn haben. Sie sollten zudem auf eine verschlüsselte Netzwerkkommunikation zurückgreifen und in Erwägung ziehen, Encrypted Computation durchzuführen (mehr dazu in Kapitel 7). Wenn Sie dann die Aggregierung vornehmen, kommt der Differential-Privacy-Mechanismus zum Einsatz. Dadurch wird die Anzahl der Beiträge pro Nutzer begrenzt, was sich wiederum positiv auf das Problem hinsichtlich nicht unabhängiger und identisch verteilter Zufallsvariablen auswirkt – wenngleich Sie dadurch wenig über Ausreißer erfahren werden.
Wie würde sich das auf Ihre Architektur auswirken? Abbildung 6-3 vermittelt Ihnen eine Vorstellung davon, wie das System auf übergeordneter Ebene organisiert sein könnte. Die Endgeräte verbinden sich und senden ihre Aktualisierungen bzw. Abfrageantworten über eine sichere Verbindung an die Aggregationspunkte. Sie können zwar mehrere Aggregationspunkte haben, um jeweils verschiedene Zonen oder Regionen zu bedienen (siehe Abbildung 6-5), aber wenn Sie die Ergebnisse zentral erfassen wollen, müssen diese an irgendeiner Stelle aggregiert oder harmonisiert werden.
Abbildung 6-3: Sicherung einer Federated-Learning-Architektur
Der Aggregationspunkt sollte gut gesichert sein, und nur wenige sollten darauf Zugriff haben (siehe Abbildung 6-3). Dies ist vergleichbar mit der lokalen Differential Privacy von Apple oder Prochlo (siehe Kapitel 3), bei denen durch den Zugriff auf diese Systeme die Datenschutz- und Sicherheitsgarantien verletzt werden, da Informationen über die Beiträge der Nutzerinnen und Nutzer direkt preisgegeben werden.
Nachdem die Abfrageergebnisse auf sichere und dem Datenschutz Rechnung tragende Weise aggregiert wurden (siehe Abbildung 6-4), können die resultierenden Daten dem Analyseteam zugänglich gemacht werden. Normalerweise werden die aktualisierten Daten vom Aggregator an das normale Analysesystem bzw. die Software gesendet. Diese beiden Systeme müssen eine gewisse Trust Boundary einhalten, damit der Schutz der Privatsphäre gewährleistet werden kann, da der Aggregator zusätzliche Informationen über die einzelnen Beiträge kennt.
Betrachten wir nun den Aggregator genauer und verschaffen wir uns einen Überblick über die Vorgänge innerhalb des Aggregators. Abbildung 6-3 zeigt, dass die aktualisierten Daten von den Endpunkten kommen, an denen die Daten gespeichert sind, und im Aggregator zusammengeführt werden. Je nachdem, wie vertrauenswürdig das System ist, können die aktualisierten Daten auch in verschlüsselter Form eingehen und mithilfe von Encrypted Computation (siehe Kapitel 7) gemeinsam ausgewertet werden (Durchschnittsermittlung, Summenbildung usw.). Es muss ein Schwellenwert festgelegt werden, da eine gewisse Anzahl an Nutzern nicht einbezogen werden kann, wenn die Verbindung zu dem entsprechenden Endgerät unterbrochen wird oder ein anderer Fehler auftritt. Sobald dieser Schwellenwert erreicht ist, erfolgt die aggregierte Berechnung. Damit die Differential-Privacy-Garantien eingehalten werden können, muss zunächst ein Clipping oder Bounding durchgeführt werden, und zwar entweder direkt auf dem Gerät vor der Erfassung oder für die Abfrageergebnisse. Anschließend können Sie die Daten – sofern sie verschlüsselt sind – mittels Encrypted Computation aggregieren, oder Sie nutzen gewöhnliche klartextbasierte Aggregationsmechanismen. Sobald die Daten aggregiert sind, können Sie eine zentralisierte Differential Privacy anwenden, da Sie die Sensitivität der Daten kennen. Sollten Sie eine Verschlüsselung verwenden, wird das Ergebnis zu diesem Zeitpunkt entschlüsselt. Das Ergebnis wird dann vom Aggregator veröffentlicht und der Analyseumgebung zugeführt.
Abbildung 6-4: Sichere und datenschutzgerechte Aggregation im Rahmen des Federated Learning
Diese Art von Systemen bringt zwar eine gewisse Komplexität mit sich, bietet aber im Vergleich zu zentralisierten Datenerfassungssystemen äußerst starke Datenschutz- und Sicherheitsgarantien. Viele dieser Ansätze stammen aus dem Bereich des Federated Learning, den Sie im Folgenden näher kennenlernen werden.
Federated Learning ist ein Verfahren, bei dem eine verteilte Datenarchitektur – wie die zuvor in diesem Kapitel beschriebene – für einen Machine-Learning-Prozess verwendet wird. Anstatt Abfragen an die Endpunkte zu senden, werden Modelle und Trainingsupdates gesendet. Jeder einzelne Randknoten bzw. jedes Gerät trägt dazu bei, ein gemeinsames Modell auf Basis seiner lokalen Daten zu trainieren, ohne dass diese Daten an eine zentrale Stelle gesendet werden.
Google war das erste Unternehmen, das Federated Learning erstmals in großem Maßstab umgesetzt hat, als es Daten von Mobiltelefonen zum Training verwendete, ohne dass die Daten dafür auf zentraler Ebene aggregiert werden mussten. Google nannte seinen Ansatz »Federated Optimization«, der in einem Artikel im Jahr 2016 (https://oreil.ly/wYv3S) vorgestellt wurde. Auf dem KI-Blog von Google wurde er im Anschluss als Federated Learning (https://oreil.ly/t8HAs) bezeichnet, und dieser Begriff wird auch heute in der Fachwelt verwendet.5
Zu jener Zeit hatte Google gerade TensorFlow 1.0 (https://oreil.ly/SerDa) veröffentlicht und seine Lösungen für verteilte Workflows als TensorFlow federated (tf-federated) zur Verfügung gestellt. Mithilfe von Federated Learning wollte Google die Vorschläge für seine Tastatur (GBoard) verbessern. Da bei Nutzung der Tastatur zahlreiche private Informationen preisgegeben werden, sollte so ein leistungsfähiges Modell trainiert werden, das ohne eine zentrale Erfassung der eingegebenen Daten auskommt.
Durch die Bereitstellung eines kleinen, vortrainierten Machine-Learning-Modells (in diesem Fall eines Modells, das auf die Empfehlung und Vervollständigung von Texten trainiert wurde) auf jedem Endgerät konnte das Training direkt auf dem Endgerät erfolgen. Die eingegebenen Daten wurden nicht an einen zentralen Speicher von Google gesendet, wodurch die Daten vertraulicher behandelt wurden und besser geschützt waren. Nach jeder Trainingsrunde wurden nur die aktualisierten Gradienten an die Aggregatoren gesendet, die jeweils den Durchschnitt dieser Gradienten berechneten und diese dann als abschließende aggregierte Aktualisierungen der entsprechenden Trainingsrunde an alle Geräte sendeten, bevor die nächste Trainingsrunde begann.
Abbildung 6-5 zeigt, wie dieser Prozess im Detail abläuft. Im ersten Schritt wird das als Kreis dargestellte Modell an alle Geräte übertragen. Anschließend wird auf jedem Gerät lokal ein Training durchgeführt und eine Reihe von lokalen Aktualisierungen erzeugt, um das Modell zu verbessern (in Abbildung 6-5 als Schritt A gekennzeichnet). Diese Aktualisierungen werden dann an einen Aggregator gesendet, der in Abbildung 6-5 als Schritt B dargestellt ist. Einige dieser Aktualisierungen beziehen sich auf dieselben Schichten und Gewichte, andere gegebenenfalls auf Singletons (siehe Schritt B in Abbildung 6-5). Anschließend werden die zu verwendenden Aktualisierungen ausgewählt, der Durchschnitt wird gebildet und zu einer einzigen Aktualisierung oder einer Reihe von Aktualisierungen vereinfacht (siehe Schritt C in Abbildung 6-5). Die Aktualisierungen werden dann an alle Geräte gesendet, um jeweils das lokale Modell eines Geräts zu aktualisieren, wobei dieser Vorgang so oft wie nötig wiederholt werden kann. Der gesamte Prozess sowie verschiedene Anwendungsfälle und verwandte Konzepte sind als Comic auf der Federated-Learning-Website von Google (https://federated.withgoogle.com) zu finden.
Abbildung 6-5: Der Ablauf beim Federated Learning
In Kapitel 5 haben Sie gelernt, dass Gradienten extrem groß werden können und dadurch die Privatsphäre einzelner Personen verletzt werden kann. Dies gilt auch für Federated Learning! In der ursprünglichen Implementierung wurde dies von Google nicht berücksichtigt. Mittlerweile ist es jedoch üblich, dass Dienste, die auf Federated Learning oder Federated Analysis basieren, auch Differential Privacy als Teil dieser Aggregation berücksichtigen. Anstatt den Durchschnitt der aktualisierten Gradienten zu bilden und das Ergebnis an alle Telefone zu senden, werden diese zunächst vom Aggregator auf einen Wertebereich beschränkt (Clipping), dann wird der Durchschnitt gebildet und anschließend ein Differential-Privacy-Mechanismus mit einem entsprechenden Wert für Epsilon hinzugefügt.
Viele der in der Produktion zum Einsatz kommenden Implementierungen von Federated Learning basieren auf Deep-Learning-Architekturen. Es gibt jedoch auch zahlreiche weitere Modelle, die erforscht und implementiert wurden, wie etwa Gradient Boosted Trees (https://oreil.ly/xZKHi). Die Federated-Learning-Bibliothek von IBM (https://oreil.ly/6Nti7) bietet mehrere nützliche Implementierungen, einschließlich Boosted Trees und Naive Bayes.
Es ist auch wichtig, welche Geräte ausgewählt werden, insbesondere wenn es darum geht, Daten im Rahmen von Federated Learning zu verarbeiten, die nicht iid sind. Als Google Federated Learning zum ersten Mal einsetzte, entschied man sich, das Modell nicht auf alle Android-Smartphones zu übertragen. Stattdessen wurde eine Priorisierung vorgenommen, wobei Smartphones bevorzugt wurden, die nicht aktiv genutzt wurden, eine Strom- und Internetverbindung sowie die neueste Android-Software aufwiesen, eine bestimmte Hardwareausstattung (z.B. ausreichend Arbeitsspeicher) mitbrachten und über bestimmte Standardtastatursprachen verfügten. Auf diese Weise konnten Störungen und Unterbrechungen vermieden werden, die durch Nutzer mit unzureichendem Arbeitsspeicher oder unzureichender Netzwerkverbindung verursacht worden wären.
Das Problem, dass Daten nicht iid sein können, sowie einige ähnliche Probleme im Zusammenhang mit Daten (https://oreil.ly/ztxbK) stellen weiterhin eine Herausforderung für Wissenschaftler und Entwickler im Bereich des Machine Learning dar. Im Abschnitt »Mögliche Arten des Deployments« auf Seite 216 erfahren Sie mehr über diese Probleme und wie sie gelöst werden können. Im Großen und Ganzen sind sie noch Gegenstand der Forschung und können teilweise nur durch Verbesserungen in der Analyse, der Planung, dem Algorithmusdesign oder der Softwareentwicklung gelöst werden. Je nach Art der verwendeten Daten und dem verfolgten Ziel kann sich der Einsatz von Federated Learning daher als schwierig oder sogar ungeeignet erweisen.
Seit dem ersten Deployment von Federated Learning durch Google haben mehrere andere große Unternehmen Federated Learning in Produktionsumgebungen eingeführt, einschließlich Apple (https://oreil.ly/IRKAw), NVIDIA (https://oreil.ly/YXk1C) und Amazon Web Services (https://oreil.ly/e2kGc). Es gibt auch immer mehr Open-Source-Bibliotheken für Federated Learning und eine wachsende Zahl von Start-ups und Unternehmen, die Federated Learning in ihre eigenen Machine-Learning-Lösungen integrieren. Welche Probleme können durch Federated Learning gelöst werden, und wie kann es eingesetzt werden?
Federated Learning eignet sich für eine Vielzahl von Anwendungsfällen, bei denen es nicht möglich ist, Daten zentral zu sammeln. Die wichtigsten sind:
Sensible Daten
Wenn Personen es vorziehen, dass ihre Daten lokal und nicht zentral gespeichert werden.
IoT- bzw. Edge-Daten
Wenn es aufwendig ist, äußerst große Datensätze bei sich ständig ändernder Geräte- und Hardwareunterstützung zu warten.
On-Premise-Daten
Wenn Systeme über Sicherheits- oder Vertraulichkeitsvorkehrungen verfügen, die verhindern, dass die Daten den Speicherort bzw. die Speicherinfrastruktur verlassen.
Diese Anwendungsfälle haben eines gemeinsam: Die Daten verlassen – wann immer möglich – nicht die lokale Infrastruktur bzw. das lokale Gerät. Sie kommen dann zum Einsatz, wenn eine zentrale Datenerfassung entweder gegen bestimmte Richtlinien, Vorschriften oder Datenschutzbestimmungen verstößt oder zu unverhältnismäßigen Performance- oder Speicherproblemen führt.
Durch die Verlagerung der Datenverarbeitung »an den Rand« können Sie von den Vorteilen der Datenanalyse und des Machine Learning profitieren, ohne die Risiken einer zentralen Datenerfassung einzugehen, die Sie überwachen, pflegen und administrieren müssen. Durch die Verlagerung der Datenverarbeitung dorthin, wo sich die Daten befinden, eröffnen sich neue Möglichkeiten, und Sie können mehr Zeit für die eigentliche Datenanalyse statt für das Datenmanagement aufwenden.
Die Verarbeitung der Daten auf Randknoten und Endgeräte zu verlagern, ist jedoch keine einfache Aufgabe. Sie bringt einige zusätzliche technische Herausforderungen mit sich, die in Tabelle 6-1 zusammengefasst werden.
Tabelle 6-1: Vorteile und Herausforderungen beim Federated Learning
Vorteile |
Herausforderungen |
keine zentrale Datenerfassung |
Standardisierung der Daten auf dem Gerät |
vielfältigere Daten |
ungleichmäßig verteilte Daten |
Machine Learning direkt auf dem Gerät und/oder offline |
gemeinsame Nutzung von Modellen |
Schutz der Privatsphäre |
abhängig von der Implementierung |
Anders als bei traditionellen Machine-Learning-Systemen werden die Daten beim Federated Learning nicht an einem zentralen Ort gespeichert. Dadurch wird zum einen ein höherer Datenschutz gewährleistet, und zum anderen können die Kosten gesenkt werden, die für die zur Datenerfassung benötigte Infrastruktur und entsprechenden Support entstehen. Eine Schwierigkeit besteht darin, dass die auf dem Edge-Gerät erfassten Daten standardisiert und strukturiert werden müssen, damit das Training durchgeführt werden kann. Das bedeutet wiederum, dass die gesamte Vorverarbeitung der Daten auf dem Edge-Gerät selbst stattfinden muss und sie zunächst vereinheitlicht werden müssen, ehe das Training durchgeführt werden kann. Die Trainingsdaten können vertikal partitioniert werden, d.h., die Spalten werden geräteübergreifend miteinander verknüpft, oder sie können horizontal partitioniert werden, d.h., die Trainings- und Testdatensätze werden um die gesammelten Datenpunkte aller Geräte erweitert. Die Daten müssen so strukturiert sein, dass die erforderlichen Berechnungen mit ihnen durchgeführt werden können. Dazu müssen die Daten auf allen Edge-Geräten bereits im gleichen Format vorliegen oder erst in das gleiche Format konvertiert werden. Es ist daher sinnvoll, Edge-Geräte bzw. Hardware mit einheitlicher Datenkonfiguration zu verwenden, z.B. Geräte, die alle mit der gleichen Software arbeiten.
Sofern es sich um Daten handelt, die aus Gründen der Sicherheit und des Datenschutzes nicht zentral erfasst werden können, haben diese Systeme den zusätzlichen Vorteil, dass sie eine größere Reichweite und eine höhere Anzahl von Nutzereingaben haben, was dazu beiträgt, dem Modell eine höhere Repräsentativität (Debiasing) zu verleihen, da eine größere Population erfasst wird. Diese vielfältigen Daten sind per definitionem nicht iid, was zu den im Abschnitt »Die Entwicklung des Federated Learning im Überblick« auf Seite 210 diskutierten Problemen bei der Analyse und beim Debugging führt. Eine mögliche Lösung für dieses Problem besteht darin, bei den Auswahlkriterien penibel zu sein und vorab einige explorative Datenanalysen durchzuführen, um eine bessere Vorstellung von der Heterogenität der Nutzerpopulationen zu erhalten. Sie können Ihre Aggregatoren auch mit einer Logik versehen, um Nutzer nach der Qualität ihrer Daten zu gruppieren und innerhalb eines Aggregators zusammenzufassen. Achten Sie jedoch darauf, dass Informationen über die Nutzerinnen und Nutzer möglicherweise übermäßig offengelegt werden, wenn die Gruppen zu klein gewählt werden!
Da das Modell auf dem Gerät trainiert wird, kann es auch schneller antworten und offline verwendet werden. Wenn gemanagte IoT-Geräte oder vernetzte Geräte offline sind, wenn das Wi-Fi oder das mobile Internet ausfällt, können diese Geräte dennoch das lokale Modell sowie die Daten nutzen und Entscheidungen treffen. Der Nachteil ist, dass das Modell für alle Geräte freigegeben werden muss (siehe Kapitel 4 für mögliche Datenschutz- und Sicherheitsrisiken). Sie müssen sicher sein, dass die Übertragung des Modells (oder einer Version davon) an jedes Gerät den Vorschriften entspricht und ausreichend gesichert ist – und bedenken Sie, dass jemand das Modell von seinem Gerät abrufen und inspizieren kann und wird.
Der Schutz der Privatsphäre des Einzelnen erhöht sich, wenn die Daten auf dem Gerät gespeichert werden. Allerdings kann dies – wie Ihnen aus den Kapiteln 2 und 5 bekannt ist – je nach Implementierung stark variieren, da Gradienten und Zwischenergebnisse auch eine ganze Menge privater Informationen preisgeben können. Diese Risiken gilt es abzuschätzen und entsprechende Maßnahmen zu ergreifen, etwa indem Sie Differential-Privacy-Mechanismen Ihren Aggregationspunkten hinzufügen.
Wenn Sie Ihr Machine Learning in einem Federated-Modell oder -System strukturieren, müssen Sie Ihren normalen Data-Science-Workflow anpassen. Sie werden wahrscheinlich nicht in der Lage sein, eine explorative Datenanalyse durchzuführen. Außerdem werden Sie weit weniger Einblick in die Daten haben, und der Zugriff wird eingeschränkter sein als üblich. In vielen Fällen können Sie verteilte Abfragen mit Software durchführen, die speziell für Federated Learning entwickelt wurde, um einen Überblick über die Gesamtpopulation zu erhalten. Aber selbst dann können Sie die Daten nicht direkt einsehen. Dadurch gestaltet es sich schwierig, die Fehlerquelle zu finden, wenn ein Modell nicht einwandfrei funktioniert.
Die Modellarchitektur und die Aufteilung der Daten müssen festgelegt und entsprechend umgesetzt werden. Bei Federated Learning mit tabellarischen Daten kann zwischen vertikaler und horizontaler Aufteilung gewählt werden. Das bedeutet, dass die Daten entweder auf »Zeilen«- (horizontal) oder auf »Spalten«-Basis (vertikal) zwischen den verschiedenen Nutzern aufgeteilt werden. Auch wenn Sie nicht mit tabellarischen Daten arbeiten, können Sie diese Aufteilungen bei Bedarf dafür verwenden, Labels mit Ihren Inputdaten abzugleichen. Bevor Sie sich für eine Aufteilung entscheiden, sollten Sie sich darüber im Klaren sein, welche Art von Daten Ihre Geräte enthalten – sind es einfach nur mehr Beispiele mit den entsprechenden Labels?
Befinden sich die Labels auf einigen Geräten und die Input-Features auf anderen Geräten? Sind die Input-Features und Variablen auf mehrere Geräte verteilt? Je nachdem, wie die Daten verteilt sind, müssen Sie Ihr Modell strukturieren, wobei einige Konfigurationen einfacher sind als andere. Wenn die Daten horizontal aufgeteilt sind und jedes Gerät über Trainingsdaten und Labels verfügt, ist dies mit den heute verfügbaren Federated-Learning-Bibliotheken einfacher zu handhaben. Die Unterstützung für vertikale Aufteilungen, bei denen Labels und/oder Input-Features auf verschiedene Geräte verteilt werden können, nimmt allerdings stetig zu.
Es gibt auch einige interessante Forschungsbeiträge zu Multitask-Modellen, (https://oreil.ly/dhBjt) die in einer verteilten Umgebung trainiert werden können, in der die Daten heterogen sind und jedes Modell gegebenenfalls für eine andere Aufgabe optimiert wird. Dies ist zwar noch Gegenstand der Forschung, aber die Möglichkeit, Wissen in diesen heterogenen Umgebungen transferieren zu können, könnte neue föderale und verteilte Lernarchitekturen hervorbringen. Darüber hinaus könnten diese Fortschritte dazu beitragen, dass neue Methoden zum Erlernen von Aufgaben gefunden werden, wenn zwar keine Daten für eine bestimmte Aufgabe vorliegen, aber verwandte Daten vorhanden sind.
Es gibt noch weitere interessante Federated-Learning-Strukturen, wie Split Learning (https://oreil.ly/Eh_06), Personalisierung von Modellen auf Geräten (https://oreil.ly/oJNGk) und Meta Learning (https://oreil.ly/QA86F). Auf einige dieser Strukturen werde ich im weiteren Verlauf dieses Kapitels eingehen, wenn sie im Zusammenhang mit spezifischen Fragen oder Problemen stehen. Der Bereich des Federated Learning ist noch relativ jung. Daher werden viele dieser Ideen, obwohl sie sich in der Forschung bewährt haben, nicht unbedingt in großem Umfang eingesetzt. Ich empfehle Ihnen, sich über die neuesten Architekturen, die für Ihren Anwendungsfall infrage kommen, zu informieren und herauszufinden, ob sie bereits eingesetzt werden und ob sie in der Zwischenzeit in der Forschung oder in der Praxis optimiert oder verbessert wurden.
Die Art und Weise, wie Sie Federated-Learning-Modelle trainieren, hängt in hohem Maße davon ab, wie eng Sie mit den Infrastruktur-, Software- und DevOps-Spezialistinnen und -Spezialisten in Ihrem Unternehmen zusammenarbeiten. Vor dem Gespräch sollten Sie sich überlegen, welche Anforderungen an die Architektur und das Deployment thematisiert werden sollten und wie Sie Ihre Kollegenteams bei der Entscheidungsfindung unterstützen können..
Die Architektur von Federated-Learning-Systemen ist angesichts der zahlreichen Einschränkungen und Leistungsanforderungen bezüglich des Deployments keine leichte Aufgabe. In diesem Abschnitt erfahren Sie, was bei der Architektur eines föderalen bzw. verteilten Datensystems zu beachten ist und was bei der Entwicklung und dem Deployment von Software, bei der die Daten so weit wie möglich vom zentralen System entfernt sind, berücksichtigt werden muss.
In Federated-Learning- oder verteilten Datenanalysesystemen haben Sie mehrere wesentliche Komponenten. Diese sind:
Zunächst müssen Sie herausfinden, wie sich die Geräte gegenseitig abstimmen und ihre Ergebnisse senden. Dafür gibt es verschiedene Möglichkeiten (siehe Abbildung 6-6):
Klassisch
Die Geräte verbinden sich mit einem zentralen Aggregator. Dieser Aggregator oder ein damit verbundener Dienst ist für die Auswahl der Geräte, die Abstimmung der Trainingsläufe oder Analysen und die Durchführung des eigentlichen Aggregationsschritts zuständig. Die Endgeräte senden die aktualisierten Daten an diesen zentralen Dienst, wobei das in der Regel über eine sichere Netzwerkverbindung (z.B. per HTTPS oder über VPNs) geschieht.
Als Cluster
Sie entscheiden sich dafür, Ihre Analysen oder Machine-Learning-Prozesse auf mehrere Aggregatoren aufzuteilen, um verschiedene Geräte auf der Grundlage ihrer Software zu bedienen oder weil Ihre aktuelle Systemarchitektur verteilt ist oder um die Netzwerkleistung zu optimieren. Auch hier sollten die Verbindungen über einen sicheren Kommunikationskanal erfolgen, und die Edge-Geräte würden weiterhin mit dem ihnen zugewiesenen Aggregator kommunizieren. Diese separaten Aggregatoren müssen auch miteinander koordiniert werden, wenn sie ein aggregiertes Modell erstellen sollen.
Vollständig verteilt
Jedes der vorherigen Systeme basiert auf einer Architektur, die zentralisiert ist und von einer Organisation oder einer Gruppe von Personen gewartet und betrieben werden muss. Wie wäre es jedoch, wenn dieser Prozess tatsächlich dezentralisiert würde? Das ist zwar möglich, erfordert aber einen erheblichen Mehraufwand an Koordination und Kommunikation zwischen den Geräten selbst. Sie müssen die Aktionen und die Aufgaben der Aggregatoren übernehmen (d.h. Auswahlkriterien, Koordination und Aggregation). Aus praktischer Sicht ist dies noch nicht in großem Maßstab durchführbar, aber für einen kleinen Proof of Concept oder als neues Produkt oder Softwareangebot bietet es meiner Meinung nach einige wirklich interessante Eigenschaften in Bezug auf den Datenschutz und die Dezentralität! Sie werden noch mehr über Architekturen wie diese in Kapitel 7 erfahren.
Abbildung 6-6: Verschiedene Optionen, die für den Aufbau eines Federated-Learning-Aggregators geeignet sind
Sie müssen nicht nur die Architektur des Federated-Learning-Systems und des Aggregators entwickeln, sondern auch geeignete Auswahlkriterien festlegen. Im Folgenden finden Sie einige Fragen, die Ihnen bei der Auswahl helfen:
Gerätekonnektivität
Über welche Internetverbindung verfügt das Gerät? Können Sie sich darauf verlassen, dass die Verbindung nicht mitten in der Analyse unterbrochen wird? Was passiert, wenn eine bestimmte Anzahl an Geräten eine Runde »aussetzt«? Es empfiehlt sich, einen Schwellenwert festzulegen, ab dem die Analyse fortgesetzt werden soll.
Systemspeicher und -last
In welchem Zustand befindet sich das Gerät derzeit? Ist es durch andere laufende Prozesse stark ausgelastet? Wie viel Arbeitsspeicher (RAM) ist für Analysen oder Trainingsläufe verfügbar?
Stromversorgung und Hardware
Wie sind die Hardwarespezifikationen des Geräts? Ist das Gerät an das Stromnetz angeschlossen? Wenn nicht, wie hoch ist der Akkustand, und wie lang muss der Akku noch ausreichen, um eine Analyse oder ein Training auf dem Gerät durchzuführen?
Software und Datenzugriff
Verwendet das Gerät eine aktuelle Softwareversion? Wird die Analyse von der laufenden Software unterstützt? Verfügt das Gerät über lokale Daten, die für das Training und die Analyse relevant sind, wie z.B. die Einwilligung des Nutzers und Zugriffsrechte?
Verteilung der Daten
Erfüllen das betreffende Gerät und die Daten die datenwissenschaftlichen Anforderungen für Ihre Analyse? Gibt es bestimmte Auswahlkriterien, die Sie verwenden können, damit die Analyse erfolgreich durchgeführt werden kann, z.B. Regionen, Sprachen, Nutzertypen usw.?
Solche Entscheidungen können nicht allein getroffen werden. Stattdessen sollten Sie eng mit Ihren Kolleginnen und Kollegen aus der Datenabteilung und den Bereichen Infrastruktur, Operations, Systems Reliability Engineering und/oder DevOps zusammenarbeiten. Diese Teams werden wahrscheinlich die Infrastruktur und die Geräte für Ihr Machine-Learning- oder Analysesystem bereitstellen, überwachen und warten. Es ist nicht einfach, diese Art von Berechnungen erfolgreich und in großem Maßstab durchzuführen. Daher benötigen Sie die Unterstützung dieser Teams, um das System zu organisieren, zu testen, zu deployen und kontinuierlich zu verbessern.
Im besten Fall arbeiten Sie mit den Teams aus den Bereichen Infrastruktur und Operations zusammen, die mit diesen Arten von Architekturen vertraut sind. Versuchen Sie, Ihren Horizont hinsichtlich derartiger Systeme zu erweitern, indem Sie von dezentralen Identitätssystemen (https://oreil.ly/yvdJu) und Zero-Trust-Architekturen (https://oreil.ly/9oS83) lernen. Diese Ansätze sind zwar nicht ganz identisch, aber sie befassen sich mit ähnlichen Problemen hinsichtlich der Gestaltung der Architektur und der Vertrauensbildung.
Wenn Sie darüber nachdenken, wie Sie Ihre Software und die verteilte Analyse testen, ausrollen und (gegebenenfalls) wieder einstellen, sollten Sie mit einer koordinierten Diskussion beginnen, die zu einer gemeinsamen Entscheidung führt. Sie möchten auf jeden Fall vermeiden, dass Ihre Edge-Geräte abstürzen, weil der verfügbare Arbeitsspeicher der Geräte nicht ausreicht, oder dass Sie Softwarebugs einführen, die die Benutzerfreundlichkeit beeinträchtigen oder sogar zu Fehlern im Rahmen der föderalen Analyse führen. Daher ist es wichtig, eine umfassende und robuste CI/CD-Pipeline einzurichten, eine integrierte Testumgebung zu entwickeln und eine Reihe von Testgeräten als »Staging«-Umgebung zu verwenden.
Darüber hinaus werden Sie auch ein Debugging verteilter Daten vornehmen müssen, die Sie nicht einsehen können. Das ist genauso schwierig, wie es klingt! Im Folgenden möchte ich Ihnen ein paar Tipps an die Hand gegeben, die Sie beachten sollten, um diese Aufgabe erfolgreich zu meistern:
Wahren Sie die Privatsphäre.
Wenn Ihre Datenschutzanforderungen die Hauptmotivation für den Übergang zu einer föderalen Architektur und Analyse sind, sollten Sie sicherstellen, dass diese Anforderungen während des Debuggings auch tatsächlich eingehalten werden. Dies kann zwar etwas mehr Zeit in Anspruch nehmen, führt aber letztlich zu robusten Systemen, die sowohl Datenschutzstandards und -garantien erfüllen als auch verteilte Analysen und Machine-Learning-Prozesse durchführen können. Es wäre daher wenig zielführend, erst eine derartige Infrastruktur aufzubauen, um die Daten dann am Ende an einen zentralen Ort zu kopieren und sie dort zu debuggen oder sensible Informationen an zentraler Stelle zu loggen.
Testen Sie oft und entwickeln Sie Fehlermetriken.
Die Entwicklung eines kleinen Gerätelabors für lokale Tests beschleunigt das Debugging. Sie können an beiden Enden des Problems ansetzen und Bugs und Fehler frühzeitig erkennen. Dabei empfiehlt es sich, auch Metriken und Fehlermeldungen zu entwickeln, die keine sensiblen oder privaten Informationen preisgeben. Denken Sie daran, dass Sie keine Informationen erheben sollten, mit denen sich ein bestimmter Nutzer bzw. ein bestimmtes Gerät identifizieren lässt. Versuchen Sie stattdessen, elementare Metriken zu ermitteln, die Sie auf die vorhandenen Probleme hinweisen. Wenn Sie feststellen, dass die von Ihnen benötigten Metriken sensible Informationen enthalten, wie z.B. zusammenfassende Statistiken über die Daten oder den Standort einer Nutzerin, sollten Sie im Rahmen der Ermittlung der Metriken die Aggregierung unter Anwendung von Differential Privacy vornehmen. Das heißt, wenn ein bestimmter Fehler bei vielen Geräten nicht auftritt, werden Sie ihn auch nicht bemerken.
Verlegen Sie das Debugging auf die Endgeräte und identifizieren Sie Muster.
Je näher das Debugging am Gerät stattfindet, desto mehr Daten stehen zur Verfügung. Verwenden Sie diese Metriken und/oder sicheren Fehlerübersichten und stellen Sie fest, ob es Muster für bestimmte Probleme gibt, indem Sie sie für verschiedene Geräte vergleichen. Auf diese Weise können Sie Probleme systematisch identifizieren.
Mein Rat an Sie ist – nachdem ich bereits an verteilten Systemen gearbeitet habe, bei denen die Privatsphäre gewahrt wird (https://oreil.ly/UrKbf) –, geduldig zu sein und sich ausreichend Zeit zum Experimentieren und zum Debuggen zu nehmen, ehe Sie ein System in die Produktion überführen. Im folgenden Abschnitt möchte ich Ihnen einige hart erarbeitete Lektionen vermitteln, die ich beim Aufbau und der Instandhaltung verteilter Rechensysteme gewonnen habe.
In diesem Kapitel haben Sie sich bereits mit verschiedenen Problemen und Aspekten befasst, z.B. wie das Deployment ausgestaltet werden kann, welche technischen Voraussetzungen die Geräte erfüllen müssen, welche verschiedenen Möglichkeiten es gibt, Fehler zu beheben, und welche Probleme hinsichtlich der Daten auftreten können. Doch es gibt noch weitere Herausforderungen! Sie müssen sich auch Gedanken darüber machen, ob das Modell selbst ausreichend gesichert ist, wenn Sie es auf die Geräte übertragen.
Ein Modell lässt sich, wie Sie bereits in Kapitel 4 erfahren haben, nur schwer vor Reverse Engineering schützen – vor allem wenn das Modell als lokale Kopie vorliegt. Eine Möglichkeit, dies zu verhindern, besteht darin, das Modell an einer bestimmten Schicht (engl. Layer) aufzuteilen (was als Split Learning (https://splitlearning.mit.edu) bezeichnet wird) und nur einige Schichten (feingetunt oder mit Ausgangsgewichtung) an die Geräte zu übertragen. Dadurch wird zwar nicht verhindert, dass die Arbeitsweise des Modells offengelegt wird, aber es wird vermieden, dass das gesamte Modell an alle Geräte gesendet wird.
Für einen umfassenden und wissenschaftlich fundierten Überblick über die Fortschritte und Herausforderungen im Bereich des Federated Learning empfehle ich Ihnen den Artikel »Advances and Open Problems in Federated Learning« (https://oreil.ly/s79IZ), der von mehreren Wissenschaftlern und Fachleuten aus der Praxis verfasst wurde und den gegenwärtigen Stand der Forschung aufzeigt.
Ein weiteres ernst zu nehmendes Sicherheitsrisiko besteht in der Möglichkeit, dass ein Nutzer das zentralisierte Modell »aushebelt« (sei es böswillig oder nur irrtümlich). Data Poisoning ist eine Art von Angriff, bei dem ein Nutzer oder eine Nutzerin bzw. eine ganze Gruppe falsche Daten übermittelt, um das Modell in Richtung einer bestimmten oder einer falschen Vorhersage zu beeinflussen. In einer föderalen Umgebung könnte dies ein Nutzer oder eine Gruppe von Akteuren sein, die gemeinsam an einem Trainingslauf teilnehmen. Data Poisoning Attacks, die in einer Federated-Machine-Learning-Umgebung stattfinden, werden auch als Byzantine Poisoning Attacks (oft in Kurzform als Byzantine Attacks) bezeichnet.6
Um diesem Problem entgegenzuwirken, können Sie ein weiterentwickeltes Auswahlkriterium verwenden und mehrere Modellkandidaten parallel trainieren, die Sie dann jeweils mit separaten Nutzern als Testdatensatz evaluieren. Sie können auch eine Stichprobe der dem Modell übergebenen Daten nehmen und unterstellen, dass Beobachtungen, die sehr große Gradienten aufweisen, untypisch sind, und diese entweder aussortieren oder die Gradienten beschränken (Clamping). Allerdings kann Ihr Modell dann nicht aus Beobachtungen lernen bzw. sich an Daten anpassen, die nicht wirklich bösartig sind.
Andere Ansätze, die für Data Poisoning Attacks und Adversarial Attacks empfohlen werden, sind das Transformieren von Beispielen, um näher an der Mannigfaltigkeit (engl. Manifold) zu sein, (https://oreil.ly/icwSq) oder das Training so zu gestalten, dass Adversarial und Poisoning Attacks berücksichtigt werden (https://oreil.ly/QN4Ip). Zwar lassen sich Angriffe dadurch nicht vollständig ausschließen, aber diese Ansätze sollten dennoch dazu beitragen können, den Einfluss, der von kleinen Gruppen von Akteuren in einem großen verteilten Machine-Learning-Prozess ausgehen kann, zu verringern.
Schließlich gibt es noch ein weiteres Problem: Wenn Ihre Nutzerinnen und Nutzer davon ausgehen, dass an irgendeiner Stelle ein Backup ihrer Daten erstellt wird, wie können Sie dann sicherstellen, dass Daten, die wichtig sind, ordnungsgemäß gesichert werden, wenn Sie sie nicht zentral speichern? Sie könnten den Nutzern ermöglichen, die Daten, die sie zentral gespeichert haben möchten, auf nutzerfreundliche Weise zu identifizieren, oder Sie könnten ihnen entsprechende Backup-Optionen anbieten, die sie gegebenenfalls bereits anwenden, wie z.B. die Daten in der mit dem jeweiligen Konto des Nutzers verbundenen Cloud zu speichern.
Auch in diesem Fall sollten Sie zunächst überlegen, wie Sie Ihren Nutzern eine möglichst datenschutzfreundliche, einwilligungsabhängige und zugleich sichere Lösung anbieten können. In der Praxis gibt es viele Beispiele, in denen im Namen des Nutzers Annahmen getroffen werden, die höchstwahrscheinlich nicht auf alle Nutzer zutreffen (z.B. veraltete Chatnachrichten oder Inhalte, von denen die Nutzer angenommen haben, dass sie nur vorübergehend gespeichert werden, die aber länger als gewünscht vorgehalten werden). Sprechen Sie im Zweifel direkt mit den Nutzern!
Federated Learning und Federated Analytics eröffnen völlig neue Anwendungsbereiche, die sich nicht für eine zentralisierte Datenerfassung eignen. Edge-Geräte, die große Datenmengen erzeugen, sind aufgrund von Konnektivitäts- und Speicherproblemen nicht geeignet, Daten an einen zentralen Dienst zu übermitteln. Da die Rechen- und Speicherleistung von Edge-Geräten zunimmt, ergeben sich neue Möglichkeiten, diese Geräte mit Rechenkapazität auszustatten, anstatt Daten zu zentralisieren, die in den meisten Fällen nicht genutzt werden können oder sollen.
Beispielsweise sind aggregierte IoT-Daten in der Regel wenig nützlich, vor allem weil es schwierig ist, sie mit interessanten Datenquellen wie Wetter-, Standort-, Störungs- und Fehlerdaten oder anderen Umgebungsdaten zu verknüpfen, die nur jemandem zugänglich sind, der sich in der Nähe des Geräts befindet. Wenn diese Daten am Rand des Systems und auf Geräteebene verbleiben und statistische Analysen und/oder Trainings mit diesen Daten am Rand des Systems durchgeführt werden können, könnten diese Systeme die tatsächliche Ursache von Problemen und deren Auswirkungen schneller erkennen, z.B. bei der vorausschauenden Wartung (engl. Predictive Maintenance) oder bei Warnsystemen.
Aufgrund der zusätzlichen Datenschutz- und Sicherheitsmechanismen kann Federated Learning neue Optionen für siloübergreifende Lern- oder Analyseaufgaben eröffnen – bei denen verschiedene Teile einer einzelnen Organisation, die normalerweise keine Daten gemeinsam nutzen, ein Modell erstellen oder Daten gemeinsam analysieren können. Dies kann organisationsübergreifende oder organisationsinterne Datenprojekte ermöglichen, z.B. zwischen Mutter- und Tochterunternehmen oder zwischen verschiedenen Unternehmen, die sich mit unterschiedlichen Aspekten einer Aufgabe befassen, wie z.B. Industriepartnerschaften in den Bereichen Logistik, Operations oder Telekommunikation.
Im Grunde bietet Federated Learning die Möglichkeit, Modelle auf demokratischere Weise mit Nutzerinnen und Nutzern zu teilen. Da Sie Daten der Nutzer zum Trainieren des Modells verwenden, scheint es nur fair zu sein, ihnen auch einen besseren Zugang und mehr Mitsprache zu gewähren. Daraus ergibt sich der zusätzliche Vorteil, dass Sie auch die Personalisierung anders gestalten können. Was wäre, wenn Sie personalisiertere Modelle anbieten könnten, bei denen Sie den lokalen Modellen erlauben, vom zentralen Modell abzuweichen? Die Nutzer würden dann ein personalisiertes Modell erhalten, das besser zu ihren Daten passt – vorausgesetzt, ihre Features und Labels stehen auf lokaler Ebene zur Verfügung. Das bedeutet zugleich, dass Sie keine Kopie dieses Modells besitzen – was Ihren Datenschutzgarantien zugutekäme und gleichzeitig einen Mehrwert für Ihre Nutzer darstellt.
Meiner Meinung nach entspricht dieser Ansatz auch eher der Wahrnehmung der Nutzer hinsichtlich der Art und Weise, wie ihre Daten gespeichert und verwendet werden. Die Schlagzeilen in den Medien, die das öffentliche Bewusstsein über die Funktionsweise von Machine-Learning-Systemen geschärft haben (z.B. dass Menschen die Trainingsdaten einsehen und mit Labels versehen, dass die Daten zentral an einem Ort gespeichert werden, über den der Nutzer keine direkte Kontrolle hat, usw.), haben den Mangel an Transparenz und Verantwortungsbewusstsein deutlich gemacht, den die Branche im Laufe ihrer Entwicklung an den Tag gelegt hat. Es liegt auf der Hand, dass noch ein langer Weg zurückzulegen ist, um das Vertrauen wiederherzustellen. Die Entwicklung von Systemen, bei denen die Nutzerinnen und Nutzer tatsächlich die Kontrolle über ihre Daten haben, ihre Einwilligung gezielt erteilen können und die Möglichkeit bekommen, dass ihre Daten nur lokal gespeichert werden, würde dazu beitragen, den entstandenen Schaden zu beheben und die besondere Bedeutung des Datenschutzes für die betreffenden Produkte, Softwareprogramme oder Dienste zu unterstreichen.
Wenn Sie zu dem Schluss gekommen sind, dass Federated Learning für Ihren speziellen Anwendungsfall geeignet ist, oder wenn Sie ein höheres Maß an Datenschutz und Datensparsamkeit anstreben, müssen Sie zunächst herausfinden, wie Sie das Deployment der Software gestalten und wie Sie die Aggregations- und Orchestrierungsinfrastruktur aufbauen, um die Grundlage für Ihre ersten Schritte zu legen.
Wenn Sie Federated Learning in großem Umfang zum Einsatz bringen wollen, müssen Sie zunächst herausfinden, welche Art von Architektur und Wartung für Ihr Unternehmen geeignet ist. Wenngleich ich persönlich von vollständig föderalen und dezentralisierten Lösungen begeistert bin, verfolgen die meisten der erprobten Frameworks einen semizentralisierten Ansatz.
Daher sollten Sie eng mit den DevOps-, Infrastruktur- und/oder Plattformteams in Ihrem Unternehmen zusammenarbeiten, um die zugrunde liegende Architektur aufeinander abzustimmen und zu implementieren. Falls Sie bereits Software für Edge-Geräte bereitstellen, dürfte sich das nicht so schwer gestalten, wie Sie vielleicht denken.
Hier sind ein paar Einstiegsfragen für die Diskussion:
Stellen Sie sicher, dass Ihr Team beim Testen und Ausrollen der föderalen Infrastruktur auf Unterstützung zählen kann – schließlich handelt es sich um einen recht komplexen Vorgang, bei dem Sie abteilungsübergreifend zusammenarbeiten sollten, damit das Deployment reibungslos vonstattengehen kann. Denken Sie auch daran, dass andere Elemente, wie z.B. die auf den Geräten gespeicherten Logdateien oder Fehlermeldungen, hochsensible Informationen enthalten können und daher als persönlich identifizierende Informationen (PII) behandelt werden müssen.
Kämpfen Sie nicht gegen Windmühlen! Führen Sie zunächst einen Betatest mit einer kleinen Anzahl von Geräten durch, die Ihren Anforderungen in Bezug auf Konnektivität, Rechenleistung und Datenqualität am besten entsprechen. Setzen Sie Prioritäten, um das bestmögliche Ergebnis zu erzielen, und sehen Sie, ob es funktioniert. Wenn Sie während der Entwicklung, des Deployments oder des Trainings auf vorhersehbare oder unvorhersehbare Probleme stoßen, können Sie auf der Grundlage der bestmöglichen Ausgangssituation schneller debuggen und die nächsten Schritte festlegen.
Wenn Sie bislang noch nicht mit Federated Learning arbeiten, sollten Sie sich zunächst mit den Open-Source-Softwarelösungen vertraut machen, bevor Sie ein Deployment durchführen oder Ihre eigene Software entwickeln. Im nächsten Abschnitt lernen Sie eine Open-Source-Bibliothek kennen, mit der Sie ein erstmaliges Deployment testen können.
Sowohl die Open-Source-Community als auch viele der größeren Technologieunternehmen und Start-ups haben sich mittlerweile dem Konzept der verteilten Datenanalyse verschrieben. Es gibt viele quelloffene, gut unterstützte und gepflegte Bibliotheken, mit denen Sie Federated Learning umsetzen können.
Wenn die von Ihnen verwendete Machine-Learning-Bibliothek bereits Federated Learning unterstützt, sollten Sie am besten auf diese zurückgreifen. Verwenden Sie zum Beispiel bereits TensorFlow, ist es ratsam, direkt mit tf-federated (https://oreil.ly/si-JyK) zu arbeiten.
Im folgenden Abschnitt stelle ich Ihnen die Bibliothek Flower vor. Sie ist eine äußerst interessante und nützliche Bibliothek, die von mehreren Forschern aus Cambridge gepflegt wird und die die Möglichkeit bietet, das Machine-Learning-Backend zu wechseln, wobei unter anderem TensorFlow, PyTorch und Hugging Face unterstützt werden.
Da sich Bibliotheken, Funktionalitäten und Open-Source-Angebote schnell verändern können, sollten Sie zunächst herausfinden, was sich für Ihren Anwendungsfall und Ihre Architektur am besten eignet. Federated Learning wird weiterhin intensiv erforscht und findet zunehmend auch in der Praxis Anwendung. Daher sollten Sie sich vorab ein Bild davon machen, ob es neue Bibliotheken gibt, die Ihnen gegebenenfalls zusätzliche Möglichkeiten eröffnen.
Die Entwickler von Flower haben sich zum Ziel gesetzt, eine einheitliche Benutzeroberfläche für verschiedene Federated-Learning-Backends wie TensorFlow, PyTorch, Hugging Face, MXNet und scikit-learn zu schaffen. Flower stellt auch Emulatoren für iOS und Android zur Verfügung und bietet Unterstützung für Ray (https://oreil.ly/CMMTH), eine Bibliothek und Community, die sich auf Distributed Data Analysis, Analytics und Machine Learning spezialisiert hat.
Darüber hinaus unterstützt Flower einfache Abfragen, mit denen Sie gezielt einzelne Werte von den Knotenpunkten abrufen können. In der Dokumentation (https://flower.dev) finden Sie noch weitere Beispiele und eine Reihe von Google-Colab-Notebooks.
Das vollständige Notebook und die dazugehörigen Skripte finden Sie im Code-Repository des Buchs, wobei das Repository ein wenig anders aufgebaut ist als der hier vorgestellte Code. Der folgende Code stammt aus einem der vielen hilfreichen Beispiele in der Dokumentation und zeigt, wie Sie mithilfe der integrierten Klassen eigene Strategien zur Verwaltung Ihres föderalen Trainings einrichten können:
strategy = fl.server.strategy.FedAvg(
fraction_fit=0.1,
min_fit_clients=10, # Mindestanzahl der Clients, die beim
# nächsten Trainingslauf ausgewählt werden
min_available_clients=80, # Mindestanzahl der Clients, die mit dem
# Server verbunden sein müssen, bevor
# ein Trainingslauf beginnen kann
)
Gehen wir die einzelnen Parameter einmal durch, damit Sie besser nachvollziehen können, was sie bewirken:
In diesem Codebeispiel wird als Strategie ein Federated Averaging verfolgt, das dem ursprünglichen Algorithmus entspricht, der im Jahr 2017 von Forschern von Google vorgeschlagen wurde (https://oreil.ly/xTH_4). Seitdem wurde er in vielen Federated-Learning-Bibliotheken implementiert. Bei dem Algorithmus werden die aktualisierten Gradienten der einzelnen Clientmodelle gesammelt – in der Regel nachdem zuvor einige Trainingsläufe auf lokaler Ebene durchgeführt worden sind –, und diese werden dann über den Aggregationsserver aggregiert, der den Durchschnitt aller aktualisierten Gradienten bildet, um einen föderalen Durchschnitt für den Gradienten zu ermitteln. Dieser durchschnittliche Gradient wird dann an die Geräte gesendet, auf denen daraufhin weitere Trainingsläufe durchgeführt werden.
Dieser grundlegende Ansatz lässt sich noch verbessern. Hierfür gibt es zahlreiche Algorithmen, bei denen es sich lohnt, sie einmal auszuprobieren, z.B. Federated Averaging mit Client-level Momentum (https://oreil.ly/JX6HS), Byzantine-Robust Federated Averaging (https://oreil.ly/y9oUk) und mehrere innovative Ansätze, die Sie in dem Artikel »Advances and Open Problems in Federated Learning« (https://oreil.ly/YUtFw) nachvollziehen können. Gegenwärtig wird intensiv daran geforscht, Aggregationsalgorithmen zu entwickeln, die Differential Privacy und Encrypted Computation als Garantien bieten, was oftmals als private and secure Aggregation bezeichnet wird. Weitere Einzelheiten hierzu erfahren Sie in Kapitel 7.
Mit den in der Dokumentation des Flower-Frameworks enthaltenen Tutorials, in denen die verschiedenen Strategien vorgestellt werden (https://oreil.ly/_s9RA), können Sie noch mehr über diese Strategien erfahren und wie Sie Ihre eigene Strategy-Klasse erstellen können.
Flower verfügt auch über ein Simulationsmodul, mit dem etwaige Fehler zunächst simuliert werden, wodurch Sie einfacher debuggen können. Dies lässt sich wie im folgenden Code umsetzen:
fl.simulation.start_simulation(
client_fn=client_fn,
num_clients=NUM_CLIENTS,
config=fl.server.ServerConfig(num_rounds=100),
strategy=strategy,
)
Die Simulationsmethode erfordert einige Schlüsselwortparameter, unter anderem eine Funktion, die der Instanziierung der Clients dient, die Anzahl der zu startenden Clients, die Serverkonfigurationen und die zu verfolgende Strategie. Beachten Sie, dass Sie eine Vielzahl von Simulationen durchführen müssen, um zu ermitteln, was Ihrer tatsächlichen Nutzung am ähnlichsten ist. Wenn Sie Android-, iOS- oder Embedded-Devices simulieren möchten, sollten Sie die integrierten Tools der Bibliothek nutzen.
Wird dieser Code ausgeführt, wird im Hintergrund eine auf dem Ray-Framework basierende Simulation erstellt. Ray verfügt über eine eigene Methode zur Verwaltung von Clustern, über die Sie mehr in der Dokumentation (https://oreil.ly/2s-_X) erfahren können. Bei Flower wird dagegen eine Abstraktion verwendet, die sich hervorragend dafür eignet, lokale Simulationen und Tests durchzuführen. Bevor Sie Flower in einer Staging- oder Produktionsumgebung einsetzen, sollten Sie sich zunächst eingehend mit diesen Abstraktionen vertraut machen.
Nachdem Sie einige Simulationsläufe durchgeführt haben, können Sie Flower mit einer Reihe verbundener Geräte ausführen. Entwickeln Sie Applikationen für mobile Endgeräte, können Sie einen entsprechenden Dienst nutzen oder sogar Ihr eigenes Gerätelabor haben.
Damit Flower auf den Geräten ausgeführt werden kann, müssen Sie zunächst einen innerhalb Ihrer Architektur betriebenen Server einrichten und diesen den Clients über SSL zur Verfügung stellen. In der Dokumentation gibt es einen kurzen Abschnitt (https://oreil.ly/wA2pL), in dem beschrieben wird, wie sich dies bewerkstelligen lässt. Allerdings sollte Ihr Infrastruktur- und Softwareteam dafür sorgen, dass der Server gesichert ist und über eine solide Rechen- und Speicherleistung sowie eine Load-Balancing-Strategie verfügt, sofern Sie eine hohe Last von den verbundenen Geräten erwarten.
Anschließend müssen Sie Flower auf den Geräten installieren und deployen. Dabei müssen Sie sicherstellen, dass die Clientseite startet und ausreichend viele Geräte zur Verfügung stehen, damit die Mindestanzahl an Geräten, die für die von Ihnen gewählte Strategie erforderlich ist, erreicht wird. Außerdem sollten Sie sicherstellen, dass sich die Federated Clients problemlos in die Software integrieren lassen, die Sie bereits auf den Geräten einsetzen. Wenn Sie sich ein Bild davon machen möchten, wie die Konfiguration aussehen könnte, schauen Sie sich die clientspezifische Dokumentation (https://oreil.ly/UCYyq) und die entsprechenden Architekturdiagramme (https://oreil.ly/FcrRS) an.
Sie sind nun in der Lage, Ihre erste Analyse bzw. Ihr erstes Machine-Learning-Modell in die Produktion zu überführen. Nachdem Sie Ihre ersten erfolgreichen Analysen aufgesetzt bzw. Modelle implementiert haben, werden Sie das nötige Selbstvertrauen entwickelt haben, um weitere Iterationen und Versuche durchzuführen. Mit jedem neuen Modell bzw. jeder neuen Analyse können Sie die Risiken in Bezug auf den Datenschutz verringern und sich nach und nach Kenntnisse darüber aneignen, wie Data Science mit weniger zentralisierten Daten durchgeführt werden kann.
Flower ist, wie bereits erwähnt, nur eine von vielen neueren Federated-Learning-Bibliotheken, die für Distributed Data Science und Federated Learning entwickelt wurden. Dieser Bereich wird in den kommenden Jahren noch erheblich an Bedeutung gewinnen, was nicht nur zu einem größeren Angebot an Open-Source-Bibliotheken führen wird, sondern auch dazu, dass die Verwendung von Daten so umstrukturiert werden kann, dass sie den realen Problemen, die in der Data Science gelöst werden sollen, besser entsprechen.
Ich bin fest davon überzeugt, dass Distributed Data Science, Analytics und Machine Learning unsere Zukunft sind. Werfen wir einen Blick auf einige Beispiele, die zeigen, wie Datenanalysen und Data Science im Edge-Bereich dazu beitragen können, die Probleme von heute zu lösen.
Kommunen, Landkreise und Bundesländer könnten beispielsweise den Anbau und die Versorgung mit Nahrungsmitteln durch intelligente landwirtschaftliche Geräte steuern, die den durchschnittlichen Ertrag pro Pflanze ermitteln. Diese Daten könnten dann aggregiert werden, um Fragen wie »Werden wir genug zu essen haben?« zu beantworten. Anstatt diese Daten bei einem Agrarriesen zentral zusammenlaufen zu lassen, könnten sie an die zuständigen Kommunal- oder Landesregierungen oder an landwirtschaftliche Verbände weitergeleitet werden, um eine bessere Planung und Koordination zu ermöglichen.
Die COVID-19-Pandemie hat gezeigt, dass mit kleinräumigen Daten, wie z.B. von kleinen Embedded Devices in Krankenhäusern, Anstiege von Neuinfektionen verfolgt werden konnten. Anhand dieser Daten konnten potenzielle Infektionswellen identifiziert und die Ausbreitung des Virus mithilfe intelligenter Modellierung eingedämmt werden, die wiederum als Grundlage für Empfehlungen und Vorschriften im Bereich der öffentlichen Gesundheit herangezogen werden konnte. Auf diese Weise erhielten die Gesundheitsbehörden bessere Informationen, während die Privatsphäre der Betroffenen gewahrt blieb.
Mit vernetzten Wetter- und Wassersensoren, die eine bessere Lageeinschätzung ermöglichen, könnten den sich immer stärker ausweitenden Klimakatastrophen besser begegnet werden, was zu Früherkennungs- und Warnsystemen führen würde, die durch eine föderale Datenaggregation auf Basis von Edge-Geräten betrieben werden.
Diese Beispiele sind erst der Anfang. Wenn Daten verstärkt auf lokaler Ebene genutzt werden, eröffnen sich neue Möglichkeiten für ein kollektives Eigentum an Daten. Wenn Daten in kollektivem Eigentum stehen und kollektiv verwaltet werden, ergeben sich Anwendungsfälle, bei denen Gewinn und Kontrolle nicht an einer zentralen Stelle konzentriert sind. Wenn Nutzer, Nutzergruppen oder sogar diverse Datenanbieter in die Lage versetzt werden, sich gegenseitig bei der Analyse von Datenproblemen zu helfen und herauszufinden, wie sie ihre eigenen Modelle über bessere und benutzerfreundlichere Schnittstellen trainieren können, dann ergibt sich ein ganz anderes Bild davon, wozu Machine Learning eingesetzt werden kann.
Durch den Übergang zu einer kollektiv genutzten und kollektiv verwalteten Art, über Daten nachzudenken, werden bestehende Beschränkungen in Möglichkeiten umgewandelt. Die begrenzte Rechenleistung wird zu einem praktischen Mittel, mit dem Communitys gemeinsam daran arbeiten können, Probleme auf lokaler Ebene zu lösen. Diese Communitys vernetzen sich und tauschen ihr Wissen aus, ohne dass die Daten zentralisiert oder das Eigentum an ihnen geteilt werden muss. Die Welt verlagert sich bereits immer mehr auf die Ebene der Endgeräte. Ich hoffe, dass wir dies als Chance nutzen können, um für uns und unsere Welt bessere Fragen zu stellen und zu beantworten.
In diesem Kapitel haben Sie mehr über die verteilte Datenanalyse und das Federated Learning erfahren und darüber, wie Sie diese auf Ihren eigenen Anwendungsfall oder Ihr eigenes Problem anwenden können. Sie haben auch die Herausforderungen und Möglichkeiten dieser Technologien kennengelernt – einschließlich der Frage, wie Sie die Datenschutzgarantien erhöhen können, indem Sie föderale Ansätze mit Konzepten kombinieren, die Sie bereits kennen, wie Differential Privacy und Trust Boundaries.
Sie haben gelernt, wie sich der Einsatz und die Architektur von föderalen Systemen auf Ihre Anwendungsfälle auswirken können und werden, und Sie hatten die Gelegenheit, eine Open-Source-Federated-Learning-Bibliothek auszuprobieren und zu sehen, wie deren Einsatz unter realen Bedingungen aussehen könnte. Darüber hinaus haben Sie bestenfalls darüber reflektiert, wie Federated Learning und verteilte Datenanalysen neue Möglichkeiten eröffnen, die die Art und Weise, wie Sie Daten verwalten und über sie nachdenken, grundlegend verändern können.
Im nächsten Kapitel werden Sie sich mit Encrypted Computation befassen. Diese Technologie kann, wie ich bereits in diesem und anderen Kapiteln erwähnt habe, dazu beitragen, den Datenschutz, die Vertraulichkeit und die Sicherheit zu verbessern und die Art und Weise, wie Vertrauen in verteilten Systemen gestaltet wird, zu verändern.
