Baseline

The question this phase answers

Training produces a model, but a finished model is not automatically a useful model. We still need to answer:

Is this model actually good enough for the job?

This phase builds that answer one step at a time:

flowchart LR
    A[Baseline: minimum to beat] --> B[Benchmark: shared test]
    B --> C[Evaluation: complete checking process]
    C --> D[Confusion Matrix: count every outcome]
    D --> E[Accuracy, Precision, Recall and F1]

A baseline gives us a simple reference point.
A benchmark gives models a common test.
Evaluation is the full process of testing and interpreting results.
A confusion matrix records which predictions were right and how the wrong ones failed.
Accuracy, precision, recall, and F1 summarize different parts of that matrix.

We need several metrics because “good” depends on the real problem. Missing a dangerous disease and incorrectly marking a normal email as spam are both errors, but their consequences are different.

Suppose someone tells you their new model correctly predicts house prices 80% of the time. Is that good? You genuinely can’t tell — not without knowing what you’re comparing it to. That comparison point has a name: a baseline.

The simple definition

A baseline is the simplest reasonable model or method used as a reference point, so a more sophisticated model’s performance can be judged as genuinely good or not. A number on its own — “80% accurate” — is meaningless in isolation. The same number becomes meaningful the moment you know what a simple, honest baseline achieves on the same task: if a baseline gets 78%, your fancy new model barely helped; if a baseline gets 50%, your model represents real, substantial progress.

Why this needs to exist at all

Recall from the Generalization phase that a model’s real value lies in how well it performs on new, unseen data — but “how well” is a relative question, not an absolute one. Without a baseline, it’s genuinely easy to be fooled by a number that sounds impressive but isn’t, in context, impressive at all. This is a subtle but common trap: a model can look sophisticated, use enormous amounts of compute, and still barely outperform something trivially simple — and without a baseline for comparison, that fact would go completely unnoticed.

flowchart LR
    A[Simple Baseline: e.g., always predict the most common answer] --> C[Compare performance]
    B[Your trained Model] --> C
    C --> D{Does the model meaningfully beat the baseline?}

What a baseline actually looks like in practice

A baseline is deliberately simple, almost by definition — its whole purpose is to represent the bar a genuinely useful model has to clear. A few common forms:

The “always guess the most common answer” baseline. For a classification task like spam detection, if 90% of emails in a dataset aren’t spam, a baseline that always predicts “not spam” achieves 90% accuracy without learning anything at all. Any real model needs to beat that 90% meaningfully to prove it’s actually learned something useful — a number that would look impressively high in isolation but means almost nothing here.
A simple, classic algorithm. Comparing a sophisticated neural network against a basic decision tree or linear regression model, both trained on the exact same data, reveals whether the added complexity is actually earning its keep.
Human performance. For tasks where a human’s accuracy is known or measurable, human performance itself is often used as a meaningful baseline — a model matching or exceeding typical human accuracy on a task is a genuinely notable milestone.

ANALOGY vs. TECHNICAL REALITY

Analogy: Think of judging a new fitness tracker’s step-counting accuracy. Saying it’s “94% accurate” means little until you know a basic pedometer — the simplest possible baseline device — already achieves 91% accuracy on the same walks. The tracker’s real added value is a modest 3-point improvement over a much cheaper, simpler alternative, not the full 94%.

Where this breaks down: A pedometer is a fixed, physical baseline device that doesn’t change. An ML baseline is chosen deliberately by the engineer running the comparison, and different, equally valid baseline choices (always-guess-the-majority-class vs. a simple linear model vs. human performance) can tell meaningfully different stories about the same model — there’s judgment involved in choosing which baseline actually matters for a given project, unlike a physical pedometer’s fixed accuracy.

A baseline with numbers

Suppose 1,000 transactions contain 950 legitimate payments and 50 fraudulent payments. A very simple baseline always predicts legitimate.

Correct predictions = 950
Total predictions   = 1,000
Baseline accuracy   = 950 ÷ 1,000 = 95%
Fraud caught        = 0 out of 50 = 0%

The 95% accuracy sounds excellent, yet the baseline catches no fraud. A new fraud model must beat the relevant baseline—not only its accuracy, but especially its ability to find fraud without producing too many false alarms.

Useful baseline choices include:

The most common class, such as “always legitimate.”
A random prediction using known class proportions.
A simple rule already used by the business.
The current production model.
A small, understandable model such as logistic regression.

A concrete example, layered

For a simple beginner example: a model predicting whether it will rain tomorrow, evaluated against a naive baseline of “always predict whatever tomorrow’s weather actually was most often historically” (say, “no rain,” which might be correct 70% of the time in a dry climate) needs to beat that 70% meaningfully to prove it’s genuinely learned useful weather patterns, not just exploited an imbalanced dataset. For a production example: a bank building a fraud detection model would establish a baseline using its existing, simpler rule-based fraud flagging system (echoing the Function/Rule-based Logic article), and would only justify replacing that system with a new Machine Learning model if the new model demonstrably outperforms that existing baseline by a meaningful margin, accounting for the added complexity and maintenance cost of the more sophisticated approach.

Real model example: GPT-4 needed a reference point

In the GPT-4 Technical Report, results were shown beside earlier systems instead of presenting GPT-4’s scores alone.

The report lists an 86.4% MMLU score for GPT-4 and 70.0% for GPT-3.5 under its evaluation setup. GPT-3.5 provides a baseline:

measured improvement = 86.4 - 70.0
                     = 16.4 percentage points

Without the reference, 86.4% is merely a number. With it, the reader can see the measured improvement. This does not mean GPT-4 is 16.4 percentage points better at every possible task; the comparison belongs to this benchmark and setup.

Common misconception

A frequent beginner mistake: treating any high-sounding accuracy number as automatically impressive, without checking what a trivial baseline would achieve on the same data. This is precisely the trap the “always guess not-spam” example above illustrates — a model reporting 90% accuracy on a 90%-not-spam dataset has told you almost nothing about whether it actually learned anything, unless you know the baseline it’s implicitly being compared against.

Where this fits in what comes next

Baseline gives you a reference point for one specific model on one specific task. The next article, Benchmark, extends this same idea to a much broader, standardized scale — a shared, public test that many different models and labs can all be compared against fairly, using the same fixed task and scoring method.

In one sentence

A baseline is the simple reference point that gives a model’s performance number actual meaning, and without one, even an impressive-sounding accuracy figure tells you almost nothing about whether a model has genuinely learned anything useful.

Author: TechByteByByte Editorial Team
Reviewed by: TechByteByByte Admin
Published: August 31, 2026
Last reviewed: August 31, 2026