Zapisz datę! Google I / O powraca w dniach 18-20 maja Zarejestruj się teraz
Ta strona została przetłumaczona przez Cloud Translation API.
Switch to English

Federated Learning

Przegląd

W tym dokumencie przedstawiono interfejsy, które ułatwiają zadania uczenia federacyjnego, takie jak szkolenie federacyjne lub ocena z istniejącymi modelami uczenia maszynowego zaimplementowanymi w TensorFlow. Projektując te interfejsy, naszym głównym celem było umożliwienie eksperymentowania z uczeniem federacyjnym bez konieczności posiadania wiedzy o tym, jak działa on pod maską, oraz ocenę zaimplementowanych algorytmów uczenia federacyjnego na różnych istniejących modelach i danych. Zachęcamy do współtworzenia platformy. TFF został zaprojektowany z myślą o rozszerzalności i komponowalności, dlatego mile widziany jest wkład; nie możemy się doczekać, aby zobaczyć, co wymyślisz!

Interfejsy oferowane przez tę warstwę składają się z trzech kluczowych części:

  • Modele . Klasy i funkcje pomocnicze, które pozwalają opakować istniejące modele do użycia z TFF. Zawijanie modelu może być tak proste, jak wywołanie pojedynczej funkcji opakowującej (np. tff.learning.from_keras_model ) lub zdefiniowanie podklasy interfejsu tff.learning.Model celu pełnego dostosowania.

  • Sfederowane konstruktory obliczeń . Funkcje pomocnicze, które konstruują federacyjne obliczenia na potrzeby szkolenia lub oceny przy użyciu istniejących modeli.

  • Zestawy danych . Gotowe kolekcje danych, które można pobierać i uzyskiwać do nich dostęp w języku Python do użytku w symulowaniu scenariuszy uczenia się federacyjnego. Chociaż uczenie federacyjne jest przeznaczone do użytku ze zdecentralizowanymi danymi, których nie można po prostu pobrać w scentralizowanej lokalizacji, na etapach badań i rozwoju często wygodnie jest przeprowadzić wstępne eksperymenty z wykorzystaniem danych, które można pobrać i manipulować lokalnie, zwłaszcza dla programistów, którzy mogą być nowość w podejściu.

Te interfejsy są zdefiniowane głównie w przestrzeni nazw tff.learning , z wyjątkiem zestawów danych badawczych i innych możliwości związanych z symulacją, które zostały zgrupowane w tff.simulation . Ta warstwa jest implementowana przy użyciu interfejsów niższego poziomu oferowanych przez Federated Core (FC) , który zapewnia również środowisko wykonawcze.

Przed kontynuowaniem zalecamy najpierw przejrzenie samouczków dotyczących klasyfikacji obrazów i generowania tekstu , ponieważ wprowadzają one większość opisanych tutaj koncepcji na konkretnych przykładach. Jeśli chcesz dowiedzieć się więcej o tym, jak działa TFF, możesz przejrzeć samouczek niestandardowych algorytmów jako wprowadzenie do interfejsów niższego poziomu, których używamy do wyrażania logiki obliczeń federacyjnych i przestudiować istniejącą implementację interfejsy tff.learning .

Modele

Założenia architektoniczne

Serializacja

TFF ma na celu obsługę różnych scenariuszy rozproszonego uczenia się, w których kod modelu uczenia maszynowego, który piszesz, może być wykonywany na dużej liczbie heterogenicznych klientów o zróżnicowanych możliwościach. Chociaż na jednym końcu spektrum w niektórych aplikacjach klienci ci mogą być potężnymi serwerami baz danych, wiele ważnych zastosowań, które nasza platforma zamierza obsługiwać, obejmuje urządzenia mobilne i wbudowane o ograniczonych zasobach. Nie możemy zakładać, że te urządzenia są w stanie obsługiwać środowiska wykonawcze Pythona; jedyną rzeczą, jaką możemy założyć w tym momencie, jest to, że są w stanie hostować lokalne środowisko wykonawcze TensorFlow. W związku z tym podstawowym założeniem architektonicznym, które poczynimy w TFF, jest to, że kod modelu musi być serializowany jako wykres TensorFlow.

