Can one dataset support several learning tasks?

Yes. Different choices of inputs, targets, and objectives can define different tasks from the same records.

Is classification a complete task specification?

No. It names a broad problem type but leaves the categories, inputs, timing, and success criteria unspecified.

Does low training loss mean the task is solved?

No. It shows performance on the training objective and data; intended-use evaluation and the suitability of the objective still matter.

AI Glossary / Mathematics and optimization / Beginner

Learning task

Definition

A learning task is the problem a machine-learning system is asked to learn from data. It specifies what information is available, what output is sought, and how success is assessed. In supervised learning, an important part of this specification is choosing the features and labels associated with each example.

What it means

A dataset does not uniquely determine a learning task. The same collection of product photographs could support category prediction, defect detection, or object counting. Each task gives different meaning to the outputs and may require different annotations and evaluation criteria.
Several algorithms can address the same task. Choosing a neural network does not specify what it should learn or how its output will support a decision.
Although the feature-label description is especially useful for supervised learning, the broader phrase includes other settings, such as learning representations or choosing actions from feedback. Their objectives and available feedback should be stated explicitly rather than forced into a misleading single-label description.

How it works

Begin with the intended use and the unit of prediction. State when a prediction is made, what information is then available, and what target or feedback defines success. Specify the population and conditions in which the system is expected to operate.
For a supervised task, choose a feature representation, label space, and loss or evaluation criterion. A model class and training procedure then provide a way to attempt the task. Training loss and business success may differ, so their relationship needs explanation.
Finally, define an evaluation design that reflects the intended use. If deployment involves future events, the task should not quietly rely on information recorded afterward. If the output will guide an action, distinguish predicting an outcome from estimating what would happen under an intervention.

Three practical examples

A document collection can support a task that predicts the responsible service team from message content available on arrival.
Store records can support a task that predicts next week's demand using information available before that week begins.
Product images can support a task that identifies the location of visible damage, requiring spatial annotations rather than only a damaged-or-undamaged label.

Think of it this way

Think of a learning task as the brief for an investigation. The same evidence can answer different questions, and the question determines which details matter. The analogy is limited because a machine-learning task also needs an operational mathematical or procedural definition of inputs, outputs, and evaluation; a broad aspiration is not enough.

Worked example

Consider an original dataset of 200 service requests. Each record contains the initial message, arrival time, final resolution time, and the team that eventually handled it. Two possible tasks use these records differently.
Task A predicts the handling team when a request arrives. Its input can include the initial message and arrival information. Its target is the eventual team, subject to an agreed policy for transfers. Final resolution time cannot be an input at arrival because it is not yet known.
Task B predicts the number of hours until resolution at arrival. Its target is final resolution time minus arrival time. A request arriving at 09:00 and resolved at 15:30 has target 6.5 hours. If a model predicts 5 hours, its absolute error is 1.5 hours and its squared error is 2.25 hours squared.
These tasks cannot share a performance number without explanation. An 85% team-classification accuracy and a 1.5-hour average absolute duration error measure different outcomes. Nor can a team identifier simply be treated as a duration target because both happen to be stored as numbers.
Suppose the company instead wants to choose which team should receive a request to minimize resolution time. Historical handling-team prediction does not directly answer that question: reproducing past assignments is different from evaluating the consequences of alternative assignments. That proposed use requires a revised task and evidence, not merely a new label on Task A's output.

Illustrative case study

In a fictional equipment supplier, a project begins with the instruction to use AI on inspection photographs. A workshop identifies two possible uses: flagging images for human review and estimating how many replacement parts to order. The team recognizes that a visible-defect classifier alone does not specify the second problem.
It writes separate task descriptions, identifies additional records needed for parts planning, and chooses an evaluation plan for each. This prevents a successful classification demonstration from being mistaken for validated inventory planning. The scenario is hypothetical.

Common misconceptions and mistakes

Do not describe a task only by its dataset name or algorithm. Do not assume a target is appropriate just because it is easy to extract. A historical outcome can reflect old policies, inconsistent recording, or information unavailable at prediction time.
Also avoid assuming that two tasks using the same data must benefit from joint training. Shared structure can help, but competing objectives or irrelevant dependencies can hurt. Finally, an aggregate metric can conceal important operating conditions; the task definition should make clear which errors and populations matter for the intended use.

Business use

A task specification helps a project team connect data work with an actual decision. Include the prediction moment, available inputs, target definition, output consumer, evaluation population, and action the output may support. Use a few concrete examples to expose ambiguity before large-scale labeling or model development.
When requirements change, review the task rather than only adjusting the model. Changing from predicting what happened to recommending what should happen is a substantial shift. So is changing from a monthly forecast to a prediction for each individual transaction. Both can require new targets, data preparation, and evidence of usefulness.

Check your understanding

A model predicts which team historically handled a request. Does that alone prove it identifies the team that would resolve the request fastest?

Answer: No. Predicting recorded assignments and estimating the consequences of alternative assignments are different tasks.

Related terms

Learn next

Next, write a one-paragraph task brief with the prediction moment, inputs, target, and success measure. Then test it against two realistic examples and one ambiguous case before choosing a model or commissioning annotations.

Sources

Primary terminology reference: Alexander Jung and contributors, The Aalto Dictionary of Machine Learning, learning task entry and its feature-label formulation: https://aaltodictionaryofml.github.io/ADictML_Main.pdf . The request-routing comparison and project-design examples are original illustrations.

Previous: Learning rule Next: Learning to rank