Bad Reasons to Fine-Tune

Introduction

Last lesson — L185 (Good Reasons to Fine-Tune) — mapped the small set of places where fine-tuning genuinely pays off. This lesson is its shadow: the bad reasons, the ones that make most fine-tuning projects fail — and fail silently. That word matters. A bad fine-tune rarely throws an error. It posts a nice number on your target task, looks great in the demo, and quietly degrades everything else — general reasoning, safety, reliability on real inputs — in ways you won't see unless you go looking.

So this isn't a list of things that crash. It's a list of ways to spend weeks and real money making your system worse while believing you improved it. We'll name each trap, show the evidence, and — because the goal is to make you good at this — give you the fix that turns each bad fine-tune into a defensible one (or into a prompt / a retriever, where it belonged all along).

An infographic titled 'Bad Reasons to Fine-Tune', the third lesson of the fine-tuning container, the counterpoint to the good reasons, showing the expensive traps that make most fine-tuning projects fail silently. The biggest trap is fine-tuning to add knowledge or facts: fine-tuned weights cannot reliably hold facts, they hallucinate far more than retrieval, pattern-match, forget, and go stale the moment a fact changes, so knowledge belongs in RAG, not in the weights. The silent killer is catastrophic forgetting: a fine-tune that posts a twelve-point gain on the target task can quietly degrade general reasoning, undo the base model's safety training, or lose to the base on real production samples, and full parameter fine-tuning produces roughly nineteen point nine percent forgetting versus about zero point six percent for LoRA, a ninety-seven percent reduction, which is why you use LoRA and mix in five to ten percent general instruction data. Too little data is another trap: under a few hundred clean examples there is nothing to learn, the model overfits and invents, and even ten-shot fine-tuning can undo safety. Other traps are skipping prompt engineering, because most we-must-fine-tune problems are a better prompt plus few-shot plus structured outputs; chasing a benchmark for a two-percent vanity gain with no volume and no return on investment that often loses to the base on production samples; trying to fix a fundamental capability gap a weak base model simply does not have; and shipping with no evaluation suite, so the regression is invisible, when a proper evaluation needs four sets, a task holdout, a capability-drift set, a refusal and safety set, and a paired arena against the base on real production samples. The hidden bill is the maintenance treadmill: fine-tune on product specs, ship a product update, and the model confidently quotes the old specs, so you re-train every release, and the hidden costs of data preparation, expert labor, hosting, and monitoring often exceed the infrastructure cost. The fixes are to use RAG for facts, prompt first, choose LoRA over full fine-tuning, mix in general data, and build the four-set evaluation before you train. Earn it with LoRA plus adequate data plus an evaluation, or do not train at all.

Trap #1 — Fine-Tuning to Add Knowledge

The single most common — and most expensive — bad reason: "the model doesn't know our docs / our product / our policies, so let's fine-tune it on them." It feels right. It is wrong, and you already know why from L184 (Prompting vs RAG vs Fine-Tuning: The Decision): fine-tuning changes behavior, not knowledge.

Train a model on your facts and here's what actually happens: it pattern-matches them (so it parrots the shape of an answer, not the truth), it hallucinates far more than RAG when asked anything slightly off the training distribution, it suffers catastrophic forgetting of things it used to know, and it goes stale the instant a fact changes — which, for facts worth knowing, is constantly. Teams routinely burn five figures fine-tuning what a one-line retrieval call would have fixed.

The fix: if you can finish the sentence "the model doesn't know X," that's a retrieval problem. Put X in the prompt (small, static) or behind RAG (large, changing). Knowledge → context, always.

Trap #2 — Catastrophic Forgetting (The Silent Regression)

This is the one that gets good engineers, because the target metric goes up. When you train a model on a narrow task, you're moving its weights toward that task — and away from everything else it knew. The model forgets. A fine-tune that posts a +12-point gain on your task can simultaneously degrade general reasoning, undo the base model's safety training, and lose to the base model on your real production samples — all invisible if you only score the one thing you trained.

How bad? The method decides it. The cleanest controlled numbers in 2026:

Full fine-tuning → ~19.9% forgetting. LoRA → ~0.6% forgetting. A 97% reduction.