Możesz (i powinieneś) nadal rozwijać swój kod TF zgodnie z najnowszymi najlepszymi praktykami, takimi jak używanie trybu eager. Jednak końcowy kod musi być tf.function do serializacji (np. Może być opakowany jako tf.function dla kodu w trybie tf.function ). Gwarantuje to, że każdy stan Pythona lub przepływ sterowania niezbędny w czasie wykonywania można serializować (prawdopodobnie za pomocą autografu ).

Obecnie TensorFlow nie obsługuje w pełni serializacji i deserializacji TensorFlow w trybie przyspieszonym. Zatem serializacja w TFF jest obecnie zgodna ze wzorcem TF 1.0, gdzie cały kod musi być zbudowany wewnątrz tf.Graph który kontroluje TFF. Oznacza to, że obecnie TFF nie może konsumować już zbudowanego modelu; zamiast tego logika definicji modelu jest spakowana w funkcji tff.learning.Model która zwraca tff.learning.Model . Ta funkcja jest następnie wywoływana przez TFF w celu zapewnienia serializacji wszystkich komponentów modelu. Ponadto, będąc silnie typizowanym środowiskiem, TFF będzie wymagał trochę dodatkowych metadanych , takich jak specyfikacja typu danych wejściowych twojego modelu.

Zbiór

Zdecydowanie zalecamy większości użytkowników tworzenie modeli przy użyciu Keras, zobacz sekcję Konwertery dla Keras poniżej. Te opakowania obsługują agregację aktualizacji modelu, a także wszelkie metryki zdefiniowane dla modelu automatycznie. Jednak nadal może być przydatne zrozumienie, w jaki sposób jest obsługiwana agregacja dla ogólnego tff.learning.Model .

W uczeniu federacyjnym zawsze istnieją co najmniej dwie warstwy agregacji: lokalna agregacja na urządzeniu i agregacja między urządzeniami (lub federacyjna):

  • Lokalna agregacja . Ten poziom agregacji odnosi się do agregacji w wielu partiach przykładów należących do pojedynczego klienta. Dotyczy to zarówno parametrów modelu (zmiennych), które ewoluują sekwencyjnie, gdy model jest trenowany lokalnie, jak i obliczanych statystyk (takich jak średnia strata, dokładność i inne metryki), które model ponownie zaktualizuje lokalnie podczas iteracji po lokalnym strumieniu danych każdego klienta.

    Za wykonanie agregacji na tym poziomie odpowiada kod modelu i jest ona wykonywana przy użyciu standardowych konstrukcji TensorFlow.

    Ogólna struktura przetwarzania jest następująca:

    • Model najpierw konstruuje tf.Variable do przechowywania agregatów, takich jak liczba partii lub liczba przetworzonych przykładów, suma strat na partię lub na przykład itp.

    • TFF wywołuje metodę forward_pass w Model wiele razy, sekwencyjnie w kolejnych partiach danych klienta, co pozwala aktualizować zmienne przechowujące różne agregaty jako efekt uboczny.

    • Na koniec TFF wywołuje metodę report_local_outputs w modelu, aby umożliwić modelowi skompilowanie wszystkich zebranych statystyk podsumowujących w zwarty zestaw metryk do wyeksportowania przez klienta. W tym miejscu kod modelu może na przykład podzielić sumę strat przez liczbę przykładów przetworzonych w celu wyeksportowania średniej straty itp.

  • Agregacja federacyjna . Ten poziom agregacji odnosi się do agregacji na wielu klientach (urządzeniach) w systemie. Ponownie dotyczy to zarówno parametrów modelu (zmiennych), które są uśredniane dla klientów, jak i metryk, które model wyeksportował w wyniku lokalnej agregacji.

    Za przeprowadzenie agregacji na tym poziomie odpowiada TFF. Jako twórca modelu możesz jednak kontrolować ten proces (więcej na ten temat poniżej).

    Ogólna struktura przetwarzania jest następująca:

    • Model początkowy i wszelkie parametry wymagane do szkolenia są dystrybuowane przez serwer do podzbioru klientów, którzy wezmą udział w rundzie szkolenia lub oceny.

    • Na każdym kliencie, niezależnie i równolegle, kod modelu jest wywoływany wielokrotnie w strumieniu lokalnych partii danych w celu utworzenia nowego zestawu parametrów modelu (podczas uczenia) oraz nowego zestawu metryk lokalnych, jak opisano powyżej (jest to lokalna zbiór).

    • TFF obsługuje rozproszony protokół agregacji w celu gromadzenia i agregowania parametrów modelu oraz metryk eksportowanych lokalnie w całym systemie. Ta logika jest wyrażana w sposób deklaratywny przy użyciu własnego federacyjnego języka obliczeń TFF (nie w TensorFlow), w federated_output_computation modelu federated_output_computation. Zobacz samouczek algorytmów niestandardowych, aby uzyskać więcej informacji na temat interfejsu API agregacji.

