How do you design evals that catch regressions rather than just measuring level?

What happens when a score barely moves the same week one whole kind of ticket quietly stops working?

How to answer this, stage by stage

Nobody is grading whether you can name a metric. They are grading whether you can tell a level apart from a change, out loud, before you've finished your first sentence.

Let's learn

A support team used to read every new ticket by hand and decide two things: what kind of problem it was, and how fast someone needed to look at it. One senior agent did this every morning, about a hundred and fifty tickets before the rest of the team even logged on. She could spot a billing complaint from the first line, almost every time.

Then a tool called TagBridge took over. It reads a ticket the moment it lands and stamps it with an issue type and an urgency level, all six categories, in under a second. It handles about eighteen hundred tickets a day now, more than ten agents used to manage by hand.

Checked every week against six hundred tickets a QA lead grades by hand and holds back from anything the model trains on, TagBridge tags tickets correctly about ninety one percent of the time.

Ninety one percent sounds like the whole story. It isn't. One number can hide six very different stories, one per issue type, and only one of those six actually matters when it breaks.

Say the team swaps in a newer model version, cheaper and a little faster per ticket. The blended score barely moves, ninety one point four to ninety point nine, well inside the normal week to week wobble nobody worries about. Nobody looks twice.

Underneath that one number, billing dispute tickets, the ones where someone says "you charged me twice," fell from ninety five percent tagged correctly to fifty eight. The other five categories actually got a bit better that same week. Averaged together, the good news covered the bad news almost perfectly.

Once the habit sets in, there is no dial left. Only a switch: check the slice, or trust the tile completely.

At its worst, a billing dispute ticket tagged "routine" instead of "urgent, escalate" sits in a two day queue instead of a two hour one. Over eleven days, thirty seven billing tickets sat in the wrong queue before anyone noticed, including one customer charged twice for a twenty four hundred dollar invoice, three days from a public chargeback dispute before a support lead finally called her back.

What I'd leave alone: password reset tickets don't need this. The urgency call there is close to binary and hasn't drifted in over a year. Auditing it every deploy the same way as billing would just take hours away from the category where a miss actually costs someone money.

The lesson: a number can hold dead steady while something underneath it breaks completely. Ninety one percent told the team the tool was fine. It never said whether this week looked like last week, category by category, and that's the only question a regression check actually has to answer.

Now here is the same thing as a story

Read the short version above when you're in the room. Read this one when you want to feel why a quiet week can be the dangerous one.

For two years, Monday mornings at TagBridge belonged to one person and one screen.

Her name is Radha Blackthorn. She built TagBridge's eval pipeline herself, from nothing, two years ago. Hand her a QA report and she can tell you, before her second coffee, whether a number is genuinely fine or just quiet.

For the first year, every single deploy got the full treatment. Radha would pull the per category breakdown, six issue types crossed with three urgency tiers, eighteen cells, and read every one before she signed off. Forty minutes, every time. TagBridge shipped once a month back then, so forty minutes was nothing.

Deploys got more frequent as the team grew confident. Once a week, then twice. Most were small, safe sounding changes, a cheaper model version here, a faster one there, always announced the same way: same eval score, lower cost. Radha kept pulling the full breakdown on anything that touched the tagging prompt itself. On the changes that were "just" a model swap, framed as a pure win, she started skimming the one blended number and moving on. It kept coming back clean. Why wouldn't it.

By the ninth month of weekly deploys, she'd stopped opening the per category view on cost only swaps altogether. Just the one tile: this week's score, last week's score, both fine.

Then TagBridge shipped a model version migration. Forty percent cheaper per ticket. The release note said, in full: same eval score, lower cost, ship it. Blended accuracy that week: ninety point nine, down half a point from ninety one point four, well inside the noise band anyone had ever seen it wobble in. Radha glanced at the tile, same as always, and signed off.

Eleven days later, a support team lead called her directly. A customer had been charged twice for a twenty four hundred dollar invoice. She'd emailed twice, called once, and both times the ticket sat tagged "routine, general inquiry," the forty eight hour queue, when it should have been "billing dispute, urgent," the two hour one. She was three days from filing a chargeback and posting about it.

Radha pulled that one ticket first. Then she pulled every billing dispute ticket from the eleven days since the migration, thirty seven of them, not the handful a weekly sample would have caught. Thirty four were mistagged the same way. Fifty eight percent of billing dispute tickets correct, against ninety five percent the week before.

The other five categories, checked that same afternoon, hadn't gotten worse at all. Four of them had actually improved by two or three points. That's the whole reason the blended score never moved: five categories got a little better, one category collapsed, and averaged together it looked like a quiet, unremarkable week.

The model didn't just cost TagBridge thirty seven mistagged tickets. It cost the retailer that bought TagBridge their trust in the routine tag itself. For the next month, their own support lead had every billing ticket in the routine queue re read by a person before it moved, by hand, the exact work they had bought TagBridge to stop doing.

The habit thinned slowly, over months. Nobody decided to stop. It just tapered.

The flip itself was not gradual at all. One week she checked. The next, she didn't, and never went back.

Two years earlier, when Radha first built the eval pipeline, the team talked for maybe ten minutes about whether to build proper run history, a real comparison between this deploy and the last one. TagBridge shipped once a month then. Someone said Radha herself was the diff, she'd remember what last month looked like without a screen for it. Building a comparison view felt like effort nobody had asked for yet. They shipped the single tile instead: this week's score, refreshed, nothing to compare it to. Reasonable, at one deploy a month. Nobody ever came back to that call as deploys sped up.

