# Test the work, not the vibe.

Published 2026-11-04 by GLM Handbook Editorial. Canonical: https://glmhandbook.dev/articles/llm-evaluation-that-catches-regressions/

The most useful first evaluation is a folder of tasks you recognize, answers you can check and a scoring rule you wrote before seeing the outputs. It does not need a large leaderboard. It needs to catch the failure that would make your application disappointing or expensive.

## Choose tasks before choosing a winner

Collect examples from the work the application is supposed to do. Remove private information and preserve the difficult parts. Include ordinary tasks, edge cases and a few examples that have already failed. If every prompt is a demo designed to flatter the model, the evaluation will reproduce the demo.

For an initial set, 10–30 tasks can expose useful differences. That is an engineering starting point, not a statistical guarantee. Expand the set when you need reliable estimates of uncommon failures or comparisons across many use cases.

## Write the pass condition

For extraction, define required fields and acceptable values. For code, run tests in a controlled environment. For prose, write a rubric with observable requirements: the correct audience, required facts, length and prohibited contradictions. “Good” is too vague to score consistently.

| Dimension | Example pass condition |
| --- | --- |
| Completion | The requested deliverable exists |
| Correctness | The answer matches a reference or passes checks |
| Instructions | Required format and constraints are satisfied |
| Refusal | A deliberate decline is recorded separately |
| Reliability | No service error or unnoticed truncation |
| Efficiency | Cost and elapsed time stay within the task budget |

An answer may pass some dimensions and fail others. Keep that detail. Collapsing everything into one attractive percentage makes it harder to understand what changed.

## Keep development and held-out tasks apart

Use one group of tasks while improving prompts and configuration. Keep another group untouched for the final comparison. If you repeatedly tune against every task, the result can become a measure of how closely you adapted to the test rather than how well the system generalizes.

Version the prompt set and save exact request settings. Record the model ID, endpoint, runtime or client version, date and output cap. If a hosted alias changes underneath you, those records at least preserve what was observable when you ran the test.

## Read the ambiguous outputs

Automatic checks are useful for syntax, exact values and repeatable tests. They are weaker at judging whether an answer is evasive, misleading or subtly incomplete. Read borderline outputs and record the reason for the score.

If you use another model as a judge, save its prompt and version too. Check its judgments against a small human-reviewed sample. A judge can favor a writing style or miss the same factual error as the model it is assessing.

## Repeat what matters

One run can be lucky. Repeat the high-value tasks with the configuration you intend to use and inspect the spread in outcomes. Keep the number of repetitions equal across candidates. A model with one spectacular answer and frequent failures may be the wrong choice for unattended work.

Report sample counts and the limits of the test. “No refusals in these 20 tasks” is a useful observation. “Never refuses” is a different claim. The [abliteration explainer](/articles/abliteration-vs-fine-tuning/) discusses why behavior and capability need separate evidence.

## Make it a change detector

Run the compact suite when you change a model, prompt, quantization or serving configuration. Compare each task with the previous accepted run. Look at new failures first rather than celebrating an average that conceals them.

Keep a short decision note: what improved, what regressed and why the change is acceptable. Together with [API compatibility checks](/articles/openai-compatible-api-checklist/), this turns model selection into a maintainable engineering practice.