Abstrakcyjne interfejsy

Ten podstawowy konstruktor + interfejs metadanych jest reprezentowany przez interfejs tff.learning.Model w następujący sposób:

  • Konstruktor, metody forward_pass i report_local_outputs powinny odpowiednio konstruować zmienne modelu, przebieg do przodu i statystyki, które chcesz raportować. TensorFlow skonstruowany za pomocą tych metod musi być możliwy do serializacji, jak omówiono powyżej.

  • Właściwość input_spec , a także 3 właściwości, które zwracają podzbiory zmiennych input_spec trenowania, nienadających się do trenowania i zmiennych lokalnych, reprezentują metadane. TFF wykorzystuje te informacje do określenia, jak połączyć części twojego modelu z federacyjnymi algorytmami optymalizacji oraz do zdefiniowania wewnętrznych sygnatur typu, aby pomóc w weryfikacji poprawności skonstruowanego systemu (tak, że twój model nie może być utworzony na danych, które nie pasują do tego, co model jest przeznaczony do konsumpcji).

Ponadto, abstrakcyjny interfejs tff.learning.Model naraża nieruchomość federated_output_computation , że wraz z report_local_outputs nieruchomość wspomniano wcześniej, pozwala kontrolować proces agregacji statystyk podsumowania.

Przykłady definiowania własnego niestandardowego tf.learning.Model można znaleźć w drugiej części naszego samouczka dotyczącego klasyfikacji obrazów , a także w przykładowych modelach, których używamy do testowania w model_examples.py .

Konwertery dla Keras

Prawie wszystkie informacje wymagane przez TFF można uzyskać, wywołując interfejsy tf.keras , więc jeśli masz model Keras, możesz polegać na tff.learning.from_keras_model aby skonstruować tff.learning.Model .

Zwróć uwagę, że TFF nadal chce, abyś udostępnił konstruktor - bezargumentową funkcję modelu, taką jak następujące:

def model_fn():
  keras_model = ...
  return tff.learning.from_keras_model(keras_model, sample_batch, loss=...)

Oprócz samego modelu, dostarczasz przykładową partię danych, których TFF używa do określenia typu i kształtu danych wejściowych twojego modelu. Gwarantuje to, że TFF może poprawnie utworzyć instancję modelu dla danych, które będą faktycznie obecne na urządzeniach klienckich (ponieważ zakładamy, że te dane nie są ogólnie dostępne w czasie konstruowania TensorFlow do serializacji).

Użycie opakowań Keras jest zilustrowane w naszych samouczkach dotyczących klasyfikacji obrazów i generowania tekstu .

Sfederowane konstruktory obliczeń

