Federated learning

Federated learning is a way to train one AI model on data that stays in many different places. Each phone, shop or hospital trains the model on its own data and sends back only what the model learned, never the data itself. Organisations that may not pool their customer or patient files can still build a model together this way.

How does it work?

The name and the basic method come from McMahan et al. at Google (2016). In their Federated Averaging algorithm (FedAvg), a training round goes like this:

1. The server sends the current model to a random sample of the participants (clients).
2. Each client trains the model on its own data for a few passes.
3. Each client sends back its updated model, not its data.
4. The server averages the models, giving more weight to clients with more data, and starts the next round.

Because every client does more work per round, FedAvg needed 10 to 100 times fewer communication rounds than plain distributed training with stochastic gradient descent in their experiments. Google described the phone version in April 2017: the phone downloads the model, improves it with data on the phone and sends a small encrypted update, which is averaged with other users' updates. Training runs only when the phone is idle, charging and on a free wireless connection.

Where is it used?

The survey by Kairouz et al. (2019) distinguishes two settings:

• Cross-device: a very large number of phones or other devices, up to billions. The survey names Google's Gboard keyboard and Apple's use in iOS 13 for the QuickType keyboard and the voice classifier for "Hey Siri".
• Cross-silo: a few organisations, such as hospitals or banks, typically 2 to 100.

A cross-silo study: Sheller et al. (2020) trained a brain tumour model on scans from 10 institutions, kept apart as they would be in practice. The federated model reached 99% of the quality of a model trained on all the data in one place.

Where does it go wrong?

• Updates can give data away. Zhu et al. (2019) reconstructed training images pixel by pixel and texts token by token from shared gradients. Extra protection is therefore common: secure aggregation, with which the server can only decrypt the average of hundreds or thousands of updates, according to Google, and differential privacy, which clips the updates and adds noise, as Kairouz et al. describe.
• The data is uneven. Each client has its own mix of data; McMahan et al. call such unbalanced, non-IID data a defining characteristic of the setting.
• Devices come and go. According to Google, phones have slow, high-latency connections and are only intermittently available for training.

Kairouz et al. conclude that federated learning "can mitigate many of the systemic privacy risks" of central training. That makes it a way to reduce risk, and it does not make a project compliant with privacy law on its own.

Example

Suppose a group of 30 dental practices wants a model that flags unusual X-rays, but the practices may not pool patient files. With federated learning, each practice trains the shared model on its own X-rays overnight and sends back only the updated model, and a coordinator averages the results. The patient files never leave the practices. The group still has to agree who runs the coordinator and whether updates are protected with secure aggregation or differential privacy.