Benchmark Correlation
A public leaderboard ranks models on a small subset of benchmarks, so its rank does not comprehensively evaluate a model or guarantee performance on your application.
The Shortcut of Picking the Top Model
Suppose you are building an application and you want a foundation model that handles your task well. A natural first step is to open a public leaderboard, find the model at the top, and start building on it. The shortcut is tempting, because it rests on a belief that seems reasonable: that a leaderboard rank summarizes how well a model will perform on your task. This article examines why that belief breaks down, and what the difficulties of choosing and combining benchmarks mean for anyone selecting a model.
The misconception to correct is this: a public leaderboard is a comprehensive evaluation of foundation models. It is easy to fall into this trap because a leaderboard presents a single ranking, and a single ranking looks authoritative. Leaderboards are genuinely useful, but they are far from complete, and the reasons for that are the subject of the sections that follow.
What do you think happens?
A leaderboard places one model at number one. Does that tell you how the model will perform on your specific application?
Reveal answer
No, the rank reflects only the small set of benchmarks the leaderboard runs.
A public leaderboard ranks models on a subset of benchmarks. That rank does not comprehensively evaluate a model and does not guarantee performance on your application, because your task may depend on capabilities the leaderboard never measures.
Why a Rank Covers Only Part of a Model
A public leaderboard ranks models by their aggregated performance on a subset of benchmarks. Each benchmark tests some particular capability, and the leaderboard combines the results into one position. The rank therefore only describes the capabilities that happen to be covered by the chosen benchmarks. Anything outside that set, including the kinds of tasks your application needs, is simply not reflected in the number.
Benchmark correlation describes how similar the performance of two benchmarks is across models. If two benchmarks tend to rise and fall together, they measure similar things. Understanding correlation is central to deciding which benchmarks a leaderboard should include and how much its rank can be trusted.
Compute Limits on Which Benchmarks Fit
The first reason leaderboards are incomplete is compute. Evaluating a model on a benchmark requires compute, so most leaderboards can include only a small number of benchmarks. That constraint forces a choice, and a leaderboard may leave out an important benchmark simply because it is expensive to run. HELM Lite, for example, left out an information retrieval benchmark called MS MARCO for this reason. Hugging Face chose not to include HumanEval because it has large compute requirements, since it needs a great many generated completions.
Leaderboard size has also grown only slowly. When Hugging Face first launched its Open LLM Leaderboard in 2023, it consisted of four benchmarks. By the end of that year it had been extended to six. Even the larger set is small compared with the range of things foundation models are asked to do, and a small set of benchmarks is not nearly enough to represent the broad capabilities and the different failure modes of these models.
Read the diagram from left to right. A leaderboard designer starts with many candidate tests. Each filter removes some of them: expensive tests drop out at the compute stage, and tests that duplicate what another test already measures drop out at the redundancy stage. The remaining tests are then checked for coverage, meaning whether together they span a range of capabilities. Only the tests that survive all of these steps appear on the leaderboard.
Why Different Leaderboards Use Different Benchmarks
The second problem is that different leaderboards do not share the same benchmarks. Stanford's HELM Leaderboard used ten benchmarks around the same time that Hugging Face ran its six. Only two of them, MMLU and GSM-8K, also appeared on the Hugging Face leaderboard. That overlap is small, and it makes the rankings hard to compare and interpret, because two models ranked against each other on one leaderboard were not tested on the same evidence as on the other.
| Leaderboard | Benchmarks used | Shared with the other leaderboard |
|---|---|---|
| Hugging Face Open LLM Leaderboard | Six benchmarks by end of 2023, including ARC-C, MMLU, WinoGrande, TruthfulQA, and GSM-8K | MMLU and GSM-8K |
| Stanford HELM Leaderboard | Ten benchmarks around the same time | MMLU and GSM-8K |
Overlap between two leaderboards queried around the same period
Leaderboard designers generally try to balance coverage against the number of benchmarks. They aim for a small set that spans a wide range of capabilities, such as reasoning, factual consistency, and domain-specific skills like math and science. At a high level this makes sense. The difficulty is that coverage is rarely defined precisely, and the public descriptions do not explain why a leaderboard stops at six benchmarks or at ten.
Specific choices raise questions that the public rationale does not fully answer. Why are medical and legal tasks included in HELM Lite but not general science? Why does HELM Lite include two math tests and no coding test? Why do both leaderboards lack tests for summarization, tool use, toxicity detection, or image search? These questions are not criticism. They show how hard it is to select benchmarks that rank models well, and if the developers cannot fully explain their selection, that may reflect a real difficulty of the problem rather than carelessness.
Reading a Benchmark Correlation Table
Correlation is the tool for deciding whether two benchmarks are worth including together. The correlation values discussed here are Pearson correlations among the six benchmarks on the Hugging Face leaderboard, computed in January 2024. A value near 1.0 means two benchmarks are strongly related. Each benchmark has a correlation of exactly 1.0 with itself, which is why the diagonal of such a table is always 1.0. The values off the diagonal are the ones to read.
Reading the table this way shows a clear pattern. ARC-C, MMLU, and WinoGrande are strongly correlated with one another, with values between about 0.87 and 0.90. That fits the fact that all three test reasoning capabilities. TruthfulQA, by contrast, is only moderately correlated with the others, with values around 0.45 to 0.55. The reading offered for this pattern is that improving a model's reasoning and math capabilities does not always improve its truthfulness. Benchmarks that look different on the surface can therefore carry very different information.
What does this mean for selection? Among ARC-C, MMLU, and WinoGrande, the three benchmarks largely repeat the same signal. Including all three adds less than it appears to, and the shared reasoning tendency is counted several times over. Because perfectly correlated benchmarks add nothing when both are included, and strongly correlated ones can exaggerate a bias by counting the same tendency twice, a designer should prefer a benchmark from the moderately correlated group when it adds a different kind of evidence, such as TruthfulQA does here.
Averaging Scores Into One Rank
Once benchmarks are chosen, their results must be combined into a ranking. This combining step is called aggregation. As of the time of the source, Hugging Face averaged a model's scores on all its benchmarks to produce the final score used for ranking. Each benchmark contributes its score, the scores are summed, and the total is divided by the number of benchmarks, so that one number stands for the whole set.
The before-and-after view shows what the aggregate hides. The two separate results are still there, each with its own meaning, but after averaging only the combined number is visible. If one of the benchmarks is far harder to score well on, the average still treats its result as one equal share, and the individual results that drove the ordering are no longer shown.
Mistakes Beginners Make With Leaderboards
Common mistake Treating the top rank as a complete evaluation of the model
What it looks likeChoosing the number one model without checking any benchmark that resembles your task.
Why it failsA leaderboard ranks models on a small subset of benchmarks, so it does not evaluate every capability the model has.
Do this insteadLook at the individual benchmark results and check whether the benchmarks measure what your application needs.
Common mistake Assuming two leaderboards can be compared directly
What it looks likeComparing a model's place on one leaderboard with its place on another as if both used the same tests.
Why it failsDifferent leaderboards often choose different benchmarks, and the overlap can be very small, as with HELM and Hugging Face sharing only two benchmarks.
Do this insteadCheck which benchmarks each leaderboard actually runs before comparing rankings.
Common mistake Counting strongly correlated benchmarks as independent evidence
What it looks likeBelieving that ARC-C, MMLU, and WinoGrande together give three separate views of quality.
Why it failsThese benchmarks are strongly correlated, so they largely repeat the same signal and can exaggerate the same reasoning tendency.
Do this insteadPrefer benchmarks that add a different kind of evidence, such as a moderately correlated one.
Common mistake Assuming equal weights match what matters to you
What it looks likeTrusting an average in which an 80% on TruthfulQA counts the same as an 80% on GSM-8K when truthfulness is your priority.
Why it failsAveraging gives every benchmark the same weight, which may not reflect the importance of each capability for your task.
Do this insteadLook at the separate scores and weight them according to your own needs.
Practice Choosing From a Benchmark Set
A leaderboard runs four benchmarks. Benchmark W and benchmark X are strongly correlated with each other, with values around 0.9. Benchmark Y is only moderately correlated with both, around 0.5. Benchmark Z is expensive to run and is strongly correlated with W. If the designer must keep only three benchmarks, which should be kept, which should be dropped, and why?
Hints
- Start by asking which benchmark adds information the others do not provide.
- Strongly correlated benchmarks repeat each other, so consider dropping one of a redundant pair.
- Compute cost is a real constraint, so an expensive benchmark that repeats another is a strong candidate to drop.
Key Takeaways
- A public leaderboard ranks models on a small subset of benchmarks, so its rank is not a comprehensive evaluation and does not guarantee performance on your application.
- Compute costs and coverage goals limit which benchmarks a leaderboard can include, and different leaderboards often choose different benchmarks, which makes their rankings hard to compare.
- Benchmark correlation shows which benchmarks move together across models. Perfectly correlated benchmarks add nothing when both are included, and strongly correlated ones can exaggerate biases.
- Averaging combines benchmark scores into one number by treating every benchmark equally, which can misrepresent how hard each result is to achieve and how much each capability matters for your task.