An AI that aces short-answer tests can still fall apart when you hand it a multi-step task.

This question reframes benchmarking as a deployment-fit problem rather than a leaderboard one: the corpus suggests there is no single "good score," only scores that happen to match how you'll use the model. The clearest split is interaction length. Short-interaction benchmarks simply don't predict long-horizon delegated performance — DELEGATE-52 found models that looked identical on single-turn tasks diverged sharply by relay 25, with degradation curves invisible to standard tests Do short benchmarks predict how models perform over long workflows?. So if you're deploying a chatbot for quick answers, single-turn scores matter; if you're handing off a multi-step workflow, they actively mislead you.

The deeper move is to stop treating capability as a scalar at all. One note argues capability is a vector across at least five separable axes — task success, privacy compliance, long-horizon retention, mode-shift behavior, ecosystem readiness — and that models topping one axis often rank low on another, so a single score is systematically misleading for real deployment Does a single benchmark score actually predict agent readiness?. Which component of that vector matters is exactly what your deployment context picks out. Agent evaluation work pushes the same point: one-shot task success hides trajectory quality, memory hygiene, context efficiency, and verification cost — the things that actually govern whether an agent survives in production Should agent evaluation measure more than task success?.

Deployment context also shapes which benchmark mode matters along axes you might not expect. Domain flips the sign of effects: preference tuning reduces lexical diversity in code generation but increases it in creative writing, because code rewards converging on one correct answer while creative work rewards distinctiveness Does preference tuning always reduce diversity the same way?. A diversity benchmark that looks like a warning sign for a writing assistant might be a feature for a coding tool. Similarly, how much you cram into a prompt matters: instruction-following degrades predictably with density, and reasoning models hold ~150 instructions before failing steeply — so a high-density deployment needs a density-stress benchmark, not a clean single-instruction one How does instruction density affect model performance?.

There's a subtler trap the corpus flags: even when you measure the right thing, the score can be measuring two different phenomena at once. RLVR work shows genuine reasoning activation and benchmark improvement are separable — gains can reflect real new behavior or just memorization on contaminated datasets, and both can coexist Can genuine reasoning activation coexist with contaminated benchmarks?. And switching to richer interactive evaluation doesn't rescue you automatically: the old problems of comparability and reproducibility just reappear at the trajectory level rather than disappearing Do interactive evaluations actually solve the benchmark comparison problem?. The fix is shared protocols, not new formats.

The thread tying these together — and the thing worth taking away — is that benchmarks aren't just imperfect measurements of one underlying quality; different deployment contexts surface genuinely different qualities. If you can compensate with inference-time compute (smaller models matching larger ones on hard prompts Can inference compute replace scaling up model size?), then raw model-size benchmarks matter less and your compute budget matters more. Choosing a benchmark is really choosing a hypothesis about how the model will be used — and getting that hypothesis wrong is how good scores produce bad deployments.