Part 9 — Continuous Evaluation

Regression suites

The safety net·Evaluation·6 min read

Evaluation isn't a one-time gate — it's a suite you run on every change, forever. The regression suite is the safety net that stops fixed bugs from silently returning: a growing set of test cases, heavy with past failures, run automatically so a change can never quietly break what used to work.

Everything before this part treated evaluation as something you do — build a dataset, score a system, analyse failures. This part treats it as something you run continuously, because an LLM system is never finished: prompts change, models get swapped, guardrails get added, and every one of those changes can silently break something that used to work. The regression suite is the defence — an evaluation you run on every change, built so that any fixed bug that tries to return is caught before it ships.

What you will understand by the end

  • What a regression suite is and why continuous systems need one.
  • Why it should be heavy with past failures, not just fresh cases.
  • How it turns root-cause analysis into a permanent safety net.
  • Why "it passed before" is not a guarantee without one.

Every change can break what worked

An LLM system's behaviour is diffuse — it lives in prompt wording, model weights, decoding settings, and correction rules, all interacting. So a change made to fix one thing routinely breaks another, often somewhere unrelated: a prompt tweak that fixes extraction degrades classification, a guardrail that helps one model regresses another. Without a suite that re-checks the old cases, these regressions ship invisibly and you discover them from users.

Key idea

A regression suite is a fixed set of test cases run on every change, so no change can silently break behaviour that previously worked. It converts "I hope this didn't break anything" into "the suite says it didn't." For a system whose behaviour is spread across prompt, model, and policy, it is the only way to change anything with confidence.

Build it from past failures

A regression suite is not just a representative sample — it's a memory of every bug you've ever fixed. The most valuable cases in it are the ones that once failed:

  • Each root-caused failure becomes a permanent case, with its correct answer, added to the suite.
  • Each boundary the system slipped on becomes a case that pins that distinction.
  • Each guardrail regression becomes a case that guards the cases the rule shouldn't touch.

This is what makes the suite grow along the dimensions your system actually fails on — it accumulates exactly the tests that matter, because each was born from a real failure. A fresh representative set tells you current quality; the regression suite tells you that yesterday's fixes still hold.

Watch out

"It passed the last eval, so this small change is safe" is exactly the assumption regressions exploit. Behaviour you didn't test isn't protected, and the change you think is small touches shared prompt/model state that affects unrelated cases. Only a suite that re-runs the old cases on every change can license "safe" — intuition can't.

Run it automatically, on every change

A regression suite only works if it runs without anyone remembering to run it — wired into the change process so a prompt edit, a model swap, or a policy tweak automatically re-runs it. A suite you run "when you remember" protects nothing, because the changes that break things are exactly the ones that felt too minor to bother testing. Automation makes the net always-on.

Observed evidence

This project's discipline of changing one knob per experiment and re-measuring is a regression suite in miniature: every configuration change was re-scored on the same fixed 88-task set, which is exactly how the 7B guardrail regression was caught instead of shipped — the suite re-ran the old cases and showed the rule broke ones that previously passed. Scale that habit to run automatically on every change and you have a regression suite. See the re-measured cases that caught the regression →

Mental model

A regression suite is an always-on evaluation run on every change, built from a memory of every bug you've fixed. Fresh data measures today's quality; the regression suite guarantees yesterday's fixes still hold. Automate it, feed it every root-caused failure, and "small safe change" becomes a claim the suite can actually check.

Common mistakes

  • No regression suite. Every change risks silently breaking working behaviour, discovered only from users.
  • Only fresh cases, no past failures. You measure current quality but don't protect the bugs you already fixed from returning.
  • Running it manually. The changes that break things are the ones that felt too minor to test; automation is what makes the net real.
  • Never growing it. A static suite protects a shrinking fraction of behaviour as the system evolves.

Practical guidance

  • Add every root-caused failure to the suite as a permanent case with its correct answer — the suite should accumulate your bug history.
  • Wire it into the change process so it runs automatically on every prompt, model, or policy change — never on memory.
  • Include regression-guard cases: previously-passing inputs a new guardrail shouldn't touch, so regressions surface immediately.
  • Treat a new failure that slips through as a gap in the suite — add it, so it can't recur.

Summary

  • A regression suite runs on every change so nothing that worked can silently break.
  • Its most valuable cases are past failures — it's a growing memory of every bug you've fixed.
  • It turns root-cause analysis into a permanent safety net and must run automatically.
  • This project's re-measure-every-change discipline is a regression suite in miniature — it's what caught the 7B guardrail regression.

Knowledge check

You fix a failing boundary case and the fix works. Root-cause analysis is done. What's the one more step that makes the fix durable?

Add the failing case — the exact input with its correct answer — to the regression suite as a permanent test, run automatically on every future change. Without that, a later prompt tweak or model swap can silently reintroduce the same failure and you'd never notice until users hit it. The fix isn't durable until the suite is guarding it; that's how each root-caused failure becomes a permanent protection rather than a one-time patch.

Why should a regression suite be weighted toward past failures rather than just being a fresh representative sample?

Because a fresh representative sample measures current quality, but the regression suite's job is to guarantee that yesterday's fixes still hold — and the cases most likely to silently break are precisely the ones that were hard enough to fail before. Past failures pin the exact distinctions, boundaries, and guardrail-sensitive cases your system has historically gotten wrong, so the suite grows along your real failure dimensions and protects the behaviour that's actually fragile.

Related chapters