A model can top a public leaderboard and still be wrong for your product. Benchmarks measure someone else's questions. What you need to know is how the model behaves on yours.
Here is a practical way to evaluate a language model for the work it will actually do.
Start with your own tasks#
Collect real inputs from the workflow the model will serve: support tickets, contracts, code reviews, whatever it is. Include the ordinary cases and the ones that make your team sigh.
For each, write down what a good answer looks like. Fifty well-chosen cases tell you more than a thousand borrowed ones.
Score what matters#
"Is it good?" is too vague to measure. Break it into parts you can score:
- Correctness. Is the answer right?
- Completeness. Did it cover what was asked?
- Tone and format. Would you send it as written?
- Safety. Does it avoid what it must never do?
Use automatic checks where a rule can decide, and expert reviewers where judgement is needed. Mixing both keeps the process fast without losing the nuance.
Probe for the gaps#
Normal tests show how a model behaves when things go well. Red teaming shows what happens when they do not: tricky wording, missing information, requests that push at the limits.
Keep a record of every failure you find. Each one becomes a permanent test, so the same problem cannot return unnoticed.
Set a gate#
Decide before you test what result is good enough to ship, and what blocks a release. A threshold agreed in advance is much harder to talk yourself out of on deadline day.
Then run the same tests after every change to the model, the prompt or the data. The comparison is only meaningful if the test stays the same.
Where we can help#
We build customised evaluation pipelines for models and agents, with expert reviewers and red teaming included. Read more about our evaluation service, or see how it fits with data and fine-tuning.
