Title: Lecture 10 — Evaluating Fine-Tuned Models and Detecting Overfitting
Course: AIINFRA 201: Model Adaptation — Fine-Tuning & Quantization > Section: Week 10 — Evaluating Fine-Tuned Models and Detecting Overfitting

📖 Lecture — Evaluating Fine-Tuned Models and Detecting Overfitting

Back in Week 5 you fine-tuned a model. The natural next question is: did it actually get better? It is tempting to reach for one number and call it done, but a trustworthy answer takes a small investigation. This week builds the habits of that investigation. Why perplexity is not enough. Perplexity measures how well a model predicts held-out text — literally, how "surprised" it is by the next token. It's cheap to compute and useful as a sanity check, but for instruction-tuned (chat) models it can actively mislead you. A model can achieve very low perplexity on your evaluation text simply because it has memorized phrasing that closely resembles its training data, not because it reasons better or follows instructions more reliably. Perplexity says nothing about whether a model refuses appropriately, follows multi-step instructions, reasons correctly through a math problem, or avoids unsafe outputs — the behaviors that actually matter in production. Treat perplexity as one weak signal among many, never as your headline metric for a chat-tuned model. Reading the overfitting signature. The most important diagnostic you'll build this week is the training-loss vs. validation-loss curve. In a healthy training run, both curves fall together, then validation loss levels off while training loss keeps dropping slowly. In an overfit run, validation loss stops improving and then rises while training loss keeps falling — the model is increasingly memorizing specific training examples rather than learning generalizable patterns. That inflection point, where the two curves diverge, is the moment you should have stopped training (or where you should roll back to an earlier checkpoint). A two-sided evaluation, not a one-sided one. Rigorous practice separates evaluation into two questions, both answered with EleutherAI's lm-evaluation-harness so the numbers are directly comparable across models and runs:

Question | Example benchmarks | What it tells you
Did the target task actually improve? | GSM8K (math fine-tunes), or your own custom task | Task-specific gain
Did general capability regress? | HellaSwag, WinoGrande, ARC-Challenge | Forgetting / regression

A common recommended structure uses four evaluation sets in total (a training-adjacent holdout, an independent task-improvement set, and two or more general regression sets), combined with bootstrap statistical testing and a CI gate written into your evaluation code. The ship decision follows a simple rule: only ship if regression sets hold steady AND at least one genuinely independent improvement set shows a statistically meaningful gain. Improvement on a training-adjacent holdout alone is weak evidence — that holdout is drawn from the same distribution as your training data, so gains there can just as easily reflect memorization as real skill. Contamination can lie to you in either direction. Benchmark contamination happens when evaluation questions (or close paraphrases) leaked into training data, intentionally or not. Contaminated benchmarks can produce inflated scores that look like real improvement but aren't — and counterintuitively, scores can keep climbing as contamination increases, making a model look more capable while its true generalization is unchanged or worse. This is why comparability matters: running base and fine-tuned models through the identical harness and task set, and cross-checking against benchmarks you're confident weren't in your training mix, is your best defense against being fooled by a leaderboard number. Correcting the misconceptions. First: perplexity is not the primary metric for judging an instruction-tuned model. It doesn't capture instruction-following, reasoning quality, or safety behavior — the things users actually experience — so use it only as a supporting signal alongside task benchmarks. Second: a high score on one benchmark, especially a training-adjacent holdout, does not prove your fine-tune worked. Rigorous evaluation always pairs task-specific gains with regression testing on general benchmarks, because a model can win narrowly on your target task while quietly losing broad capability — and you won't know unless you check. Put together, this week's lab turns these ideas into a repeatable workflow: score both models with lm-eval-harness, compute deltas, and visually locate the overfitting inflection point in your Week 5 training logs.