Drift and model monitoring

Production AI, lesson 7

Notice when inputs or quality shift after launch.

You know what to record for every call ("Logs, metrics and traces") and when to page someone ("When to page someone"). It helps to know how a model grader scores answers ("Models as graders" in Evaluation).

Part 1. Three things that drift

A support assistant launched in March. Every week a grader scores a random sample of its real answers, and in March 94% were good. In June it's 86%. Nobody changed the code, the prompt or the help articles.

Something drifted, and there are three usual suspects. The inputs: people ask different things than they did, because of a new product, a new country, or a policy change that floods you with returns questions. The world: facts your answers rely on went stale, so an answer that was right in March is wrong in June. The model: your provider changed what sits behind the model name you call, and it behaves differently.

Input drift and output drift

Input drift is a change in what comes in: topics, length, language, kinds of user. Output drift is a change in what the model sends back: length, tone, refusals, format. Either can come with quality drift, a change in how often answers are right. That's the one that matters, and the hardest to measure.

Providers do change models. Researchers at Stanford and Berkeley put the same questions to GPT-4 twice, three months apart, in 2023. Its accuracy at telling prime numbers from composite ones fell from 84% to 51%, and other behaviour shifted too. Anyone calling the unpinned model name got the later behaviour without changing a line.

Your turn

Graded quality fell from 94% to 86%. The weekly topic mix looks the same as ever, but average answer length jumped 35% on the 12th, and your records show the snapshot the provider reports changed that same day. What's the likely cause?

Two signals changed on one day, and one of them is the model's own id. Inputs didn't move, and stale articles go wrong gradually, not overnight. Check by running your fixed eval set against the old and new snapshots if you can still reach both.

Show the answer

C. Two signals changed on one day, and one of them is the model's own id. Inputs didn't move, and stale articles go wrong gradually, not overnight. Check by running your fixed eval set against the old and new snapshots if you can still reach both.

Part 2. Telling the causes apart

Each suspect leaves different marks, if you recorded them. On top of the per-call record from "Logs, metrics and traces", add a few cheap fields: a topic label for each input (from rules or a small classifier), input length and language, output length, whether the answer refused or broke the format, the ids and last-updated dates of any documents it drew on, and the exact model snapshot the provider says answered.

Keep going with Pro

You've done the first part. Pro opens the rest of this lesson, and every other one.

Still to come

Telling the causes apart
Detectors a small team can run
What a small team actually sets up

See Pro plans I have Pro: sign in

Next lessonHow prompt injection worksText in the input that overrides your instructions. Start lesson 8

Production AI overviewSpotted a mistake? Tell us.

07 · Drift and model monitoring