What Makes a 'Good Benchmark'? An arXiv Paper Distills Five Design Principles
An arXiv paper argues good evaluation tasks share five traits: correct, solvable, verifiable, well-specified, and 'hard for interesting reasons'. The best tasks describe a real problem an experienced practitioner would recognize, in a practitioner's language, with tests that verify the outcome rather than the approach.
Bottom line
The stronger models get, the more evaluation matters—but benchmark-gaming and distortion also worsen. This arXiv paper returns to basics, distilling five design principles for 'good evaluation tasks'.
The five principles
- Correct: the task itself has no errors—prompt, gold answer, and judging logic all hold up.
- Solvable: the task can be solved, not an unsolvable or self-contradictory pseudo-problem.
- Verifiable: the result can be objectively verified, not left to subjective scoring.
- Well-specified: the task is clear and unambiguous, leaving no room for loophole-gaming or misreading.
- Hard for interesting reasons: difficulty comes from the problem's depth, not vague wording, dirty data, or rote volume.
A key judgment: verify the outcome, not the approach
The paper stresses the best tasks verify the 'outcome' rather than the 'approach'.
- If a benchmark only accepts one 'standard solution', it penalizes equally-correct different paths and is easy to overfit.
- Verifying only 'is the result right' is closer to the real world—no one dictates which method you must use, as long as the problem is truly solved.
An implicit standard: resemble a real problem
The paper notes the best tasks describe a real problem an experienced practitioner would recognize, in the language a practitioner would use. In other words:
- A good benchmark isn't a contrived puzzle but something a real expert nods at: 'yes, this is the kind of problem I meet in my work'.
Why it matters for anyone using models
- Model selection: if the leaderboard you rely on is flawed (unverifiable, vague, gameable), conclusions about 'who's stronger' aren't trustworthy.
- Building your own eval: many teams build private benchmarks for their scenarios. These five principles are a checklist against self-deception.
- Against gaming: 'verify outcome not approach' and 'hard for interesting reasons' fight overfitting and score-gaming—deciding whether a benchmark truly distinguishes model ability.
In an era where everyone ships and games leaderboards, returning to 'what is a good task' is worth more than one more benchmark.