The most dangerous eval set is the one that still passes. A regression suite that goes red gets attention: someone opens the failing case, argues about it, fixes the bug or updates the expectation. A green suite gets trust. And trust is exactly what a rotted eval set does not deserve, because the score stayed green not because your system is good but because the test stopped resembling what your users actually do.
This is the quiet failure mode of AI evaluation. You build a golden dataset — a few hundred carefully labeled cases that represent the job your product does. It earns its keep for a quarter. Every deploy runs it, every score lands green, and everyone sleeps well. Meanwhile the product ships three new features, enterprise traffic climbs from ten percent of queries to forty-five, and users start phrasing requests in ways nobody on your team wrote down eighteen months ago. The eval set doesn't know about any of it. It keeps grading the model on a distribution that no longer exists.
The failure is insidious precisely because it produces no alarm. Model regression is loud — a metric drops, a dashboard turns red, someone gets paged. Eval drift is silent. Nothing breaks, the checks keep landing, and you're flying blind with the instrument panel showing all-clear. A passing score on a rotted set is worse than no eval at all, because "no eval" makes you cautious and a green check makes you confident. Manufactured confidence is the expensive kind.
An Eval Set Is a Living Asset, Not a Fixture #
The mental model most teams start with is wrong. They treat the golden dataset like a unit test: write it once, commit it, and trust it forever because the inputs and expected outputs are pinned. That works when the thing under test is deterministic and the world it models is static. Neither is true for an AI product.
The world your eval set models is the distribution of real user behavior, and that distribution moves. It moves when you add a feature, when you enter a new market, when a competitor's outage sends you a wave of unfamiliar users, when a viral post teaches people a new way to ask for something. Your labeled cases were a photograph of user behavior at one moment. Photographs age.
So the correct mental model is closer to a garden than a fixture. It needs weeding, replanting, and seasonal attention. An eval set has a maintenance cost, and if you don't budget for that cost, you're not saving effort — you're deferring it into a category of failure that's much harder to detect. The teams that get this right treat the dataset as a first-class artifact with the same governance as code: it's versioned, changes to ground truth get code review, and deleting or modifying a labeled case is treated as production risk, not housekeeping.
The Three Ways It Rots #
Decay isn't one thing. It shows up in at least three distinct modes, and they call for different responses.
Coverage gaps open as the product grows. Every new feature introduces intents, entities, and edge cases the original set never sampled. You launched a summarization feature; your eval set has zero summarization cases. The score is still green because the existing cases still pass — but "green" now means "we tested the eighty percent of the product that existed last year." The untested twenty percent is where the fresh bugs live, and by construction your eval is blind to exactly the code you're most likely to break.
Stale labels accumulate as ground truth shifts underneath you. The definition of a "good" answer is not fixed. A response that was correct last year may be wrong now because a policy changed, a fact changed, a downstream system changed, or your own product's notion of quality matured. The case still runs, still compares the model output against the stored expectation, and still reports pass or fail — but the expectation itself is a fossil. Worse, a deprecated behavior whose cases still count against you will punish the model for doing the right thing.
Distribution skew is the subtlest and the most consequential. Here your cases are individually valid and the labels are correct, but the mix no longer matches production. Your set is sixty percent simple lookups because those were easy to write; production is now dominated by multi-step reasoning queries. The aggregate score is a weighted average over the wrong weights. This is not hypothetical: research from Meta AI found that evaluation datasets skewed toward simple queries overestimated production RAG quality, with accuracy dropping twenty-five to thirty percent once measured on a realistic query distribution. Your eval said ninety; reality said sixty; the gap was entirely in the sampling.
There's a fourth, self-inflicted mode worth naming: overfitting to the set itself. If your eval never changes, every prompt tweak and model swap is optimized against the same few hundred cases until the system learns the test rather than the task. A frozen golden set doesn't just go stale — it becomes a target, and Goodhart's law does the rest.
References:
https://galileo.ai/blog/beyond-golden-datasets-static-evals-failureshttps://dev.to/gabrielanhaia/eval-set-drift-how-to-know-when-your-golden-set-went-stale-p8mhttps://www.getmaxim.ai/articles/building-a-golden-dataset-for-ai-evaluation-a-step-by-step-guide/https://dextralabs.com/blog/production-rag-in-2025-evaluation-cicd-observability/https://www.arthur.ai/column/evaluating-ai-agents-in-productionhttps://arize.com/llm-evaluation/https://www.databricks.com/blog/best-practices-and-methods-llm-evaluationhttps://www.evidentlyai.com/blog/embedding-drift-detectionhttps://dev.to/jenueldev/ai-evals-are-broken-but-builders-still-need-them-nh3https://blog.bytebytego.com/p/a-guide-to-llm-evals
Let's stay in touch and Follow me for more thoughts and updates