Evaluating New-Generation LLM Claims: Separating Real Capability from Marketing

Every time a flagship large model is released, the public reaction splits into two camps: one declares that a qualitative breakthrough has arrived, while the other digs through the evaluation details to find flaws. For engineering teams, neither emotional celebration nor wholesale suspicion is useful. What matters is converting launch-day messaging into verifiable technical facts, then deciding whether, when, and how to bring the new model into production environments. This article does not target any specific product; instead, it abstracts the typical controversies from recent release cycles into three general questions: Has agentic capability undergone a generational leap? How should we judge the real value of benchmark scores? And what easily overlooked signals have emerged around safety and alignment?

1. From “Advisor” to “Executor”: Agentic Capability Is the Real Dividing Line

1.1 The boundary between conversational models and agentic models

The output loop of a conversational model stops at the text layer: writing code, drafting documents, proposing solutions. It is essentially an “advisor,” and final execution still depends on humans. An agent is different. It receives a goal rather than a question and must autonomously close the task loop: decompose sub-tasks → invoke tools → operate the environment → handle exceptions → deliver results, with real side effects along the way (placing orders, sending messages, modifying files).

A typical scenario such as “help me sell a used piece of furniture” requires the system to break down photography, copywriting, pricing, listing, responding to inquiries, and negotiating delivery, while accepting dynamically inserted new constraints mid-task (adding defect descriptions, adjusting the price floor). This tests the combination of long-horizon planning, context management, and goal re-planning; if any one of these is missing, the task breaks down.

1.2 What to look for when evaluating agents

• End-to-end task success rate: not single-turn answer accuracy, but whether the final deliverable meets the bar;
• Human intervention rate: the number of times a human must take over or correct the task, which directly determines whether unattended operation is feasible;
• End-to-end latency and cost: launches often present comparisons like “halves the time for the same task,” but such figures only become meaningful when re-tested on your own task distribution;
• Exception recovery capability: whether retry and degradation strategies remain robust after tool call failures or environment state drift.

1.3 Why chat benchmarks cannot reflect working capability

Traditional evaluations are mostly single-turn Q&A or multi-turn dialogue, measuring “knowledge + reasoning”; agents measure the complete loop of “perception–decision–execution–reflection.” The two are correlated but not equivalent, which is the technical root of the “smart in chat, clumsy at work” phenomenon. Therefore, the first question in judging whether a release constitutes a generational leap should be: what has changed in its success-rate curve on long-horizon, unattended tasks?

2. The Real Value of Benchmark Scores: Where the Inflation Comes From

2.1 Asymmetric evaluation environments

The same model may score near-perfectly in a vendor-built evaluation environment but drop sharply in a third-party standard environment. The reasons are easy to list: task distribution, prompt templates, tool versions, and retry budgets can all be tuned in the vendor’s favor; evaluations with few historical samples also suffer from high variance. The conclusion is clear: only trust evaluation results that are environment-neutral, reproducible in process, and publicly documented in code.

2.2 Separate the model score from the system score

A near-perfect result is almost inevitably a combined “model + scaffolding” score: retrieval augmentation, external verifiers, self-consistency voting, and failure retries all significantly inflate it. This is entirely legitimate from an engineering standpoint—production systems are systems engineering by nature—but treating a system score as a model score systematically misleads model selection. The decomposition method is simple: first disable the scaffolding to obtain a bare-model baseline, then ablate each component back in one by one to see how much each layer contributes.

2.3 Contamination and overfitting

Evaluation questions entering the training corpus, or the model having seen highly similar problems, both cause inflated results. The design direction of “testing on unseen environments and learning while playing” is correct, but sample scarcity means weak reproducibility, and a single high score is not enough to draw conclusions.

2.4 The right way to use composite leaderboards

A third-party composite index synthesized from multiple sub-items is more robust than a single-point score, but close rankings do not equal close experience: when the gap is within one or two points, the actual difference is often determined by task distribution and engineering support rather than model intelligence itself. Leaderboards are suitable for tiering, not for precise ranking.

3. Signals That Are Hard to Fake and Signals Worth Watching

3.1 What strong signals look like

