Sfederowane uczenie się

Przegląd

W tym dokumencie przedstawiono interfejsy ułatwiające zadania związane z stowarzyszonym uczeniem się, takie jak stowarzyszone szkolenie lub ocena, z istniejącymi modelami uczenia maszynowego zaimplementowanymi w TensorFlow. Projektując te interfejsy, naszym głównym celem było umożliwienie eksperymentowania ze stowarzyszonym uczeniem się bez konieczności posiadania wiedzy o tym, jak to działa pod maską, a także ocena zaimplementowanych algorytmów stowarzyszonego uczenia się na różnych istniejących modelach i danych. Zachęcamy do ponownego wniesienia wkładu na platformę. TFF został zaprojektowany z myślą o rozszerzalności i możliwości komponowania, dlatego mile widziane są wszelkie uwagi; nie możemy się doczekać, co wymyślisz!

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

• Modele . Klasy i funkcje pomocnicze, które pozwalają opakować istniejące modele do użytku z TFF. Zawijanie modelu może być tak proste, jak wywołanie pojedynczej funkcji opakowującej (np. tff.learning.models.from_keras_model ) lub zdefiniowanie podklasy interfejsu tff.learning.models.VariableModel w celu zapewnienia pełnej możliwości dostosowywania.

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

• Zbiory danych . Gotowe kolekcje danych, które można pobrać i uzyskać do nich dostęp w języku Python w celu wykorzystania w symulowaniu scenariuszy uczenia się stowarzyszonego. Chociaż stowarzyszone uczenie się jest przeznaczone do stosowania w przypadku zdecentralizowanych danych, których nie można po prostu pobrać z centralnej lokalizacji, na etapach badań i rozwoju często wygodnie jest przeprowadzić wstępne eksperymenty z wykorzystaniem danych, które można pobrać i którymi można manipulować lokalnie, szczególnie w przypadku programistów, którzy mogą nowość w podejściu.

Interfejsy te są zdefiniowane głównie w przestrzeni nazw tff.learning , z wyjątkiem zbiorów danych badawczych i innych funkcji związanych z symulacją, które zostały zgrupowane w tff.simulation . Warstwa ta 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 zapoznanie się z tutorialami dotyczącymi klasyfikacji obrazów i generowania tekstu , ponieważ przedstawiają one większość opisanych tutaj koncepcji na konkretnych przykładach. Jeśli chcesz dowiedzieć się więcej o działaniu TFF, możesz przejrzeć samouczek dotyczący algorytmów niestandardowych jako wprowadzenie do interfejsów niższego poziomu, których używamy do wyrażania logiki obliczeń stowarzyszonych, oraz do przestudiowania istniejącej implementacji algorytmu interfejsy tff.learning .

Modele

Założenia architektoniczne

Serializacja

TFF ma na celu obsługę różnych scenariuszy uczenia się rozproszonego, w których napisany kod modelu uczenia maszynowego może być wykonywany na dużej liczbie heterogenicznych klientów o różnych możliwościach. Choć na jednym końcu spektrum, w niektórych aplikacjach klientami mogą być potężne serwery 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; jedyne, co możemy w tym momencie założyć, to to, że są w stanie hostować lokalne środowisko wykonawcze TensorFlow. Zatem podstawowym założeniem architektonicznym, jakie przyjmujemy w TFF, jest to, że kod modelu musi umożliwiać serializację jako wykres TensorFlow.

Możesz (i powinieneś) nadal rozwijać swój kod TF zgodnie z najnowszymi najlepszymi praktykami, takimi jak korzystanie z trybu chętnego. Jednakże końcowy kod musi nadawać się do serializacji (np. może być opakowany jako tf.function dla kodu w trybie gotowości). Zapewnia to możliwość serializacji dowolnego stanu Pythona lub przepływu sterowania niezbędnego w czasie wykonywania (prawdopodobnie za pomocą Autograph ).

