Live data from Hacker News

When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

arxiv.org

61–70 of 139 posts

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#61
As a PC gamer who grew up in the 00s, this has been something I’ve tried to warn ardent LLM and model enthusiasts about for quite some time.

Benchmarks are handy when they’re new, novel, and constantly changing. The second you let even a single aspect of it stagnate, it becomes a gameable score rather than a useful metric. In PC Gaming, we saw vendors optimize for specific titles, benchmark tools, and scenarios at the expense of general performance, and eventually the industry had a “come to Jesus” moment where we had to collectively decide how to move forward from an industry built on thoroughly gamed benchmarks, with entities like Gamers’ Nexus and Digital Foundry being the end results of that falling out.

LLMs were always going to end up the same way, because the people building the benchmarks - well-intentioned as they were - ultimately fell into the exact same traps with fixed scoring rubrics, known test questions, and believing in some form of “completeness” that could be attained or achieved. The net result are models consistently scoring better on benchmarks but also seeing diminishing returns and rising vulnerabilities, because actual improvement or utility isn’t what they’re being optimized for so much as bragging rights. It’s why there’s so much growing interest in things like MoE execution on unified memory platforms as a means of porting larger models to consumer kit, or ternary models (shoutout to Bonsai) as a means of reducing overall size: both take leading edge, benchmark-saturating models and show that with minimal score loss, they function about as well as frontier models might.

Building a new benchmark won’t solve the problem, either. To move forward, we must evaluate LLMs objectively and with continuously evolving workloads. More “pelican on a bicycle” stuff, but from varying perspectives and use cases. Radiologists putting models through their paces with usable sample data they don’t share with AI labs, or IT folks tasking agents with bootstrapping specific, real-world workloads. To prove general intelligence, we need more specialists evaluating them specifically and generally in ways that are transparent to consumers but difficult or impossible for AI companies to prepare against.

Only then will scoring values matter.

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#62

As a PC gamer who grew up in the 00s, this has been something I’ve tried to warn ardent LLM and model enthusiasts about for quite some time. Benchmarks are handy when they’re new, novel, and constantly changing. The second you let even a single aspect of it stagnate, it becomes a gameable score rather than a useful metric. In PC Gaming, we saw vendors optimize for specific titles, benchmark tools, and scenarios at th…

> Building a new benchmark won’t solve the problem, either.

It will if the benchmark is proprietary. If you can't train on it, then it's extremely difficult to game, and if it's hard enough, then it's economically more efficient to just...make the model smarter

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#63

Earlier quoted context omitted.

If you know all this, can you explain how these models produce advanced mathematical proofs? (as recently done by OpenAI, for example) I tried to generate the next word to the best of my ability, starting with a mathematical problem, but I did not create a valid proof. How do these LLMs work when they create math proofs to problems not yet solved?

Yes, it turns out that matrix math over a feature space of math works pretty well because unlike poetry or real world work, maths are internally coherent and entirely theoretical.

This not understanding "understanding".

> maths are internally coherent and entirely theoretical

Nope. This kind of wish-washy thinking is not what we mean by understanding.

https://iep.utm.edu/math-inc/

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#64

This seems to be the end of the road for LLM's. There's only so much accuracy on a highly non-linear space you can get from a regression. If the Pareto rule is any indicator, 80% of results come from 20% of causes. It seems that we have alot more to learn about intelligence. I am reminded of a statement on truth from an ancient philosopher, this sentiment seems to be exactly the opposite of the LLM training paradigm…

Idk about end of the road, I’m sure they can squeeze out some more performance by curating even more data and doing even more RL. But I would bet that pretty much all of the improvement we’ve seen over the last year with coding has come from RL, not from the models becoming particularly stronger. And this makes sense, if models grow sublinearly with compute. And it seems like they do.

It seems pretty obvious from the steep 'intelligence' drop-off on out-of-distribution tasks that the performance improvement is from throwing untold tens of billions at RL. There are legions of highly skilled people employed solely to feed the RL loop. Evidently effective, but there's an unmistakable feeling this won't ultimately be the way forward.

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#65

This seems to be the end of the road for LLM's. There's only so much accuracy on a highly non-linear space you can get from a regression. If the Pareto rule is any indicator, 80% of results come from 20% of causes. It seems that we have alot more to learn about intelligence. I am reminded of a statement on truth from an ancient philosopher, this sentiment seems to be exactly the opposite of the LLM training paradigm…

>This seems to be the end of the road for LLM's. There's only so much accuracy on a highly non-linear space you can get from a regression. It's just inadequate benchmarks. Anyone who has used Fable for anything particularly difficult will have seen that it's miles ahead of Opus 5.0, yet the majority of benchmarks are completely unable to capture this.

