Federated learning for recommendation

Every model in this course assumed a comfortable premise: clicks, watch-times, and queries all land in one warehouse and you train on them. Federated learning challenges that premise directly — it trains a shared model while the raw behavior never leaves the device. A beautiful answer to privacy, a brutal answer to systems design.

Why anyone would accept this much pain

Centralizing raw user behavior is the default because it is easy and it works. Federation gives that up, so it had better be buying something. The trigger is 22 · Privacy turned into a constraint: regulation (GDPR, PIPL) plus eroding user trust make a central honeypot of raw behavior a liability rather than an asset. Federation buys three things back:

• Privacy & compliance. If a user's watch history, location-laced clicks, and dwell times never leave their phone, a whole class of breach and subpoena risk simply does not apply — there is no central store to leak.
• Breaking data silos. Two parties (a video app and a retailer) can jointly improve a model without either handing over raw logs — each trains locally, only model updates are shared.
• Freshness. The device holds the user's very latest interactions. A local update can reflect a click from ten seconds ago, versus a T+1 batch pipeline that is a day stale.

The honest framing: federation trades a large, recurring systems tax (communication, heterogeneity, convergence loss) for a reduction in privacy/legal risk. Whether the trade is positive depends entirely on how high the risk side is — which is why federation is real in mobile keyboards and health, and mostly aspirational in mainstream feed ranking.

FedAvg, derived

Start from ordinary SGD. To take one gradient step on the global model w you need the average gradient over all data:

Client k holds n_k examples; n = Σ n_k is the total. The key observation: this average is separable. Each client computes its own term ∇L_k on its own data, and the server needs only the data-size-weighted average. No raw example ever moves. That single fact is the whole reason federation is possible.

Naively you would have each client send one gradient per step. But a step is tiny and the network round-trip is enormous — you would spend almost all your time talking, not learning. The fix that defines Federated Averaging (FedAvg): let each client run many local SGD steps before it phones home, and average the resulting weights instead of single gradients. One round:

Repeat for hundreds of rounds. The sanity check: when E = 1 and clients take a single full-batch step, FedAvg reduces exactly to centralized SGD. The interesting regime is E > 1, where it stops being equivalent and the tradeoffs begin.

The communication–computation tradeoff

The reason FedAvg exists is that bandwidth, not FLOPs, is the scarce resource. A phone has spare cycles when charging overnight; what it lacks is the willingness (or the data plan) to upload a full model every few milliseconds. So the design knob is E, the local epochs per round:

Crank E up and each client does more useful work between syncs, so you need fewer rounds → fewer uploads → less total communication. The win is large: FedAvg with E in the tens cuts communication rounds 10–100× versus naive per-step gradient sharing. But the win is not free.

Two cheaper tricks ride alongside E to shrink bytes-per-round directly:

• Sparsification + quantization. Send only the top-k largest-magnitude entries of Δ_k (e.g. top 10%) and round them to 1 bit — together this routinely cuts >90% of uplink bytes. You must add error feedback (accumulate the dropped residual locally, fold it into the next round) or the model develops a systematic bias.
• Differentiated cadence. Active users sync daily, dormant users weekly; stragglers don't hold up a round. Helps the tail but complicates convergence guarantees.

The non-IID problem — the quiet model killer

Centralized SGD shuffles all data, so every mini-batch is a roughly unbiased sample of the global distribution. Federation cannot shuffle: each client sees only its owner's data, and no two users are an i.i.d. sample of "everyone." One user watches only cooking videos; another only basketball. Their local gradients point in genuinely different directions. Two flavors:

• Feature-distribution shift — regional preference differences mean clients live in different parts of feature space.
• Label-distribution shift — different demographics have wildly different base click rates.

Averaging skewed local models drifts the result away from the true global optimum (client drift), and convergence slows or plateaus below centralized accuracy. How much? On a well-shuffled (IID) federated setup FedAvg essentially matches centralized training; under realistic non-IID splits the typical penalty is a 3–8% drop in accuracy / AUC, and in pathological cases (e.g. each phone sees only one category) it can stall far worse or fail to converge at all. Recommendation makes it worse because the user–item interaction matrix is extremely sparse: each client touches a sliver of the catalog, amplifying the skew. Standard responses:

