Federated Recommendation

Recommendation normally works because everyone's interaction history sits in one table. Federated recommendation asks whether the same model can be learned while that history never leaves the devices that produced it.

Training moves, data stays
The server holds the shared parameters — above all the item embeddings — and sends them to a sample of clients. Each device computes gradients on its own local interactions, and only those updates travel back to be averaged into the next round, the FedAvg pattern. The split falls naturally out of the model: a user's own factor vector can live on the phone permanently, since nothing else needs it, while the item factors are the genuinely shared quantity.

Why it is harder here
Three constraints make the recommendation case awkward:

• Implicit feedback has no negatives, so a client must sample unobserved items to train against — and which items it requests can itself reveal what the user engaged with.
• Gradient sparsity leaks. Updating only the embeddings of items you touched tells the server exactly which ones those were, so updates are padded with sampled items, hidden under secure aggregation, or blurred with calibrated noise for differential privacy.
• Catalogue scale collides with device memory: shipping millions of item vectors to a handset is not viable, so practical systems send a restricted candidate set or compressed factors.

Why it matters
This is the main technical answer to a recommender that must personalise without accumulating a behavioural record of every user. It costs accuracy and many rounds of communication, and it buys a system where the sensitive history exists only on the device — increasingly a binding legal constraint rather than a preference.