Pakiet tff.learning udostępnia kilka konstruktorów dla tff.Computation które wykonują zadania związane z uczeniem się; spodziewamy się, że w przyszłości zestaw takich obliczeń będzie się rozszerzał.

Założenia architektoniczne

Wykonanie

Istnieją dwie odrębne fazy wykonywania obliczeń stowarzyszonych.

  • Kompiluj : TFF najpierw kompiluje federacyjne algorytmy uczenia się w abstrakcyjną serializowaną reprezentację całego rozproszonego obliczenia. Dzieje się tak, gdy ma miejsce serializacja TensorFlow, ale mogą wystąpić inne transformacje w celu obsługi bardziej wydajnego wykonywania. Odnosimy się do serializowanej reprezentacji emitowanej przez kompilator jako obliczenie federacyjne .

  • Wykonaj TFF zapewnia sposoby wykonywania tych obliczeń. Na razie wykonanie jest obsługiwane tylko przez lokalną symulację (np. W notebooku wykorzystującym symulowane zdecentralizowane dane).

Obliczenia federacyjne generowane przez Federated Learning API TFF, takie jak algorytm uczący, który wykorzystuje uśrednianie modelu federacyjnego lub ocenę federacyjną, obejmuje szereg elementów, w szczególności:

  • Zserializowana forma kodu modelu, a także dodatkowy kod TensorFlow utworzony przez platformę Federated Learning w celu sterowania pętlą uczenia / oceny modelu (np. Konstruowanie optymalizatorów, stosowanie aktualizacji modelu, iterowanie potf.data.Dataset s i metryki obliczeniowe i zastosowanie zbiorczej aktualizacji na serwerze, żeby wymienić tylko kilka).

  • Deklaratywna specyfikacja komunikacji między klientami a serwerem (zazwyczaj różne formy agregacji na urządzeniach klienckich i rozgłaszanie z serwera do wszystkich klientów) oraz sposób, w jaki ta rozproszona komunikacja jest przeplatana z wykonaniem lokalnym lub lokalnym na serwerze kodu TensorFlow.

Obliczenia federacyjne reprezentowane w tej postaci serializowanej są wyrażane w niezależnym od platformy języku wewnętrznym innym niż Python, ale aby korzystać z Federated Learning API, nie musisz zajmować się szczegółami tej reprezentacji. Obliczenia są reprezentowane w kodzie Pythona jako obiekty typu tff.Computation , które w większości można traktować jako nieprzejrzyste pliki callable Pythonie.

W samouczkach te obliczenia federacyjne będą wywoływane tak, jakby były zwykłymi funkcjami języka Python, które mają być wykonywane lokalnie. Jednak TFF jest przeznaczony do wyrażania obliczeń federacyjnych w sposób niezależny od większości aspektów środowiska wykonawczego, dzięki czemu można je potencjalnie wdrożyć np. W grupach urządzeń z systemem Android lub w klastrach w centrum danych. Ponownie, główną konsekwencją tego są silne założenia dotyczące serializacji . W szczególności po wywołaniu jednej z metod build_... opisanych poniżej obliczenia są w pełni serializowane.

Stan modelowania

TFF to funkcjonalne środowisko programowania, ale wiele procesów będących przedmiotem zainteresowania w federacyjnym uczeniu się ma charakter stanowy. Na przykład pętla szkoleniowa, która obejmuje wiele rund uśredniania modelu federacyjnego, jest przykładem tego, co możemy zaklasyfikować jako proces stanowy . W tym procesie stan, który ewoluuje od rundy do rundy, obejmuje zestaw parametrów modelu, które są trenowane, i ewentualnie dodatkowy stan związany z optymalizatorem (np. Wektor pędu).

Ponieważ TFF jest funkcjonalny, procesy stanowe są modelowane w TFF jako obliczenia, które akceptują bieżący stan jako dane wejściowe, a następnie dostarczają zaktualizowany stan jako dane wyjściowe. Aby w pełni zdefiniować proces stanowy, należy również określić, skąd pochodzi stan początkowy (w przeciwnym razie nie możemy załadować procesu). Jest to ujęte w definicji klasy pomocniczej tff.templates.IterativeProcess , z dwiema właściwościami initialize a next odpowiadającymi odpowiednio inicjalizacji i iteracji.