On top of statistical heterogeneity sits system heterogeneity: a flagship phone and a five-year-old budget device differ 10× in compute, so a synchronous round runs at the speed of its slowest participant. Stragglers are handled by over-selecting clients and dropping the laggards, by asynchronous aggregation, or by giving weak devices a smaller distilled model to train.

Horizontal vs vertical — which axis are you partitioning?

Everything above quietly assumed one kind of split: millions of phones, each holding the same feature schema but a different user. That is horizontal federated learning (HFL) — the data is partitioned by sample/user, the feature space is shared. It is the cross-device regime, and FedAvg is its workhorse. The on-device item-table problem below is an HFL setting through and through.

Vertical federated learning (VFL) flips the axis: the same users, but different feature spaces held by different organizations. A video platform knows your watch behavior; a bank knows your spend. Neither has the other's columns. Before you can train you must figure out which rows are the same person without revealing your user lists — encrypted entity alignment via private set intersection (PSI). Then training proceeds over encrypted intermediate representations exchanged between the parties (one side forwards its partial activations, gradients flow back), and only the party holding the labels ever sees the loss signal. This leans hard on the SMPC / homomorphic-encryption machinery from lesson 22 — far heavier crypto than HFL's plain averaging.

The third, sparser case is federated transfer learning: little overlap in either users or features, so you transfer a representation learned by one party to bootstrap another rather than jointly fitting one model. Naming the axis matters in an interview — "federated" alone is ambiguous until you say which dimension is shared.

Federating a multi-task ranker — gradient conflict, amplified

A production ranker is never single-objective — it jointly predicts watch-time, like, comment, share (12 · Multi-task). On a central trainer those heads already fight: the gradient that raises like-rate can lower the gradient for watch-time, because the behaviours trade off (a user who taps "like" and swipes away is the opposite of one who watches to the end). Centralized training averages that conflict over a shuffled, population-representative batch, so the tug-of-war is at least balanced. Federation breaks that balance.

The fix has two halves — balance the objectives locally before upload, then de-conflict at aggregation.

Worked projection. Take two objective gradients on a client — watch-time (the main objective) and like:

Their inner product is g_like · g_watch = (−0.8)(1.0) + (0.6)(0.0) = −0.8 < 0 — a genuine conflict: stepping along g_like partly undoes the watch-time step. Naive summation gives g_watch + g_like = (0.2, 0.6), whose watch-time component has collapsed from 1.0 to 0.2 — the like head has eaten 80% of the watch-time progress. PCGrad projection removes the offending component of g_like along g_watch:

Now the combined step is g_watch + g_like^proj = (1.0, 0.6): watch-time keeps its full magnitude and the like head still contributes its non-conflicting component. The phone uploads a delta that improves the main objective and respects the secondary one, instead of an angry like-only vector that fights every other client at aggregation.

The recsys killer — where does the item embedding table live?

This is what makes federated recommendation genuinely different from federated keyboards or vision. As lesson 04 · Ranking models hammered, a recommender's parameters are dominated not by its dense network but by its embedding tables — one learned vector per user and per item. Three hundred million items at 64-dim fp32 is 300 × 10⁶ × 64 × 4 ≈ 77 GB. FedAvg's step 2 says "broadcast the global model to each client." You cannot broadcast a 77 GB item table to a phone, and the phone cannot train it.

The standard architecture is a hybrid central-item / federated-user split — exactly the sharding mindset from 19 · Large-scale optimization, but with the shard boundary drawn along a privacy line instead of just a memory line:

• User side (on device, federated). The user embedding and the personal ranking head live and train on the phone. They never leave — exactly the sensitive part you wanted to protect.
• Item side (central server). The big item table lives server-side. The phone receives only the vectors for the handful of items the server actually shows the user — those few hundred rows go down, and only their gradients come back up.
• Partial updates. Because each client touches almost no items, item-embedding updates are extremely sparse. The server aggregates these sparse partial updates across many clients into the central table. (And the very fact that a client uploads a gradient for item j leaks that it saw item j — which is precisely why secure aggregation, next, is not optional here.)

This split is why the clean "data stays put, model travels" slogan gets muddy for recommendation: the model is too big to travel, so you travel only the per-request slice of it, and you accept that the global item knowledge is effectively still centralized.

Secure aggregation and its link to differential privacy

