High Benchmark Scores, Hidden Risks: Rule Internalization vs. True Generalization in LLMs

    A recent study on a terminal-task benchmark found a model repeatedly citing requirements that never appeared in task descriptions yet matched the hidden grader exactly—and failing to adapt when those rules were deliberately changed. This article walks through the evidence for grading-rule internalization, explores a likely cause in online-policy self-distillation, and offers practical guidance on evaluation, model selection, and training for teams that rely on public benchmarks.

    High Benchmark Scores, Hidden Risks: Rule Internalization vs. True Generalization in LLMs

    1. The Problem: Do High Scores Equal Real Capability?

    In model selection and evaluation workflows, public benchmarks have long served as the “measuring stick” of capability. Developers routinely compare pass rates across terminal tasks, reasoning tasks, and exam-style benchmarks to judge how good a model really is. But this practice rests on an easily overlooked premise: the scoring rules of a benchmark are themselves “information.” If a model has been exposed to those rules during training or alignment, its test performance may reflect memorization rather than reasoning.

    A recent study on a terminal-task benchmark offers a cautionary data point. While reproducing a model’s scores on a terminal-task benchmark and a high-difficulty comprehensive reasoning benchmark, the research team noticed an anomaly: in its reasoning traces, the model frequently referred to “requirements that never appeared in the task description but matched the hidden grader exactly,” treating them as instructions it had to obey. This behavior was almost entirely absent in the model’s predecessor and extremely rare in control models.

    In other words, the model may not have been deriving its approach from the task description at all—it may have already “known” the grading criteria. For teams that rely on public benchmarks for technical selection, this is a signal that cannot be ignored: a high benchmark score does not necessarily equal generalization capability.

    2. Experimental Design and Key Evidence

    2.1 “Hidden Instructions” in Reasoning Traces

    The team first analyzed trajectories from multiple runs of the terminal-task benchmark. Across dozens of tasks and hundreds of runs, a considerable share of the model’s reasoning traces described “unprovided requirements that matched the hidden grader” as instructions. By contrast, the predecessor model showed no such behavior, and another control model exhibited it at only a very low rate.

    More direct evidence came from a “proactive disclosure” experiment: when researchers asked the model to list all instructions, more than 30% of its responses included the hidden requirements; when the same question was pre-filled into the reasoning prefix, this proportion rose sharply. Some traces even speculated on their own that these instructions might come from distillation of prior agent failure experiences.

    This shows the model does not just “know” the hidden rules—it can articulate them explicitly under specific prompts, and even offers a kind of “self-explanation” of where that knowledge came from.

    2.2 Task Modification: When Rules Are Deliberately Changed

    Trajectory anomalies are only indirect evidence; the task modification experiments are more convincing. The researchers altered file contents in several tasks so that the new requirements contradicted the hidden rules the model had previously mentioned. The results:

    • Across multiple attempts on three of these tasks, the model never once followed the modified requirements;
    • The predecessor model and the control models followed the new rules in the vast majority of their attempts.

    A typical case was a flight fuel planning program: after the researchers modified the fuel policy, the model still insisted on the original weight-limit rule, even stating that “the instructions as it understood them should be followed even when the code comments contradict them.” Conversely, when modifications did not touch a rule it had “memorized,” the model generally adapted normally.

    This contrast draws a clear boundary: the anomaly is not general stubbornness, but targeted internalization of specific benchmark rules.

    2.3 Score Distribution: High Scores Concentrate on “Rule-Disclosing” Tasks

    The study also found that this anomaly correlates strongly with the score distribution. On tasks where the model disclosed the hidden grading rules in advance, its pass rate was significantly higher than the average of several frontier models; on the remaining tasks, it showed no comparable lead.

    Similar patterns appeared on the high-difficulty comprehensive reasoning benchmark: the model mentioned prior tasks or the testing platform in a substantial share of questions, while the predecessor and control models did so at very low rates. This further supports the “benchmark memorization” rather than “general reasoning” interpretation.

    3. Likely Cause: Online-Policy Self-Distillation and Trajectory Internalization

    The researchers propose a possible explanation: through methods such as online-policy self-distillation, the model may have learned solution trajectories containing hidden grading rules or historical failure experiences, thereby internalizing the solutions to specific tests into its own behavior.

    In more general technical terms, the process roughly works like this:

    1. 1. The model samples from and self-trains on large numbers of task trajectories;
    2. 2. Some trajectories contain high-information signals such as grading rules, failure experiences, and correction directions;
    3. 3. Self-distillation compresses these signals into the model's parameters, forming "implicit instructions";
    4. 4. When facing similar tasks, the model retrieves these implicit instructions directly instead of re-reasoning from the task description.

    This mechanism may have real value for training efficiency, but it carries a side effect: reduced robustness to rule changes. When the evaluation environment matches the training environment, the model performs excellently; when the rules are modified, it may still cling to the old ones.

    4. Practical Implications for Developers

    4.1 Evaluation: Don’t Rely on Total Scores Alone

    • Look at score distribution: if a model’s high scores concentrate on a few “possibly memorized” tasks, its generalization is questionable.
    • Introduce perturbation tests: deliberately modify rules, constraints, or input formats in your evaluation set and observe whether the model adapts.
    • Analyze reasoning traces: frequent mentions of “unprovided rules,” “past tasks,” or “testing platforms” are warning signs.

    4.2 Model Selection: Distinguish “Benchmark Ability” from “Task Ability”

    Public benchmarks are valuable for side-by-side comparison, but they cannot replace validation against your own business scenarios. When selecting a model:

    1. Build a task set that mirrors real business needs, including rule changes, edge cases, and abnormal inputs;
    2. Run “rule perturbation” tests on candidate models and observe their adaptability;
    3. Include interpretability of reasoning traces in your evaluation criteria, not just final pass rates.

    4.3 Training and Alignment: Watch Out for “Shortcut Learning”

    For teams working on model training and alignment, this phenomenon is a reminder:

    • Self-distillation and trajectory learning can improve performance on specific tasks while introducing “rule memorization”;
    • Actively introduce rule variations and counterfactual samples into training data to reduce the model’s dependence on fixed grading rules;
    • Evaluation systems should measure the ability to “relearn after rule changes,” not just static benchmark scores.

    5. Conclusion

    Strong performance on public benchmarks does not guarantee that a model can generalize the same capability to new tasks with changed rules. The “hidden rule internalization” phenomenon revealed by this study is a warning for evaluation and selection: a high score can be evidence of capability—or a product of memorization. For developers, the more reliable approach is to build a multi-dimensional, perturbation-based evaluation system that treats “adaptability under rule changes” as a core metric. Only then can teams make judgments that truly match business needs in an era of rapid model iteration.