Run the same Thursday again, with one change. Every deploy now gets scored against its own immediate predecessor, on the identical six hundred ticket held out set, sliced by category and tier, and any slice that moves more than two standard deviations outside its own trailing month gets flagged red before anyone can sign off. Same model version migration ships. The blended tile still reads ninety point nine, same as before. But the billing dispute cell reads fifty eight percent against a slice that's never dropped below ninety two in a year, thirty four points outside its own noise. Radha sees red before her coffee's cold, holds that one category, and engineering patches the billing tagging examples in the prompt by that afternoon. Zero billing tickets go out mistagged instead of thirty seven. Same trigger. Caught the same day it shipped, not eleven days and one furious phone call later.

One design let a genuine improvement quietly carry a real collapse on its back for eleven days. The other design makes the collapse show up on its own, the same afternoon it happens, no matter how good everything around it looks.

What I'd tell myself, back in that ten minute conversation: the moment an eval covers cases with wildly different costs, ask whether one blended number can still answer for the cheapest case and the most expensive case at once, or whether it only ever could because the expensive case was too rare to move it. Nobody asked. That's on the room, not on Radha, and not on the model.

The five steps, so a quiet number never fools you again

FLIPS, run once on Radha's story. Each letter earns its place, and one of them is genuinely the hard one.

Five steps. Only the I step is genuinely hard to find.

Three things worth stating directly, since this is where the real judgment sits. The first alternative the team almost took after the missed call was doubling review frequency: have Radha pull the full per category breakdown on every single deploy, forever, no matter the cadence. It lost because deploys were already weekly and trending toward daily. That just restores the old forty minute habit at a pace nobody can sustain, a dial turned up, not a decision taken back. The second alternative considered was tightening the blended score's own alert threshold, flagging any weekly move bigger than half a point instead of a point and a half. It also lost: a category that's only nine percent of ticket volume can collapse by thirty points and still barely nudge a blended average past even a tight global threshold, so the fix has to be structural, per category tracking, not a smaller global number. The AI specific failure worth naming by name is silent regression from a model version migration: a newer model can be genuinely, measurably better on average while quietly breaking one specific, low volume, high stakes slice of its own behavior, because nothing about "the aggregate benchmark held" guarantees uniform behavior across every kind of input underneath it. The guardrail is the same predecessor, per category diff with a trailing noise band, checked on every deploy, not just the risky looking ones. That guardrail isn't free. It means twelve dashboards to watch instead of one, and roughly twenty extra minutes of compute a deploy running the fixed set through both model versions, a real cost accepted on purpose, weighted toward the categories where a miss is actually expensive, not spread evenly across all six.

And if you want to be sure it really works, try it somewhere else

Same five steps, a law firm's intake room, nothing about customer support anywhere in sight.

CaseFlag is a tool an immigration law firm uses to read incoming case documents and tag them by visa type and urgency, with a special flag for asylum and detention cases that need expedited handling. Zafar Grieve is the senior paralegal who used to read every incoming document himself, and who decides how CaseFlag's tags get used now.

The case for the blended score: CaseFlag ran for eight months with a single weekly accuracy tile, and it held between ninety and ninety three percent the entire time. Zafar handed the day to day tagging fully to it and moved his own attention to case strategy instead.

The case against it: a routine model update, framed as a formatting fix, quietly dropped the expedite flag recall on asylum cases from ninety six percent to sixty one, while the much larger general visa inquiry category improved enough to hold the blended score at ninety one, barely different from the week before.

Zafar didn't taper off checking the way Radha did. He handed it down whole, then took the whole category back at once.

Same five steps, a different flip. Zafar didn't stop checking gradually. He'd fully handed the tagging down the day CaseFlag launched, the way a senior lawyer delegates to a trusted junior. When the expedite flag miss surfaced, three weeks later, in a case that nearly missed a court filing deadline, Zafar didn't just start spot checking again. He reclaimed the entire asylum category by hand, on top of his existing caseload, because he no longer trusted CaseFlag's word on it at all. Two people were now doing the tagging one tool was supposed to do alone.

Same rank as before: score every deploy against its last one, sliced by category, and let the rare, expensive slice fail loud on its own. A blended tile that held steady for eight months proved nothing about the one category with the least room for error.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the fix, diff every deploy against its predecessor, sliced by category, on the same fixed set.
Cost: there's no budget this quarter for both the sliced eval and a flashier top line dashboard. The sliced eval wins every time. A clean looking average that's hiding a collapse is worse than an honest, ugly one.
The model got better, for real: say the new version genuinely improves the blended score. That's not proof every slice improved with it. A model can get better on average while the slice that costs the most stays exactly as broken as before, or gets worse.

Where people run it wrong.
They read a flat or rising average as proof nothing's wrong anywhere, and never ask what it's built from.
They fix a scare by widening the acceptable noise band instead of narrowing what they're measuring.
They treat "the fix was small" as a reason to skip the slice check, when small fixes are exactly the ones nobody re verifies.

How to use it live. Say the tension out loud before answering: "is this asking me for a threshold, or for a way to catch what a threshold can't see." That buys a beat to think instead of guessing out loud in front of the interviewer.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0