Join the community of Machine Learners and AI enthusiasts.
Sign Up
I want to clarify that obviously still we need to generate with the best models we have but evaluate the batches manually be it 100 or 1000. Even if it's a quick read over examples. Never EVER let an AI generate without rails. I was too confident on frontier models outputs just to get dissapointed later.
Reading examples one at a time catches the wrong rows. It can't catch the templated ones.
Per-example review measures validity. Template collapse is a between-rows property: every row is individually fine and the batch still spans only three skeletons. You can read 1000, feel good, and miss it, because the flaw lives in the distribution, not in any single example.
So the rail isn't a quality read. It's a diversity number. Parse each row down to its skeleton, count distinct skeletons, watch the entropy across the batch. Low entropy over 100k rows means the model learns the skeleton and not the range. That IS "looks like templates," measured.
And it's not really a model-quality failure. A frontier model under one fixed prompt falls to its modal phrasing every time. The lever is prompt variance, not a better generator.
What does the distinct-skeleton count look like on your worst batch?
I think we agree more than it seems. I am not saying manual review should replace diversity metrics.
Skeleton counts and entropy are useful, but they only catch what the parser measures. A batch can have many distinct skeletons and still repeat the same reasoning, tone, difficulty, or task patterns.
My point is to catch that early, while the batch is still small enough to change the prompts or generation strategy. After 100k rows, deduplication cannot recover the missing diversity.
The safest rail is both: batch-level diversity metrics and periodic human review.
Agreed on the trap. The fix is not a human though, it is a metric that sees semantics instead of syntax.
A skeleton count reads structure. Two rows with different skeletons can be the same task in different nouns, and the parser scores that as diversity when it is not. You are right that the instrument only measures the axis it was built for. But a human reading the batch has the same blindness one level up. You can feel that row 40 and row 900 rhyme, you cannot hold the task-type distribution of 100k rows in your head. Reading measures per-row validity. It never measures between-row spread, no matter how many rows you read.
So move the metric off syntax. Embed every row, cluster in embedding space, count effective clusters instead of skeletons. Or self-BLEU, or n-gram entropy at the reasoning-step level rather than the surface. Now many skeletons, one reasoning pattern shows up as one fat cluster, measured, with nobody eyeballing anything.
Where the human is irreplaceable is calibration, not coverage. Read 50 rows once, decide which metric actually moves when the failure you care about is present, then let that metric scale to 100k. Human picks the axis. The number does the counting.
And your early-catch point is the real rail. Run the metric you picked on the first 1k and treat it as go/no-go on the prompt strategy, before you spend the generation budget. It fires while you can still change the prompt, which is the whole game.
Which axis of collapse bit you worst, reasoning or difficulty?
