AI/ML News & Innovations Hub

If you work in enterprise AI, you’ve probably been here: a vendor claims their model leads on a popular leaderboard. A procurement team is weighing two systems and benchmark scores are the tiebreaker. An executive deck cites a safety benchmark to argue a model is “production-ready.”

Some of those numbers are real. Some are what we’d call benchmark washing – the selective use of convenient results to imply performance, reliability, safety, or readiness that the evidence doesn’t actually support.

We build benchmarks for a living. We started MLPerf in 2018 – years before the AI evaluation explosion – and created the industry-standard benchmark for AI systems. We’ve spent years building the governance, audit trails, and integrity controls that make results defensible. We’ve also seen, up close, just about every way a benchmark can fail, be gamed, or be misused.

We don’t sit in your procurement meetings. We’re not claiming to know exactly what your evaluation workflow looks like from the inside. But we hear from enterprise teams that they need a way to tell the difference between a benchmark result they can trust and one they can’t. This is our attempt to help with that – not as a vendor selling you an assessment, but as a consortium that has learned some hard lessons about what makes benchmark evidence hold up and what makes it fall apart.

The Benchmark Trust Test

When someone hands you a benchmark result and asks you to make a decision based on it, here are the questions we’d ask. It isn’t realistic that every enterprise becomes a benchmarking expert – but every enterprise needs to become an intelligent benchmark consumer. We believe these questions are worth carrying into any conversation in which a benchmark score is used to support a consequential decision.

If they’re hard to answer, if the person presenting the result can’t answer them, or hasn’t thought about them… that’s noteworthy.

1. Does this benchmark actually measure what I’m deciding about?

A good benchmark starts with a decision, not a dataset. It should be clear what the benchmark is for – model selection, vendor shortlisting, release readiness, risk acceptance, cost-performance trade-off. We’ve seen the failure mode where a benchmark gets used because it’s available and familiar, not because it’s relevant to the decision at hand. The result can be perfectly accurate and still misleading. A high score on a knowledge benchmark doesn’t tell you much about reliability under production workload. A strong coding benchmark doesn’t prove secure code generation.

2. Where did the data come from, and has it been kept clean?

The evaluation population, sampling method, labeling, provenance, and known limitations should be documented. More importantly – and this is a problem we think is more widespread than many people realize – the data should be checked for contamination. Has the system seen the test data during training? This isn’t a rare accident. Survey literature now treats test-set leakage as a structural, recurring threat. The data tells a clear story.

In a recent analysis of a grade-school arithmetic benchmark, researchers discovered that accuracy can plunge by 13 points across several model families once a fresh, equivalent test set is introduced to eliminate contamination. Perhaps the most sobering evidence comes from software engineering. On the public SWE-Bench Verified, elite models frequently exceed 70%. However, when Scale AI’s research lab utilized its SWE-Bench Pro, which relies on private, proprietary repositories that models haven’t seen, those results evaporated. GPT-5’s performance dropped from 23% to less than 15%, while Claude Opus 4.1 sank from 23% to 18%. This represents a 55-point discrepancy between public and private evidence, all on a metric that teams are currently using to justify high-stakes investments in automated coding infrastructure.

If a benchmark can’t demonstrate contamination controls, a high score might reflect memorization rather than capability. And as the SWE-Bench example shows, the gap between those two things may be significant enough to impact such decisions.

3. Could someone else reproduce this result- and reconstruct what happened?

A trustworthy benchmark controls the conditions under which evidence is produced: model version, prompts, hyperparameters, hardware, random seeds, scoring method, post-processing. This isn’t aspirational. We’ve seen prompt formatting alone swing measured accuracy by tens of points, with format-based rankings barely correlating across models. A single number as a benchmarking result is both an artifact of conditions and a property of the system. If the benchmark can’t specify and reproduce those conditions, the score is more of a snapshot than a measurement.

