How to Build a Private AI Evaluation Set That Resists Leaderboard Gaming and Sponsored Benchmarks

Why “Beating Some Model” Is Becoming a Weak Signal

In technical communities, you often see claims like “Model X outperformed Model Y on a certain task.” These conclusions sometimes come from public benchmarks, sometimes from personal tests, and sometimes from commercially sponsored content. The problem is that, regardless of the source, a single result is hard to transfer directly to your own business scenario.

The reasons are not complicated.

First, public tasks are vulnerable to leaderboard gaming. Public benchmarks usually have fixed datasets, fixed evaluation scripts, and public leaderboards. Once the evaluation methodology is widely known, models can be specifically optimized against it during training. Some models perform well on public datasets but degrade noticeably when applied to real internal data, real codebases, or real business pipelines. This gap between “strong on the leaderboard” and “weak in production” causes people who only look at rankings to make poor decisions.

Second, private test results are often unverifiable. Some people publish their own private test results, such as “I tested my internal project and Model A is indeed better than Model B.” These claims may be true, but outside readers cannot reproduce them. Without access to the test data, prompts, scoring criteria, and runtime environment, there is no way to determine whether the test was fair.

Therefore, rather than continuing to debate whether a public result was influenced by commercial partnerships, it is more productive to build your own repeatable, inspectable, and iterable private evaluation set. This shifts the focus from “what others claim” to “what actually works in my scenario.”

The Core Goal of Private Evaluation: Staying Close to Real Development Work

The primary principle when building a private evaluation set is that tasks must be close enough to real work. Many general-purpose Q&A or short-text generation tasks can no longer effectively distinguish the capability boundaries of modern large language models. It is not hard for a model to produce one correct sentence. What is hard is maintaining stable output when complex context, long reasoning chains, structured constraints, and cross-domain knowledge are all present at once.

An effective private evaluation task typically has several characteristics.

First, the task has a concrete deliverable. For example, a runnable frontend page, a 3D model file, a compilable backend code module, a set of interface definitions, or structured data. The more concrete the deliverable, the easier it is to make scoring objective.

Second, the task contains implicit constraints. In real development, many requirements are not fully written out. For example, “build a medical anatomy model” may seem to only require visual quality on the surface, but in practice it also requires correct organ positions, proportions, connections, and functional annotations. These implicit constraints require the evaluator to have relevant domain knowledge.

Third, the task has locatable errors. If the only difference between model outputs is a subjective sense of “good” or “bad,” evaluation will be unstable. A better situation is when errors can be clearly identified, such as a bone placed in the wrong orientation, a piece of code crashing under specific conditions, or an API returning a value of the wrong type.

Fourth, the task has meaningful complexity. Simple tasks can no longer separate model capabilities. You need to introduce multi-step reasoning, cross-file code modifications, 3D spatial understanding, physical rules, domain knowledge, or historical context tracking.

Building Frontend Tasks: Moving from “Looks Good” to “Structurally Correct”

If frontend evaluation only focuses on visual appeal, subjective factors will dominate. A more reliable approach is to combine frontend tasks with 3D modeling, animation, video generation, or complex interaction, and to embed domain-specific checkpoints.

For example, you can ask the model to build a “3D human anatomy model.” This task tests not only whether the model can output a renderable 3D structure, but also whether organ positions are spatially accurate, whether hierarchical relationships match anatomical knowledge, and whether annotations point to the correct structures. Even if the model produces decent visuals, it should still be marked as failed if the pulmonary artery and aorta are swapped or the relationship between the left and right lung lobes is wrong.

Similarly, you can design a “3D planetary motion demonstration.” The model needs to represent orbital direction, relative speed, orbital plane, perihelion, and aphelion. If it only generates a few spheres rotating around the sun but gets the orbital radii, velocity relationships, or inclination wrong, it shows that the model has not truly understood the underlying physics.

Video tasks can follow the same approach. For example, ask the model to generate a short video demonstrating a specific biological process or chemical experiment phenomenon. The evaluation should not only check whether the footage is visually coherent, but also whether the order of reagent addition, color changes, precipitate formation, and energy changes match experimental facts.

The advantage of these frontend tasks is that they naturally contain two layers: a visual result and verifiable knowledge. The visual result allows quick screening, while the domain knowledge enables deeper validation.

Building Backend Tasks: Using Real Codebases to Create Sufficiently Complex Context

Backend evaluation is closer to everyday enterprise development. You can select structurally complex projects from open source communities, then use commit history, bug reports, or issue discussions to locate branches in historical versions that had many problems.

Specifically, find a module that was frequently patched during a certain period, then use the pre-fix code as the task input. This input already carries the historical baggage of a real project: inconsistent naming, module coupling, complex conditional branches, missing comments, and hidden dependencies. This kind of complexity is hard to simulate with hand-written problems.

