Multi-Task Learning for Ranking: Why Joint Optimization Beats Single-Objective

TL;DR.

• Single-objective rankers optimize one number — usually click — and quietly degrade the feed by promoting clickbait, low-dwell content, and engagement traps.
• Multi-task learning for ranking jointly predicts click, save, share, dwell, and downstream signals from a shared representation, then combines the scores at serving time.
• The dominant production architectures are MMoE (Google, 2018), PLE (Tencent, 2020), and SNR (Google, 2019). All three exist because hard parameter sharing causes a "seesaw" — one task improves, another regresses.
• Real deployments report task-level lifts in the 5-15% range relative to single-task baselines, and PLE on Tencent video reported +2.23% view-count and +1.84% watch-time over prior MTL models.
• Joint training is not free: gradient conflict between tasks is real, and techniques like PCGrad and GradNorm exist specifically to keep one loss from steamrolling the others.

If your ranker optimizes click-through rate and nothing else, you already know what's going to happen: the model finds the cheapest path to a click. Titles get louder, thumbnails get more contrived, and a month later your save rate and your average session length both go sideways. This post is about why production teams stopped pretending CTR is a sufficient objective, what multi-task learning for ranking actually looks like in the architectures that now run YouTube, Tencent Video, and Kuaishou, and how to think about the gradient interactions you'll trip over when you try it.

Why single-objective rankers fail in production

A click is a cheap signal. It happens before the user has seen the content. Optimizing only for click selects for the most clickable item, not the best one — and "most clickable" is a function of thumbnail, title, position, and recent surprise, none of which correlate strongly with what the user actually wanted.

In a feed product, this shows up fast. You'll see the headline metric move first (more clicks per impression), then a slower drift in the downstream metrics that actually pay rent: dwell time, save rate, share rate, return-visit rate, subscription rate. Nine times out of ten the ML team finds out from the product team, not from the dashboard the team set up.

The cleanest framing comes from the YouTube ranking paper by Zhao et al. (RecSys 2019), which groups objectives into two buckets: engagement signals (click, watch time) and satisfaction signals (like, share, dismiss, rate). Engagement is what the user does; satisfaction is whether they're glad they did it. A model that optimizes only engagement will happily recommend things the user clicks and regrets, and the gap between those two metrics is the gap between a feed people use and a feed people enjoy.

What multi-task learning for ranking actually means

Multi-task learning for ranking is the practice of training a single neural ranker to predict several user behaviors simultaneously — typically click, dwell, save, share, comment, like, complete-watch, and any conversion event downstream of the impression. Each task has its own loss, the shared portion of the network gets gradients from all tasks, and at serving time the per-task predictions are combined into a single score (usually a weighted product, sometimes a weighted sum after calibration).

There are three reasons teams reach for MTL on a ranking problem:

1. Regularization. Each task is a noisy supervisor. Combining them gives the shared representation a more stable target than any single label.
2. Data efficiency. Most user actions are sparse. Click is dense, share is sparse, conversion is very sparse. Joint training lets the sparse tasks borrow signal from the dense ones.
3. Joint ranking objectives. Most products do not have a single business objective. They have a basket. Modeling that basket directly is more honest than picking one proxy and hoping.

The catch — and the entire reason the field exists as a research area — is that naive joint training causes negative transfer. Tasks fight each other through the shared parameters. The architectures below are different answers to the same question: how much sharing, and where?

MMoE: shared experts, per-task gates

The Multi-gate Mixture-of-Experts paper from Ma et al. (KDD 2018) is the architecture most production MTL rankers descend from. The construction is simple. Instead of a single shared bottom MLP, you have N expert MLPs in parallel. Each task has its own gating network that produces a softmax over the experts, and the task's tower receives a weighted sum of expert outputs. Experts are shared across tasks; gates are per-task.

The key claim from the paper is that MMoE models task relationships from data rather than assuming them. If two tasks are similar, their gates will learn to attend to overlapping experts. If two tasks are dissimilar, their gates will route to disjoint experts and the shared bottom effectively becomes task-specific. You don't have to hand-design the sharing structure; the gates do it.

