Sfederowane uczenie się

Przegląd

W tym dokumencie przedstawiono interfejsy, które ułatwiają sfederowane zadania uczenia się, takie jak szkolenie sfederowane 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 sfederowanym uczeniem się bez konieczności posiadania wiedzy o tym, jak to działa pod maską, oraz ocena zaimplementowanych algorytmów sfederowanego uczenia się na różnych istniejących modelach i danych. Zachęcamy do powrotu do platformy. TFF został zaprojektowany z myślą o rozszerzalności i komponowaniu, dlatego chętnie przyjmujemy wkłady; jesteśmy podekscytowani, aby zobaczyć, 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 umożliwiają zawijanie istniejących modeli do użytku z TFF. Zawijanie modelu może być tak proste, jak wywołanie pojedynczej funkcji zawijania (np. tff.learning.from_keras_model ) lub zdefiniowanie podklasy interfejsu tff.learning.Model w celu pełnego dostosowania.

  • Sfederowani Konstruktorzy Obliczeń . Funkcje pomocnicze, które konstruują sfederowane obliczenia 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 symulowania scenariuszy nauczania sfederowanego. Chociaż sfederowane uczenie 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 przeprowadzać wstępne eksperymenty z danymi, które można pobrać i manipulować lokalnie, zwłaszcza dla programistów, którzy mogą być nowy w podejściu.

Te interfejsy są zdefiniowane głównie w przestrzeni nazw tff.learning , z wyjątkiem zestawów danych badawczych i innych funkcji 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 zapoznanie się z samouczkami dotyczącymi klasyfikacji obrazów i generowania tekstu , ponieważ zawierają one większość opisanych tu pojęć na konkretnych przykładach. Jeśli chcesz dowiedzieć się więcej o tym, jak działa 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ń sfederowanych oraz do przestudiowania istniejącej implementacji tff.learning interfejsy.

Modele

Założenia architektoniczne

Serializacja

TFF ma na celu obsługę różnych scenariuszy uczenia rozproszonego, w których napisany przez Ciebie kod modelu uczenia maszynowego może być wykonywany na dużej liczbie heterogenicznych klientów o różnych możliwościach. Chociaż na jednym końcu spektrum, w niektórych aplikacjach tymi 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 z ograniczonymi zasobami. Nie możemy zakładać, że te urządzenia mogą obsługiwać środowiska uruchomieniowe Pythona; jedyną rzeczą, jaką możemy w tym momencie założyć, jest to, że są w stanie hostować lokalne środowisko wykonawcze TensorFlow. Dlatego podstawowym założeniem architektonicznym, jakie przyjmujemy w TFF, jest to, że kod modelu musi być możliwy do serializacji jako wykres TensorFlow.

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

