← Exercises|

Diagnose: the evaluation that was too good

Diagnose25 of 26 · about 10 min

Diagnose: the evaluation that was too good

A routing model scored 94% on the holdout set, up from 71%. Nobody could reproduce the improvement in the pilot. The model had not improved; the evaluation had broken.

Tickets were sampled into a development set and a holdout set — but the same ticket appears more than once in the export, and the near-duplicates went to different sides. A case the model was tuned against was also a case it was graded on.

Leakage is not usually dramatic. It is one join, one resample, one helpful person topping up the dev set from the same pool. The defence is a check that runs every time the sets are built, not care.

Example

overlap = set(dev_ids) & set(holdout_ids)
assert not overlap, f"{len(overlap)} tickets are in both sets"

One assertion, run on every build of the datasets. It is worth more than the rest of the harness.

Your task

Write leakage_report(dev, holdout) returning a tuple (shared_ids_sorted, adjusted_score) where the adjusted score is accuracy over the holdout rows that are NOT shared. Print the shared ids, the raw score and the adjusted score, each as a percentage with no decimals.

Stuck?

Explain it

The adjusted score is worse than the score you had before the model changed. What do you put in the release recommendation?

Not graded — this is for you.

Where this goes

D7 is the evaluation harness and D8 the release recommendation. Reproducibility is assessed directly: a result nobody else can reproduce does not count as evidence.