Learn AI /Model Quality and Evaluation /Evaluation
Evaluation
- Starter
- Model Quality and Evaluation
- Managers & front offices
- Programme & data teams
Also called: evaluation metric, eval, evals.
Back to the milestone you came from
In five seconds
What it is
Evaluation checks how well a system performs on a defined task, while metrics are the specific measures and evals are the tests used to produce them.
In plain words
Evaluation is the organised check to see whether a system does the job you need. Metrics are individual measures, such as how often it is correct. Evals often means the tests used to generate evidence.
An everyday example
You record an app’s predicted journey time and the actual time for 20 trips along the same route. Average error is one metric. You also count how often the app is more than ten minutes wrong and compare rush-hour trips with quieter periods. Running this planned test is the eval; reviewing all the results and deciding whether the app is dependable is the evaluation. A good average may still hide consistently poor advice exactly when traffic is busiest.
Real AI evaluation can involve many kinds of outputs, not just yes-or-no forecasts. In some tasks there is no single simple ground truth, and people may need human reviewers, safety checks or multiple metrics. Also, AI systems can change behaviour across languages, populations or contexts in ways that a simple weather log does not capture.
Remember thisEvaluation is the overall procedure, an eval is a test used within it, and a metric is a defined measure of performance. Always ask whether the task, conditions and error measures match the real use.
Understand it
Understand it
Why it matters
A score can look impressive and still hide serious problems. If you approve, buy or use a system based on the wrong evaluation, you may reward the wrong behaviour, miss harmful errors or trust a tool outside the situation it was tested for. Non-specialists do not need to calculate every metric themselves, but they do need to ask: evaluated on what, using which metric, against which baseline, and for which real-world risk? Good evaluation supports better procurement, safer deployment, clearer accountability and more honest reporting about what a system can and cannot do.
How evaluation, metrics and evals relate
Show that evaluation is the full checking process, metrics are the measures inside it, and evals are the concrete tests used to generate evidence.
01
1. Define the task
State what the system is supposed to do and what success means in this context.
Draw a box labelled 'Task and success criteria' with sublabels 'use case', 'risks', and 'what matters most'.
02
2. Prepare evals
Choose test examples and references that reflect real use. These concrete tests are often called evals.
Draw a second box labelled 'Evals: test set or test procedure' connected from step 1. Add small icons for examples and reference answers.
03
3. Compare outputs
Run the system on the evals and compare the outputs with the references or reviewer judgements.
Draw a third box labelled 'Run system and compare' with two inputs entering it: 'model output' and 'reference/judgement'.
04
4. Calculate and interpret
Produce metrics such as accuracy, precision or recall, then interpret them with error patterns and context.
Draw a fourth box labelled 'Metrics and findings' showing small chips 'accuracy', 'precision', 'recall', plus a note 'failure cases and limits'.
A left-to-right flow with four boxes. Read from the task definition to the test examples, then to the model outputs and comparisons, and finally to the evidence produced. Small labels under the third and fourth boxes distinguish “evals” from “metrics” and from the wider evaluation process.
Hover or tap each box to reveal a short note: evaluation = whole process, evals = tests, metrics = measures.
Describe this without the diagram
The diagram is a four-step flow. First, define the task and what success means. Second, prepare evals, meaning the concrete test examples or procedures. Third, run the system and compare its outputs with reference answers or human judgements. Fourth, calculate metrics such as accuracy, precision and recall, then interpret them alongside failure cases and context. The key message is that evaluation is the full process, evals are the tests, and metrics are the measures produced inside that process.
With reduced motion: A static horizontal flow chart with four labelled boxes and arrows between them, plus text notes that distinguish the overall evaluation process from evals and metrics.
Evaluation is the overall process of checking whether a system works well enough for a particular purpose. An evaluation metric is the yardstick used in that process, such as accuracy or recall. People also say eval or evals to mean one test, a set of tests, or the whole evaluation setup, depending on context.
What goes in? Usually you need model outputs, the correct answers or another reference, and a clear question such as “good at what?” Then you choose how to compare the outputs with the reference. That comparison produces scores, notes, or pass/fail results.
What happens? You run the system on examples, compare its outputs with what you expected, and calculate one or more metrics. For example, a system might be right 90% of the time overall, but still miss many rare and important cases. That is why one score is often not enough.
What comes out? You get evidence about quality, limits and trade-offs. A good evaluation does not only give a number. It also shows where the system fails, whether the test matches real use, and whether the result is strong enough to support a decision.
Evaluation is often confused with a benchmark and with a loss function. A benchmark is a standard test set-up used to compare systems on a defined task under stated conditions. A loss function turns outputs and targets into a number showing error for an example or batch. Evaluation is the wider process of judging performance for a purpose; it may use benchmarks or loss values as evidence.
How “Testing a journey-time app before relying on it” maps onto the real thing
| In the story | In the AI system |
|---|---|
| daily forecast compared with recorded weather | model outputs compared with reference answers |
| overall correctness for the month | an evaluation metric such as accuracy |
| counting missed rain and false alarms separately | using more than one metric to inspect different error types |
| checking performance during planting season | evaluating on the specific real-world use case, not only on average |
A worked example
Before a thematic monitoring report is cleared, an information management officer at a regional hub evaluates a tool that assigns 100 de-identified sentences from public reports to four reporting themes.
Starting from: The tool’s labels, reference labels agreed by two officers, and a protocol defining a correct classification. Twenty sentences concern access constraints.
- The officer runs the same 100 sentences through the tool under the defined test conditions.
- The predicted theme is compared with the reference label for each sentence. The tool labels 82 sentences correctly, giving 82% accuracy.
- For access constraints, the tool identifies 12 of the 20 relevant sentences. Recall for that theme is therefore 60%.
- The officer reviews the errors and finds that most missed access constraints are expressed indirectly or appear in short bullet fragments.
Result: The evaluation produces more than one score. Accuracy is 82%, but recall for access constraints is only 60%, and the qualitative review identifies a recurring failure pattern. The officer recommends further testing before the tool is used to support the report.
In a United Nations workplace
A humanitarian affairs officer supporting a procurement unit reviews a vendor’s test results for a tool that classifies situation-report submissions. Following a bilateral meeting, the officer records in a note for the file whether the test dataset reflects field formats and languages, which metrics were reported, and which error cases remain unanswered before close of business.
A high overall score may conceal poor recall for access constraints or weak performance on short field updates. The evaluation must therefore specify the task, test conditions, reference labels and error breakdowns, rather than simply reproduce the vendor’s preferred metric.
Before you try thisBid material, operational reports and any personal, protection-sensitive or security-sensitive information must not be entered into a tool that is not approved for those data. Evaluation should use authorised, minimised and appropriately de-identified material. Procurement-sensitive findings must remain on the file and follow the applicable access controls.
Where you may hear it
- A vendor demonstration during a procurement meeting
- An ICT governance board considering a deployment
- A model review before a monitoring report is cleared
- A first reading of an evaluation protocol
Avoid confusion
Avoid confusion
Often confused with
Benchmark
A benchmark is a standard test set-up used to compare how well systems perform on a defined task under stated conditions.
Loss function
A loss function turns a model’s output and the correct target into a single number that shows how wrong the model was for that example or batch.
Accuracy
The share of cases a system labels correctly out of all the cases it was tested on.
Baseline
A reference method or result used to judge how a model performs against a relevant starting point.
Common misconceptions
Common misconception: A high score means the system is ready to use everywhere.
Correction: Scores depend on the task, data and metric. A system can score highly on a narrow test but perform poorly in another country, language, season or user group. Evaluation should check whether the test matches the real setting and whether the system generalises beyond the examples it was measured on.
Common misconception: Evaluation is just one number, usually accuracy.
Correction: Different metrics answer different questions. Accuracy tells you the overall share of correct results, but it can hide important failures, especially when one outcome is rare. In many real tasks you need several metrics plus qualitative review of failure cases.
Common misconception: If a vendor says they ran evals, that proves the tool is reliable.
Correction: The word evals only tells you that some testing happened. It does not tell you whether the tests were independent, realistic, representative, or aligned with the actual risks. A weak evaluation can produce reassuring numbers that do not hold up in practice.
Common misconception: Evaluation and training loss are basically the same thing.
Correction: Training loss is an internal mathematical target used to improve the model during training. Evaluation is a separate judgement process that checks performance on chosen tests, often using metrics that matter to users and decision-makers. A model can have low loss yet still fail on the real task you care about.
Quick check
Which statement best distinguishes evaluation, metrics and evals?
This is the most defensible distinction. In practice people use the words loosely, but it is useful to separate the overall process of judging performance from the specific measures and the specific tests that generate evidence.
Go deeper
Go deeper
The simple version
Evaluation is the organised check to see whether a system does the job you need. Metrics are individual measures, such as how often it is correct. Evals often means the tests used to generate evidence.
The technical version
Formally, evaluation is the procedure for estimating system performance on a specified task under defined conditions. Inputs may include an evaluation dataset or protocol, model outputs, reference labels or human judgements, and a set of metrics. The procedure may produce scalar scores, error breakdowns, confidence intervals, subgroup analyses and qualitative findings. An evaluation metric provides a defined measure of some aspect of performance, such as accuracy, precision or recall. An eval or set of evals often refers to the concrete test suite, prompts, datasets, rubrics or review protocol used to obtain that evidence. This differs from a benchmark, which is a standard test set-up for comparing systems on a defined task under stated conditions. A loss function turns outputs and targets into a number showing error for an example or batch. It is often used during optimisation, but may also be reported in evaluation. Sound evaluation considers distribution shift, class imbalance, data leakage, robustness and whether results generalise beyond the test conditions.
Reviewed external resources
Primary sourceAI Risk Management Framework (opens in a new tab)NIST
This official framework explains evaluation as part of risk management and trustworthy use, which suits leadership, procurement and governance audiences.
Intermediatelink checked 2026-07-31
EncyclopaediaWikipedia search: Evaluation (opens in a new tab)Wikipedia
This Wikipedia search results page helps readers scan different uses of the word across fields, which suits beginners who need orientation rather than one definitive article.
search results, not one pagelink checked 2026-07-31
CourseClassification: Accuracy, recall, precision (opens in a new tab)Google
This course resource gives a practical introduction to accuracy, recall and precision, which suits readers who want to understand common evaluation metrics.
Intermediatelink checked 2026-07-31
VideoVideo explanations: Evaluation (opens in a new tab)YouTube search
This YouTube search results page helps visual learners find different video explanations and teaching styles, so it suits beginners who prefer audiovisual learning.
search results, not one pagelink checked 2026-07-31
DiscussionCommunity discussion: Evaluation (opens in a new tab)Reddit search
This Reddit search results page shows common questions, confusions and informal explanations from the public, which suits readers who want to see how people talk about the term in practice.
search results, not one pagelink checked 2026-07-31
Where this came from
Drafted with a language model through an offline pipeline, checked against this site's schema, and every external link above fetched to see whether it answers. Treat it as a starting point and check anything that matters against the primary sources. How this site is built and what that means.
The one thing to remember
Evaluation is the overall procedure, an eval is a test used within it, and a metric is a defined measure of performance. Always ask whether the task, conditions and error measures match the real use.