What Machine Learning Solves: Regression, Classification, Clustering, Ranking
The four task families every ML practitioner must recognise on sight, with the output type, evaluation metric, and real examples of each.
- Classify any ML proposal as regression, classification, clustering, or ranking and state its output type
- Name an appropriate evaluation metric for each of the four task families
- Turn a vague business request into a concrete ML task specification
- Explain why the task family determines the model family you may even consider
An interviewer slides a sheet of paper across the table: "We have click data from our shopping app. Build us AI." That is all. The correct next question is not "which algorithm?" — it is "do you want a number per user, a yes/no flag per session, hidden groups of users, or an ordered feed?" Four different answers, four different datasets, four different metrics, four different careers. Choosing the task family is the first technical decision in every ML project, and most bad projects die right here, before a single line of model code.
Every ML problem is one of four shapes. The field looks infinite in its applications and surprisingly narrow in its task types. Strip any ML project proposal down and you will almost always find one of four shapes underneath: predict a number (regression), predict a category (classification), discover hidden groups (clustering), or produce an ordered list (ranking). Learning to see the shape instantly is the single highest-leverage skill in the foundation stage — because the shape decides your label format, your loss function, your metrics, your model shortlist, and what "success" even means.
Regression — predict a continuous quantity. The label is a number on a continuous scale, and you want a number out. How much will this house sell for? How many minutes until the courier arrives? What will tomorrow's peak electricity demand be? The model outputs ŷ ∈ ℝ, and evaluation compares prediction to truth with error measures in the original units: MAE (mean absolute error — average rupee-sized miss, robust to outliers), MSE/RMSE (squared error — punishes big misses harder; RMSE puts the penalty back in original units), and R² (what fraction of the target's variance your model explains; 0 means no better than predicting the mean). Regression models the magnitude of an outcome. A classic beginner mistake is treating a discrete-count target ("how many complaints next month?") as either trivially regression or trivially classification — counts are their own family (Poisson-flavoured), but plain regression is a defensible first baseline when counts are large.
Classification — predict a discrete label. The label is one of a small set of categories. Binary: spam or not, default or not, tumor malignant or not. Multiclass: which digit (0–9), which department will this ticket go to, which disease. The model outputs either a hard label or a probability per class, and evaluation uses accuracy (only when classes are balanced — more on the trap in Module 2), precision/recall/F1 (the workhorses when costs are asymmetric), and ROC-AUC / PR-AUC (threshold-free ranking quality). Note the tight relationship: a binary classifier that outputs probabilities is really producing a continuous score, and you threshold it to a label. That threshold is a business decision — catching fraud at 0.5 versus 0.1 catches different amounts of fraud and generates different amounts of false alarms.
Clustering — discover structure without labels. No one hands you the answer; the goal is to find groups that are internally similar and externally different. Customer segmentation by purchase behaviour, grouping sensor faults into failure types, organising documents into topics before anyone has a taxonomy. The output is a partition (or soft membership) of your data, and evaluation is the field's eternal pain: there is usually no ground truth to score against. Practitioners use internal measures (silhouette — how much closer points are to their own cluster than to the nearest other one), stability checks (does the clustering survive resampling?), and, most importantly, domain usefulness — does a human look at the segments and say "yes, these are real, actionable groups?" Clustering is a lens for human decision-making, not an answer machine.
Ranking — order items by relevance. The task is not "is this relevant?" in isolation but "given a query and a pool of candidates, produce the best order". Search results, recommender feeds, document retrieval, ad ordering. Ranking is built from classification-like relevance judgements but evaluated as sequences: precision@k (of the top k shown, how many are relevant), MAP (mean average precision across queries), NDCG (discounted gain — early positions matter more, graded relevance allowed). A system can be excellent at classifying each item independently and terrible at ranking if it does not calibrate scores across items. Ranking deserves its own lesson (and often its own engineer) precisely because the unit of quality is the list, not the item.
How to decide, in practice. Ask the stakeholder one question: "what will you do differently, per what unit?" A price on each house → regression per house. A red flag on each transaction → classification per transaction. A segment for a marketing campaign → clustering per customer cohort. A reordered home feed → ranking per session. Then write the one-sentence spec: predict [label] from [features available at prediction time] for [unit], evaluated by [metric] on [held-out data]. If you cannot fill in that sentence, you do not yet have an ML problem — you have a conversation you have not finished.
| Family | Output | Classic metrics | Real examples |
|---|---|---|---|
| Regression | A continuous number | MAE, RMSE, R² | House price, ETA in minutes, demand forecast |
| Classification | A category (or probability per category) | F1, precision/recall, ROC-AUC | Spam, fraud, disease, ticket routing |
| Clustering | Group assignments / memberships | Silhouette, stability, domain usefulness | Customer segments, document topics, fault types |
| Ranking | An ordered list | precision@k, MAP, NDCG | Search results, recommender feed, ad order |
When someone says "build a recommender", the ML core is almost always a ranking problem: score candidate items for a user, then order them. The scoring model may be collaborative filtering, a gradient booster, or an LLM — the evaluation unit is still the ordered list.
Predict [label] from [features available at prediction time] for [unit], evaluated by [metric] on [held-out data]. Every blank you cannot fill is a decision you are postponing — and postponed decisions become leaky pipelines.
- 1
(a) "Estimate each delivery rider's remaining time, in minutes"
Regression — output is continuous minutes per delivery. Metric: MAE (easy to explain: "off by 6.2 minutes on average") or RMSE if large misses are extra costly.
- 2
(b) "Flag each payment as fraud or not fraud, for the review queue"
Binary classification per transaction — but note the output used operationally is a score sorted into a queue, so PR-AUC and precision@queue-length matter more than raw accuracy (fraud is rare).
- 3
(c) "Group our 40,000 members into behaviourally distinct clusters for a newsletter test"
Clustering — no labels exist; output is group memberships per member. Metric: silhouette plus human validation that segments are actionable.
- 4
(d) "Order job-internship matches on each student's home screen"
Ranking — each student session gets an ordered list of internship cards. Metric: NDCG@10 or click-based precision@5.
- 5
(e) "Predict how many lab-session no-shows the department will have next month"
Regression on a count (or a dedicated count model later). Unit: no-shows per month. Metric: MAE on held-out months. Count-specific: Poisson deviance is the specialised upgrade — know it exists, start with MAE.
Solution
(a) regression · (b) classification · (c) clustering · (d) ranking · (e) regression (count-flavoured). Notice how each answer immediately implies a different label format, a different metric, and a different failure conversation with the stakeholder — the algorithm was never the deciding factor.
Find three data-ish requests in your own life or campus ("predict exam results", "improve our club's Instagram", "reduce canteen queues"). For each: write the spec sentence, name the family, and state one metric you would argue for in the meeting. If a request is not ML-shaped at all, say so — "just average last year's numbers" is often the winning answer.
Hint: If there is no label and no evaluation story, it may be a dashboard, an A/B test, or a rule — not an ML problem.
Jumping to algorithms before fixing the task family
The family determines the loss, metric, and shortlist. "Use a neural net" is never the first decision; "regression on minutes, MAE, features from trip history" is.
Using accuracy for a rare-event classification problem
99% accuracy by always predicting "not fraud" on 1% fraud data is worthless. Use precision/recall/F1 or PR-AUC, and state the business cost of each error type.
Treating clustering output as ground truth
Clusters are hypotheses for humans to validate. If no downstream decision changes based on the segments, the clustering has zero value regardless of its silhouette score.
Framing ranking as per-item classification and evaluating with accuracy
The quality unit is the ordered list (precision@k, NDCG). Two systems with identical per-item AUC can differ hugely in top-of-list quality — that difference is the product.
A telecom company wants to "use AI to reduce customer churn". Rewrite this as an ML task specification: name the family, the unit, the label, and a primary metric — and name one non-ML alternative that should be considered first.
Family: binary classification (churn / no-churn) per subscriber per month; operationally a risk score sorted into a retention-call queue. Label: cancelled within the next billing cycle (defined before modelling, from historical records). Features: usage trends, complaints, tenure, plan, payment delays — all available at scoring time. Primary metric: PR-AUC or precision@top-N-call-list (churn is rare, and the call list is finite), plus the business metric of retained revenue. Non-ML alternative: a rule like "call everyone with two consecutive late payments" — your model must beat that rule on the same cost basis, or it is decoration.
Source: Standard product-sense + ML framing question in analyst and ML-engineer screens.
- Four shapes cover almost all applied ML: regression (number), classification (label), clustering (groups), ranking (ordered list).
- The shape fixes the label format, the loss, the metric, and the model shortlist — decide it first.
- Regression uses MAE/RMSE/R²; classification uses F1/AUC; clustering uses internal measures plus human usefulness; ranking uses precision@k/MAP/NDCG.
- Rare-event classification makes accuracy a trap; choose metrics that price false alarms and misses.
- Write the spec sentence (predict X from Y for Z, evaluated by M) before touching a dataset.