This is also the architecture YouTube describes in its multi-task ranking paper, on top of which the team adds a shallow tower to absorb position bias. MMoE is, in one industry survey's words, "by far the most widely adopted" architecture in web-scale ranking systems.

PLE: the seesaw problem and how to fix it

MMoE has a failure mode: even with per-task gates, experts can collapse onto whatever signal is loudest. Tencent's Progressive Layered Extraction paper (Tang et al., RecSys 2020) calls this the seesaw phenomenon — improving one task systematically hurts another, and you can't find a setting that lifts both.

PLE's fix is to split experts into two kinds: shared experts (used by all tasks, like MMoE) and task-specific experts (used only by one task's gate). The task-specific experts give each task a protected region of the model where the shared gradients can't degrade it. Stacking these layers gives the architecture its name — at each layer, the routing "extracts" task-specific features progressively.

The numbers from the paper are the most cited deployment figures in the MTL recommender literature: PLE delivered a 2.23% increase in view-count and a 1.84% increase in watch time over the prior best MTL baseline on Tencent's video recommender, on a billion-sample dataset. That's the lift of one architecture change at the head of an already-tuned ranking stack — and it's why PLE is the second name you should know after MMoE.

SNR and the rest of the architecture family

SNR — Sub-Network Routing — from Ma et al. at AAAI 2019 generalizes MMoE one step further. Instead of a single layer of experts, SNR modularizes the shared bottom into multiple stacked sub-networks, and the connections between sub-networks are themselves learnable (continuous or discrete) variables. The result is a learned routing graph: each task gets the path through the shared parameters that best predicts its target.

SNR was validated on YouTube-8M and improves accuracy without growing parameter count much. In practice, MMoE and PLE remain more common in production because they're easier to train and easier to reason about, but SNR is a reasonable choice when you have many weakly related tasks and don't want to hand-tune which ones share.

A handful of more recent architectures — CGC, HoME from Kuaishou, STEM, DLEN — extend the same lineage. The high-level shape is consistent: shared and task-specific experts, learned routing, separate towers per task, and a combiner at the top. The differences are about which collapse mode (expert collapse, gate collapse, seesaw) you optimize against. If you're new to MTL for ranking, build MMoE first, then upgrade to PLE if you see seesaw behavior, and only reach for SNR or HoME if you have a clear reason.

The gradient interactions you'll trip over

The architecture is half the problem. The other half is what happens to the shared parameters during back-prop when several losses are pulling on them at once.

The pathology is gradient conflict: two tasks' gradients at a shared parameter point in directions with negative cosine similarity, so any step you take improves one and hurts the other. The 2020 NeurIPS paper Gradient Surgery for Multi-Task Learning (Yu et al.) calls the dangerous case the "tragic triad": conflicting direction + high positive curvature + large magnitude difference. When all three hold, the smaller task is systematically run over by the larger one.

The two interventions you'll see most often:

• PCGrad (Projecting Conflicting Gradients). For each pair of tasks whose gradient cosine similarity is negative, project one gradient onto the normal plane of the other. Non-conflicting tasks pass through untouched. It's a few lines on top of any optimizer.
• GradNorm. Re-weight each task's loss dynamically so the gradient magnitudes at the shared layer are balanced. Doesn't fix direction conflicts, only magnitude conflicts, so it's usually paired with PCGrad or used when conflicts are mostly about scale.

If you train MTL rankers without either, the model usually still works — but you're paying for that with a quietly degraded sparse task (typically share or conversion, the ones with smallest gradient norms). When a sparse task underperforms its single-task baseline, suspect gradient magnitude before you suspect architecture.

The combiner: what to do at serving time

Joint training gives you K calibrated probabilities per item. You still have to combine them into one score. The two patterns in production:

