Federated Learning

Federated learning trains a model on many devices without collecting the raw data in one place. The model goes to the phone. The data stays on the phone.

The old way was to upload everything. If a company wanted better autocorrect, it had to send billions of personal messages to its own cloud. That hit privacy, security, and rules like GDPR. The company got a bigger training set. Users lost control of the messages.

Federated learning sends a base model to the smartphone. While you type, the model learns local patterns on the device. Once a day the phone computes a small geometric update, a math summary of what it learned, and sends only that encrypted update back. Your messages never leave the device. The server averages updates from millions of phones and improves the global model.

Then it ships the new model back out. The next round starts from that better base.

Keyboard vendors use this for next-word prediction. Google's Gboard is the usual example: the phone trains on your typing, the server never sees the texts. Hospitals use the same idea for cancer-detecting vision models. Rival hospitals can train one model on millions of MRI scans without moving a patient record past the hospital firewall.

The pattern is the same: more data in training, less raw data in transit.

It is not a privacy guarantee. A poisoned device can send a bad update and pull the global model off course. Gradients can leak information about the training data if you invert them. Teams still need secure aggregation, checks on updates, and limits on what the local model can see. Federated learning reduces how much raw data you centralize.

It does not remove the need to treat updates as sensitive. Google's 2017 federated averaging paper trained a model across phones by shipping weight updates, not raw data.