Dostępne konstruktory

W tej chwili TFF zapewnia dwie funkcje konstruktora, które generują federacyjne obliczenia dla federacyjnego szkolenia i oceny:

Zestawy danych

Założenia architektoniczne

Wybór klienta

W typowym scenariuszu uczenia federacyjnego mamy dużą populację potencjalnie setek milionów urządzeń klienckich, z których tylko niewielka część może być aktywna i dostępna do szkolenia w dowolnym momencie (na przykład może to być ograniczone do klientów, którzy są podłączony do źródła zasilania, a nie do sieci z pomiarem i w inny sposób bezczynny). Generalnie grupa klientów, z którymi można uczestniczyć w szkoleniu lub ocenie, jest poza kontrolą dewelopera. Ponadto, ponieważ koordynacja milionów klientów jest niepraktyczna, typowa runda szkolenia lub oceny obejmie tylko ułamek dostępnych klientów, z których można wybierać losowo .

Kluczową konsekwencją tego jest to, że obliczenia federacyjne, zgodnie z projektem, są wyrażane w sposób nieświadomy dokładnego zbioru uczestników; całe przetwarzanie jest wyrażane jako zagregowane operacje na abstrakcyjnej grupie anonimowych klientów , a ta grupa może się różnić w zależności od rundy szkolenia. Rzeczywiste powiązanie obliczenia z konkretnymi uczestnikami, a tym samym z konkretnymi danymi, które wprowadzają do obliczenia, jest zatem modelowane poza samym obliczeniem.

Aby zasymulować realistyczne wdrożenie sfederowanego kodu uczenia się, zazwyczaj napiszesz pętlę szkoleniową, która wygląda następująco:

trainer = tff.learning.build_federated_averaging_process(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

while True:
  data_for_this_round = sample(federated_training_data)
  state, metrics = trainer.next(state, data_for_this_round)

Aby to ułatwić, podczas korzystania z TFF w symulacjach dane federacyjne są akceptowane jako list Pythona, z jednym elementem na każde uczestniczące urządzenie klienckie, który reprezentuje lokalnytf.data.Dataset tego urządzenia.

Abstrakcyjne interfejsy

W celu ujednolicenia postępowania z symulowanymi zestawami danych federacyjnych, TFF zapewnia abstrakcyjny interfejs tff.simulation.datasets.ClientData , który umożliwia wyliczenie zestawu klientów i skonstruowanietf.data.Dataset zawierającego dane określonego klient. Tetf.data.Dataset można podawać bezpośrednio jako dane wejściowe do generowanych obliczeń stowarzyszonych w trybietf.data.Dataset .

Należy zauważyć, że możliwość dostępu do tożsamości klientów jest funkcją zapewnianą przez zbiory danych wyłącznie do wykorzystania w symulacjach, gdzie może być potrzebna możliwość uczenia się na danych z określonych podzbiorów klientów (np. W celu symulacji dziennej dostępności różnych rodzaje klientów). Skompilowane obliczenia i bazowe środowisko wykonawcze nie obejmują żadnego pojęcia tożsamości klienta. Po wybraniu danych z określonego podzbioru klientów jako danych wejściowych, np. W wywołaniu tff.templates.IterativeProcess.next , tożsamości klientów nie są już w nim wyświetlane.

Dostępne zestawy danych

tff.simulation.datasets nazw tff.simulation.datasets przeznaczyliśmy dla zestawów danych, które implementują interfejs tff.simulation.datasets.ClientData do użytku w symulacjach, i tff.simulation.datasets.ClientData ją w 2 zestawy danych w celu obsługi samouczków dotyczących klasyfikacji obrazów i generowania tekstu . Zachęcamy do przesyłania własnych zestawów danych na platformę.