What is multitask learning?

Training one model on several related tasks together, sharing a representation so tasks borrow each other's evidence.

When does it beat separate models?

When tasks genuinely share underlying signals, especially when some tasks have little data of their own.

What is negative transfer?

The harm done when unrelated tasks are forced to share, dragging each toward the others' patterns.

Is it the same as transfer learning?

Related but distinct: transfer learning reuses a finished model on a new task; multitask trains the tasks together from the start.

Is a foundation model a multitask model?

In spirit: it was trained on enormous mixtures of tasks, and its generality is the multitask dividend at scale.

AI Glossary / AI and machine learning / Intermediate

Multitask

Definition

Multitask describes learning several related tasks together in one model: one representation, several output heads, so each task borrows evidence from the others instead of learning alone.

What it means

The idea is apprenticeship by sharing. Tasks that draw on the same underlying signals, demand in different regions, risk across product lines, can learn faster together than apart, because patterns found for one task serve the rest.

The gain is data economics: each task effectively trains on the family's combined data for its shared parts, which is why thin tasks in a real family benefit most.

The risk is negative transfer: when tasks are not truly related, sharing drags each toward the others' patterns, and the joint model can underperform separate ones.

Multitask is also an engineering economy: one model to serve, monitor and retrain instead of a fleet, which matters when the model count has outgrown the team.

For a business, the multitask question recurs constantly, one model or many, and the honest answer is empirical: test the joint model against separate ones, because relatedness is a hypothesis, not a hope.

The term covers a spectrum: hard sharing, where layers are fully common, to soft sharing, where tasks keep separate parameters but are nudged toward agreement.

How it works

Group candidate tasks and argue their relatedness explicitly: shared signals, aligned units, comparable data quality.

Choose the sharing structure: one representation with per-task heads, or joint training with task-specific penalties.

Train jointly and validate per task against strong single-task baselines, since the family average hides failing members.

Watch for negative transfer per task, and give demonstrably different tasks their own models without guilt.

Operate the joint model as one system with per-task dashboards, so shared failure and single-task failure are both visible.

Log per-task sample counts in training, since an imbalanced family lets the big tasks dominate the shared representation.

Three practical examples

One demand model serving twelve regions with regional heads, outperforming twelve separate models on the thin regions.
A support platform predicting resolution time and satisfaction together, since both draw on the same case signals.
A bank scoring several product risks jointly, until a genuinely different product is split out after negative transfer appears.

Think of it this way

Think of a medical resident rotating through wards: skills from cardiology inform the eye for pneumonia, because the wards share a patient. Rotations work because the cases are cousins, not strangers.

Worked example

the thin region that gained

Suppose a delivery firm forecasts demand for nine cities, and the two newest cities have four months of history. The figures are illustrative.

Separate models for the new cities swing wildly with each week of data, while a multitask model with per-city heads borrows the seven established cities' seasonal structure.

The new cities' forecasts steady immediately, and the old cities lose nothing, because their own data dominates their own heads.

The test that matters is run anyway: each city's joint-model error against its single-task alternative, and the family is kept only where it wins.

Illustrative case study

A fictional retailer folded a new pharmacy category into its grocery multitask model, reasoning that retail is retail, and pharmacy forecasts degraded for a quarter.

The categories drew on different drivers, prescription cycles versus weather and promotions, and the shared representation averaged the two into mediocrity.

The invented lesson: relatedness is tested, not asserted. Give the odd task its own model early, and re-attempt the family when evidence says it belongs.

Common misconceptions and mistakes

Multitask always helps. It helps when tasks share signals; between strangers it imports noise, the negative transfer.
One model means one metric. Every task needs its own validation and dashboard, because the family average hides the failing member.
It is only a training trick. It is also an operating model: one service instead of a fleet, with the governance that implies.

Business use

Try multitask when several tasks share signals and at least one is data-thin.

Validate per task against single-task baselines, and let any task leave the family when its own numbers say so.

Count the operating benefit honestly: one model to run, but per-task monitoring still required.

Revisit the family membership as products and processes change, since relatedness decays like everything else.

Ask vendors which tasks share the model you are buying, since the family membership is part of what you are purchasing.

Check your understanding

Why must a multitask model be validated per task rather than on the family average?

Answer: Because sharing can help some tasks and harm others, and the average conceals the harmed members, so each task's error against its own single-task baseline is the only honest test of whether the family earns its keep.

Related terms

Learn next

AI for Business Owners helps you run the one-model-or-many decision on evidence: https://aiforbusinessandlife.com/academy/ai-for-business-owners. [C2]

Model

Sources

[S24] scikit-learn documentation, Glossary of Common Terms and API Elements; [S17] Ruder, An Overview of Multi-Task Learning in Deep Neural Networks. Full URLs are in the source ledger. Verified 11 October 2026.

Previous: Multistate model Next: Multitask learning