Evaluating AI models

This page is an overview of how AI models are measured. It covers public benchmarks, leaderboards based on human votes, and your own task-specific evaluations. The aim is to read model announcements critically and to choose and change models based on evidence.

Why evaluation is hard

Traditional software can be tested with exact expectations: this input must produce that output. A language model produces open-ended text, can answer differently on each run, and is good at some tasks and weak at others. A single score cannot capture that. Evaluation therefore asks narrower questions: how often does the model get this kind of task right, at what cost and speed, and how badly does it fail when it is wrong?

Benchmarks

A benchmark is a fixed set of tasks with known correct answers and a scoring method. Running a model on it gives a score that can be compared across models. Well-known examples:

Benchmarks are useful for tracking progress over time and comparing models on the same footing. They have well-known weaknesses:

• Saturation. Models improve until the benchmark no longer separates them. MMLU went from difficult to nearly solved within a few years, which is why harder benchmarks keep appearing.
• Contamination. Benchmark questions get published on the web and can end up in training data. A model may then remember answers instead of solving the tasks.
• Narrowness. A multiple-choice score says little about writing a good email, following a long instruction, or working through a two-hour coding task.
• Selective reporting. Providers tend to publish the benchmarks on which their model looks best, sometimes under settings that differ from competitors’.

Leaderboards based on human preference

LMArena, which started in 2023 as Chatbot Arena, takes a different approach. Users enter a prompt, see answers from two anonymous models side by side, and vote for the better one. Thousands of these comparisons produce a ranking, similar to a rating system in chess.

This measures something benchmarks miss: which answers people actually prefer on their own questions. It has its own biases. Voters tend to prefer longer, more confident, and nicely formatted answers, even when they are less accurate, and providers can tune models for that style. A high rank means people like the answers, not necessarily that the answers are correct.

Independent services such as Artificial Analysis combine several benchmarks with measurements of price and speed, which is useful when choosing a model for an application.

Measuring agents

For agents, the question shifts from “is this answer right?” to “can it finish this task?”. Agent benchmarks give a model tools and an environment, such as a codebase, a browser, or a terminal, and check whether the task was completed. SWE-bench is an example.

The research group METR measures how long a task, measured by the time a human expert needs, an AI agent can complete with reasonable reliability. In 2025 it reported that this length had been doubling about every seven months for several years. Measures like this describe practical capability better than exam-style scores.

Building your own evaluation

Public scores are a starting point. The decision for your application should rest on your own tasks. A practical evaluation looks like this:

1. Collect examples. Gather 50 to a few hundred real inputs from your use case, including difficult and unusual ones. Add new examples whenever a failure is found in production.
2. Define what good means. For each example, write the expected answer or the criteria a good answer must meet.
3. Choose a grading method. Use the simplest one that works:
   • Exact checks for classifications, extracted values, or JSON fields.
   • Automated tests for generated code.
   • A model as judge: a second model scores answers against written criteria. It scales well, but check a sample of its judgments by hand, because judges have biases too.
   • Human review for tone, nuance, and high-stakes content.
4. Measure more than accuracy. Record cost per request, response time, and the kind of errors. A model that is slightly less accurate but ten times cheaper may be the better choice.
5. Run it on every change. New model version, new prompt, new retrieval settings: run the evaluation again and compare.

flowchart LR
  examples["Real examples"] --> run["Run model and prompt"]
  run --> grade["Grade: exact checks, tests, judge model, people"]
  grade --> report["Accuracy, cost, speed, error types"]
  report --> change["Change model, prompt, or retrieval"]
  change --> run

Reading model announcements

A short checklist when a new model claims to be the best:

• Which benchmarks are shown, and which familiar ones are missing?
• Are the comparisons made under the same settings, such as the same number of attempts and the same reasoning effort?
• Do independent tests confirm the numbers?
• How does it perform on your own evaluation?
• What does it cost per task, not per token? A model that uses fewer tokens can be cheaper even at a higher price per token.