A subtle point: FedAvg already keeps raw data on-device, but the updates can still leak. A single client's Δ_k, or the set of item gradients it sends, can be inverted to reconstruct training examples (gradient-inversion attacks), and the model can memorize, exposing it to membership-inference. Two complementary defenses:

• Secure aggregation (SecAgg). A cryptographic protocol so the server learns only the sum Σ Δ_k, never any individual Δ_k. Clients add pairwise-cancelling masks; the masks vanish in the sum but hide each contribution. The server gets the aggregate it needs and nothing more.
• Differential privacy (DP). Clip each update and add calibrated Gaussian noise so no single user's participation measurably changes the result — a formal, provable bound on what can be inferred (see 22 · Privacy). The cost is accuracy: more noise (smaller ε) means stronger privacy and a worse recommender, so ε is a tunable dial, not a free upgrade.

Robust aggregation — surviving poisoned clients

Gradient-inversion was a privacy threat: an honest server might learn too much. The mirror-image threat is integrity: a malicious or simply faulty client sends crafted or garbage updates — model poisoning, data poisoning, or a targeted backdoor that misfires only on a chosen trigger. Plain FedAvg is defenceless here. It computes a weighted mean, and a mean has breakdown point zero: a single contributor pushing a large enough Δ_k can drag the global model anywhere it likes.

The fix is to replace the mean with a statistic that resists outliers — a Byzantine-robust aggregator. Three standard ones:

The catch is the same one the non-IID section warned about, now wearing a security hat: a legitimately different client looks exactly like an attacker. A user who only watches cooking videos sends an update that is a genuine outlier, and a robust aggregator will happily trim it away — so you buy robustness at the cost of throwing out real signal from the tail of the heterogeneity distribution. Tune β too aggressively and you re-introduce the convergence penalty you were fighting in the first place.

How do you even evaluate a federated model?

Every offline metric you know — AUC, NDCG, mean watch-time — assumes a central test set: pool the labels, score the model, compute the number. Federation forbids exactly that. The labels live on devices and never leave, so there is no place to run roc_auc_score(y, ŷ). This is a genuine, non-obvious failure mode: a team can build a flawless federated training pipeline and then discover it has no honest way to measure what it built. The answer mirrors training — don't move the data, aggregate the statistics.

The recurring trick: every metric you want is a function of some aggregate (a count, a sum, a sorted distribution). Compute the local piece on each device, then combine the pieces through SecAgg so the server sees only the global statistic, never a client's raw scores.

Worked Fed-AUC. Say three clients each report, after SecAgg, a 4-bucket score histogram for positives and negatives. The summed global counts are:

AUC is the probability a random positive outscores a random negative, estimable from these histograms. Bucket-4 positives (50) beat all negatives in buckets 1–3 (60+25+10 = 95) and tie the 5 in bucket 4; bucket-3 positives (30) beat buckets 1–2 negatives (85); and so on. Summing winning pairs over 100 positives × 100 negatives = 10,000 comparisons gives 50·95 + 30·85 + 15·60 = 8,200 clear wins plus 1,225 same-bucket ties at half credit (612.5), so AUC ≈ (8,200 + 612.5) / 10,000 ≈ 0.88 — computed without the server ever seeing one (score, label) pair. Coarser buckets cost accuracy in the estimate; that granularity is itself a privacy knob.

Federated cold start — bootstrapping a client with no history

The non-IID section gave personalized FL (Per-FedAvg) for users who differ; cold start is the harder cousin — a brand-new user or a newly-joined client (a fresh region/platform) with almost no local data to fine-tune on, where the central tricks from 15 · Cold start and 38 · Cold start (advanced) can't run because the cold user's data won't move. Three named federated mechanisms, each attacking it differently:

The privacy tie-in: cold start is exactly when you'd relax the budget — F2's adaptive ε says spend more ε early (accept higher privacy cost to get a usable profile fast), then tighten as the user accumulates real local signal.

Interactive · federated round-cost estimator

The thing to feel is how communication cost behaves as you turn the dials. More local epochs cut rounds; compression cuts bytes-per-round; but a bigger model and more clients push everything back up. And the item table, if you ever tried to federate it, dwarfs all of it — which is the whole argument for the hybrid split above.

An honest verdict — when does federation actually pay?

Federated learning is real, deployed technology (mobile keyboard prediction is the canonical success). For a recommender, be clinical:

Interview prompts you should be ready for