Full-parameter fine-tuning rewrites the whole network, so it gets the biggest task gain and the biggest collateral damage. LoRA trains a tiny adapter (≈0.5% of the weights) and leaves the base mostly intact — you keep the general ability and get the specialization. (You'll learn why in L192 (Full Fine-Tuning vs PEFT) and L193 (LoRA & QLoRA Explained).)

The fix: prefer LoRA over full fine-tuning by default; lower the learning rate and epochs; and mix 5–10% general instruction-following data into your training set so the model is reminded of what it must not forget.

Trap #3 — Too Little Data (Overfitting)

"We have 60 perfect examples — let's fine-tune." No. With too few examples there is nothing to generalize from, so the model memorizes your training set: training loss drops beautifully while validation loss climbs, and the model starts inventing confident nonsense on anything it hasn't seen. Overfitting doesn't just fail to help — it actively introduces hallucinations. (Disturbingly, as little as 10-shot fine-tuning can be enough to undo a model's safety training — small data is not a small risk.)

The rule of thumb practitioners converge on: skip fine-tuning under ~a few hundred clean examples — there's nothing for the model to learn that a few in-context examples wouldn't teach it for free. Real behavioral fine-tuning wants hundreds to thousands of high-quality, diverse examples (you'll size this properly in L195 (Data Quality, Coverage & Quantity)).

The fix: if you don't have the data, build it — harvest corrected production traces, or distill labels from a strong teacher (the pattern from L185) — then train. And always hold out a validation set and stop early when its loss turns up.

Traps #4–#6 — Skipping the Prompt, Vanity Gains & No Eval

Three more that share a theme — you didn't earn it, or you can't see it:

#4 — Skipping prompt engineering. Fine-tuning before you've genuinely exhausted a strong prompt, few-shot examples, and structured-output / tool-schema modes. The large majority of "we need to fine-tune" is a better prompt — free, in minutes, with nothing to host or re-train. Climb the cheap rungs first.

#5 — Chasing a benchmark / vanity gains. Fine-tuning to move a leaderboard number +2% with no volume and no ROI. That's a research project, not a shipping decision — and such gains routinely lose to the base model on real production samples once you actually score them side by side. (Related: you can't fix a fundamental capability gap either — if the base genuinely can't reason about your domain, fine-tuning won't install the reasoning; it specializes, it doesn't make a model generally smarter.)

#6 — No evaluation. The most dangerous of all, because it hides every other trap. If you can't measure general ability, safety, and head-to-head-vs-base on production data, you cannot tell whether your +task gain came with a −general regression. A proper fine-tuning eval needs four sets: a task holdout, a capability-drift set (did unrelated tasks regress?), a refusal/safety set, and a paired arena against the base on real samples. One number is a lie (you'll build this in L205 (Evaluating a Fine-Tuned Model)).

Trap #7 — The Maintenance Treadmill (The Hidden Bill)

Even a good fine-tune signs you up for a recurring cost most teams forget to price in. Fine-tune a model on your product specs, then ship a product update — and the model confidently quotes the old specs. Now you re-train every release. The base provider ships a better model? You re-train to move to it (or you're stuck on the old one). Your data drifts? Re-train.

And the sticker price was never the GPU hours. Data preparation is ~80% of the work; add expert labor, a hosted endpoint to serve, and monitoring — the hidden costs routinely exceed the infrastructure cost. A prompt or a RAG index, by contrast, you update instantly, for free, with no training run.

The fix: before you fine-tune, ask "what will make me re-train, and how often?" If the answer is "every time our facts or specs change," you've found a RAG problem wearing a fine-tuning costume.

The Fix: How to Make a Fine-Tune Defensible

Suppose you've cleared the traps — it's a genuine behavior gap (not facts), you've tried the prompt, and you have enough data. Here's the discipline that separates a defensible fine-tune from a silent regression: LoRA, mix in general data, and evaluate on four sets.

# Turn a risky fine-tune into a defensible one.
# 1) Use LoRA, NOT full fine-tuning - ~0.6% forgetting vs ~20% (and ~0.5% of params train).
from peft import LoraConfig
peft = LoraConfig(r=16, lora_alpha=32, target_modules="all-linear")

# 2) Mix 5-10% general instruction data INTO the task data to preserve broad ability.
import random
k = int(0.08 * len(task_examples))
train = task_examples + random.sample(general_instruct_data, k)

# 3) Evaluate on FOUR sets - a single task number is a LIE.
suites = {
    "task":   task_holdout,    # (a) did the target task actually improve?
    "drift":  general_suite,   # (b) did unrelated tasks regress? (catastrophic forgetting)
    "safety": refusal_set,     # (c) did fine-tuning undo safety? (10-shot can!)
    "arena":  prod_samples,    # (d) does it BEAT the base on REAL production inputs?
}
for name, suite in suites.items():
    ft, base = score(finetuned, suite), score(base_model, suite)
    print(f"{name:7} fine-tuned={ft:.2f}  base={base:.2f}  delta={ft - base:+.2f}")

# SHIP ONLY IF (a) is up AND (b),(c),(d) are not down.
# A +12 on the task with -8 on general ability is a REGRESSION you'd have shipped blind.

See It: The Fine-Tuning Failure Lab

Now make the traps happen. Configure a project — pick why you're fine-tuning, drag the dataset size, choose full-FT vs LoRA, and toggle whether you tried a prompt and have an eval. Watch the forgetting number, the overfitting flag, and the traps panel respond. Two moves to try: flip full → LoRA and watch forgetting collapse from ~20% to ~0.6%; and drag the data below 300 and watch it overfit.

Interactive: the Fine-Tuning Failure Lab. The user configures a fine-tuning project and watches it succeed or break live. They (1) pick why they are fine-tuning from five chips, including the facts trap and the vanity-benchmark trap; (2) drag a dataset-size slider from twenty to five thousand examples; (3) choose the method, full fine-tune versus LoRA; (4) toggle whether they tried a strong prompt first; and (5) toggle whether they have an evaluation suite. The results panel shows base-to-fine-tuned deltas: a task-score bar on production data and a general-ability bar that drops by catastrophic forgetting, which collapses from roughly twenty percent under full fine-tuning to under one percent under LoRA, an overfitting indicator that spikes when the dataset is under about three hundred examples, and a train-versus-production gap that opens for the facts trap. A traps-hit panel lights up every bad reason triggered with its one-line fix, and a net verdict states whether the project actually helped on production data, was merely marginal and not worth the re-training treadmill, made things silently worse, or — with no eval — cannot even be measured.

The lesson the Lab makes physical: a fine-tune can show a green task bar and a red general bar at the same time — and with no eval, you only ever see the green one.

Why This Matters

Fine-tuning is the most seductive tool in the kit — it feels like real AI engineering, and the target metric obediently goes up. That's exactly why it's so often a net-negative decision: the cost is paid in invisible places (general ability, safety, the re-training treadmill) while the benefit is loud and narrow. Engineers who know the bad reasons cold don't just avoid wasting a training run — they catch the silent regression before it ships, and they redirect 80% of "we should fine-tune" conversations to a prompt or a retriever in five minutes. That judgment is worth more than the ability to run the training script.

🧪 Try It Yourself

Find the trap in your own backlog. Take any "we should fine-tune for this" idea you've heard (or pick one: "fine-tune so the model knows our latest API docs"). Run it through the seven traps and answer: (1) Is it secretly a facts problem? (2) Did anyone try a strong prompt? (3) Is there 300+ clean examples? (4) Full-FT or LoRA — and what's the forgetting budget? (5) What are the four eval sets? (6) What will force a re-train, and how often? Write the one-line verdict — prompt it / RAG it / LoRA-it-with-an-eval / don't — and the single thing that would change your mind. Then open the Failure Lab above and reproduce your scenario: did it light up the trap you predicted?

Mental-Model Corrections

"The task score went up, so the fine-tune worked." Not until you've checked general ability, safety, and head-to-head-vs-base on production data. A task gain with a hidden regression is a net loss.
"Fine-tuning will teach it our facts." It will teach it to sound like it knows them, then hallucinate and go stale. Facts → RAG.
"More data is always better, but we'll start with what we have (50 rows)." Below a few hundred clean examples you overfit and invent — that's worse than not training. Build the dataset first.
"Full fine-tuning is the 'real', most powerful option." It's also the one that forgets ~20%. LoRA gets the specialization with ~0.6% forgetting — it's usually the better engineering choice, not a compromise.
"We'll fine-tune once and be done." You'll re-train on every spec change, data drift, and base-model upgrade. Price the treadmill before you step on it.

Key Takeaways

Most fine-tunes fail silently — the target metric rises while general ability, safety, or production reliability quietly fall.
The seven traps: (1) adding facts (→ RAG), (2) catastrophic forgetting (full-FT ~20% vs LoRA ~0.6%), (3) too little data (< a few hundred → overfit & hallucinate), (4) skipping the prompt, (5) vanity benchmark gains with no ROI, (6) no eval (the regression is invisible), (7) the maintenance treadmill.
The fixes: RAG for facts; prompt first; LoRA, not full fine-tuning; mix in 5–10% general data; and build the 4-set eval (task · drift · safety · arena-vs-base) — ship only if the task is up and nothing else is down.
Earn it: a defensible fine-tune is a LoRA on adequate data for a genuine behavior gap, with an eval to prove it. Anything else is a prompt, a retriever, or a regret.

Next: L187 — Fine-Tuning + RAG Together (the two aren't rivals — the best stacks combine tuned behavior with retrieved facts), then L188 — Estimating Cost & Effort.