Obecnie TensorFlow nie obsługuje w pełni serializacji i deserializacji TensorFlow w trybie chętnym. Zatem serializacja w TFF jest obecnie zgodna ze wzorcem TF 1.0, gdzie cały kod musi być skonstruowany wewnątrz tf.Graph kontrolowanego przez TFF. Oznacza to, że obecnie TFF nie może zużyć już zbudowanego modelu; zamiast tego logika definicji modelu jest spakowana w funkcji bez argumentu, która zwraca wartość tff.learning.models.VariableModel . Ta funkcja jest następnie wywoływana przez TFF, aby upewnić się, że wszystkie komponenty modelu są serializowane. Ponadto, będąc środowiskiem o silnym typie, TFF będzie wymagało trochę dodatkowych metadanych , takich jak specyfikacja typu danych wejściowych modelu.

Zbiór

Zdecydowanie zalecamy, aby większość użytkowników konstruowała modele przy użyciu Keras, zobacz sekcję Konwertery dla Keras poniżej. Te opakowania obsługują agregację aktualizacji modelu, a także wszelkich metryk zdefiniowanych dla modelu automatycznie. Jednak nadal przydatne może być zrozumienie, w jaki sposób agregacja jest obsługiwana w przypadku ogólnego tff.learning.models.VariableModel .

W uczeniu stowarzyszonym zawsze istnieją co najmniej dwie warstwy agregacji: agregacja lokalna na urządzeniu i agregacja na różnych urządzeniach (lub agregacja stowarzyszona):

• Agregacja lokalna . Ten poziom agregacji odnosi się do agregacji wielu partii przykładów będących własnością indywidualnego klienta. Dotyczy to zarówno parametrów modelu (zmiennych), które stale ewoluują sekwencyjnie w miarę lokalnego uczenia modelu, jak i obliczanych statystyk (takich jak średnia strata, dokładność i inne metryki), które model będzie ponownie aktualizowany lokalnie podczas iteracji po lokalnym strumieniu danych każdego indywidualnego klienta.

  Wykonywanie agregacji na tym poziomie jest obowiązkiem kodu modelu i jest realizowane przy użyciu standardowych konstrukcji TensorFlow.

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

  • Model najpierw konstruuje tf.Variable s 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 Twoim Model wielokrotnie, sekwencyjnie w kolejnych partiach danych klienta, co pozwala na aktualizację zmiennych zawierających różne agregaty jako efekt uboczny.

  • Na koniec TFF wywołuje metodę report_local_unfinalized_metrics w Twoim modelu, aby umożliwić Twojemu modelowi skompilowanie wszystkich zebranych statystyk podsumowujących w kompaktowy 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 pomiędzy wieloma klientami (urządzeniami) w systemie. Ponownie dotyczy to zarówno parametrów modelu (zmiennych), które są uśredniane pomiędzy klientami, jak i metryk wyeksportowanych przez model w wyniku agregacji lokalnej.

  Za agregację 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 wielokrotnie wywoływany w strumieniu lokalnych partii danych w celu wygenerowania nowego zestawu parametrów modelu (podczas uczenia) i nowego zestawu lokalnych metryk, jak opisano powyżej (jest to lokalne zbiór).

  • TFF uruchamia protokół agregacji rozproszonej w celu gromadzenia i agregowania parametrów modelu oraz metryk eksportowanych lokalnie w całym systemie. Ta logika jest wyrażona w sposób deklaratywny przy użyciu własnego stowarzyszonego języka obliczeniowego TFF (nie w TensorFlow). Więcej informacji na temat interfejsu API agregacji można znaleźć w samouczku dotyczącym algorytmów niestandardowych .

Interfejsy abstrakcyjne

Ten podstawowy interfejs konstruktora i metadanych jest reprezentowany przez interfejs tff.learning.models.VariableModel w następujący sposób:

