An evaluation is a measurement of what a model can do. The reason it is harder than it sounds is that the answer depends as much on how you asked as on the model.
The three questions evaluations answer
Is it good at the task. Performance on work resembling what you want, which is what a product team needs and what benchmarks approximate badly.
What can it do at all. The upper bound of its ability under favourable conditions, which is what a safety assessment needs.
How does it behave. Whether it refuses what it should, stays consistent, and holds up under pressure. This is a property of training rather than capability.
Mixing these produces confusion. A model that declines to help with something is being measured on behaviour, and that says nothing about whether it could.
Elicitation, and why negatives are weak
The same weights can look incapable or capable depending on how hard you try. Prompting, worked examples, chain of thought, tool access, several attempts and picking the best all move the result substantially.
So a capability finding is really a finding about a model and a method. A positive result is solid, since the model demonstrably did it. A negative is weak, because it only says this attempt failed, and somebody with more effort or better tools may succeed.
This asymmetry is why frontier labs put serious effort into elicitation before declaring a capability absent, and why a model appearing safe in a quick test is not evidence of much.
Benchmarks
Public datasets with public scores, covering knowledge, reasoning, coding and safety. They make models comparable, which is genuinely useful.
Two limits. Contamination, because a benchmark on the open internet is plausibly in the training data of every model released afterwards, so a high score may be partly recall. And construct validity, because doing well on curated questions is not the same as doing well on your messy ones.
Treat them as a shortlist rather than a decision.
Dangerous capability evaluations
Frontier labs now test specifically for abilities that would be harmful if present, rather than for quality. The usual categories are meaningful uplift to somebody attempting a cyber attack or a biological or chemical one, manipulation and persuasion, and autonomy, meaning whether a model can acquire resources, copy itself or operate unsupervised over long horizons.
The point is not that a model wants to do these things. It is that capability is durable and willingness is not. Refusal training can be removed by further fine tuning, so a lab that knows what its model could do knows what an adversary would have after removing the refusals.
These evaluations are what safety frameworks are built on. A threshold is defined in advance, the model is tested against it, and crossing it triggers agreed measures rather than a discussion.
For a product team
The transferable parts are three.
Build an evaluation set of your own cases, because no public benchmark describes your work. Try hard to elicit the failure before concluding it is not there, since a negative from a lazy attempt means nothing. And rerun everything at each model version, because capability arrives unevenly and last month's result does not carry forward.