Did you know? Training one neural network to answer two related questions can save computation and help both tasks—but the same shared parameters can also make one task worse. Multi-task learning uses a common representation for several prediction heads or objectives. Its promise is useful shared structure; its central risk is negative transfer, when information or parameter updates helpful for one task interfere with another. The practical answer is to compare against honest single-task baselines, balance task losses, inspect gradient conflict and evaluate every task independently on relevant held-out data.
A model might read one customer message and predict both its topic and urgency, or analyse one image for several types of information. A shared encoder processes features once, and separate heads produce the distinct outcomes. But if one task has far more labels or a much larger numerical loss, it can dominate updates. If the tasks require incompatible cues, equal weighting does not guarantee fair training. Training goals and evidence—not the fact that the architecture has two outputs—determine whether sharing is worthwhile.
This guide explains the mechanism, solves an original two-dimensional gradient-conflict example, compares weighted losses with gradient surgery and adaptive balancing, diagnoses evaluation leaks, and transfers the ideas to a new practical problem. It covers present-day supervised learning rather than hypothetical superintelligence. The calculations are illustrative, not results from an external model experiment.
Contents
- What shared learning actually shares
- Loss scales and observation masks are the first practical problem
- Gradient directions reveal cooperation and interference
- PCGrad: projecting away a conflicting gradient component
- GradNorm and adaptive balancing address another part of the problem
- Choosing what to share and what to keep task-specific
- Worked case: one dataset, two labels and unequal evaluation costs
- Prevent leakage when related tasks share labels and records
- Batches, labels and task selection change the effective objective
- Diagnosing negative transfer without inventing a culprit
- Transfer exercise: a single camera predicts cracks and surface colour
- What a shared network cannot promise
- Frequently asked questions
- Reader pathways and primary research
What shared learning actually shares
A multi-task network commonly has a shared feature extractor followed by separate prediction heads. The encoder may convert text, images or sensor measurements into internal representations. One head produces a category, another a continuous value, and perhaps a third predicts an event probability. The architecture promises a cheaper and potentially more useful representation because related tasks can teach the same early features instead of relearning them independently.
Imagine a message triage service. A text encoder may learn representations of date phrases, negative sentiment, product names and explicit requests. A topic head classifies billing, support or sales. An urgency head determines whether a human should respond quickly. Some phrases help both decisions; a complaint about a payment failure is relevant to topic and urgency. But other cues separate them: a sales inquiry can be urgent, while a billing discussion can be calm. A single shared encoder must preserve information for both outcomes.
Multi-task learning is not the same as concatenating two labels and training without thought. Each head has its own output space, loss, sampling structure and operational decision. One head may use cross-entropy with categorical labels; another uses squared error for a measured value. Their raw losses may differ by orders of magnitude just because of units, even if both tasks matter equally. Calling their unweighted sum a neutral compromise would be a mathematical assumption, not a proven fact.
Parameter sharing comes in degrees. Hard sharing uses common encoder parameters with task-specific heads. Soft sharing may keep separate task models but penalise or encourage differences in their representations. More complex designs use gating, task-specific adapters or cross-attention. Each design changes what information and gradients interact. An architecture that shares almost everything is not necessarily more intelligent than one that isolates task-specific layers.
The first decision should be whether the tasks have a credible common structure and whether the user benefits from joint outputs. A model that predicts school subject and needed support might plausibly share language understanding, but it still needs task definitions and verified labels. If joint training confuses distinct educational concepts, two separate systems or simple rules may be safer.
Loss scales and observation masks are the first practical problem
Suppose a network has shared parameters theta and two task-specific heads. Task A has loss L_A, and task B has loss L_B. A simple objective is total loss = alpha × L_A + beta × L_B, where alpha and beta are nonnegative coefficients chosen under a policy or validation experiment. Gradients from both tasks flow through shared parameters, while each head’s private parameters receive only relevant task gradients.
The coefficients cannot be understood without loss definitions. Imagine an invented training batch where L_A = 0.4 cross-entropy units and L_B = 40 in squared physical units. Adding them without scaling gives 40.4; the numerical dominance of B does not prove B is more important. Measurement units and aggregation rules influence gradient sizes. Standardising outcomes or using a likelihood appropriate to each task may be more meaningful than arbitrarily multiplying one loss by a large number.
Missing labels are common. A customer message may have a verified topic but no reliable urgency annotation. A correct multi-task training step uses a mask so that example contributes to the topic loss but not to an invented urgency target. Setting missing urgency labels to zero creates false supervision; dropping the entire example wastes potentially useful topic evidence. The mask’s denominator must be stated and checked.
For example, consider 100 training messages, 100 with topic labels but only 60 with urgency labels. If the total topic loss across all 100 is 45, its average is 45/100 = 0.45. If the urgency loss across its 60 observed records is 30, its average is 30/60 = 0.50. Dividing the urgency sum by 100 would give 0.30, silently changing the relative task weight. Whether that is intended must be explicit rather than accidental.
An effective report records observed label counts, uncertainty about annotations, task loss type, normalisation and final weights. The missing-data guide provides the wider distinction between an unobserved outcome and a real zero. Multi-task learning amplifies the importance of that distinction because label availability can vary by task.
Gradient directions reveal cooperation and interference
A gradient is a vector of partial derivatives indicating how the loss changes with parameters. Under gradient descent, the update moves opposite the gradient. For a shared encoder, each task proposes an update direction. If the gradients point broadly the same way, a joint step can improve both locally. If they point in opposing directions, reducing one task’s loss may initially increase the other task’s loss. This is a concrete version of negative transfer.
The dot product supplies a useful local diagnostic. For two gradient vectors g_A and g_B, a positive dot product indicates an acute angle, a negative dot product indicates an obtuse angle and local conflict, and zero means orthogonality. This does not prove the global optimum is impossible or that one training run will fail; gradients vary with minibatches, current parameters and loss scales. It does identify a specific mathematical tension at one point in parameter space.
Suppose task A has gradient (3,1) and task B has gradient (−1,2) on two shared parameters. Their dot product is 3×(−1) + 1×2 = −1. The negative result shows opposition. The naive equally weighted sum is (2,3), whose negative gives an update direction (−2,−3). That step is a compromise in parameter space but not evidence that both tasks will improve equally.
Check the local first-order effects using the proposed update. For small step size eta, the change in task A loss is approximately g_A·(−eta(2,3)) = −eta(3×2+1×3) = −9eta. For task B, it is approximately g_B·(−eta(2,3)) = −eta((−1)×2+2×3) = −4eta. In this illustrative state, both can improve despite the task gradients conflicting with each other. Thus a negative dot product warns about interference without guaranteeing that the weighted sum harms one task immediately.
The geometry matters when interpreting training dashboards. If task B worsens after a shared update, first inspect its gradient direction and magnitude as well as its data and labels. If both improve, gradient opposition is still worth monitoring across training, but not a reason to declare the model broken. A single cosine similarity chart cannot replace held-out outcomes.
PCGrad: projecting away a conflicting gradient component
Gradient surgery offers a way to alter how shared updates combine. The original Gradient Surgery for Multi-Task Learning paper proposes PCGrad, which projects conflicting task gradients so one gradient’s component opposing another can be removed under a defined procedure. This is an optimiser modification, not a new label or evidence source.
Using the invented g_A=(3,1) and g_B=(−1,2), their dot product is −1, and the squared norm of g_B is (−1)^2 + 2^2 = 5. Projecting g_A away from its conflicting component along g_B produces g_A’ = g_A − (g_A·g_B / ||g_B||²)g_B. Substitute the numbers: g_A’ = (3,1) − (−1/5)(−1,2) = (2.8,1.4).
Verify the resulting dot product: (2.8,1.4)·(−1,2) = −2.8+2.8 = 0. The projected task A gradient is locally orthogonal to B’s original gradient. This removes a particular linear component of conflict under this construction; it does not prove that task A or B will generalise better, or that a larger nonlinear update preserves the relation exactly.
PCGrad for multiple tasks involves interactions among several pairwise gradients and chosen projection order. Implementations may randomise ordering and compute per-task gradients before combining them. That can increase memory and computation compared with one summed objective. Record the exact variant, handling of private head parameters and interaction with gradient clipping or distributed training. Do not assume every library calling itself gradient surgery implements the same algorithm.
Compare a PCGrad candidate against a carefully tuned simple baseline. If an ordinary weighted sum already achieves good outcomes for all tasks, extra complexity may not help. If one task systematically deteriorates under shared training and the gradients exhibit conflict, the method is a meaningful candidate. Its purpose is to address a measured optimisation problem, not guarantee the absence of negative transfer.
GradNorm and adaptive balancing address another part of the problem
Adaptive task weighting aims to balance how different losses influence shared training. GradNorm: Gradient Normalization for Adaptive Loss Balancing in Deep Multitask Networks proposes adjusting weights using task gradient magnitudes and relative training rates. The motivation differs slightly from PCGrad: one task can dominate not only because its direction conflicts with another, but because its gradient scale or pace overwhelms the others.
Imagine the topic classifier improves rapidly while urgency prediction barely changes. Even if the two task gradients are not directly opposing, the shared encoder might allocate most effective learning to the easier task. GradNorm-style methods try to prevent training rates from becoming disproportionate under a particular balancing objective. The paper reports benefits in studied architectures; the result cannot be imported as a universal ranking of algorithms.
An adaptive weighting system still needs an external definition of success. Equalising gradient norms is not the same as equalising fairness, operational value or statistical uncertainty. A task with noisier labels may show large gradients because of contradictions in its data. Increasing its influence could make the shared model worse. Before balancing, ask whether each task is well-defined and genuinely learnable.
Some losses naturally rise or fall at different speeds. A difficult task might need more representation capacity; a low-entropy task can saturate early. A training-rate heuristic that seems to rescue one task at one point may slow another needlessly. Keep per-task held-out metrics, label counts and calibration beside the adaptive coefficients rather than evaluating success from the coefficient trajectory alone.
The practical menu is therefore layered: first fix targets, masks and units; then compare a simple weighted loss, task sampling and model architecture; finally test gradient surgery or adaptive weighting if measured interference remains. A more sophisticated gradient optimiser cannot substitute for correct target meaning.
Choosing what to share and what to keep task-specific
Hard sharing is economical because one encoder computes features that several heads use. But shared representations are not intrinsically appropriate for every pair of tasks. Consider a sensor system predicting equipment temperature and the sentiment of a human maintenance note. A common input interface does not imply the same latent features are useful. Forcing early sharing may create inefficient compromises.
One strategy shares lower-level features and keeps high-level task-specific layers. Another uses separate encoders connected by adapters or cross-stitch links. A third groups tasks believed to transfer positively and separates others. These architectures should be selected based on task structure and evidence. Merely adding a head to an existing network does not create a principled multi-task model.
Task grouping is important when labels vary in quality. A broadly labelled topic task may have tens of thousands of observations, while a specialist outcome task has a few hundred reviewed cases. If the shared encoder learns a shortcut dominant in the large dataset, the smaller task can inherit it. That looks like transfer but may be spurious. Use subgroup checks, group-safe splits and targeted error review.
Some real tasks share output dependencies. If urgency depends partly on topic, predicting both independently may lose relevant structure; conditioning one head on another can help. Yet feeding predicted topic at inference creates a new error-propagation problem. If training instead feeds the true topic, evaluation must reproduce how the deployed system obtains that input. Otherwise reported urgency performance benefits from privileged information.
The criterion for architectural complexity is not whether a design sounds elegant. It is whether the joint model improves task-specific outcomes under the deployment conditions while maintaining acceptable cost and reliability. A pair of smaller models can be the right answer when interference is severe or oversight responsibilities differ.
Worked case: one dataset, two labels and unequal evaluation costs
Consider a fictional dataset of 2,000 support messages. Every message has a reviewed topic label, but only 1,200 have a reviewed urgency label. Split by customer and date so related messages are not leaked across train and test. Suppose a held-out test set of 400 independent messages contains 400 topic labels and 240 urgency labels. These are invented teaching counts; they are not a production evaluation.
An illustrative single-task topic model gets 352 of 400 topics correct, or 88%. The multi-task version gets 356 of 400, or 89%. An illustrative single-task urgency model gets 204 of its 240 reviewed urgency labels correct, or 85%, while the multi-task version gets 192 of 240, or 80%. The joint model gains one percentage point for topic and loses five percentage points for urgency. Reporting only topic accuracy would conceal negative transfer on the second job.
Now suppose urgent false negatives are particularly costly because they delay human review. Among the 240 urgency cases, imagine 60 are genuinely urgent. The single-task model finds 51, a recall of 51/60 = 85%. The multi-task model finds 45, a recall of 45/60 = 75%. These counts need not determine overall urgency accuracy by themselves; the remaining nonurgent correct and incorrect predictions complete each confusion matrix. They highlight why a second head’s operational outcome needs its own denominator.
The right next experiment is not automatically to increase urgency’s weight until its training accuracy improves. Inspect whether the 1,200 urgency-labelled records cover the relevant populations, whether the multi-task model is systematically missing a subgroup, and whether gradients conflict during relevant batches. Compare a controlled change in weighting or architecture on a validation set and reserve an untouched final test.
Also account for deployment cost. If the joint encoder reduces latency or memory substantially, that may be useful, but any trade-off between reduced compute and missed urgent messages must be acknowledged and approved by the decision owner. An engineer cannot declare the trade-off acceptable solely from an average score.
Prevent leakage when related tasks share labels and records
Multi-task datasets create unusual leakage opportunities. A label available for one head can sometimes be a near-direct proxy for another head’s target. That may be legitimate if the proxy will genuinely be available at inference, but not if it is an outcome recorded afterward. A model that predicts a future fault cannot use the later repair code as a feature just because the dataset contains it for an auxiliary task.
Group and temporal splitting are especially important. If the same customer, patient, machine or document template appears repeatedly, a row-wise random split can give the model familiarity with entities that will be new in deployment. The Data Leakage — Grouped Splits and Future Information guide explains these restrictions more generally.
All models in a comparison need the same evaluation populations. If one single-task baseline is evaluated only where labels exist but the multi-task candidate is evaluated on a different mixture, observed differences may be due to selection rather than training method. Report per-task eligible counts and the rules for missing labels. If common samples are used for paired comparison, preserve the pairing.
Task weights should be calculated from training statistics only where they depend on prevalence or variance. Do not tune them against the final test set. A multi-task model has more hyperparameters than a single-task baseline, so undisciplined search can make its final score look better merely from repeated selection. Use a structured validation process with documented settings and an independent confirmation set.
One complete final score is not enough when outcomes have different practical consequences. Report classification recall, calibration, regression error, subgroup performance and task-related latency as relevant. A global mean hides whether one task never meets its minimum acceptable result. If the joint model does not meet all required safety gates, return separate models or human review rather than burying the failure in an average.
Batches, labels and task selection change the effective objective
Two training strategies that share the same nominal task weights can still behave differently. A joint minibatch may contain many examples from one task and few from another. Task-specific minibatches may alternate training steps. If each step updates the shared encoder, the order can influence optimiser state, batch normalisation statistics and effective learning rates. Record what an epoch and update mean in the actual procedure.
Consider a fictional training plan with 300 topic-only batches and 100 urgency batches. If both are treated as equal single steps without correction, the topic task receives three times as many chances to update the shared encoder. This may be acceptable if the task value and data support it, but it is not equivalent to drawing a balanced task per step. A declared 1:1 task loss weight does not necessarily imply 1:1 cumulative gradient exposure.
If training samples contain labels for both tasks, the model may compute both losses in one step. If only one label is observed, the other head should not be trained against a fabricated placeholder. Task sampling, missing-label masks and loss normalisation interact. Small debugging batches where every label status is known can establish that each update uses the intended evidence.
Batch sampling also affects rare-event performance. If the urgency task has few positive events, nominally balanced task exposure may still yield batches with no positives. The model may learn a common default rather than the signal sought. Sampling plans and class weighting need their own validation; they cannot be inferred from the number of task heads.
The execution plan should describe update count, task proportions, masks, weights, optimiser and randomisation. These details make the training experiment reproducible and help identify whether an apparent negative-transfer effect is actually a scheduling artefact.
Diagnosing negative transfer without inventing a culprit
The clearest test of negative transfer compares a multi-task candidate with well-matched single-task baselines on independent task-specific evaluation. If task B’s performance worsens, that is an observed transfer concern. To understand why, examine task labels, sampling, gradient angles, class prevalence and architecture. A negative gradient dot product alone is not a proof of a generalisation failure, and a validation drop alone does not identify gradient conflict as the cause.
Error diagnosis should begin with concrete cases. Did the joint model confuse urgency in quiet billing requests? Did it overreact to words often used in sales? Are errors concentrated among customers with different writing styles? Inspect a manageable set of false positives and false negatives with domain experts. A second task may have encouraged a shortcut that looks statistically useful but fails when context changes.
Check optimisation state next. Are gradients from one task consistently larger? Does the balance change across training? Does clipping apply before or after task gradients are combined? A large individual task gradient may dominate even when the scalar losses look similar. Conversely, conflicting gradients may cancel and lead to apparently slow learning.
Change one intervention at a time. Compare task weights with fixed architecture, then perhaps gradient surgery with the same splits and budgets, then representation separation if needed. If three controls change at once, it is impossible to attribute improvement with confidence. Multiple random seeds can help estimate whether the observed difference is stable.
If the same result appears across experiments, document its magnitude in the unit readers care about. A two-point increase in topic accuracy and a six-point decrease in urgent-case recall convey a real trade-off; an unlabeled score that averages them conveys much less. This is how a multi-task optimisation finding becomes a responsible operational decision.
Transfer exercise: a single camera predicts cracks and surface colour
Now change the modality. An imaginary inspection system analyses images of manufactured tiles. It predicts whether a tile has a crack and estimates a continuous colour difference from a reference. Cracks depend on fine edges and local irregularities; colour estimation depends on broad illumination-normalised appearance. Some early features may be shared, but the tasks can pull representations in different directions.
Suppose 1,000 held-out tiles have crack labels, while only 500 have reliable colour measurements. A joint model identifies 80 of 100 cracked tiles and falsely flags 60 of the 900 uncracked tiles. Crack recall is 80/100 = 80%; precision is 80/(80+60) = 80/140 ≈ 57.14%. The crack evaluation denominator is all 1,000 labelled tiles. The colour model’s mean absolute error must be calculated over its own 500 measured tiles, not 1,000.
Imagine colour absolute errors across the 500 measured tiles sum to 900 colour units. Mean absolute error is 900/500 = 1.8 units. Another model has a sum of 750 and MAE 750/500 = 1.5. If the second model improves colour but reduces crack recall, the business owner must decide whether this is acceptable. A global average combining percent recall and raw colour units has no meaningful interpretation without an explicit objective.
How should the architecture respond? Inspect whether colour-specific layers or an additional task head improve colour without harming crack detection. Verify that illumination changes affect both tasks differently. If gradients conflict in shared early layers, gradient projection or a partially separated encoder is a candidate. But if crack labels are inconsistent or the camera is miscalibrated, architectural changes will not solve the evidence problem.
The generalisable lesson is to compare outcomes per task and per denominator, then decide which sharing and weighting choices serve the actual application. The mathematical gradient diagnostic from the text-message case still applies, but the data, controls, error costs and validation rules have changed.
What a shared network cannot promise
Multi-task learning does not guarantee increased accuracy, improved fairness or reduced resource use. Sharing may create efficiencies, but additional heads and gradient processing can introduce memory and training cost. A shared encoder can transfer useful structure or an unwanted shortcut. Its value depends on whether the tasks are genuinely related and evaluated properly.
PCGrad and GradNorm are research-backed proposals, not universal proof that gradient balancing will fix every conflict. Their effects depend on model architecture, loss scales, task interactions and experimental conditions. A system may prefer simple weights or separate models. The decision must be evidence-based.
Some tasks cannot share sensitive data for privacy or policy reasons, even when joint training might improve performance. Architectural convenience is not permission to combine restricted datasets or use labels beyond their authorised purpose. Separate training and inference permissions remain enforceable.
A system with task-specific outputs also requires task-specific human accountability. One head may inform an optional recommendation, while another triggers a consequential review. Sharing computation cannot erase the difference in approval or oversight requirements. Define separate thresholds, fallbacks and explanations as needed.
Every numerical case in this guide is fictional and clearly identified. No actual shared encoder, PCGrad algorithm or benchmark was run during the writing. The described methods are grounded in primary research and first-principles reasoning rather than invented experimental results.
Frequently asked questions
What is multi-task learning in simple words? One model learns to support several prediction tasks, often through a shared representation with separate output heads. The aim is to benefit from common structure without losing task-specific performance.
Can tasks help one another? Yes, when they share relevant features or provide useful complementary supervision. Negative transfer is possible when their gradients or required representations conflict. The outcome must be tested rather than assumed.
What does a negative gradient dot product mean? At that parameter state, the task gradients point more than ninety degrees apart, indicating local directional opposition. It does not prove that the overall weighted update or final model will fail.
Are equal loss weights fair? Not necessarily. Loss units, label counts, gradient scales and operational costs differ. Equal coefficients are one baseline, not an objective statement of task importance.
How does PCGrad work? It modifies conflicting task gradients by projecting away components that oppose other task gradients under a specified algorithm. It needs careful implementation and independent evaluation.
How does GradNorm differ? It adaptively adjusts task weights to influence gradient magnitudes and relative training rates. The mechanism targets balancing rather than only pairwise directional conflict.
What if an auxiliary label is missing? Mask the missing task loss appropriately and define the denominator from observed labels. Do not substitute zero as though it were a real label.
Should one multi-task model replace two good single-task models? Only when it meets both task requirements and offers a justified benefit in performance, latency, resource use or maintenance. A compact but unreliable model is not automatically a better solution.
Reader pathways and primary research
If you are a student, draw a shared encoder and two heads, then reproduce the gradients g_A=(3,1), g_B=(−1,2) and their dot product −1. Project g_A against g_B and verify the resulting dot product is zero. This small exercise reveals the difference between sharing features and combining learning objectives.
If you build AI models, begin with a matched single-task baseline and an exact record of label masks, task weights, update schedules and held-out splits. Change only one optimisation control at a time, and require every task to meet its own acceptance criteria. The data leakage guide gives the necessary framework for independent evaluation.
Primary research: Chen et al., GradNorm: Gradient Normalization for Adaptive Loss Balancing in Deep Multitask Networks (ICML 2018) and Yu et al., Gradient Surgery for Multi-Task Learning (NeurIPS 2020). Read their evaluations as results for their studied problems, not blanket guarantees.
For wider learning context, see How AI Works and The Gold Standard of Education. Good shared intelligence remains accountable to each individual reader job and its actual evidence.