• Konstruktor, metody forward_pass i report_local_unfinalized_metrics powinny konstruować odpowiednio zmienne modelu, przekaz w przód i statystyki, które chcesz raportować. TensorFlow skonstruowany tymi metodami musi nadawać się 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 możliwych do wyszkolenia, niemożliwych do wytrenowania i zmiennych lokalnych, reprezentują metadane. TFF wykorzystuje te informacje do określenia, w jaki sposób połączyć części modelu ze stowarzyszonymi algorytmami optymalizacyjnymi oraz do zdefiniowania wewnętrznych podpisów typów, które pomagają w weryfikacji poprawności skonstruowanego systemu (aby nie można było utworzyć instancji modelu na podstawie danych, które nie pasują do model jest przeznaczony do konsumpcji).

Ponadto abstrakcyjny interfejs tff.learning.models.VariableModel udostępnia właściwość metric_finalizers , która pobiera niesfinalizowane wartości metryki (zwracane przez report_local_unfinalized_metrics() ) i zwraca sfinalizowane wartości metryki. Metody metric_finalizers i report_local_unfinalized_metrics() zostaną użyte razem do zbudowania agregatora metryk dla wielu klientów podczas definiowania stowarzyszonych procesów szkoleniowych lub obliczeń ewaluacyjnych. Na przykład prosty agregator tff.learning.metrics.sum_then_finalize najpierw zsumuje niesfinalizowane wartości metryk od klientów, a następnie wywoła funkcje finalizatora na serwerze.

Przykłady definiowania własnego niestandardowego tff.learning.models.VariableModel znajdziesz w drugiej części naszego poradnika 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.models.from_keras_model do skonstruowania tff.learning.models.VariableModel .

Zauważ, że TFF nadal chce, abyś udostępnił konstruktor - funkcję modelu bezargumentową, taką jak poniższa:

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

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

Korzystanie z opakowań Keras jest zilustrowane w naszych samouczkach dotyczących klasyfikacji obrazów i generowania tekstu .

Stowarzyszeni konstruktorzy obliczeń

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

Założenia architektoniczne

Wykonanie

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

• Kompiluj : TFF najpierw kompiluje stowarzyszone algorytmy uczenia się w abstrakcyjną serializowaną reprezentację całego rozproszonego obliczenia. Dzieje się tak, gdy zachodzi serializacja TensorFlow, ale mogą wystąpić inne transformacje w celu zapewnienia bardziej wydajnego wykonywania. Serializowaną reprezentację emitowaną przez kompilator nazywamy obliczeniem stowarzyszonym .

• Execute TFF umożliwia wykonanie tych obliczeń. Na razie wykonanie jest obsługiwane wyłącznie poprzez symulację lokalną (np. w notatniku wykorzystującym symulowane zdecentralizowane dane).

Obliczenia stowarzyszone generowane przez interfejs API Federated Learning firmy TFF, takie jak algorytm uczący wykorzystujący uśrednianie modelu stowarzyszonego lub ocena stowarzyszona, obejmują szereg elementów, w szczególności:

• Serializowana postać kodu modelu, a także dodatkowy kod TensorFlow skonstruowany przez platformę Federated Learning w celu sterowania pętlą uczenia/oceny modelu (np. konstruowanie optymalizatorów, stosowanie aktualizacji modelu, iteracja po tf.data.Dataset s i metryki obliczeniowe). i zastosowanie zagregowanej 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łaszania z serwera do wszystkich klientów) oraz sposobu, w jaki ta rozproszona komunikacja jest przeplatana z wykonaniem lokalnym na kliencie lub lokalnym na serwerze kodu TensorFlow.

Obliczenia stowarzyszone reprezentowane w tej serializowanej formie są wyrażone w niezależnym od platformy języku wewnętrznym, innym niż Python, ale aby korzystać z interfejsu API Federated Learning, nie trzeba przejmować się szczegółami tej reprezentacji. Obliczenia są reprezentowane w kodzie Pythona jako obiekty typu tff.Computation , które w większości przypadków można traktować jako nieprzezroczyste callable wiadomości Pythona.

W tutorialach będziesz wywoływał te stowarzyszone obliczenia tak, jakby były zwykłymi funkcjami Pythona, które mają być wykonywane lokalnie. Jednakże TFF został zaprojektowany do wyrażania obliczeń stowarzyszonych 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 Android lub w klastrach w centrum danych. Ponownie, główną konsekwencją tego są mocne założenia dotyczące serializacji . W szczególności, gdy wywołasz jedną z opisanych poniżej metod build_... obliczenia zostaną w pełni serializowane.

