The four anti-patterns
The mirror of the previous lesson. These are the situations where fine-tuning is the wrong tool, and where most failed projects start.
1. One-off tasks
If you only need a behavior occasionally, prompt engineering is faster, cheaper, and more flexible. Fine-tuning is for repeated, consistent behavior at production frequency.
2. Rapidly changing knowledge
Fine-tuning bakes facts into weights at training time. If your data changes weekly (news, prices, product catalogs, ticket queues), use RAG. The model cannot "unlearn" outdated facts without retraining, and you do not want to be retraining every Tuesday.
3. Tiny datasets (< 50 examples)
Most fine-tuning setups need at least 50–100 examples to see improvement, and 500–1,000 for reliable results. Below 50 examples you usually get one of two failures: no measurable change, or aggressive overfitting that destroys generality.
4. Adding factual knowledge
The most common misconception. Fine-tuning does not reliably teach a model new facts. It teaches behaviors — how to format, when to refuse, what tone to use. For knowledge, use RAG. Trying to teach facts via fine-tuning is the single most common project-failure pattern.
Catastrophic forgetting
The shadow risk that ties them all together: aggressive full fine-tuning can overwrite the model's general capabilities. A model fine-tuned heavily on legal text can become measurably worse at creative writing or basic reasoning. This is one of the deepest reasons parameter-efficient methods like LoRA exist (Track 4) — by updating only a tiny fraction of parameters, they minimize the risk of stomping on the rest of the model.