Model drift: regression testing when the model changes under you

On a Tuesday morning, an invoice parser that had worked for eight months started returning dates as 2026-03-04 instead of 04/03/2026. No deploy went out. No prompt was edited. The downstream service rejected every record with a validation error and the queue backed up by 40,000 invoices.

The cause was an upgraded model behind the same API name. Nothing in the team's test suite would have caught it, because the suite only ran when someone pushed code.

Short version

• Model drift means the model behind your API changes, so the same input produces a different output.
• Pin an exact model version. A name without a version is a moving target.
• Keep a golden set: fixed inputs with known-good outputs, stored in version control.
• Run that set on a schedule, not only on commit. Drift does not wait for your deploys.
• Before any upgrade, run both versions side by side and diff the outputs.
• Learn your noise floor first, or you will chase randomness instead of regressions.

---

Three things people call drift

The word covers three different problems, and they need different fixes.

This guide is mostly about the first. It is the one that arrives without warning and the one testers are best placed to catch.

Pin the version, always

Most providers offer two kinds of model identifier: an alias like assistant-latest, and a dated version like assistant-2026-02-14. The alias moves. The dated version does not, until it is retired.

Use the dated version everywhere, and keep it in one place in your config:

MODEL_ID=assistant-2026-02-14

Then treat a model upgrade like any other dependency upgrade: a pull request, a test run, and a review. Do not let it happen through a provider announcement you did not read.

Four rules that go with pinning:

1. Log the version with every response. When a bug is reported three weeks later, you need to know what answered.
2. Watch deprecation dates. Pinned versions get retired. Put the date in your calendar with a month of margin.
3. Pin in every environment. A staging environment on a different version tests nothing useful.
4. Pin the embedding model too. If you use retrieval, changing the embedding model invalidates your whole index. This one is easy to forget and expensive to fix.

Pinning does not remove randomness. Two calls to the same pinned version with the same input can still differ. It only removes the surprise upgrade.

Build a golden set

A golden set is a fixed list of inputs with outputs you have checked and accepted. It is the closest thing to a unit test suite that AI features have.

Keep it small enough to run often and broad enough to matter. Fifty to two hundred cases is a good range. Store it in your repository as plain files so changes show up in code review.

Each case needs:

• A stable ID, such as INV-014.
• The input, exactly as the system receives it.
• The expected output, or the rules the output must satisfy.
• The reason this case exists, in one line.

That last field pays for itself. Six months later, nobody remembers why INV-014 uses a Belgian VAT number, and someone will delete it.

Cover four groups deliberately:

• Common cases. The inputs 80 percent of users send.
• Edge cases. Empty fields, very long text, mixed languages, unusual characters.
• Past bugs. Every production incident becomes a permanent case. This is the highest-value group.
• Safety cases. Inputs that must be refused, and inputs that must not be refused.

Assert on structure before meaning

Most drift damage happens at the structural level, and structure is cheap to check exactly. Do these first:

• Output parses as valid JSON.
• Required fields are present.
• Dates match YYYY-MM-DD.
• Numbers are numbers, not strings like "49.00".
• No markdown code fences wrapped around the JSON.
• Enum fields contain only allowed values.

The invoice example at the top of this article would have been caught by one regular expression on the date field.

For meaning, use looser checks that tolerate wording changes:

• The answer contains a specific value, such as AC-88142.
• The answer does not contain a forbidden phrase.
• A classification label matches exactly.
• Similarity to the reference answer stays above a threshold.
• A separate grading model scores the answer against a short rubric, with humans reviewing every failure.

Structural checks can gate a release automatically. Meaning checks should raise a flag for a human, at least until you trust the grader.

Find your noise floor first

Before you can call anything a regression, you need to know how much your outputs vary when nothing has changed.

1. Pick your golden set and pin the model version.
2. Run the whole set 10 times on the same day, changing nothing.
3. Record the pass rate for each run.
4. The spread between the best and worst run is your noise floor.

If your pass rate wanders between 91 and 96 percent with no changes, then a drop to 94 percent after an upgrade means nothing. A drop to 78 percent means something.

Write the floor into your alert rules. Teams that skip this step either alert on everything and then mute the channel, or set the threshold so wide that real regressions slip through.

Run canary evaluations on a schedule

A canary evaluation is a small, fast subset of your golden set that runs automatically and often.

A practical setup:

• Every hour: 10 cases against production. Structural checks only. Alerts go to the on-call channel.
• Every night: the full golden set against production and staging. Structural and meaning checks. Results posted as a trend, not just pass or fail.
• On every merge: the full set against staging, blocking the merge on structural failures.
• Before any model change: the full set on both versions, with a diff.

The hourly canary is what catches a provider-side change on a Tuesday morning. Keep it cheap. Ten short cases per hour is a small cost next to 40,000 rejected invoices.

Track the trend rather than the last result. A pass rate falling from 96 to 94 to 91 over three weeks is drift you can act on early. A single red run is often noise.

Diff two versions before you upgrade

When you are ready to move from assistant-2026-02-14 to assistant-2026-05-30, do not just check that tests still pass. Look at what changed.

1. Run the full golden set on both versions, five times each, same inputs, same settings.
2. Compare pass rates per case, not just overall. Overall numbers hide swaps where five cases break and five improve.
3. List every case that changed status in either direction.
4. Read the actual outputs for those cases. Side by side, in full.
5. Measure length and latency too. New versions often produce longer answers, which costs money and slows the page.
6. Write a short note: what improved, what broke, what you will change in the prompt.

Step 3 is the one to insist on. A team that reports "97 percent before, 97 percent after" and ships has learned nothing. Ten cases flipping in each direction is a meaningful behaviour change even when the number is flat.

Then roll out gradually. Send 5 percent of traffic to the new version, watch your production quality signals for a few days, and keep the old version pinned and ready. If your provider retires versions quickly, that rollback window is short, which is another reason to test early rather than on the deprecation date.

Frequently asked questions

How often does model drift actually happen?

Alias-based upgrades happen several times a year for most providers, and infrastructure changes can shift behaviour in between. If you pin versions, the surprise events mostly disappear and you control the timing.

Is temperature zero enough to make outputs stable?

No. Lower randomness settings reduce variation but do not remove it. Batching, hardware, and provider-side routing all introduce small differences. Measure your noise floor rather than assuming zero.

How big should the golden set be?

Fifty cases is a real suite. Two hundred is comfortable. Beyond that, split it: a small canary subset for frequent runs and the full set for nightly and pre-upgrade runs.

What do I do when a case fails after an upgrade?

Read the output first and decide whether the new answer is actually worse. Sometimes the model improved and your expected output was wrong. Update the golden case deliberately, in a pull request, with a note explaining why.

Who owns the golden set?

Whoever owns the feature, with testers writing most of the cases. Keep it in the same repository as the prompt so a prompt change and its test change land in the same review.