The two times I tried to use fable I had it attempt something I had already had Opus 4.6 do with no issues. It blasted through 10% of my weekly allowance on a 100$ a month sub and produced something broken and nonsensical.

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#66

I started thinking about this back after the Llama 4 release, and since then our team has put a lot of thought into designing evaluations that don't saturate, are resistant to contamination, and can scale. What has worked best for us is using multi-agent environments with open-ended cooperative or competitive goals. Mostly designed as multiplayer games. The results tend to align with our experience for coding better…

You post your benchmark on every other AI article, I've seen you do this by now more than a dozen times. It's a bit much. I don't want to be too harsh but your benchmark is obviously flawed when the top 3 models for Typescript (Combined) are Grok 4.5, Muse Spark 1.1 (lol), Gemini 3.5! Flash and then followed by Luna, beating Opus 5, Fable, 5.6 Sol etc by quite some margin. In fact 5.6 Sol ranks lower than Kimi K2.7 Code and even Grok Build 0.1. There are so many entries in your rankings that don't make any sense whatsoever that I can't take this benchmark serious and I have not seen it gaining traction. Please stop spamming it?

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#67

This seems to be the end of the road for LLM's. There's only so much accuracy on a highly non-linear space you can get from a regression. If the Pareto rule is any indicator, 80% of results come from 20% of causes. It seems that we have alot more to learn about intelligence. I am reminded of a statement on truth from an ancient philosopher, this sentiment seems to be exactly the opposite of the LLM training paradigm…

Assuming you are completely correct about the 80/20 rule, we have evidently not yet reached that 80%. Who can say when it will be achieved? The ceiling is glass, we have to touch it to know where it is.

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#68
post #67

This seems to be the end of the road for LLM's. There's only so much accuracy on a highly non-linear space you can get from a regression. If the Pareto rule is any indicator, 80% of results come from 20% of causes. It seems that we have alot more to learn about intelligence. I am reminded of a statement on truth from an ancient philosopher, this sentiment seems to be exactly the opposite of the LLM training paradigm…

Assuming you are completely correct about the 80/20 rule, we have evidently not yet reached that 80%. Who can say when it will be achieved? The ceiling is glass, we have to touch it to know where it is.

[dead]

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#69
post #47

Earlier quoted context omitted.

Weird moment for this take. We're seeing some of the fastest and most impressive progress ever right now. Frontier labs have categorically different & better set ups for evaluation, they're fine. It's work but it's not a crisis.

I've heard that every week of every month for the past three years. And yet, ask an LLM about a seahorse emoji and see what happens.

The seahorse emoji thing appears to be fixed actually. (Sonnet 5)

Re: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation

#70
post #66

I started thinking about this back after the Llama 4 release, and since then our team has put a lot of thought into designing evaluations that don't saturate, are resistant to contamination, and can scale. What has worked best for us is using multi-agent environments with open-ended cooperative or competitive goals. Mostly designed as multiplayer games. The results tend to align with our experience for coding better…

You post your benchmark on every other AI article, I've seen you do this by now more than a dozen times. It's a bit much. I don't want to be too harsh but your benchmark is obviously flawed when the top 3 models for Typescript (Combined) are Grok 4.5, Muse Spark 1.1 (lol), Gemini 3.5! Flash and then followed by Luna, beating Opus 5, Fable, 5.6 Sol etc by quite some margin. In fact 5.6 Sol ranks lower than Kimi K2.7 C…

The reality is that cost is the primary constraint for the public benchmark we provide. While we run enough samples to get results that are generally quite accurate on average, we only produce ~10 coding submissions per language for each model and those are across random environments, which naturally has noise. Plus that's split between agentic coding sessions and one-shot coding.

So just adding a language or tag filter can result in some pretty small sample sizes. You can see how many samples survived in the box plot, but that's probably bad UX that most people never see. There's a reason no other benchmark provides this type of data (even for our sample sizes it runs almost 10K USD/month to keep up to date with new releases).

Might be a good idea to reduce the ability to apply filters into a cohort with less than ~20 samples -- not the first time we've gotten that feedback. Seems like adding too many options to see individual sample variation is just misdirecting. I'm a nerd who loves data so I hate removing access, especially since the aggregate performance is very interesting (averaged across all languages, we see consistent and interesting performance data across models, like models outperforming with strongly typed languages). But tbh I think you're right and we'll try limiting filters to where we actually have statistically significant data.

Post reply on HN