1. Weighted product, e.g. score = p_click^a * p_dwell^b * p_save^c * p_share^d. Each exponent is a hyperparameter tuned offline against a downstream objective (DAU, watch time, revenue) and via online experiment. YouTube's paper describes this approach.
2. Weighted sum with calibration, e.g. score = a*p_click + b*p_dwell + ... after each p is calibrated against its empirical rate. Easier to reason about; harder to handle when probabilities span very different orders of magnitude.

The weight tuning is its own engineering project. Most teams update weights on a cadence (monthly is common) tied to the product's current strategic priority, and explicitly avoid weighting click highly even when click is the densest signal. The combiner is the lever the product team should be allowed to pull; the model is what the ML team owns. That separation is one of the underrated benefits of MTL — you can change strategy without retraining.

How ×marble fits in

If you're standing up a personalization layer, MTL for ranking is one of the last problems you solve, not the first. You need an event pipeline, an interaction store, a knowledge graph or embedding index, and a working single-objective ranker before joint optimization buys you anything.

×marble gives you that foundation — graph-based user and content modeling, real-time interaction ingestion, and an inference layer where multiple objectives are first-class. Our Video product and Vivo briefings both run joint ranking objectives across click, dwell, and save under the hood, because a single-objective ranker would have eaten the product within a month. If you'd rather not rebuild the MMoE/PLE stack from scratch, we built it as a product. See also our reference architecture for real-time personalization and the marketing engineer's personalization stack for how this fits into a full system.

FAQ

What is multi-task learning for ranking?

Multi-task learning for ranking is training a single neural ranker to predict multiple user behaviors — click, dwell, save, share, like, conversion — from a shared representation, then combining the per-task predictions into a single score at serving time. It contrasts with single-objective ranking, which optimizes one metric (usually click-through rate) and relies on that metric being a good proxy for everything else.

Why is MTL better than training separate rankers per task?

Three reasons. Sparse tasks (share, conversion) borrow signal from dense tasks (click, dwell) through the shared representation, which improves their accuracy when data is limited. The shared layers act as a regularizer, since each task's noise gets averaged out. And per-task models trained independently don't share infrastructure cost — one MTL ranker is cheaper to serve than K separate models.

What is the seesaw phenomenon in MTL recommendations?

The seesaw phenomenon is when joint training improves one task and regresses another, with no setting that lifts both. It's caused by negative transfer through shared parameters and by gradient conflict between tasks. Tencent's PLE paper named it and addressed it by separating shared experts from task-specific experts, so each task has a protected region of the model.

MMoE vs PLE — which should I use?

Start with MMoE. It's simpler, well-studied, and the default in most production stacks. Move to PLE if you observe seesaw — a task you care about regresses below its single-task baseline and you can't find expert-count or learning-rate settings that fix it. PLE's task-specific experts add parameters but typically recover the regressing task without giving up the shared lift.

How much lift does multi-task learning for ranking deliver in production?

Published numbers vary by stack and starting point, but task-level lifts of roughly 5-15% over a single-task baseline are typical when teams report results. Tencent reported +2.23% view-count and +1.84% watch-time from PLE vs prior MTL models, which represents the marginal lift of one architecture change at the head of an already-mature ranking stack — not the full MTL-vs-single-task delta.

Further reading

• Recommendation engine vs personalization layer — where ranking sits in the broader personalization stack.
• Explainable recommendations and the path of a recommendation — what a joint score actually means when you have to explain it to a user.
• Hyper-personalization explained for engineers — broader context for why single-objective optimization breaks at the product level.
• Modeling Task Relationships in Multi-task Learning with Multi-gate Mixture-of-Experts (Ma et al., KDD 2018) — the MMoE paper.
• Progressive Layered Extraction: A Novel Multi-Task Learning Model for Personalized Recommendations (Tang et al., RecSys 2020) — the PLE paper, including the Tencent deployment numbers.
• Recommending What Video to Watch Next: A Multitask Ranking System (Zhao et al., RecSys 2019) — YouTube's production MTL ranker.
• Gradient Surgery for Multi-Task Learning (Yu et al., NeurIPS 2020) — PCGrad and the "tragic triad" of gradient conflict.