Obecnie TensorFlow nie obsługuje w pełni serializacji i deserializacji TensorFlow w trybie podekscytowanym. W związku z tym serializacja w TFF jest obecnie zgodna ze wzorcem TF 1,0, w którym cały kod musi być skonstruowany wewnątrz tf.Graph , który kontroluje TFF. Oznacza to, że obecnie TFF nie może wykorzystywać już skonstruowanego modelu; zamiast tego logika definicji modelu jest pakowana w funkcję bezargumentową, która zwraca tff.learning.Model . Ta funkcja jest następnie wywoływana przez TFF, aby zapewnić serializację wszystkich składników modelu. Ponadto, będąc środowiskiem o silnych typach, TFF będzie wymagać 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 oraz wszelkie metryki zdefiniowane dla modelu automatycznie. Jednak nadal przydatne może być zrozumienie sposobu obsługi agregacji w przypadku ogólnego tff.learning.Model .

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

  • Agregacja lokalna . 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 lokalnie szkolony, jak również obliczanych statystyk (takich jak średnia strata, dokładność i inne metryki), które model będzie ponownie lokalnie aktualizowany ponieważ iteruje po lokalnym strumieniu danych każdego klienta.

    Za wykonywanie agregacji na tym poziomie odpowiada kod modelu i jest ona realizowana 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 wielokrotnie wywołuje metodę forward_pass w Model , 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_unfinalized_metrics w modelu, aby umożliwić modelowi skompilowanie wszystkich zebranych statystyk podsumowujących w kompaktowy zestaw metryk do wyeksportowania przez klienta. W tym miejscu kod Twojego modelu może na przykład podzielić sumę strat przez liczbę przykładów przetworzonych w celu wyeksportowania średniej straty itp.

  • Sfederowana agregacja . Ten poziom agregacji odnosi się do agregacji wielu klientów (urządzeń) w systemie. Ponownie dotyczy to zarówno parametrów modelu (zmiennych), które są uśredniane dla klientów, jak i metryk wyeksportowanych przez model w wyniku agregacji lokalnej.

    Za wykonanie agregacji na tym poziomie odpowiada TFF. Jako twórca modeli 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 będą uczestniczyć 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 wygenerowania nowego zestawu parametrów modelu (podczas uczenia) oraz nowego zestawu metryk lokalnych, jak opisano powyżej (jest to lokalny zbiór).

    • TFF uruchamia protokół agregacji rozproszonej, aby gromadzić i agregować parametry modelu oraz lokalnie wyeksportowane metryki w całym systemie. Ta logika jest wyrażana w sposób deklaratywny przy użyciu własnego sfederowanego języka obliczeń TFF (nie w TensorFlow). 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, forward_pass i report_local_unfinalized_metrics powinny odpowiednio konstruować zmienne modelu, przekazywanie do przodu i statystyki, które chcesz raportować. TensorFlow skonstruowany przez te metody 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 możliwych do trenowania, niemożliwych do trenowania i lokalnych, reprezentują metadane. TFF wykorzystuje te informacje, aby określić, jak połączyć części modelu ze sfederowanymi algorytmami optymalizacji oraz zdefiniować wewnętrzne sygnatury typów, aby pomóc w weryfikacji poprawności zbudowanego systemu (tak, aby nie można było utworzyć instancji modelu na danych, które nie są zgodne z model jest przeznaczony do konsumpcji).

Ponadto abstrakcyjny interfejs tff.learning.Model 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() będą używane razem do tworzenia agregatora metryk między klientami podczas definiowania stowarzyszonych procesów szkoleniowych lub obliczeń oceny. Na przykład prosty agregator tff.learning.metrics.sum_then_finalize najpierw zsumuje niezakończone wartości metryki od klientów, a następnie wywoła funkcje finalizatora na serwerze.

Przykłady definiowania własnego niestandardowego tff.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 .

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

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

Oprócz samego modelu dostarczasz próbną 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 prawidłowo 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 czasie konstruowania TensorFlow do serializacji).

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

Sfederowani konstruktorzy obliczeń

Pakiet tff.learning zawiera kilka programów budujących tff.Computation s, 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

Uruchamianie obliczeń federacyjnych składa się z dwóch odrębnych etapów.

  • Kompiluj : TFF najpierw kompiluje algorytmy uczenia sfederowanego w abstrakcyjną serializowaną reprezentację całego obliczenia rozproszonego. To wtedy ma miejsce serializacja TensorFlow, ale mogą wystąpić inne przekształcenia w celu obsługi wydajniejszego wykonywania. Zserializowaną reprezentację emitowaną przez kompilator nazywamy obliczeniami federacyjnymi .

  • Execute TFF zapewnia sposoby wykonywania tych obliczeń. Na razie wykonanie jest obsługiwane tylko przez symulację lokalną (np. w notebooku przy użyciu symulowanych danych zdecentralizowanych).