Stan modelowania

TFF jest funkcjonalnym środowiskiem programistycznym, jednak wiele procesów będących przedmiotem zainteresowania w uczeniu stowarzyszonym ma charakter stanowy. Na przykład pętla szkoleniowa obejmująca wiele rund uśredniania modelu stowarzyszonego jest przykładem tego, co możemy sklasyfikować jako proces stanowy . W tym procesie stan ewoluujący z rundy na rundę obejmuje zestaw trenowanych parametrów modelu i ewentualnie dodatkowy stan powią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 wynik. Aby w pełni zdefiniować proces stanowy, należy również określić, skąd pochodzi stan początkowy (w przeciwnym razie nie moglibyśmy uruchomić procesu). Jest to ujęte w definicji klasy pomocniczej tff.templates.IterativeProcess , z dwiema właściwościami initialize i next odpowiadającymi odpowiednio inicjalizacji i iteracji.

Dostępni konstruktorzy

Obecnie TFF udostępnia różne funkcje konstruktora, które generują stowarzyszone obliczenia na potrzeby stowarzyszonego szkolenia i oceny. Dwa godne uwagi przykłady obejmują:

• tff.learning.algorithms.build_weighted_fed_avg , który jako dane wejściowe przyjmuje funkcję modelu i optymalizator klienta i zwraca stanowy tff.learning.templates.LearningProcess (który stanowi podklasę tff.templates.IterativeProcess ).

• Funkcja tff.learning.build_federated_evaluation przyjmuje funkcję modelu i zwraca pojedyncze obliczenia stowarzyszone na potrzeby stowarzyszonej oceny modeli, ponieważ ocena nie jest stanowa.

Zbiory danych

Założenia architektoniczne

Wybór klienta

W typowym scenariuszu uczenia się stowarzyszonego 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 danym 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 pomiarowej i poza tym bezczynny). Ogólnie rzecz biorąc, grupa klientów dostępnych do udziału w szkoleniach lub ocenach jest poza kontrolą programisty. Co więcej, ponieważ koordynacja milionów klientów jest niepraktyczna, typowa runda szkolenia lub oceny obejmie tylko ułamek dostępnych klientów, którzy mogą zostać wybrani losowo .

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

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

trainer = tff.learning.algorithms.build_weighted_fed_avg(...)
state = trainer.initialize()
federated_training_data = ...

def sample(federate_data):
  return ...

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

Aby to ułatwić, podczas korzystania z TFF w symulacjach dane stowarzyszone są akceptowane jako list Pythona, z jednym elementem na każde uczestniczące urządzenie klienckie reprezentujące lokalny tf.data.Dataset tego urządzenia.

Interfejsy abstrakcyjne

Aby ujednolicić postępowanie z symulowanymi stowarzyszonymi zbiorami danych, TFF udostępnia abstrakcyjny interfejs tff.simulation.datasets.ClientData , który pozwala wyliczyć zbiór klientów i skonstruować tf.data.Dataset zawierający dane konkretnego klient. Te elementy tf.data.Dataset można wprowadzić bezpośrednio jako dane wejściowe do wygenerowanych obliczeń stowarzyszonych w trybie chętnym.

Należy zauważyć, że możliwość dostępu do tożsamości klientów to funkcja udostępniana 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 typy klientów). Skompilowane obliczenia i leżące u ich podstaw środowisko wykonawcze nie uwzględniają ż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 będą się już w nich pojawiać.

Dostępne zbiory danych

Przestrzeń nazw tff.simulation.datasets przeznaczyliśmy dla zestawów danych, które implementują interfejs tff.simulation.datasets.ClientData do wykorzystania w symulacjach i obsadziliśmy ją zbiorami danych w celu obsługi samouczków dotyczących klasyfikacji obrazów i generowania tekstu . Chcielibyśmy zachęcić Cię do przesyłania własnych zbiorów danych na platformę.