Evals Gap

This is the concept that separates teams whose LLM apps quietly break in production from teams who know exactly when and why they broke. Mastering it gives you a concrete, durable skill: you will be able to inspect any AI project, see whether it has a measurement loop, and close the gap with a small, honest evaluation set. This unlocks the rest of LLM Evaluation — Evaluation Datasets, Deterministic Validators, Answer Relevancy and Correctness, BLEU and Reference Metrics, Benchmarking, Evaluator Drift, Gold and Adversarial Sets, and the Four-Axis framework — because every one of those builds on the simple act of deciding what to measure, recording it, and checking it on every change.

Imagine you are a chef who has just launched a new dish at your restaurant. You taste it once before you serve it, it seems fine, and you put it on the menu. You do not taste it again for a month. Diners start complaining — the sauce is too salty, the chicken is dry — but you have no idea when it changed, which ingredient caused it, or whether the new oven is the culprit. You only know that people are unhappy. Now imagine a chef who keeps a notebook. Every day, they cook the same sample portion, taste it, rate it on a scale of one to ten for saltiness, dryness, and flavour, and write the number in the notebook. If the rating drops, they know exactly when it dropped, and they can trace back to what changed that day — the new salt brand, the new cooking oil, the new recipe tweak. The second chef has a measurement discipline. The first has an evals gap. The evals gap, in AI, is the distance between a team that ships an LLM application with no systematic way of checking whether it still works, and a team that can answer, with evidence, 'Is this version better or worse than the last, and by how much?'

Think of a bridge. A bridge is designed, built, and opened to traffic. If nobody ever inspects it — no load tests, no crack monitoring, no routine checks — then a small crack in a support beam goes unnoticed for months, until one day the bridge fails catastrophically. The cost of failure is enormous, and it could have been caught with a small, cheap inspection regime. The evals gap is the same thing for AI systems. An LLM application is a bridge: it is built on a foundation (a model), carries traffic (users), and is subject to stress (new prompts, new data, unusual edge cases). Without inspection — without a fixed set of test prompts, a way to score the outputs, and a habit of running that score on every change — a regression slips through. The demo of the bridge, at opening day, proves nothing about its state six months later. And the demo of an LLM app — 'look, it answered this question beautifully' — proves nothing about how it will behave with a user who phrases things differently, or asks something slightly out of scope. Where the analogy breaks down: a bridge's failure modes are physical and fairly predictable; an LLM's failures are creative, unpredictable, and can be triggered by a single word change in a prompt. So the inspection regime has to be even more careful — you need not one test, but many, covering different kinds of inputs. Also, a bridge doesn't change on its own; an LLM's foundational model can be updated (by the vendor) without your action, and your own code changes alter the system's behaviour. So you need to re-run the checks more often, and you need to version the checks themselves.

The evals gap is the widespread failure to build any systematic measurement into LLM applications — meaning that quality regressions go unnoticed until users complain, because no one has defined what 'working' looks like in measurable terms, collected a stable set of inputs and expected outcomes, and checked every change against that set.

You have not yet covered any other evaluation concepts, so this page stands alone as your introduction. But it connects forward to everything listed under LLM Evaluation: Evaluation Datasets (the fixed reference set you'll build), Deterministic Validators (the simplest checks that can run first), Answer Relevancy and Correctness (the distinction between whether an answer addresses the question and whether it's true — both need measurement), BLEU and Reference Metrics (automatic ways to compare text), Benchmarking (comparing models on standard tasks), Evaluator Drift (the risk that your measurement itself changes and becomes unreliable), Gold and Adversarial Sets (the two kinds of test data you'll want), and the Four-Axis framework (the reminder that quality is only one axis — safety, cost, and reliability also need measurement). The evals gap is the problem; all those concepts are pieces of the solution. You are starting at the beginning, which is exactly right.