Topic 13.5
When Fine-Tuning Helps (and When It Doesn't)
In one line
Fine-tuning continues a model's training on your own examples. It is good at teaching a format, a style or a narrow task, and poor at adding facts, which belong in retrieval. Try prompts and retrieval first.
Think of it like this
A chef who already cooks everything, hired for your restaurant. Training them in your house style (how you plate, how you greet guests, how you word the menu) works well, and after a week they do it without being told. But training does not teach them today's prices or this week's specials. For that you hand them the menu every morning. House style is fine-tuning. The daily menu is retrieval (Phase 8).
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- Fine-tuning
- Continuing a model's training on your own examples so its behaviour changes.
- Training example
- One input paired with the output you want the model to learn.
- Validation set
- Examples kept out of training, used to check that the tuned model works on new inputs.
- LoRA
- A cheap way to fine-tune: freeze the model and learn a small correction made from two thin matrices.
- Rank (r)
- The width of the thin matrices in LoRA. Bigger rank, more parameters, more capacity.
- Adapter
- The small file of LoRA numbers. It is loaded together with the unchanged base model.
- Data leakage
- Test or validation examples that also appear in training, which makes scores look better than they are.
- Overfitting
- Learning the training examples so closely that performance on new inputs gets worse.
Step by step
01Step 1: measure the prompt-only baseline
Before collecting any data, run your eval set (Phase 9) with the best prompt you can write, with examples in it. Write down the pass rate, the tokens per call and the cost. Fine-tuning has to beat this baseline by enough to be worth the extra work, otherwise you have built a more complicated system for nothing.
02Step 2: decide whether the problem is facts or behaviour
If the model gives wrong answers because it does not know your documents, the fix is retrieval. If it knows enough but answers in the wrong shape, tone or length, the fix may be fine-tuning. A quick test: if the right answer would be on a page you could paste into the prompt, you have a retrieval problem.
03Step 3: build a clean data set
Collect real inputs, write or review the desired outputs, normalise the text, remove duplicates, split into training and validation with a fixed seed. The second example does the duplicates, the split and a leakage check on twelve tiny examples. Two of them are the same prompt with different spacing and case, and they must not end up on both sides of the split.
{"messages":[{"role":"user","content":"Where is my refund?"},{"role":"assistant","content":"billing"}]}04Step 4: understand what training changes
Training nudges the weights so the example outputs become more likely for the example inputs. With LoRA the nudge is stored as two thin matrices per chosen layer. The base model stays exactly as it was, which means you can remove the adapter and get the original back.
05Step 5: count what LoRA saves
The first example prints the full size of three matrices, the LoRA size at rank 8, and the share. Over all 32 layers the adapter is around 0.32 percent of the adapted matrices and about 16 megabytes at 16 bits, which is why adapters are easy to store, share and swap.
06Step 6: evaluate against the baseline and watch for regressions
Run the same eval set on the tuned model. Compare it with the baseline per case, not just on average: list cases that got worse (Topic 13.8). Also test inputs unlike your training data, because a tuned model can become worse at everything else. If it does not clearly beat the baseline, do not ship it.
Try it yourself
- 1
Change the rank
In the first example set
R = 64. Predict the LoRA share for the 4,096 x 4,096 matrices before you run. At what rank does the adapter stop being a small fraction of the matrix? - 2
Predict the split
In the second example change the seed from 3 to 8. Do different ids land in validation? Does the leak count stay 0? Why does the leak check not depend on the seed?
- 3
Add a hidden duplicate
Add an example
(13, "Charged twice!", "billing"). Does the normaliser treat it as a duplicate of id 7? What should a stronger normaliser do about punctuation?
Code & diagrams
Matrix shapes are example numbers, not a real model. The formula is the point: r x (d_in + d_out) against d_in x d_out.
Expected output
attention query: full 16777216, LoRA 65536 (0.39 percent)
attention value: full 16777216, LoRA 65536 (0.39 percent)
feed-forward up: full 45088768, LoRA 120832 (0.27 percent)
per layer: full 78643200, LoRA 251904
all 32 layers: full 2516582400, LoRA 8060928 (0.32 percent)
adapter file at 16 bits: 16.1 MB
rank sweep for a 4096 x 4096 matrix:
r=1: 8192 parameters (0.049 percent)
r=4: 32768 parameters (0.195 percent)
r=8: 65536 parameters (0.391 percent)
r=16: 131072 parameters (0.781 percent)
r=64: 524288 parameters (3.125 percent)Twelve tiny examples with two near-duplicates. The shuffle uses the course's seeded generator so every language agrees.
Expected output
kept 10 of 12; dropped duplicate ids: 3, 9
train ids: 8, 7, 4, 11, 6, 2, 10, 12
validation ids: 1, 5
validation prompts that also appear in train: 0
train labels: billing 3, bug 3, other 2
validation labels: billing 1, bug 1, other 0Break it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
Multiply instead of add
In the first example change lora = R * (d_in + d_out) to lora = R * (d_in * d_out).
Break #2
Skip the duplicate check
In the second example change key = normalise(prompt) to key = prompt.
Myth vs fact
Myth
Fine-tuning teaches the model my company's knowledge.
Fact
It mostly teaches behaviour. Facts become blurry, go stale and cannot be cited. Use retrieval for knowledge (Phase 8).
Myth
More training data is always better.
Fact
Wrong or inconsistent examples teach wrong or inconsistent behaviour. A few hundred clean examples can beat thousands of messy ones.
Myth
A fine-tuned model no longer needs a prompt.
Fact
It still needs instructions and the user's input. The prompt gets shorter, not absent.
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
Rank is a capacity dial. Too low and the adapter cannot learn the behaviour, too high and it costs more memory and overfits small data sets. Treat rank as a hyper-parameter and compare two or three values on your validation set.
- ▸
Compare cost per successful task before and after: tuning cost and serving cost on one side, the saved prompt tokens and the cheaper model on the other (Topic 13.2 has the break-even maths).
- ▸
Keep the training data, the base model version, the settings and the eval results together as one record. Fine-tuning is code plus data, and without both you cannot reproduce or roll back (Topic 12.7).
- ▸
A tuned model can become worse at things you did not test. Keep a small general-ability check next to your task eval and look for regressions after every training run.
Remember this
- 1
Why this exists. A prompt has limits. Many examples in every prompt cost tokens on every call (Topic 6.1), a model may still drift from your format, and some behaviours are easier to show with 500 examples than to describe in words. Fine-tuning moves that behaviour out of the prompt and into the model, so a short prompt is enough and the style is consistent.
- 2
What it is. You take a model, show it many examples of an input and the output you want, and continue its training so that its weights change a little in the direction of those examples (Topic 1.7 described how models are trained in the first place). The result is a new version of the model, which you must store, serve and evaluate like any other candidate (Topic 13.1). Hosted providers offer fine-tuning for some of their models, and open-weights models can be tuned on your own hardware. Formats, supported models and prices differ, so follow your provider's documentation.
- 3
When it helps. A fixed output format that prompting cannot make reliable. A voice or tone that must be the same on every reply. A narrow task at high volume (classify, extract, rewrite) where a small tuned model can match a large prompted one at far lower cost (Topic 13.6). Short prompts, because the examples no longer ride along on every call. When it does not help. Adding facts. Facts learned in training come out blurry, go stale, cannot be cited and cannot be deleted. Policies, prices, product documents and anything that changes belong in retrieval, where you can update a document and the next answer is correct (Phase 8).
- 4
The order to try things. First a clear prompt and examples in the prompt (Phase 3). Then structured output and validation (Phase 4). Then retrieval if the problem is missing knowledge (Phase 8). Only then fine-tuning if the problem is still behaviour: format, style, or cost of a long prompt. Each step is cheaper to try and easier to undo than the next, and fine-tuning without an eval set (Phase 9) cannot be judged at all.
- 5
The data decides the result. Quality beats quantity: examples must be correct, consistent and like the real inputs. For a narrow task, a few hundred to a few thousand good examples is a common range, but it depends on the task. Remove duplicates (the second example below does this), hold out a validation set that never enters training, and check that no validation prompt also appears in training, or your scores will be inflated. Do not put secrets or personal data in training sets, because a trained model can repeat what it was trained on (Topic 10.5).
- 6
LoRA in plain words. Changing every weight is expensive. LoRA (low-rank adaptation) freezes the original weights and learns a small correction for chosen weight matrices. A matrix of size d_in x d_out is not changed directly: the correction is the product of two thin matrices of size d_in x r and r x d_out, where r, the rank, is small. That is r x (d_in + d_out) numbers instead of d_in x d_out. The first example counts them: for a 4,096 x 4,096 matrix and r = 8, 65,536 numbers instead of 16,777,216, about 0.39 percent. The learned correction is a small adapter file you can keep next to the base model and swap.
Explain it without notes
When should you fine-tune rather than use retrieval?
Explain LoRA and why its adapter is small.
Why must the validation set be kept out of training, and how do you check?
In what order would you try to fix a feature that gives answers in the wrong format?
Practice
Write lora_params(d_in, d_out, r) and full_params(d_in, d_out), and print both for a 4096 x 4096 matrix with r = 8.
Write train_size(n, percent) that returns how many of n examples go to training using whole-number maths (n * percent // 100), and print it for 10 examples at 80 percent and for 7 examples at 80 percent.
Trade-offs
- ↔
Fine-tuning shortens prompts and stabilises behaviour, but adds data work, training runs, a model to serve and a new thing to evaluate and keep current.
- ↔
A higher LoRA rank learns more but costs more and overfits small data sets more easily.
- ↔
A tuned small model is cheap to run, but it is narrower and can fail on inputs unlike its training data.
Done when you can
Done when you can say whether a problem is about facts or behaviour.
Done when you can list the steps to try before fine-tuning.
Done when you can clean, split and leak-check a training set in code.
Done when you can count LoRA parameters against full parameters.
Done when you can compare a tuned model with the prompt-only baseline per case.