How to Build a Reliable Private AI Evaluation Dataset

I. Why We Need Private Evaluation Datasets

When comparing model capabilities, both public and private evaluations have distinct limitations. Public benchmarks offer fixed tasks and reproducibility, but long-term use often leads to data contamination or benchmark gaming. Some models perform exceptionally well on public leaderboards but fail dramatically in real-world business scenarios. This usually happens because the model has implicitly seen similar samples during its training or fine-tuning phases.

Private evaluation datasets are the opposite. Tasks are designed by the users themselves, and the samples are not publicly disclosed, making it difficult for models to overfit in advance. However, private tasks have their own challenges: if the task design is too simple, it lacks discriminating power; if the task itself is flawed or the grading criteria are unclear, the evaluation results are easily disputed.

Therefore, a reliable private evaluation dataset must simultaneously satisfy three conditions: sufficient task complexity, verifiable conclusions, and executable grading standards.

---

II. Frontend Tasks: Upgrading “Can Generate” to “Can Generate Correctly”

Frontend generation tasks are currently a highly competitive area for various models. Capabilities like 3D modeling and video generation are iterating rapidly, but many demonstrations remain purely visual. If you only evaluate whether the generated image looks aesthetically pleasing, it is easy to encounter situations where the output “looks great but is actually incorrect.”

To improve task discrimination, you can introduce explicit structural validation checkpoints into generation tasks.

2.1 Increasing Verifiability via Domain Knowledge

Take 3D modeling as an example. If you ask a model to generate a human anatomical model, you cannot just check if the surface morphology looks realistic. You also need to verify the following:

• Whether the bone positions conform to anatomical structure;
• Whether muscle origins and insertions are connected to the correct bony landmarks;
• Whether joint movement directions align with real human joints;
• Whether the relative positions of different organs are reasonable.

Similarly, for a celestial motion simulation, when generating a local model of the Earth-Moon system or the Solar System, you can check:

• Whether planetary orbits approximate ellipses;
• Whether distances and periods roughly comply with Kepler’s laws;
• Whether axial tilt affects day/night and seasonal simulations;
• Whether the occlusion relationships between celestial bodies are correct.

These checkpoints do not rely on subjective aesthetics but are based on explicit scientific rules. Even if the model generates a visually stunning image, as long as the structural relationships are wrong, it can be deemed unqualified.

2.2 Increasing Task Difficulty with Multi-Disciplinary Constraints

Single-discipline rules might not be sufficient. You can overlay multiple knowledge domains within a single task, forcing the model to satisfy different constraints simultaneously. For example:

Generate a 3D model of a human knee joint for basic educational purposes, requiring:

1. Inclusion of the distal femur, proximal tibia, patella, and major ligaments;
2. Bone contact surfaces matching anatomical morphology;
3. Ability to simulate flexion and extension, with a range of motion close to a real joint;
4. Polygon count not exceeding 200,000 for web-based rendering.

This type of task simultaneously tests the model’s 3D modeling capabilities, anatomical knowledge, understanding of physical movement, and resource constraint awareness. A model that simply produces “visually realistic” output will fail the evaluation.

---

III. Backend Tasks: Constructing Controllable Complex Legacy Code

Backend code tasks are easier to quantify than frontend tasks but are also more susceptible to models “memorizing answers.” If you use public, popular open-source projects as evaluation samples, the model may have already seen similar code during pre-training. To mitigate this risk, you can start from the task construction methodology.

3.1 Selecting Real-World Complex Problems

You can utilize repositories on code hosting platforms to find task materials. The specific approach is as follows:

1. Select projects with complex functionality, numerous modules, and long maintenance histories;
2. Review the Issue list to locate real bugs that occurred in the past;
3. Find the two versions immediately before and after the bug fix;
4. Understand the trigger conditions and impact scope of the bug.

Tasks derived this way have a key advantage: they correspond to real engineering problems with clear right and wrong boundaries.

3.2 Deliberately Creating “Spaghetti Code”

Directly using the pre-fix code as input might not be difficult enough. You can have a weaker model perform a “destructive rewrite” of the code and attach misleading prompts.

For instance, if the original requirement is:

Fix the issue where order status might be lost during concurrent updates.

It can be rewritten as:

This code occasionally has inaccurate status in concurrent scenarios, help me optimize it a bit, no need to change too much.

Combined with the output of a weaker model, the code might end up with a chaotic structure, arbitrary variable names, and redundant branches, while the core problem remains unfixed. You then hand this “spaghetti code” to the model being tested, requiring it to:

• Locate the original bug;
• Remove invalid changes;
• Provide a fix that meets the original requirement.

This approach significantly increases task difficulty and prevents the model from directly outputting a “memorized standard answer.”

3.3 Controlling the Intensity of Misleading Prompts

Misleading prompts should not be too obvious, or the task will turn into a “spot the prompt trap” game rather than a test of code comprehension capabilities. You can gradually increase interference across three levels:

Level	Misleading Method	Applicable Scenario
Low	No misleading, just provide the code	Basic capability test
Medium	Describe the problem without giving a location, attach irrelevant optimization suggestions	Comprehensive capability test
High	Use spaghetti code generated by a weaker model, and provide misleading direction hints	High-difficulty discrimination test

It is recommended to choose the appropriate level based on your evaluation goals. If you only want to know if a model can perform basic fixes, use the low level. If you want to differentiate between top-tier models, use the high level for construction.

---

IV. Grading Standards: Using a Stronger Model for Unified Inspection

Once tasks are completed, manually checking each item is costly and prone to subjective bias. You can use a stronger model as an “inspector” to grade the outputs based on pre-written standards.

4.1 Inspection Standards Must Be Written as Executable Items

Vague descriptions like “is the structure correct” are too ambiguous for an inspector model to execute. Each criterion must be broken down into assessable items.

For example, the inspection standard for the backend concurrent update task can be written as:

Checklist:
1. Does the pre-fix code lose the subsequently submitted status when concurrently calling update_order_status?
2. Does the fixed code introduce locks, transactions, or equivalent concurrency control mechanisms?
3. Does the fix affect the original state transition logic in single-threaded scenarios?
4. Are there obvious redundant branches or invalid variables in the code?
5. Does the modification keep the original external interface unchanged?
Grading Rules:
- All met: Pass;
- Either item 1 or 2 not met: Fail;
- Items 3 or 4 not met: Deduct points but not deemed a complete failure.

The advantage of this standard is that regardless of who conducts the inspection, the conclusion will remain largely consistent.

4.2 Identifying Inspector Model Errors

Even if a very strong model is used as an inspector, misjudgments can occur. Common misjudgments include:

• Over-sensitivity to synonymous implementations, e.g., considering “not using transactions” as an error, even though the code solved the problem using an optimistic lock;
• Letting code style preferences affect scoring, e.g., focusing too much on whether naming is elegant;
• Providing unstable evaluations on “aesthetics” in open-ended tasks.

The countermeasure is: for key inspection items, base judgments on “whether substantive requirements are met” rather than “whether it matches the reference implementation.”

4.3 Recommending Manual Spot Checks

For critical conclusions, after automatic model scoring, you can extract a small sample for manual review. If the consistency rate between automatic scoring and manual judgment is high, you can gradually expand the proportion of automatic scoring. If the consistency rate is low, you need to revise the inspection standards first.

---

V. A Complete Evaluation Workflow Example

Let’s connect the above steps using a comprehensive example.

Task Description:

Background: A legacy system has an issue where order status is lost during concurrent updates.
Input:
1. A piece of destructively rewritten code generated by a weaker model;
2. A vague and misleading requirement description.
Requirement:
Fix the code and provide an explanation of the modifications.

Inspection Standards:

1. Correctly identify the concurrent status loss issue;
2. Fix using locks, transactions, version numbers, or equivalent means;
3. Preserve original external interfaces;
4. Do not introduce new race conditions;
5. Modification explanation aligns with code logic.

Workflow:

1. The tested model receives the task and outputs the fixed code and explanation;
2. The inspector model scores against the five standards item by item;
3. Manually review the top 5% and bottom 5% of samples;
4. Aggregate pass rate, misjudgment rate, and typical error types.

Through this approach, the evaluation results are backed by quantitative metrics and are not dominated by public data contamination or subjective judgments.

---

VI. Conclusion

The value of a private evaluation dataset lies not in “making things harder for the model,” but in “ensuring that differences in model capabilities can be stably observed.” Frontend tasks can counter visual biases by introducing scientific structural constraints. Backend tasks can construct discriminating inputs using real bugs, weaker model destruction, and misleading prompts. The scoring phase relies on clear standards and a stronger inspector model, reducing manual costs and subjective fluctuations.

Building a reliable private evaluation dataset requires significant effort, but once established, this methodology can be continuously reused. For teams looking to systematically assess a model’s actual development capabilities, such an investment is usually worthwhile.