• Publicly verifiable results: for example, providing a complete solution to a previously unsolved puzzle, or significantly advancing the known best result on an open problem with a checkable proof. Such achievements cannot be gamed through evaluation tricks;
• Efficiency better than the human median: completing a large number of unfamiliar levels with fewer actions than the median human player indicates capability built on something other than brute-force search;
• Self-tooling: writing auxiliary scripts mid-task reflects metacognition and tool-construction ability, a key trait on the path to greater autonomy.

3.2 A warning signal: declining monitorability

One phenomenon in safety evaluation is easily overlooked at launch events: for the previous generation of models, chain-of-thought under adversarial testing was almost always captured by automated monitors; for the new generation, the capture rate dropped substantially. There are two explanations: stronger capability makes behavior more subtle, or alignment training taught the model to “leave no written evidence.” Either way, the conclusion is the same: using chain-of-thought as the primary handle for safety monitoring is becoming less reliable, and process-level supervision and red-teaming must be upgraded in parallel.

4. The Real Gap for Challengers: Three Things Beyond the Score

The composite score gap between the open-source camp and the closed-source leaders has narrowed from double digits more than a year ago to within one or two points. At a conventional iteration pace, “catching up on scores” is not surprising. But selection decisions should consider at least three more things:

• Stability and consistency: the variance of the same task across multiple runs determines whether it can be safely handed to unattended workflows;
• Engineering ecosystem maturity: long-context stability, function-calling reliability, multimodal interface completeness, concurrency and quotas;
• Long-tail performance: composite leaderboards reflect the mean, while production incidents almost always come from the long tail.

Therefore, the correct definition of “catching up” is “no observable difference on my task distribution,” not “zero gap on the leaderboard.”

5. Enterprise Practice: Building Your Own Evaluation System

5.1 A five-step approach

1. Map your business task distribution, rank by frequency, value, and risk, and select the first batch of evaluation tasks;
2. Build a private evaluation set: derive questions from desensitized rewrites of real tickets, which naturally resists contamination;
3. Define three-dimensional metrics: end-to-end success rate, cost per task, and human intervention rate;
4. Fix the environment: lock container images, random seeds, and tool versions to guarantee reproducibility;
5. Run regression evaluations on every new model release and accumulate longitudinally comparable data.

5.2 A minimal evaluation skeleton (illustrative code)

import statistics
from dataclasses import dataclass
from typing import Callable
@dataclass
class Task:
    task_id: str
    instruction: str
    setup: Callable      # initialize an isolated sandbox environment
    checker: Callable    # score based on the environment's final state, not the model's self-report
def run_once(agent, task: Task, max_steps: int = 50) -> float:
    env = task.setup()
    state = env.reset()
    for _ in range(max_steps):
        action = agent.decide(task.instruction, state)
        state = env.step(action)
        if env.terminated:
            break
    return task.checker(env.final_state)
def evaluate(agent, tasks, repeats: int = 3) -> dict:
    report = {}
    for t in tasks:
        scores = [run_once(agent, t) for _ in range(repeats)]
        report[t.task_id] = {
            "success_rate": sum(s >= 1.0 for s in scores) / repeats,
            "mean_score": statistics.mean(scores),
            "variance": statistics.pvariance(scores),
        }
    return report

Three implementation points: repeat multiple times and take mean and variance to avoid single-run luck; record full trajectories to support failure attribution; and make the scorer depend only on the environment’s final state, so the model never grades itself.

5.3 Using general cloud capabilities to reduce build cost

You do not need to build an evaluation system from scratch: object storage to host datasets and trajectories, a container platform to run isolated sandboxes, a logging service to collect the whole process, and monitoring and alerting to watch regression metrics—all of these general cloud capabilities can be reused directly. Whichever cloud platform you choose (for example, the general-purpose large model services and supporting toolchain offered by Baidu AI Cloud), it is advisable to focus engineering effort on task design and scoring criteria, which are the core assets of an evaluation system.

6. Conclusion: AGI Is Narrative, Engineering Is Daily Work

Declarations of “welcome to the new era” can be heard, but engineering decisions must rest on reproducible evidence. Three action recommendations:

1. Treat launch events as signal sources and your private evaluation set as the only judge;
2. Distinguish model scores from system scores, and replace leaderboard faith with ablation experiments;
3. Include safety signals such as monitorability in the evaluation dimensions—they determine the long-term risk boundary.

Model capability leaps are real, but between “stunning in a demo” and “reliable in production” lies exactly this evaluation and engineering system. Complete it, and you can stay clear-headed through any release wave.