To make the task more challenging, you can introduce “distracting modifications.” For example, first give the original code to a weaker model, then provide it with misleading hints such as “How do you think the concurrency issue here should be handled,” “Please optimize this logic,” or “Please refactor according to modern coding style.” The weaker model will often deliver code that looks reasonable but actually contains many defects. This code can then become part of the complex task.

The final test task can be designed as follows: given a codebase that has been artificially corrupted, the target model must restore correct behavior. The task description can include incorrect clues, half-finished implementations, missing boundary handling, and unreasonable abstractions. The target model needs to identify the business intent, restore broken logic, fix concurrency issues, and complete test cases.

The value of this kind of task is that it is neither a pure algorithm problem nor simple code completion. The model must locate problems within a codebase-level context, understand the original design intent, and resist misleading information.

Writing Executable Check Criteria

Building the task is only the first step. More importantly, you need to define clear and stable check criteria for each task. These criteria should be as automatable as possible to reduce subjective human judgment.

For frontend 3D or video tasks, you can break the checks into individually judgeable items. For example: “The heart is located slightly left of the midline of the chest,” “The left lung has two lobes,” “The axial tilt is approximately 23.5 degrees,” “The Moon’s orbital direction is broadly consistent with Earth’s rotation direction.” Each item should have an unambiguous true or false result. Some 3D structures can be verified through coordinate comparison, ratio relationships, or spatial topology checks.

For backend tasks, prepare a set of test inputs and expected behaviors. Focus on boundary conditions, error paths, concurrency scenarios, and interface constraints. For example:

Input: empty array
Expected: return 400, no null pointer exception
Input: two concurrent write requests
Expected: final count is 2, no lost updates
Input: date crosses a month boundary
Expected: billing cycle is calculated correctly

If certain behaviors cannot be covered by a single test case, use multiple weighted cases. Each failed item deducts points, eventually producing a task completion score.

Using a Strong Model as the Evaluator

Traditional manual review is expensive, and different reviewers often apply inconsistent standards. An alternative is to organize the check criteria into structured documentation and hand it to a sufficiently capable model to verify task completion.

For backend tasks, for example, you can provide the target model’s output code, the original task description, the modification history, the test report, and the check criteria to the evaluating model. The evaluator’s job is not to “judge quality by intuition,” but to check each item against the predefined conditions and point out where and why failures occurred.

To reduce the chance of misjudgment, require the evaluating model to output structured results rather than free-form text. For example:

{
  "task_id": "backend-009",
  "checks": [
    {
      "check_id": "C01",
      "description": "Empty array request must not trigger a null pointer exception",
      "status": "fail",
      "evidence": "Line 42 directly calls first() without a null check"
    },
    {
      "check_id": "C02",
      "description": "Concurrent write requests must not lose updates",
      "status": "pass",
      "evidence": "Uses an atomic update statement"
    }
  ],
  "overall_score": 0.5,
  "summary": "Core logic works, but boundary handling is incomplete"
}

This output format makes it easier to accumulate historical data. As tasks run repeatedly, you can build capability trend curves for different models on the same task set. You can also analyze which tasks best separate model capabilities, and use that insight to further optimize the evaluation set.

Building a Sustainable and Iterative Evaluation Loop

A private evaluation set should not be a one-time effort. It should be maintained like a codebase.

After each run, record three types of information: whether the task is stable, whether the check criteria are clear, and whether the model’s failure patterns are discriminative. If almost all models pass a task, the difficulty is insufficient and you need to add constraints or increase contextual complexity. If even the strongest models frequently fail a task, check whether the task description is ambiguous, whether the check criteria are wrong, or whether the code input itself is unfixable.

At the same time, the runtime environment should be fixed. Frontend tasks need pinned browser versions, rendering environments, and resource loading policies. Backend tasks need pinned dependency versions, language runtime versions, and hardware conditions. Environmental differences will contaminate evaluation results.

It is best to save complete logs for every evaluation run, including task input, model output, check results, evaluator configuration, runtime duration, and error messages. This allows you to trace back to specific execution records if disputes arise later.

Practical Suggestions

Rather than worrying about whether a particular public benchmark is reliable, spend that time building your own task library. Even if you start with only three to five tasks, as long as the tasks are realistic, the check criteria are clear, and the runs are repeatable, the accumulated information over time will far exceed scattered public comparisons.

In practice, start with the business modules you know best. An interactive list page, a form validation scenario, or a code module that once caused an incident in production can all be turned into evaluation tasks. Real failures are often the best source of test material because they naturally contain boundary conditions, contextual dependencies, and verifiable error behavior.

Once you have accumulated enough tasks, categorize them by frontend, backend, data, API, security, and other dimensions to gradually form a private capability profile. The ultimate goal is not a simple ranking, but a clear answer to this question: on the complex tasks most relevant to my business, which model deserves to move to the next round of validation?