Obliczenia sfederowane generowane przez interfejs API sfederowanego uczenia się TFF, takie jak algorytm uczący wykorzystujący uśrednianie modelu sfederowanego lub ocena sfederowana, obejmują szereg elementów, w szczególności:

  • Zserializowana forma kodu modelu, a także dodatkowy kod TensorFlow skonstruowany przez platformę Federated Learning w celu prowadzenia pętli uczenia/oceny modelu (np. konstruowanie optymalizatorów, stosowanie aktualizacji modelu, iterowanie po tf.data.Dataset 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łaszanie z serwera do wszystkich klientów) oraz sposób, w jaki ta rozproszona komunikacja jest przeplatana z wykonywaniem na kliencie lokalnym lub 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 interfejsu API federacji edukacyjnej, nie trzeba 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 obiekty, które można callable w Pythonie.

W tych samouczkach będziesz wywoływać te sfederowane obliczenia tak, jakby były zwykłymi funkcjami Pythona, które mają być wykonywane lokalnie. Jednak TFF jest przeznaczony do wyrażania sfederowanych obliczeń w sposób niezależny od większości aspektów środowiska wykonawczego, dzięki czemu można je potencjalnie wdrożyć na przykład 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 opisanych poniżej metod build_... obliczenie jest w pełni serializowane.

Stan modelowania

TFF jest funkcjonalnym środowiskiem programistycznym, jednak wiele procesów interesujących w sfederowanym uczeniu się ma stan. Na przykład pętla ucząca obejmująca wiele rund uśredniania modelu federacyjnego jest przykładem tego, co możemy sklasyfikować jako proces stanowy . W tym procesie stan, który ewoluuje z rundy na rundę, obejmuje zestaw trenowanych parametrów modelu 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 uchwycone w definicji klasy pomocniczej tff.templates.IterativeProcess , z 2 właściwościami Initialize, a next odpowiadającymi odpowiednio initialize i iteracji.

Dostępne budowniczych

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

Zbiory danych

Założenia architektoniczne

Wybór klienta

W typowym scenariuszu sfederowanego uczenia się 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 z pomiarem i w inny sposób bezczynny). Ogólnie rzecz biorąc, zestaw klientów dostępnych do udziału w szkoleniu lub ocenie jest poza kontrolą programisty. 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 wybrać losową próbę .

Kluczową konsekwencją tego jest to, że obliczenia sfederowane, z założenia, są wyrażane w sposób, który jest nieświadomy dokładnego zestawu uczestników; całe przetwarzanie jest wyrażane jako operacje agregujące 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 kodu nauczania sfederowanego, zazwyczaj napiszesz pętlę szkoleniową, która wygląda tak:

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 używania TFF w symulacjach dane sfederowane są akceptowane jako list Pythona, z jednym elementem na uczestniczące urządzenie klienckie, które reprezentuje lokalne tf.data.Dataset tego urządzenia.

Abstrakcyjne interfejsy

W celu ujednolicenia postępowania z symulowanymi sfederowanymi zestawami danych, TFF udostępnia abstrakcyjny interfejs tff.simulation.datasets.ClientData , który umożliwia wyliczenie zestawu klientów i skonstruowanie tf.data.Dataset zawierającego dane konkretnego klient. Te tf.data.Dataset s mogą być przekazywane bezpośrednio jako dane wejściowe do wygenerowanych obliczeń stowarzyszonych w trybie przyspieszonym.

Należy zauważyć, że możliwość dostępu do tożsamości klientów jest funkcją, którą zapewniają tylko zestawy danych do użytku w symulacjach, w których może być potrzebna możliwość uczenia się na danych z określonych podzbiorów klientów (np. do symulacji dziennej dostępności różnych rodzaje klientów). Skompilowane obliczenia i bazowe środowisko uruchomieniowe 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 zbiory danych

Wydzieliliśmy przestrzeń nazw tff.simulation.datasets dla zestawów danych, które implementują interfejs tff.simulation.datasets.ClientData do użytku w symulacjach, i wyposażyliśmy go w zestawy danych w celu obsługi samouczków klasyfikacji obrazów i generowania tekstu . Zachęcamy do wniesienia własnych zbiorów danych do platformy.