Evaluation drift occurs when an evaluator stops measuring the behavior the team actually cares about. The system under test may not have changed at all. What changed is the instrument: the test set no longer looks like your traffic, the judge model was updated underneath you, the rubric no longer matches current policy, or the system found a way to pass the eval without getting better.
This is the most expensive failure mode in evaluation because of how it presents. Model drift shows up as worse numbers, which is annoying but actionable. Evaluation drift shows up as stable or improving numbers while the product degrades, so you get green dashboards and angrier users, and the dashboard is the reason nobody looks.
Data drift is a change in the inputs, model drift is a change in the system’s behavior, and evaluation drift is a change in the validity of the measurement. Only the third one makes your other monitoring lie to you.
Build better agents with Arize
Trace, evaluate, and learn. Build agents that work with Arize AX and start tracing your runs today.
Prefer open source? Try Arize Phoenix for self-hosted, open source agent observability.
Key takeaways
- Evaluation drift is a loss of measurement validity, not a drop in scores. The tell is scores that hold steady while user complaints rise.
- The five concrete causes are set staleness, a judge model changing version, rubric and grader shift, label rot, and optimization against the eval itself.
- A judge model accessed through a floating alias will change under you with no commit in your repository. Pin exact versions and record them with every score.
- Human graders drift too. Inter-annotator agreement decays as annotators are added, get faster, or reinterpret an edge case.
- The detection method is a frozen replay: re-score a preserved sample with today’s judge and compare to the original scores. If they differ, the instrument moved.
The concrete causes
The set stopped representing traffic
A golden dataset built at launch captures the traffic of that month. Six months later there are new locales, a new integration whose tool errors nobody anticipated, sessions three times longer, and a customer segment that phrases everything as one run-on question. The suite still passes at 0.91 because it is still testing the old traffic. The fix is unglamorous: refresh the set from recent production records on a schedule, and track the distribution of the set against live traffic the way you would track any other drift.
The judge model changed underneath you
If your scorer calls a model through a floating alias rather than a pinned version string, the provider can update the weights behind it and your scores move with no commit in your repository. Even with a pinned version, a change in refusal behavior, default decoding settings, or system prompt handling during an SDK upgrade shifts results. A judge that starts refusing to score borderline safety content produces null results that get averaged as though they were scores.
So pin exact model versions in scorer configuration, store the version with every result, and re-run a fixed sample after any provider or SDK change. This is the least glamorous part of deciding when an LLM judge is the right instrument and the part that most often explains an unexplained score movement.
Rubric and grader shift
Two versions of the same problem. The rubric version: someone edits the judge prompt to improve it, a good instinct that silently makes every score before the edit incomparable to every score after. The grader version: annotators change. New people calibrate differently, veterans get faster and less careful, and an ambiguous category gets resolved one way in March and the other way in July.
Both are measurable. Keep a small set of records with agreed labels, re-label a portion periodically, and track agreement over time. Running a panel of judges rather than one also gives you a disagreement rate, and a rising one is a leading indicator of a rubric that has become ambiguous.
Label rot
Ground truth expires. A reference answer citing the refund window, the supported region list, or the pricing tier was correct when written. After the policy changes, the correct current answer gets marked wrong and the model is penalized for being right. Retrieval suites rot the same way: the expected document is re-chunked or removed, and a context-recall check starts failing for reasons unrelated to the retriever. Any set whose answers depend on a corpus or a policy needs an owner and a review cadence tied to that corpus.
The system learned the test
Iterate on prompts against a fixed set for long enough and the score rises without user outcomes improving. Sometimes it is honest overfitting: the phrasing that satisfies the judge is not the phrasing users prefer. Sometimes it is leakage, with eval cases used as few-shot examples or pulled into fine-tuning data. Either way the score now measures adaptation to the test.
The countermeasure is a held-out set that never informs iteration, a second set rotated from recent traffic, and a check of eval scores against an independent production signal such as escalation rate or negative feedback. That last one requires scores joined to real sessions, which is where tracing and evaluating agents against production traffic stops being optional.
How to detect it
- Frozen replay. Keep a sample of prepared evaluation inputs and their original scores, then re-score them with today’s judge and configuration. The inputs are identical by construction, so any divergence is the instrument moving.
- Human agreement tracking. Score a small labeled audit set on a fixed cadence and track agreement between the scorer and human labels. A falling agreement rate is the clearest single signal.
- Score against outcome. Plot eval score alongside an independent production signal. When quality scores rise while retries, escalations, or thumbs-down also rise, believe the users.
- Set versus traffic comparison. Compare the eval set to live traffic on intent mix, input length, language, and customer segment. If a score moved and no version string in the record changed, something unversioned moved.
FAQ
How is evaluation drift different from data drift or model drift?
Data drift means the inputs changed. Model drift means the system’s behavior changed. Evaluation drift means the measurement lost validity, so it can be occurring while both input and output distributions look stable. It is also the only one of the three that corrupts your ability to detect the other two.
Can evaluation drift make scores go up?
Yes, and that is the more dangerous direction. Scores rise when the system has adapted to the test, when a judge model update makes it more lenient, when stale reference answers happen to be easier than current questions, or when a rubric edit relaxed a criterion. Rising numbers get investigated far less often than falling ones.
How often should an eval set be refreshed?
Tie it to the rate of change in your product and traffic rather than to a calendar default. A reasonable pattern is a frozen regression suite that rarely changes, so historical comparisons stay valid, plus a rotating set refreshed from recent production records every few weeks. Any policy or corpus change should trigger a review of the affected reference answers immediately.
Does evaluation drift apply to deterministic checks too?
Less often, but yes. A schema assertion drifts when the schema is extended and the check is not. A forbidden-phrase list drifts as product vocabulary changes. A regular expression written for one output format silently passes everything after the format changes. Deterministic checks fail loudly when the code breaks and quietly when the world moves.
