From Benchmark Scores to General Intelligence: How to Assess Model Capability Leaps

Why a Single Aggregate Score Cannot Tell the Whole Story

When evaluating a new generation of AI models, aggregate benchmark scores tend to attract the most attention: a single number is easy to compare and convenient for summarizing a model’s overall performance across a set of tasks. But if different models have similar composite scores—or if an older model scores slightly higher than a newer one—this does not necessarily mean the newer model has not improved. The key questions are: what does the composite score actually measure, which tasks contribute to it, and does it cover the capabilities users genuinely care about?

Composite scores typically aggregate results from multiple task categories into a single metric. If the test set emphasizes knowledge Q&A, mathematical reasoning, or text comprehension, a model’s gains on those tasks may be limited; meanwhile, it may still show substantial changes in tool invocation, multi-step planning, working with codebases, or sustained completion of complex tasks. Conversely, if a new model achieves high scores only on a few specific tests, that alone does not justify inferring a broad improvement in overall capability.

Therefore, when confronting a “total score” in model release information, the more reasonable approach is not to draw immediate conclusions but to keep asking: Which tasks does the score include? How are task weights assigned? Is there training data leakage in the tests? Were results obtained from multiple runs? Were different models tested under the same prompts, tools, and compute budgets? These conditions directly affect the credibility of any conclusion.

What Disaggregated Metrics Reveal About Capability Changes

The relevant materials list several different types of evaluation results: automation task scores rising from 18.1% to 41.4%, science task scores rising from 22.4% to 64.6%, along with claims of a safety test reaching 100% and a specific abstract reasoning test reaching 99.9%. Because complete test descriptions, evaluation protocols, and independent verification information are lacking, these figures should be treated as reported results awaiting verification rather than established universal conclusions. In particular, percentages may represent accuracy, task completion rate, pass rate, or other metrics, and cannot be directly compared across categories without their definitions.

Nevertheless, such disaggregated data still highlights an important point: model capability is not a single dimension. Automation tasks emphasize breaking goals into multiple steps and correcting actions based on feedback along the way; science tasks may require combined reading, reasoning, computation, and evidence organization; safety tests focus on whether a model adheres to constraints when facing specific risk requests; and abstract reasoning tests typically assess a model’s ability to induce rules from limited examples and transfer them to new applications. These measure different capabilities, and their results cannot simply be summed into an “intelligence level.”

If automation task scores improve significantly, it is worth examining further whether the model can actually complete long-chain work reliably, rather than succeeding only under fixed templates. For example, a task might require a model to read materials, organize data, generate a plan, invoke external tools, and check the final result. If any single step fails, the entire task may fail to deliver. In evaluation, beyond counting final success rates, one should also record intermediate step error types, the number of human interventions, retry costs, and task completion time.

High Scores Do Not Equal General Intelligence

There is no industry-wide accepted threshold that can be directly determined by a single score for “artificial general intelligence.” What is commonly called generality involves at least several aspects: whether a model can handle a broad range of tasks, whether it can transfer existing knowledge to unfamiliar problems, whether it can plan reasonably when information is incomplete, whether it can recognize its own uncertainty, and whether it can maintain goal consistency and correct errors over longer time spans.

A model approaching a perfect score on one test may indicate that it adapts well to the question types covered by that test, but it cannot prove that the model is equally reliable in unseen domains, open environments, or real business processes. Test set size, difficulty distribution, scoring methods, and the possibility of the model having encountered test samples all affect how high scores should be interpreted. If task formats are relatively fixed, a model may also achieve good results by recognizing familiar patterns while degrading when conditions change slightly.

Safety evaluations also require cautious interpretation. Passing all tests in a particular set only shows that the model met established requirements under that test set and corresponding rules; it does not mean all risks have been resolved. In real usage environments, input forms, context length, user intent, and tool permissions all shift the risk boundary. Safety evaluation should cover different attack methods, context variations, and multi-turn interactions, and should report failure cases rather than showing only an aggregate percentage.

Building a More Reliable Model Evaluation Framework

For R&D teams and enterprise users, the following aspects can help establish an evaluation process when comparing models.

1. Define Tasks and Success Criteria Clearly

First, translate “strong capability” into specific business objectives. For example, code review focuses on defect identification rate, false positive rate, and usability of fix suggestions; knowledge retrieval focuses on answer accuracy, citation traceability, and handling of missing information; process automation focuses on end-to-end completion rate, frequency of human takeover, and exception recovery capability. Without clear success criteria, benchmark scores are difficult to translate into procurement or deployment decisions.

2. Report Both Overall and Disaggregated Results

Overall scores are suitable for a quick overview, while disaggregated results help locate capability boundaries. It is advisable to break down statistics at least by task type, difficulty, input form, and error severity, and to specify sample sizes and scoring rules. For automation tasks, single-step accuracy and full-process success rate should be recorded separately to avoid local advantages masking end-to-end failures.

3. Conduct Repeated Testing and Independent Verification

Generative model outputs may vary due to prompt phrasing, randomness, and runtime conditions. For important conclusions, tests should be repeated under fixed conditions and the range of variation reported, rather than presenting only a single best result. Test sets should also be isolated from the model development process as much as possible and updated regularly to reduce bias from data contamination and overfitting.

4. Incorporate Cost, Latency, and Stability into Evaluation

Model capability is not the only decision factor. Practical applications must also consider response time, inference cost, concurrency capacity, long-task stability, and failure recovery. A model that performs better on difficult tests may not be suitable for all production scenarios if its cost is too high or its output fluctuates noticeably. Conversely, a smaller capability gain that significantly reduces manual review workload may have higher business value.

5. Run Controlled Pilots in Real Workflows

Offline testing helps screen candidate solutions but cannot fully simulate real user input and business constraints. Before deployment, pilots should be conducted in scoped, risk-controlled scenarios with human review and rollback mechanisms in place, continuously collecting error types, user feedback, and resource consumption. Only when a model’s benefits in real workflows are stable and risks are manageable do benchmark results carry strong practical significance.

Conclusion: Focus on Capability Evidence, Not Labels

Flat composite scores and improved disaggregated capabilities are not contradictory; they may reflect changes in a model across different task dimensions. Automation, scientific reasoning, safety response, and abstract transfer all deserve separate evaluation, but no single high score is sufficient on its own to prove that a model has achieved general intelligence. More rigorous judgment requires complete testing protocols, reproducible results, real-world validation, and comprehensive consideration of cost and risk.

For readers, the most valuable question is not “Is it already artificial general intelligence?” but “On which tasks is it reliable, under what conditions does it fail, how much supervision does it require, and can it create verifiable value in the target workflow?” Answering these questions clearly is far more practical than making judgments based on a striking total score or a promotional label.