What role does the golden set play in a migration decision?
- Build the golden set stratified by disease category, with its own minimum count per category, not one flat sample.Why: an average accuracy number can look great while quietly hiding a category the new model barely handles.
- Weight the minimum count toward severity, not toward how common the disease actually is.Why: a disease that only shows up a dozen times a season can still wipe a field, and daily-volume sampling would give it almost no examples at all.
- Refresh the golden set continuously through the parallel run, not once before cutover.Why: a set built before the migration started can't catch a category the new model happens to be weak on, if nobody was already looking for it.
- Hold back a slice of the golden set that never touches training or prompt-tuning.Why: a set the team can see while tuning stops being a real test and starts being a target.
- Require an agronomist to confirm every label by hand, never auto-generated from either model's own output.Why: letting an unverified model's guesses feed the set it gets graded against quietly lowers the bar it has to clear.
- Report accuracy per category on the migration dashboard, not as one blended number.Why: the blended number is exactly what let a weak category hide the first time this was tried without a real golden set.
How to answer this, stage by stage
Nobody is grading whether you can define "golden set" from a textbook. They are grading whether you can design one that would actually catch a rare, dangerous failure before it reaches a farmer's field. Six moves get you there.
Let's learn
Say we build a model that looks at a photo of a maize leaf and names the disease on it. Before AgroLens existed, an extension agent had to recognise the disease by eye, or drive a sample two hours to a regional lab and wait a week for results. By the time the answer came back, a treatable disease had often already spread past the point where treatment helped.
Then AgroLens went live with Husk, its first diagnosis model. Point a phone at a leaf, get a likely disease and a recommended treatment in under two seconds. Region-wide accuracy sat around ninety-one percent on the mix of diseases agents actually see most often: common blight, rust, gray leaf spot. Extension agents stopped guessing and started treating fast.
Now AgroLens is migrating from Husk to Tassel. Tassel is a bigger model, trained on a wider mix of diseases, and on the common categories it's clearly better, catching leaf diseases Husk sometimes missed. But "clearly better on average" is not the same claim as "clearly better on every category," and that gap is exactly where a migration goes wrong. Maize streak virus is rare, only about fifteen confirmed cases a week across the whole region, but it's also one of the most destructive diseases a smallholder farmer can face, capable of cutting yield by half if treatment starts even a week late.
Say plainly: the extra accuracy Tassel picks up on common diseases is not the real problem. The real problem is that streak virus is such a small slice of total photo volume that a single blended accuracy number could look wonderful while Tassel is quietly worse on exactly the disease that can least afford to be missed.
At its worst, Tassel goes live region-wide having been checked against maybe four or five confirmed streak virus photos, the natural share it would get from a flat, unstratified sample of forty thousand weekly photos. If Tassel turns out to miss streak virus more often than Husk did, that gap won't show up in the aggregate number, and the first sign of trouble will be a farmer's field, weeks later, past the point where treatment still works.
The choice I would take back. When Tassel's migration was first scoped, the golden set was built by pulling a random one-percent sample of the last month's photos and having an agronomist confirm the labels. That felt rigorous. It also meant the set's category mix matched daily photo volume exactly, which is precisely wrong for a model check: it gave the golden set almost no examples of the diseases that matter most and can least afford to be missed.
What I would leave alone. AgroLens also runs a much lower-stakes model that suggests the best time of day to spray fungicide based on humidity forecasts. A flat, unstratified sample is genuinely fine there, because every outcome in that category is roughly as costly as every other, there's no single rare case that can wipe out a season on its own.
The lesson. A golden set that mirrors daily volume will always be dominated by what's common. If the thing you actually can't afford to get wrong is rare, the golden set has to be built around that fact on purpose, or it will quietly never test it at all.
Now here is the same thing as a story
The short version is above. Read on if you want to feel why a ninety-four percent accuracy number almost hid a real problem.
Rohan Trench has run AgroLens' model roadmap for two years, and he built the first golden set discipline the company ever had, back when Husk shipped. He's the one people trust to say whether a model is actually ready, not just impressive on a demo.
When Tassel's evaluation results came back, the number on the slide was ninety-four percent, up from Husk's ninety-one. The room was ready to approve cutover on the spot. Rohan wasn't, because he knew exactly how that ninety-four percent had been built: a random sample of last month's photos, confirmed by an agronomist, but sampled in proportion to how often each disease actually showed up.
He asked one question before anyone signed off: how many confirmed streak virus examples were actually in that evaluation set. The answer was four. Four photos, out of nearly four hundred in the whole golden set, deciding whether Tassel was trusted on the single disease capable of cutting a smallholder's yield in half.
Rohan paused the cutover and asked the agronomy team to pull every confirmed streak virus photo from the last six months of AgroLens' archive, plus new ones collected specifically for this migration, rather than waiting for enough to show up naturally in the normal weekly volume. It took nine days to gather sixty confirmed examples. On that stratified slice, Tassel's accuracy on streak virus specifically was seventy-eight percent, well below Husk's eighty-nine.
Tassel had learned the common diseases better and the rare, severe one worse, and nothing about the original ninety-four percent number would ever have shown that, because streak virus made up such a tiny share of daily volume that even a real regression in it barely moved the blended average.
What stayed with Rohan wasn't the seventy-eight percent number itself, it was how close the team came to shipping Tassel on the strength of a number that had never actually been tested on the case that mattered. At the kickoff meeting, someone had proposed stratifying the golden set from the start. It was set aside as extra process for a migration already running behind schedule. Nobody argued against it directly, it just lost to the calendar.
The second version of the golden set discipline sets a category-specific minimum, sixty confirmed examples for any disease capable of a yield loss over thirty percent, refreshed every two weeks through the parallel run instead of frozen once at the start, with a held-back slice the modeling team never sees while tuning. Run the same Tassel migration through that design and streak virus's real gap gets caught in the first evaluation cycle, not nine days into an emergency pause after the fact.
The thing Rohan would tell his past self, back at that kickoff meeting: an evaluation set that mirrors normal volume will always test what's common. If what you actually can't afford to get wrong is rare, you have to go build the set for it on purpose, because it will never show up on its own in time to matter.
SPARK, in one screen
This is a design question about how to build the migration's own validation gate, not a story about a person's habit flipping, so SPARK fits and FLIPS doesn't.
S, situation. Before this discipline existed, a migration decision got made off one evaluation set, sampled in proportion to daily photo volume and confirmed by an agronomist, then reduced to a single blended accuracy number. That number decided whether the new model shipped region-wide.
P, payoff. The habit we want the team to build is checking every disease category on its own, not the region-wide average. We considered leaving the golden set as a single flat sample and just watching the blended number more closely, and rejected it: watching a number more closely doesn't change what that number is capable of showing, and a rare category can move by forty percentage points without visibly denting an aggregate built mostly from common cases.
A, anchor. Stratify the golden set by disease category. Set a real minimum confirmed-label count for each category, weighted by how severe a miss would be, not by how often the disease shows up in a normal week. Streak virus gets sixty confirmed examples on purpose, not the four it would earn from a flat one-percent sample of forty thousand weekly photos.
R, risk. The first time this design is wrong, it's because the minimum count for some category turns out too low to catch a real regression, or a rushed migration timeline pressures the team into shrinking it. The fix isn't a bigger number picked once, it's making the minimum a real gate that blocks cutover on its own, not a target that can quietly slip under deadline pressure.
K, keep out. Deliberately not automating golden-set growth from live production traffic and either model's own confident output. That would let an unverified model's guesses feed the bar it's graded against, and the labeling stays slower and human-confirmed on purpose, even though it costs agronomist hours every week that an automated pipeline wouldn't.
One more thing worth naming: precision by category gets tracked for the full parallel run, not just at the evaluation gate before cutover. Tassel matching or beating Husk once, in one evaluation cycle, isn't the bar. It has to hold for several consecutive cycles on every category, because a model can pass a single evaluation by chance on a small, rare-category sample and still be genuinely worse in the field.
And if you want to be sure it really works, try it somewhere else
Isthmus Library Network is migrating the model that auto-tags incoming donated books with subject and genre labels, from an older classifier to a newer one that's meaningfully better on the library's most common categories: fiction, biography, general nonfiction.
S, situation. Isthmus' current evaluation set is a random sample of last quarter's donated books, labeled by a cataloguer, weighted naturally toward whatever categories get donated most. Fiction and biography dominate it, the way they dominate real donations.
P, payoff. Cosimo Provost, the PM running this migration, wants the team checking accuracy per subject category before cutover, not one blended number across the whole donation mix.
A, anchor. Stratify the golden set by subject category, with a real minimum for categories that are rare in donations but high-stakes to mislabel, government documents and legal reference chief among them, since a mistagged legal reference can sit undiscovered in the wrong section for years.
R, risk. If government documents and legal reference stay under-sampled, the new classifier could quietly mistag them more often than the old one while the blended accuracy number, dominated by fiction and biography, still looks like an improvement.
K, keep out. Not auto-expanding the golden set from the new classifier's own confident guesses on unlabeled donations, for the same reason as at AgroLens: an unverified model's output shouldn't get to define the bar it's judged against.
Swap the trigger and it still runs.
Speed: an interviewer caps the answer at ninety seconds. Skip straight to the anchor: stratify the golden set by category, weight the minimum toward severity, refresh it continuously, gate on every category separately.
Cost: the agronomy team can only confirm labels part-time this quarter. Don't shrink the rare-category minimum to fit the budget, shrink the common-category oversampling instead; the common categories already have plenty of naturally occurring confirmed examples.
The model got better: Tassel turns out to beat Husk on every category, including streak virus. That doesn't make the stratified design unnecessary, it just means the gate confirms what everyone hoped, instead of assuming it.
Where people run it wrong.
They build the golden set as a random sample and mistake "random" for "unbiased," when a random sample of real-world volume is biased toward whatever's common, by definition.
They freeze the golden set once, before the migration starts, so it can never catch a category the new model turns out to struggle with that nobody expected.
They let a blended accuracy number stand in for the real question, whether every category the product actually depends on cleared its own bar.
How to use it live. Say the anchor before naming a single number: "the golden set has to be built to catch the category that's rare and expensive to miss, not the category that's common and already safe." That buys the room to ask what's actually rare and severe in this specific product, instead of reciting a generic testing checklist.
Flashcards (click a card to flip it)
Check yourself Score: 0 / 0
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
Show hint
Show answer
"Won't a held-back slice just be extra labeling cost with no immediate payoff?" Response: the payoff is exactly what almost got missed here, a set the modeling team can see while tuning stops being an honest test, so the small ongoing labeling cost buys the one thing a visible set can't: a number nobody could have quietly optimized toward.
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
- A live AI agent you actually shipped
- A launch decision you can defend under pressure
- An interview-ready portfolio, not more flashcards
More on Model migration and version changes for users
- #1 Your provider deprecates the model behind your main feature in 60 days. Write the plan.
- #2 How do you test a replacement model against the behaviour users have come to expect?
- #3 Explain why a strictly better model can still be a bad migration.
- #4 What should you tell users when model behaviour changes underneath them?
- #5 Describe a dual-running strategy for a model migration.
- #6 How do you handle customers who tuned their prompts to the old model?