What is eval dataset drift?

Eval dataset drift is the growing mismatch between what a golden evaluation dataset contains and what the production agent actually does. It develops in three forms: input distribution shift (users start sending different queries than the dataset anticipated), label drift (expected outputs become wrong as the agent or policy changes), and coverage decay (new failure modes accumulate in production that no test case covers).

How do I know if my eval dataset has drifted?

The clearest signal is a divergence between eval scores and production complaint rate: scores staying high while customer escalations increase. You can also check directly by pulling 200-300 recent production spans from your trace source, clustering them by intent, and comparing the distribution against your dataset. Input clusters present in production but absent in the dataset are gaps that drift has opened.

What is input distribution shift in LLM evaluation?

Input distribution shift is what happens when users start sending queries that differ from the queries your golden dataset was built on. The graders may still work correctly, but they are evaluating the agent on test inputs that no longer represent what users send. The eval score reflects performance on an older query distribution, not the current one.

What is label drift in LLM evals?

Label drift occurs when the expected output in the dataset becomes wrong because the agent's behavior policy changed. If the system prompt changed to require a different response format, or business rules changed what the agent should return, old expected outputs will mark correct new behavior as failures. The score drops because the agent's behavior changed, not because quality declined.

What is coverage decay in agent evaluation?

Coverage decay is the accumulation of failure modes in production that no test case in the dataset covers. As the agent handles more volume and more varied inputs, new failure modes emerge that were not present when the dataset was built. The dataset does not grow automatically to include them, so those failure modes go undetected by the eval suite.

How does pulling from production traces fix dataset drift?

Production traces reflect what the agent is actually handling after each deploy, not what it handled at launch. Sampling recent spans from Langfuse or Braintrust and clustering them by intent surfaces input patterns in current traffic that existing graders haven't reached. Those become new cases when accepted, keeping the dataset distribution aligned with real production behavior.

Eval Dataset Drift: Why Golden Test Sets Stop Catching Failures

An eval suite can pass on every deploy while customer escalations climb. The graders are fine; the golden dataset they run against no longer looks like production traffic. That gap is eval dataset drift, and it develops in three forms: input distribution shift, label drift, and coverage decay.

Hamel Husain’s eval engineering FAQ gives this pattern a timeline: skip three months of sampling production queries and adding them to the dataset, and the eval suite no longer represents what users send. The staleness he documents is in the test cases, not just the graders.

Dataset drift is distinct from grader maintenance. A grader can be well-calibrated against cases that no longer represent real traffic. A dataset can stay current in its cases while the graders evaluating them lose accuracy. The two problems produce the same symptom (false confidence from a passing score) but require different fixes. Drift in test cases needs new sampling from production; drift in graders needs recalibration against current output quality.

What Causes Input Distribution Shift in LLM Eval Datasets

Input distribution shift happens because a golden dataset captures the query distribution that existed when it was assembled, while users keep sending different queries as the product evolves. The test cases reflect the product at launch; current traffic does not.

Months later, the product has new features, the user base has shifted, and what users actually ask has shifted with them. The graders evaluate the agent on inputs that no longer represent current production traffic. Query types that dominated the original dataset may now be a fraction of actual traffic. Query types common in current sessions may have no representation in the dataset at all.

The eval score stays accurate on the old cases while becoming uninformative about what users are actually sending today. The only mechanism that corrects this is sampling current production queries and adding them to the dataset on a regular schedule, which is exactly what Hamel Husain identifies as the practice teams skip.

What Happens to Expected Outputs When the Agent Evolves

Expected outputs in a golden dataset become wrong whenever the agent’s behavior changes and the dataset doesn’t follow. Each case was written to reflect what correct behavior meant at that time. When the system prompt changes, policy changes, or the model shifts output formats, those expected outputs start marking correct behavior as failures.

Each change, whether a prompt update, an integration change, or a business rule shift, makes old expected outputs a source of noise rather than signal. Some of those changes never appear in your repo: a model provider update can shift output formats with no deploy on your side. Scores drop when the agent actually improved because the dataset still grades against what correct meant months ago.

The clearest way to detect label drift is to sample 50-100 recent production spans and identify cases where the agent’s output does not match the old expected output. For each, check whether the new output is correct under the current system prompt and policy. If it is, that case is label drift rather than a regression, and the expected output needs updating. The proportion of confirmed label drift cases in the mismatch pool tells you how much of a score drop reflects genuine quality decline versus outdated expected outputs.

How Coverage Decay Lets Failure Modes Accumulate Undetected

Coverage decay is the accumulation of production failure modes that no test case in the dataset covers. As new failure modes appear in real traffic, the eval suite has no grader to detect them, so the agent fails while the suite reports green.

Users discover edge cases through use. A query pattern that triggers failures may not have existed in the traffic the original dataset was sampled from. As the agent handles more varied inputs at scale, the space of queries it encounters widens, and the dataset, frozen at launch, falls progressively behind.

When no test case exists for a failure mode, the eval score does not move. Engineers read consistent pass rates as stable quality while the category of inputs that triggers failures accumulates undetected in production logs. The longer the dataset goes without sampling from current traffic, the wider that unmonitored gap grows.

How to Tell When Eval Dataset Drift Has Taken Hold

Two signals are specific to dataset drift rather than grader staleness.

The first is a divergence between eval score trajectory and production complaint rate. If scores hold steady or improve while customer escalations increase, the dataset is no longer measuring the failure modes users encounter.

Reading the trend matters more here than any single score. An imperfect grader misfires at a stable rate, so a sustained shift across grader verdicts signals a real change even when individual graders capture intent loosely. Dataset drift is what breaks that property: a frozen dataset flattens the trend on exactly the inputs where quality is moving.

The second is a coverage gap between the dataset’s input distribution and current production traffic. Pull recent spans from your Langfuse or Braintrust trace source, cluster by intent or topic, and compare the cluster distribution against the cases in your dataset. Clusters present in production but absent from the dataset are where drift has opened gaps. The eval coverage gap article describes how to run this comparison and what to do with the clusters it surfaces.

How to Fix Dataset Drift Using Production Traces

Production traces fix all three types of drift because they reflect what the agent is actually handling after each deploy, not what it handled at launch. A span from a connected trace source is always current. Sampling from that pool means new dataset cases come from the distribution users are in today.

Input distribution shift is visible when the cluster analysis shows query types common in recent spans that have no representation in the dataset. Label drift surfaces when production spans show the agent returning outputs that do not match old expected outputs but are clearly correct under the current prompt and policy. Coverage decay shows up when clustering recent spans turns up failure patterns that no grader has been written to catch.

Tessary compares incoming production spans against your dataset’s input cluster distribution and flags the query types in current traffic that no test case covers. For label drift, it does more than surface the spans where agent output diverged from old expected outputs: when a score moves, it correlates the shift with the change that triggered it, whether a prompt edit, an integration change, or a provider model update that never touched your repo. Whether a drop is a regression to fix or a dataset case to relabel becomes an answered question instead of a 50-span manual audit.

Langfuse and Braintrust hold the traces and track the scores. Tessary reads those traces to tell you which drift form you are looking at and, when quality genuinely dropped, which change moved it. The evals that evolve with the product page covers how new cases flow into the suite when you accept them.

Connect your Langfuse or Braintrust source and see where your dataset has drifted before the next deploy, with each real score drop tied to its cause. The first report runs without a credit card.

Find what broke your agent