In this write-up I split apart these terms that float around in the world of AI Engineering - Evals, Benchmarks, Verifiers and give a brief history on their evolution as I have observed working in the field.
The story for all 3 begins in the need to generate proof.
Proof that probabilistic model actually works.
(While the true boundaries on them are not as well defined as I draw in my high level diagram, the diagram is a pretty good mental model. For a deeper picture of how evals, verifiers and benchmarks have started spilling over into greyed lines, checkout my more detailed plot later in my blog.)
Benchmarks
The core concept of benchmarks is to prove generalizability and set a standard. It’s the equivalent of defining a measuring scale that everyone in the field can reuse and report performance on a diverse set of problems. Benchmarks are shaped as a collection of examples or problems with known or algorithmically verifiable solutions - meaning the judgement is objective, verifiable and not subjective, based on personal taste.
Generalizability vs Specificity
A quick detour on generalizability vs specificity. Most real world problems and their solutions have a tradeoff between precision and recall. Meaning -
- If you try to build a solution that can tackle the full diversity of problems, your solution will generally be less precise on any single problem. You have taken a hit on precision in favor of improving recall (coverage). A generalized solution.
- If on the other hand, you scope down the problem to a very specific subset and build a solution only for that, your solution will likely be much more precise but cannot diversify equivalently on the problems outside your defined subset. You have taken a hit on recall in favor of improving precision. A specific solution.
Benchmarks have been heavier toward measuring generalizability and you’ll often find them being reported by people building solutions that can generalize well across many problems. Example - when a frontier lab says they are “releasing a SOTA model” - the SOTA claim is based on scores against most popular benchmarks.
A benchmark becomes useless if everyone can score high on it - aka “saturation” or if the held out test set leaks out for anyone to game. In fast evolving spaces, like frontier labs releasing AI models, this becomes a major problem and starts pushing on the question - what should benchmarks really become to remain valid scales of measurement?
There’s no single answer, but the latest trends point toward puzzle solving dynamic benchmarks like - Arc AGI, meta benchmarks like METR’s task completion horizon and companies moving down along the Y-axis to make more specific benchmarks for their own usage and data instead of relying on public benchmarks like Databricks’ study on Agent Harness x LLM model effectiveness on their codebase.
Brief History
Benchmarks trace back to classic ML competitions like MNIST and ImageNet (2009-2012), where a fixed, labeled dataset let researchers compare models on a level playing field. NLP followed with GLUE and SuperGLUE (2018-2019), then the LLM era brought MMLU, HellaSwag, and BIG-Bench (2020-2022) to test broad knowledge and reasoning at scale.
As models saturated older benchmarks, harder ones emerged, like GPQA, MATH, SWE-bench (2023-2024) targeting expert-level and real-world coding tasks. RLVR (Reinforcement Learning with Verifiable Rewards) then became closely tied to benchmark design, since training and evaluation increasingly relied on the same verifiable signal. Today benchmarks face a “contamination and saturation” crisis, pushing toward dynamic, harder-to-game evaluation suites.
Verifiers
The core concept of a verifier is to deterministically, objectively and algorithmically judge an outcome as pass or fail (or be able to score it). These are often defined for a narrow, specific task, where the judgement rubric can be cleanly implemented. Verifiers are frequently used inside an RL loop for achieving a specific task rather than for reporting model quality on more generalized tasks.
To describe the true power of having a verifier one must imagine what improving probabilistic solutions (like Agents solving a task) really looks like. The dev loop is basically - propose a solution -> judge against problem set -> learn from failures -> propose a solution …
Paths to automated improvement in AI are known (fine-tuning, reinforcement learning etc.). Verifiers plug the automated judgement gap and that unblocks one to run this loop fully autonomously.
The best example of a successful improvement flywheel exhibits in the rise of agentic coding. Coding is by default verifiable to some degree (ex - leetcode is a verifier for competitive coding, compile errors are a signal on verifiability of solutions).
Algorithmic verifiers lately are LLMs-as-judge under the hood - example Deepseek-R1, a model trained improved by RL based on verifier signal from another LLM. Verifiers are not a formally solved problem the field is active in trying to find a solution that can generalize - example Erik Meijer’s guardians project.
The hottest place for verifiers right now is in unblocking “software factories” - autonomous agents building software without any human intervention. If one could define generalized automated verifiers, the loop can be closed and maybe humans never have to code again.
Brief History
The concept of verifiers predates deep learning entirely. Compilers, type-checkers, and unit tests have been “verifiers” of program correctness since the earliest software engineering practices. In classical AI, formal proof checkers and constraint solvers played a similar role, giving deterministic ground truth.
The term gained new prominence in LLM training once RLVR emerged from DeepSeek-Math and Tulu 3 in 2024, using verifiable reward functions that evaluate correctness via deterministic rules. This let models be optimized on math, code, and other domains using rule-based or reference-answer checks rather than learned preference models.
Verifiers have since become central to “AI engineering” practice more broadly, since they provide a machine-checkable signal for exact-answer checks, unit tests, or formal proof checking instead of relying on human or model judgment.
Evals
While Evals in reality is an umbrella term for everything described in this blog, more recently Evals are used as a term to imply - measuring the subjective characteristics of an AI system. The core concept is that - beauty is in the eye of the beholder - and so judgement by default is subjective. Only subject matter experts or the developer knows what good looks like. Evals describe a framework to formalize this subjectivity into something that can be objectively measured.
Hamel Hussain and Shreya Shankar have released the most popular framework for practicing this field. Many SaaS tools offer ways to enable this framework or some loose equivalent of it via dashboards (example - Langsmith, Braintrust, Arize etc.)
The framework is fairly complex to accomplish rigorously and involves 9 or so steps to do well. I have written about this in more detail in my project eval-loops which releases open source skills for you to implement Evals with your coding agent and SaaS tool of choice.
Brief History
Human evaluation of AI outputs is as old as AI itself, from the Turing Test (1950) through early expert-system audits and human-rated MT quality scores in the 1990s-2000s. In deep learning, evals largely meant benchmark accuracy until RLHF (2017-2022) introduced human preference judgments as a first-class training signal, popularized by InstructGPT and ChatGPT.
As LLM products proliferated post-2022, “evals” became AI-engineering shorthand for custom, product-specific quality checks often combining human review, rubric grading, and LLM-as-a-judge scoring.
Tooling matured quickly (2023-2025) with frameworks like OpenAI Evals, Braintrust, and LangSmith, treating evals as the “unit tests” equivalent of prompt/product iteration. The current frontier blends evals with verifiers and RLVR with teams increasingly try to convert subjective, custom evals into objective, automatable checks wherever a task’s correctness can be made verifiable.
The full landscape
The clean three-box mental model at the top is a lie of convenience — handy, but the real boundaries are fuzzy. Below is the same idea plotted properly: every technique placed on two axes — how subjective vs. objective the judgement is (horizontal), and how specific vs. generalizable the target is (vertical). The three concepts settle into three quadrants, the fourth (top-left) has no clean name, and a whole population of hybrids smears across the middle.
Hover a dot (or tap on mobile) for details · tap a legend swatch to highlight a group.
Show all points as a table
| Name | Category | Why it sits here |
|---|---|---|
| MMLU | Benchmarks | Multiple-choice, auto-graded, spans dozens of academic domains |
| HellaSwag | Benchmarks | Objective scoring, broad commonsense/reasoning coverage |
| ARC | Benchmarks | Objective scoring, broad commonsense/reasoning coverage |
| GPQA | Benchmarks | Objective grading, but narrower (grad-level science) than MMLU |
| GSM8K | Benchmarks | Objective, but domain-limited to grade-school math |
| BIG-Bench | Benchmarks | Explicitly designed as a broad multi-task objective suite |
| Compiler/type-checker | Verifiers | Fully deterministic, only meaningful for one narrow task (does code compile) |
| Unit test / CI suite | Verifiers | Pass/fail, tied to one specific codebase |
| RLVR math answer-checker | Verifiers | Exact-match against ground truth, used for one task type (math correctness) |
| Regex / JSON-schema validator | Verifiers | Rule-based, extremely narrow |
| Chess/game legality checker | Verifiers | Deterministic rule engine, single domain |
| Custom product eval (e.g. refund policy adherence) | Evals | Human/LLM-judged, tightly scoped to one product |
| Internal red-teaming (specific harm category) | Evals | Judgment call, narrow target behavior |
| Human QA rubric scoring for a feature | Evals | Subjective rating, single feature |
| A/B-tested response quality review | Evals | Human preference, specific to your app's outputs |
| LLM-as-a-judge (open-ended custom rubric, one product/use-case) | Evals | Judge model given a loose, product-specific rubric (e.g. 'is this response helpful and on-brand for our support bot'). Still fundamentally a subjective call, and scoped to one use case, so it sits with hand-built Evals rather than Benchmarks. |
| Chatbot Arena | Subjective + generalizable | Human preference voting (very subjective), spans open-ended chat across huge topic variety |
| LLM-as-a-judge (general-purpose open rubric, e.g. G-Eval / pairwise preference) | Subjective + generalizable | Model judgment rather than a hard rule, but applied as a repeatable method across many tasks/domains |
| MT-Bench | Subjective + generalizable | GPT-4-judged, multi-turn, somewhat more scoped than Arena |
| AlpacaEval | Subjective + generalizable | Pairwise LLM-judge preference, broad instruction-following coverage |
| SWE-bench | Boundary / hybrid | Execution-based (tests pass/fail) but drawn from real-world repo issues, giving it more breadth than a plain unit test |
| LLM-as-a-judge (structured rubric with defined criteria, applied broadly) | Boundary / hybrid | Rubric breaks 'quality' into checkable sub-criteria (e.g. faithfulness, citation presence, format compliance) and is reused across many tasks. More consistent/objective than open preference judging, and still broad -- a bridge between the top-left quadrant and Benchmarks. |
| LLM-as-a-judge (binary/strict rubric, one specific task) -- verifier-adjacent | Boundary / hybrid | When the rubric collapses to a clear pass/fail check for one narrow task (e.g. 'does the answer match the reference fact, yes/no'; 'did the agent call the correct tool'), the LLM judge is functionally acting as a verifier -- high objectivity, narrow scope. The x/y position is nearly identical to a hand-coded verifier; the only difference is the check is executed by a model prompt instead of deterministic code, which makes it faster to build but noisier/less reliable than a true rule-based verifier. |
| LLM-as-a-judge (reference-based equivalence check, e.g. semantic match to a gold answer) | Boundary / hybrid | Given a ground-truth answer, the judge checks semantic equivalence rather than open quality. More objective than preference judging since there's a target to check against, and reusable across a domain (e.g. any QA task with a gold answer) rather than one product -- sits between Benchmarks and Verifiers. |