Evaluation drift is when your benchmark stays the same, but the world changes. Users adopt new intents, policies evolve, new tools are added, and the knowledge base changes. Your evaluation suite keeps passing, yet customers report worse outcomes. That is not a model mystery. That is drift.
Where drift comes from
Common sources of evaluation drift include:
- Intent drift. Users ask new questions as they learn what the product can do.
- Policy drift. Refusal and disclosure policies change (see policy layering).
- Tool drift. New tools and new tool contracts change the action space (see tool contracts).
- Knowledge drift. Documents are updated, deprecated or deleted (see source lifecycle).
- Population drift. New tenants and domains change language and edge cases.
Detect drift with coverage signals
You do not need perfect detection. You need early signals:
- Unmapped intents. Production queries that do not match any evaluation cluster.
- Rising abstention/complaints. Spike in refusals, clarifications or re-tries.
- Tool error changes. New failure classes after tool updates (see error taxonomy).
Operational telemetry helps here (see usage analytics and observability).
Refresh your evaluation suite intentionally
Benchmarks should have a refresh cadence. A practical approach:
- Monthly sampling. Sample real queries and outcomes, then add representative cases.
- Incident-derived tests. Convert failures into permanent regression cases (see incident response).
- Policy suite updates. Update refusal and disclosure tests when policy changes (see refusal calibration).
Version the dataset and track changes like code (see evaluation datasets).
Protect against benchmark gaming
When teams over-focus on a fixed benchmark, they tune to the test. Controls that help:
- Keep a small "holdout" set that is not used for tuning.
- Rotate a portion of the benchmark each refresh cycle.
- Use rubrics that score outcomes, not specific phrasing (see evaluation rubrics).
Link evaluation results to versions and rollouts
Drift is easier to manage when you can correlate changes:
- Record prompt and config versions for every evaluation run (see prompt registries).
- Run evaluations on every change and gate high-risk releases (see testing pyramid).
- Use canaries in production to validate outcomes on real traffic (see canary rollouts).
Evaluation drift is not a reason to stop benchmarking. It is a reason to treat benchmarks as living assets. When your evaluation suite evolves with your users and policies, it becomes a reliable control system rather than a comforting dashboard.