AI, for real

Silent regressions: why your AI quietly gets worse (and how to catch it)

Same model name, same prompt, completely different behaviour. Stanford researchers watched GPT-4 go from 97.6% to 2.4% on one task. Here's the cheap weekly habit that catches drift before your users do.

This is the companion article to the AI, for real Short. Watch it on YouTube (@ai4real-chelvas).

Here's a scary thought. Your AI was working fine last month. Today it's quietly giving worse answers, and nobody told you.

That's a silent regression. Nothing crashed. No error was thrown. Your dashboards look totally normal.

Why it happens

AI behaviour depends on more moving parts than most code:

The model gets updated. Hosted model names often point to a moving target.
Your prompt changes. A one-word edit can shift behaviour across thousands of conversations.
A library gets bumped. New SDK defaults, a new tokenizer, a changed retrieval setting.
Your data changes. New documents in your knowledge base change what gets retrieved.

Traditional monitoring watches uptime, error rates and latency. A silent regression moves none of them. The system is healthy; the answers are worse.

It's real: the Stanford GPT-4 study

Researchers from Stanford and UC Berkeley evaluated the March 2023 and June 2023 versions of GPT-4 on the same tasks. On identifying prime numbers, GPT-4's accuracy went from 97.6% in March to 2.4% in June, with the same model name and the same questions (Chen, Zaharia & Zou, arXiv:2307.09009). Their conclusion: the behaviour of the "same" LLM service can change substantially in a short time, so it needs continuous monitoring.

Princeton's Arvind Narayanan and Sayash Kapoor later argued this didn't show GPT-4 got less capable: its default answer to "is this prime?" seems to have flipped from "yes" to "no" after fine-tuning. But they agreed on the part that matters for you: routine fine-tuning can cause drastic behaviour changes on some tasks (Narayanan & Kapoor). Capability or behaviour, your users get the wrong answer either way, and only measurement tells you it happened.

The fix costs almost nothing

Save a small set of test cases with known good answers. Twenty to fifty real questions from your users, each with the answer you've checked is correct. Include the failures you found in EP 1.
Run them every week, and on every change: model version, prompt edit, dependency bump, knowledge-base update.
Track the score over time. If it drops, you catch it before your users do.
Pin what you can. Use dated model snapshots where your provider offers them, version your prompts, and treat a prompt change like a code change.

A small test set, run on a schedule, is the whole game.

Tools that help

You can do this with a spreadsheet and a script. Open-source tools make it easier: Langfuse datasets let you store test cases and run experiments against them; promptfoo runs prompt test suites from the command line and in CI. For the full tool landscape, see the EP 3 tools guide.