Federacja – państwo składające się z części obdarzonych autonomią, ale posiadających wspólny rząd. Tak federację definiuje Wikipedia. Jeśli jesteś fanem uniwersum Star Trek, to zapewne kojarzysz Zjednoczoną Federację Planet. Układ partnerski, w którym uczestniczy wiele ras, posiadający wspólny rząd. Ale po co ja w ogóle o tym piszę? Przecież miało być o danych! I będzie. Potrzebuję jednak jakiejś fajnej analogii, żeby omówić koncepcję Federated Learning.
Idea Federated Learning
Nie znam dokładnej daty powstania idei Federated Learning, Wikipedia natomiast wskazuje publikację „Federated Optimization: Distributed Optimization Beyond the Datacenter” z 2015 jako jedną z pierwszych poruszających tę tematykę. Data wskazuje, że jest to całkiem świeży temat, nawet jeśli chodzi o uczenie maszynowe. O co więc tutaj chodzi?
Idea jest podobna jak do wspomnianej powyżej definicji federacji. Mamy autonomiczne urządzenia, które zbierają dane i je procesują. Następnie komunikują się miedzy sobą (albo z centralnym „szefem”) i wymieniają ichnimi lokalnymi modelami, w celu wypracowania wspólnego lepszego rozwiązania. Pomysł na tyle prosty, że pozostaje pytanie, co w tym takiego nowoczesnego? Przecież mamy już wiele algorytmów rozproszonego uczenia maszynowego i równoległego. Po co nam to?
Uwięzione dane
Pomysł na Federated Learning pojawił się mniej więcej w momencie gdy okazało się, że powoli oddolnie wchodzimy w erę Internet of Things. Istnieje bowiem coraz więcej urządzeń podłączonych do internetu, zbierających dane i mogących wykonywać obliczenia. Najbardziej intuicyjnym przykładem będzie tutaj smartphone. Możemy stworzyć aplikację, która przy całkiem sporej dozie szczęścia zostanie zainstalowana miliony razy na milionach urządzeń. Nasza aplikacja może podejmować jakieś działania na bazie modelu uczenia maszynowego. Wraz z jej używaniem, będzie też zbierać dane, które mogą posłużyć do ulepszenia tego modelu. Chcielibyśmy więc „zaopiekować się tymi danymi” w celu ulepszenia doświadczenia użytkownika. Ale w Europie może stanąć nam na przeszkodzie na przykład takie RODO. Oprócz tego słabe wizerunkowo może też być narażanie użytkownika na zużywane transferu danych. No i wyjaśnianie jakie dane właściwie zbieramy i co z nimi robimy. Mamy więc teoretycznie dostęp do nowych danych, ale są one uwięzione na urządzeniach, których nie kontrolujemy.
Ale co jeśli dałoby się jakoś sprytnie ulepszać lub trenować nowy model bazując na tych danych właśnie na tych urządzeniach? Reprezentacja takiego modelu nie będzie musiała posiadać dających się interpretować prywatnych danych. Może także być mniejsza niż zbiór danych. Nie będzie również wykorzystywana jako pojedynczy obiekt, tylko zostanie zintegrowana w pełny model. Dane i pośredni model mogą zostać wtedy usunięte. Natomiast nowa informacja pozostanie.
W taki sposób Google rozwija system podpowiedzi kolejnych słów w swojej klawiaturze Android.
Ryzyko i wady
Oczywiście, żeby nie było zbyt różowo, mamy tutaj też pewne ryzyko i wady. Mimo iż założenie jest takie, że nie przesyłamy bezpośrednich danych, a model nie powinien eksponować prywatnej informacji, czasem taka informacja „przecieka”. Może się bowiem zdarzyć, że pewne dane są na tyle unikatowe, że chcąc nie chcąc model zacznie się ich uczyć na pamięć. Wtedy tworząc taki system, trzeba zadbać o odpowiednią obsługę takich sytuacji. Co wcale nie musi być łatwe.
Zasadniczą wadą jest też fakt, że dane użyte do trenowania powinny być dobrze zdefiniowane jako dane dla uczenia nadzorowanego. Czyli, że składają się z cech niezależnych, którym przyporządkowana jest jakaś cecha zależna. Jeśli nie mamy możliwości zebrać takich danych, to nie uda nam się ulepszyć modelu. A jeśli dane będą błędne (bo np. użytkownicy będą coś robić źle bądź będą oszukiwać) to nowy model będzie psuł aktualnie najlepszy model. Trzeba więc dobrze zdefiniować problem, który rozwiązujemy i metrykę, którą będziemy monitorować.
Nie każdy model da się też w ten sposób ulepszać. Musimy więc na etapie projektowania systemu zdecydować się na jedno konkretne rozwiązanie. Jeżeli w przyszłości będziemy chcieli je zmienić, będzie to prawdopodobnie bardzo czasochłonne.
No i ostatnia wada takiego rozwiązania to większe skomplikowanie architektury. W centralnym (niejako domyślnym) uczeniu maszynowym nasze podejście jest proste — dzielimy dane, trenujemy model, sprawdzamy czy jest wystarczająco dobry i dostarczamy go „na produkcję”. Tutaj musimy jeszcze opracować częstotliwość łączenia modeli, ich synchronizację, komunikację między urządzeniami, ocenę jakości modeli cząstkowych i modelu wypadkowego. Jest więc więcej miejsc, gdzie coś może pójść nie tak.
Federated learning — Podsumowanie
Federated learning to temat, który bardzo mi się podoba i planuję poświęcić mu więcej uwagi w przyszłości. A z racji wspomnianego coraz bardziej popularnego Internet of Things oraz RODO ten sposób budowania modeli może być coraz bardziej wartościowy w biznesie. Sądzę więc, że warto mieć ten temat na uwadze.