Multitask learning: share only when tasks help each other

On 30 July 2026, “multitask learning” can sound like a system that writes, translates and recognises images. The technical idea is narrower: train several tasks jointly so that they share part of what is learned. This can save data, compute or parameters and improve generalisation. It can also sacrifice one task to benefit another. The useful question is not how many functions a model advertises, but what is shared, between which tasks, and what evidence shows that the transfer is positive.

The distinction matters outside the laboratory. A team may put fraud detection and churn prediction in one network because both use customer records; a vehicle may estimate depth, lanes and objects from one camera; a language model may learn translation and classification. In none of these cases does coexistence prove that joint training is better. Sharing infrastructure is an engineering decision. Sharing learning is a hypothesis that needs a control.

What it means to learn tasks together

In supervised learning, a task specifies an input, an output, a loss function and a data distribution. Depth estimation and pixel classification are two tasks even when they receive the same image. Classifying two classes within one problem does not necessarily create two tasks. Nor is it multitask learning to run two models in parallel when they share neither parameters nor training signals.

Rich Caruana’s classic formulation described multitask learning as inductive transfer: signals from related tasks act as a bias that guides the learning of a common representation. The original 1997 paper did not promise that every mixture would work; its definition depends on related tasks and on what one can teach another.

The most recognisable architecture has a shared trunk and one head per task. The trunk converts the input into a representation; each head produces its own output. During training, task losses are combined, schematically, as L = λ₁L₁ + λ₂L₂ + .... The coefficients determine how strongly each objective acts on shared parameters. A “soft sharing” alternative keeps separate networks but constrains or exchanges some representations. There is no universally correct architecture: how much to share and where to share it are parts of the hypothesis.

Why joint learning can help

An auxiliary task can provide more examples from which to learn features needed by the main task. If two outputs depend on edges, geometry or syntactic structure, joint training may favour a representation that is less fitted to noise in a single label. It can also act as regularisation: the model cannot memorise one narrow solution if it must satisfy several objectives. A shared network may also avoid duplicating most of the computation required by separate models.

Yet “related” does not merely mean that tasks belong to the same industry or use the same database rows. Relatedness depends on the data, architecture, budget, stage of training and target metric. It can be asymmetric: A may help B while B harms A. Taskonomy measured transfer dependencies among 26 visual tasks and found a structure that could guide which supervision to reuse. The transferable lesson is not its particular map but its method: measure the relationship instead of inferring it from intuition.

Negative transfer: when sharing subtracts

Suppose two tasks update the same parameter. If their gradients point in compatible directions, one step may help both. If they point in opposing directions, improving one can damage the other. The PCGrad paper formalised conditions of interference and proposed projecting conflicting gradients. It is a specific intervention, not a universal guarantee: its own results depend on the problem and the baselines.

Conflict has other sources. A numerically large loss may dominate the sum even when its task is not the most important. A task with far more examples may appear more often. One head may learn quickly while another remains stuck. Two tasks may compete for a shared representation with insufficient capacity. An improvement in the mean may conceal a regression on the critical task.

Multitask training is therefore a multiple-objective problem, not one score. Sener and Koltun explicitly framed it as multi-objective optimisation and sought Pareto-optimal solutions: configurations in which one task cannot be improved without worsening at least one other. This reading prevents a model from being declared the winner merely because its average increased.

Loss weights are not a detail

Adding losses with equal weights looks neutral, but it is not. Losses may differ in units, scale, noise and learning speed. Changing metres to centimetres in a regression changes the number without changing the task’s importance. The work of Kendall, Gal and Cipolla derived weights based on each task’s uncertainty to combine regression and classification. GradNorm dynamically adjusted weights to balance gradient magnitudes and training rates.

These methods address different problems. Uncertainty weighting does not prove that tasks should share a representation. Equalising learning rates does not necessarily remove a directional conflict. Projecting gradients does not decide which task matters most to a product. Before choosing an algorithm, diagnose whether the failure comes from scale, sampling frequency, interference, capacity or priorities. A technique’s name cannot replace that diagnosis.

Task selection is part of the experiment

Adding tasks one by one creates a rapidly growing number of combinations. Training all of them together is a cheap starting point, but it may be a poor grouping. In 2021, Fifty and colleagues proposed estimating, during a single joint run, how one task’s gradient would affect another task’s loss. On Taskonomy, their grouping reduced test loss compared with training every task together. That is evidence for the method on that benchmark, not a law that transfers without validation.

A sensible policy begins with one primary task and adds auxiliaries for a causal reason: they share latent factors, provide a denser signal, supply cheaper labels or regularise a particular ambiguity. Each addition is then measured. If an auxiliary improves only training performance but not unseen data, it may be easing optimisation without improving generalisation. If it helps the mean but harms the worst group or a safety condition, that cost must remain visible.

The protocol a multitask claim should pass

First, train an independent baseline for every task. It needs a comparable budget: the same relevant data, a declared hyperparameter search, and controlled capacity or compute. Comparing one large multitask network against deliberately small single-task models attributes to transfer what may simply come from extra capacity.

Second, report results per task rather than only an average. Include variation across seeds, training cost, latency, memory and performance on relevant subgroups. Third, run ablations: the primary task alone; each auxiliary separately; all tasks jointly; a frozen trunk or partial sharing; fixed weights and an adaptive method where appropriate. Fourth, inspect the mechanism: gradient similarity, loss curves, batch frequency and capacity use. Fifth, validate under distribution shift. An auxiliary task may teach a shortcut that vanishes outside the training set.

The reading card is:

• Tasks: what input, output, loss and data define each one?
• Sharing: which parameters, layers or representations are common?
• Rationale: what transferable information should one task provide to another?
• Conflict: how are incompatible scales, rates or gradients detected?
• Control: is every task compared with an independent model under an equivalent budget?
• Decision: who sets the acceptable trade-off, and which task must not regress?

The durable skill is telling a demonstration of shared learning from a list of functions. A system is multitask because several signals alter a common representation; it is better only when per-task comparisons show useful transfer with costs and regressions exposed. The architecture shares parameters. The evidence decides whether it should have.