Knowing Whether the Model Actually Works
Here’s a common situation.
A team compares models on public benchmarks and selects one.
They deploy it.
On their own workload, the results don’t match the leaderboard.
The benchmark wasn’t wrong. It simply measured something other than what the team needed. This is the core challenge of evaluation.
Evaluation is how you know whether what I touched in last three weeks - pretraining, fine-tuning, post-training actually produced what you wanted. Without it, every decision above it is a guess.
What benchmarks are good for
Public benchmarks are a useful first filter. They tell you which models are roughly in the same league, which genuinely helps when you’re narrowing a long list down to a few candidates.
They’re less suited to the final decision, for a straightforward reason: a single leaderboard number compresses many different capabilities into one ranking, and that ranking rarely matches the weighting your use case needs. A model that’s strong on competition math may be average at summarizing your support tickets. The benchmark measured one capability; you need another.
So benchmarks narrow the field. Your own evaluation makes the call.
The evaluation that matters most is your own
The most reliable signal comes from building an evaluation set out of your own workload.
This doesn’t need to be elaborate. A few dozen to a few hundred real examples from your domain - actual inputs, with known-good outputs or clear judging criteria will tell you more. There are three parts to doing it well:
Representative inputs. Pull from real traffic rather than invented examples. Edge cases are where models actually differ.
A clear definition of “good.” Sometimes there’s a correct answer to check against. Often there isn’t, and you need a rubric - accuracy, tone, format, safety, whatever matters for your case.
A way to score against that rubric. This is where most of 2026’s evaluation tooling focuses.
The scoring problem splits cleanly. When answers are verifiable - a number, a passing test, a valid structure - scoring is automatic and cheap. When answers are open-ended - a summary, an explanation, a draft, you need a judge.
Judging open-ended outputs
For open-ended outputs, the common approach is LLM-as-judge: use a capable model to score another model’s outputs against your rubric. It’s fast, inexpensive, and scales to thousands of examples quickly.
It comes with characteristics worth designing around:
Judges have biases - they often prefer longer answers, their own style, or the first option shown.
A judge is only as good as the rubric it’s given. A vague rubric produces noisy scores.
For higher-stakes decisions, keeping humans in the loop matters - at minimum to confirm the judge agrees with human judgment on a sample.
The pattern that tends to work: automatic scoring for the verifiable parts, LLM-as-judge for the open-ended parts, and periodic human spot-checks to keep the judge calibrated.
The solutions architect lens
Evaluation is infrastructure, even though it doesn’t always look like it.
Evaluation is a system, not a one-time test. A deployed model drifts and the provider updates it, your traffic shifts, your prompts change. Evaluations need to run continuously, more like monitoring than like a one-time selection step.
Build the evaluation harness early. The costly version of this is deploying first and then having no way to tell whether a later change helped or hurt. The eval set is what lets you move quickly and safely afterward.
Offline evaluation isn’t the whole picture. A test set catches regressions before deploy. Production monitoring - sampling real outputs, tracking user signals and watching for drift catches what the test set misses.
What I’d take away
Benchmarks tell you the league, not the winner. Use them to narrow the field, then decide with your own data.
Your evaluation set is among the most valuable things you’ll build. A few hundred real examples from your workload beats any public benchmark for your decision.
Verifiable answers score themselves; open-ended ones need a judge. LLM-as-judge plus human spot-checks is the workable 2026 pattern.
Evaluation is continuous infrastructure. Models drift, and the harness that catches it is what lets you keep changing things with confidence.
Next week we start a new chapter - inference. You’ve built or chosen a model; now you have to serve it to real users, fast and affordably, at scale, and it has a stack of techniques all its own.
If you want it in your inbox, subscribe.