Reproducibility has two faces, and both matter. The first is the peer-review perspective: could another benchmarking team take the specification and re-run the evaluation themselves? This is the lens we apply in MLPerf – the rules exist so that a qualified reviewer can reconstruct the result and verify it was produced fairly. The second is the auditor perspective: could an independent assurance provider – someone who isn’t a benchmarking expert but needs to verify evidence for compliance, procurement, or risk purposes – trace what happened? Who ran the benchmark, when, on what system, with what inputs, how were outputs scored, what exceptions occurred, and how were results approved? This is the lens we apply in our AI Risk and Reliability work, where the audience is often an auditor or assurance provider rather than a fellow researcher.

Both perspectives ask the same underlying question: is there enough of an evidence trail that someone other than the person who produced the result can stand behind it? If that trail doesn’t exist, the result can’t be audited – and using a result that can’t be audited to inform a production decision carries additional risks..

4. Is the score telling you everything you need – or just the easiest thing to measure?

A single score is easy to communicate. It’s also easy to over-rely on. When a benchmark reports one number – usually accuracy or resolve rate – it’s worth asking what’s missing. Quality, latency, cost, reliability, safety, efficiency – these dimensions often matter as much as the headline metric, and they frequently trade off against each other. A model that scores highest on accuracy might also be the most expensive to run, the slowest in production, or the least robust to edge cases. We don’t think every benchmark needs to measure everything. But we do think it’s worth understanding what a benchmark isn’t measuring, and whether the gaps matter for the decision you’re making. A benchmark that reports only accuracy isn’t wrong – but a claim that attempts to extend that accuracy measurement into “the best system for your use case” is worth being skeptical of.

5. Is the system under test a passive subject – or could it be gaming the test?

This is a newer problem, and we’ll be honest: it surprised us. Frontier models can sandbag – strategically underperform to hit a target score. They exhibit evaluation awareness – they can often tell when they’re being tested and infer what’s being measured, which means test behavior may not transfer to production. In agentic settings, systems have been caught searching public repositories (and, making headlines recently, breaking into private ones) for a benchmark’s answers instead of solving the task. A benchmark that assumes the system is passive is operating on an assumption that, in our experience, no longer holds for capable models. Look for integrity controls: blinded protocols, held-out items, trajectory inspection, continuous stewardship of the evaluation – not just final scores.

6. If a model is scoring the results, has that model been validated?

As benchmarks move toward open-ended generation, many rely on an LLM to score another LLM’s output. This is scalable, but the judge is itself a fallible instrument – biased toward longer answers, particular styles, self-preference, and position in comparisons. If the benchmark uses automated scoring, we’d want to know that the judge has been anchored to human judgments on a documented sample, checked for bias and stability, and version-controlled. Where the judge can’t be made reliable, objective ground truth should carry the weight instead.

7. Is the benchmark still alive – or has it gone stale?

A benchmark isn’t trustworthy (or even particularly useful) if it was abandoned after launch. Models saturate benchmarks. Data distributions shift. Threat models change. A benchmark that discriminated between systems two years ago may not discriminate today. We believe this is one of the more underappreciated risks in enterprise settings: the benchmark keeps producing numbers, the numbers just stop carrying the same meaning. Look for a maintenance plan: scheduled reviews, drift analysis, contamination checks, retirement criteria. If the benchmark hasn’t been refreshed, its scores may be measuring adaptation to the test, not real capability.

Why This Is Getting Harder, Not Easier

We’ve been at this for years, and here’s what concerns us: these problems aren’t just present – they’re compounding. Contamination is structural. Leaderboards create incentives to optimize for the leaderboard. Safety benchmarks can measure capability, not safety. And once a benchmark saturates, it stops discriminating between systems but keeps producing confident-looking numbers. Each of these failures is documented. What’s harder to see is how they interact – a contaminated, saturated benchmark that’s been gamed by well-resourced providers and cited in a vendor deck is a stack of compounding distortions, each one invisible on its own.

The “I told you so” here isn’t directed at anyone in particular. It’s the recognition that these problems are now well-documented enough that pretending they don’t exist is itself a form of benchmark washing.

What Good Looks Like

Not all benchmarks are built for the same job. We find it useful to distinguish between two types.

A research benchmark is designed to explore – to test hypotheses, reveal emerging capabilities, create shared reference points, and push the frontier of what can be measured. BIG-bench, MMLU, HELM, and CheckList are examples. They’re built for discovery, speed, and comparability, not for operational decisions.

