Evals Gap

This concept explains why some teams' AI tools work reliably in daily use while others break silently when conditions change slightly. Mastering it gives you a practical skill: you can look at any artificial intelligence project and see if it has a routine way to check for quality problems, and if it does not, you can close that gap with a small, honest set of test cases. This is the foundation for all other measurement techniques — such as building fixed reference sets, using simple yes-or-no checks, distinguishing between relevant and correct answers, comparing text outputs automatically, measuring performance against standards, noticing when your own tests become unreliable, testing both easy and hard questions, and balancing quality against safety and cost — 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 artificial intelligence 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: unlike a physical bridge, an AI system's behavior can shift unpredictably due to updates in its core model or subtle changes in your own code, meaning you must run these checks frequently and track every version carefully.

The evals gap is the widespread failure to build any systematic measurement into artificial intelligence 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.