Everything in this course so far has treated the model as frozen: the weights never change, and the context window is the only variable you control. That framing is accurate — and it has one deliberate exception. Sometimes you change the weights themselves. That's fine-tuning, and this track is about when and how to do it.
The Prompting track established that the model is a fixed statistical artifact — the same weights answer every question, for every user, every time. The Feeding track showed how to work around that: RAG, search, and agents inject fresh information into the context window without touching the model at all.
Fine-tuning is the third option, and it's categorically different. Instead of changing what the model reads, you change what the model is. You take an existing trained model and continue training it on your own data, nudging its weights so that the patterns in your data become part of the model itself.
Prompting and RAG hand the model a briefing document before every conversation. Fine-tuning sends the model back to school. After the briefing, the model is unchanged; after school, it's a different model — one that behaves differently even with an empty context window.
The most common misconception about fine-tuning is that it's a way to teach the model new facts. It's a poor tool for that. Facts injected through fine-tuning are absorbed unevenly, can't be updated without retraining, and can't be traced to a source. If your problem is "the model doesn't know about our product catalog," the Feeding track already gave you the right tool: retrieval.
What fine-tuning changes reliably is behavior — the shape, style, and habits of the model's output:
Notice the pattern: these are all things you'd otherwise have to re-explain in every single prompt. Fine-tuning moves instructions out of the context window and into the weights. That has a practical side effect worth naming — shorter prompts mean fewer input tokens on every request, which at volume means real latency and cost savings.
If fine-tuning makes the model natively good at your task, why did this course spend two tracks on prompting and retrieval first? Because fine-tuning has real costs that context engineering doesn't:
It requires data. Not a description of what you want — examples of it. Hundreds to thousands of high-quality input/output pairs that demonstrate the behavior. Assembling and cleaning that dataset is usually the majority of the work.
It requires evaluation. When you change the weights, you can change them in ways you didn't intend. You need a way to measure whether the tuned model is actually better on your task — and whether it got worse at anything you still care about.
It creates an artifact you must maintain. A prompt can be edited in seconds. A fine-tuned model is a versioned asset: when the base model is upgraded, when your requirements shift, when your data distribution drifts, you retrain.
Fine-tuning is a last resort in the best sense: it's what you reach for when you've demonstrated that prompting and retrieval can't get you there. If you haven't seriously tried a well-crafted prompt with good context first, you don't yet have the evidence that you need fine-tuning — and you don't yet have the evaluation baseline to know whether it helped.
Once you've decided the weights need to change, there are two fundamentally different ways to do it. You can update all of them — full fine-tuning — or you can freeze the model and train a small set of added parameters alongside it — parameter-efficient fine-tuning, or PEFT. The difference isn't a minor implementation detail. It changes the hardware you need, the risks you take on, and how you deploy the result.
That choice is the subject of the next page.