A friend of mine joined a law firm after five years in journalism. She already knew how to write — brilliantly. What took her three months was learning that this firm ends every advisory note with a one-paragraph risk summary, never uses the word "obviously", and cites clauses in a particular order. Nobody taught her to write. They showed her a hundred old notes.
That is fine-tuning, and this lesson is about what happens under the hood — with no gradient mathematics, because no placement interview has ever asked for it.
What actually changes
A model is a very large set of numbers — its weights. Everything it can do is encoded in them. Pretraining set those numbers by reading an enormous amount of text; that step costs millions and is already done.
Fine-tuning is continued training from that finished checkpoint. You show it your examples, it predicts, it's wrong by some amount, and the weights are nudged to be slightly less wrong next time. Repeat a few thousand times and the model has drifted toward doing your task your way.
Two consequences worth stating plainly. Nothing about the prompt or the context window changes — you get a different model, not a different configuration. And that model is a new artefact you now have to version, evaluate, serve and eventually retire.
Where fine-tuning sits
| Stage | What happens | Who does it |
|---|---|---|
| Pretraining | learns language and world knowledge from a vast corpus | model labs — millions of dollars |
| Instruction tuning | learns to follow instructions from (instruction, response) pairs | model labs — this is what makes it a usable assistant |
| Preference tuning | learns which of two responses people prefer | model labs — shapes helpfulness and safety |
| Your fine-tune | learns your task, format and voice from your examples | you — hours on one GPU |
Note where you start: from an already instruction-tuned model, not a raw base one. That is why a few thousand examples can be enough — you are adjusting a finished professional, not teaching a beginner.
Epochs, loss, and the curve
Two words you need, both simple.
Loss is a number measuring how wrong the model's predictions are. Lower is better, and it should fall during training.
An epoch is one complete pass over your training set. Two epochs means the model saw every example twice.
You always split your data: most of it to train on, a validation slice held out and never trained on. The model's loss on the training data tells you how well it is memorising. Its loss on the validation data tells you whether it is actually learning. Those diverge, and the gap is the whole story.
Overfitting
Training loss keeps dropping — it always will, given enough epochs, because the model can simply memorise. Validation loss bottoms out and then climbs, because a memorised model does worse on anything it hasn't seen.
The checkpoint you want is where validation loss was lowest. Everything after it is damage that looks like progress on the training number.
Practical defences: few epochs (1–3 is typical), early stopping on validation loss, a lower learning rate, more and more varied data, and parameter-efficient methods like LoRA that give the model less capacity to memorise with.
💡 If loss collapses toward zero within a handful of epochs, that is rarely good news. It usually means too few examples, duplicated examples, or a learning rate that is too high.
Wait — can it get worse at things it could already do?
Yes, and this is the failure that surprises teams after launch. It is called catastrophic forgetting.
Training hard on a narrow dataset pulls the weights toward that dataset — and away from everything else those weights were encoding. A model tuned aggressively on 500 legal summaries may become noticeably worse at ordinary conversation, at arithmetic, at your second market's language, or at refusing things it should refuse.
The dangerous part is that your task eval set will not show it — it only tests the new task, which improved. The regression surfaces in production, as "the answers got weird".
Mitigations, in order of usefulness: use LoRA so the original weights are frozen; train for fewer epochs at a lower learning rate; mix some general examples into the dataset; and — non-negotiably — evaluate general capability separately before and after (lesson 7 gives you a compact probe set).
SFT vs preference tuning
Two names that come up in interviews.
Supervised fine-tuning (SFT) trains on examples of the right answer: input → the exact response you want. It needs a gold answer for every input, and it is what almost every practical fine-tune means.
Preference tuning (RLHF, and the simpler DPO) trains on comparisons: this response is better than that one. It only needs someone to pick a winner, which is far cheaper to collect and works for qualities you can't write down — helpfulness, tone, tactfulness.
For placement purposes: know that SFT teaches by imitation, preference methods teach by ranking, and preference tuning is mostly done by model labs rather than by application teams.
Why it's bad at facts
Lesson 1 asserted this; here is the mechanism. Fine-tuning adjusts weights toward producing certain kinds of text. If your examples all contain a fact, the model becomes more likely to produce that fact — but it has no index, no lookup, and no source. It may half-remember, blend two facts, or state a superseded one confidently.
# A training example like this:
user: "Where is my order?"
assistant: "Order ORD10024 is in transit, arriving 5 Sep."
# does NOT teach the model about order ORD10024.
# It teaches: "when asked about an order, confidently state an
# order id, a status and a date."
#
# In production, with no order data supplied, that is a
# hallucination machine — and you trained it on purpose.This is the single most common dataset bug, and lesson 3 is largely about avoiding it: every example's response must be derivable from that example's input.
🎯 Selection-round radar: "What is catastrophic forgetting?" and "what is overfitting in fine-tuning?" are both common. Answer overfitting with the curve — train loss down, validation loss up, so take the validation minimum — and forgetting with the consequence: it loses general ability, and a task-only eval set is blind to it, so I'd run a general-capability regression set too.
Common mistakes
- Judging a run by training loss alone.
- Running many epochs because "more training is better".
- No held-out validation set, or one that leaks near-duplicates from training.
- Only evaluating the new task, so forgetting goes undetected.
- Expecting facts in the training data to become reliable knowledge.
- Confusing fine-tuning with pretraining in an interview answer.
Quick recap
| Concept | One-liner |
|---|---|
| Fine-tuning | continued training from a finished checkpoint; the weights change |
| Epoch | one full pass over the training set; 1–3 is typical |
| Overfitting | train loss down, validation loss up — take the validation minimum |
| Catastrophic forgetting | general ability degrades; invisible to a task-only eval set |
| SFT vs preference tuning | imitate a gold answer vs learn from "this one is better" |
| Facts | blended into weights: unsourced, staleable, sometimes half-remembered |
Practice Zone — PYQs from real selection rounds
Six MCQs, then two tasks: read a real training log, and explain fine-tuning to a non-technical stakeholder.
What does fine-tuning actually change?
Asked in
What is 'instruction fine-tuning'?
Asked in
What is catastrophic forgetting?
Asked in
What does an 'epoch' mean in fine-tuning, and why do too many hurt?
Asked in
Which statement about fine-tuning and knowledge is accurate?
Asked in
What is the difference between SFT and preference tuning (RLHF/DPO)?
Asked in
Hands-on tasks:
You are shown these logs from a fine-tuning run. Diagnose what is happening and say what you would change.
Asked in
epoch 1 train_loss 1.84 val_loss 1.79
epoch 2 train_loss 1.21 val_loss 1.34
epoch 3 train_loss 0.74 val_loss 1.41
epoch 4 train_loss 0.38 val_loss 1.66
epoch 5 train_loss 0.14 val_loss 1.95An interviewer asks you to explain fine-tuning to a non-technical stakeholder in under a minute, and to say plainly what it will and won't fix. Write your answer.
Asked in
FAQ
How long does a fine-tune take?
For a few thousand examples with LoRA, typically minutes to a few hours on one GPU. Hosted fine-tuning jobs are usually in the same range. The compute is rarely the bottleneck — the dataset is.
What learning rate should I use?
Start from your framework's or provider's default, which is chosen sensibly. LoRA generally wants a higher rate than full fine-tuning (often around 1e-4 to 2e-4) because far fewer parameters are moving. Then tune against validation loss rather than against a number from a blog post.
Can I fine-tune a model that was already fine-tuned?
Technically yes, and it compounds the risks: more drift from the base, more forgetting, and a longer chain of versions to reproduce. It is usually cleaner to re-tune from the base with a combined dataset — which is also why versioning the dataset matters so much (lesson 6).
Next lesson: the part that actually takes the weeks — building a dataset that teaches the right thing — Lesson 3: Preparing Training Data →