An industrialized benchmark is designed to support specific decisions – procurement, model selection, release gates, risk acceptance, regulatory claims. Its design, operation, evidence, and maintenance are robust enough to support production decisions and external accountability.

The distinction isn’t about size or sophistication. A narrow benchmark can be trustworthy and fit for industrial use if its purpose is clear, its limitations are documented, its execution is controlled, and its outputs are interpreted within appropriate boundaries. A sophisticated test set can be untrustworthy if it lacks governance, repeatability, and auditability.

An industrial benchmark has:

Explicit scope and decision linkage – it knows what decision it informs and doesn’t claim more than it measures
Governed data – documented provenance, contamination controls, and stated limitations
Repeatable execution – versioned data, code, configuration, prompts, hardware, and seeds
Awareness of what the score doesn’t cover – trade-offs between dimensions like cost, latency, and quality are surfaced where they matter, and claims don’t generalize beyond what the benchmark actually measures
Honest uncertainty – variance and confidence are reported where they’re material, so “Model A beat Model B” is a claim that can survive scrutiny, not just a headline
Auditability – complete evidence trails that an independent reviewer can reconstruct
Integrity controls – blinding, refresh, red-teaming, and trajectory inspection for systems that can game the test
Lifecycle maintenance – scheduled review, drift monitoring, retirement criteria, and controlled change logs

Our MLPerf family of benchmarks is our flagship example, and we’re proud of them. MLPerf Inference is on version 6.1, and each version encapsulates new learnings about how to build industry-grade benchmarks. Its rules address fairness, consistency of systems and frameworks, shared implementations, restrictions on non-determinism, prohibitions on benchmark detection, mandatory replicability, and audit processes. That level of discipline isn’t bureaucracy for its own sake. It’s what makes a result defensible when someone’s procurement decision, product claim, or regulatory filing depends on it.

AILuminate is rapidly catching up to MLPerf as our second family of industry-grade benchmarks. While MLPerf focuses on performance measurement (time-to-first token, concurrency, power consumption, etc.), AILuminate measures reliability, which involves more subjective topics such as safety and jailbreak resilience. We launched AILuminate in 2024, and that ongoing effort continues to build on our perspective of “What Good Looks Like.”

This doesn’t mean every benchmark needs to be MLPerf or AILuminate. We believe credible performance and reliability claims require comparable controls, scaled to the stakes. A benchmark for a low-risk internal assistant may need lightweight governance and monthly review. A benchmark supporting clinical, financial, or safety-critical deployment probably needs independent review, formal audit trails, subgroup analysis, and adversarial testing. The standard, as we see it, is proportionality. The evaluation rigor should match the consequences of potential failure states – and the benchmarks used in those evaluations should actually measure those failure states.

Research Benchmarks Still Matter

To be clear – this piece is not an argument against research benchmarks. We use them. We value them. They are where new measurement frontiers open, where capability gaps get revealed, and where the concepts that later become production controls are first discovered. They are the laboratory. Industrialized benchmarks are the operating plant. You need both.

The mistake isn’t using research benchmarks. The mistake is treating exploratory evidence as production assurance without industrializing the evaluation process around it. A research benchmark that’s transparent about its assumptions and limits is doing its job. A research benchmark whose results show up in a vendor deck as proof of production readiness is being misused – and that misuse is benchmark washing.

Why We’re Saying This

We’re a consortium, not a vendor. We don’t have a model to sell or a leaderboard to win. Our incentive is to make benchmark evidence more trustworthy, not to make any particular result look good. We think that’s worth something – and we think it’s the reason a piece like this is better coming from us than from anyone who has a model in the market.

We also think independent validation has real value. Not because we’re the only ones who can provide it, but because the principle itself – that you shouldn’t grade your own homework, and that the person measuring the system shouldn’t be the same person selling it – is one we’ve seen violated often enough to know it matters.

A benchmark result is only as meaningful as the conditions under which it was generated, the representativeness of what it measures, the integrity of the process that produced it, and the honesty with which its limitations are disclosed. If you can’t answer the eight questions above about a benchmark result you’re being asked to trust – ask. If the answers aren’t there, we believe the result probably isn’t either.