An AI eval is a repeatable test that scores the output of an AI model or system against criteria you define for a specific task. Scoring can be done by code, a model acting as a judge, or human review.
The word is short for "evaluation", and in practice people use it for both a single test case and the whole suite of them. "Evals" in the plural usually means the suite: the dataset, the criteria, and the scoring logic that together tell you whether a change to a prompt, a model, or a retrieval step made your system better or worse.
Evals exist because ordinary software testing does not survive contact with a language model. The same input can produce different output on two consecutive runs, and both can be correct. Asserting exact equality would fail constantly while telling you nothing. So an eval replaces the equality check with a scoring rule: a number, a label, a pass or fail against a rubric, or a written critique.
Eval vs. benchmark vs. test
These three words get used interchangeably, and they should not be. The distinction is about who owns the data and what the scoring rule looks like.
| Unit test | Benchmark | Eval | |
|---|---|---|---|
| Data | Hand-written cases | Shared and standardised | Your own, task-specific |
| Scoring | An assertion you write | Fixed, standardised metric | Criteria you define |
| Result | Pass or fail | A comparable score | A graded score or verdict |
| Purpose | Prove code is correct | Compare models to each other | Prove your system works for your users |
| Determinism | Fully deterministic | Standard metric, sampled output | Non-deterministic when a model judges |
A unit test is deterministic and binary. parseDate("2026-08-18") either returns the right value or it does not. There is nothing to grade.
A benchmark is shared and comparative. MMLU, GSM8K, SWE-bench, and HumanEval all exist so that different models can be scored on identical data with an identical metric, which is what makes a leaderboard meaningful. Benchmarks tell you which model is generally stronger. They cannot tell you whether that model handles your customers' refund requests correctly, because your refund requests are not in the benchmark.
An eval is the private, task-specific counterpart. You supply the data, drawn from your own product, and you define what "good" means for your use case. That is the whole point: an eval measures your system on your problem, which is what makes it predictive of what your users will actually experience.
The practical consequence is that a benchmark score is a purchasing decision and an eval score is an engineering decision. You read benchmarks when picking a model. You run evals every time you change a prompt.
A worked example
Say you have a support assistant that answers billing questions from a knowledge base. You want to know whether it refuses to invent policies it cannot find.
1. Collect the cases. Pull twenty real questions from your logs. Ten have a clear answer in the knowledge base. Ten deliberately do not: they ask about policies you have never published.
2. Define expected behaviour. For the first ten, the answer must state the correct policy. For the second ten, the assistant must say it does not know and offer to escalate. Anything confident and invented is a failure.
3. Write the scorer. For the answerable cases, a code-based check gets you started: does the response contain the policy number from the reference answer? That is a proxy, and worth naming as one, since a reply can cite the right number and still describe it wrongly. For the unanswerable cases, use a model judge with a narrow prompt:
The assistant was asked a question with no answer in its knowledge base.
Does the response admit uncertainty rather than stating a policy as fact?
Return PASS or FAIL and one sentence of reasoning.4. Run it and record a baseline. Suppose you score 10/10 on answerable questions and 4/10 on unanswerable ones. That 4/10 is the number you are trying to move, and having it written down is most of the value.
5. Change something and re-run. Add a line to the system prompt instructing the assistant to answer only from retrieved context. Re-run. Now you get 9/10 on unanswerable questions but 8/10 on answerable ones: in two cases the model decided its retrieved context was too thin to rely on and withheld the policy number entirely, so the substring check finds nothing.
That trade-off is the eval doing its job. Without it you would have shipped the prompt change, felt good about the hallucination fix, and never noticed the regression on the questions you can actually answer. Twenty cases and an afternoon bought you a fact you could not have guessed.
Note what this is not. It is not a benchmark, because the data is yours and nobody else can run it. It is not a unit test, because "admits uncertainty" has no exact string to compare against.
Where to go next
The example above is one criterion over twenty rows, a deliberately small starting point. Real eval work involves choosing between offline and online evaluation, calibrating model judges against human labels, curating production traces into regression cases, and deciding where human review is non-negotiable.
That is the practitioner's side of the subject, and it is covered in depth in AI Evals 101: targets, datasets, and evaluators; the 2x2 that tells you when your evaluator is wrong rather than your model; and the flywheel that turns production failures into permanent tests.
If you remember one thing from this page, make it the definition. An eval is a repeatable, scored test of your AI system on your own data, against criteria you wrote. Everything else is detail.